Asking here because the mechanics of asking VSI are not in place yet.

We're doing testing for updating a customer system from an HP VMS V8.4 on RX3600 box to VSI V8.4-2L1 on an RX2800; same setup we were asking about disk partitioning before. Starting with restoring clean image backups of the production box, we installed the upgrade, along with updating DECnet Phase IV, TCPIP, and the other relevant item on the installation media. DECnet was working with the HP VMS version.

Since then we can't get DECnet to work. TCPIP seems to be ok but the DECnet circuit remains on-synchronizing. We have wiped the DECnet config and rebuilt it, same results. It sees all four NICs on the RX2800, and we have tried making each one in sequence the active connection, with the same results. We have confirmed nothing broke on the network by restoring the HP VMS version to another disk; works fine, and using a fresh install of VSI VMS on another disk; both have working DECnet..

This is our first VSI update (as opposed to install). I have a vague recollection of some kind of DECnet problem in early VSI days but have not found the reference yet. Anyone have info or a link?

Due to unavailability of some of the older software we really would prefer to stick with an upgrade over a fresh install and then try to get all their third party products working. DECnet is strongly desired for the test and eventual move from the 3600 to the 2800; after that it won't matter.

thanks

On 10/29/2021 1:17 PM, Rich Jordan wrote:
> Asking here because the mechanics of asking VSI are not in place yet.
>
> We're doing testing for updating a customer system from an HP VMS V8.4 on RX3600 box to VSI V8.4-2L1 on an RX2800; same setup we were asking about disk partitioning before. Starting with restoring clean image backups of the production box, we installed the upgrade, along with updating DECnet Phase IV, TCPIP, and the other relevant item on the installation media. DECnet was working with the HP VMS version.
>
> Since then we can't get DECnet to work. TCPIP seems to be ok but the DECnet circuit remains on-synchronizing. We have wiped the DECnet config and rebuilt it, same results. It sees all four NICs on the RX2800, and we have tried making each one in sequence the active connection, with the same results. We have confirmed nothing broke on the network by restoring the HP VMS version to another disk; works fine, and using a fresh install of VSI VMS on another disk; both have working DECnet..
>
> This is our first VSI update (as opposed to install). I have a vague recollection of some kind of DECnet problem in early VSI days but have not found the reference yet. Anyone have info or a link?
>
> Due to unavailability of some of the older software we really would prefer to stick with an upgrade over a fresh install and then try to get all their third party products working. DECnet is strongly desired for the test and eventual move from the 3600 to the 2800; after that it won't matter.
>
> thanks
>

Recently I installed VSI VMS V8.4 2L3 on an RX2660 system.

DECnet is not working.

Using the iLO as the console, I get the following:

Message from user DECNET on ITANIC
DECnet event 4.7, circuit down, circuit fault
From node 1.37 (ITANIC), 29-OCT-2021 13:52:32.73
Circuit EWA-1, Line synchronization lost

Ok, from a TelNet session (sorry Steve, I like TelNet for local sessions)
I decided to run STARTNET.COM, and DECnet came up and for the first time
worked on this system.

Then I decided to reboot and see what happens. As soon as I got the iLO
into console mode, before logging in, DECnet died.

I haven't yet contacted VSI about the DECnet problem because I was a
bit busy doing stuff that didn't really need DECnet, though is
would have been nice to have it for VMS to VMS work. But now it
has me interested. Why would getting the iLO into console mode
cause a DECnet problem. if that is actually what happened?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

Rich,

so you're saying: DECnet IV works after a fresh install of VSI VMS V8.4-2L1, but doesn't after an upgrade from HP VMS V8.4 ?

Any DECnet OPCOM messages ?
$ MC NCP SHOW KNO LINE COUNT
$ MC NCP SHOW KNO CIRC COUNT
DECnet license active ?
TCPIP started AFTER DECnet ?

Volker.

On 10/29/2021 1:56 PM, Dave Froble wrote:
> On 10/29/2021 1:17 PM, Rich Jordan wrote:
>> Asking here because the mechanics of asking VSI are not in place yet.
>>
>> We're doing testing for updating a customer system from an HP VMS V8.4 on RX3600 box to VSI V8.4-2L1 on an RX2800; same setup we were asking about disk partitioning before. Starting with restoring clean image backups of the production box, we installed the upgrade, along with updating DECnet Phase IV, TCPIP, and the other relevant item on the installation media. DECnet was working with the HP VMS version.
>>
>> Since then we can't get DECnet to work. TCPIP seems to be ok but the DECnet circuit remains on-synchronizing. We have wiped the DECnet config and rebuilt it, same results. It sees all four NICs on the RX2800, and we have tried making each one in sequence the active connection, with the same results. We have confirmed nothing broke on the network by restoring the HP VMS version to another disk; works fine, and using a fresh install of VSI VMS on another disk; both have working DECnet..
>>
>> This is our first VSI update (as opposed to install). I have a vague recollection of some kind of DECnet problem in early VSI days but have not found the reference yet. Anyone have info or a link?
>>
>> Due to unavailability of some of the older software we really would prefer to stick with an upgrade over a fresh install and then try to get all their third party products working. DECnet is strongly desired for the test and eventual move from the 3600 to the 2800; after that it won't matter.
>>
>> thanks
>>
>
> Recently I installed VSI VMS V8.4 2L3 on an RX2660 system.
>
> DECnet is not working.
>
> Using the iLO as the console, I get the following:
>
> Message from user DECNET on ITANIC
> DECnet event 4.7, circuit down, circuit fault
> From node 1.37 (ITANIC), 29-OCT-2021 13:52:32.73
> Circuit EWA-1, Line synchronization lost
>
>
> Ok, from a TelNet session (sorry Steve, I like TelNet for local sessions)
> I decided to run STARTNET.COM, and DECnet came up and for the first time
> worked on this system.
>
> Then I decided to reboot and see what happens. As soon as I got the iLO
> into console mode, before logging in, DECnet died.
>
> I haven't yet contacted VSI about the DECnet problem because I was a
> bit busy doing stuff that didn't really need DECnet, though is
> would have been nice to have it for VMS to VMS work. But now it
> has me interested. Why would getting the iLO into console mode
> cause a DECnet problem. if that is actually what happened?
>

Ok, support call logged with VSI. DECnet person not available until Monday.
I'll post what is discovered.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On Friday, October 29, 2021 at 1:02:18 PM UTC-5, Volker Halle wrote:
> Rich,
>
> so you're saying: DECnet IV works after a fresh install of VSI VMS V8.4-2L1, but doesn't after an upgrade from HP VMS V8.4 ?
>
> Any DECnet OPCOM messages ?
> $ MC NCP SHOW KNO LINE COUNT
> $ MC NCP SHOW KNO CIRC COUNT
> DECnet license active ?
> TCPIP started AFTER DECnet ?
>
> Volker.

Volker
License is active as part of VMS FOE pak; DECnet is in end-node state.
TCPIP was not started during this boot; it was manually started in one previous to test, and it is after DECnet startup in the startup procedures.
I DO need to test it again to make sure I'm not reporting a false positive about its status but I'm swamped, later today or next week to confirm that.

The line count is all clear except

Line = EIA-0
....
4103 Send failure, including:
Carrier check failed

The circuit count is clear except

Circuit = EIA-0
31 Circuit Down

Note that I had the circuit turned off to stop all the operator messages, and it restarted the count when I re-enabled it to post this. Its up to 55 now.

I tried a different switch and cable also, no difference, and again both old and new switch worked fine when booted from old HP VMS or the fresh install of VSI VMS.

I'll follow up with a TCPIP startup and test as soon as I can; everyone decided to have their peecees do diaper dumps today.

I am not currently connected to the iLO but the iLO _is_ connected to the same switch as the server data link (only one server NIC has been connected at a time).

On Friday, October 29, 2021 at 7:59:37 PM UTC+1, Rich Jordan wrote:
> On Friday, October 29, 2021 at 1:02:18 PM UTC-5, Volker Halle wrote:
> > Rich,
> >
> > so you're saying: DECnet IV works after a fresh install of VSI VMS V8.4-2L1, but doesn't after an upgrade from HP VMS V8.4 ?
> >
> > Any DECnet OPCOM messages ?
> > $ MC NCP SHOW KNO LINE COUNT
> > $ MC NCP SHOW KNO CIRC COUNT
> > DECnet license active ?
> > TCPIP started AFTER DECnet ?
> >
> > Volker.
> Volker
> License is active as part of VMS FOE pak; DECnet is in end-node state.
> TCPIP was not started during this boot; it was manually started in one previous to test, and it is after DECnet startup in the startup procedures.
> I DO need to test it again to make sure I'm not reporting a false positive about its status but I'm swamped, later today or next week to confirm that.
>
> The line count is all clear except
>
> Line = EIA-0
> ...
> 4103 Send failure, including:
> Carrier check failed
>
>
> The circuit count is clear except
>
> Circuit = EIA-0
> 31 Circuit Down
>
> Note that I had the circuit turned off to stop all the operator messages, and it restarted the count when I re-enabled it to post this. Its up to 55 now.
>
> I tried a different switch and cable also, no difference, and again both old and new switch worked fine when booted from old HP VMS or the fresh install of VSI VMS.
>
>
> I'll follow up with a TCPIP startup and test as soon as I can; everyone decided to have their peecees do diaper dumps today.
>
> I am not currently connected to the iLO but the iLO _is_ connected to the same switch as the server data link (only one server NIC has been connected at a time).

I've recently upgraded to VSI V8.4-2L3 on an RX4640 from L2 without any DECnet IV issues over ethernet circuits, except for issues with LAT. I solved that problem
by using separate interfaces for DECnet, TCP-IP and LAT.

Keith

On 10/29/2021 5:53 PM, cao...@pitbulluk.org wrote:

> I've recently upgraded to VSI V8.4-2L3 on an RX4640 from L2

2L2 was Alpha only as far as I know. Was it perhaps 2L1 to 2L3?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

In article <slhclr$eck$1@dont-email.me>, Dave Froble
<davef@tsoft-inc.com> writes:

> Ok, from a TelNet session (sorry Steve, I like TelNet for local sessions)

Why not LAT?

Rich,
> Line = EIA-0
> ...
> 4103 Send failure, including:
> Carrier check failed

This does explain the 'on-synchronizing' state of the DECnet circuit. But WHY can't the interface send any packets ?

Let me repeat my question: a new installation of VSI OpenVMS V8.4-2L1 does work ? Please confirm.

Is SYS$EIDRIVER the SAME version/link date in both cases ?

Does LANCP> SHOW DEV/COUNT/INTERNAL EIA0 provide any additional information ? Please consider to compare the output of this command for the working and failing case.

How about SDA> SHOW LAN/DEV=EIA
and
SDA> LAN TRACE/DEVICE=EIA

I wouldn't expect TCPIP to work over this LAN interface, if the driver can't send any packets at all !

Volker.

On 10/30/2021 2:27 AM, Phillip Helbig (undress to reply) wrote:
> In article <slhclr$eck$1@dont-email.me>, Dave Froble
> <davef@tsoft-inc.com> writes:
>
>> Ok, from a TelNet session (sorry Steve, I like TelNet for local sessions)
>
> Why not LAT?
>

The terminal emulator I use, SmarTerm, does not have LAT as a standard option.

Actually, I'd like to get the company all using something a bit more secure.
I'm going to look at SSH.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 10/30/21 11:38 AM, Dave Froble wrote:
> On 10/30/2021 2:27 AM, Phillip Helbig (undress to reply) wrote:
>> In article <slhclr$eck$1@dont-email.me>, Dave Froble
>> <davef@tsoft-inc.com> writes:
>>
>>> Ok, from a TelNet session (sorry Steve, I like TelNet for local
>>> sessions)
>>
>> Why not LAT?
>>
>
> The terminal emulator I use, SmarTerm, does not have LAT as a standard
> option.
>
> Actually, I'd like to get the company all using something a bit more
> secure.
> I'm going to look at SSH.

When you do, you may need to have a look at the part of SYLOGIN.COM that
has the SET TERM/INQUIRE command. In the boilerplate version that comes
with VMS, a rather long list of device types are excluded from running
that command, including "FT" which is what is used by interactive SSH
connections, so by default, VMS won't know what kind of terminal you
have and lots of stuff doesn't work with terminal type "Unknown." If
you delete FT from the list, your interactive sessions will start
getting the correct terminal type, but other things that tunnel over SSH
may break.

In my case Kermit from a Linux system tunneled over SSH stopped working.
I had to exclude the account that was doing that from the check, which
is a pretty desperate hack. If there's a better way to identify
sessions that are using FTDRIVER and have a TT device with a device
class of 66 but are not actual interactive terminal sessions using SSH,
I'd be happy to hear what it is.

On 10/30/2021 7:00 PM, Craig A. Berry wrote:
> On 10/30/21 11:38 AM, Dave Froble wrote:
>> On 10/30/2021 2:27 AM, Phillip Helbig (undress to reply) wrote:
>>> In article <slhclr$eck$1@dont-email.me>, Dave Froble
>>> <davef@tsoft-inc.com> writes:
>>>
>>>> Ok, from a TelNet session (sorry Steve, I like TelNet for local sessions)
>>>
>>> Why not LAT?
>>>
>>
>> The terminal emulator I use, SmarTerm, does not have LAT as a standard option.
>>
>> Actually, I'd like to get the company all using something a bit more secure.
>> I'm going to look at SSH.
>
> When you do, you may need to have a look at the part of SYLOGIN.COM that
> has the SET TERM/INQUIRE command. In the boilerplate version that comes
> with VMS, a rather long list of device types are excluded from running
> that command, including "FT" which is what is used by interactive SSH
> connections, so by default, VMS won't know what kind of terminal you
> have and lots of stuff doesn't work with terminal type "Unknown." If
> you delete FT from the list, your interactive sessions will start
> getting the correct terminal type, but other things that tunnel over SSH
> may break.
>
> In my case Kermit from a Linux system tunneled over SSH stopped working.
> I had to exclude the account that was doing that from the check, which
> is a pretty desperate hack. If there's a better way to identify
> sessions that are using FTDRIVER and have a TT device with a device
> class of 66 but are not actual interactive terminal sessions using SSH,
> I'd be happy to hear what it is.
>

Thanks, may keep me from some cussing ...

If SYLOGIN is an issue, placing commands in select LOGIN.COM files could be one solution.
Not one I like. But nobody ever promised me a rose garden ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2021-10-30 23:00:00 +0000, Craig A. Berry said:

> When you do, you may need to have a look at the part of SYLOGIN.COM
> that has the SET TERM/INQUIRE command. In the boilerplate version that
> comes with VMS, a rather long list of device types are excluded from
> running that command, including "FT" which is what is used by
> interactive SSH connections, so by default, VMS won't know what kind of
> terminal you have and lots of stuff doesn't work with terminal type
> "Unknown." If you delete FT from the list, your interactive sessions
> will start getting the correct terminal type, but other things that
> tunnel over SSH may break.

I'm guilty of most of that ginormous DCL abomination, as an earlier
wide-open SET TERMINAL /INQUIRE was blowing up too much, and the
terminal settings changes (particularly around performing that command
on the console, and around clearing screens, IIRC) were derailing the
regression tests. That DCL abomination because SET TERMINAL /INQUIRE
wasn't all that much past a box of rocks at its own intended job. That
all due to upward compatibility. And FT is (also) used for foreign
terminals, which'll blow up other stuff that uses FT.

Pragmatically, ssh should have used its own terminal type, but that's
probably not going to change now.

There are other issues lurking here, such as with the (lack of)
TT_ACCPORNAM handling allowing identifying the source of arriving IP
terminal connections.

It'd be interesting to see if ssh could be adapted to permit VT virtual
terminal support, too.

Dredging up an old and semi-related discussion around DECterm and its
use of FT, David Jones wrote "For FT devices, the field holding
internal PID of the job whose bytlm was charged for the UCB
(UCB$L_CPID) overlays UCB$L_LOCKID, so you can retrieve it using
sys$getdvi with the LOCKID item code. You can convert the internal PID
to an external PID and then sleuth the process that created the
pseudo-terminal (e.g. DECW$TE_xxxx would be a decterm)."

It took a while to get OpenVMS detect the size of the original terminal
window in an OpenVMS session, but at least that's been working for a
while.

SET TERMINAL really shouldn't spew errors either, but the non-ANSI and
busted-emulation terminals will. Old Tektronix certainly did. (4014 was
pre-ANSI and did. 4125 had ANSI and didn't.) It's probably past time to
rework all of this OpenVMS code though, and to adopt that ssh and
telnet (ugh) and OPA0: serial or iLO are our connection paths, and just
let truly fossil-grade terminals spew their errors, but... well...
compatibility.

--
Pure Personal Opinion | HoffmanLabs LLC

On Sunday, October 31, 2021 at 12:00:05 PM UTC+13, Craig A. Berry wrote:
> In my case Kermit from a Linux system tunneled over SSH stopped working.

What sort of errors was it reporting?

> I had to exclude the account that was doing that from the check, which
> is a pretty desperate hack. If there's a better way to identify
> sessions that are using FTDRIVER and have a TT device with a device
> class of 66 but are not actual interactive terminal sessions using SSH,
> I'd be happy to hear what it is.

What is the need for FTDRIVER, exactly? Isn’t there some standard pseudo-terminal facility equivalent to pty(7) <https://manpages.debian.org/bullseye/manpages/pty.7.en.html>? On Linux, SSH service is implemented entirely in userland.

On Saturday, October 30, 2021 at 2:06:57 AM UTC-5, Volker Halle wrote:
> Rich,
> > Line = EIA-0
> > ...
> > 4103 Send failure, including:
> > Carrier check failed
> This does explain the 'on-synchronizing' state of the DECnet circuit. But WHY can't the interface send any packets ?
>
> Let me repeat my question: a new installation of VSI OpenVMS V8.4-2L1 does work ? Please confirm.
>
> Is SYS$EIDRIVER the SAME version/link date in both cases ?
>
> Does LANCP> SHOW DEV/COUNT/INTERNAL EIA0 provide any additional information ? Please consider to compare the output of this command for the working and failing case.
>
> How about SDA> SHOW LAN/DEV=EIA
> and
> SDA> LAN TRACE/DEVICE=EIA
>
> I wouldn't expect TCPIP to work over this LAN interface, if the driver can't send any packets at all !
>
> Volker.

Volker
sorry been tied up on a new site network install that ate the last few days and will likely consume Sunday as well. I will check and followup Monday, don't have remote access to the RX2800 right now, but I can confirm that yes, DECnet did work on a fresh install of V8.4-2L1 from the ISO, was working with HP V8.4 from an image restore from the customer system, and does not work after upgrading HP to VSI using the same ISO. I should be able to confirm TCPIP function, reconfirming the DECnet function of the fresh install and getting the other requested info before getting sidetracked again.. This project is becoming cursed with endless interruptions for other stuff.

Rich

Rich,

and $ SHOW DEV/FULL EIA0 should easily tell you, whether OpenVMS believes the link is up or not.

Volker.

In article <slkr4j$8cc$1@dont-email.me>, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> writes:
>On 2021-10-30 23:00:00 +0000, Craig A. Berry said:
>
>> When you do, you may need to have a look at the part of SYLOGIN.COM
>> that has the SET TERM/INQUIRE command. In the boilerplate version that
>> comes with VMS, a rather long list of device types are excluded from
>> running that command, including "FT" which is what is used by
>> interactive SSH connections, so by default, VMS won't know what kind of
>> terminal you have and lots of stuff doesn't work with terminal type
>> "Unknown." If you delete FT from the list, your interactive sessions
>> will start getting the correct terminal type, but other things that
>> tunnel over SSH may break.
>
>I'm guilty of most of that ginormous DCL abomination, as an earlier
>wide-open SET TERMINAL /INQUIRE was blowing up too much, and the
>terminal settings changes (particularly around performing that command
>on the console, and around clearing screens, IIRC) were derailing the
>regression tests. That DCL abomination because SET TERMINAL /INQUIRE
>wasn't all that much past a box of rocks at its own intended job. That
>all due to upward compatibility. And FT is (also) used for foreign
>terminals, which'll blow up other stuff that uses FT.
>
>Pragmatically, ssh should have used its own terminal type, but that's
>probably not going to change now.
>
>There are other issues lurking here, such as with the (lack of)
>TT_ACCPORNAM handling allowing identifying the source of arriving IP
>terminal connections.

$ sh term
Terminal: _FTA99: Device_Type: VT200_Series Owner: SYSTEM
Remote Port Info: ssh/ool-########.dyn.optonline.net:50130

Input: 9600 LFfill: 0 Width: 132 Parity: None
Output: 9600 CRfill: 0 Page: 24

Terminal Characteristics:
Interactive Echo Type_ahead No Escape
Hostsync TTsync Lowercase Tab
No Wrap Scope No Remote Eightbit
Broadcast No Readsync No Form Fulldup
No Modem No Local_echo No Autobaud No Hangup
No Brdcstmbx No DMA No Altypeahd Set_speed
No Commsync Line Editing Overstrike editing No Fallback
No Dialup Secure server No Disconnect No Pasthru
No Syspassword No SIXEL Graphics No Soft Characters No Printer Port
Numeric Keypad ANSI_CRT No Regis No Block_mode
Advanced_video Edit_mode DEC_CRT DEC_CRT2
No DEC_CRT3 No DEC_CRT4 No DEC_CRT5 No Ansi_Color
VMS Style Input <CTRL-H> Backspace

I developed a product over a decade ago to add the ACCPORNAM info to FTA's
used with ssh. I designed it to be flexible for site needs by providing a
set of "formatters" that can be specified to modify how the remote info is
presented in the ACCPORNAM field.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On 10/30/21 9:26 PM, Lawrence D’Oliveiro wrote:
> On Sunday, October 31, 2021 at 12:00:05 PM UTC+13, Craig A. Berry wrote:
>> In my case Kermit from a Linux system tunneled over SSH stopped working.
>
> What sort of errors was it reporting?

None. It just hung. My best guess is the host was waiting for a reply
to the inquiry that it never got.

>> I had to exclude the account that was doing that from the check, which
>> is a pretty desperate hack. If there's a better way to identify
>> sessions that are using FTDRIVER and have a TT device with a device
>> class of 66 but are not actual interactive terminal sessions using SSH,
>> I'd be happy to hear what it is.
>
> What is the need for FTDRIVER, exactly?

No idea.

> Isn’t there some standardpseudo-terminal facility equivalent to pty(7)

FTDRIVER is a pseudo-terminal driver. There is also something called a
virtual terminal (VTDRIVER?) but I've never used it and couldn't find
much in the way of documentation just now.

As Hoff said else-thread:

"It'd be interesting to see if ssh could be adapted to permit VT virtual
terminal support, too."

On 2021-10-31 12:59:22 +0000, Craig A. Berry said:

> There is also something called a virtual terminal (VTDRIVER?) but I've
> never used it and couldn't find much in the way of documentation just
> now.
>
> As Hoff said else-thread:
>
> "It'd be interesting to see if ssh could be adapted to permit VT
> virtual terminal support, too."

VT Virtual Terminals are TTDRIVER, reconfigured and operating as
disconnectable.

https://vmssoftware.com/docs/VSI_SYS_MGMT_MANUAL_VOL_I.PDF#page=270

Also see the DISCONNECT and CONNECT commands in DCL.

Getting DECterm to deal with this would be substantially more of an
effort, with all of X along for that dark and scary and
really-just-an-RPC-with-an-attached-windowing-system, ride.

Virtual Terminals are handy when connections are spotty, which used to
be modems and now might be mobile or congested or other spotty network
connections.

The closest client-side analog to the OpenVMS virtual terminal support
is arguably the GNU screen and BSD tmux apps, though these must
continue to be connected with the server and don't otherwise preserve
the server-side session.

For server management, this virtual terminal support was a way to
temporarily back out of a connection without losing context,
fix/restart/rewire/reboot whatever happened with the connection or with
client-side, and re-connect and resume the server session. Such as
happens when the modem drops out. Yeah, modems, how quaint. Which is
why virtual terminal support really hasn't seen much widespread use in
recent decades.

Getting ssh and the rest over to its own terminal device name and off
FT and/or BG would make the whole thing a shade easier to manage using
traditional tools, too. Though I do recall somebody around here has
grumbled once or twice about OpenVMS (dis)integration with IP. OpenVMS
development had its head... elsewhere and too-long-preferred DECnet and
OSI and for way too many years, and the fallout from that era continues
to plague us.

Not that I expect any of this to change this decade, as VSI has other
and higher-priority work.

--
Pure Personal Opinion | HoffmanLabs LLC

On Saturday, October 30, 2021 at 10:26:27 PM UTC-4, Lawrence D’Oliveiro wrote:
> What is the need for FTDRIVER, exactly? Isn’t there some standard pseudo-terminal facility equivalent to pty(7) <https://manpages.debian.org/bullseye/manpages/pty.7.en.html>? On Linux, SSH service is implemented entirely in userland.

FTDRIVER is the pseudo-terminal facility included with OpenVMS. I first saw it appear with DECWindows
DECterms (I think VWS did something different, but may be wrong). The nomenclature is different,
pseudoterminal and control program rather than slave and master device-pair, but the concepts are the
same.

My biggest problem with SET TERM/INQUIRE was that it purged the typeahead buffer in order to prevent
it's contents being interpreted as the terminal's response to the identify query. I had the habit of typing
in my first command before the prompt appeared, so the typeahead purge would clip off the beginning
of what I typed. I had to deal with a similar issue with my multi-line editing code for the SQLite shell, but
involving a cursor position report rather than device type query.

On Monday, November 1, 2021 at 8:25:20 AM UTC+13, osuv...@gmail.com wrote:
> My biggest problem with SET TERM/INQUIRE was that it purged the typeahead
> buffer in order to prevent it's contents being interpreted as the terminal's response
> to the identify query.

I think I remember that (mis)behaviour ...

But really, all actual physical dumb terminals are museum pieces now (aren’t they?). All we have left are software-based terminal emulators running on actual computers. And all these emulators emulate some member of the VT100 family. So do we still need SET TERMINAL/INQUIRE? Just assume you’re using a VT100, and be done with it.

On 10/31/2021 5:10 PM, Lawrence D’Oliveiro wrote:
> But really, all actual physical dumb terminals are museum pieces now
> (aren’t they?). All we have left are software-based terminal
> emulators running on actual computers. And all these emulators
> emulate some member of the VT100 family. So do we still need SET
> TERMINAL/INQUIRE? Just assume you’re using a VT100, and be done with
> it.

On VMS we will need at least VT200.

Arne

On Monday, November 1, 2021 at 1:59:27 AM UTC+13, Craig A. Berry wrote:
> On 10/30/21 9:26 PM, Lawrence D’Oliveiro wrote:
>> On Sunday, October 31, 2021 at 12:00:05 PM UTC+13, Craig A. Berry wrote:
>>> In my case Kermit from a Linux system tunneled over SSH stopped working..
>>
>> What sort of errors was it reporting?
>>
> None. It just hung. My best guess is the host was waiting for a reply
> to the inquiry that it never got.

There are ways to debug that, but ... come to think of it, why are you bothering with Kermit when you have SSH? Because SSH includes secure file transfer capabilities via SCP and SFTP, so why not use those?

On Monday, November 1, 2021 at 10:26:25 AM UTC+13, Arne Vajhøj wrote:
>
> On 10/31/2021 5:10 PM, Lawrence D’Oliveiro wrote:
>>
>> Just assume you’re using a VT100, and be done with
>> it.
>
> On VMS we will need at least VT200.

What extra capabilities do you need? All the ones that are worth implementing should already be in the available open-source emulators.

On 10/31/2021 5:28 PM, Lawrence D’Oliveiro wrote:
> On Monday, November 1, 2021 at 10:26:25 AM UTC+13, Arne Vajhøj
> wrote:
>> On 10/31/2021 5:10 PM, Lawrence D’Oliveiro wrote:
>>> Just assume you’re using a VT100, and be done with it.
>>
>> On VMS we will need at least VT200.
>
> What extra capabilities do you need? All the ones that are worth
> implementing should already be in the available open-source
> emulators.

Emulators are fine. But we need VT200 emulation and terminal
type set to VT200 (or higher).

Arne