[HECnet] DECnet-VAX V3.0, VMS V3.5 (Was Re: 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] 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 --