OpenVMS Notes: TCPware - MultiNet Tips

TCPware & MultiNet
- Sniffers
- FTP/SFTP
  - OpenVMS Notes: ssh2 (sftp starts with ssh/ssh2)
- MIME and Mail
- Timezones
- NTP
- DECnet over I/P (lines and tunnels)
  - our current DECnet network (soon to be retired)
  - our proposed solution #1
  - our proposed solution #2
OpenVMS Links

edit: 2021-09-11

TCPware - MultiNet - UCX

TCPware is a third-party TCP/IP stack published by Process Software Corp (PSC) for both VMS and OpenVMS. When I first started using TCPware on VMS in the early 1990s, DEC did not have a TCP/IP product for VAX. IMHO, one of the most useful features of TCPware are the FTP Library and TELNET Library which will enable your programs to more-easily connect to the internet.

According to PSC, TCPware will never be developed to support IPv6.

MultiNet was a competitor to TCPware originally created by TGV. PSC purchased the MultiNet stack from CISCO in 1997 so now they sell two stacks but only MultiNet is capable of both IPv4 and IPv6.

http://www.process.com/products/multinet/

UCX (Ultrix Communication eXtension) was a TCP/IP stack ported from the Ultrix OS to OpenVMS by DEC (Digital Equipment Corporation) where it was known as TCP/IP Services for OpenVMS v4 (at that time "OpenVMS" always meant "Alpha" but not VAX). UCX was then developed into TCPIP Services for OpenVMS v5

Packet Sniffing (raw) Examples

TCPware

$ set term/wrap/width=132
$ tcpdump :== $tcpware:tcpdump
$ tcpdump tcp and host kawc0g.on.bell.ca and port not ssh -vv -x -z -s 1500

MultiNet

$ multinet tcpdump /verbose/hex/snap=1500 tcp and host 142.180.221.220 and port 80

Note: programmers will often need to see the whole Ethernet packet (see the RED text) rather than just the first 64 bytes

FTP/SFTP

You can set up FTP-only inbound accounts in the two ways.

same way as an interactive user account (default)
you can go a little bit further and really lock it down (optional).

For example, by creating an MFD (master file directory) logical name in the system-level logical name table, your FTP-only account will appear to be in the top directory (root index) of a private disk. This will prevent hackers from "clicking up" to explore other directories on the disk because they are already at the top. See: systartup_vms_ftp_stub.com

Post Transaction Processing

When we moved from VAX to Alpha back in 1999, there were no Alpha versions of XCOM (which we used to start a batch job after each transaction). So I developed these two DCL scripts to reproduce that lost functionality.

Hint: on many VMS systems, SSH-based connections like SFTP, are identified as "F$MODE()=OTHER" rather than "F$MODE()=NETWORK"

SFTP (started out as FTP over SSH)

OpenVMS Notes: ssh2 (sftp starts with ssh/ssh2)

MIME and Mail

Link: OpenVMS Notes: mime (includes info on how to mail an attached ZIP file (requires version 5.8 or higher)

Timezones

You can read the docs, but it might me better to check the contents of these two files:

File	Contents
TCPWARE:TIMEZONES.DAT	vendor supplied timezone data
TCPWARE:TIMEZONES.LOCAL	customer supplied (custom) timezone data

A quick scan of file #1 shows:

my "Zone Name" should be "Canada/Eastern"
my "GMTOFF" should be -5:00
my "RULES" should be "CANADA"

NTP (Network Time Protocol)

You should only allow one software module to change time zones. Either OpenVMS (via sysgen parameter auto_dlight_sav) or TCPware (if you are running NTP)
caveats:
- sysgen parameter auto_dlight_sav was added in OpenVMS 7.3 so earlier VMS and OpenVMS systems will need to resort to a different technique (perhaps a DCL script)
  - https://docs.vmssoftware.com/vsi-openvms-system-manager-s-manual-volume-1-essentials
- Older unpatched OpenVMS systems which do support auto_dlight_sav could set back the time based upon rules set before the most recent change in 2007
- Most implementations of ntp/ntpd can be reconfigured in the field.
- PSC added a vms-specific-tweak to ntpd in TCPware which can change certain VMS/OpenVMS logical names (read on)
Dropping the following string into a Google search...

site:www.process.com auto_dlight_sav

...will cause Google to search the process.com web site looking for the phrase "auto_dlight_sav"

One of the articles states:

adding set_vms_logicals to the NTP.CONF file will cause TCPware (or MultiNet 5) to modify these VMS logical names:
SYS$TIMEZONE_DIFFERENTIAL
SYS$TIMEZONE_DAYLIGHT_SAVING
SYS$TIMEZONE_NAME
which is really important for certain programs requiring them.
Here is an example of my "ntp.conf" for a VMS box sitting on the public internet

$type tcpware:ntp.conf

server time.nrc.ca
server tick.utoronto.ca
server tock.utoronto.ca
set_vms_logicals
Because internet distance will translate into time delays, be sure to connect to NTP servers close to your location (e.g. not the University of Toronto servers I listed here)
Be sure to restart the ntp daemon after changes to the config file
@tcpware:restart ntp

(some) TCPware command-line tools to aid in pretesting, debugging, and monitoring.

Legend: <sr> = system response
        <ur> = user response
===============================
<sr> $
<ur> ntptrace time.nrc.ca
<sr> 132.246.11.227: stratum 2, offset 0.012997, synch distance 0.00626  
     tac.nrc.ca: stratum 1, offset 0.011343, synch distance 0.00026, refid 'PPS'
     $
<ur> ntpq
<sr> ntpq>
<ur> lpeers
<sr>      remote           refid      st t when poll reach   delay   offset  jitter
     ==============================================================================
     +132.246.11.227  132.246.11.231   2 u   65   64  376   46.859   14.623  53.121
     *dns4.utoronto.c 128.100.103.253  2 u   63   64  377   37.068   15.417  29.145
     +dense.utcc.utor 128.100.200.166  2 u    4   64  377   38.072   14.140  42.984
     ntpq>
<ur> exit
<sr> $
===============================
Column 1 Notes: 
1) asterisk: indicates our NTP daemon is currently locked onto dns4.utoronto.ca
2) plus    : indicates that these servers could be used if the primary is lost
3) space   : is usually seen after restarting ntpd and only indicates ntp
             connectivity if STRATUM < 16

DECnet over I/P (Lines and Tunnels)

I recently (2011.12.xx) was asked to move ten old VAX/VMS-5.5.2 systems (which require DECnet Phase IV) from "an intranet where DECnet was supported" to "a newer intranet where only I/P-routing is supported". Using TCPware's Tunneling DECnet over I/P feature works fairly well but here are a couple of gotchas:

Caveats:
1. Two important excerpts from TCPware chapter 29:
  1. This feature is intended for DECnet Phase IV. There is no need to use it with DECnet/OSI (a.k.a. DECnet Phase V). Instead, configure DECnet/OSI to run over TCP/IP as described in the DECnet/OSI documentation. No special TCPware configuration is required.
  2. To use DNIP lines, you must install a DECnet routing license on the system, unless the DNIP line is the only DECnet line on the system.
2. Since all network communications occur at the MAC layer (you ARP out with an Ethernet broadcast; the host system responds with a MAC address; communication continues MAC-to-MAC) native DECnet communications between any two machines should still work on any given Ethernet subnet. You will only need to use this feature when DECnet is blocked block by an I/P-only router. Do not bother with DECnet tunneling unless you need it.
Your DECnet license doesn't care if you install phase IV or phase V so you might wish to upgrade your DECnet stack.
- Be aware that phase V employs a different command-line interface for phase V ($mcr ncl) than than the one in phase IV ($mcr ncp).
- DECNET phase V on OpenVMS 7.0 (and higher) supports both NCP or NCL but phase V specific commands were only added to NCL
We now live in an I/P world so some DECnet terms, like routing, do not mean what you think
- So first a little history:
  - before the mid 1980s, routers were (almost always) computers which usually only supported one networking protocol
  - since the mid 1980's (after the creation of CISCO), routers became stand-alone special-purpose RISC appliances which could support multiple networking protocols. But computers (still mostly CISC) still could perform routing functions.
  - since Y2K, CISCO has been dropping support for less popular protocols like DECnet, etc.
- A DECnet address is specified in AREA.HOST notation like so: 63.1022
- DECnet can run in three different modes (types)
  - NON-ROUTING
    - required license: DVNETEND
    - a host attempting to make a connection does the DECnet equivalent of an ARP (address resolution protocol), then expects the destination node to answer back with a MAC address. So in a typical DECnet network (composed of only NON-ROUTING hosts) all the hosts would need to be on the same subnet. Since a DECnet area can support 1024 host addresses this could make for a busy subnet. Back in 1990 if you had a busy Ethernet subnet you would split it into one, or more, segments which would be connected with an Ethernet bridge. Something similar was done to split a DECnet.
    - this type of machine can have many lines but only one active circuit (which results in only one line being used)
  - ROUTING (level-1 routing)
    - required license: DVNETRTG
    - a host running DECnet is joining two, or more, logical DECnets with the same AREA
    - In the Ethernet world we would refer to this as an Ethernet bridge (which only works at the MAC layer).
    - Since this is done at the network layer but only allows similar DECnet AREAS, in my mind it is more like a DECnet bridge
    - this type of machine can have many lines and many circuits
  - AREA (level-2 routing)
    - required license: DVNETRTG
    - a host running DECnet is joining two, or more, logical DECnet(s) with any AREA
Tunneling Caveats:
- DECnet non-routing
  - all DECnet connections must be either native or tunneled but not both
    - (this restriction does not include the special DECnet channel used for cluster communication which is almost always done on a PE device like PEA0:)
- DECnet Routing (level-1 routing) or DECnet Area (level-2 routing)
  - supports mixed DECnet connections (visit this link then inspect the block diagram)
    (HTML) http://www.process.com/tcpip/tcpware59docs/html/management/ch29.htm
    (PDF) http://www.process.com/tcpip/tcpware59docs/pdf/manage.pdf
    The two middle nodes must be ROUTING (or AREA)
  - DECnet Routing requires a DVNETRTG license from HP.
  - DECnet AREA seems to only require a DVNETRTG license (at least on uVAX-4300). I have been told that AREA routing was more expensive in the past. I have never had to do this but have been told that if you are in a jam, then you can legally bump up the units of a license (provided the license option contains the phrase MOD_UNITS) with commands like this:
    
    $lic unload DVNETRTG
    $lic mod /units=460 DVNETRTG
    $lic load DVNETRTG
    How does this work? All the licenses containing the string MOD_UNITS place their resources in a license pool. A bumped up license may borrow from the pool which could affect other resources like the maximum number of interactive users so please be careful.
- Which DECnet Phase IV mode is your system running?
  - $ mcr ncp
  - ncp> show exec characteristics (then inspect TYPE which could be one of:
    1. NON ROUTING IV
    2. ROUTING IV
    3. AREA
  - ncp> exit
  - Caveat: you can't change this parameter using a command like "SET EXEC TYPE ROUTING IV". You must use something like "DEFINE EXEC TYPE ROUTING IV" (or "DEFINE EXEC TYPE AREA") then must restart the stack (or reboot the system) to have it take effect. Warning: many years ago I did this on a system with insufficient license units only to find I was not able to use NCP to restore the stack to "NON ROUTING IV". At this point I could only navigate to SYS$MANAGER then execute DCL script NETCONFIG.COM (so be very careful and be sure you have a hard copy of your parameters in case you need to put them back manually)
- when configuring DNIP on TCPware, make sure you enter the I/P address of the destination machine. The tool in TCPware-5.9-2 allows you to enter your own machine without any warnings or errors but this can cause strange things to happen when you restart your whole stack (which could be many months or perhaps years)

MY EXPERIMENTS (2011.12.xx)
===========================

                   DECnet Friendly Intranet                          DECnet Hostile Intranet
                                                                           (Proposed)
+----------------------+          +----------------------+          +----------------------+
| Node: KAWC15         |          | Node: KAWC09         |          | Node: KAWC98         |
| AlphaServer-DS20e    |          | AlphaServer-DS20e    |          | AlphaServer-2100     |
| Addr: 12.345         |          | Addr: 12.346         |          | Addr: 12.347         |
| Mode: NON ROUTING IV |          | Mode: ROUTING IV     |          | Mode: NON ROUTING IV |
| DECnet Known Lines:  |          | DECnet Known Lines:  |          | DECnet Known Lines:  |
| Line/Circ State      |          | Line/Circ State      |          | Line/Circ State      |
| --------- -----      |          | --------- -----      | DECnet   | --------- -----      |
|                      |          | DNIP-0-0  on  note-0 + tunnel   + DNIP-0-0  on  note-0 |
| EIA-0     off note-1 + 100-Mb/s + EIA-0     off note-1 + 100-Mb/s + EIA-0     off note-1 |
| EWA-0     on  note-2 +  10-Mb/s + EWA-0     on  note-2 |          |                      |
| FPA-0     on  note-3 + 100-Mb/s + FPA-0     on  note-3 |          |                      |
+----------------------+          +----------------------+          +----------------------+
Notes:
0) DECnet-tunnel will use any available I/P network to accomplish its tasks (eg. 100-Mb/s)
1) DECnet is not allowed on the new 100 Mb/s Ethernet (NCP: turn off line and circuit)
2) DECnet is     allowed on the old  10 Mb/s Ethernet (which will be retired very soon)
3) Our FDDI network is private so we can do whatever we want in our computer room
4) Every line set to OFF in DECnet is still ON in TCPware (obviously)
5) The middle node must be ROUTING (or AREA) in order for the outer nodes to communicate
   with each other

Our current DECnet-friendly Network (soon to be retired)
Note: TCP/IP equipment is not shown
Note: RED stuff will be ripped out so we need alternatives
==========================================================

                                      +-----------------+
                                      | Cisco           +--> To Quebec City (area: 28)
                       +--------------+ DECnet AREA     +--> To Montreal    (area: 25)
                       |              | Addr: 63.1022   +--------------+     
                       |              +-----------------+              |
                       |                                               |     
+----------------------+----------------------+ +----------------------+-------------------+
| Cisco (Kitchener)                           | | Cisco (Toronto)                          |
| DECnet Routing                              | | DECnet Routing                           |
| Address: 14.1022                            | | Address: 17.1009                         |
+----------------------+----------------------+ +----------------------+-------------------+
                       |                                               |
+----------------------+----------------------+ +----------------------+-------------------+
| Synoptics Ethernet Hub                      | | Synoptics Ethernet Hub                   |
+----------------------+----------------------+ +----------------------+-------------------+
                       |                                               |
+--------------------+ | +--------------------+ +--------------------+ |
| VAX                | | | DEC-Alpha          | | VAX                | |
| DECnet Non-Routing +-+-+ DECnet Non-Routing | | DECnet Non-Routing +-+
| Node KAWC01 14.842 | | | Node KAWC15 14.950 | | Node SMCC07 17.367 | |
+--------------------+ | +--------------------+ +--------------------+ |
+--------------------+ | +--------------------+ +--------------------+ |
| VAX                | | | DEC-Alpha          | | VAX                | |
| DECnet Non-Routing +-+-+ DECnet Routing IV  | | DECnet Non-Routing +-+
| Node KAWC02 14.843 |   | Node KAWC09 14.828 | | Node SMCC08 17.368 | |
+--------------------+   +---------+----------+ +--------------------+ |
                                   |            +--------------------+ |
  DECnet over IP  ->               |            | VAX                | |
  (Experimental)         +---------+----------+ | DECnet Non-Routing +-+
                         | DEC-Alpha          | | Node SMCC09 17.439 |
                         | DECnet Non-Routing | +--------------------+
                         | Node KAWC98 14.998 |
                         +--------------------+
Notes:
1) The company wants to remove all the stuff in RED 
   a) Ethernet hubs will be replaced with Ethernet switches
   b) DECnet support will be dropped from the routers
   c) DECnet (and any other non-standard protocol) should always be possible on local
      subnets
2) Depending upon how your new equipment is configured, you "might not need" to run DECnet
   Tunneling between machines on the same subnet so don't install it unless you require it
3) If intra-city subnets exist, then each city will require at least one machine acting as
   a ROUTER
4) If the designated ROUTER node does not have NICs connected to all local subnets, then
   each subnet will need at least one machine running as a ROUTER node, and those ROUTER
   nodes would need to be connected by DECnet Tunneling.
5) In this network, inter-city routing required at least one machine running as an AREA
   node. If the AREA node does not have NICs connected to each subnet where communication
   is required, then you must setup a DECnet Tunnel between the AREA node and the various
   ROUTER nodes
6) Since SMCC07 needs to send hourly messages to the VAX machines in Kitchener, perhaps
   SMCC07 and KAWC01 would be good AREA candidates. (AREA machines can also do ROUTING and
   END)
7) These AREA routers will need to be connected via DECnet tunnels
8) In this example, KAWC09 acts as a bridge between KAWC98 and the other machines on the 
   Kitchener subnet. Without KAWC09 performing this role, no machines would be able to
   connect to KAWC98, and KAWC98 would not be able to connect to any machine other than
   KAWC09.

Proposed solution 1 of 2 (best performance; more burden placed upon LAN hardware)
Note: TCP/IP equipment is not shown
Note: DEC-Alpha boxes not shown
=================================================================================
  Kitchener                Toronto                  Montreal                 Quebec City
  (area: 14)               (area: 17)               (area: 25)               (area: 28)
                         +--------------------+   +--------------------+
                         | DNIP-0-1 note-1    +---+ DNIP-0-1 note-1    |
                       +-+ DNIP-0-0 note-2    |   | DNIP-0-0 note-3    +--------------------------+
                       | | VAX                |   | VAX                |                          |
                       | | DECnet Area Rtg    |   | DECnet Area Rtg    |                          |
                       | | Node SMCC07 17.xxx |   | Node STDC02 25.xxx |                          |
                       | | ISA-0    note-4    +-+ | ISA-0    note-4    +-+                        |
                       | +--------------------+ | +--------------------+ |                        |
+--------------------+ | +--------------------+ | +--------------------+ | +--------------------+ |
| DNIP-0-0 note-2    +-+ |                    | | |                    | | | DNIP-0-0 note-3    +-+
| VAX                |   | VAX                | | | VAX                | | | VAX                |
| DECnet Area Rtg    |   | DECnet Non-Routing | | | DECnet Non-Routing | | | DECnet Area Rtg    |
| Node KAWC01 14.xxx |   | Node SMCC08 17.xxx | | | Node STDC05 25.xxx | | | Node LGVC13 28.xxx | 
| ISA-0    note-4    +-+ | ISA-0    note-4    +-+ | ISA-0    note-4    +-+ | ISA-0    note-4    +-+
+--------------------+ | +--------------------+ | +--------------------+ | +--------------------+ |
+--------------------+ | +--------------------+ | +--------------------+ | +--------------------+ |
| VAX                | | | VAX                | | | VAX                | | | VAX                | |
| DECnet Non-Routing | | | DECnet Non-Routing | | | DECnet Non-Routing | | | DECnet Non-Routing | |
| Node KAWC02 14.xxx | | | Node SMCC09 17.xxx | | | Node STDC06 25.xxx | | | Node LGVC14 28.xxx | |
| ISA-0    note-4    +-+ | ISA-0    note-4    +-+ | ISA-0    note-4    +-+ | ISA-0    note-4    +-+
+--------------------+   +--------------------+   +--------------------+   +--------------------+

Notes:
0) If you change all the DECnet addresses to the same area then you can change AREA to ROUTING IV
1) This is the link between areas 17 and 25
2) This is the link between areas 17 and 14
3) This is the link between areas 25 and 25
4) These links all happen on the local subnet (no need to tunnel)
5) Consider adding another tunnel between areas 14 and 28 (completes the circle; backup path)

Proposed solution 2 of 2 (future proof; more burden placed upon computers)
Note: TCP/IP equipment is not shown
Note: DEC-Alpha boxes not shown
==========================================================================
  Kitchener                Toronto                  Montreal                 Quebec City
  (area: 14)               (area: 17)               (area: 25)               (area: 28)
                         +--------------------+   +--------------------+
                         | DNIP-1-1 note-1    +---+ DNIP-1-1 note-1    |
                       +-+ DNIP-2-1 note-2    |   | DNIP-3-1 note-3    +--------------------------+
                       | | VAX                |   | VAX                |                          |
                       | | DECnet Area Rtg    |   | DECnet Area Rtg    |                          |
                       | | Node SMCC07 17.367 |   | Node STDC02 25.xxx |                          |
                       | | DNIP-2-2 note-2    +-+ | DNIP-3-2 note-3    +-+                        |
                       | +--------------------+ | +--------------------+ |                        |
                       |                        |                        |                        |
+--------------------+ | +--------------------+ | +--------------------+ | +--------------------+ |
| VAX                | | | VAX                | | | VAX                | | | VAX                | |
| DECnet Area Rtg    | | | DECnet Non-Routing | | | DECnet Non-Routing | | | DECnet Area Rtg    | |
| Node KAWC01 14.842 | | | Node SMCC08 17.368 | | | Node STDC05 25.xxx | | | Node LGVC13 28.xxx | |
| DNIP-2-1 note-2    +-+ | DNIP-2-1 note-2    +-+ | DNIP-3-1 note-3    +-+ | DNIP-3-1 note-3    +-+
| ISA-0    off       |   | ISA-0    off       |   | ISA-0    off       |   | ISA-0    off       |
| DNIP-2-2 note-2    +-+ | DNIP-2-2 note-2    +-+ | DNIP-3-2 note-3    +-+ | DNIP-3-2 note-3    +-+
+--------------------+ | +--------------------+ | +--------------------+ | +--------------------+ |
                       |                        |                        |                        |
+--------------------+ | +--------------------+ | +--------------------+ | +--------------------+ |
| VAX                | | | VAX                | | | VAX                | | | VAX                | |
| DECnet Non-Routing | | | DECnet Non-Routing | | | DECnet Non-Routing | | | DECnet Non-Routing | |
| Node KAWC02 14.843 | | | Node SMCC09 17.439 | | | Node STDC06 25.xxx | | | Node LGVC14 28.xxx | |
| DNIP-2-1 note-2    +-+ | DNIP-2-1 note-2    +-+ | DNIP-3-1 note-3    +-+ | DNIP-3-1 note-3    +-+
| ISA-0    off       |   | ISA-0    off       |   | ISA-0    off       |   | ISA-0    off       |
| DNIP-2-2 note-2    +---+ DNIP-2-2 note-2    |   | DNIP-3-2 note-3    +---+ DNIP-3-2 note-3    |
+--------------------+   +--------------------+   +--------------------+   +--------------------+

Notes:
0) If you change all the DECnet addresses to the same area then you can change AREA to ROUTING IV
1) This tunnel links areas 17 and 25 (Ontario to Quebec) which is only used for maintenance
2) These tunnels constitute the Ontario ring
3) These tunnels constitute the Quebec ring
4) Consider adding another tunnel between SMCC09 and STDC06

OpenVMS Links

PSC (Process Software Corp)
my OpenVMS Notes (index from A-Z)
- OpenVMS Notes: SSH2
- OpenVMS Notes: SSL/TLS
- OpenVMS Notes: Cryptography
- Calendar Concerns (and other computer clock stuff)

Back to Home
Neil Rieck
Waterloo, Ontario, Canada.