The VMS SharkOpenVMS Notes: TCPware Tips

  1. The information and software presented on this web site are intended for educational use only by OpenVMS application developers and OpenVMS system attendants.
  2. The information and software presented on this web site are provided free of charge.
  3. The information and software presented on this web site are presented to you as-is. I will not be held responsible in any way if the information and software presented on this web site damages your computer system, business or organization (sounds like the legal warning from a Microsoft shrink-wrap seal, eh?)
  4. Is this text too small? You have two options:
    1. hold down the CTRL key while rolling the mouse wheel (zoom-in, zoom-out)
    2. use your keyboard like so:
      • hit: CTRL with "-" key to zoom smaller
      • hit: CTRL with "+" key to zoom larger
      • hit: CTRL with zero key to reset zoom
 Edit: 2012-05-23 (added proposed solution #2)

Quick Nav Menu

TCPware & MultiNet

TCPware is a third-party TCP/IP stack published by Process Software Corp for VMS and OpenVMS. When I first started using TCPware on VMS in the early 1990s, DEC did not have an equivalent TCP/IP product. IMHO, one of the most useful features of TCPware are the FTP Library and TELNET Library which will enable your programs to make easy connections to the network.

MultiNet was a competitor to TCPware created by TGV. Process purchased the MultiNet stack from CISCO in 1997 so now they sell two stacks.

FTP/SFTP

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

  1. same way as an interactive user account (default)
     
  2. 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.
     
    systartup_vms_ftp_stub.com

Post Transaction Processing

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

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:

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

NTP (Network Time Protocol)

  1. 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)
     
  2. Dropping the following string into Google...
     
        site:www.process.com  auto_dlight_sav
     
    ...will cause Google to search the process.com web site looking for the phrase "auto_dlight_sav". Here are a few hits:
    http://www.process.com/techsupport/tcpware_faqs.html
    http://www.process.com/techsupport/multinet_faqs.html
    http://www.process.com/tcpip/2007Newsletters/12-2.html#ntpfaq2
    which states:
    adding set_vms_logicals to the NTP.CONF file will cause TCPware to modify these VMS logicals:
    SYS$TIMEZONE_DIFFERENTIAL
    SYS$TIMEZONE_DAYLIGHT_SAVING
    SYS$TIMEZONE_NAME
    which is really important for certain programs requiring them.
  3. 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)
     
  4. Be sure to restart the ntp daemon after changes to the config file
    @tcpware:restart ntp
  5. (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> $
          Notes: 
         1) an asterisk in column 1 indicates our NTP daemon is currently locked onto dns4.utoronto.ca
         2) a plus sign in column 1 indicate that these servers could be used if the primary is lost
         4) a space in column 1 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:

<<< MY EXPERIMENTS (2011.12.xx) >>>

                   DECnet Semi-Friendly Intranet(s)                                DECnet Hostile Intranet
                                                                                           (Future)
+----------------------+                 +----------------------+                   +-----------------------+
| 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       |
| --------- -----      |                 | --------- -----      |                   | --------- -----       |
|                      |                 | DNIP-0-0  on  note-0 +- DECnet over IP --+ DNIP-0-0  on  note-0  |
| EIA-0     off note-1 +- 100 Mb/s ENet -+ EIA-0     off note-1 +- 100 Mb/s ENet 2 -+ EIA-0     off note-1  |
| EWA-0     on  note-2 +-  10 Mb/s ENet -+ EWA-0     on  note-2 |                   |                       |
| FPA-0     on  note-3 +- 100 Mb/s FDDI -+ FPA-0     on  note-3 |                   |                       |
+----------------------+                 +----------------------+                   +-----------------------+
Notes:
0) DECnet-over-IP will use any available I/P network to accomplish its tasks (100 Mb/s Enet 2 in this case)   
1) DECnet-over-Ethernet is not allowed on the new 100 Mb/s Ethernet (so turn off the line and circuit in NCP)
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 node.
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 wouldn't 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.367 |   | 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.842 |   | Node SMCC08 17.368 | | | 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.843 | | | Node SMCC09 17.439 | | | 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


Back to OpenVMS
Back to Home
Neil Rieck
Kitchener - Waterloo - Cambridge, Ontario, Canada.