Tuesday, September 12, 2017

DECnet Phase IV: copy node database from remote host and share it with other nodes over network with Digital DEC servers

Supratim Sanyal's Blog: DECnet-20 on TOPS-20 (TWENEX)
DECnet-20 on TOPS-20 (TWENEX) from "TOPS-20 DECnet-20 Programmer's Guide and Operations Manual" at Bitsavers


DECnet Phase IV on OpenVMS VAX 7.3

To copy the nodes database from a remote host and make it available to other nodes to copy from my node, I use the command file at the bottom. Here <REMOTE-NODE> is the DECnet node name / address of the host I copy my node database from.

After copying over the remote node database from another server (a PDP-11/24 running RSX-11M Plus that serves HECnet the world-wide hobbyist DECnet in this case), I basically copy SYS$SYSTEM:NETNODE_LOCAL.DAT and SYS$SYSTEM:NETNODE_REMOTE.DAT to SYS$COMMON:[SYSEXE] and grant them world-read permission.

Before doing this, other nodes that tried to copy the node database from my node (1.559) used to get this error, which does not happen any more:
$ MC NCP TELL 1.559 LIST KNOWN NODES
Known Node Permanent Summary as of 12-SEP-2017 18:29:00
%NCP-W-FILOPE, File open error , Permanent database
%NML-E-OPENIN, error opening SYS$COMMON:[SYSEXE]NETNODE_LOCAL.DAT; as input
-RMS-E-FNF, file not found

I also played around with enabling the NML proxy before running the commands in the DCL command file at bottom. I am not sure if I had enabled the NML proxy during installation of DECnet Phase IV and if these were required, but just doing these did not solve the problem. They may be required part of the solution, though.

$ MC NCP SET EXECUTOR INCOMING PROXY ENABLE
$ MC NCP DEFINE EXECUTOR INCOMING PROXY ENABLE
$ MC NCP SET OBJECT NML PROXY INCOMING
$ MC NCP DEFINE OBJECT NML PROXY INCOMING

Here is the DCL script:

$ SET PROC/PRIV=ALL
$ MC NCP copy known nodes from <REMOTE-NODE> using volatile to BOTH
$ MC NCP LIST KNOWN NODES
$ COPY/LOG/NOCONF SYS$SYSTEM:NETNODE_LOCAL.DAT SYS$COMMON:[SYSEXE]NETNODE_LOCAL.DAT
$ SET FILE/LOG/PROT=(W:R) SYS$COMMON:[SYSEXE]NETNODE_LOCAL.DAT
$ COPY/LOG/NOCONF SYS$SYSTEM:NETNODE_REMOTE.DAT SYS$COMMON:[SYSEXE]NETNODE_REMOTE.DAT
$ SET FILE/LOG/PROT=(W:R) SYS$COMMON:[SYSEXE]NETNODE_REMOTE.DAT


PDP-11/24 RSX-11M-PLUS 4.6


The HECnet node database is diligently maintained current at http://mim.update.uu.se/hecnod. It is a list of nodes, one per line, with a search box at the top. The line entries are in the form of white-space delimited information fields per node for HECnet nodes. The first two fields are the DECnet node address and the node name in round brackets. Here is an example line entry:

31.3 (PYRTR)    Reachable                   IP-0-9       31.3 (PYRTR)

The following simple Linux command-line fetches the HECnet node database over HTTP and produces a "nodename.cmd" command file that can be uploaded and executed on PDP-11/24 systems running RSX-11M-PLUS operating system (for example, my own node JUICHI). The command file will be a series of NCP command lines, one per node, setting the node addresses to node names.

curl -sNm 60 http://mim.update.uu.se/hecnod | dos2unix | egrep "^[0-9]" | cut -f 1-2 -d " " | sed -re 's/^/NCP SET NODE /' | sed -re 's/[(]/NAME /' | sed -re 's/[)]//' > nodename.cmd

But the resultant nodename.cmd misses the entry of 1.13 (MIM) because MIM is the executor and only mentions itself at the top of the list, not in the actual list of known nodes. So manually edit nodename.cmd and add a line for MIM:

NCP SET NODE 1.13 NAME MIM

To upload nodename.cmd to JUICHI, I FTP it to QCOCAL VAX and then use DECnet COPY to copy it over to JUICHI.

Alternatively, if we are already connected to HECnet, steps like the following get the node database straight from MIM using CFE. We can ignore the warnings for trying to redefine the executor's node name and address.


UNIBUS (UNA network device):

>NCP SET NODE MIM ADDRESS 1.13
NCP -- Set failed, invalid identification format, Node
>NFT FIX.CMD=MIM"GUEST GUEST"::HECNET:FIX.CMD
>RUN [5,54]CFERES
Enter filename: [5,54]CETAB
CFE>@fix.cmd
    DEF >>NOD 31.12 NAME JUICHI
CFE -- Parameter not applicable
CFE>^Z
>


QBUS (QNA network device):

>NCP SET NODE MIM ADDRESS 1.13
>NFT FIX.CMD=MIM"GUEST GUEST"::HECNET:FIX.CMD
>RUN [5,54]CFEFSL
Enter filename: [5,54]CETAB
CFE>@FIX.CMD
    DEF >>NOD 31.34 NAME NANAJU
CFE -- Parameter not applicable
CFE>^Z
>


PDP-10 KS10 TOPS-10 DECnet-10 (TWONKY)


To update the DECnet node database on my PDP-10 KS10 node "TWONKY" I run this command procedure from the [1,2] account:

;NODNAM.CMD
.r opr
*enter ncp
*set node 1.13 name mim
*return
*exit
.r nft
*copy fix.t20=mim::hecnet:FIX.T20/user:guest::guest
;exit
.r opr
*enter ncp
*take fix.t20
*exit
 

PDP-10 KL10 TOPS-20 DECnet-20 (TWENEX)

Current Approach

I have a command file "NODNAM.CMD" with the following contents which I then SUBMIT NODNAM.CMD as a batch job and watch the log using TYPE NODNAM.LOG.

;NODNAM.CMD
@ena
@r opr
*enter ncp
*set node 1.13 name mim
*return
*exit
@nft
*SET DEFAULTS MIM:: /USER:GUEST
*SET DEFAULTS MIM:: /PASSWORD:GUEST
*SET DEFAULTS MIM:: /ACCOUNT:GUEST
*copy mim::hecnet:fix.t20 fix.t20
;Access information for node mim::
;User: guest
;Account: guest
;Password:guest
;mim::DU1:[DECNET]FIX.T20;123 => TOPS20:<OPERATOR>FIX.T20.2 [OK]
*exit
@r opr
*enter ncp
*take fix.t20
*exit
@info batch
@echo game over

Once the bacth job completes, the latest HECnet node names are defined on TWENEX, and I can, for example, successfully do this:

$OPR
OPR>NCP TELL NJEVX2 SHOW EXEC CHAR
OPR>
04:31:53        NCP
                Request # 288 Accepted
OPR>
04:31:53        NCP

Request # 288; Show Executor Node Characteristics Completed

Executor Node = 31.36 (NJEVX2)

  Identification = DECnet for OpenVMS VAX V7.3
  Management Version = 4.0.0
  Incoming Timer = 45
  Outgoing Timer = 60
  Parameter #522 = 0
  Parameter #523 = 0
  NSP Version = 4.1.0
  Maximum Links = 32
  Delay Factor = 80
  Delay Weight = 5
  Inactivity Timer = 60
  Retransmit Factor = 10
  Routing Version = 2.0.0
  Type = Nonrouting IV
  Routing Timer = 600
  Broadcast Routing Timer = 180
  Maximum Address = 1023
  Maximum Circuits = 16
  Maximum Cost = 1022
  Maximum Hops = 30
  Maximum Visits = 63
  Maximum Area = 63
  Maximum Broadcast Nonrouters = 64
  Maximum Broadcast Routers = 32
  Parameter #933 = 1
  Area Maximum Cost = 1022
  Area Maximum Hops = 30
  Maximum Buffers = 100
  Buffer Size = 576
  Non-privileged User ID = DECNET
  Default access = Incoming and outgoing
  Pipeline quota = 4032
  Parameter #2743 = 32
  Parameter #2780 = 0
  Parameter #2785 = 31
OPR>EXIT
$LOGOUT
[Jobs 0(DET), 1, 2(DET), 3, 4, 5, 6, 7, 8 also logged in under OPERATOR]
Killed Job 9, User OPERATOR, TTY5, at 10-Feb-2020 04:38:35

 Used 0:00:00 in 0:04:44

Prior (Obsolete) Approach

To update the DECnet node database on my PDP-10 TWENEX node I first run the following Linux command line to produce a nodnm20.cmd command file. The generated command file is basically a series of lines of the form "SET NODE <xx.yyy> NAME <name>" based on the nodename database retrieved over the web from MIM.


curl -sNm 60 http://mim.update.uu.se/hecnod | dos2unix | egrep "^[0-9]" | cut -f 1-2 -d " " | sed -re 's/^/SET NODE /' | sed -re 's/[(]/NAME /' | sed -re 's/[)]//' > nodnm20.cmd


I then manually edit nodnm20.cmd to add a line for MIM itself:

SET NODE 1.13 NAME MIM

and then upload nodnm20.cmd using OPERATOR account to TWENEX. For uploading, I FTP it to a VAX (e.g. QCOCAL) and the use DECnet COPY from the VAX to TWENEX, like this:

$ COPY/LOG nodnm20.cmd TWENEX"OPERATOR <PASSWORD>"::

Then, my subsequent steps to update the TOPS-20 MONITOR are:

^C
@LOGIN OPERATOR
Password: 
 End of <SYSTEM>LOGIN.CMD.2
 End of LOGIN.CMD.1
@ENA
$COPY NODNM20.CMD  SYS:
 NODNM20.CMD.1 => <SUBSYS>NODNM20.CMD.3 [OK]
$PURGE SYS:
$DIR SYS:NOD*.CMD

   TOPS20:<SUBSYS>
 NODNM20.CMD.3


 Total of 8 pages in 1 file
$RUN SYS:SETNOD
SETNOD>TAKE NODNM20.CMD
SETNOD>SAVE SYSTEM:DECNET-NODES.DAT

SETNOD>INSERT
SETNOD>EXIT


PDP-11/73 RSTS/E 10.1 DECnet/E V4.1


Updating the DECnet node database on my PDP-11/73 running RTST/E 10.1 with DECnet/E 4.1 is similar, but not identical, to TWENEX and RSX-11M-PLUS. The following Linux bash shell script produces a RSTS/E command file defnod.cmd. It includes DEFINE NODE commands and then SET NODE commands to update the permanent as well as volatile node databases.

#!/bin/bash
OUTFILE="defnod.cmd"
echo "SET VER" > ${OUTFILE}
echo "SET NOON" >> ${OUTFILE}
curl -sNm 60 http://mim.update.uu.se/hecnod | dos2unix | egrep "^[0-9]" | cut -f 1-2 -d " " | sed -re 's/^/NCP DEFINE NODE /' | sed -re 's/[(]/NAME /' | sed -re 's/[)]//' >> ${OUTFILE}
sleep 5
curl -sNm 60 http://mim.update.uu.se/hecnod | dos2unix | egrep "^[0-9]" | cut -f 1-2 -d " " | sed -re 's/^/NCP SET NODE /' | sed -re 's/[(]/NAME /' | sed -re 's/[)]//' >> ${OUTFILE}
ls -l ${OUTFILE}


I then manually edit defnod.cmd and add a line for MIM itself:

NCP SET NODE 1.13 NAME MIM

and FTP the final defnod.cmd to a VAX/VMS box and then copy it over DECnet to the [1,2] account on RSTS/E. The /OVERWRITE switch is necessary here since DECnet/E for RSTS/E refuses to overwrite the file if it already exists.

$ copy *nod.cmd RST101"1,2 <password>":: /log /over
%COPY-I-OVERLAY, RST101"1,2 password"::SY:[1,2]DEFNOD.CMD being overwritten
%COPY-S-COPIED, DUA1:[SANYAL]DEFNOD.CMD;2 copied to RST101"1,2 password"::SY:[1,2]DEFNOD.CMD (95 blocks)

Then I log into RSTS/E as 1,2 and execute the command file.

$ @defnod.cmd

A simple test to check if it works:

$ NCP TELl NJEVX2 SHOW EXEC CHAR
Node Volatile Characteristics as of 11-FEB-20 23:23:52

Executor Node = 31.36 (NJEVX2)

Identification             = DECnet for OpenVMS VAX V7.3
Management Version         = 4.0.0
Incoming Timer             = 45
Outgoing Timer             = 60
Parameter #522             = %H'00' 
Parameter #523             = %H'00' 
ECL Version                = 4.1.0
Maximum Links              = 32
Delay Factor               = 80
Delay Weight               = 5
Inactivity Timer           = 60
Retransmit Factor          = 10
Routing Version            = 2.0.0
Type                       = Non-Routing IV
Routing Timer              = 600
Broadcast Routing Timer    = 180
Maximum Address            = 1023
Maximum Circuits           = 16
Maximum Cost               = 1022
Maximum Hops               = 30
Maximum Visits             = 63
Maximum Area               = 63
Max Broadcast Nonrouters   = 64
Max Broadcast Routers      = 32
Parameter #933             = %D'1' 
Area Maximum Cost          = 1022
Area Maximum Hops          = 30
Maximum Buffers            = 100
Buffer Size                = 576
Parameter #2712            = %A'DECNET' 
Parameter #2731            = %H'03' 
Parameter #2740            = %D'4032' 
Parameter #2743            = %D'32' 
Parameter #2780            = %H'00' 
Parameter #2785            = %D'31' 
$ 


Apple Macintosh Classic MacOS 7 & MacOS 9 - Thursby TSSNet / DEC Digital Pathworks for Macintosh

From the TSSNet or DECnet for Macintosh folder, launch the NCP application. This will open up the "DECnet Network Control Program" (NCP) window.

Click on the "Node Definitions" long button on the "DECnet Network Control Program" window.


DECnet for Macintosh: Thursby Software TSSNET for Macintosh: Copy node database - Screen 1



The "DECnet Node Name Management" window will be displayed. Fill in the Area Number and Node Number of the remote DECnet node which you want to copy the node database from. Then click on the "Ask" button.


DECnet for Macintosh: Thursby TSSnet for Macintosh: Copy node database - Screen 2



You will be presented with a windows asking for the Username and Password. Usually there is not Username and Password configured for DECnet Node Database access; leave them empty and click on OK.


DECnet for Macintosh: Thursby Software TSSnet for Macintosh: Copy node database - Screen 3



The next question will be about the name of the node or area number that you are inquiring about. Since we want to copy over the entire node database including all areas and all nodes, enter an asterisk (*) and click on INQUIRE.

DECnet for Macintosh: Thursby TSSNET for Macintosh: Copy node database - Screen 4



A pop-up will now say "Loading Node : " followed by rapidly changing node names as their definitions are copied over from the remote node.


DECnet for Macintosh: Thursby Software TSSNET for Macintosh: Copy node database - Screen 5





Windows NT 4.0 - DEC Pathworks 32 7.4



Supratim Sanyal's Blog: Copy DECnet Phase IV Node Databse from OpenVMS VAX server to Windows NT 4.0 running DEC Pathworks 32 7.4 over DECnet using NCP copy command


After configuring DEC Pathworks 32 on Windows NT 4.0 and establishing DECnet Phase IV communication with my DECnet nodes, I copied over the DECnet node database from IMPVAX OpenVMS VAX 7.3 (1.559) to Windows NT 4.0 Pathworks-32 using the simple NCP command:

NCP COPY KNOWN NODES FROM 1.559

A subsequent NCP LIST KNOWN NODES command produced a full list of DECnet nodes copied over from IMPVAX.


DECnet/Python



Paul Koning's DECnet/Python expects a list of DECnet nodes and addresses, one on each line, in the format:

node address name

This bash shell script generates a suitable nodenames.conf database for HECnet:

CISCO Switches (DECnet over GRE tunnel on CISCO 7204VXR)



No comments:

Post a Comment

"SEO" link builders: move on, your spam link will not get posted.

Note: Only a member of this blog may post a comment.