Newsgroups: vmsnet.networks.tcp-ip.ucx,news.answers Path: news1.ucsd.edu!ihnp4.ucsd.edu!mvb.saic.com!news.mathworks.com!uunet!in1.uu.net!esseye!swdev.si.com!tillman From: tillman@swdev.si.com (Brian Tillman) Subject: UCX FAQ - DEC TCP/IP Services for OpenVMS FAQ Message-ID: <10JUL95.12113370@swdev.si.com> Followup-To: vmsnet.networks.tcp-ip.ucx Sender: news@esseye.si.com Nntp-Posting-Host: terwed.si.com Organization: Smiths Industries Aerospace Date: Mon, 10 Jul 1995 12:11:33 GMT Approved: news-answers-request@MIT.EDU Expires: Fri, 1 Sep 1995 12:11:28 GMT Lines: 1477 Xref: news1.ucsd.edu vmsnet.networks.tcp-ip.ucx:1885 news.answers:41254 Archive-name: dec-faq/ucx Posting-Frequency: monthly Last-modified: 19-Jun-1995 10:18 Version: 3.14 [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 (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 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 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 ? 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. | | ** NOTE: When you install any of these ECOs, you should shut UCX off before | installing and you must reboot immediately afterward. ** | | Thanks to Brendan Welch (welchb@aspen.uml.edu) for asking that this | warning be included. 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.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.1) Why isn't 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. | V3.3 of UCX supports SLIP and CSLIP. 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, . This port is available from the FTP server at ftp.spc.edu in file [.ucx]ping.bck. Larry Horn 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 notes that UCX PING/NUMBER=n hostname will report statistics similar to the Unix ping command. Steve Anich 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 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. 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. 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 (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.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 ? 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 , 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 (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., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- .