On Monday, November 1, 2021 at 10:52:35 AM UTC+13, Arne Vajhøj wrote:
> Emulators are fine. But we need VT200 emulation and terminal
> type set to VT200 (or higher).

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 6:22 PM, Lawrence D’Oliveiro wrote:
> On Monday, November 1, 2021 at 10:52:35 AM UTC+13, Arne Vajhøj wrote:
>> Emulators are fine. But we need VT200 emulation and terminal
>> type set to VT200 (or higher).
>
> What extra capabilities do you need? All the ones that are worth
> implementing should already be in the available open-source
> emulators.

There is not a problem with the available emulators.

But we need the terminal type to be VT200 or higher - not VT100.

Arne

On 10/31/21 4:27 PM, Lawrence D’Oliveiro wrote:
> 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

Yeah but, no one making decisions wanted it debugged, I don't have
access to the sending system, and it's all slated for replacement very
soon. Three of four interfaces that use this mechanism have recently
been retired.

, 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?

Numerous reasons. Kermit has a very nice scripting capability and the
scripts that had been working for a decade or three with serial ports
and/or terminal servers worked with few if any changes after swapping
out the underlying connection to use ssh.

Also, scp to VMS systems from non-VMS systems mostly doesn't work --
they use different and incompatible versions of the protocol. The only
real workaround I've found for that is to build PuTTY on the Unix/Linux
system and use its pscp rather than scp. This problem is going away in
TCP/IP Services 6.x and the separate OpenSSH package that gets installed
alongside it, but that's not generally available quite yet, and
certainly wasn't available when we retired the last terminal server
about twelve years ago.

Rich,

a major difference between the upgrade and freshly installed system would be the system parameter file. Try copying SYS$SYSTEM:I64VMSSYS.PAR from the 'good' to the 'bad' system disk or vice versa.

Volker.

On Monday, November 1, 2021 at 8:18:15 AM UTC+13, Stephen Hoffman wrote:

> 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.

I remember that hoary old RSTS/E had pseudo-keyboards accessible from (privileged) userland processes, odd that VMS never did. Dave Cutler didn’t want to sully his brainchild with such an “inefficient” concept?

Also I remember looking into how SET HOST (the DECnet equivalent of Telnet) worked: once the RTPAD program had set up the connection, all subsequent I/O transfers between the terminal driver and the network connection happened directly in kernel mode, with little or no further intervention from userland. No doubt efficient (at least looking at user-mode CPU usage), but needing a custom kernel-mode driver for each terminal-connection protocol limited your flexibility somewhat.

On 10/29/2021 1:56 PM, Dave Froble wrote:

> Recently I installed VSI VMS V8.4 2L3 on an RX2660 system.
>
> DECnet is not working.

I just checked the sources for NETACP.EXE and NETDRIVER.EXE, and there was a single change between V8.4-2L1 and V8.4-2L3.

It was a change that I made that fixed a problem in searching the binary trees in the volatile database
for node entries.

That code is only used for searching the node entries themselves, since node databases can hold up to 63*1024 entries
and needed some form of optimization.

The other volatile databases (line, circuit, object, etc...) hold far fewer entries, and are not implemented as binary
trees.

I'm pretty sure the DECnet Phase IV code is not broken.

--

-- Rob

On 2021-11-01 14:23:41 +0000, Robert A. Brooks said:

> I'm pretty sure the DECnet Phase IV code is not broken.

🎯

--
Pure Personal Opinion | HoffmanLabs LLC

On Monday, November 1, 2021 at 10:23:44 AM UTC-4, Robert A. Brooks wrote:
> On 10/29/2021 1:56 PM, Dave Froble wrote:
>
> > Recently I installed VSI VMS V8.4 2L3 on an RX2660 system.
> >
> > DECnet is not working.
>
> I just checked the sources for NETACP.EXE and NETDRIVER.EXE, and there was a single change between V8.4-2L1 and V8.4-2L3.
>
> It was a change that I made that fixed a problem in searching the binary trees in the volatile database
> for node entries.
>
> That code is only used for searching the node entries themselves, since node databases can hold up to 63*1024 entries
> and needed some form of optimization.
>
> The other volatile databases (line, circuit, object, etc...) hold far fewer entries, and are not implemented as binary
> trees.
>
> I'm pretty sure the DECnet Phase IV code is not broken.
>
> --
>
> -- Rob

I don't believe that DECnet is broken either. A clean installation works as expected. There is something in the upgrade process that breaks existing DECnet systems.
This is what was reported and is of concern.

On 11/1/2021 10:49 AM, Stephen Hoffman wrote:
> On 2021-11-01 14:23:41 +0000, Robert A. Brooks said:
>
>> I'm pretty sure the DECnet Phase IV code is not broken.
>
> 🎯

Noted.

--

-- Rob

On Sunday, October 31, 2021 at 6:50:21 AM UTC-5, Volker Halle wrote:
> Rich,
>
> and $ SHOW DEV/FULL EIA0 should easily tell you, whether OpenVMS believes the link is up or not.
>
> Volker.

Testing this AM
I booted the fresh VSI install and started DECnet.
Decnet IV works. I can set host and copy files to the test Alphaserver on the network.
SYS$EIDRIVER reports Ident X-5, Link date 27-JUL-2016 10:30:17.55, Build Ident XE3A-H4N-000000

TCPIP also worked.

Then booted the upgraded system disk (HP V8.4 to VSI)

SYS$EIDRIVER is the same image version and link date (from 2016) on both system disks.

The LANCP internal counters show the same thing referred above; the upgrade system has a rising carrier check failure count, and zero packets received/sent, the VSI installed system shows normal data counters and no errors.

I did not boot the original (restored, pre-upgrade) HP V8.4 disk but it did work fine a couple of weeks ago, the first time since we used DECnet to make network backups over to the test alpha (safety copies) prior to upgrading; this after modifying the system to handle the different device names on the new server. I'll try overlaying the parameter file later if time and interrupts allow. Ditto for SDA output; I dumped the upgraded system's SHOW LAN/DEV to a file to review but my internals and crash dump analysis days ended 15+ years ago; we'll see what we can make out. The TRACE output mostly shows a series of Check Link entries with occasional Transmit Errors.

And sorry. I must have misremembered with all the testing and reboots. TCPIP does NOT work on the system that was upgraded from HP V8.4 to VSI V8.4-2L1. It has barely been used since DECnet is so much easier moving files back and forth from the test Alpha that has connections to the main network. The new RX2800 is on an isolated network with no direct outside access.

I threw the question out here after getting yanked off this work too many times and misquoted my notes. So both DECnet and TCPIP are down after the upgrade. Tried testing with LAT also after enabling outbound connections on both machines, and they can't see each-other.

So its not a DECnet specific issue.

Rich

On 11/1/2021 10:23 AM, Robert A. Brooks wrote:
> On 10/29/2021 1:56 PM, Dave Froble wrote:
>
>> Recently I installed VSI VMS V8.4 2L3 on an RX2660 system.
>>
>> DECnet is not working.
>
> I just checked the sources for NETACP.EXE and NETDRIVER.EXE, and there was a single change between V8.4-2L1 and V8.4-2L3.
>
> It was a change that I made that fixed a problem in searching the binary trees in the volatile database
> for node entries.
>
> That code is only used for searching the node entries themselves, since node databases can hold up to 63*1024 entries
> and needed some form of optimization.
>
> The other volatile databases (line, circuit, object, etc...) hold far fewer entries, and are not implemented as binary
> trees.
>
> I'm pretty sure the DECnet Phase IV code is not broken.
>

Well, I figured the most likely culprit would be, well, me.
But I had no idea what I had done wrong. As before, I had
run NETCONFIG, then used STARTNET to start DECnet.

I'll add that I've had little to no experience with multiple ethernet
ports.

And it could be a HW issue.

And it is the first itanic on which I've installed VMS.

Anyway, one of the fine support people wrote:

===============
It looks like DECnet is configured on both EWA-0 and EWA-1. It is also a nonrouting node so DECnet can only function on one interface, not two or more. Could you reply back with the output from $ MCR LANCP SHOW CONFIG/USER so we can see what interfaces are active and what other protocols you have running?

Once we know that, we can remove one of the interfaces from the NCP database so only the correct one is active on the system.

To remove the incorrect linen and circuit from NCP, you would use the following commands:

$ MCR NCL PURGE CIRCUIT name ALL
$ MCR NCL PURGE LINE name ALLL

Also, the correct way to stop and restart DECnet on your system without rebooting is to use the following commands:

$ MCR NCL SET KNOWN CIRCUIT STATE OFF
$ MCR NCL SET KNOWN LINE STATE OFF
$ MCR NCL SET EXEC STATE OFF

$ @SYS$MANAGER:STARTNET

Best regards,
Walt
=================

So other than the suggestion to use NCL instead of NCP for DECnet IV,
I at least figured that out, and this seemed to get things working.
DECnet is still working without the line sync issue.

I hate not understanding. I still don't know what I did wrong, to get
both ethernet interfaces involved.

As Robert mentioned, no problems in the DECnet code, just a Dave problem.

--
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 11/1/2021 10:59 AM, abrsvc wrote:
> On Monday, November 1, 2021 at 10:23:44 AM UTC-4, Robert A. Brooks wrote:
>> On 10/29/2021 1:56 PM, Dave Froble wrote:
>>
>>> Recently I installed VSI VMS V8.4 2L3 on an RX2660 system.
>>>
>>> DECnet is not working.
>>
>> I just checked the sources for NETACP.EXE and NETDRIVER.EXE, and there was a single change between V8.4-2L1 and V8.4-2L3.
>>
>> It was a change that I made that fixed a problem in searching the binary trees in the volatile database
>> for node entries.
>>
>> That code is only used for searching the node entries themselves, since node databases can hold up to 63*1024 entries
>> and needed some form of optimization.
>>
>> The other volatile databases (line, circuit, object, etc...) hold far fewer entries, and are not implemented as binary
>> trees.
>>
>> I'm pretty sure the DECnet Phase IV code is not broken.
>>
>> --
>>
>> -- Rob
>
> I don't believe that DECnet is broken either. A clean installation works as expected. There is something in the upgrade process that breaks existing DECnet systems.
> This is what was reported and is of concern.
>

Dan, that is what Rich reported, not what I reported. Mine was a ??clean??
install of 2L3. My problem has been solved, I think.

--
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,

thanks for testing and sharing your notes. So it really looks like an upgrade vs. install issue. And it affects the LAN interface, irrelevant of the protocol used.

Is the 'link LED' lit on the physical LAN interface ?

SHOW DEV/FULL EIA0 shows 'no link' - right ?

Please test with the system parameter file from the freshly installed system disk.

Volker.

On 2021-10-30, Lawrence D?Oliveiro <lawrencedo99@gmail.com> wrote:
> On Sunday, October 31, 2021 at 12:00:05 PM UTC+13, Craig A. Berry wrote:
>> 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.

As already mentioned, it implements pseudoterminal support on VMS.

However, if you look at the man page you quote, you will see that the
actual pty devices are also created by a kernel mode device driver on
Linux, just as is done with FTDRIVER on VMS.

You will also see that there are even kernel parameters to control the
maximum number of pseudoterminals that exist at any one time on Linux.

Simon.

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

On Monday, November 1, 2021 at 1:40:00 PM UTC-5, Volker Halle wrote:
> Rich,
>
> thanks for testing and sharing your notes. So it really looks like an upgrade vs. install issue. And it affects the LAN interface, irrelevant of the protocol used.
>
> Is the 'link LED' lit on the physical LAN interface ?
>
> SHOW DEV/FULL EIA0 shows 'no link' - right ?
>
> Please test with the system parameter file from the freshly installed system disk.
>
> Volker.

Volker
the sho dev command does show link down. The link light is lit on the port and the switch with the activity light winking once every 12-14 seconds.

I will try the parameter file overwrite tomorrow if at all possible. Got another priority interrupt to work on now.

Rich

On Tuesday, November 2, 2021 at 7:43:51 AM UTC+13, Simon Clubley wrote:
> However, if you look at the man page you quote, you will see that the
> actual pty devices are also created by a kernel mode device driver on
> Linux ...

Of which there is only one, which is available to userland processes, and which is suitable for all cases where virtual terminals are needed. Implementing an SSH server? Use that. Implementing a GUI terminal emulator? Use that. Implementing a remote terminal server for some other network/comms protocol? Use that. Implementing a screen scraper to get info out of some legacy proprietary app? Use that.

Is FTDRIVER the same? If yes, then I take everything back, except to wonder why it doesn’t work better. :)

On 11/1/2021 6:45 PM, Lawrence D’Oliveiro wrote:
> On Tuesday, November 2, 2021 at 7:43:51 AM UTC+13, Simon Clubley
> wrote:
>> However, if you look at the man page you quote, you will see that
>> the actual pty devices are also created by a kernel mode device
>> driver on Linux ...
>
> Of which there is only one, which is available to userland processes,
> and which is suitable for all cases where virtual terminals are
> needed. Implementing an SSH server? Use that. Implementing a GUI
> terminal emulator? Use that. Implementing a remote terminal server
> for some other network/comms protocol? Use that. Implementing a
> screen scraper to get info out of some legacy proprietary app? Use
> that.
>
> Is FTDRIVER the same? If yes, then I take everything back, except to
> wonder why it doesn’t work better. :)

FTDRIVER is the pseudo terminal driver. It is not SSH specific for any
particular application.

To quote the docs:

<quote>
Chapter 6. Pseudoterminal Driver
This chapter describes the use of the pseudoterminal driver (FTDRIVER)
and the pseudoterminal
software.
A pseudoterminal is a software device that appears as a real terminal to
an application communicating
with it, but does not require the existence of a physical terminal. A
pseudoterminal consists of two
components: the pseudoterminal device and a control program. The control
program acts like a keyboard;
that is, anything written to the control program appears on the
pseudoterminal device as if the
keystrokes had been typed in at a physical terminal. The control program
also acts like a viewport to
the pseudoterminal device; that is, the control program reads anything
that is written by the system to
the pseudoterminal device.
A pseudoterminal allows an application to be set up on the control side
of the link to communicate
with another application that is on the pseudoterminal side. This
arrangement allows development of
applications that either simulate users or monitor the communication
between a real user (at a physical
terminal) and an application. As with other devices, the work of the
pseudoterminal is performed by a
device driver and is tightly coupled to the operating system.
</quote>

It may still be a bit different in nature from its Linux counterpart due
to the fact that VMS is different from Linux.

Arne

On Tuesday, November 2, 2021 at 12:05:49 PM UTC+13, Arne Vajhøj wrote:
> To quote the docs:

I’ve been having a look at this <https://vmssoftware.com/docs/VSI_IO_REF.pdf>. Seems this is a little bit different from a regular kernel driver: you need to use special PTD$xxx calls to open and close instances. Note this in the description of PTD$CREATE: “This channel is only intended to be used for PTD$XXX operations.” So there is some kind of extra layer on top of the kernel driver, and you are not supposed to access the latter directly.

> It may still be a bit different in nature from its Linux counterpart due
> to the fact that VMS is different from Linux.

Still, VMS has -- or had -- a sufficiently versatile kernel driver architecture that it could have managed this better.

On 11/3/2021 7:55 PM, Lawrence D’Oliveiro wrote:
> On Tuesday, November 2, 2021 at 12:05:49 PM UTC+13, Arne Vajhøj
> wrote:
>> To quote the docs:
>
> I’ve been having a look at this
> <https://vmssoftware.com/docs/VSI_IO_REF.pdf>. Seems this is a little
> bit different from a regular kernel driver: you need to use special
> PTD$xxx calls to open and close instances. Note this in the
> description of PTD$CREATE: “This channel is only intended to be used
> for PTD$XXX operations.” So there is some kind of extra layer on top
> of the kernel driver, and you are not supposed to access the latter
> directly.

Yes.

PTD$ user mode library ---> some VMS kernel code ---> driver code

Arne

On Thursday, November 4, 2021 at 1:19:18 PM UTC+13, Arne Vajhøj wrote:
>
> On 11/3/2021 7:55 PM, Lawrence D’Oliveiro wrote:
>>
>> I’ve been having a look at this
>> <https://vmssoftware.com/docs/VSI_IO_REF.pdf>. Seems this is a little
>> bit different from a regular kernel driver: you need to use special
>> PTD$xxx calls to open and close instances. Note this in the
>> description of PTD$CREATE: “This channel is only intended to be used
>> for PTD$XXX operations.” So there is some kind of extra layer on top
>> of the kernel driver, and you are not supposed to access the latter
>> directly.
>>
> Yes.
>
> PTD$ user mode library ---> some VMS kernel code ---> driver code

And note the implication that bad things could happen if you $DASSGN the channel without calling PTD$DELETE. Or if you tried to $QIO yourself without using PTD$READ/WRITE.

I wonder why it was necessary to do it this way?

On Wednesday, November 3, 2021 at 11:51:05 PM UTC-4, Lawrence D’Oliveiro wrote:
> On Thursday, November 4, 2021 at 1:19:18 PM UTC+13, Arne Vajhøj wrote:
> >> ... So there is some kind of extra layer on top
> >> of the kernel driver, and you are not supposed to access the latter
> >> directly.
> >>
> > Yes.
> >
> > PTD$ user mode library ---> some VMS kernel code ---> driver code
> And note the implication that bad things could happen if you $DASSGN the channel without calling PTD$DELETE. Or if you tried to $QIO yourself without using PTD$READ/WRITE.
>
> I wonder why it was necessary to do it this way?

Most of PTD$ code runs in kernel mode with some at elevated IPL. The PTD$CREATE call
creates a buffer object for the buffer you supply so that the buffer (and its S0 address)
stays locked in memory. PTD$READ/WRITE queue request packets directly to FTDRIVER,
skipping some of the overhead of $QIO processing.

I wonder if DECnet would be able to use a pseudo-terminal for a DDCMP link and have
the control program tunnel the packets over a secure link of some kind. Unlike LDRIVER,
unfortunately, PTD$CREATE doesn't let you specify the unit number of the created
device.

On 11/4/2021 12:54 AM, David Jones wrote:
> On Wednesday, November 3, 2021 at 11:51:05 PM UTC-4, Lawrence D’Oliveiro wrote:
>> On Thursday, November 4, 2021 at 1:19:18 PM UTC+13, Arne Vajhøj wrote:
>>>> ... So there is some kind of extra layer on top
>>>> of the kernel driver, and you are not supposed to access the latter
>>>> directly.
>>>>
>>> Yes.
>>>
>>> PTD$ user mode library ---> some VMS kernel code ---> driver code
>> And note the implication that bad things could happen if you
>> $DASSGN the channel without calling PTD$DELETE. Or if you tried to $QIO yourself
>> without using PTD$READ/WRITE.
>>
>> I wonder why it was necessary to do it this way?
>
> Most of PTD$ code runs in kernel mode with some at elevated IPL.

Very interesting.

So it is not a traditional call stack:

user exe application user mode
P0 space
---------- ----------
VMS shrexe PTD$ API
P0 space some logic
---------- ----------
VMS SYS$ API
S0 space CHMK ----------
more logic kernel mode
----------
EXE$ and other
----------
Driver

But:

user exe application user mode
P0 space
---------- ----------
VMS shrexe PTD$ API
P0 space some logic
SYS$CMKRNL ----------
more logic kernel mode
---------- ----------
VMS EXE$ and other
S0 space ----------
Driver

Sounds like somebody did not like SYS$QIO(W).

:-)

> The PTD$CREATE call
> creates a buffer object for the buffer you supply so that the buffer (and its S0 address)
> stays locked in memory.

There is nothing unusual in the fact that when doing an "open" at some
level then one need to do a "close" at the same level.

> PTD$READ/WRITE queue request packets directly to FTDRIVER,
> skipping some of the overhead of $QIO processing.

Arne

On Thursday, November 4, 2021 at 9:23:38 AM UTC-4, Arne Vajhøj wrote:
> On 11/4/2021 12:54 AM, David Jones wrote:
> > Most of PTD$ code runs in kernel mode with some at elevated IPL.
> Very interesting.
>
> So it is not a traditional call stack:
>

PTD$SERVICES_SHR.EXE is installed as a protected shareable image, the
functions it export will on entry CHMK in order to process the request
in kernel mode via that image's change mode dispatcher. PTD$READW and
PTD$WRITEW invoke CHMK with the code for the corresponding asynch.
function and then call EXE$SYNCH (same way SYS$QIOW works).

> Sounds like somebody did not like SYS$QIO(W).

Considering how slow the VAX was and that terminal I/O was often many
many small transfers, that kind of micro-optimization was probably worth
while.

On Monday, November 1, 2021 at 1:40:00 PM UTC-5, Volker Halle wrote:
> Rich,
>
> thanks for testing and sharing your notes. So it really looks like an upgrade vs. install issue. And it affects the LAN interface, irrelevant of the protocol used.
>
> Is the 'link LED' lit on the physical LAN interface ?
>
> SHOW DEV/FULL EIA0 shows 'no link' - right ?
>
> Please test with the system parameter file from the freshly installed system disk.
>
> Volker.

Replacing the parameter file on the upgraded system with the one from the clean VSI install did not make a difference WRT the network; it did cause some complaints because DECwindows could not start, but everything else did after I updated SCSNODE and SCSSYSTEMID in the copied file to match the upgraded system's name and ID.

I tried a second NIC port for the hell of it, but none of them come up. Counters show the same errors as before.

I'm contacting the customer's VSI rep to find out how we can put in a support request; hopefully that side of things has been taken care of.

Rich

On Thursday, November 4, 2021 at 5:54:21 PM UTC+13, osuv...@gmail.com wrote:
> Most of PTD$ code runs in kernel mode with some at elevated IPL.

So does a device driver. Why do the PTD functions have to be a separate layer from the device driver? Particularly a separate, caller-visible layer that breaks the normal driver QIO abstraction?

> PTD$READ/WRITE queue request packets directly to FTDRIVER,
> skipping some of the overhead of $QIO processing.

Remember, these are terminals we are talking about -- devices geared to the limits of human I/O bandwidth. Any “overheads” associated with I/O processing would be insignificant compared to the time it takes for a human to type input or read output.