OpenVMS Notes: TCPIP Services for OpenVMS

  1. The information presented here is intended for educational use by qualified OpenVMS technologists.
  2. The information presented here is provided free of charge, as-is, with no warranty of any kind.
Quick-Nav Menu
Edit: 2016-01-06 (updated some info about FTP logical names)
Edit: 2024-03-31 (added a blurb about TCPIP v6.0)

The Name Game

TCPIP v5.7 Gotchas

1) The biggest problem with this product is a lack of documentation. Why?

2) Config Data Corruption

3) Patching is flaky (unpredictable)

4) do not believe what you see when using script sys$manager:tcipip$config

5) limiting the actions of hackers when sitting on the public internet.

Setting up SMTP TCPIP v5.7 (what a pain)

Notice: despite my troublesome comments below, once I fine-tuned the anti-spam settings of this product, the SPAMMERS have been driven away. My site was receiving ~150 pieces of SPAM per day but now only receive ~5. SPAM was wasting CPU and I/O resources on my system but those resources have been freed for other uses.

Programmatically sending SMTP with ANTI-SPAM enabled

Okay so the problem I am about to describe will not affect most systems but it affected me.

Jumping forward to the fall of 2014

I enabled even more anti-SPAM

A few words on: FTP

Anyone coming to this stack from TCPware or MultiNet will be disappointed. For example, both TCPware and MultiNet support a huge number of logical names which modify the behavior of the FTP server and/or FTP client. By comparison, there are hardly any logical names for FTP on this stack and the ones which do exists are poorly documented.
 
  Title Source TCPIP$FTPD_
UNIX_DISPLAY
1 HP TCP/IP Services for OpenVMS User's Guide (2003) http://h41379.www4.hpe.com/doc/732final/6525/6525pro.html n
2 HP TCP/IP Services for OpenVMS Release Notes (2010) http://h41379.www4.hpe.com/doc/84final/tcprn/tcp_rnpro.html n
3 TCPIP57ECO04.RELEASE_NOTES (2012) http://starlet.deltatel.ru/sys$common/syshlp/TCPIP57ECO04.RELEASE_NOTES y
4 TCPIP57ECO05.RELEASE_NOTES (2014) inspect folder sys$help on your system y

On top of this, the logical names you do find might not do what you think. For example:

A few words on: resolv, NAMEd and BIND

History from a UNIX perspective:

  1. in the earliest days people needed to know the I/P address of their desired destination
  2.  then some kind soul decided to place easy-to-remember names and their equivalent I/P addresses in a local file known as "/etc/hosts"
    • type "man hosts" on UNIX for more information; the man command retrieves online manuals
  3. "resolve" library routines were developed to read this file. These routines were compiled into all the internet apps of the time and still are (more on this a few lines down).
    • type "man resolver" for more information
  4. Since local admins were wasting a lot of time each day updating their local hosts file, a scheme was worked out where changes would be made publically (through a Stanford group called Network Information Center) then periodically downloaded. But as the file size grew larger, and the number of systems needing the file exploded, it became apparent that a dynamic system was required so the formal DNS (domain name system) was developed.
  5. Numerous authors developed name server software which is almost always implemented as named (name daemon). One very popular implementation called BIND (Berkeley Internet Name Domain) beat out all others and it is sometimes implemented locally as either "named" or "bind". The "BIND" acronym is unfortunate because it has nothing to do with "binding to a socket" so will forever confuse search engine results.
  6. At this point the "resolve" library routines were updated so they could also refer to a local name sever (if one exists), or a remote name server (if you have access to one; systems behind a firewall usually do not), or do nothing. Local configuration information was placed in file "/etc/resolv.conf"
    • notice that resolve is spelled with only 6-letters; the 7th character has been dropped.
    • type "man resolver" for more information or lookup RFC-1034 and RFC-1035
    • TOO MANY CHEFS SPOIL THE BROTH? Many systems wanted to, or were required to, coexist with more than one name system (NIS+, WINS, LDAP, etc.). The system-admin configured this functionality in files like:
      •  "/etc/nsswitch.conf" (primarily seen in Solaris)
      • "/etc/svc.conf" (primarily seen in ULTRIX)

Test Tools:

TCPIP Services for OpenVMS 5.7

Examples

maintaining the hosts file on OpenVMS (can't use an editor)

Legend:	<sr>	system response
	<ur>	user response
-------------------------------
<sr>	$							! my DCL prompt
<ur>	TCPIP
<sr>	TCPIP>							! my new prompt
<ur>	show host /local					! what is in the HOSTS file?
<sr>
	     LOCAL database
  
	Host address    Host name
 
	127.0.0.1       LOCALHOST, localhost
	67.69.184.7     NSR_DNS
	207.35.137.66   bellics.com, bellics, KAWC99, kawc99
	207.35.137.65   defaultgate
	67.69.184.83    ns83_kawc99
	67.69.184.84    ns84_kawc99
	67.69.184.87    ns87_kawc99

	TCPIP>
<ur>	set host "yada.ca"/address=207.164.234.128/alias=yada	! add a new entry (quote to preserve case)
<sr>	TCPIP>
<ur>	show host /local					! view changes
<sr>
	     LOCAL database

	Host address    Host name

	127.0.0.1       LOCALHOST, localhost
	67.69.184.7     NSR_DNS
	207.35.137.66   bellics.com, bellics, KAWC99, kawc99
	207.35.137.65   defaultgate
	67.69.184.83    ns83_kawc99
	67.69.184.84    ns84_kawc99
	67.69.184.87    ns87_kawc99
	207.164.234.128 yada.ca, YADA

	TCPIP>
<ur>	set nohost yada.ca					! removing an entry (this is not a joke)
<sr>	TCPIP>
<ur>	show host /local					! view changes
<sr>
	     LOCAL database

	Host address    Host name

	127.0.0.1       LOCALHOST, localhost
	67.69.184.7     NSR_DNS
	207.35.137.66   bellics.com, bellics, KAWC99, kawc99
	207.35.137.65   defaultgate
	67.69.184.83    ns83_kawc99
	67.69.184.84    ns84_kawc99
	67.69.184.87    ns87_kawc99
	TCPIP>

changing name server (BIND) settings

caveats:

  1. TCPIP$CONFIG refers to BIND whilst the TCPIP CLI refers to NAME
  2. If you find BIND too complicated then just leave it disabled in TCPIP$CONFIG and work with the RESOLVER
Legend:	<sr>	system response
	<ur>	user response
-------------------------------
<sr>	$						! this is my DCL prompt
<ur>	TCPIP						! activate the TCPIP command interpretor
<sr>	TCPIP>						! this is my new prompt
<ur>	show config name				! view permanent name_server settings
<sr>
	BIND Resolver Configuration

	  Transport:  UDP
	  Domain:     com
	  Retry:         2
	  Timeout:       2
	  Servers:    67.69.184.87, 67.69.184.7
	  Path:       com
	TCPIP>
<ur>	show name					! view volatile name_server settings
<sr>
	BIND Resolver Parameters
   
	 Local domain: com
  
	 System
   
	  State:     Started, Enabled
   
	  Transport: UDP
	  Domain:    com
	  Retry:     2
	  Timeout:   2
	  Servers:    ns87_kawc99, NSR_DNS
	  Path:       com
  
	 Process
   
	  State:     Enabled
   
	  Transport:  
	  Domain:     
	  Retry:      
	  Timeout:    
	  Servers:     
	  Path: 
	TCPIP>
<ur>	set name /server=yada				! add host "yada" to the volatile name_server
<sr>	TCPIP>
<ur>	show name					! view the changes (went into PROCESS, not SYSTEM) 
 
	BIND Resolver Parameters
   
	 Local domain: com
  
	 System
   
	  State:     Started, Enabled
   
	  Transport: UDP
	  Domain:    com
	  Retry:     2
	  Timeout:   2
	  Servers:    ns87_kawc99, NSR_DNS
	  Path:       com
  
	 Process
   
	  State:     Enabled
   
	  Transport:  
	  Domain:     
	  Retry:      
	  Timeout:    
	  Servers:    YADA
	  Path:        
	TCPIP>
<ur>	exit
<sr>	$

Note: At this point you can do some testing from your (PROCESS) account

<ur>	nslookup ibm.com				! give me the I/P address of ibm.com 
<sr>	Server:  mtrlpq02dnsvp1.srvr.bell.ca		!
	Address:  207.164.234.128 			!

	Non-authoritative answer:			! "non-authoritative" means "from a cache"
	Name:    ibm.com
	Address:  129.42.38.1

	$ 


<ur>	set name /noserver=yada				! remove the yada host from the PROCESS area
<sr>	TCPIP>
<ur>	set name /system /server=yada			! add the yada host to the SYSTEM area of the name server
<sr>	TCPIP>
<ur>	sh name						! view the changes 
<sr> 
	BIND Resolver Parameters
   
	 Local domain: com
  
	 System
   
	  State:     Started, Enabled
   
	  Transport: UDP
	  Domain:    com
	  Retry:     2
	  Timeout:   2
	  Servers:    ns87_kawc99, NSR_DNS, YADA
	  Path:       com
  
	 Process
   
	  State:     Enabled
   
	  Transport:  
	  Domain:     
	  Retry:      
	  Timeout:    
	  Servers:
	  Path:        
	TCPIP>

Caveat: changes must also be in the permanent database in order to survive a reboot
	so repeat the "set name" commands above but use "set config name"

TCPIP v6.0 from VSI

When it comes to computing, newer is almost always better. In March of 2024 I had the opportunity to play with v6.0 from VSI. This product appears much cleaner than 5.7 from HP/HPE. Anyone still running OpenVMS-8.4 would be wise to buy support from VSI then upgrade to OpenVMS-8.4-1H1 or higher, then upgrade to TCPIP v6

External Links

Back to Home
Neil Rieck
Waterloo, Ontario, Canada.