OpenVMS Notes: TCPIP Services for OpenVMS

The information presented here is intended for educational use by qualified OpenVMS technologists.
The information presented here is provided free of charge, as-is, with no warranty of any kind.

Quick-Nav Menu

The name game
TCPIP v5.7 Gotchas
setting up SMTP on 5.7
- This anti-spam module really works
- Programmatically sending SMTP messages with ANTI-SPAM enabled
a few words on: FTP (UNIX feature needs work)
a few words on: resolv, NAMEd, BIND
Examples
- viewing/changing the HOSTS file
- viewing/changing name server settings
OpenVMS External Links

Edit: 2016-01-06 (updated some info about FTP logical names)

The Name Game

This product went by the name UCX ("Unix Communications Services" but was also referred to by the moniker "Ultrix Communications Services") for VMS on VAX.
- All library calls are prefixed with the string "UCX$"
The product was rebranded "TCPIP Services for OpenVMS" around the time OpenVMS was released for Alpha
- All library calls are prefixed with the string "TCPIP$"
- not sure if I've ever seen this product on VAX

TCPIP v5.7 Gotchas

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

TCPIP v5.7 was released on 2010-03-26
ECOs (Engineering Change Orders - major patches)
- ECO1 was released on 2010-06-30
- ECO2 was released on 2011-01-25
- ECO3 was released on 2011-12-08
- ECO4 was released on 2012-10-23
- ECO5 was released on 2014-12-02
however,
- several config files refer you to the manual HP TCP/IP Services for OpenVMS Management which has not been updated since 2006
- 5.7 product release notes and/or ECO release notes (all found in folder sys$help) do not contain information missing from the manual
- in the case of SMTP
  - TCPIP$SMTP.CONF is considerably different than TCPIP$SMTP_CONF.TEMPLATE
  - TCPIP$SMTP_CONF.TEMPLATE refers you to manual HP TCP/IP Services for OpenVMS Management which has not been updated since 2006 (many parameters in this config template are not documented anywhere)
  - as a last resort, the SMTP service does write all configurable parameters to the log file; some of these parameters are not found anywhere (even the confg template)
  - this is the first commercial OpenVMS product I have ever seen which requires you to be Sherlock Holmes just to do the install/config.

2) Config Data Corruption

there are times when:
- an Ethernet port will stop working (reboot will not fix it)
- the script sys$manager:tcipip$config will just bomb out with an error when displaying interface data of a working stack (reboot will not fix it)
- a patch cannot be installed (you will get a PCSI stack-dump during the product install procedure -and- reboot will not fix it)
at this point, use the script sys$manager:tcipip$config to doing a shutdown/disable followed by an enable/restart of the whole stack seems to fix the problem (a simple shutdown followed by restart will not do)

3) Patching is flaky (unpredictable)

this just in (2014.10.03) from another developer producing products for all three IP stacks (TCPware, MultiNet, TCPIP Services for OpenVMS);
he had a customer reporting a problem with TCPIP Services which he could not produce on his system until he played around with the patches
- he was able to produce his customer's problem by doing a fresh install of v5.7 followed by ECO3
- the problem disappeared when he did a fresh install of v5.7 followed by ECO1, ECO2, then ECO3

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

I have used the script to see if either SMTP or BIND were running, and they appeared to be based upon the choices offered by the config script. However, shutting down either one of these services (via the script) produced the message "service already stopped".
- the only way to test stack-managed services is via the cli like so: $tcpip show services (you will not see other binds like Apache on port 80/443 or MySQL on port 3306)
- the only way to test BIND is via the nslookup command which is defined in script: sys$manager:tcpip$define_commands.com
  (and even then you might be using resolv so be careful)
- the only way to test SMTP (provided it was properly configured in the first place) is like this:
  - type: telnet 127.0.0.1 25 ! failure to connect at all means it is not running at all
  - wait for 220 message
  - type: HELO
  - wait for 250 message
  - type: QUIT
update: the config script only remembers that it started a given service so will offer (by menu choices) to shut down things which may not be running. For example:
- use the script to "run the BIND SERVICE" even though you have not configured it. It may appear to start (what you see will depends upon other factors like: whether you have modified files in folders TCPIP$ETC or TCIP$BIND)
- now execute (in DCL) $tcpip show services and notice that BIND is not running
- now use the script menu choice "stop the BIND SERVICE" (confusing message because it is already stopped); as the script runs you will notice the message "already stopped"

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

NTP
- typing $tcpip show service ntp /full reveals that limit=1 (which is a good thing)
- Notice that account TCPIP$NTP is defined in SYSUAF with prior=8. You might wish to take it down to four or lower.
- If NTP hacking persists, permanently close the service then run a batch job every four hours to sync your system with another NTP server. No system I have ever worked on requires the system clock to be this precise.
SMTP
- typing $tcpip show service smtp /full reveals that limit=300. If you have no intention of supporting 300 inbound clients -OR- want to be to survive a DoS attack on this port then I suggest dropping this number to 10
- Notice that account TCPIP$SMTP is defined in SYSUAF with prior=8. You might wish to take it down to four or lower. On one of my systems I set it to 0 (the lowest possible value)
- additional tip: even when enabling anti-spam in your SMTP subsystem, you will constantly be probed by spammers to see how many simultaneous email connections can be opened -AND- how responsive they are. Offering them degraded responses will cause many to probe elsewhere
FTP
- not everyone has an open FTP port on the public internet but typing $tcpip show service ftp /full reveals that limit=1000. Whoa! Drop this down to something more reasonable like 10 or less.
TELNET
- not everyone has an open TELNET port on the public internet but typing $tcpip show service telnet /full reveals that limit=10000. Whoa! Drop this down to something more reasonable like 10 or less.
Services not managed by TCPIP (like Apache HTTPd, MySQL/MariaDB, etc.) need to be managed in their respective config files.

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.

Even on a new installation in 2014, two seemingly incompatible SMTP-related files will be created in folder TCPIP$SMTP_COMMON
- TCPIP$SMTP.CONF
  - which does not work since it is totally different than the template
- TCPIP$SMTP_CONF.TEMPLATE
  - which refers you to the HP TCP/IP Services for OpenVMS Management which has not been updated since 2006
  - 5.7 stack release notes were updated in 2010 but ECO release notes (found in folder sys$help) do not contain all the information you will search for
  - some SMTP config parameters are not mentioned anywhere (not even in the template file) but are written to the specific SMTP log file when the service starts (provided you enabled verbose logging by defining logical TCPIP$SMTP_LOG_LEVEL to 3). You need to be Sherlock Holmes to properly configure this product.
SMTP-TIPS:
1. in file TCPIP$SMTP.CONF be sure to:
  1. configure SPAM-Action: OPCOM
  2. add 127.0.0.1 to the comma-delimited list of Good-clients: (to reduce spam detection on local connections)
2. enter $reply/enable at your terminal session to monitor what the TCPIP-stack writes to your system console when a transaction is rejected
3. despite everything you have read, anti-SPAM is turned on by default and you will need to use $telnet 127.0.0.1 25 to debug your installation attempts.
  Observations:
  - during your inbound SMTP handshake, sending unsupported data on either the MAIL FROM: or RCPT TO: lines may cause the anti-spam module to just close the connection (okay so this is kind of cool)
  - configure Security: FRIENDLY in file TCPIP$SMTP.CONF to reveal more information
4. After local connections to address 127.0.0.1 works properly, repeat the same command from other nodes expected to send mail to your node
  Observations:
  - with Reject-Unbacktranslatable-IP: TRUE in place, you might not be able to connect without an enabled BIND Service (most likely of the caching variety)
    - caveats:
      - some email clouds (google, hot-mail) will send you mail from servers which have no DNS so be very careful when you enable this rule
      - many client apps, like TELNET and FTP, have the resolv library code baked-in. This is not true of most TCPIP services including SMTP. Just because you have nameserver entries defined in TCPIP$RESOLV.CONF which work from TELNET does not mean they will be used by the SMTP Server.
5. now make sure you can send mail out

for your viewing pleasure here is a copy of the file TCPIP$SMTP_CONF.TEMPLATE followed by an abbreviated dump

! File name:      TCPIP$SMTP.CONF
! Product:        HP TCP/IP Services for OpenVMS
! Version:        V5.7
!
! © Copyright 1976, 2007 Hewlett-Packard Development Company, L.P.
!

!
! SMTP server configuration file
!

!
! DESCRIPTION:
!
!    This is a template for the TCPIP$SMTP.CONF file. The TCPIP$SMTP.CONF 
!    file holds SMTP configurable fields.  The real TCPIP$SMTP.CONF file 
!    must reside in TCPIP$SMTP_COMMON directory (SYS$SPECIFIC:[TCPIP$SMTP]  
!    if  you  don't define the TCPIP$SMTP_COMMON logical name yourself).
!
!    HP TCP/IP Services for OpenVMS Version 5.7 onwards, all the SMTP 
!    configurable fields, except the SMTP tracing logical names, supported 
!    in TCPIP$SMTP.CONF file. The TCPIP$SMTP.CONF will support configurable
!    fields for anti-SPAM features, all configuration information stored in
!    TCPIP$CONFIGURATION data file (i.e pre V5.7) from the TCPIP SET/SHOW 
!    CONFIGURATION SMTP command along with the SMTP configuration logical 
!    names. The logical names (other than tracing logical names) and 
!    TCPIP SET/SHOW CONFIGURATION SMTP will be obsolete.
!    
!
! NOTES:
!
!    1. Do not modify this file. It exists for  documentation  purposes  and
!       will be updated periodically in the TCP/IP Services kit.
!
!    2. The field names for each supported field are listed below.  Each one
!       is preceded by three exclamation points.  If you want to  create  an
!       initial TCPIP$SMTP.CONF without the comments from this file do:
!
!         $ SEARCH /OUT=TCPIP$SMTP_COMMON:TCPIP$SMTP.CONF -
!         $_ TCPIP$SMTP_COMMON:TCPIP$SMTP_CONF.TEMPLATE
!
!         Search for three !'s
!
!    3. This template file contains examples  of  each  supported  field; it
!       does not document the purpose of the fields,  their defaults,  their
!       syntax or the way they interact.
!
!    4. Regarding defaults note that all fields that require a default  have
!       one built into SMTP which means that  configurations  which  require
!       all the defaults need not even have an TCPIP$SMTP.CONF file.
!
!    Refer to the HP TCP/IP Services for OpenVMS Management guide  for  more
!    information on the SMTP configurable fields.
!
!
! CONFIGURATION:
!
! Examples for supported fields:
!
!!!Good-Clients:   relay.dec.com, 16.20.0.0/16, 16.20.208.1
!
!!!Bad-Clients: 1.2.3.5, 11.1.0.0/8
!
!!!Relay-Zones: dec.com,
!!!        digital.com,
!!!        compaq.com
!
!!!RBLs: blackholes.mail-abuse.org, dialups.mail-abuse.org
!
!!!Relay-Based-On-Mx: TRUE
!
!!!Reject-Unbacktranslatable-IP: TRUE
!
!!!Accept-Unqualified-Senders:  TRUE
!
!!!Accept-Unresolvable-Domains: TRUE
!
!!!Reject-Mail-From: *.xyz.com, known.spammer@*, *the_internet*
!
!!!Accept-Mail-From: *@notabadguy.xyz.com, the_internet_news@somehwere.com
!
!!!SPAM-Action: OPCOM, ACCOUNTING
!
!!!Security: FRIENDLY
!
! Legal values NEVER, ALWAYS or LOCALLY
!!!Allow-EXPN: NEVER
!
! Legal values NEVER, ALWAYS or LOCALLY
!!!Allow-VRFY: LOCALLY
!
!!!Unbacktranslatable-IP-Text:  Your IP address is unbacktranslatable. SPAMMER!
!!!Bad-Clients-Text:            You dirty SPAMmer.
!!!Client-In-RBL-Text:          I Spotted you in an RBL. SPAMBREATH!
!!!Reject-Mail-From-Text:       Haven't you SPAMmed me before?
!!!Unqualified-Sender-Text:     MAIL FROM who? You've got to be kidding.
!!!Unresolvable-Domain-Text:    MAIL FROM where? Yeah right.
!!!SPAM-Relay-Text:		Trying to launch your SPAM from my site will get you nowhere.
!!!EXPN-Used-Text:              Trying to mine my email lists, eh? Shame!
!!!VRFY-Used-Text:              Usernames on my system are none of your business.
!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! Fields below are not strictly anti-SPAM fields.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!
! If Symbiont-Checks-Deliverability is set to TRUE, the SMTP receiver will not
! check the deliverability of incoming email, passing it to the symbiont to
! check. If Symbiont-Checks-Deliverability is set to FALSE, the SMTP receiver
! will check the deliverability of incoming email and reject it. The default is
! FALSE to allow the receiver to check deliverability.
!
!!!Symbiont-Checks-Deliverability: FALSE
!
! The symbiont will always try to relay outbound mail using the SMTP gateways
! specified in MX records. As an added measure it can also try to relay to hosts
! specified in A records. This switch tells the symbiont when it should try to
! relay an outbound mail using A records. Note that MX records are always used
! and they are always used before A records. The symbiont can be configured
! always to try A records, never to try A records or only to try them if it can
! find no MX records for the recipient's domain. The default is ALWAYS to remain
! consistent with past behavior but a setting of IFNOMX is recommended for
! new installations.
!
! Legal values NEVER, ALWAYS or IFNOMX
!!!Try-A-Records: ALWAYS
!
!!!Initial-Interval              : 0 00:30:00.00
!
!!!Retry-Interval                : 0 01:00:00.00
!
!!!Retry-Maximum                 : 3 00:00:00.00
!
!!!Zone                          : dec.com,hp.com
!
!!!Receive-Timeout               : 5
!
!!!Retry-Address                 : 16
!
!!!Hop-Count                     : 16
!
!!!Send-Timeout-Init             : 5
!
!!!Send-Timeout-Mail             : 5
!
!!!Send-Timeout-Rcpt             : 5
!
!!!Send-Timeout-Data             : 3
!
!!!Send-Timeout-Term             : 10
!
!!!Header-Placement              : TOP
!
!!!Eightbit                      : TRUE
!
!!!Relay                         : FALSE
!
!!!Alternate-Gateway             : MY.ALT.MYZONE.COM
!
!!!General-Gateway               : 
!
!!!Substitute-Domain             : VMS.ZKO.HP.COM
!
!!!Queue-Name                    : TCPIP$SMTP
!
!!!Postmaster-Alias              : Postmaster
!
!!!Receiver-Debug                : 0
!
!!!Receiver-Trace                : 0
!
!!!Symbiont-Debug                : 0
!
!!!Symbiont-Trace                : 0
!
!!!Utilities-Debug               : 0
!
!!!Utilities-Trace               : 0
!
!!!Log-Level                     : 0
!
!!!EF-Debug-Level                : 0
!
!!!Channel-Debug-Level           : 0
!
!!!Symbiont-Snapshot-Blocks      : 0
!
!!!Receiver-Snapshot-Blocks      : 0
!
!!!Utilities-Snapshot-Blocks     : 0
!
!!!Log-Line-Numbers              : TRUE
!
!!!Memory-Debug                  : TRUE
!
!!!Mail$Protocol-Debug           : TRUE
!
!!!CF-Debug                      : TRUE
!
!!!Parse-Debug                   : TRUE
!
!!!Altgate-Always                : TRUE
!
!!!Mx-If-Noaltgate               : TRUE
!
!!!No-Mx                         : TRUE
!
!!!No-Subs-Domain-Inbound        : TRUE
!
!!!Smtp-Jacket-Local             : TRUE
!
!!!Cent-Sign-Hack                : FALSE
!
!!!Nosey                         : TRUE
!
!!!Deliver-NoXVMS                : TRUE
!
!!!Deliver-VMS-Def-To            : TRUE
!
!!!MTS-From-Hack                 : TRUE
!
!!!Rewrite-MTS-From              : TRUE
!
!!!Local-Alias-Only              : TRUE
!
!!!SFF-Requires-Priv             : TRUE
!
!!!8BitMIME-Hack                 : TRUE
!
!!!Suppress-Version-Info         : TRUE
!
!!!Foreign-Transport-Synonyms    : FALSE
!
!!!Postmaster-Forwards-To        : FALSE
!
!!!Persistent-Server             : OFF
!                                
!!!Idle-Timeout                  : 0 00:01:00.00
!
!!!Loop-Max                      : 10
!

The next 70 lines were extracted from the SMTP service log file (v5.7 ECO4) with log level set to 3. Notice that many parameters are not documented anywhere. One of the parameters displayed here is called "Symbiont-Checks-Deliverability" but is documented as "Symbiont-Checks-Delivery" in the manual. Happy hacking!

%%%%%%%%%%%%                   18-NOV-2014 07:27:53.35  %%%%%%%%%%%%
%TCPIP-I-SMTP_LOGSUC, using log file TCPIP$SMTP_COMMON:TCPIP$SMTP_KAWC98.LOG

TCPIP SMTP configuration data:
Server-Nodes                  : KAWC98
Queue-Name                    : TCPIP$SMTP
Alternate-Gateway             : 
General-Gateway               : 
Substitute-Domain             : 
Zone                          : 
Postmaster-Alias              : Postmaster
Postmaster-Forwards-To        : SYSTEM
Foreign-Transport-Synonyms    : 
Smtp-Dis-Dir                  : TCPIP$SMTP_COMMON:
Initial-Interval              : 0 00:30:00.00
Retry-Interval                : 0 01:00:00.00
Retry-Maximum                 : 3 00:00:00.00
Idle-Timeout                  : 17-NOV-1858 00:00:00.00
Persistent-Server             : FALSE
Loop-Max                      : 0
Receive-Timeout               : 5
Retry-Address                 : 16
Hop-Count                     : 16
Symbiont-Snapshot-Blocks      : 0
Receiver-Snapshot-Blocks      : 0
Utilities-Snapshot-Blocks     : 0
Number-Of-Queues-Per-Node     : 1
Send-Timeout-Init             : 5
Send-Timeout-Mail             : 5
Send-Timeout-Rcpt             : 5
Send-Timeout-Data             : 3
Send-Timeout-Term             : 10
Log-Level                     : 3
Receiver-Debug                : 0
Receiver-Trace                : 0
Symbiont-Debug                : 0
Symbiont-Trace                : 0
Utilities-Debug               : 0
Utilities-Trace               : 0
EF-Debug-Level                : 0
Channel-Debug-Level           : 0
Header-Placement              : TOP
Eightbit                      : FALSE
Relay                         : FALSE
Altgate-Always                : FALSE
Mx-If-Noaltgate               : FALSE
No-Mx                         : FALSE
No-Subs-Domain-Inbound        : FALSE
Smtp-Jacket-Local             : TRUE
Cent-Sign-Hack                : TRUE
Percent-Sign-Hack             : FALSE
Nosey                         : FALSE
Log-Line-Numbers              : FALSE
Memory-Debug                  : FALSE
Mail$Protocol-Debug           : FALSE
CF-Debug                      : FALSE
Parse-Debug                   : FALSE
Deliver-VMS-Def-To            : FALSE
Deliver-NoXVMS                : FALSE
MTS-From-Hack                 : FALSE
Rewrite-MTS-From              : FALSE
Local-Alias-Only              : FALSE
Relay-Based-On-Mx             : FALSE
Reject-Unbacktranslatable-IP  : FALSE
Accept-Unqualified-Senders    : FALSE
Accept-Unresolvable-Domains   : FALSE
SFF-Requires-Priv             : FALSE
8BitMIME-Hack                 : FALSE
Suppress-Version-Info         : FALSE
Symbiont-Checks-Deliverability: FALSE
Try-A-Records                 : IFNOMX

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.

We have a common mailer which we have been using for more than a decade with another stack.
This program (call it: ABC) sends out SMTP email on behalf of three other programs (call them: DEF, GHI, JKL). ABC must craft email with FROM and REPLY-TO addresses based upon the message source (eg: DEF@YADA.COM or GHI@YADA.COM or JKL@YADA.COM)
Back in the day, this common mailer sent mail directly to port-25 of the desired destination but ran into problems a few years ago when anti-spam changes elsewhere required we connect to the MX-destination rather than the A-destination (at that time we were only doing gethostbyname but did not have the time to rewrite the code to emulate NSLOOKUP with querytype=MX)
So the app was quickly pointed to port 25 of the local loopback address (127.0.0.1) which allowed the stack to do the MX lookup.

Jumping forward to the fall of 2014

We installed TCPIP Services for OpenVMS then noticed we could not send outbound email to to loopback address when anti-SPAM features were enabled (they are enabled by default)
Even after if I placed 127.0.0.1 in the GOOD-CLIENTS list, these emails were being treated as an unauthenticated connection (at least with ECO4) then run through anti-SPAM where it was stopped by rule "RELAY: FALSE"
We needed to run with "RELAY: TRUE" for a week until a fix could be introduced. There were two approaches available:
- fix-1 involves adding code to the program so it can simulate an NSLOOPUP with querytype=MX. I wrote and tested the code but did not turn it up because this program was becoming too complex (my efforts can never be as robust as the code found in TCPIP Services for OpenVMS and why reinvent the wheel?)
- fix-2 involved leveraging code found in TCPIP Services for OpenVMS by linking to the stack (at run-time) then calling entry label TCPIP$SEND_FROM_FILE
  - demo in BASIC: sff_demo.bas
  - demo in C: sff_demo.c
  - for people wishing to use this technique from DCL, you only need to declare a foreign command like so:
    SMTP_SFF :== $TCPIP$SYSTEM:TCPIP$SMTP_SFF.EXE
    then invoke the program like so:
    SMTP_SFF infile_name [-log logfile_name] [-loglevel log_level]

I enabled even more anti-SPAM

If you want to thwart the efforts of the few idiots out their who think they can get rich by spamming then consider these settings in TCPIP$SMTP.CONF

Rules		Notes
Reject-Unbacktranslatable-IP	TRUE	rejects any mail from an SMTP client whose IP address cannot be backtranslated to a hostname
Accept-Unresolvable-Domains	FALSE	reject mail where the sender address (from the MAIL FROM command) has a domain that cannot be resolved using MX lookup
Allow-EXPN	NEVER	Don't allow probing
Allow-VRFY	NEVER	Don't allow probing
Relay	FALSE	Don't agree to forward to another destination
Relay-Based-On-Mx	false	Don't agree to forward to another destination even if MX tests pass

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:

TCPIP$FTPD_UNIX_DISPLAY does not make your file system to appear look like UNIX. It's only job is to remove the annoying carets found in some long filename displays. There are some clients out there (Microsoft .NET stuff comes to mind) which require your VMS server to appear to look like a UNIX server so good luck with that situation. I would like a logical which will force the display to look like this:
```
drwxrwxrwe my-folder/
drwxrwxrwx  1 commsvcs      226     1234 Nov  1 08:05 FOLDER1
-rwxr-x---  1 commsvcs      226    15027 Nov 18 09:42 YADA.txt
-rwxr-x---  1 commsvcs      226        0 Dec  2 17:36 YADA.LOG
```
TCPIP$FTP_NO_VERSION drops the file version number only if the connected client is not an OpenVMS system
I recently encountered some difficulty FTPing certain ASCII files to a system running TCPIP Services. This is the error message which comes back from the FTP server:
!UL byte record too large for user's buffer
This problem can be fixed (at least with ECO5) by shutting down the FTP server then defining this logical name like so:
```
	$define/sys TCPIP$FTP_STREAMLF 1			! remember to restart the server

	but you must not have defined:
		TCPIP$FTP_COMPAT_REV "5.1"
		TCPIP$FTPD_COMPAT_REV "5.1" 
```
These logical names will make uploading a little more efficient -and- are not deleted when the FTP server process is shut down
```
	$def/sys/exec    tcpip$ftp_file_alq      100		! NSR - 2015-11-26
	$def/sys/exec    tcpip$ftp_file_deq      100            ! ''
```

Verifying logical names

first
	$set def sys$disk:[SYS0.SYSCOMMON.SYSEXE]
then
	$search tcpip*ftp*.exe tcpip$ftp
or
	$dump TCPIP$FTP_CHILD.EXE/out=neil.txt
	$edit neil1.txt
or
	$dump TCPIP$FTP_SERVER.EXE/out=nei2.txt
	$edit neil2.txt

A few words on: resolv, NAMEd and BIND

History from a UNIX perspective:

in the earliest days people needed to know the I/P address of their desired destination
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
"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
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.
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.
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:

nslookup (name server lookup)
- has been the defacto test tool since the earliest days of DNS
- it usually has no built-in help (not true on Windows) so you need to refer to system documents (type "man nslookup" on UNIX)
- was deprecated by ISC in 2012 but undeprecated in 2014. Read on to see why.
dig (domain information groper )
- I am not aware of this program being available before BIND-9 which was first released in October-2000.
- dig is the better tool but can be dangerous in the hands of Dilbert's boss. Why? When dig finds no useful way of getting off your system it will resort to a baked-in list of root servers. It will tell you this but you need to read every text line in the display (something the pointy-haired boss won't do). So this tool will actually appear to work even though other apps (like telnet and ftp) will not.

TCPIP Services for OpenVMS 5.7

I have no experience with this stack before v5.7 but it appears to me that previous VMS authors did not want to employ configuration files at all. You were required to use the DCL command "TCPIP" to manage data stored in proprietary data files (can't be maintained with a plain text editor)
Almost all stacks from all vendors begin with code from ISC. This means that adding VMS-specific changes may be costly while also unnecessary
v5.7 offers a hybrid setup (sort of).
- You can use TCPIP for everything
- You can use flat-files (so-called ASCII configuration) for most (but not all) things
- In the case of the built-in resolver, it appears to become confused with any previous attempts to play with config files in folders TCPIP$BIND (if it exists) or TCPIP$ETC
- For example, if you configured the resolver with "script TCPIP$CONFIG" or "DCL command TCPIP" then you may find that your efforts are being functionally overridden by any previous hacking you might have done in the flat files. If this happens, delete (or rename) any files in these folders with an extension of ".config"
- If you are using config files then do yourself a favor by making sure equivalent entries are not present via the TCPIP interface (this recommendation will only reduce future confusion)
- Script TCPIP$CONFIG allows you to only add or modify resolver information. However, some things may only be deleted using the TCPIP interface
- There are no flat-file equivalents of "/etc/hosts" so you must make changes via the TCPIP interface.
- Config files are only read when the associated feature is restarted.
- CAVEAT:
  - most changes made to the running system via the TCPIP interface are not permanent unless you enter them twice.
    - tcpip set name" and "tcpip show name" deal with volatile information associated with the name_server
    - tcpip set config name" and "tcpip show config name" deal with permanent information associated with the name_server (seen after the next stack restart or system reboot)
  - this is not true when modifying the HOST file
I have no experience (yet) with the command TCPIP CONVERT but believe it may be the best way to move between UNIX-style and VMS-style configurations.

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:

TCPIP$CONFIG refers to BIND whilst the TCPIP CLI refers to NAME
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"

External Links

Back to Home
Neil Rieck
Waterloo, Ontario, Canada.