Subject: UCX FAQ - DEC TCP/IP Services for OpenVMS Frequently Asked Questions
Nntp-Posting-Host: terwed.si.com
Date: Thu, 4 Jan 1996 09:04:41 GMT

Posting-Frequency: monthly
Version: 3.18

[Administrative note: The file will be posted to the vmsnet.networks.tcp-ip.ucx
newsgroup with an expiration date 2 months from the date of posting. When a new
version is released (usually monthly) the old version will be superseded by the
new one. This should keep the FAQ as the first post in the newsgroup listing
for the majority of sites.]

[IMPORTANT NOTE:  It should not be construed that the authors of this FAQ
are experts on DEC TCP-IP Services for OpenVMS.]

*******************************************************
*..... .      *
*   Answers to Frequently asked questions about UCX   *
*......      *
*******************************************************

This post contains Part 1 (currently the only part) of the UCX FAQ. It will
be posted to vmsnet.networks.tcp-ip.ucx and news.answers monthly.

Changes to this FAQ will be marked with vertical bars (or whatever passes for
a vertical bar on your display) like this:

| This is a sample changed section.

Change bars will also be placed on the corresponding entry in the table of
| contents so that it's easier to know where the changes are.  This suggestion
came from Mike Davis (davism@KCGL1.eng.ohio-state.edu).

This document contains "Frequently Asked Questions" (or FAQ for short) about
DEC TCP/IP Services for OpenVMS, also known as UCX, from an earlier version.
Answers (hopefully correct ones, even) are also included. There is a table of
contents, followed by the actual questions and answers.

Many common questions about UCX are answered in this document, it would be a
good idea to read it to see if your question has already been answered before
posting to the UCX newsgroup.  We monitor the related newsgroups for
UCX-related questions and answers, and add them to this document when
appropriate.  Updates will be posted approximately every month.

If you have additional information or corrections to any of the items in this
FAQ, feel free to send them to to one of the FAQ maintainers for inclusion
in the next version.  See the end of this file for their addresses. Please
indicate in your message that you are submitting an item for the UCX FAQ.

This file is also available via FTP from ftp.spc.edu (192.107.46.27) in the
[.ucx] directory as ucx-faq.txt

CONTENTS

     1. General Information
.1.1) What is UCX?
|.1.2) What is the current version?
.1.3) What patches are available and what are they for?
.1.4) What new features are in the current release?

     2. Included Utilities
.2.1) Why isn't <favorite utility> included?
.2.2) Why doesn't UCX FTP support STRU VMS?
.2.3) Why doesn't UCX V1.3 FTP work with "new" Unix FTP servers?
.2.4) Why doesn't UCX Telnet have a 3270 mode?
.2.5) Why isn't a BIND server included?
.2.6) Why isn't SLIP/PPP included?

     3. Other Utilities
.3.1) What add-on utilities are available?
.3.2) PING
 .3.3) SMTP mail
.3.4) NSLOOKUP
.3.5) RLOGIN
.3.6) TALK
.3.7) LPR
.3.8) POP server
.3.9) Archie client
.3.10) IRC client
.3.11) Empire client
.3.12) NNTP clients and servers
.3.13) WHOIS
.3.14) Finger
.3.15) TRACEROUTE
.3.16) Gopher
.3.17) NTP (Network Time Protocol)
.3.18) FTP
 .3.19) HTTP and WWW
.3.20) NETLIB

     4. Programming
.4.1) Where is the programming documentation?
.4.2) Why don't routines like getprotobyname() work?

     5. Common Problems and Solutions
.5.1) Why can't non-privileged users do <X>?
.5.2) What is the UCX security patch for?
.5.3) How can I disable incoming Telnet access
.5.4) Why is Auxiliary Server (inetd) startup so slow?
.5.5) Why doesn't Anonymous FTP work?
.5.6) How do I add proxies in a cluster?
.5.7) How do I set up a BIND server?

     6. NFS (Network File System)
.6.1) Where can I get an NFS client (as opposed to a server) for UCX?

1. General Information.

1.1) What is UCX?

  UCX ("DEC TCP/IP services for OpenVMS") is a package from Digital Equipment
Corporation (DEC) which provides connectivity between VAX and AXP systems
running OpenVMS and other systems running the TCP/IP protocols. The name UCX
is based on a former name of this software, VMS/Ultrix Connection and is now
based on the prompt "UCX>" of the control program.  The former name implied
that it was for connecting Ultrix systems to VMS systems and originally, that
was its purpose.  However, since it also works with other TCP/IP
implementations Digital elected to change the name.  Because it is a DEC
product available under the Campuswide Software License Grant (CSLG) program
to qualifying schools and because it comes bundled with many VMS-supported
systems as part of the NAS packages, it enjoys a large popularity.

1.2) What is the current version?

  UCX V4.0 was released in November of 1995 for both OpenVMS VAX and OpenVMS
AXP and is available on the current Consolidated Distribution disks.  The most
| recent prior version was V3.3 for AXP and VAX.  The new features and
| corrections listed in the release notes are as follows:
|
|      o Support for RFC 1112 IP multicasting
|      o BIND server cluster load balancing
|      o BIND server well-known services support
|      o BIND server round-robin scheduling
|      o New management commands and qualifiers for the above
|      o Sun RPC calls (RPCXDR, RPCGEN)
|      o DECthreads-safe socket library
|      o FTP SET ERROR_LEVEL command
|      o TELNET /CREATE_SESSION and /DELETE_SESSION qualifiers
|      o The CREATE DIRECTORY and CREATE CONTAINER commands now work properly
|      o The BIND server commands SHOW NAME/STATISTICS and SHOW NAME/QUERY
|        now work correctly
|      o No more ACCVIO from the BIND resolver when no BIND servers were
|        defined
|      o OPCOM and errorlog messages are no longer disabled when a directory
|        is NFS-exported to the world
|      o The NFS client now sees local directories faster
|      o The NFS client no longer requires GRPPRV when accessing a file owned
|        by a same-group user when group access is enabled
|      o ADF deletion for rmdir of NFS-mounted directory now works
|
| Restrictions in UCX V4.0 are:
|
|      o The logical name UCX$NTP_TZ must be defined prior to starting NTP.
|      o DELETE/ENTRY used on a TELNETSYM queue can cause the queue to hang
|        on occasion.  STOP/RESET will fix it
|      o SMTP mail does not correctly set the CC header for outbound mail.
|      o SMTP does not work correctly when local and remote addresses are mixed
|        at the To: prompt.  Keep like addresses together as in
|
|        To: local1,local2,smtp%"remote1@domain1,remote2@domain2"
|              or
|        To: smtp%"local1,local2",smtp%"remote1@domain1,remote2@domain2"
|
|      o Two additional questions may be asked after installation procedure
|        states "More more questions will be asked."
|      o BACKUP/VERIFY may issue spurious messages with NFS using VMS-to-VMS
|        mode
|      o Using CMS on NFS-mounted libraries is not recommended
|      o You cannot MAP remote files with UCX for use by OpenVMS POSIX.
|      o If you supply incorrect remote information to RCP, the resulting
|        error message is unpredictable
|      o The SET NOROUTE comman doesn't accept partial wildcards
|      o Services must be disabled and re-enabled in order for SET SERVICE
|        changes to take effect
|      o DISABLE SERVICE, in general, does not stop existing processes
|      o You cannot compile Sun RPC programs with VAX C.

1.3) What patches are available and what are they for?

|   There are no ECOs at this time for UCX V4.0.  There is one ECO kit
available from Digital for UCX V3.3.  The kit is named UCXECO6-033 and there
are separate savesets for ther VAX and Alpha versions.

  The problems fixed by this ECO that were not addressed in the prior ECO are:

    o Crash during shutdown for improperly defined SLIP interface
    o ReadS simetimes wouldn't complete if packets arrived out of order
    o Too many ARP messages
    o Crash in security driver when using the local interface
    o Crashes in PWIP
    o UCX SHOW MX didn't always show all MX records
    o Incorrect setting of terminal attributes in TELNET negotiation
    o Crash in TNDRIVER
    o TELNET/NOINTERACTIVE didn't operate properly in some cases
    o Exiting TN3270 with CTRL-Z left CTRL-T and CTRL-Y disabled
    o Crash caused by wrong broadcast mask for SET CONFIG INTERFACE
    o Permanently defined CLUSTER_TIMER was lost after UCX restart
    o Intermittent bad status returned from select()
    o Infinite loop in TFTP
    o BOOTP droped request when non-existent file specified

  There is one ECO kit available from Digital for UCX V3.2.  The kit is
named UCXECO8-032 and there are separate savesets for the VAX and AXP
versions.  It is available as a patch kit via DSNlink's INVOKE_FUNCTION.  The
Colorado Springs Customer Support Center (CSC) has also issued several ECO
kits for previous versions of UCX.  Since Digital makes an effort to include
all known bug fixes in each release of this product, you are strongly
encouraged to upgrade to the current version and apply the appropriate ECO
kit.  Version V3.1 had ECOs up to ECO 14, also avbilable as a patch kit.  The
kit is named UCXECO14-031 and is available via DSNlink's INVOKE_FUNCTION.
Search for "DEC TCP/IP Services for OpenVMS V3.1" in the ECO-SUMMARY
database.  This patch kit incorporates all ECOs for UCX V3.1.

** NOTE: When you install any of these ECOs, you should shut UCX off before
installing and you must reboot immediately afterward. **

  The following is provided merely for historical purposes.  Believe me, the
current version of UCX is much better and less buggy than any previous
version.  You really ought to upgrade if you're not running it.

  If you are still running V1.3 of UCX for VAX, the cumulative patch kit is
CSCPAT_0903xxx, where xxx is the version number which changes. The latest
version is 019, meaning release 1.9 of the patch kit.  This brings UCX V1.3
to V1.3B.

  For sites running UCX V2.0 for VAX, there is one patch kit currently
available.  It is:

 o CSCPAT_0908xxx, currently V1.2, V2.0E cumulative release

  For sites running UCX V3.0 for AXP, there is also a patch kit currently
available.  It is:

 o CSCPAT_0909xxx, currently V1.4, V3.0-16E cumulative release.

  Other patches that may apply to sites running UCX are as follows:

 o CSCPAT_0269xxx, currently V2.8, Volume Shadowing for OpenVMS VAX V5.4-1
   through V5.5-2.

 o CSCPAT_0408xxx, currently 1.0, DEC Rdb V5.1, SQL/Services V5.1 for OpenVMS
   VAX V5.4 and up.

 o CSCPAT_0552xxx, currently V2.2, Ethernet drivers for OpenVMS VAX 5.4-3
   through V5.5-2 (but _not_ V5.5-2HF, -2HW, or -2H4).

 o CSCPAT_1113xxx, currently V1.1, I/O Routines for OpenVMS VAX V6.0.

 o CSCPAT_1121xxx, currently V1.0, DECwindows transport for OpenVMS VAX V5.4-3
   through V6.0.

 o CSCPAT_3035xxx, currently V1.2, Pathworks for DOS V4.2.

 o CSCPAT_3061xxx, currently V1.2, Pathworks for DOS (TCP/IP) V2.0.

 o CSCPAT_3081xxx, currently V1.3, Pathworks for OpenVMS V4.2.

 o CSCPAT_3109xxx, currently V1.1, DEC Mailworks Server for OpenVMS V1.2.

 NOTE: Never apply any patch unless you _know_ it applies to your site.

  On occasion Digital doesn't have DSN ITS / DSNlink articles written for all
of the patches that may apply to a product.  You have to "discover" them in
DSN VTX or by calling the CSC.  Also note that they may not have the keyword
"UCX" attached, so you should search using the keyword "TCP" as well.

  If you have telephone support, you are probably entitled to these patches.
If you have an "access number" for the CSC, you can contact them to order the
patch kit. UCX V2.0E for VAX is also on the May, 1994 OpenVMS VAX
Consolidated CD.

  There are a number of bugs in the V1.3 base kit, some of which will allow
nonprivileged users to crash your system.  You are strongly urged to acquire
and install the patch kit or upgrade to V3.3 if you haven't already.

1.4) What new features are in the current release?

  You can obtain product information from the SPD (25.A4.06 for VAX,
46.46.02 for AXP) in a variety of ways:

  o  DEC's Electronic Connection, DSIN/DSNlink, and the Digital
     Reference Service.  

  o  Anonymous FTP to ftp.digital.com; the file name is
     pub/Digital/info/SPD/46-46-02.txt

  o  World Wide Web; the URL is
     file://ftp.digital.com/pub/Digital/info/SPD/46-46-02.txt

  Note that the latter two methods currently contain only the SPD for AXP.
Digital will add the SPD for VAX soon, which differs only in the list of
supported hardware. 

  The following new features and enhancements are in UCX V3.2.

  o  NFS Client

  o  Anonymous FTP

  o  Default /LOWERCASE for RSH and RLOGIN usernames

  Also, The following new features and enhancements are in UCX V3.3.  The
SPDs for this version are 25.A4.07 for VAX and 46.46.03 for AXP.

  o  On-demand termination of TCP connections with UCX DISCONNECT

  o  SLIP and CSLIP

  o  VMS-aware NFS, that supports all VMS file types and VMS file naming
     conventions for NFS clients mounting V3.3 NFS-served files.

  o  NTP

  o  Default case insensitivity for RSH and RLOGIN usernames.

  o  Incoming RLOGIN proxies (available but unsupported)

  o  Multiple TELNET sessions

  o  TCPIPTRACE DCL command

  o  Outbound TELNET pseudo-devices (available but unsupported)

  o  RCP (available but unsupported)

2. Included Utilities

2.1) Why isn't <favorite utility> included?

  Good question.  Early versions of UCX seemed to contain only the features
necessary to interact with Ultrix systems.  Some of the missing features were
added in V2 of UCX, like TRACEROUTE and SNMP.  Others have been added in the
current versions.  Digital states that it desires to add the most requested
features found in other commercial TCP/IP implementations.  Still other
features are available from various FTP sites (see below).

2.2) Why doesn't UCX FTP support STRU VMS?

  First, STRU VMS is an extension to the FTP protocol which was developed by
TGV, Inc. (makers of another TCP/IP package for VMS called MultiNet).  It
allows two systems that support the STRU VMS extension to transfer arbitrary
VMS file types. Normal FTP only has two modes, text and binary, which means
that "complex" VMS file types such as .OBJ and RMS indexed files cannot be
transfered. You can always insert these files into BACKUP savesets, which
can then be transfered in binary mode.

  Note that such files will be received with a record size of 512, which
VMS BACKUP won't like. You can use any of the record attribute changers,
such as Joe Meadows' excellent FILE utility, to reset the record size.

  V2.0's FTP ECO 1 and later include a mode called "VMS Plus" which, according
to Digital, produces somewhat faster file transfer by allowing the receiving
system to preallocate file lengths and buffer storage.  This is a negotiated
mode and does not look at all like it is be compatible with the format used
by TGV's MultiNet and others.  Moreover, on occasion, it can cause connection
problems with systems that do not understand the negotiations.  In these
cases it can be disabled with the FTP command DISABLE VMS_PLUS.

  Further studies using a version which reports itself as "X3.0", supplied
by the CSC, seem to indicate that there are actually two modes involved,
one of which retrieves a file called filename.typeFDL when you say GET/FDL,
and then uses the FDL to format the retrieved filename.type. This has the
advantage that the server system doesn't have to be running UCX, it just
has to have the FDL file. This means that (theoretically) you could use
this with a Unix server. The other mode appears to pass the FDL information
along with the file, similar to STRU O VMS in MultiNet and others. Unfor-
tunately, UCX doesn't seem to interoperate with this widely-accepted stan-
dard, instead using some UCX-specific method. As there are far more STRU O
VMS-aware anonymous FTP servers than UCX anonymous FTP servers, this seems
to be a disservice to the UCX user base.  However, Digital is considering
inclusion of this option in a future release.

  Also note that the V2.0B FTP client generates some messages which are
not present in the shipped UCX message file - apparently DEC forgot to
update the kit's message file.  I'm told by a source in Digital that this has
been fixed in the current version.

2.3) Why doesn't UCX V1.3 FTP work with "new" Unix FTP servers?

  A new version of the Unix FTP server has been showing up at popular archive
hosts. It generally identifies itself as version 6.something. By default, it
generates long multi-line responses which confuse the UCX FTP client. At most
sites, when you give the anonymous username and are prompted for a password,
entering a dash "-" in front of your network address will instruct the server
to use the older mode. You may miss some important messages when doing this,
however.

  This problem has been corrected in V2 of UCX. It may be fixed in the V1.9
patch kit for UCX V1.3.  By the way, the ftp.spc.edu server now emits
multi-line messages, so you'll need to upgrade to V2.0 or do the dash thing
there as well.  The best thing to do is upgrade to the current version.

  There is also a freely available FTP client and server from MadGoat software
(ftp.wku.edu) that will work with and provide identical functionality to not
only UCX, but Multinet, TCPware, CMUIP, and Pathway Access which may address
this problem.

2.4) Why doesn't UCX Telnet have a 3270 mode?

  Actually, it now does.  A TN3270 emulator is part of UCX V3.1, but has been
included unannounced in the V2.0E patch kit.  I've used it.  It seems to work
well.

2.5) Why isn't a BIND server included?

  Actually, it now is.  Previous versions, however, did not, probably due
to the fact that it wasn't needed for connecting VMS and Ultrix systems.
If you run a previous version, the BIND client allows you to use a Unix box
to provide name service to the UCX systems.  Also, if you are connected to
the Internet, it is likely that your regional service provider can supply
name service for you.  For information on how to set up a name server, see
section 5.7.

2.6) Why isn't SLIP/PPP included?

  Actually, as of V3.3, UCX does support SLIP and CSLIP.  However, one can
speculate that since there are so many, low-cost communications servers
available that have SLIP/PPP built in, that it would be more efficient to
use one of them to do the job, rather than having your VAX or AXP do it.
Telebit, Digital, Xyplex, and other companies sell communications servers
that have SLIP/PPP capability and that interoperate with UCX just fine.

3. Other Utilities

3.1) What add-on utilities are available?

  Due to the missing pieces in UCX, many sites have ported parts of the Berk-
eley Unix tools to UCX or written replacements from scratch. Here is a list
of the known tools. If you have additional info on any of these, please write
so it can be added to the list.

3.2) PING

  PING is used to test if a TCP/IP host is alive, by sending echo request
packets to it.  The current version of UCX contains PING.

  PING is a relatively easy port from BSD to UCX. One such port was done by
William P. Bame, <bill@office.ab.umd.edu>. This port is available from the FTP
server at ftp.spc.edu in file [.ucx]ping.bck.

  Larry Horn <hornlo@okra.millsaps.edu> writes: "For those who for whatever
reason (policy, etc.) cannot get, or don't want to fool with the port, UCX
offers this:

.$ PING == "UCX LOOP"
.$ PING ftp.spc.edu
.%UCX-I-LOOPACT, FTP.SPC.EDU is alive

Selden E Ball Jr <SEB@lns592.lns.cornell.edu> notes that UCX PING/NUMBER=n
hostname will report statistics similar to the Unix ping command.  Steve Anich
<anich@sicdes.dnet.etn.com> reports that SYS$SYSTEM:UCX$PING.EXE must be
installed with OPER privilege if non-privileged accounts are to be able to
use it.

3.3) SMTP mail

  UCX V2.0 and V3.x include a basic SMTP interface. If you are looking for
support for multiple transports (such as UCX and BITNET, UCX and UUCP, etc.)
then you will probably want to consider one of the following packages as well.

  UCX V1.3 does not include any native facilities for handling the transport
of mail over TCP/IP links. There are at least two packages that implement mail
with UCX. The first is a commercial package from Innosoft, called PMDF. For
more information, contact them at:

.Innosoft International, Inc.
.1050 East Garvey Avenue South
 .West Covina, CA 91790
.(818)919-3600
.(818)919-3614 (FAX)
.service@innosoft.com

  The second package is non-commercial, and was written by Matt Madison of TGV
and now offered by MadGoat Software, a software company composed of Matt and
Hunter Goatley of Western Kentuky University.  It is called MX (or Message
eXchange) and is available via anonymous FTP from ftp.spc.edu and
ftp.wku.edu.  It is also available on various DECUS Program Library tapes.

  Both of these packages support various additional transports and provide
extra utilities such as mailing list management and file distribution.

  A number of users have written suggesting various ways to gateway SMTP
mail with UCX. However, as they have all noted, there are problems with the
UCX native SMTP support.  Users may want to consider one of the above packages
if reliable SMTP gatewaying is needed.

[editor note:  The current version's SMTP appears to be more stable than
prior versions.]

3.4) NSLOOKUP

  NSQUERY is a package similar in function to the nslookup tool provided on
BSD Unix systems. It takes a host name or Internet address and returns infor-
mation from a nameserver about that host or address. It was written by Matt
Madison and is available via anonymous FTP from ftp.spc.edu.  UCX itself
supports the command UCX SHOW HOST hostname.  Moreover, in all versions of
UCX V3.x an NSLOOKUP command is provided:

        $ nslookup == "$ucx$nslookup"
.$ nslookup ftp.spc.edu
.Server:  wpi.WPI.EDU
.Address:  130.215.24.1

.Non-authoritative answer:
.Name:    spcvxa.spc.edu
.Address:  192.107.46.27
.Aliases:  ftp.spc.edu

3.5) RLOGIN

  RLOGIN is available under UCX V2.0 and V3.x.  One apparent "bug" is that
usernames are truncated to eight characters, although this is a problem with
other commercial TCP/IP implementations for VMS as well.  Some older Unix
systems require the shorter usernames.  The other problem is that RLOGIN
makes the escape character non-transparent (Unix RLOGIN allows the escape
character to be sent by typing it twice).  Terry Kennedy of Saint Peter's
College (terry@spcvxa.spc.edu) has developed *unofficial* and *unsupported*
patches for V2.0 to fix the first problem and to disable escape processing
completely as a workaround for the second problem.  The patch text is
available from ftp.spc.edu in the [.ucx] subdirectory as rlogin-patch.doc.

  RLOGIN (remote login) is one of the Unix r-series commands (others are rcp,
rsh, and rdist). UCX provides an RLOGIN server which prompts the user for a
username and password (thus acting just like TELNET). UCX V1.3 does not
provide an RLOGIN client.

3.6) TALK

  TALK is the TCP/IP equivalent of the VMS PHONE utility.  Terry Kennedy has
ported the BSD Network-2 version of TALK to VMS.  It is available from
ftp.spc.edu in the [.ucx] directory as ntalk.bck, ntalkd.bck, and
talk.readme. Note that you had better have at least V1.2 of the CSCPAT_0903
patch kit (see section 1.3) if you are running V1.3 of UCX or someone _will_
crash your system with this.

3.7) LPR

  LPR is the remote printing support package used by Unix systems. The closest
thing to it under VMS/DECnet would be DQS (Distributed Queueing Services). I
don't know of any stand-alone ports of LPR to UCX. Both a client and server
are available as part of UCX V2.x and V3.x.

  Keith Moore <moore@cs.utk.edu> says that he has a version of LPR that works
with UCX as well as other TCP/IP packages. It also includes DECnet support.
You can FTP it from cs.utk.edu as readonly/port-lpr-1-3.vms.

3.8) POP server

  The IUPOP3 server is a VMS implementation of the Post Office Protocol Vers-
ion 3, based on RFC 1225 (which supersedes RFC 1081).

  IUPOP3 was developed and tested on VMS 5.3 and 5.4 systems, using the VMS
callable mail (MAIL$) interface.  The current release is believed to be com-
patible with current versions of these TCP/IP network implementations: Wol-
longong's WIN/TCP for VMS, DEC's UCX, and TGV's Multinet.

 The current version is 1.8, and is available from ftp.indiana.edu in
directory /pub/vms/iupop3.  Email questions and/or comments can be directed
to iupop3@indiana.edu.  IUPOP3 is compatible with UCX V3.1 for both OpenVMS
VAX and OpenVMS AXP.  It won't work with UCX V3.0.

3.9) Archie client

  Archie is a client/server system which assists users in locating packages
that are available for anonymous FTP on the Internet. Normally a user would
give the name of a program and Archie would return the names of sites that
program could be retrieved from. At the moment, the Archie servers don't seem
to have a lot of information about VMS packages, but that will probably change
soon.

  A version of the Archie client was posted to the vmsnet.sources newsgroup 
and can be retrieved via anonymous FTP from cerritos.edu in the [.vmsnet] dir-
ectory as archie_client.bck_z.

3.10) IRC client

  IRC (Internet Relay Chat) is a real-time chat system. It is a very popular
system among students. A client for VMS is available via anonymous FTP from
freebie.engin.umich.edu as /pub/irc/clients/vms/IRC172.COM. Note that this
host is a Unix system - case matters. There is another variant available
from coombs.anu.edu.au as /pub/irc/vms/irc173.com.

3.11) Empire client

  Empire is a multi-player war game. It's the other popular thing students
do. A version of the client for UCX is available via anonymous FTP from
ucbvax.berkeley.edu as /pub/games/empire/bsd/vms-emp1.1client-2.5. Again, this
is a Unix system so case matters. Also, you'll have to call it something else
on your system as this name isn't valid on VMS.

3.12) NNTP clients and servers

  NNTP is the protocol used to transfer Usenet news over TCP/IP links. The
most common package seems to be ANU News, which is available as part of the
DECUS UUCP distribution. It has a UCX client but no server. A multithreaded
ANU NNTP server for UCX was posted to news.software.anu-news by Steve Bour,
jsbour@ualr.edu. It can be obtained via anonymous FTP from ualret.ualr.edu
in the /pub/anu-news directory.

  Another news reader is the aptly named NEWSRDR package by Matt Madison and
MadGoat Software. It is available via anonymous FTP from public.tgv.com in
the [.madison.newsrdr] subdirectory.  It's also available from
ftp.spc.edu:[.MACRO32.SAVESETS] and ftp.wku.edu:[.MADGOAT].

  Joel Snyder's VNEWS package also supports UCX (and also other TCP packages
such as MultiNet, Wollongong, Process Software, CMU/Tek as well as DECnet) as
a news transport. A Fortran compiler is required. VNEWS is available via
anonymous ftp from arizona.edu in the directories [.software.vms.vnews...].
It is being maintained by Joel Snyder (jms@arizona.edu), so questions and bug
reports should go to him.

  VMS NEWS is from Bernd Onasch (bernd@rzsun2.rz.uni-karlsruhe.de or
Onasch@askdonald.ask.uni-karlsruhe.de).  It's apparently a threaded news
reader and is available from ftp.spc.edu:[.UCX]NEWS_125.SHARE.

  DXRN/MXRN (X Windows readers for DECwindows and DECwindows/Motif) support
UCX as well. Both programs are built from the same source files. It is
available via anonymous FTP from decuac.dec.com as file /pub/DEC/dxrn.share.
This is a VMS-SHARE format file.  Contact Rick Murphy
(murphy@burfle.dco.dec.com) for more information.

  BULLETIN from Mark London (mrl@pfc.mit.edu) contains a news reader client.
Send INFO to bulletin@pfc.mit.edu for a description of BULLETIN.

  FNEWS is basically a mixture of NEWSRDR and ANU-NEWS, providing a
somewhat different full-screen interface and quick response to all groups.
It can be found in the pub/fnews/vms directory on zephyr.grace.cri.nz.
Contact Chris Pugmire (Chrisp@grace.cri.nz) for more information.

3.13) WHOIS

  WHOIS is an interface into the user/host/network registry provided by the
DDN Network Information Center, nic.ddn.mil. The Unix version ported easily
to UCX and is available from ftp.spc.edu in directory [.ucx] as whois.bck.

3.14) Finger

  Finger is a user locater and information tool. Many versions exist. One
which is known to work with UCX was written by Matt Madison and is available
via anonymous FTP from ftp.spc.edu.

  Another version, called "DECUS Finger" is available via anonymous FTP from
ftp.spc.edu in subdirectory [.finger]. Its UCX support is present and works
rather well, however a major rewrite is in progress.

  Jacob Levanon writes: "You can get a finger daemon that works with UCX/
WINS/TGV from ftp.indiana.edu via anonymous ftp. (/pub/vms/iufingerd)."

  Bernd Onasch has written a finger client and server, along with a number
of other servers for "standard" Unix features like chargen, echo, etc. You
can obtain these via anonymous FTP from ftp.spc.edu in the [.ucx] directory.

  Takasji Ichihara reports that the "Penn State Finger package", available
from ftp.otc.psu.edu:/pub/ntp/vms/finger/psfinger11-1.zip works fine in an
OpenVMS AXP V6.1/UCX V3.1 environment

3.15) TRACEROUTE

  TRACEROUTE is a tool for determining what path your packets take to get from
your host to another host. It is very useful for troubleshooting network
problems.  UCX V2.0 supports traceroute, but the times reported are off by an
order of magnitude (they're 1/10th the actual times).  A source in Digital
reports that this is repaired in UCX V3.1.  An *unsupported* and *unofficial*
patch to correct this for V2.0 is available from ftp.spc.edu in the [.ucx]
subdirectory as traceroute-patch.doc.  Note that with this patch installed,
times will be reported to the nearest 10 milliseconds instead of 1 as on
Unix. This is due to the resolution of the timer code being used.

  Look for TRACEROUTE in SYS$COMMON:[SYSHLP.EXAMPLES.UCX].

3.16) Gopher

  A Gopher client for UCX is available from boombox.micro.umn.edu in the
directory /pub/gopher/incoming as gopher1.1v.tar.Z. Note that this package was
packaged with various Unix tools which you might not have readily available.
There is a VMS BACKUP saveset of this kit (along with the patch mention-
ed below) on ftp.spc.edu in the [.ucx] subdirectory as gopher11v.bck.

  As distributed, the client has a problem working with UCX because it is
trying to set an inverted mask as a socket option. To fix this, find the
line in [.object]gsgopherobj.c that reads:
     setsockopt(iSock, SOL_SOCKET, ~SO_LINGER, 0, 0);
and change it to:
#ifndef  UCX
     setsockopt(iSock, SOL_SOCKET, ~SO_LINGER, 0, 0);
#endif /* UCX */

  Gopher V1.2 is available by mail from King's College, London
(vmsserv@bay.cc.kcl.ac.uk).

  The current version of Gopher is 2.1.3.  I don't know if the above sites
carry the current verion.  Version 2.1.4 is in beta, but Arne Vajhj
(ARNE@ko.hhs.dk) reports that it doesn't work with VMS (yet).  The latest
version of the VMS Gopher client VMS can always be retrieved from Foteos
Macrides Gopher-server at gopher://gopher.wfeb.edu/11/_fileserv.  If FTP is
preferred, then Arne's mirror, ftp.hhs.dk, will have it.  The URL is
ftp://ftp.hhs.dk/fote_mirror/.


3.17) NTP (Network Time Protocol)


  UCX V3.3 supports NTP, both low-strata (server) peers and high-strata
(client) peers.

  Klaus Steinberger (Klaus.Steinberger@Physik.Uni-Muenchen.DE) writes that
an NTP client which interfaces with the DECdts facility (part of the DECnet
Phase IV Extensions) can be found on ftp.bl.physik.tu-muenchen.de (129.187.
160.11) in the /pub/vms/DECdts directory.

  Russell Mosemann (mose@ccsn.edu) states that Ntpdate for VMS is also now
available from louie.udel.edu in /pub/ntp/ntpdate_vms.tar.Z.  Ntpdate selects
the best among one or more NTP servers and optionally sets the time.  He also
reports that ftp.ccsn.edu has RDATE in /pub/rdate.  RDATE retrieves the
current time from a time server and sets the system time accordingly.  It
understands Daylight Savings Time.

  Eric Rustomji (rustomji@scsmac1.monsanto.com) notes that ftp.ccsn.edu also
has ntpdate in /pub/ntpdate.

  lst@mvx.grc.nia.nih.gov (I don't know who this is, as no personal name or
sig was included in the mail) reports that 132.163.135.130 has a package
named vms_tcp_time_client.c in pub/daytime that will set the VMS clock via
NIST.

  Wolfgang J. Moeller (moeller@gwdgv1.dnet.gwdg.de) has ported XNTPD to VMS
using UCX V3.2 and DEC C.  It's available from ftp.gwdg.de:pub/vms/xntp* and
gwdw04.gwdg.de:VMS/XNTP*.  The differences between this port and the original
xntp3.4v from louie.udel.edu are also at the above sites, in case anyone has
the original and wishes to make the changes.  Wolfgang has submitted the
changes for inclusion in the official release.  The port hasn't been tested
with UCX V3.3.

3.18) FTP (File Transfer Protocol)

  While UCX comes with FTP, there is, as mentioned above, a free version of
FTP available from MadGoat Software (ftp.wku.edu) which uses the NETLIB
package (also by MadGoat) to make it portable across most versions of TCP/IP
running on OpenVMS systems (both VAX and AXP).  This version of FTP supports
the STRU O VMS construct mentioned previously, thus enabling VMS file
structure compatibility between whichever TCP/IP implementation you run.

3.19) HTTP and WWW (World Wide Web)

  There are two sides to a connection to the World Wide Web: an HTTP
(HyperText Transfer Protocol) server and a WWW client or browser.  Both are
available for UCX.  Additional information on the WWW, servers, and browsers
can be found in the comp.infosystems.www news hierarchy.

  The CERN HTTP server is available from info.cern.ch.  The Ohio State
DECthreads HTTP server, written by David Jones, is available from osu.edu.
Both have advantages, but the latter is very efficient in its use of VMS
resources and is a very flexible server.

  Version V2.4 of Lynx, a VT-compatible WWW traversal tool, is available
from ftp2.cc.ukans.edu.  Foteos Macrides keeps an up-to-date version with some
extra modifications on his gopher server.  Arne Vajhj's ftp mirror also
carries it.

  Another character cell browser employing SMG was written by Dudu Rashty
and is available from vms.huji.ac.il in the directory www/www_client.

  NCSA Mosaic is an X-based browser.  V2.0 of Mosaic is available from King's
College (vmsserv@bay.cc.kcl.ac.uk) or from
ftp.w3.org:/pub/www/bin/vms/Mosaic-2.0.VMS-14.tar.Z.  Mosaic V2.4 sources are 
available from ftp.wku.edu:[.vms.unsupported].  Also, Digital provides the
executable of Mosaic 2.4 for OpenVMS 6.x at
ftp.service.digital.com:/pub/vms/Mosaic.  It requires UCX 3.1 or higher, or
3.0 with patch.  Again, Foteos Macrides and Arne Vajhj also keep copies.

  Anyone with more extensive experience with these tools and who wants to
provide a more lengthy explanation can send it to one of us for inclusion
here.

3.20) NETLIB

  NETLIB is a package from MadGoat Software that allows one to write portable
software for just about any TCP/IP package currently running on OpenVMS.
Some of the utilities in this chapter will operate with UCX because of this
package.  If you intend to write programs that "talk" TCP/IP, this package is
worth it.  Get it from ftp.wku.edu or ftp.spc.edu.

  A notable suppliment to NETLIB is the SOCKETSHR package from Eckart Meyer
of the Technical University of Braunschweig in Germany.  SOCKETSHR provides a
socket interface on top of NETLIB so that many existing IP applications can
be modified to work with any VMS-supported TCP/IP package with a simple
#include in the C course.  SOCKETSHR can also be found at ftp.wku.edu.

4. Programming

4.1) Where is the programming documentation?

  The documentation is split between the UCX Programmer's Reference (part of
the UCX documentation) and the VAX C RTL User's Guide (part of the VAX C doc-
umentation). The Unix-style routines are in the back of the C manual and the
$QIO routines are in the UCX manual. Note that the Unix-style routines are in-
complete (see section 4.2) and are not listed in any known order in the manual.
Also, the examples installed in SYS$EXAMPLES: for UCX V2.0 are the obsolete
ones from UCX V1.3. If you want to see how to use the V2.0 Auxiliary Server,
you'll need to look in the Programming manual. Note: V2.0E still ships the
obsolete files instead of the correct ones.

  Sources at Digital say that the examples in the UCX Programmer's Reference
have been thoroughly revised, clearing up most of these problems.  Could
someone in the field report on whether or not the SYS$EXAMPLES files have
been cleared up as well?

4.2) Why don't routines like getprotobyname() work?

  DEC seems to have added entry points for all of the Unix networking functions
to the UCX sharable image. This way, functions could be implemented in the fu-
ture without reqiring relinking of existing programs. Unfortunately, the unim-
plemented functions return NULL, rather than a null pointer, so most programs
ported from Unix will ACCVIO rather than returning an error.  Sources within
Digital state than the errors like this that have been found have been fixed
in the current version.

  Some of these may be newly functional in V3.x. For example,
getprotobyname() and getprotobynumber() have been added.  Digital welcomes
feedback from the field on remaining problems.

  There are patches available from DSIN/DSNlink for previous versions that
enable some additional routines. These should be in both the DEC-TCP and C
databases (the master articles are in the C database).

5. Common Problems and Solutions

5.1) Why can't non-privileged users do <X>?

  An early bug in UCX V1.3 caused the file UCX$ACCESS_SHR to not be installed
properly. A copy needs to be in SYS$SPECIFIC:[SYSLIB], protected with G:RE and
W:RE. A bug in V2.0's FTP ECO 1 randomly prevented non-privileged users from
getting files. This was corrected in ECO 2.

5.2) What is the UCX V1.3 security patch for?

  On December 18th, 1990 DEC issued a warning bulletin to UCX customers warning
of a potential security problem. That letter is also found on the CD-ROM dis-
tribution of UCX. If you don't have a copy, you should contact your support 
person and get a copy of the letter if you are running V1.3.

5.3) How can I disable incoming Telnet access?

  Edit the file SYS$MANAGER:UCX$REMOTE_TTY_STARTUP.COM and comment out the
line: UCX START SERV TELNET. You may also want to comment out the line: UCX
START SERV RLOGIN.

5.4) Why is Auxilary Server (inetd) startup so slow?

  Part of this is due to normal VMS process creation overhead. However,
there is a bug in V2.0 of UCX (at least through NET ECO 1 / CSCPAT #906)
which causes most server processes to be created at priority 0, which is
essentially "suspended animation". Once the process proceeds through the
LOGINOUT image, it will have the proper priority as specified in the UAF
record for the server account. However, on a heavily loaded system this
can take minutes. An *unofficial* and *unsupported* patch to fix this
problem has been developed locally. The patch text is available from the
ftp.spc.edu server in the [.ucx] subdirectory as inetacp-patch.doc.
Note: This bug is fixed in V2.0E.

5.5) Why doesn't Anonymous ftp work?

  DEC added the anonymous ftp feature to UCX V3.2.  When the installation
process is completed, you will then have to run the UCX configuration
procedure.  Select the "Optional components" option and then you will see
the selection for setting up anonymous ftp.

  After answering the questions, you will then have to modify the
protection of the anonymous ftp log file to allow write access to the world.
The file name is UCX$FTP_ANONYMOUS.LOG and is found in [UCX$FTP].

  MadGoat FTP, mentioned earlier also supports anonymous FTP and will work
for versions of UCX prior to V3.2.

5.6) How do I add proxies in a cluster?

  When adding proxies in a cluster, the proxy records are added to the
cluster-wide proxy database (UCX$PROXY), but they are loaded only on the node
where they're added.  This results in being able to reference that particular
node only with, for example, the R-series commands.

  In order to have all of the nodes in the cluster reload their in-memory
proxy database, you need to use the undocumented SET UCX_SERVER command from
SYSMAN, like this:

$ mcr sysman
SYSMAN> set env/node=ucxnodes
%SYSMAN-I-ENV, current command environment:
        Individual nodes: NODE1,NODE2,NODE3
        Username TESTUSER     will be used on nonlocal nodes

SYSMAN> do ucx set ucx_server/signal
%SYSMAN-I-OUTPUT, command execution on node NODE1
%UCX-I-LOADSERV, Loading UCX Server proxy information
%UCX-I-SERVLOADED, UCX Aux. Server loaded with 7 proxy records
-UCX-I-SERVSKIP,  Skipped 0 communication proxy records
-UCX-I-SERVTOTAL,  Total of 7 proxy records read
..
SYSMAN>

Once this is done, all nodes will have the in-memory proxy database correctly
configured.

  For completeness sake, here is the SET UCX_SERVER command syntax:

      SET UCX_SERVER[/qualifier]

where "/qualifier" can be /DEBUG=(option[,...]) (where "option" is READ,
WRITE, UPDATE, or DELETE), /HOST=(host[,...]), /PROXIES=n (default=20),
/REMOTE_USER_NAME=name, and /SIGNAL.

I don't know what the other qualifiers do.  Perhaps others will let us know.

5.7) How do I set up a BIND Server?

  The following is presented with thanks to Ramesh Tumkur
(ramesh@lassie.ucx.lkg.dec.com).  It is presented as he sent it to me, with
only some minor editing.

Name servers:
-------------

  Name servers are programs that store information about part or all of the
domain name space (zone).

Primary and Secondary name server:
----------------------------------

  A primary name server gets data for the zones over which it has authority
from "database files" in directory SYS$SPECIFIC:[UCX$BIND], on the host where
it runs.

  A secondary name server loads its zone data over the network from another
name server via a process called "zone transfer".  It saves the backup copy
of the zone data in SYS$SPECIFIC:[UCX$BIND].  However, a secondary server is
not required to save a backup copy of the zone data, although it is
recommended, since if at a particluar instance the primary is down, and the
secondary is started, the secondary will be not be able to perform "zone
transfer", until the primary is up.  With the backup copies, the secondary
does have some data, even if it is somewhat out of date, and it can perform
its basic tasks.

Primary name server setup:
-------------------------

  To set up a primary name server, "data base files" are to be created (if they
do not exist), in the directory SYS$SPECIFIC:[UCX$BIND].  These files and
their purpose are as follows:

NAMED.LOCAL - The UCX primary server needs this file for "loopback address",
for directing traffic to itself.  The network is almost always 127.0.0, and
the local host number is 127.0.0.1

Here is an example of a typical NAMED.LOCAL file:
;
; BIND data file for local loopback interface.
;
; Provided for DEC TCP/IP Services for OpenVMS.
;
@           IN  SOA     dot.ucx.lkg.dec.com. postmaster.dot.ucx.lkg.dec.com. (
                        1       ; Serial
                        3600    ; Refresh
                        300     ; Retry
                        3600000 ; Expire
                        3600 )  ; Minimum
            IN  NS      dot.ucx.lkg.dec.com.
1           IN  PTR     localhost.
localhost.  IN  A       127.0.0.1

--

NAMED.CA - relates to the data pertaining to the  "root name servers".  This
file is loaded when the name server starts.

Here is an example of a typical NAMED.CA file:
;
; Data file for initial cache data for root domain servers.
;
; Provided for DEC TCP/IP Services for OpenVMS.
;
; Updated from rs.internic.net:/netinfo/root-servers.txt on 16 April 1993.
; A directory of the file file showed a modification date of 5 April 1993,
; and the contents of the file were dated internally as `Apr 93',
;
;
                   99999999    IN      NS      NS.NIC.DDN.MIL.
                   99999999    IN      NS      KAVA.NISC.SRI.COM.
                   99999999    IN      NS      AOS.BRL.MIL.
                   99999999    IN      NS      C.NYSER.NET.
                   99999999    IN      NS      TERP.UMD.EDU.
                   99999999    IN      NS      NS.NASA.GOV.
                   99999999    IN      NS      NIC.NORDU.NET.
                   99999999    IN      NS      NS.INTERNIC.NET.
;
NS.NIC.DDN.MIL.     99999999    IN      A       192.112.36.4
KAVA.NISC.SRI.COM.  99999999    IN      A       192.33.33.24
AOS.BRL.MIL.        99999999    IN      A       128.63.4.82
                    99999999    IN      A       192.5.25.82
C.NYSER.NET.        99999999    IN      A       192.33.4.12
TERP.UMD.EDU.       99999999    IN      A       128.8.10.90
NS.NASA.GOV.        99999999    IN      A       192.52.195.10
                    99999999    IN      A       128.102.16.10
NIC.NORDU.NET.      99999999    IN      A       192.36.148.17
NS.INTERNIC.NET.    99999999    IN      A       198.41.0.4

--

DOMAIN_NAME.DB - For mapping all host names to addresses.  For domain
"UCX.LKG.DEC.COM", the file is created as "UCX_LKG_DEC_COM.DB".

Here is an example of a typical DOMAIN_NAME.DB DNS file:

$ORIGIN lkg.dec.com.
ucx           IN      SOA     dot.ucx.lkg.dec.com. postmaster.dot.lkg.dec.com.
(
                      23      ; Serial
                     600      ; Refresh
                     300      ; Retry
                  172800      ; Expire
                   43200 )    ; Minimum
;
              IN      NS      dot.ucx.lkg.dec.com.
              IN      NS      hageln.ucx.lkg.dec.com.
;
$ORIGIN ucx.lkg.dec.com.
ucxaxp        IN      A       16.20.208.53
$ORIGIN ucx.lkg.dec.com.
hageln        IN      A       16.20.208.10
$ORIGIN ucx.LKG.DEC.COM.
WKStesthave   IN      WKS     16.20.208.255 255
kempo         IN      A       16.20.208.47
              IN      MX      10 kempo.ucx.lkg.dec.com.
              IN      MX      100 inet-gw-1.pa.dec.com.
              IN      MX      100 mts-gw.pa.dec.com.
              IN      MX      200 crl.dec.com.
              IN      MX      300 decuac.dec.com.
boxmor        IN      A       16.20.208.30
              IN      MX      10 boxmor.ucx.lkg.dec.com.
              IN      MX      100 inet-gw-1.pa.dec.com.
              IN      MX      100 mts-gw.pa.dec.com.
              IN      MX      200 crl.dec.com.
              IN      MX      300 decuac.dec.com.
dot           IN      A       16.20.208.72
              IN      MX      10 dot.ucx.lkg.dec.com.
              IN      MX      100 inet-gw-1.pa.dec.com.
              IN      MX      100 mts-gw.pa.dec.com.
              IN      MX      200 crl.dec.com.
              IN      MX      300 decuac.dec.com.
piltdown      IN      A       16.20.208.73
              IN      MX      10 pultdown.ucx.lkg.dec.com.
              IN      MX      100 inet-gw-1.pa.dec.com.
              IN      MX      100 mts-gw.pa.dec.com.
              IN      MX      200 crl.dec.com.
              IN      MX      300 decuac.dec.com.
celtics       IN      A       16.20.208.79
              IN      MX      10 celtics.ucx.lkg.dec.com.
              IN      MX      100 inet-gw-1.pa.dec.com.
              IN      MX      100 mts-gw.pa.dec.com.
              IN      MX      200 crl.dec.com.
              IN      MX      300 decuac.dec.com.

--

ADDRESS.DB - Maps address back to host names (reverse mapping).  For address
16.20.208, the file is created as "208_20_16_IN-ADDR_ARPA.DB"

Here is an example of a typical ADDRESS.DB file (208_20_16_IN-ADDR_ARPA.DB):

$ORIGIN 20.16.in-addr.arpa.
208             IN      SOA     dot.ucx.lkg.dec.com.
postmaster.dot.ucx.lkg.dec.com.
(
                                1     ; Serial
                              600     ; Refresh 
                              300     ; Retry
                           172800     ; Expire
                            43200 )   ; Minimum
;
              IN      NS      dot.ucx.lkg.dec.com.
              IN      NS      hageln.ucx.lkg.dec.com.
;
$ORIGIN 208.20.16.IN-ADDR.ARPA.
53            IN      PTR     ucxaxp.ucx.lkg.dec.com.
10            IN      PTR     hageln.ucx.lkg.dec.com.
47            IN      PTR     kempo.ucx.lkg.dec.com.
30            IN      PTR     boxmor.ucx.lkg.dec.com.
72            IN      PTR     dot.ucx.lkg.dec.com.
73            IN      PTR     piltdown.ucx.lkg.dec.com.
79            IN      PTR     celtics.ucx.lkg.dec.com.

--

BOOT FILE - this gets created during installation/configuration of UCX using
"@SYS$MANAGER:UCX$CONFIG".  The boot file gets created in SYS$COMMON:[SYSEXE]
as "UCX$CONFIGURATION.DAT".  This file also holds data relating to
interfaces and other components in addition to BIND.  For BIND, it acts as a
mechanism for pointing the "server" (here, a secondary server), to the
database files.

HOST TABLE - The input for creating DNS database files. It is created as
"SYS$COMMON:[SYSEXE]UCX$HOST.DAT" and can be populated from a Unix /etc/hosts
file using the UCX CONVERT/VMS HOST command or by using UCX SET HOST
commands.  Its contents can be viewed with the UCX SHOW HOST /LOCAL.

--

The commands for creating the DNS database files from UCX$HOST.DAT for a
typical domain "ucx.lkg.dec.com" are:

$ UCX CONVERT/ULTRIX BIND /DOMAIN=UCX.LKG.DEC.COM
    (creates file: UCX_LKG_DEC_COM.DB)

$ UCX CONVERT/ULTRIX BIND /DOMAIN=208.20.16.IN-ADDR.ARPA
    (creates file: 208_20_16_IN-ADDR_ARPA.DB)

NAMED.LOCAL and NAMED.CA can be retrieved from internet hosts.

Here is a typical directory listing:

      $ dir sys$specific:[ucx$bind]

      Directory SYS$SPECIFIC:[UCX$BIND]

      208_20_16_IN-ADDR_ARPA.DB;1     NAMED.CA;1
      NAMED.LOCAL;1   UCX_LKG_DEC_COM.DB;1    LOGIN.COM;1
      UCX$BIND_STARTUP.COM;1          UCX$BIND_STARTUP.LOG;1

      $ dir ucx$hosts

      Directory SYS$COMMON:[SYSEXE]

      UCX$HOST.DAT;1

      $ DIR UCX$CONFIGURATION

      Directory SYS$COMMON:[SYSEXE]

      UCX$CONFIGURATION.DAT;1

--

To instruct the primary name server to read the DNS database files using the
"UCX$CONFIGURATION.DAT" mechanism, use the following commands:

      $ UCX SET CONFIG BIND /CACHE
      $ UCX SET CONFIG BIND /PRIM=(DOMAIN:UCX.LKG.DEC.COM)
      $ UCX SET CONFIG BIND /PRIM=(DOMAIN:208.20.16.IN-ADDR.ARPA)
      $ UCX SET CONFIG BIND /PRIM=(DOMAIN:0.0.127.IN-ADDR.ARPA,
                                       FILE:NAMED.LOCAL)
      $ UCX SHOW CONFIG BIND

Primary
 Domain:     UCX.LKG.DEC.COM               File: UCX_LKG_DEC_COM.DB

Primary
 Domain:     208.20.16.IN-ADDR.ARPA        File: 208_20_16_IN-ADDR_ARPA.DB

Primary
 Domain:     0.0.127.IN-ADDR.ARPA          File: NAMED.LOCAL

Cache
 Domain:     .                             File: NAMED.CA

--

  The last step is to run "CONFIG" for setting up "BIND resolver" and to
stop/restart the "DNS server"

      $ @SYS$MANAGER:UCX$CONFIG
--

      $ ucx show name

      BIND Resolver Parameters

      Local domain: ucx.lkg.dec.com

      System

      State:     Started, Enabled

      Transport: UDP
      Domain:    ucx.lkg.dec.com
      Retry:     4
      Timeout:   4
      Servers:   dot.ucx.lkg.dec.com

      Process

      State:     Enabled

      Transport:
      Domain:
      Retry:
      Servers:

--

$ UCX SHOW SERVICE BIND

Service             Port  Proto    Process          Address           State

BIND                  53  TCP,UDP  UCX$BIND         0.0.0.0           Enabled

=============================================================================

How to set up a secondary name server:
 --------------------------------------

  To set up a secondary name server on a host named celtics, the steps are:

Copy NAMED.LOCAL AND NAMED.CA from primary (example host: dot)
Create ucx$configuration.dat (from config menu)

$ UCX SET CONFIG BIND /SEC=(DOMAIN:UCX.LKG.DEC.COM,
                            FILE:UCX_LKG_DEC_COM.DB,
                            HOST:DOT.UCX.LKG.DEC.COM)

$ UCX SET CONFIG BIND /SEC=(DOMAIN:208.20.16.IN-ADDR.ARPA,
                            FILE:208_20_16_IN-ADDR_ARPA.DB,
                            HOST:DOT.UCX.LKG.DEC.COM)

$ UCX SET CONFIG BIND /PRIM=(DOMAIN:0.0.127.IN-ADDR.ARPA,
                             FILE:NAMED.LOCAL)

$ UCX SET CONFIG BIND /CACHE

--

The last step is to run "CONFIG" for setting up "BIND resolver" and to
stop/restart the "DNS server" with @SYS$MANAGER:UCX$CONFIG

--

$ ucx show name

BIND Resolver Parameters

Local domain: ucx.lkg.dec.com

System

State:     Started, Enabled

Transport: UDP
Domain:    ucx.lkg.dec.com
Retry:     4
Timeout:   4
Servers:   celtics.ucx.lkg.dec.com

Process

State:     Enabled

Transport:
Domain:
Retry:
Servers:

--

$ UCX SHOW SERVICE BIND

Service             Port  Proto    Process          Address            State

BIND                  53  TCP,UDP  UCX$BIND         0.0.0.0            Enabled

P.S: The serial number of SOA record in the DB files need to incremented
when new db files are created or DB files updated.

For most systems, the above two server set ups would suffice.

=============================================================================

Setting up a Forwarder:
-----------------------

  Forwarders are used where off-site DNS traffic is to be limited.  If the
customer's site has 5 or 6 servers, for example, all servers could send
off-site DNS query packets for all off-site queries generated at the site.
Instead one server can be designated as a "forwarder", and all other server
queries can be directed to it.

  If, for example, the host "dot" is to be the forwarder. the other 5 or 6
servers mentioned above could just add:

              UCX SET CONFIG BIND /FORWARDERS=(HOST:dot)

in their configuration file

=============================================================================

Configuring the remaining hosts:
-------------------------------

                                       name-
               (host-1)        (host-2:server)         (host-3)
                   |                 |                     |
                   |                 |                     |
               ------------------------------------------------ (network-A)
                                       |
                                 (host-4:server) multi-homed
                                       |
                                       |
               ------------------------------------------------- (network-b)
                       |                               |
                       |                               |
                    (host -6)                       (host-7)

Having configured host-2 and host-4 as name_servers for this particular
example domain, the "resolvers" of the remaining hosts host-1,3,6,7 could
just point to any/both of these servers. (You need not run ucx$bind in these
hosts.  In this example, UCX$BIND is disabled in host-1,3,6,7.)

host-7> UCX SHOW NAME

BIND Resolver Parameters

Local domain: ucx.lkg.dec.com

System

State:     Started, Enabled

Transport: UDP
Domain:    ucx.lkg.dec.com
Retry:     4
Timeout:   4
Servers:   host-2, host-4

The BIND resolver in other hosts could be configured from the config menu
"SYS$MANAGER:UCX$CONFIG"

=============================================================================

Other configuration commands:
-----------------------------

UCX> SET CONFIGURATION NAME_SERVICE /SERVER=LASSIE

  Upon the next UCX startup, this command enables the local BIND resolver 
and defines hosts LASSIE as the name server. 

UCX> SET CONFIGURATION NAME_SERVICE /NOSERVER=LASSIE

Upon the next UCX startup, LASSIE is removed from the list.

  If you define a server list and then issue another SET NAME_SERVICE/SERVER
command, UCX appends the new servers to the end of the list.

  To specify multiple hosts, list them by request preference.  The resolver
sends the first lookup request to the first host on the list.

  To delete the old nameserver information and configure the bind resolver,
follow these steps:

Step 1: Upon the next UCX startup, configure the BIND Resolver.

$ ucx sho config name

BIND Resolver Configuration

Transport:  UDP
Domain:     ucx.lkg.dec.com
Retry:         4
Timeout:       4
Servers:    16.20.208.100             (old name server)
                                      (lassie.ucx.lkg.dec.com)

 - Delete the old name server/(s) from the config list using:

$ucx set config name /noserver=16.20.208.100 

 - view the result

$ ucx sho config name

BIND Resolver Configuration

Transport:  UDP
Domain:     ucx.lkg.dec.com
Retry:         4
Timeout:       4
Servers:    not defined

 - add the new name server:

$ucx set config name /server=16.20.208.53  (new server - ipaddress or name)

 - display the new entry

$ ucx sho config name

BIND Resolver Configuration

Transport:  UDP
Domain:     ucx.lkg.dec.com
Retry:         4
Timeout:       4
Servers:    16.20.208.53..(ucxaxp.ucx.lkg.dec.com)

Other useful commands:

                                             [ /[NO]DOMA=domain ]
                                             [ /RETRY=seconds   ]
SET CONFIG [NO]NAME_SERVICE /[NO]SERVER=host [ /SYSTEM          ]
                                             [ /TIMEOUT=seconds ]
                                             [                  ]
                                             [ /TRANSP=protocol ]

These entries will become "current" upon the next UCX startup

-------

Step 2: Configure the resolver for the "current" setup..
 (modify system parameters - for immediate effect)

$ ucx sho name

BIND Resolver Parameters

Local domain: ucx.lkg.dec.com

System

State:     Started, Enabled

Transport: UDP
Domain:    ucx.lkg.dec.com
Retry:     4
Timeout:   4
Servers:   lassie...(old name server)

Process

State:     Enabled

Transport:
Domain:
Retry:
Timeout:
Servers:

 - delete the old name server from the system table..

$ucx set name /noserver=lassie/system

 - view the result

$ ucx sho name

BIND Resolver Parameters

Local domain: ucx.lkg.dec.com

System

State:     Started, Disabled

Transport: UDP
Domain:    ucx.lkg.dec.com
Retry:     4
Timeout:   4
Servers:   No servers defined

Process

State:     Disabled

Transport:
Domain:
Retry:
Timeout:
Servers:

 - add the new server to the system table, enable the resolver..

$ ucx set name /server=ucxaxp/system/enable

 - view the result

$ ucx sho name

BIND Resolver Parameters

Local domain: ucx.lkg.dec.com

System

State:     Started, Enabled

Transport: UDP
Domain:    ucx.lkg.dec.com
Retry:     4
Timeout:   4
Servers:   ucxaxp....(new name server)

Process

State:     Enabled

Transport:
Domain:
Retry:
Timeout:
Servers:

 - view the  new logicals

$ show log UCX$BIND*

(LNM$SYSTEM_TABLE)

  "UCX$BIND_DOMAIN" = "ucx.lkg.dec.com"
  "UCX$BIND_RETRY" = "...."
  "UCX$BIND_SERVER" = "........"
  "UCX$BIND_SERVER000" = "16.20.208.53"  (ucxaxp- new name server entry)
  "UCX$BIND_STATE" = "........"
  "UCX$BIND_TIMEOUT" = "...."
  "UCX$BIND_TRANSPORT" = "UDP"

Related useful commands:

                                  [ /DISABLE            ]
                                  [ /[NO]DOMAIN=domain  ]
                                  [ /ENABLE             ]
                                  [                     ]
SET NAME_SERVICE /[NO]SERVER=host [ /RETRY=seconds      ]
                                  [ /SYSTEM             ]
                                  [ /TIMEOUT=seconds    ]
                                  [                     ]
                                  [ /TRANSPORT=protocol ]

6. NFS (Network File System)

  [Anyone with more extensive experience with UCX's NFS can provide
enhancements to this section.  Please let us know what should be covered
here].

6.1) Where can I get an NFS client (as opposed to a server) for UCX?

  An NFS client for UCX has been available since the V3.2 release.  It was
present in the release previous to that as well, but it didn't always work.

  There was an NFS client for UCX offered by Process Software, but Cathy
Wadelton <wadelton@process.com>, the Product Marketing Manager of that firm
said that it is no longer being sold.  Those in the know say that this client
is, in fact, the client that UCX V3.2 and above uses.

  Just recently, Lawrence B. Henry of The Wollongong Group (larry@twg.com)
said the following in the comp.os.vms newsgroup:

  "Wollongong does sell an NFS Client add-on for UCX. If you need information
on this product (or any PathWay product) drop a note to sales@twg.com."

.Brian Tillman..Senior Engineer
.tillman_brian@si.com.Smiths Industries, Grand Rapids, MI USA

.Dave Desroches...VMS Systems Manager
.dmdesroches@jake.wpi.edu.Worcester Polytechnic Institute

-----------------------------+--------------------------------
 Brian Tillman               | Internet: tillman@swdev.si.com
 Smiths Industries, Inc.     |           tillman_brian@si.com
 4141 Eastern Ave., MS239    | Hey, I said this stuff myself.
 Grand Rapids, MI 49518-8727 | My company has no part in it.
-----------------------------+--------------------------------
