Edit: 2024-03-31 (added a blurb about
TCPIP v6.0)
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 by HP 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 (40 lines) is considerably different than TCPIP$SMTP_CONF.TEMPLATE (240 lines)
- 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.
6) Where to locate missing template files
$set def sys$library ! change default directory
$ lib/list TCPIP$TEMPLATES.TLB
Directory of TEXT library SYS$COMMON:[SYSLIB]TCPIP$TEMPLATES.TLB;1 on 20-JAN-2025 14:37:32
Creation date: 8-NOV-2014 12:08:15 Creator: Librarian I01-37
Revision date: 8-NOV-2014 12:08:16 Library format: 3.0
Number of modules: 40 Max. key length: 39
Other entries: 0 Preallocated index blocks: 11
Recoverable deleted blocks: 0 Total index blocks used: 4
Max. Number history records: 20 Library history records: 20
CLIENT_PCY
DHCPCAP
DHCPTAGS
FAILSAFE_CONFIG
IPNODES
IPSEC_CAINFO
IPSEC_EXAMPLE_XML
IPSEC_PROFILE
LOCALHOST_DB
LOOPBACK_DB
LPD_CONF
NAMED_CONF
NAMEPOOL
NETMASKS
NETS
RESOLV_CONF
RNDC_CONF
ROOT_HINT
SERVER_PCY
SERVICES
SSH2_CONFIG
SSHD2_CONFIG
SYSCONFIGTAB
TCPIP$EXTENSION_MIB_RUN
TCPIP$EXTENSION_MIB_SHUTDOWN
TCPIP$EXTENSION_MIB_STARTUP
TCPIP$GATED
TCPIP$IMAP_CONF
TCPIP$IMAP_MAGIC_TXT
TCPIP$LBROKER_CONF
TCPIP$NTP_CONF
TCPIP$POP_CONF
TCPIP$PRINTCAP_DAT
TCPIP$SMTP_CONF
TCPIP$VMS_SNMP_CONF
XDM_CONFIG
XDM_KEYS
XDM_XACCESS
XDM_XSERVERS
_DDNSKEYS
$
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 SMTP-related files will be created in folder TCPIP$SMTP_COMMON
- TCPIP$SMTP.CONF (40 lines)
- which is missing some stuff since it is derived from TCPIP$SMTP_CONF.TEMPLATE (any lines with three exclamation characters was not copied)
- TCPIP$SMTP_CONF.TEMPLATE (240 lines)
- 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:
- in file TCPIP$SMTP.CONF be sure to:
- configure SPAM-Action: OPCOM
- add 127.0.0.1 to the comma-delimited list of Good-clients: (to reduce spam detection on local connections)
- enter $reply/enable at your terminal session to monitor what the TCPIP-stack writes to your system console when a transaction is rejected
- 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
- 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.
- 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, [email protected]
!
!!!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: [email protected] or [email protected] or [email protected])
- 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.
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"
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.