From Newsgroup: comp.os.vms

VMSSoftware has posted a YouTube video of the recent webinar with Camiel talking about what's ahead for OpenVMS x86 V9.2-4

https://youtu.be/EbQebijmBcg?si=FKhJD15gs1IDbMf1
--
John H. Reinhardt
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 3/23/2026 8:34 AM, John H. Reinhardt wrote:

-aVMSSoftware has posted a YouTube video of the recent webinar with Camiel talking about what's ahead for OpenVMS x86 V9.2-4

https://youtu.be/EbQebijmBcg?si=FKhJD15gs1IDbMf1

Forgot the links to
Webinar Slides - https://vmssoftware.com/docs/2026-03-19-openvms924-beyond.pdf
Q & A - Link didn't work. TBD
--
John H. Reinhardt

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 3/23/2026 4:05 PM, Simon Clubley wrote:

On 2026-03-23, John H. Reinhardt <johnhreinhardt@thereinhardts.org> wrote:

VMSSoftware has posted a YouTube video of the recent webinar with Camiel talking about what's ahead for OpenVMS x86 V9.2-4

https://youtu.be/EbQebijmBcg?si=FKhJD15gs1IDbMf1

I skipped through this and saw some interesting items.

I wonder if anyone will complain about the removal of the telnet server ?

The signed execlets is interesting but that only protects you against alterations to the on-disk files containing those execlets.

The same sentence also talks about drivers. I wonder if user-supplied
drivers will also need to be signed and what the procedure for that
will be if this is the case ?

BTW, the first video in the sidebar for me was "Linux Age Verification".

So when does VMS get all this new age verification API nonsense ? :-)

I get a real kick out of all this Age Verification stuff.
Have we already forgotten: "On the INTERNET no one can tell your a dog."

bill


--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2026-03-23, bill <bill.gunshannon@gmail.com> wrote:

On 3/23/2026 4:05 PM, Simon Clubley wrote:

On 2026-03-23, John H. Reinhardt <johnhreinhardt@thereinhardts.org> wrote: >>> VMSSoftware has posted a YouTube video of the recent webinar with Camiel talking about what's ahead for OpenVMS x86 V9.2-4

https://youtu.be/EbQebijmBcg?si=FKhJD15gs1IDbMf1

I skipped through this and saw some interesting items.

I wonder if anyone will complain about the removal of the telnet server ?

The signed execlets is interesting but that only protects you against
alterations to the on-disk files containing those execlets.

The same sentence also talks about drivers. I wonder if user-supplied
drivers will also need to be signed and what the procedure for that
will be if this is the case ?

BTW, the first video in the sidebar for me was "Linux Age Verification".

So when does VMS get all this new age verification API nonsense ? :-)

I get a real kick out of all this Age Verification stuff.
Have we already forgotten: "On the INTERNET no one can tell your a dog."

This latest push, this time against the operating systems themselves,
seems to have come out of nowhere over the last few months.

I wonder what's really driving it ?

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10puk74$18v2v$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2026-03-23, bill <bill.gunshannon@gmail.com> wrote:

On 3/23/2026 4:05 PM, Simon Clubley wrote:

On 2026-03-23, John H. Reinhardt <johnhreinhardt@thereinhardts.org> wrote: >>>> VMSSoftware has posted a YouTube video of the recent webinar with Camiel talking about what's ahead for OpenVMS x86 V9.2-4

https://youtu.be/EbQebijmBcg?si=FKhJD15gs1IDbMf1

I skipped through this and saw some interesting items.

I wonder if anyone will complain about the removal of the telnet server ? >>>
The signed execlets is interesting but that only protects you against
alterations to the on-disk files containing those execlets.

The same sentence also talks about drivers. I wonder if user-supplied
drivers will also need to be signed and what the procedure for that
will be if this is the case ?

BTW, the first video in the sidebar for me was "Linux Age Verification". >>>
So when does VMS get all this new age verification API nonsense ? :-)

I get a real kick out of all this Age Verification stuff.
Have we already forgotten: "On the INTERNET no one can tell your a dog."

This latest push, this time against the operating systems themselves,
seems to have come out of nowhere over the last few months.

I wonder what's really driving it ?

Mostly misunderstanding. :-D

The state of California apparently passed a law that systems
that have an "App Store" like thing need to verify the age of
people who are buying apps from that store. In doing so, they
seem to have conflated the concept of an, "Operating System"
with the iOS/macOS and Android application ecosystems: the
language of the law talks about Operating Systems, specifically,
though I understand there's specific language about app stores
or equivalents.

It's really just goofy.

- Dan C.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

Dan Cross <cross@spitfire.i.gajendra.net> wrote:

The state of California apparently passed a law that systems
that have an "App Store" like thing need to verify the age of
people who are buying apps from that store. In doing so, they
seem to have conflated the concept of an, "Operating System"
with the iOS/macOS and Android application ecosystems: the
language of the law talks about Operating Systems, specifically,
though I understand there's specific language about app stores
or equivalents.

This is what happens when nontechnical people attempt to legislate technological solutions to social problems.

I'm still waiting to hear what WindRiver is going to be doing about
this.

This is on a par with the ECPA of 1986 which defines subcarriers
as a form of encryption and consequently makes it illegal to listen
to stereo FM.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10pv597$cdr$1@panix2.panix.com>,
Scott Dorsey <kludge@panix.com> wrote:

Dan Cross <cross@spitfire.i.gajendra.net> wrote:

The state of California apparently passed a law that systems
that have an "App Store" like thing need to verify the age of
people who are buying apps from that store. In doing so, they
seem to have conflated the concept of an, "Operating System"
with the iOS/macOS and Android application ecosystems: the
language of the law talks about Operating Systems, specifically,
though I understand there's specific language about app stores
or equivalents.

This is what happens when nontechnical people attempt to legislate >technological solutions to social problems.

100%

I'm still waiting to hear what WindRiver is going to be doing about
this.

Can't have underage martians buying random bits of malware from
the rovers now, can we?

This is on a par with the ECPA of 1986 which defines subcarriers
as a form of encryption and consequently makes it illegal to listen
to stereo FM.

Or the time the FCC almost auctioned off the color orange.

- Dan C.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Tue, 24 Mar 2026 19:04:07 -0400 (EDT)
kludge@panix.com (Scott Dorsey) wrote:

Dan Cross <cross@spitfire.i.gajendra.net> wrote:

The state of California apparently passed a law that systems
that have an "App Store" like thing need to verify the age of
people who are buying apps from that store. In doing so, they
seem to have conflated the concept of an, "Operating System"
with the iOS/macOS and Android application ecosystems: the
language of the law talks about Operating Systems, specifically,
though I understand there's specific language about app stores
or equivalents.

This is what happens when nontechnical people attempt to legislate technological solutions to social problems.

Do you want to say that if they were technical people then they would
do better?

I'm still waiting to hear what WindRiver is going to be doing about
this.

This is on a par with the ECPA of 1986 which defines subcarriers
as a form of encryption and consequently makes it illegal to listen
to stereo FM.
--scott

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 3/23/2026 4:05 PM, Simon Clubley wrote:

BTW, the first video in the sidebar for me was "Linux Age Verification".

So when does VMS get all this new age verification API nonsense ? :-)

Well - Linux supposedly put it in systemd.

So on VMS it obviously has to go in SYSTARTUP_VMS!

So maybe someone in VSI is going over the bookshelf
trying to find their old copy of Paul A and Hoff's
old book.

:-) :-) :-)

Arne

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2026-03-24, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <10puk74$18v2v$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

This latest push, this time against the operating systems themselves,
seems to have come out of nowhere over the last few months.

I wonder what's really driving it ?

Mostly misunderstanding. :-D

The state of California apparently passed a law that systems
that have an "App Store" like thing need to verify the age of
people who are buying apps from that store. In doing so, they
seem to have conflated the concept of an, "Operating System"
with the iOS/macOS and Android application ecosystems: the
language of the law talks about Operating Systems, specifically,
though I understand there's specific language about app stores
or equivalents.

It's really just goofy.

That's what it looks like to me as well.

There's an interesting new claim in this area I had not seen before:

https://www.theregister.com/2026/03/24/foss_age_verification/

The claim is that Meta and other organisations are actively lobbying
for these new laws.

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10q1a6m$26gqo$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2026-03-24, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <10puk74$18v2v$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

This latest push, this time against the operating systems themselves, >>>seems to have come out of nowhere over the last few months.

I wonder what's really driving it ?

Mostly misunderstanding. :-D

The state of California apparently passed a law that systems
that have an "App Store" like thing need to verify the age of
people who are buying apps from that store. In doing so, they
seem to have conflated the concept of an, "Operating System"
with the iOS/macOS and Android application ecosystems: the
language of the law talks about Operating Systems, specifically,
though I understand there's specific language about app stores
or equivalents.

It's really just goofy.

That's what it looks like to me as well.

There's an interesting new claim in this area I had not seen before:

https://www.theregister.com/2026/03/24/foss_age_verification/

The claim is that Meta and other organisations are actively lobbying
for these new laws.

Reading between the lines, Meta et al would love to kick the age
verification can for their services down the road to the OS
vendors. Under 13-year olds can't download the Facebook app if
the machine they use has already verified that they're not
under 13.

It's all so stupid.

- Dan C.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2026-03-25, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

Or the time the FCC almost auctioned off the color orange.

I did a quick search for this and didn't find anything.

What was the story here ? Someone try selling off the wrong part of
the EM spectrum by mistake ? :-)

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10q1ao5$26gqo$2@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2026-03-25, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

Or the time the FCC almost auctioned off the color orange.

I did a quick search for this and didn't find anything.

What was the story here ? Someone try selling off the wrong part of
the EM spectrum by mistake ? :-)

It may be apocryphal, but as the joke goes, a group of $INSERT_YOUR_FAVORITE_INSTITUTION_HERE (I think I heard MIT)
students approached the FCC about licensing the rights to a
particular part of the RF spectrum. The FCC saw no problem
with it, and was about to finalize it when someone pointed out
that the frequencies in question corresponded to the color
orange in the visible light part of the spectrum. Oops. :-)

- Dan C.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Wed, 25 Mar 2026 11:00:50 -0400, Arne Vajh|+j wrote:

So when does VMS get all this new age verification API nonsense ? :-)

Well - Linux supposedly put it in systemd.

All IrCOm aware of, is that a date-of-birth field has been added to the
user info schema. As is the *nix tradition, this is just an addition
to the mechanism, not a policy change. The policy, as usual, is
dictated by the humans who control the system; this just gives them a
new option, nothing more.

That this change itself was already considered something
controversial, is a separate issue ...
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

It may be apocryphal, but as the joke goes, a group of $INSERT_YOUR_FAVORITE_INSTITUTION_HERE (I think I heard MIT)
students approached the FCC about licensing the rights to a
particular part of the RF spectrum. The FCC saw no problem
with it, and was about to finalize it when someone pointed out
that the frequencies in question corresponded to the color
orange in the visible light part of the spectrum. Oops. :-)

Ah, the return of the son of dihydrogen monoxide.

De
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 25 Mar 2026, Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> posted some news:10q1d2t$27ik8$2@dont-email.me:

On Wed, 25 Mar 2026 11:00:50 -0400, Arne Vajh|+j wrote:

So when does VMS get all this new age verification API nonsense ? :-)

Well - Linux supposedly put it in systemd.

All IrCOm aware of, is that a date-of-birth field has been added to the
user info schema. As is the *nix tradition, this is just an addition
to the mechanism, not a policy change. The policy, as usual, is
dictated by the humans who control the system; this just gives them a
new option, nothing more.

That this change itself was already considered something
controversial, is a separate issue ...

The problem isn't so much the OS as the device.

The majority of kids don't use computers much anymore. They use smart
phones and tablets. Add an age variable to the device firmware that can
be queried.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2026-03-31, 11/70 toggler <none@08.00.20> wrote:

On 25 Mar 2026, Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> posted some news:10q1d2t$27ik8$2@dont-email.me:

On Wed, 25 Mar 2026 11:00:50 -0400, Arne Vajh|+j wrote:

So when does VMS get all this new age verification API nonsense ? :-)

Well - Linux supposedly put it in systemd.

All IrCOm aware of, is that a date-of-birth field has been added to the
user info schema. As is the *nix tradition, this is just an addition
to the mechanism, not a policy change. The policy, as usual, is
dictated by the humans who control the system; this just gives them a
new option, nothing more.

That this change itself was already considered something
controversial, is a separate issue ...

The problem isn't so much the OS as the device.

The majority of kids don't use computers much anymore. They use smart phones and tablets. Add an age variable to the device firmware that can
be queried.

Or everyone can tell Meta (and their lackey governments) to sod off.

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Tue, 31 Mar 2026 12:12:47 -0000 (UTC)
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2026-03-31, 11/70 toggler <none@08.00.20> wrote:

On 25 Mar 2026, Lawrence =?iso-8859-13?q?D=FFOliveiro?=
<ldo@nz.invalid> posted some news:10q1d2t$27ik8$2@dont-email.me:

On Wed, 25 Mar 2026 11:00:50 -0400, Arne Vajh|a-+j wrote:

So when does VMS get all this new age verification API nonsense
? :-)

Well - Linux supposedly put it in systemd.

All I|ore4raom aware of, is that a date-of-birth field has been added
to the user info schema. As is the *nix tradition, this is just an
addition to the mechanism, not a policy change. The policy, as
usual, is dictated by the humans who control the system; this just
gives them a new option, nothing more.

That this change itself was already considered something
controversial, is a separate issue ...

The problem isn't so much the OS as the device.

The majority of kids don't use computers much anymore. They use
smart phones and tablets. Add an age variable to the device
firmware that can be queried.

Or everyone can tell Meta (and their lackey governments) to sod off.

Simon.

Meta is from USA.
The goverment that started this particular Bedlam was Aus.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 3/31/2026 10:31 AM, Michael S wrote:

On Tue, 31 Mar 2026 12:12:47 -0000 (UTC)
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2026-03-31, 11/70 toggler <none@08.00.20> wrote:

The majority of kids don't use computers much anymore. They use
smart phones and tablets. Add an age variable to the device
firmware that can be queried.

Or everyone can tell Meta (and their lackey governments) to sod off.

Meta is from USA.
The goverment that started this particular Bedlam was Aus.

The idea is being discussed in many countries.

UK:

https://www.eff.org/deeplinks/2026/03/uk-politicians-continue-miss-point-latest-social-media-ban-proposal

Denmark:

https://www.dw.com/en/denmark-to-ban-social-media-for-children-under-15/a-74666210

Arne


--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Tue, 31 Mar 2026 10:40:19 -0400
Arne Vajhoj <arne@vajhoej.dk> wrote:

On 3/31/2026 10:31 AM, Michael S wrote:

On Tue, 31 Mar 2026 12:12:47 -0000 (UTC)
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2026-03-31, 11/70 toggler <none@08.00.20> wrote:

The majority of kids don't use computers much anymore. They use
smart phones and tablets. Add an age variable to the device
firmware that can be queried.

Or everyone can tell Meta (and their lackey governments) to sod
off.

Meta is from USA.
The goverment that started this particular Bedlam was Aus.

The idea is being discussed in many countries.

UK:

https://www.eff.org/deeplinks/2026/03/uk-politicians-continue-miss-point-latest-social-media-ban-proposal

Denmark:

https://www.dw.com/en/denmark-to-ban-social-media-for-children-under-15/a-74666210

Arne

They are discussin it still. AFAIK, in Australia it's already a law.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2026-03-31, Michael S <already5chosen@yahoo.com> wrote:

Meta is from USA.

Headquarters in the US but international in scope.

I've been looking into this a bit since it was suggested that Meta
and others were behind this.

It turns out that Meta are having a serious problem with AI slop
when it comes to trying to sell advertising because they can't
easily prove who is actually a real user.

By verifying that an account belongs to a real user, they will now
know who is a real user when it comes to being able to sell advertising.

However, the twist is that Meta appears to be pushing for this to be implemented at device level, so they can benefit from it, but without
having to implement it themselves.

Ie: If Meta have their way, everyone suffers so that Meta can benefit,
even those who would never go near a Meta application.

The goverment that started this particular Bedlam was Aus.

I don't know if Meta were responsible for this one, or if they merely
saw the bandwagon (and an opportunity) and then jumped on it, but by establishing a series of smaller events around the world, you build up
momentum for the larger markets.

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10qf17a$2t6ig$1@dont-email.me>, ldo@nz.invalid says...

On Tue, 31 Mar 2026 08:16:33 +1300, David Goodwin wrote:

In article <10ps6eh$ei2s$2@dont-email.me>, clubley@remove_me.eisner.decus.org-Earth.UFP says...

I wonder if anyone will complain about the removal of the telnet
server ?

A little disappointing - its the only telnet server I've encountered
that will actually try to negotiate a terminal type with the client.

Perhaps because these days it will likely not be the Telnet/SSH client
that is performing the actual terminal emulation?

I don't think telnet servers skipping this is a new thing - I've got
plenty of vintage unix around here and none of them try to negotiate a terminal type that I've noticed.

Probably just one of the many telnet options that never became
widespread - like encryption.



--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10qgdnu$3amha$1@dont-email.me>, clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:

Or everyone can tell Meta (and their lackey governments) to sod off.

Meta's products are pretty good at getting people to produce endorphins,
and too many people can't imagine a happy life without them.

John
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 3/31/2026 2:18 PM, David Goodwin wrote:

In article <10qf17a$2t6ig$1@dont-email.me>, ldo@nz.invalid says...

On Tue, 31 Mar 2026 08:16:33 +1300, David Goodwin wrote:

In article <10ps6eh$ei2s$2@dont-email.me>,
clubley@remove_me.eisner.decus.org-Earth.UFP says...

I wonder if anyone will complain about the removal of the telnet
server ?

A little disappointing - its the only telnet server I've encountered
that will actually try to negotiate a terminal type with the client.

Perhaps because these days it will likely not be the Telnet/SSH client
that is performing the actual terminal emulation?

I don't think telnet servers skipping this is a new thing - I've got
plenty of vintage unix around here and none of them try to negotiate a terminal type that I've noticed.

Probably just one of the many telnet options that never became
widespread - like encryption.

I can't imagine why any telnet server would ever care what the terminal
type was. Need to know a terminal type would be at the applications
layer. What ever you connected to should be the one querying for the
terminal type. On Unix, the shell (which is where the user enters a
terminal type if needed and not queried) and I would expect DCL or the
login process on VMS.

bill

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <n33as6FarsoU1@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:

On 3/31/2026 2:18 PM, David Goodwin wrote:

In article <10qf17a$2t6ig$1@dont-email.me>, ldo@nz.invalid says...

On Tue, 31 Mar 2026 08:16:33 +1300, David Goodwin wrote:

In article <10ps6eh$ei2s$2@dont-email.me>,
clubley@remove_me.eisner.decus.org-Earth.UFP says...

I wonder if anyone will complain about the removal of the telnet
server ?

A little disappointing - its the only telnet server I've encountered
that will actually try to negotiate a terminal type with the client.

Perhaps because these days it will likely not be the Telnet/SSH client
that is performing the actual terminal emulation?

I don't think telnet servers skipping this is a new thing - I've got
plenty of vintage unix around here and none of them try to negotiate a
terminal type that I've noticed.

Probably just one of the many telnet options that never became
widespread - like encryption.

I can't imagine why any telnet server would ever care what the terminal
type was.

RFC 1091 says that the motivation was to support multiple
terminal types at the beginning of a session, _and_ to support
server-driven changes, mid-session. Putting that into the
protocol makes some sense: it enables a server to signal an
automatic change to a client. For example, perhaps the user
runs some program that generates Tek vector codes; the session
could pop up a graphical window containing the drawing
automatically, and return to the normal mode once done.

Need to know a terminal type would be at the applications
layer. What ever you connected to should be the one querying for the >terminal type. On Unix, the shell (which is where the user enters a
terminal type if needed and not queried) and I would expect DCL or the
login process on VMS.

On Unix, the handling of terminals is inelegant, at best. The
responsibility for dealing with them is handled across the
kernel and a smattering of userspace libraries and programs;
historically, the shell was more or less not involved, instead
delegating to the kernel's "TTY" layer for e.g., input handling,
and not caring at all about output handling.

This has changed over time, as users have demanded richer models
of interaction.

Also, the protocol becomes the natural place to handle some
display oriented options: Consider something like resizing a
graphical terminal window (such as an xterm or something)
running a telnet session; one wants the distant end to pick up
the new window dimensions and reflect those to an application
(say, a text editor). A special protocol message that's
interpreted by the server and injected into an application some
how can be useful: on Unix, the telnet/ssh server usually does
this via the terminal driver, which will generate a SIGWINCH to
the application.

- Dan C.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 3/30/2026 3:16 PM, David Goodwin wrote:

In article <10ps6eh$ei2s$2@dont-email.me>, clubley@remove_me.eisner.decus.org-Earth.UFP says...

I wonder if anyone will complain about the removal of the telnet server ?

A little disappointing - its the only telnet server I've encountered
that will actually try to negotiate a terminal type with the client.

Is it important?

I would expect either SYLOGIN/LOGIN to do a
SET TERM/INQ or an application explicit send
<CSI>c or <ESC>[c and parse the <CSI>6nc or
<ESC>[6nc response to get n (VTn00).

Arne

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

=?UTF-8?Q?Arne_Vajh=C3=B8j?= <arne@vajhoej.dk> wrote:

On 3/30/2026 3:16 PM, David Goodwin wrote:

In article <10ps6eh$ei2s$2@dont-email.me>,
clubley@remove_me.eisner.decus.org-Earth.UFP says...

I wonder if anyone will complain about the removal of the telnet server ? >>

A little disappointing - its the only telnet server I've encountered
that will actually try to negotiate a terminal type with the client.

Is it important?

I would expect either SYLOGIN/LOGIN to do a
SET TERM/INQ or an application explicit send
<CSI>c or <ESC>[c and parse the <CSI>6nc or
<ESC>[6nc response to get n (VTn00).

Yes. It's DCL doing the negotiation, not telnet. You can do the same thing with Unix using tset still, I think.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <69cdb5bf$0$676$14726298@news.sunsite.dk>, arne@vajhoej.dk
says...

On 3/30/2026 3:16 PM, David Goodwin wrote:

In article <10ps6eh$ei2s$2@dont-email.me>, clubley@remove_me.eisner.decus.org-Earth.UFP says...

I wonder if anyone will complain about the removal of the telnet server ?

A little disappointing - its the only telnet server I've encountered
that will actually try to negotiate a terminal type with the client.

Is it important?

I would expect either SYLOGIN/LOGIN to do a
SET TERM/INQ or an application explicit send
<CSI>c or <ESC>[c and parse the <CSI>6nc or
<ESC>[6nc response to get n (VTn00).

Not important at all, just a surprising thing to see happen. Set Kermit
95 to emulate something completely foreign to OpenVMS (DG Dasher 200,
Linux console terminal, whatever), telnet to an OpenVMS box, then watch
Kermit 95 start iterating through its terminal emulations until it finds
one OpenVMS recognises before you ever get to the login prompt.

As for probing the terminal to figure out what it is, that only helps if
what it is turns out to be is something OpenVMS can work with. Sending
it a <CSI>c starts out with the assumption you're dealing with something vaguely ANSI-shaped, and IIRC the standard says nothing about what the response should be so its possible any answer you get may be unhelpful.

Of course the solution to all of this is to just set your terminal
emulator to VT320 or similar when pointing it at OpenVMS if you want
things to work. No need for the telnet client and server to come to some
sort of agreement.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 4/1/2026 10:12 PM, David Goodwin wrote:

In article <69cdb5bf$0$676$14726298@news.sunsite.dk>, arne@vajhoej.dk
says...

On 3/30/2026 3:16 PM, David Goodwin wrote:

In article <10ps6eh$ei2s$2@dont-email.me>,
clubley@remove_me.eisner.decus.org-Earth.UFP says...

I wonder if anyone will complain about the removal of the telnet server ? >>>

A little disappointing - its the only telnet server I've encountered
that will actually try to negotiate a terminal type with the client.

Is it important?

I would expect either SYLOGIN/LOGIN to do a
SET TERM/INQ or an application explicit send
<CSI>c or <ESC>[c and parse the <CSI>6nc or
<ESC>[6nc response to get n (VTn00).

Not important at all, just a surprising thing to see happen. Set Kermit
95 to emulate something completely foreign to OpenVMS (DG Dasher 200,
Linux console terminal, whatever), telnet to an OpenVMS box, then watch Kermit 95 start iterating through its terminal emulations until it finds
one OpenVMS recognises before you ever get to the login prompt.

As for probing the terminal to figure out what it is, that only helps if
what it is turns out to be is something OpenVMS can work with. Sending
it a <CSI>c starts out with the assumption you're dealing with something vaguely ANSI-shaped, and IIRC the standard says nothing about what the response should be so its possible any answer you get may be unhelpful.

Of course the solution to all of this is to just set your terminal
emulator to VT320 or similar when pointing it at OpenVMS if you want
things to work. No need for the telnet client and server to come to some
sort of agreement.

Trying to use anything not VT100+ with VMS is going to be limited.
I would not even want to use anything not VT200+.

EDT in line mode should work with anything. But ...

:-)

Arne

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <69cddd17$0$676$14726298@news.sunsite.dk>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 4/1/2026 10:12 PM, David Goodwin wrote:

In article <69cdb5bf$0$676$14726298@news.sunsite.dk>, arne@vajhoej.dk
says...

On 3/30/2026 3:16 PM, David Goodwin wrote:

In article <10ps6eh$ei2s$2@dont-email.me>,
clubley@remove_me.eisner.decus.org-Earth.UFP says...

I wonder if anyone will complain about the removal of the telnet server ? >>>>

A little disappointing - its the only telnet server I've encountered
that will actually try to negotiate a terminal type with the client.

Is it important?

I would expect either SYLOGIN/LOGIN to do a
SET TERM/INQ or an application explicit send
<CSI>c or <ESC>[c and parse the <CSI>6nc or
<ESC>[6nc response to get n (VTn00).

Not important at all, just a surprising thing to see happen. Set Kermit
95 to emulate something completely foreign to OpenVMS (DG Dasher 200,
Linux console terminal, whatever), telnet to an OpenVMS box, then watch
Kermit 95 start iterating through its terminal emulations until it finds
one OpenVMS recognises before you ever get to the login prompt.

As for probing the terminal to figure out what it is, that only helps if
what it is turns out to be is something OpenVMS can work with. Sending
it a <CSI>c starts out with the assumption you're dealing with something
vaguely ANSI-shaped, and IIRC the standard says nothing about what the
response should be so its possible any answer you get may be unhelpful.

Of course the solution to all of this is to just set your terminal
emulator to VT320 or similar when pointing it at OpenVMS if you want
things to work. No need for the telnet client and server to come to some
sort of agreement.

Trying to use anything not VT100+ with VMS is going to be limited.
I would not even want to use anything not VT200+.

EDT in line mode should work with anything. But ...

:-)

EDT in line mode works amazingly well over AX.25 packet radio.

- Dan C.

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2026-04-01, Arne Vajhoj <arne@vajhoej.dk> wrote:

Trying to use anything not VT100+ with VMS is going to be limited.
I would not even want to use anything not VT200+.

TECO with the VTEDIT macro worked just fine in VT52 mode IIRC and so
did EDT also IIRC (both on RSTS/E so it's a long time ago so I can't
remember for sure).

Do they both still work in VT52 mode these days ?

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 4/2/2026 8:33 AM, Simon Clubley wrote:

On 2026-04-01, Arne Vajh|+j <arne@vajhoej.dk> wrote:

Trying to use anything not VT100+ with VMS is going to be limited.
I would not even want to use anything not VT200+.

TECO with the VTEDIT macro worked just fine in VT52 mode IIRC and so
did EDT also IIRC (both on RSTS/E so it's a long time ago so I can't
remember for sure).

Do they both still work in VT52 mode these days ?

I had completely forgotten about the VT52. It was
made obsolete by the VT100 in 1978.

TECO is not available on VMS x86-64. But on the older
platforms it probably still works fine with VT52 as I suspect
nobody has changed the code since maybe the late 70s'.

And similar with EDT - it worked back then and
if nobody has changed the code since maybe the mid 80's,
then it should still work.

But I would still not want to use VMS with a VT52.

Arne



--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms


On 4/2/26 8:05 AM, Arne Vajh|+j wrote:

On 4/2/2026 8:33 AM, Simon Clubley wrote:

On 2026-04-01, Arne Vajh|+j <arne@vajhoej.dk> wrote:

Trying to use anything not VT100+ with VMS is going to be limited.
I would not even want to use anything not VT200+.

TECO with the VTEDIT macro worked just fine in VT52 mode IIRC and so
did EDT also IIRC (both on RSTS/E so it's a long time ago so I can't
remember for sure).

Do they both still work in VT52 mode these days ?

I had completely forgotten about the VT52. It was
made obsolete by the VT100 in 1978.

TECO is not available on VMS x86-64. But on the older
platforms it probably still works fine with VT52 as I suspect
nobody has changed the code since maybe the late 70s'.

And similar with EDT - it worked back then and
if nobody has changed the code since maybe the mid 80's,
then it should still work.

But I would still not want to use VMS with a VT52.

I think it was the only option to be able to use EDT within the Alpha
SRM console. But otherwise, yeah, not much use in recent decades.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Thu, 2 Apr 2026 09:05:56 -0400, Arne Vajh|+j wrote:

I had completely forgotten about the VT52. It was made obsolete by
the VT100 in 1978.

Not completely -- not immediately. Remember the typical speed of
serial lines in those days; quite a few people realized that VT52
escape sequences, less elegant and more limited though they were, were
shorter than the corresponding VT100 sequences, and so still worth
using in some situations, if you wanted to get that little bit of
extra speed in your user interaction.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2026-04-02, Arne Vajhoj <arne@vajhoej.dk> wrote:

And similar with EDT - it worked back then and
if nobody has changed the code since maybe the mid 80's,
then it should still work.

Didn't someone at VSI change VSI to support terminal heights greater than
24 lines for >= VT100 ?

I wonder if that had any impact on the VT52 support.

But I would still not want to use VMS with a VT52.

Hmmm... Wimp... :-)

However, it is amazing what we once had to put up with.

I actually had to use an ASR33 keyboard at one point as a school student (non-DEC system) and was _very_ glad when I never had to touch the damn
thing ever again.

A TTY43 keyboard was luxury by comparison...

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2026-04-07, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2026-04-02, Arne Vajhoj <arne@vajhoej.dk> wrote:

And similar with EDT - it worked back then and
if nobody has changed the code since maybe the mid 80's,
then it should still work.

Didn't someone at VSI change VSI to support terminal heights greater than
24 lines for >= VT100 ?

"VSI change VSI" => "VSI change EDT". Sorry.

I wonder if that had any impact on the VT52 support.

But I would still not want to use VMS with a VT52.

Hmmm... Wimp... :-)

However, it is amazing what we once had to put up with.

I actually had to use an ASR33 keyboard at one point as a school student (non-DEC system) and was _very_ glad when I never had to touch the damn
thing ever again.

A TTY43 keyboard was luxury by comparison...

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 4/7/2026 8:17 AM, Simon Clubley wrote:

On 2026-04-02, Arne Vajh|+j <arne@vajhoej.dk> wrote:

And similar with EDT - it worked back then and
if nobody has changed the code since maybe the mid 80's,
then it should still work.

Didn't someone at VSI change EDT to support terminal heights greater than
24 lines for >= VT100 ?

Possible. That would have been when DECTerm was introduced
I assume.

They probably also had to make some technical changes to
the Macro-32 to get it to compile on Alpha.

But not likely to break anything.

Arne

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 4/7/2026 09:35, Arne Vajh|+j wrote:

On 4/7/2026 8:17 AM, Simon Clubley wrote:

On 2026-04-02, Arne Vajh|+j <arne@vajhoej.dk> wrote:

And similar with EDT - it worked back then and
if nobody has changed the code since maybe the mid 80's,
then it should still work.

Didn't someone at VSI change EDT to support terminal heights greater than
24 lines for >= VT100 ?

Possible. That would have been when DECTerm was introduced
I assume.

They probably also had to make some technical changes to
the Macro-32 to get it to compile on Alpha.

But not likely to break anything.

The change to which Simon refers was made in 2017 for the
never-released V8.5 version.

Those changes propagated into the V9 stream, so X86 users
have those changes.
--
-- Rob
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 4/7/26 17:12, Robert A. Brooks wrote:

The change to which Simon refers was made in 2017 for the
never-released V8.5 version.

Those changes propagated into the V9 stream, so X86 users
have those changes.

I don't know how the change made it to "OpenVMS V8.4-2L2 on node
EISNER". It has it; give it a try.

EDT (and EVE aka EDIT/TPU and LSE) still do not support alternate
screens. A feature almost every current terminal emulator has. And all
editors I used on Linux use it. When switching to screen mode, EDT still
wipes out the current screen so anything on it is lost.

The poor man's approach for emulators with a scrolling region is to
press <RETURN> until the contents are scrolled out of the current screen.

Another workaround is
$ cre edtalt.com
$ esc[0,8]=27
$ write sys$output esc,"[?1049h"
$ define/user sys$input sys$command
$ edit/edt 'p1
$ write sys$output esc,"[?1049l"
^Z
$
$ @edtalt login.com
...

Or use an editor that supports it, my version of JED - actually slang
(or my version of EDT[SHR] when I was able to build my own one).

OK, it may be only me, but I wouldn't want to use a VT editor that
didn't have this feature.

All the other VMS tools that use screen mode wipe the current screen as
well. Maybe it's time to check how the debugger and friends clear the
screen. If it is an SMG routine...

PS: My "hexedit" for VMS uses my version of slang, so it works as I
expect it to work.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10r3jrf$31vrm$1@dont-email.me>, mw40171@mucweb.de says...

On 4/7/26 17:12, Robert A. Brooks wrote:

The change to which Simon refers was made in 2017 for the
never-released V8.5 version.

Those changes propagated into the V9 stream, so X86 users
have those changes.

I don't know how the change made it to "OpenVMS V8.4-2L2 on node
EISNER". It has it; give it a try.

EDT (and EVE aka EDIT/TPU and LSE) still do not support alternate
screens. A feature almost every current terminal emulator has. And all editors I used on Linux use it. When switching to screen mode, EDT still wipes out the current screen so anything on it is lost.

You don't need a recent terminal emulator to achieve this effect. The VT330/VT340 had everything you need in 1987, and all newer terminals
(VT420, VT510, VT520, VT525 and I *assume* DECterm) can do it too. That
I know of, Windows Terminal and the next releases of Kermit 95 and
Countour will also support the same mechanism: paging.

And xterms alternate screen is really just a limited subset of the VT
paging feature, but using a few private modes (1047/1048/1049) rather
than control sequences (NP/PP/PPA/PPR/PPB). Main differences are that VT paging has:
- At least 5 pages (I believe up to 22 on the VT520 with a memory
cartridge in the back) when multiple sessions aren't in use.
- Ability to copy content between pages on the VT420 and up (DECCRA)
- Ability to write to other pages in the background (DECPCCM)
- Margins (top/bottom/left/right) are per-page
- Switching to another page doesn't automatically save the cursor in a special saved cursor buffer like the xterm alternate screen. Instead you
have to request a Cursor Information Report (DECCIR) via DECRQPSR, and
restore it later with DECRSPS if you want that behaviour.

So EDT, etc, *could* have been doing this over 30 years ago on
sufficiently modern hardware terminals - no need to wait for xterms
alternate screen to become widespread.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 4/7/2026 11:12 AM, Robert A. Brooks wrote:

On 4/7/2026 09:35, Arne Vajh|+j wrote:

On 4/7/2026 8:17 AM, Simon Clubley wrote:

On 2026-04-02, Arne Vajh|+j <arne@vajhoej.dk> wrote:

And similar with EDT - it worked back then and
if nobody has changed the code since maybe the mid 80's,
then it should still work.

Didn't someone at VSI change EDT to support terminal heights greater
than
24 lines for >= VT100 ?

Possible. That would have been when DECTerm was introduced
I assume.

The change to which Simon refers was made in 2017 for the
never-released V8.5 version.

Those changes propagated into the V9 stream, so X86 users
have those changes.

Oh. That was late.

Why do I get the feeling that VSI has at least one
engineer that:
- prefer EDT over EVE
- has large monitor
- knows Macro-32
?

:-) :-) :-)

Arne


--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 4/7/2026 7:34 PM, Arne Vajh|+j wrote:

On 4/7/2026 11:12 AM, Robert A. Brooks wrote:

On 4/7/2026 09:35, Arne Vajh|+j wrote:

On 4/7/2026 8:17 AM, Simon Clubley wrote:

On 2026-04-02, Arne Vajh|+j <arne@vajhoej.dk> wrote:

And similar with EDT - it worked back then and
if nobody has changed the code since maybe the mid 80's,
then it should still work.

Didn't someone at VSI change EDT to support terminal heights greater than >>>> 24 lines for >= VT100 ?

Possible. That would have been when DECTerm was introduced
I assume.

The change to which Simon refers was made in 2017 for the
never-released V8.5 version.

Those changes propagated into the V9 stream, so X86 users
have those changes.

Oh. That was late.

Why do I get the feeling that VSI has at least one
engineer that:
- prefer EDT over EVE
- has large monitor
- knows Macro-32
?

Mike Moroney was the engineer who did the work; I don't know his
favourite editor.

EDT, TPU, and LSE are written in BLISS.

I use EDT daily.
--

--- Rob
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2026-04-07, hb0815 <mw40171@mucweb.de> wrote:

I don't know how the change made it to "OpenVMS V8.4-2L2 on node
EISNER". It has it; give it a try.

EDT (and EVE aka EDIT/TPU and LSE) still do not support alternate
screens. A feature almost every current terminal emulator has. And all editors I used on Linux use it. When switching to screen mode, EDT still wipes out the current screen so anything on it is lost.

Alternate screens in general can be a _real_ pain however when you want
to use the information you have just looked up in a following command. Thankfully, there are a range of TERM profiles available which disable
the alternate screen setting.

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 4/8/26 14:13, Simon Clubley wrote:

On 2026-04-07, hb0815 <mw40171@mucweb.de> wrote:

I don't know how the change made it to "OpenVMS V8.4-2L2 on node
EISNER". It has it; give it a try.

EDT (and EVE aka EDIT/TPU and LSE) still do not support alternate
screens. A feature almost every current terminal emulator has. And all
editors I used on Linux use it. When switching to screen mode, EDT still
wipes out the current screen so anything on it is lost.

Alternate screens in general can be a _real_ pain however when you want
to use the information you have just looked up in a following command. Thankfully, there are a range of TERM profiles available which disable
the alternate screen setting.

Simon.

For me, enabling or disabling "Show Alternate Screen" in the pop-up menu
by pressing Ctrl+MiddleMouseButton works. I can easily use cut and paste
to enter what I've seen in the editor on the command line.
--- Synchronet 3.21f-Linux NewsLink 1.2