Archive-name: dec-faq/ucx
Posting-Frequency: monthly
Last-modified: 2-Jun-1995 13:56
Version: 3.13

[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 earier to know where the changes are. This suggestion
came from Mike Davis (dav...@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

I. 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?

II. 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?

III. 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

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

V. 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

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

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 V3.2 was released in October of 1994 for both OpenVMS VAX and OpenVMS
AXP and is available on the current Consolidated Distribution disks. The most
recent prior version was V3.1 for AXP and VAX.

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

There is one ECO kit available from Digital for UCX. The kit is
| named UCXECO6-032 and there are separate savesets for the VAX and AXP
versions. 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. The previous version, V3.1, had ECOs up to ECO 13,
| although ECO 5 for UCX V3.1 is the only ECO that is available as a patch kit.
| The kit is named CSCPAT_0910 V1.0 and is available via DSNlink's
| INVOKE_FUNCTION. Search for "DEC TCP/IP Services for OpenVMS V3.1" in the
| ECO-SUMMARY database. ECOs between ECO 5 and 13 are available via DSNlink,
| but you must request them by sending a mesage to DSN%DEC-TCPIP. Ask for
| UCXECO13-031.

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.2 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.05 for VAX,
46.46.01 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-01.txt

o World Wide Web; the URL is
file://ftp.digital.com/pub/Digital/info/SPD/46-46-01.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.1. Most of these
were in V3.0 AXP as well.

o PCNFS-D to enable PC users to mount files on NFS servers,
including printing support

o Telnet enhancements:
- TN3270 for IBM 3270 terminal emulation
- Multiple simultaneous sessions
- Printing support for printers attached via Telnet servers

o BIND (name domain) server

o Remote boot server (BOOTP/TFTP support)

o SRI QIO$ interface (compatibility with TGV, Wollongong, and Process
Software programming interfaces)

o PATHWORKS V5.x transport support

o FTP enhancements:
- RMS attributes preserved on VMS-to-VMS copy
- High performance transfer mode

o Menu-driven installation and configuration

o License options:
- Full kit
- "Client" kit (actually full kit without NFS, BIND, and remote boot
servers)


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?

While you'd really need to ask Digital to get a definitive answer, 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.

Indications from V3.3 field test sites are that SLIP will be included in
the nex version of UCX.

III. 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, <bi...@office.ab.umd.edu>. This port is available from the FTP
server at ftp.spc.edu in file [.ucx]ping.bck.

Larry Horn <hor...@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 <S...@lns592.lns.cornell.edu> notes that UCX PING/NUMBER=n
hostname will report statistics similar to the Unix ping command. Steve Anich
<an...@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)
ser...@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 (te...@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 <mo...@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 iup...@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,
jsb...@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 (j...@arizona.edu), so questions and bug
reports should go to him.

VMS NEWS is from Bernd Onasch (be...@rzsun2.rz.uni-karlsruhe.de or
Ona...@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
(mur...@burfle.dco.dec.com) for more information.

BULLETIN from Mark London (m...@pfc.mit.edu) contains a news reader client.
Send INFO to bull...@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 (Chr...@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
(vms...@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.

3.17) NTP (Network Time Protocol)

Klaus Steinberger (Klaus.St...@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 (mo...@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 (rust...@scsmac1.monsanto.com) notes that ftp.ccsn.edu also
has ntpdate in /pub/ntpdate.

l...@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.

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.3 of Lynx, a VT-compatible WWW traversal tool, is available
from ftp2.cc.ukans.edu. 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 (vms...@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.1 at
ftp.service.digital.com:/pub/vms/Mosaic. It requires UCX 3.1 or higher, or
3.0 with patch. 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.

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

V. 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. (Sorry, don't have the
| remainder of his name or his address. If he writes again, I'll add it.) It
| is presented as he sent it to me, with only some minor editing for format and
| corrections to grammar.
|
| 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 ]

VI. 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 is available in the V3.2 release. It was present
in the previous release, but it didn't always work.

There was an NFS client for UCX offered by Process Software, but Cathy
Wadelton <wade...@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 uses.

Just recently, Lawrence B. Henry of The Wollongong Group (la...@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 sa...@twg.com