I'm trying to find the oldest VAX/VMS version which:
* Supports DECnet Phase IV over ethernet
* Supports the VAX-11/730
* I can get my hands on images of the OS installation and anything (licenses?) needed for DECnet Phase IV
I found a .tap image of the VAX/VMS 3.0 distribution at the Russian mirror site. Version 3.0 interests me because I think it was the one that was released to coincide with the VAX-11/730 release. I was able to install it on a SIMH emulation of the 730. I gather that the normal VAX/VMS 3.0 distribution for the VAX-11/730 would be on an RL02 pack instead of a magtape, and I hope that I might figure out how to reconstruct an RL02 pack distribution from what is on the tape image.
I have not found any scans of the DECnet-VAX Software Installation Guide or the DECnet-VAX System Manager's Guide yet, and I don't know what needs to be done to install and/or configure DECnet in such an old VMS version. I see that stuff related to DECnet is present after installation, such as STARTNET.COM and NCP.EXE, but DECnet-VAX is referred to as an optional component which must be licensed separately. I gather from discussions elsewhere that there may be at least one critical file missing that serves as the "license" for DECnet-VAX?
STARTNET.COM comments instruct that it can be run after creating the permanent database, and trying to run it generates errors like:
$ @sys$manager:startnet.com
%OPCOM, 8-DEC-1982 13:55:13.31, message from user NETACP
DECnet starting
%NCP-I-NMLRSP, listener response - File open error, Permanent database
%RMS-E-FNF, file not found
I don't know how to create the permanent database under VAX/VMS 3.0 yet. I tried running NCP.EXE and issuing a SET EXECUTOR command. It asks for a node address in the range of 1..255, so does that imply that whatever (incomplete?) DECnet code is present there is for Phase III?
I'm experimenting with SIMH VAX-11/730 simulations for now. Eventually, I'd like to downgrade the OpenVMS v7.3 installation that came on my real VAX-11/730's R80 drive to something less bloated and more contemporary with my system, but still able to connect to HECNET over ethernet.
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
https://www.nf6x.net/
Sorry, misread the header so my assumptions were wrong
Question remains, how did you get Decnet 3.0 running and did you obtain the necessary patch.
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of R. Voorhorst
Sent: Thursday, 16 December, 2021 10:35
To: hecnet at Update.UU.SE
Subject: RE: DECnet-VAX V3.0, VMS V3.5 (Was Re: [HECnet] Oldest VAX/VMS for VAX-11/730 on HECNET) --> what is this?
Supratim,
The log is somewhat strange: Decnet 3.0 is phase III, but your executor listings gives management version 4.0.0 and routing version 2.0.0 and type nonrouting IV.
Besides, Decnet 3.0 is phase-III and will not support Ethernet, ever (yet you have Una-0 line/circuit), so there is somewhat wrong in your total decnet configuration or you are trying out something unmentioned yet.
My executor for Decnet 3.0 gives the following:
Node Volatile Characteristics as of 16-DEC-2021 10:15:29
Executor node = 84 (SWBV84)
Identification = SWBV84 DNET-3.0 R-III (63).84
Management version = V3.0.0
Incoming timer = 45
Outgoing timer = 45
NSP version = V3.2.0
Maximum links = 32
Delay factor = 64
Delay weight = 2
Inactivity timer = 60
Retransmit factor = 10
Routing version = V1.3.0
Type = routing
Routing timer = 600
Maximum address = 255
Maximum circuits = 32
Maximum cost = 40
Maximum hops = 9
Maximum visits = 10
Maximum buffers = 128
Buffer size = 576
Default access = incoming and outgoing
But it will not work because we only have a licemse for another version.
In the id I placed area 63 as memento as it will communicate with phase-IV routers up to address 255 in that area and these nodes will assume node 84 to be present in that area.
I am curious how you got an operating license to make this work or is that what creates the flaws?
Reindert
From: owner-hecnet at Update.UU.SE <mailto:owner-hecnet at Update.UU.SE> [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Supratim Sanyal
Sent: Thursday, 16 December, 2021 01:01
To: hecnet at Update.UU.SE <mailto:hecnet at Update.UU.SE>
Subject: DECnet-VAX V3.0, VMS V3.5 (Was Re: [HECnet] Oldest VAX/VMS for VAX-11/730 on HECNET)
OK, so I fired up a VAX/VMS 3.5 node and gave it the address 42 (just a coincidence, not an answer to any question). I demoted it to an end-node on a dedicated virtual ethernet adapter for the circuit with DECnet/Python. No adjacency is established. A tshark indicates DECnet-VAX V3.0 is appearing as 1.42 on the wire. Since there is no way to ask DECnet-VAX V3.0 to pretend it is 31.42, I am not sure what the next step, if any, might be to hook this up to my area on HECnet.
tshark dump is at https://www.dropbox.com/s/40hvr4x6iq3esl8/tshark-31.12-31.42-DECnet-VAX-V3.… . Maybe Paul has some advice?
Note: When DECnet-VAX V3.0 was configured as a L1 router, it oscillated between "circuit up" and "line fault" every few seconds.
$ mc ncp show exec char
Node Volatile Characteristics as of 14-DEC-1984 23:46:34
Executor node = 42 (XXXV)
Identification = DECnet-VAX V3.0, VMS V3.5
Management version = V4.0.0
Incoming timer = 45
Outgoing timer = 45
NSP version = V3.2.0
Maximum links = 32
Delay factor = 80
Delay weight = 5
Inactivity timer = 60
Retransmit factor = 10
Routing version = V2.0.0
Type = nonrouting IV
Routing timer = 600
Broadcast routing timer = 40
Maximum address = 1023
Maximum circuits = 16
Maximum cost = 1022
Maximum hops = 30
Maximum visits = 63
Max broadcast nonrouters = 64
Max broadcast routers = 32
Maximum buffers = 100
Buffer size = 576
Nonprivileged user id = DECNET
Default access = incoming and outgoing
Pipeline quota = 1200
$ mc ncp show circuit una-0 char
Circuit Volatile Characteristics as of 14-DEC-1984 23:47:01
Circuit = UNA-0
State = on
Service = disabled
Cost = 3
Router priority = 64
Hello timer = 15
Type = Ethernet
$ mc ncp show line una-0 char
Line Volatile Characteristics as of 14-DEC-1984 23:47:20
Line = UNA-0
Receive buffers = 4
Controller = normal
Protocol = Ethernet
Service timer = 4000
Hardware address = AA-00-04-00-2A-7C
Buffer size = 1498
Regards,
Supratim
On 12/9/21 7:40 PM, Paul Koning wrote:
On Dec 9, 2021, at 6:02 PM, Johnny Billquist <mailto:bqt at softjar.se> <bqt at softjar.se> wrote:
On 2021-12-09 23:52, Mark J. Blair wrote:
So, basically like bang paths in uucp? Maybe I will play with that sometime!
Yes. But depending on application, it might be that all machines have to be up and running at the moment you're trying to use it, as opposed to UUCP which was store and forward.
Right. Roughly speaking, the sending application sees that there are multiple nodes, and that it uses PMR for this. It connects to the first of the nodes, object 63. It then sends it the rest of the connect information. PMR picks off the next node. If that's the last node, it connects to the requested object, otherwise again to another PMR.
VMS has PMR-like capability for network file access because RMS recognizes file names with node name prefixes, so it's an automatic consequence of that feature. RSTS NFT (the application which does network file access) doesn't support PMR as far as I remember. So if you have VMS nodes around you can chain node names in file access, with RSTS-only you cannot.
MAIL does it internally I think. Some vague memory says that RSTS network terminal ("set host") has PMR support, I need to look.
I'll definitely add PMR to PyDECnet at some point fairly soon.
paul
--
Supratim,
The log is somewhat strange: Decnet 3.0 is phase III, but your executor listings gives management version 4.0.0 and routing version 2.0.0 and type nonrouting IV.
Besides, Decnet 3.0 is phase-III and will not support Ethernet, ever (yet you have Una-0 line/circuit), so there is somewhat wrong in your total decnet configuration or you are trying out something unmentioned yet.
My executor for Decnet 3.0 gives the following:
Node Volatile Characteristics as of 16-DEC-2021 10:15:29
Executor node = 84 (SWBV84)
Identification = SWBV84 DNET-3.0 R-III (63).84
Management version = V3.0.0
Incoming timer = 45
Outgoing timer = 45
NSP version = V3.2.0
Maximum links = 32
Delay factor = 64
Delay weight = 2
Inactivity timer = 60
Retransmit factor = 10
Routing version = V1.3.0
Type = routing
Routing timer = 600
Maximum address = 255
Maximum circuits = 32
Maximum cost = 40
Maximum hops = 9
Maximum visits = 10
Maximum buffers = 128
Buffer size = 576
Default access = incoming and outgoing
But it will not work because we only have a licemse for another version.
In the id I placed area 63 as memento as it will communicate with phase-IV routers up to address 255 in that area and these nodes will assume node 84 to be present in that area.
I am curious how you got an operating license to make this work or is that what creates the flaws?
Reindert
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Supratim Sanyal
Sent: Thursday, 16 December, 2021 01:01
To: hecnet at Update.UU.SE
Subject: DECnet-VAX V3.0, VMS V3.5 (Was Re: [HECnet] Oldest VAX/VMS for VAX-11/730 on HECNET)
OK, so I fired up a VAX/VMS 3.5 node and gave it the address 42 (just a coincidence, not an answer to any question). I demoted it to an end-node on a dedicated virtual ethernet adapter for the circuit with DECnet/Python. No adjacency is established. A tshark indicates DECnet-VAX V3.0 is appearing as 1.42 on the wire. Since there is no way to ask DECnet-VAX V3.0 to pretend it is 31.42, I am not sure what the next step, if any, might be to hook this up to my area on HECnet.
tshark dump is at https://www.dropbox.com/s/40hvr4x6iq3esl8/tshark-31.12-31.42-DECnet-VAX-V3.… . Maybe Paul has some advice?
Note: When DECnet-VAX V3.0 was configured as a L1 router, it oscillated between "circuit up" and "line fault" every few seconds.
$ mc ncp show exec char
Node Volatile Characteristics as of 14-DEC-1984 23:46:34
Executor node = 42 (XXXV)
Identification = DECnet-VAX V3.0, VMS V3.5
Management version = V4.0.0
Incoming timer = 45
Outgoing timer = 45
NSP version = V3.2.0
Maximum links = 32
Delay factor = 80
Delay weight = 5
Inactivity timer = 60
Retransmit factor = 10
Routing version = V2.0.0
Type = nonrouting IV
Routing timer = 600
Broadcast routing timer = 40
Maximum address = 1023
Maximum circuits = 16
Maximum cost = 1022
Maximum hops = 30
Maximum visits = 63
Max broadcast nonrouters = 64
Max broadcast routers = 32
Maximum buffers = 100
Buffer size = 576
Nonprivileged user id = DECNET
Default access = incoming and outgoing
Pipeline quota = 1200
$ mc ncp show circuit una-0 char
Circuit Volatile Characteristics as of 14-DEC-1984 23:47:01
Circuit = UNA-0
State = on
Service = disabled
Cost = 3
Router priority = 64
Hello timer = 15
Type = Ethernet
$ mc ncp show line una-0 char
Line Volatile Characteristics as of 14-DEC-1984 23:47:20
Line = UNA-0
Receive buffers = 4
Controller = normal
Protocol = Ethernet
Service timer = 4000
Hardware address = AA-00-04-00-2A-7C
Buffer size = 1498
Regards,
Supratim
On 12/9/21 7:40 PM, Paul Koning wrote:
On Dec 9, 2021, at 6:02 PM, Johnny Billquist <mailto:bqt at softjar.se> <bqt at softjar.se> wrote:
On 2021-12-09 23:52, Mark J. Blair wrote:
So, basically like bang paths in uucp? Maybe I will play with that sometime!
Yes. But depending on application, it might be that all machines have to be up and running at the moment you're trying to use it, as opposed to UUCP which was store and forward.
Right. Roughly speaking, the sending application sees that there are multiple nodes, and that it uses PMR for this. It connects to the first of the nodes, object 63. It then sends it the rest of the connect information. PMR picks off the next node. If that's the last node, it connects to the requested object, otherwise again to another PMR.
VMS has PMR-like capability for network file access because RMS recognizes file names with node name prefixes, so it's an automatic consequence of that feature. RSTS NFT (the application which does network file access) doesn't support PMR as far as I remember. So if you have VMS nodes around you can chain node names in file access, with RSTS-only you cannot.
MAIL does it internally I think. Some vague memory says that RSTS network terminal ("set host") has PMR support, I need to look.
I'll definitely add PMR to PyDECnet at some point fairly soon.
paul
--
L.S.
Testing as it was done on the dup-dmc combination with the dmc side used as kind of proven reference.
The initial section is a log (see pdf link: https://drive.google.com/file/d/1-m3h5fpvv3JHHUYWi3zgX_qtfm3g1aRs/view?usp=… as Hecnet seems to disallow pdf attachments) of a dmc-dmc connection that works out of the box and leads to a Decnet adjacency up message.
Note that the dmc logging is not exactly time-sequential, therefor it is separated according to time stamp which reveals that xmt and rcv logging is not strictly ordered with respect to flow of time.
This snippet shows the exact packets that are exchanged with their correct crc checksums.
The dup-dmc logging in the second section below, can be arranged in lockstep with xmt/rcv and reveals an interesting anomaly where it seems somewhere in the beginning in dup two packets are coalesced, that at least is present in the dup logging, although the dmc does see it as two packets.
>From there onwards, dup-dmc are getting in a loop. It looks like the dup logging itself is neither consistent or constant (some lines are sometimes present and later on missing). The coalescing probably indicates some error(s) in dup simulation leading to the dmc dancing around with the dup in bad crc error reporting, although the checksums of the packets look ok, until some form of reset takes place and then it starts all over again.
Now it may be time to zoom in.
Reindert
Hello,
A little while ago I purchased an HP BL860c server blade. It has an Itanium
2 CPU and I was able to install OpenVMS 8.4 on it. However I do NOT have a
HP Bladesystem chassis to put the blade in, meaning I can only connect to
it via the SUV console cable which provides usb, serial, and VGA. There's
no way to get ethernet out of the thing without plugging it into a rather
gigantic Bladesystem chassis that I don't have. If it was an x64 based
blade running windows I could just use a USB->Ethernet adapter but of
course those things don't have OpenVMS drivers.
Given ethernet's not an option, would there be any way to tunnel DECNET
over the serial port? It seems like that was possible on VAXen and maybe
even Alphas but I've no mention of doing it on an Itanium. Or if anybody
else has any ideas of how I could network this thing I would appreciate it.
Chris
On Friday, December 10, 2021 at 12:19 PM, Paul Koning wrote:
> > On Dec 10, 2021, at 2:32 PM, cyb 2600 <cyb2600 at gmail.com> wrote:
> >
> > Hello,
> >
> > A little while ago I purchased an HP BL860c server blade. It has an Itanium 2
> CPU and I was able to install OpenVMS 8.4 on it. However I do NOT have a HP
> Bladesystem chassis to put the blade in, meaning I can only connect to it via
> the SUV console cable which provides usb, serial, and VGA. There's no way to
> get ethernet out of the thing without plugging it into a rather gigantic
> Bladesystem chassis that I don't have. If it was an x64 based blade running
> windows I could just use a USB->Ethernet adapter but of course those things
> don't have OpenVMS drivers.
> >
> > Given ethernet's not an option, would there be any way to tunnel DECNET
> over the serial port? It seems like that was possible on VAXen and maybe
> even Alphas but I've no mention of doing it on an Itanium. Or if anybody else
> has any ideas of how I could network this thing I would appreciate it.
>
> I don't know that VMS ever did it, but a number of DECnet systems support
> DDCMP over async lines (terminal serial ports). That's part of the standard.
VAX/VMS certainly did async DDCMP. I've no idea if that functionality got
migrated to Alpha and Itanium. I'd suggest you try following the VMS example.
If you can get the configuration steps to work (suggesting Itanium support) then
this should work with a serial line going into a simh VAX.
Good Luck,
- Mark
On Dec 9, 2021 1:02 PM, Johnny Billquist <bqt at softjar.se> wrote:
On 2021-12-09 23:52, Mark J. Blair wrote:
> So, basically like bang paths in uucp? Maybe I will play with that sometime!
Yes. But depending on application, it might be that all machines have to
be up and running at the moment you're trying to use it, as opposed to
UUCP which was store and forward.
Where EVERY step of the uucp activity was store and forward, including the local (starting system). The uucp command just queued the file for local background/later copy to the next hop.
- Mark
A little while ago, I got a second hecnet link to let me get on hecnet from my office at my day job. I've moved some of my node names from my home in Riverside, CA to my office in Norco, CA. If I wanted to get a new pin at http://akdesign.dyndns.org:8080/map for my relocated nodes, do I need to pester somebody to manually update locations in a database? Or does the mapping crawler look for something on the nodes which might feed updated location information to it?
I've begun putting .BEGIN-HECNET-INFO blocks in my INFO.TXT files, plagiarizing what I saw on Robert's nodes. But I get the impression that nothing automatically parses those at this time?
It's kind of silly that my Riverside and Norco nodes are quite close to each other in southern California, but have two separate links up to the bay area. I can't accept incoming connections either at home or at work, so I have two separate links to Robert instead of just linking directly between my two sites. Sigh. I'm still happy that I can get on hecnet both from home and work, and my two sites can talk to each other. Interactive sessions are naturally sluggish when I do something like editing a file, but it seems to work quite well otherwise.
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
https://www.nf6x.net/
Hi folks, just FYI, some of you may notice LSSM machines (most of the
machines in area 61) will be up and visible on HECnet through parts of
today.
Today is a volunteer work day at the museum, and a local company
(Iron Mountain) is sending a group of volunteers to come and spend the
day with us and help with various things. They'll be doing everything
from cleaning to installing new surveillance cameras. We've been
preparing for this for the past couple of weeks. Due to our perpetual
short-handedness this is a really big deal for us.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA