CMUIP, TCP/IP, VAX Only TCP/IP implementation CMU OpenVMS TCP/IP Frequently Asked Questions Last Update: 27-OCT-1994 FAQ Maintainer: Andy Harper A.Harper @ kcl.ac.uk -------------------------------------------------------------------------------- This document is a set of Frequently Asked Questions (FAQ) About the CMU OpenVMS TCP/IP (hereinafter referred to as OpenCMU) package originally developed for VMS by Carnegie Mellon University and Tektronix. It is updated on an irregular basis, as new FAQs arise, and is posted on a monthly basis to the OpenCMU mailing list. The updated version may be obtained through anonymous FTP from `FTP.KCL.AC.UK' in directory [.CMU-TCPIP] as file CMU.FAQ. Each FAQ section begins with >>>> followed by the title of the section and the source of the answer, where known. Use of SEARCH on this document allows FAQ titles to be located. Please notify the maintainer of any omissions, out-of-date or incorrect information. Changes Since OCT 1994 Edition. ------------------------------- 27-OCT-1994 Add details of the FSP client/server software 11-OCT-1994 Rewrite section on telnet hanging 11-OCT-1994 Rewrite OpenCMU prerequisites section 11-OCT-1994 Change layout on all sections 10-OCT-1994 All relevant references to CMU changed to OpenCMU ! 10-OCT-1994 Add note on OpenCMU under OpenVMS 6.1 10-OCT-1994 Reorganize software details by function; rewrite some entries 10-OCT-1994 Add details of SOCKIT - a general socket library for OpenVMS 3-OCT-1994 Add details of SOCKETSHR - socket interface to NETLIB Changes Since AUG 1994 Edition. ------------------------------- 10-AUG-1994 Add hint on location of NETERROR.OBJ file 3-AUG-1994 Fix minor typos 2-AUG-1994 MX now at revision 4.1; updated filenames aaccordingly Changes Since JUL 1994 Edition. ------------------------------- 1-AUG-1994 Add more info on SLIP connections 11-JUL-1994 Correct instructions for use under OpenVMS 6.x 5-JUL-1994 Corrected use of CONVERT/FDL to modify BACKUP saveset format Changes Since JUN 1994 Edition. ------------------------------- 4-JUL-1994 Updated locations for WWW HTTP server 15-JUN-1994 Making OpenCMU work with OpenVMS 6.0 15-JUN-1994 Add details of ARCHIE software for OpenCMU 15-JUN-1994 Add details of IPADDR software for OpenCMU 3-JUN-1994 Correct typo in MGFTP description 3-JUN-1994 MGFTP is freeware, not public domain Changes Since MAY 1994 Edition. ------------------------------- 24-MAY-1994 Add details of LYNX package 16-MAY-1994 Rewrite GOPHER details. 16-MAY-1994 Update details of FTP patch kit 16-MAY-1994 Update OpenCMU overview LPD/LPRSYMB description 16-MAY-1994 How to print OpenCMU IP Error message texts 16-MAY-1994 Info on IPACP BYTLM quotas 11-MAY-1994 Tidy up software availability tables 11-MAY-1994 Add details of MGFTP - MadGoat FTP - product 6-MAY-1994 Add details of MG_FINGER - MadGoat Finger - product Changes Since APRIL 1994 Edition. --------------------------------- 14-APR-1994 Update Anonymous FTP address of UK mirror site 12-APR-1994 Correct directory of spanish mirror site -------------------------------------------------------------------------------- C O N T E N T S 1.0 GENERAL INFORMATION . . . . . . . . . . . . . . . . 1.1 What is OpenCMU . . . . . . . . . . . . . . . . 1.2 Obtaining OpenCMU . . . . . . . . . . . . . . . 1.3 PreRequisites . . . . . . . . . . . . . . . . . 1.4 Current Versions . . . . . . . . . . . . . . . 1.5 The OpenCMU Mailing List/Newsgroup . . . . . . 2.0 COMMONLY ASKED `SETUP' QUESTIONS . . . . . . . . . 2.1 Setting Up DECwindows over OpenCMU IP . . . . . 2.2 Setting up a SLIP connection . . . . . . . . . 2.3 More on setting up SLIP . . . . . . . . . . . . 2.4 Setting up an Anonymous FTP server . . . . . . 2.5 Setting up OpenCMU on OpenVMS 6.0 and 6.1 . . . . . 3.0 KNOWN PROBLEMS . . . . . . . . . . . . . . . . . . 3.1 Why is FTP so slow . . . . . . . . . . . . . . 3.2 Why does FTP crash with `exceeded quota' . . . 3.3 Why doesn't the NFS server work . . . . . . . . 3.4 Why does TELNET sometimes hang in `RWAST' . . . 3.5 Why does TELNETing into cmu hang . . . . . . . 3.6 Name Resolver gives referral limit exceeded . . 3.7 IPACP Issues status codes to OPCOM . . . . . . 3.8 IPACP crash due to insufficient quota . . . . . 3.9 FTP of BACKUP savesets gives CRC errors . . . . 4.0 PUBLIC DOMAIN SOFTWARE THAT SUPPORTS OPENCMU . . . 4.1 TCP/IP Transport Interface Libraries . . . . . 4.1.1 NETLIB . . . . . . . . . . . . . . . . . 4.1.2 SOCKETSHR . . . . . . . . . . . . . . . . 4.1.3 LIBCMU . . . . . . . . . . . . . . . . . 4.1.4 SOCKIT . . . . . . . . . . . . . . . . . 4.2 Mail Applications . . . . . . . . . . . . . . . 4.2.1 MX . . . . . . . . . . . . . . . . . . . 4.2.2 POP3 Server . . . . . . . . . . . . . . . 4.3 News Applications . . . . . . . . . . . . . . . 4.3.1 ANU NEWS . . . . . . . . . . . . . . . . 4.3.2 NEWSRDR . . . . . . . . . . . . . . . . . 4.3.3 FNEWS . . . . . . . . . . . . . . . . . . 4.4 World Wide Web Applications . . . . . . . . . . 4.4.1 MOSAIC . . . . . . . . . . . . . . . . . 4.4.2 LYNX . . . . . . . . . . . . . . . . . . 4.4.3 HTTP_SERVER . . . . . . . . . . . . . . . 4.5 File Transfer Applications . . . . . . . . . . 4.5.1 MADGOAT FTP . . . . . . . . . . . . . . . 4.5.2 C-KERMIT . . . . . . . . . . . . . . . . 4.5.3 FSP . . . . . . . . . . . . . . . . . . . 4.6 Network Archive Search Applications . . . . . . 4.6.1 ARCHIE . . . . . . . . . . . . . . . . . 4.7 Gopher Applications . . . . . . . . . . . . . . 4.7.1 GOPHER . . . . . . . . . . . . . . . . . 4.8 Finger Applications . . . . . . . . . . . . . . 4.8.1 MADGOAT FINGER . . . . . . . . . . . . . 4.9 Domain Name Server Applications . . . . . . . . 4.9.1 NSQUERY . . . . . . . . . . . . . . . . . 4.9.2 IPADDR . . . . . . . . . . . . . . . . . 1.0 GENERAL INFORMATION --------------------------- 1.1 >>>> WHAT IS OPENCMU [11-OCT-1994] ------------------------ The OpenCMU software provides a full TCP/IP network transport for VAX systems running the VMS operating system. This allows a VMS system to participate in the world wide Internet network and take advantage of the wealth of information and software available on it. OpenCMU includes the following components as standard: o TELNET for interactive access to other systems on the internet o TELNET Server for allowing interactive login to the system running OpenCMU o FTP for transferring files directly to and from other systems on the internet o FTP Server for allowing file transfer to and from the system running OpenCMU. An ANONYMOUS login facility is included. o FINGER for identifying users logged on on other systems on the internet o FINGER Server for allowing others to finger users logged in to the system running OpenCMU o TALK for interactive converstations with other users on the internet (a sort of network PHONE) o TALK Server for allowing other users to talk to anyone logged on to the system running OpenCMU. o LPD for processing incoming print file requests and status from clients. o LPRSMB for submitting files to printers attached to other systems on the internet. o IPNCP for monitoring and controlling the TCP/IP system o UNIXSHR - A TCP/IP socket library o DECW$TRANSPORT_CMU - shareable DECwindows transport for running X11 applications over OpenCMU TCP/IP. Support is provided for: o IP over ethernet o IP Over X.25 o IP Over DECnet o IP over Serial lines (SLIP) At this time, there is no support for: o Compressed SLIP o PPP o Rlogin, Rexec, Rsh Also Supported: o Electronic mail is supported via the Freeware packages MX and NETLIB (see elsewhere in this FAQ for details). o Domain Name Service is supported through the freeware DOMAIN package by Bruce Orchard. Usually available from the same sites as OpenCMU. Note: o Electronic mail support is also provided by the chargeable PMDF package available from Innosoft. Contact them for details. -------------------------------------------------------------------------------- 1.2 >>>> OBTAINING THE OPENCMU SOFTWARE [11-OCT-1994] --------------------------------------- The OpenCMU software is entirely free of charge and may be obtained through your local DECUS representative. The last relevant symposium tape that contains the OpenCMU software is the Fall 1992 tape, in directory [VAX92B.CMU] and on DECUS CDROM #12. A number of sites on the Internet maintain up to date anonymous FTP directories containing the OpenCMU software. These can be accessed using the FTP program or a mail server such as FTPMAIL that can transfer files from an anonymous FTP account back to the requestor via e-mail. The following systems maintain up to date OpenCMU kits: Master Sites: SiteName Directory Maintainer SACUSR.MP.USBR.GOV [.CMUIP]] Henry Miller [.TEKIP.FTP] [.TELNET] Mirror Sites: SiteName Directory Maintainer FTP.KCL.AC.UK [.CMU-TCPIP] Andy Harper FTP.CSUS.EDU pub/cmuip ??? DMC.COM [.VMS.CMUIP] ??? marduk.iib.uam.es /pub/VMS/cmutek-ip J.R.Valverde The first time you obtain OpenCMU, you will very likely not have an existing network facility and hence will be unable to obtain the software across the network. In this case, you should contact your local DECUS representative for a copy of the software on a suitable media. Subsequently, you can pick up new versions and patches using the network from many of the sites listed above. Announcements about these are made to the OpenCMU mailing list. -------------------------------------------------------------------------------- 1.3 >>>> PREREQUISITES [11-OCT-1994] ---------------------- Before installing OpenCMU on your system, take note of the following requirements. Hardware Requirements: A Digital VAX system. NOTE: Digital ALPHA systems are NOT currently supported. A Network connection. OpenCMU supports the following types of network interface: * Ethernet * Serial line (using SLIP) * X.25 Synchronous interface (using IP tunnelling) A network link to the outside world. The network interface must be connected to a network with at least one other network aware system connected to it. Consult your local site management or network service providers for details of how to connect to the rest of the IP world (the `Internet'). Each interface to the network MUST be allocated its own unique IP address (your service provider will supply this) and a subnet mask. Although optional, it is highly likely that access to an IP router and a Domain Name Server will be required. Ask your service provider for the IP addresses of each of these. Minimum VMS: The latest version of OpenCMU requires VMS 5.2 and upwards. There are versions of OpenCMU available that run on earlier versions of VMS. Poke around some of the FTP sites listed elsewhere to see what's available as some sites do not carry old versions. -------------------------------------------------------------------------------- 1.4 >>>> CURRENT VERSIONS OF OPENCMU [11-OCT-1994] ------------------------------------ Base Version: OpenCMU 6.6-5 Kit: CMUIP066.% { % = A,B,C,D } Update Kits: OpenCMU 6.6-5A Kit: TEKIP0665A.SAVE Telnet 5.0-1 Kit: TELNETU1050.A FTP 2.12 Kit: FTPU0212.A -------------------------------------------------------------------------------- 1.5 >>>> THE OPENCMU MAILING LIST/NEWSGROUP [11-OCT-1994] ------------------------------------------- An electronic mailing list and news group exists for exchanging information about the OpenCMU software. This is the preferred way to exchange information about problems, and their solutions, and to announce updates to the software. By subscribing, you gain access to a wealth of practical information from other users and the relevant OpenCMU experts. The address of the electronic mailing list, to which all enquiries or announcements are directed, is: CMU-OpenVMS-IP@DRYCAS.CLUB.CC.CMU.EDU Subscribe by sending a message to: CMU-OpenVMS-IP-Request@DRYCAS.CLUB.CC.CMU.EDU For those with access to USENET, the world-wide electronic NEWS system, this mailing list is automatically gatewayed to the newsgroup: vmsnet.networks.tcp-ip.cmu-tek You are recommended to subscribe to the newsgroup wherever possible, in preference to the electronic mailing list. Details of some suitable news readers can be found elsewhere in this document. 2.0 COMMONLY ASKED `SETUP' QUESTIONS ---------------------------------------- 2.1 >>>> SETTING UP DEC WINDOWS OVER OPENCMU [11-OCT-1994] -------------------------------------------- NOTE: This summary applies to the LATEST version of OpenCMU. There may be minor differences applying it to earlier versions. +===========================================================================+ | Example of the installation of dec$transport_cmu of OpenCMU V6.6-5A | +===========================================================================+ 1. Copy DECW$TRANSPORT_CMU.exe to sys$common:[syslib]decw$transport_cmu.exe ( Note: Although the change of $ to _ is required (see 5.3 upgrade and installation procedures section 10.4, p.10-)7, I didn't do so. But it works) 2. Set protections on the file as -- S:rwed,O:rwed,g:rwed,w:re 3. Add the following record in IP_STARTUP.COM if it is not already there: $ install create sys$share:decw$transport_cmu.exe /open/share/header/prot 4. Customize decw$private_server_setup.com to have the following line: $ decw$server_transports == "DECNET,LOCAL,LAT,CMU" Eg. Copy decw$private_server_setup.template to *.com in Sys$common:[sysmgr] directory and add one record as follows; $do_default: >>> $ decw$server_transports == "DECNET,LOCAL,LAT,CMU" $ exit 5. Reboot workstation. If IP is already setup and running, it should be sufficient to merely restart DECwindows via the following command: $ @sys$manager:decw$startup restart 6. Security Entry on VAX/VMS+CMU If you are using VAX/Station(VMS+CMU) and you want to create a window on the VAX/Station (i.e. you want to use it as a "server"), it is required to customize security by adding as "authorized user" the OpenCMU transport for the users and machines desired. (Select security in the setup menubar of VAX/Station and add following entry NODE: IP-address or domain-name (Eg. 134.160.1.1) USER nam ? or * (Eg. *) Transport: CMU (Eg. CMU) If you want use your VAX only as a client or your VAX is not workstation, it is not necessary to define the security entry. 6.1 Security entry on UNIX workstation (eg. SUN + X11 Release 4) If you want to communicate with a UNIX workstation running X11R4, it is also required to define the security entry of the hostname on the UNIX. There are two ways to define the security entry (1) Write hostname in /etc/X*.hosts file. (* is display number) (2) Define hostname by "xhost" command. (this works only in the local terminal. This does not work on the telneted terminal) You can get more information by "man X" and "man xhost" command in UNIX. X11 Release 4 entire kit and its patch are available for anonymous ftp from expo.lcs.mit.edu in pub/R4 directory 7. Then you can create a X-window from UNIX or on UNIX Eg. 1 (create a X-terminal on VAX/Station from SUN [SUN OS 4.0.3+X11R4] ) (% xhost hostname (authorize hostname, see 6.1)) % setenv DISPLAY hostname:0 (define display) % xterm & (Create a X-terminal of sun on VAX/VMS) Eg. 2 (create a DEC-terminal on SUN from VAX/Station) $ set disp/cre/node="hostname"/tran=CMU $ cre/term/det PS: And another one of Bruce's unsolicited tips: (Following is applied only for X11-server [i.e. VAX/Station] ) After you bring up the transport with DECWindows, do a NETSTAT to see if the transport was initialized to wait for incoming connections. You should see a TCP port at port 6000 in the LISTEN state. If not, you've done something wrong. Example $ IPNCP IPNCP> netstat 1 TCP connection found IDX Address Local Host Port Foreign Host Port State 2 0004C188 0.0.0.0 23.112 0.0.0.0 0.0 LISTEN 0 UDP connections found -------------------------------------------------------------------------------- 2.2 >>>> SETTING UP A SLIP CONNECTION [11-OCT-1994] ------------------------------------- Ensure that the SLIP Driver (SLDRV.EXE) is in the CMUIP_ROOT:[SYSLIB] directory. To create a slip line include the following in your INET$CONFIG: Device_Init:SLDRV:dev:NONE:ip-address:ip-mask Where: DEV is the terminal line to use eg. TXA1 ... ip-address is the Ip-address of the line. ip-mask is the IP-mask of the line. Here is an example line: Device_Init:SLDRV:TXA0:NONE:123.123.123.123:255.255.0.0 Defines a slip port on TXA0 having an IP address of 123.123.123.123 Then kill and restart IPACP: IPNCP IPNCP> netexit IPNCP> Startup/ipacp As far as I know there is no dynamic SLIP available. However there is a new IPACP/IPNCP in the works that will allow you to add/enable/disable SLIP lines on the fly. -------------------------------------------------------------------------------- 2.2 >>>> MORE ON SETTING UP SLIP [11-OCT-1994] -------------------------------- The information below has been culled mostly from personal experience (i.e., it works for me). All IP addresses have been changed. The reason for this is that OpenCMUIP SLIP doesn't require a password -- if you know the IP address of the SLIP interface, and the phone number to dial, you can get in. Also, any explanations given below are not necessarily completely correct; I've tried to put everything in simple terms that I understand. Those caveats given, here goes... First, in INET$CONFIG, you need to have *two* separate interfaces: one that talks to the SLIP "network", and one that talks to the Ethernet "network". These two interfaces each have their own addresses. If they "overlap" (this will be defined later), the interface to the more general network must come *last*. Example: in my configuration (remember: *all* ip addresses have been changed; OpenCMUIP SLIP doesn't bother to ask for a password for connection purposes, so anyone who knows the phone number of your modem and the IP address of your SLIP interface can connect through your system), I have a VAX with an Ethernet interface at IP address 128.97.101.101. We use subnetting here at UCLA, and our network mask is 255.255.255.0. This means that my VAX can directly connect to any computer whose address is 128.97.101.x, where x is in the range 0-255 (although I believe the first and last are off limits). To get to any computer with an address not in this range, I need to go through a gateway. In my case, the gateway is at 128.97.101.105. Note that I can directly connect to this computer. This is, of course, important. So, I need a line in INET$CONFIG that says something like Device_Init:ETHER:ESA0:00-00-00-00-00-00:128.97.101.101:255.255.255.0 and further down, one that reads Gateway:GATEWAY.PHYSICS.UCLA.EDU:128.97.101.105:0.0.0.0:0.0.0.0: Now, I want to start a SLIP interface with a modem attached to the device TTA2. I am assigned the address range 128.97.101.120 through 128.97.101.127. This is a total of eight addresses, but again, the first and last are not usable for reasons I don't understand (I think the operative terms are "network address" for the .0 one and "broadcast address" for the .127 one). At this point, the six remaining addresses belong to *me*, and are mine to assign as I wish. I choose to assign the first one to the SLIP interface itself: slip.physics.ucla.edu = 128.97.101.121 I have a computer at home (say it's a PC). I choose to assign this the next address: mypc.physics.ucla.edu = 128.97.101.122 These names must be established with the network administrator, but I am free to dole out the addresses to whomever I choose. Note that by the rules above, the ethernet connection can speak directly to mypc. This is incorrect, since that must go through the SLIP interface. This is what I have called overlap above. The range of SLIP addresses (.120 - .127) lies within that of Ethernet addresses (.0-.255). We therefore need a way to tell OpenCMUIP to use the SLIP interface for the addresses .120-.127, and the Ethernet interface for all the others. We do this simply by placing the SLIP device definition first, so that the Device_Init lines now look like: Device_Init:SLDRV:TTA2:slip.physics.ucla.edu:128.97.101.121:255.255.255.248 Device_Init:ETHER:ESA0:00-00-00-00-00-00:128.97.101.101:255.255.255.0 The only new thing here is the mask on the SLIP interface. That mask has all bits set to 1 except the last three. This means that there are eight addresses (2^3) that the SLIP interface can access, which work out to .120-.127. If OpenCMUIP wants to connect to one of these addresses, it does it through the SLIP interface. If it wants to talk to anything else with an address of 128.97.101.x, it does it through the Ethernet interface. Any other address is contacted via the gateway (which itself is contacted via the Ethernet interface). The only other thing to do is to set the IP_Forwarding flag. This allows OpenCMUIP to transmit packets from one interface to the other. without this, you couldn't use SLIP to get to the outside world: Variable:IP_Forwarding:1 That should be it. Restart OpenCMUIP, and all should be well. One other thing: many SLIP packages on the PC/Mac side expect to give the system some kind of password upon connection, and will fail if they don't receive a response from the VAX. This needs to be turned off, since the VAX won't do a thing other than just sit there. -------------------------------------------------------------------------------- 2.4 >>>> HOW TO SET UP ANONYMOUS FTP [11-OCT-1994] ------------------------------------ Note: following information taken from the FTP client release notes, with minor editing to add additional info. 2.4.1 RPI Modifications 2.4.1.1 V2.7-5, 20-JUN-1989, Madison > All FTP_ANON logical names should now be placed in the logical name table FTP_NAME_TABLE, to get them out of the system name table. To do this, add the following lines to your IP_STARTUP.COM: $ CREATE/NAME_TABLE/EXEC/PROT=(S:RWED,O:RWED,G:R,W:R)- /PARENT=LNM$SYSTEM_DIRECTORY FTP_NAME_TABLE $ FTPDEF := DEFINE/TABLE=FTP_NAME_TABLE/EXEC/NOLOG then use FTPDEF to define the FTP_ANON... logical names, for example: $ FTPDEF FTP_ANONYMOUS_DIRS USER$:[ANONYMOUS...] $ FTPDEF FTP_ANON_LOAD_THRESHOLD "0.5" $ FTPDEF FTP_ANON_PRIME_DAYS "2,3,4" ! Tuesday, Wednesday, Thursday > Added system load checking on anonymous logins if LAV0 device is available. To enable, define the following logical names in FTP_NAME_TABLE: FTP_ANON_LOAD_THRESHOLD some floating-point number between 0.0 and 1.0. FTP_ANON_PRIME_DAYS day-numbers -- indicate "prime time" days FTP_ANON_PRIMETIME_START time-of-day -- indicates start of "prime time" FTP_ANON_PRIMETIME_END time-of-day -- indicates end of "prime time" FTP_ANON_TIME_ZONE any character string indicating local time zone The only required logical is FTP_ANON_LOAD_THRESHOLD. If that logical name exists and the LAV0 device exists, the load checking code is used. The code does the following: If FTP_ANON_PRIME_DAYS is defined, it is translated. The comma-separated list of numbers (where 1=Monday, 2=Tuesday, etc.) is used to identify the days in which "prime time" is effective. If it does not exist, "prime time" is assumed to be in effect Monday through Friday. Note: Use ONLY numbers 1 through 7, and NO SPACES in the string. Surround the string with quotation marks when defining! If FTP_ANON_PRIMETIME_START is defined, it is translated and converted into a system date-time value using LIB$CONVERT_DATE_STRING. If not, then 09:00 is used as the start of "prime time". If FTP_ANON_PRIMETIME_END is defined, it is translated and converted into a system date-time value using LIB$CONVERT_DATE_STRING. If not, then 17:00 is used as the end of "prime time". If the current time is between the prime-time start and end times, then the current load averages are read from the LAV device. The current load is computed using the following formula: load = M15 * (P15 / 4.0) where M15 is the average load over the last 15 minutes, and P15 is the average priority over the last 15 minutes. Thus, the average load is normalized against typical interactive priority to guard against low-priority batch jobs preventing guest login access. If the load is greater than or equal to the LOAD_THRESHOLD value, then the guest login is denied with a reason of "system too busy". If the threshold is not exceeded, then the guest login is accepted, but the user is warned to minimize access during prime time (with the start and end times displayed along with the time zone information [if FTP_ANON_TIME_ZONE is defined]). If the current time does not fall within prime time, no load checking is performed. 2.4.1.2 V2.7-4, 09-JUN-1989, Madison > Added special messages to FTP server during guest (anonymous) login. Modified the logging of anonymous sessions slightly. 2.4.1.3 V2.7-2, 03-APR-1989, Madison > The FTP server presents a somewhat more informative banner on connection-- includes system name and version of FTP. > The code that handled directory changes was really ugly, even though it had been modified to fix the infinite-loop problem from V2.6. I replaced the code with some which makes use of available VMS system services, simply to satisfy my own sense of aesthetics. > Enhanced the Anonymous FTP support provided by OpenCMU. The enhancements include: * ANONYMOUS is never allowed privileges regardless of the contents of its UAF record. * All ANONYMOUS FTP sessions create logs. Each session creates a file SYS$MANAGER:ANON_FTP_LOG.LOG. You can put them elsewhere by defining ANON_FTP_LOG system-wide to a different location. The password given to ANONYMOUS is logged along with the remote host's name and address, as well as RETR, LIST, NLST, CWD, and CDUP commands. The log files need not be accessible to the ANONYMOUS userid (and probably should not be). NOTE: It appears that the anonymous log file is ONLY created in SYS$MANAGER if the ANON_FTP_LOG logical name is explicitly defined. By default, no log file gets created. Use: $ define/system ANON_FTP_LOG sys$manager:ANON_FTP_LOG.LOG * You can restrict the directories to which ANONYMOUS has access by defining the system-wide logical name FTP_ANONYMOUS_DIRS to a search list of device/directory specifications. Any RETR, LIST, or NLST will check against this list before going through normal system access checks. This prevents ANONYMOUS from gaining access to people's files via WORLD access. If you do not define FTP_ANONYMOUS_DIRS, the extra access checks do not take place. You can use [directory...] notation to allow access to the entire subdirectory tree below the specified directory. The steps needed to set up a controlled Anonymous FTP are: 1. Create a UAF record for ANONYMOUS. Set it /NOINTER/NOBATCH/NONETWORK to prevent logins or DECnet use. Set /FLAG=DISMAIL to prevent mail from reaching it. Assign it a UIC that is unique and outside any existing group. Give it a default device and directory. Example: UAF> ADD ANONYMOUS/PASS=JUNK/NOINTERACTIVE/NOBATCH/NONETWORK- /FLAG=DISMAIL/UIC=[666,666]/DEV=USER$DISK/DIR=[PUBLIC] 2. Put the definition of FTP_ANONYMOUS_DIRS in your system startup sequence. Make sure it is defined before allowing Anonymous access. Make sure that the default device/directory in the UAF is accessible (not strictly necessary, but easier on the users). Example: $ DEFINE/SYSTEM FTP_ANONYMOUS_DIRS - USER$DISK:[PUBLIC...],- ! public files USER$DISK:[NEWS...],- ! news archives USER$DISK:[MAIL] ! mail archives 3. Create the directories to which ANONYMOUS will have access. Do not permit ANONYMOUS to own any of the files or be in the same group as the owner of the files. Set WORLD:R protection on all files and directories to be accessible, or use an ACL to grant access specifically to ANONYMOUS. While these modifications were meant to enhance the security of Anonymous FTP, neither the author nor his employer (nor anyone else for that matter) guarantees that the software is secure. NOTE: The Load Average Driver (LAVDRIVER) referred to in this article can be obtained from a number of public archive sites. Here are some possibilities: Availability via Anonymous FTP: =============================== -------------------------------------------------------------- Site Directory File(s) Format -------------------------------------------------------------- ftp.kcl.ac.uk [.default] lavdriver.* VMS_SHARE -------------------------------------------------------------- Availability via Electronic Mail: ================================= -------------------------------------------------------------- Address Command to send Format -------------------------------------------------------------- VMSSERV @ KCL.AC.UK SEND LAVDRIVER.PACKAGE VMS_SHARE -------------------------------------------------------------- -------------------------------------------------------------------------------- 2.5 >>>> SETTING UP OPENCMU WITH OPENVMS 6.0 AND 6.1 [11-OCT-1994] ---------------------------------------------------- Following the upgrade to OpenVMS 6.0 or 6.1, OpenCMU 6.6-5A can be made to work by issuing the following sequence of commands: $ @sys$update:register_privileged_image register cmuip_root:[sys$ldr]ipdriver.exe $ @sys$update:register_privileged_image register cmuip_root:[sysexe]ipacp.exe $ @sys$update:register_privileged_image register cmuip_root:[sysexe]lpd.exe Failure to do this will likely result in error messages similar to: "System version level mismatch" and the network will fail to come up. 3.0 KNOWN PROBLEMS ------------------ 3.1 >>>> WHY IS FTP SO SLOW [11-OCT-1994] --------------------------- The version of FTP supplied with the master 6.6-5 kit suffers from a number of bugs. One of these causes excessive error rates and retransmissions resulting in a low throughput rate. It is STRONGLY recommended that the 6.6-5A patch kit be applied. This greatly improves the performance. See also the freeware MGFTP software (described in more detail in the `Software' section elsewhere). -------------------------------------------------------------------------------- 3.2 >>>> WHY DOES FTP CRASH WITH `EXCEEDED QUOTA' [11-OCT-1994] ------------------------------------------------- FTP (client or server) can fall over with an `exceeded quota' message if the SYSGEN parameter `MAXBUF' is not set correctly. The latest recommendation is for the minimum value to be 2300. In practice, however, a much larger figure of 8300 is recommended. Note that transferring files with large records, exceeding MAXBUF, may still cause problems. -------------------------------------------------------------------------------- 3.3 >>>> WHY DOESN'T THE NFS SERVER WORK [11-OCT-1994] ---------------------------------------- The NFS server broke with version 6.6-5 of OpenCMU. At this time, there is no workable solution. IF NFS is a requirement, version 6.6-4 is the last version in which NFS works. -------------------------------------------------------------------------------- 3.4 >>>> WHY DOES TELNET SOMETIMES HANG IN `RWAST' [11-OCT-1994] -------------------------------------------------- TELNET clients prior to version 5.0 could, under certain conditions, lock up a process in an RWAST state. All users are strongly recommended to upgrade to Version 5.0-1 of TELNET in which this problem, and others, are solved. -------------------------------------------------------------------------------- 3.5 >>>> WHY DOES TELNETTING INTO OPENCMU HANG [11-OCT-1994] ---------------------------------------------- When telnetting into a OpenCMU host, the system does not prompt for a username until an extra carriage return appears. There are three known, unrelated, causes for this problem. First, a bug in earlier versions of the CMU telnet software is known to cause unexpected hangs. To fix this, All users should install the latest patches to OpenCMU (6.6-5A) and the telnet client. Second, some PC telnet clients are known to contain problems that prevent them successfully interworking with CMU telnet. PC-NFS telnet versions 4.x and 5.x suffer from this problem. To fix, avoid these clients - there are plenty of reasonable alternative telnet clients around. Finally, it may be the case that some PC telnet's do not correctly negotiate the telnet options when the call is connected. One or other end can wait indefinitely for the opposite end to continue. At this time, no clear solution is known but the problem can sometimes be alleviated by adding the following to the CMU INET$CONFIG file: Variable:TELNET_NEG_TIMEOUT:0 This causes telnet not to wait for negotiations to timeout, and can speed up those logins which appear to hang for a long time. -------------------------------------------------------------------------------- 3.6 >>>> NAMRES GIVES DOMAIN REFERRAL EXCEEDED MESSAGES [11-OCT-1994] ------------------------------------------------------- The name resolver can produce the message `Maximum domain referral limit exceeded' and fail to resolve a name into its address. This is often indicative of incorrect configuration of the name resolver. Ensure that the following lines are included in the NAMRES$CONFIG file: Variable:TIMEOUT:5 Variable:REFMAX:10 Variable:RECURSE:1 You might want to also add: Variable:NS_RETRANS:2 (NOTE: in table 3-8 of the last official manual, the last variable, labelled TIMEOUT, should be labelled RECURSE. TIMEOUT is given correctly as the second entry in the table). Restart the name resolver if necessary: $ IPNCP IPNCP> NAMRES EXIT .... IPNCP> STARTUP /NAMRES -------------------------------------------------------------------------------- 3.7 >>>> IPACP ISSUES STATUS CODES TO OPCOM [11-OCT-1994] ------------------------------------------- When the IPACP process (which coordinates the IP traffic) has problems, it can issue system status codes to OPCOM. Here is a typical sequence: %%%%%%%%%%% OPCOM 16-AUG-1993 10:49:23.75 %%%%%%%%%%% Message from user SYSTEM on XYZZY IPACP: XE status error. Status = 00000A00 %%%%%%%%%%% OPCOM 16-AUG-1993 10:49:23.83 %%%%%%%%%%% Message from user SYSTEM on XYZZY IPACP: XE retried 5 times. %%%%%%%%%%% OPCOM 16-AUG-1993 10:49:23.89 %%%%%%%%%%% Message from user SYSTEM on XYZZY IPACP: XE $QIO read error (dev_inact), RC=000020D4 To determine the exact problem, it is first necessary to translate the status codes (00000A00 and 000020D4) into the more usual text form. The DCL lexical function F$MESSAGE will translate them for you. Here is a little command file to make it easier: $! SHOWMSG.COM $! Usage: @SHOWMSG 20D4 $ WRITE SYS$OUTPUT F$MESSAGE(%X'P1') Typically, the messages are indicative of a problem with the ethernet itself or with the ethernet controller; the status messages may help to determine the root cause. The message texts from OpenCMU are not part of the standard system message files. For a translation of the error code into the text to be possible, the user must have issued a SET MESSAGE command on the file NETERROR.EXE. The installation of OpenCMU should have placed this in the SYS$MESSAGE directory. If not, locate the file called NETERROR.OBJ in the CMUIP_ROOT:[*...] tree and relink it to form the NETERROR.EXE, using this command: $ LINK/SHARE=SYS$COMMON:[SYSMSG]NETERROR NETERROR.OBJ Following this, the message texts can be made available to F$MESSAGE using: $ SET MESSAGE SYS$MESSAGE:NETERROR [Note: if, for any reason, NETERROR.OBJ does not exist in the directory tree, it can be found in the second saveset of the OpenCMU kit - CMUIP066.B] -------------------------------------------------------------------------------- 3.8 >>>> IPACP CRASH DUE TO QUOTA EXCEEDED [11-OCT-1994] ------------------------------------------ For systems with a high IP load, IPACP may occasionally crash with a quota exceeded. This does not refer to disk quota, but to one of the process quota limits. Usually, the quota in question is BYTLM. To increase the BYTLM for the IPACP, modify the IP_STARTUP.COM procedure and change the value of the /BUFFER_LIMIT qualifier on the RUN command that starts the IPACP process. Then shut down and restart IPACP. At the current time, there appears to be a memory leak in IPACP which has the effect of gradually reducing the available BYTLM over time. When this gets close to zero, IPACP will hang (as it retries) and then crash soon afterwards. It is therefore desirable to give IPACP more BYTLM than the typical load might suggest. If this sort of crash is experienced, increase the BYTLM by 50% and restart it. -------------------------------------------------------------------------------- 3.9 >>>> FTP OF BACKUP SAVESETS GIVES CRC ERRORS [11-OCT-1994] ------------------------------------------------ One major use of FTP is in transferring BACKUP savesets to/from other systems. Often this leads to the recipient having difficulties unpacking that saveset; in particular, using BACKUP to list or unpack it results in a stream of messages similar to `CRC error' to the user's terminal and to OPCOM. This article summarizes why the error occurs and how to correct it. When BACKUP creates a saveset, it writes the file with a fixed length record format - the length being that specified with BACKUP's /BLOCK qualifier. For example: BACKUP/BLOCK=8192 * s.bck/save Creates a file with fixed length records of 8192. When FTP is used, in binary mode, the data is sent correctly but the record structure changes; typically, it is created with 512 byte records. Thus, when BACKUP is used to list or unpack the file contents, it finds that the record length of the file does not match the size used originally (this value is stored in the BACKUP saveset header as well as in the file header). If both ends of the FTP session support the special STRUC VMS mode of transfer, then it should be used and the file will transfer correctly. If this structure is not supported, the record structure becomes corrupted and must be manually `fixed up' before BACKUP can be used. There are three ways in which this can be done. 1. Use the VMS CONVERT utility to alter the record structure: $ CONVERT/FDL=SYS$INPUT file.bck file.bck RECORD FORMAT FIXED SIZE nnnn ^Z Where 'nnn' is the record size used on the original BACKUP command. NOTE: a new copy of the file is made. 2. Use the public domain utility called FILE (courtesy of Joe Meadows): $ FILE/RECORD_SIZE=nnn file.bck Where 'nnn' is the record size used on the original BACKUP command. NOTE: this utility does NOT make a copy of the file; instead it patches the file header directly. It is wise to make a backup copy before using this technique!!! 3. Use the public domain utility called FIX_SAVESET (author unknown): $ FIX_SAVESET file.bck This utility scans the file, on the assumption that it is a backup saveset; picks out the original record length from the backup saveset header stored in the file; and finally, patches the file header record size back to this length. A new copy of the file is not made. Both the FILE and FIX_SAVESET utilities are available from a number of public archives using anonymous FTP. Here are some possibilities: Availability via Anonymous FTP: =============================== -------------------------------------------------------------- Site Directory File(s) Format -------------------------------------------------------------- ftp.kcl.ac.uk [.default] fix_saveset.* VMS_SHARE ftp.kcl.ac.uk [.joemeadows] file.* VMS_SHARE -------------------------------------------------------------- Availability via Electronic Mail: ================================= -------------------------------------------------------------- Address Command to send Format -------------------------------------------------------------- VMSSERV @ KCL.AC.UK SEND FIX_SAVESET.PACKAGE VMS_SHARE VMSSERV @ KCL.AC.UK SEND FILE.PACKAGE VMS_SHARE -------------------------------------------------------------- Finally, to summarize the correct method of transferring a BACKUP saveset using FTP: 1. If both ends support STRUC VMS, then a. ftp> SET STRUC VMS b. ftp> GET file File will be stored locally with the correct attributes. 2. If STRUC VMS is not supported by one or both ends, then a. ftp> BINARY b. ftp> GET file Once file arrives on the VMS system: c. FIX_SAVESET file 4.0 >>>> PUBLIC DOMAIN SOFTWARE THAT SUPPORTS OPENCMU ----------------------------------------------------- In this section is described a number of network applications which are known to work with the OpenCMU transport. Volunteers are always required to port other network applications to the latest OpenCMU release. If you port anything, please notify the FAQ maintainer and the OpenCMU mailing list. Also, please try to persuade the original author of any ported application to include your OpenCMU changes in the official release. This will greatly reduce the amount of work needed to track the latest releases of software. 4.1 >>>> TCP/IP TRANSPORT INTERFACE LIBRARIES [10-OCT-1994] --------------------------------------------- There are a number of different TCP/IP transports available for OpenVMS. These include: UCX Digital's own TCP/IP OpenCMU The Carnegie-Mellon University implementation Multinet TGV Inc. Pathway Access The Wollongong group TCPware Process Software For historical reasons, each package has a slightly different application level interface, which makes writing portable TCP/IP applications harder than it should be. The software in this section provide interfaces to one or more of the available transports, providing a consistent interface for applications irrespective of which TCP transport is in use. All adopt the widely recognized `socket' interface used by BSD unix and others but in some cases the syntax used is different. Using an interface with the same syntax as BSD sockets should make it much easier to port programs between VMS and unix systems, and any other systems that come along. Some of the applications described in this section require a specific socket library interface, so it may be necessary to install two or more of them on a given system to get all the applications to run. In terms of portability, the best socket libraries are `SOCKIT' and the `SOCKETSHR/NETLIB' combination, as these interface to two or more of the commonly available transports. 4.1.1 >>>> NETLIB [10-OCT-1994] ----------------- Summary: A vendor independent TCP/IP programming interface. Description: NETLIB solves the problem by providing a vendor-independent programming interface that sits between the application and the particular version of TCP/IP installed on the system. Thus, applications can be written in terms of NETLIB routines and will run over any transport supported by NETLIB. Transports Supported: NETLIB supports OpenCMU; also, Multinet, TCPware, UCX and TWG's Win/TCP and Pathway Access. Anyone writing network applications should be strongly encouraged to use the NETLIB interface. Interface Type: Similar to BSD sockets in concept but not in syntax. See SOCKETSHR package. Author: Matt Madison Pre-Requisites: NONE, except for one of the supported TCP/Ip transports listed above. Availability via Anonymous FTP: -------------------------------------------------------------- Site Directory File(s) Format -------------------------------------------------------------- ftp.spc.edu [.macro32.savesets] NETLIBnnn.zip ZIP ftp.kcl.ac.uk [.madgoat] NETLIB.* VMS_SHARE -------------------------------------------------------------- Availability via Electronic Mail: -------------------------------------------------------------- Address Command to send Format -------------------------------------------------------------- VMSSERV @ KCL.AC.UK SEND NETLIB.PACKAGE VMS_SHARE FILESERV@ WKUVX1.WKU.EDU SEND NETLIB VMS_SHARE, MFTU, ZIP -------------------------------------------------------------- NOTE: `nnn' is a version number - replace with the latest version. 4.1.2 >>>> SOCKETSHR [10-OCT-1994] -------------------- Summary: A BSD sockets interface to NETLIB Description: SOCKETSHR provides a complete socket library that allows applications to be written with complete independence of the underlying network transport. It is written to interface to the NETLIB software, which provides an interface to all the available TCP/IP transports for VMS. A recommended package for all users who are writing or porting network applications. Transports Supported: All those supported by NETLIB Interface Type: BSD sockets compatible Author: Thanks go to Eckart Meyer for making this package available, and to Mike O'Malley, on whose LIBCMU package this is based. Pre-Requisites: To use SOCKETSHR, the NETLIB package is a pre-requisite; to use SOCKETSHR with UDP applications requires NETLIB version 1.7 as a minimum! Availability via Anonymous FTP: -------------------------------------------------------------- Site Directory File(s) Format -------------------------------------------------------------- ftp.ifn.ing.tu-bs.de [.VMS.SOCKETSHR] SOCKETSHR*.ZIP ZIP ftp.kcl.ac.uk [.default] SOCKETSHR.* VMS_SHARE -------------------------------------------------------------- Availability via Electronic Mail: -------------------------------------------------------------- Address Command to send Format -------------------------------------------------------------- VMSSERV @ KCL.AC.UK SEND SOCKETSHR.PACKAGE VMS_SHARE -------------------------------------------------------------- 4.1.3 >>>> SOCKIT [10-OCT-1994] ----------------- Summary: A socket library interface for VMS network applications Description: SOCKIT provides an emulation of the BSD socket routines for VMS. The interesting thing about this package is that it will interface to several of the commonly available TCP/IP transports, OpenCMU included. Transports Supported: CMU Wollongong UCX (thus works with Multinet if UCX emulation on!) X.25 Interface Type: BSD sockets compatible Author: Peter Kay Pre-Requisites: NONE. The code to interface to each transport is built-in. Availability via Anonymous FTP: -------------------------------------------------------------- Site Directory File(s) Format -------------------------------------------------------------- ftp.kcl.ac.uk [.default] SOCKIT.* VMS_SHARE -------------------------------------------------------------- Availability via Electronic Mail: -------------------------------------------------------------- Address Command to send Format -------------------------------------------------------------- VMSSERV @ KCL.AC.UK SEND SOCKIT.PACKAGE VMS_SHARE -------------------------------------------------------------- 4.1.3 >>>> LIBCMU [10-OCT-1994] ----------------- Summary: A socket library interface for OpenCMU Description: LIBCMU is a purpose built library of routines for interfacing applications that use Berkeley sockets to the OpenCMU programming interface. This library allows a number of applications written for sockets to be easily ported to OpenCMU. Transports Supported: CMU InterFace Type: BSD sockets compatible Author: Thanks go to Mike O'Malley for writing and maintaining the LIBCMU software. Availability via Anonymous FTP: -------------------------------------------------------------- Site Directory File(s) Format -------------------------------------------------------------- kermit.columbia.edu vms-libcmu ckvlcmu.hex HEX of backup saveset ftp.kcl.ac.uk [.cmu-tcpip] LIBCMU.* BACKUP -------------------------------------------------------------- 4.2 >>>> MAIL APPLICATIONS [10-OCT-1994] -------------------------- Electronic mail is one of the main applications used over TCP/IP networks. It allows messages to be sent from one user to another even though they are on opposite sides of the world. Provided the users both have access to a computer system running compatible mail software, messages can be sent easily. OpenCMU does not provide any mail applications. Instead one or more of the applications listed below are recommended. 4.2.1 >>>> MX ELECTRONIC MAIL [10-OCT-1994] ------------------------------- Summary: A comprehensive SMTP based network mail system that interfaces directly into VMS MAIL and the underlying TCP/IP network. Description: MX provides full SMTP mail support and interfaces to VMS MAIL. It also provides a mailing list and file server facility. MX is completely free of charge and may be obtained from your local DECUS representative or from the sites listed below. Pre-Requisites: MX requires the NETLIB interface library. Author: Matt Madison and Hunter Goatley (C) MadGoat Software ltd. Availability via Anonymous FTP: -------------------------------------------------------------- Site Directory File(s) Format -------------------------------------------------------------- ftp.spc.edu [.mx.mx041] mx041.* BACKUP ftp.kcl.ac.uk [.madgoat] mx.* VMS_SHARE -------------------------------------------------------------- Availability via Electronic Mail: -------------------------------------------------------------- Address Command to send Format -------------------------------------------------------------- VMSSERV @ KCL.AC.UK SEND MX.PACKAGE VMS_SHARE FILESERV@ WKUVX1.WKU.EDU SEND MX041 VMS_SHARE,MFTU,ZIP -------------------------------------------------------------- 4.2.2 >>>> IUPOP3 [10-OCT-1994] ----------------- Summary: A POP3 mail server Description: POP3 is a protocol that allows a PC user to download mail from a central mail server and read it on the PC using PC style interfaces. A client that understands the POP protocol must run on the PC and many public domain or shareware ones are available (Win/QVT, Eudora, PC-Eudora, POPmail, Pegasus Mail and MINUET to name but a few). IUPOP3 is a POP3 server that runs under a number of systems, including VMS, and runs over the OpenCMU TCP/IP software (also UCX and Multinet). Pre-Requisites: IUPOP3 requires a specific library for CMU, INET_CMUTIL. Note the original Author of this software (see below) do NOT currently support a CMU version. The CMU port is a one off (Thanks to Brian T Carcich). Author Indiana University Availability via Anonymous FTP: -------------------------------------------------------------- Site Directory File(s) Format -------------------------------------------------------------- ftp.indiana.edu /pub/vms/iupop3 v1.7/* source v1.7-CMU-TEK/* ftp.kcl.ac.uk [.iupop3] iupop3-017.* VMS_SHARE ftp.kcl.ac.uk [.cmu-tcpip] INET_CMUTIL.BCK BACKUP -------------------------------------------------------------- Availability via Electronic Mail: -------------------------------------------------------------- Address Command to send Format -------------------------------------------------------------- VMSSERV @ KCL.AC.UK SEND IUPOP3-017.PACKAGE VMS_SHARE -------------------------------------------------------------- 4.3 >>>> NEWS APPLICATIONS [10-OCT-1994] -------------------------- Usenet news is a world wide distributed news system. Messages generated on one system are passed around the world rapidly, to all other systems. To simplify the management of news, messages are divided into `newsgroups', each newsgroup concentrating on one general topic. Using an appropriate newsreader, a user can `subscribe' to a particular set of newsgroups and read all the related messages in a manner similar to mail. There are some 3000+ different user groups currently. There are a number of parts to the news system. Firstly, software is required to gather batches of news from an upstream `feed' site and insert it into a local news database; Second, software is required to allow users to read the news database, possibly modifying it by sending new messages. The news database can be on the same system as the user, or the news database can be on a remote system, accessible through a client-server mechanism. The user's news reader program becomes a client, using the network to access a news server. 4.3.1 >>>> ANU NEWS [10-OCT-1994] ------------------- Summary: A complete news system Description: ANU-NEWS provides a complete package to deal with USENET news. News is received from an up-stream news feed site and stored in a local on-disk database. This database can be interrogated by local users running the NEWS application; A news server can be set up that provides access to the news databases via any convenient NEWS client running on another system (see NEWSRDR elsewhere in this document for one example). The ANU-NEWS server supports OpenCMU. Author: Thanks go to Geoff Huston for writing and maintaining the ANU NEWS software. Availability via Anonymous FTP: -------------------------------------------------------------- Site Directory File(s) Format -------------------------------------------------------------- kuhub.cc.ukans.edu [.ANU_Vnnn] NEWS_Vnnn.ZIP ZIP ftp.kcl.ac.uk [.news] news.* VMS_SHARE -------------------------------------------------------------- Availability via Electronic Mail: -------------------------------------------------------------- Address Command to send Format -------------------------------------------------------------- VMSSERV @ KCL.AC.UK SEND NEWS.PACKAGE VMS_SHARE -------------------------------------------------------------- NOTE: `nnn' is a version number or version string; replace with the latest version that appears in the directory. 4.3.2 >>>> NEWSRDR [10-OCT-1994] ------------------ Summary: A VMS newsreader client Description: NEWSRDR is a news client that allows the user to access the news groups stored on a news server system. This gives users a quick way of accessing all the news without the need to build a full news system. Pre-Requisites: NEWSRDR requires the NETLIB library to interface to the underlying TCP/IP network. Author: Thanks go to Matt Madison for writing and maintaining the NEWSRDR software. >>> FNEWS [10-OCT-1994] ---------------- Summary: A NEWS reading client for VMS Description: FNEWS is another news reader client. It offers local caching of newsgroups to speed the downloading of messages. Pre-Requisities: None: FNEWS builds for the currently installed transport. Author: ??? Availability via Anonymous FTP: -------------------------------------------------------------- Site Directory File(s) Format -------------------------------------------------------------- zephyr.grace.cri.nz /pub/fnews/vms fnews.bck BACKUP ftp.kcl.ac.uk [.news] fnews.* VMS_SHARE -------------------------------------------------------------- Availability via Electronic Mail: -------------------------------------------------------------- Address Command to send Format -------------------------------------------------------------- VMSSERV @ KCL.AC.UK SEND FNEWS.PACKAGE VMS_SHARE -------------------------------------------------------------- 4.4. >>>> WORLD WIDE WEB APPLICATIONS [10-OCT-1994] ------------------------------------- The world wide web is a distributed hypertext system that literally encompasses the world. A document can be loaded from a remote server which contains hypertext links to other documents anywhere in the world. Documents can be text, graphics, sound, binary etc. World Wide Web servers accept requests from clients to download documents, and world wide web clients accept those documents and format them for the user's display. A single display can be composed of a mix of text and graphics etc. World Wide Web uses the HyperText Markup Language (HTML) to specify document format and remote links. World Wide Web links specify the location of the document (site, directory and filename) as well as the protocol used to access them (ftp, wais, gopher, html etc.). So world wide web combines the functionality of a number of client types. 4.4.1 >>>> MOSAIC [10-OCT-1994] ----------------- Summary: A graphical world wide web client that uses the X protocol over TCP/IP Descrription: MOSAIC is a superb graphical interface for browsing through the World Wide Web and gopher databases on the internet. By using a hypertext markup language, text, images and sound can be pulled together, irrespective of their locations, into a single on-screen document. This is THE program for information seekers. Pre-Requisites: X-windows is required to display the document. A socket library interface is required to build this program for the underlying network transport. For OpenCMU, the required library is LIBCMU. Author: MOSAIC is written by the National Centre for Supercomputing Applications. Availability via Anonymous FTP: -------------------------------------------------------------- Site Directory File(s) Format -------------------------------------------------------------- ftp.kcl.ac.uk [.mosaic] mosaic.* VMS_SHARE -------------------------------------------------------------- Availability via Electronic Mail: -------------------------------------------------------------- Address Command to send Format -------------------------------------------------------------- VMSSERV @ KCL.AC.UK SEND MOSAIC.PACKAGE VMS_SHARE -------------------------------------------------------------- 4.4.2 >>>> LYNX [10-OCT-1994] --------------- Summary: A World Wide Web browser, designed for line mode terminals (such as Digital's VT series. Description: LYNX is a line mode version of a World Wide Web hypertext browser. It combines the functions of gopher and FTP, together with WWW and allows access from a VT compatible terminal. It provides similar functionality to that of Mosaic except that a simple terminal interface is all that is required. Pre-Requisites: A socket library interface is required; LYNX recognizes a number of socket libraries. For OpenCMU, the LIBCMU socket library is required. Author: Thanks go to the LYNX developers, mainly at the University of Kansas, for developing and maintaining this software, and for making it freely available. Availability via Anonymous FTP: -------------------------------------------------------------- Site Directory File(s) Format -------------------------------------------------------------- ftp.kcl.ac.uk [.lynx] lynx.* VMS_SHARE -------------------------------------------------------------- Availability via Electronic Mail: -------------------------------------------------------------- Address Command to send Format -------------------------------------------------------------- VMSSERV @ KCL.AC.UK SEND LYNX.PACKAGE VMS_SHARE -------------------------------------------------------------- 4.4.3 >>> HTTP_SERVER [10-OCT-1994] Summary: A World Wide Web server conforming to the standard HTTP (HyperText Transfer Protocol) mechanism. Description: HTTP_SERVER provides a VMS system with the ability to act as a World Wide Web server using the HTTP protocol. It will accept requests from HTTP clients (such as MOSAIC - see elsewhere in this document) and return the necessary information. A full description of the World Wide Web system is outside the scope of this summary but it is, in essence, a distributed hypertext system capable of mixing text, images, graphics, animation and sound into a single on-screen display, with each element being on different systems anywhere in the world. The HTML language is used to specify the links. Pre-Requisites: None; the server contains all the necessary interfaces to work with OpenCMU, as well as with UCX and Multinet. Author: Thanks go to David Jones for writing and maintaining this software. Availability via Anonymous FTP: -------------------------------------------------------------- Site Directory File(s) Format -------------------------------------------------------------- osu.edu http_server.tar TAR ftp.spc.edu [.macro32.savesets] http_server.zip ZIP ftp.wku.edu [.vms.fileserv] http_server.zip ZIP ftp.kcl.ac.uk [.default] http_server.* VMS_SHARE -------------------------------------------------------------- Availability via Electronic Mail: -------------------------------------------------------------- Address Command to send Format -------------------------------------------------------------- VMSSERV @ KCL.AC.UK SEND HTTP_SERVER.PACKAGE VMS_SHARE FILESERV @ WKUVX!.WKU.EDU SEND HTTP_SERVER VMS_SHARE,MFTU,ZIP -------------------------------------------------------------- 4.5 >>> FILE TRANSFER APPLICATIONS [10-OCT-1994] File transfer is another major application run over the network. It allows files to be transferred between two different systems using a simple set of commands. It is most often used for retrieving files from one of the many public domain archive sites around the world. OpenCMU comes prepackaged with an FTP client and server but it is worth considering the alternatives listed here. 4.5.1 >>>> MADGOAT FTP [10-OCT-1994] ---------------------- Summary: An alternative FTP client and server. Description: The File Transfer program (or FTP) is an important part of the TCP/IP applications set. It allows files to be moved between two systems. MGFTP is a file transfer program which can be used over any of the available TCP/IP transports, including OpenCMU. This client is more functional than the one provided with OpenCMU and is recommended. Useful enhancements include: * Logging of server transactions to a file in each user's home directory * User control over how the server is used on an account * Anonymous FTP has per-directory messages * FTP client has automatic anonymous login * FTP client can have aliases defined to connect/fetch from specific systems/files Pre-Requisites: The NETLIB interface is required. Author: MGFTP is based on the OpenCMU FTP client and server, written by many people. Thanks go to Matt Madison and Hunter Goatley, of MadGoat software, and to Darrell Burkhead, for writing and maintaining MGFTP and making it available as freeware. Availability via Anonymous FTP: -------------------------------------------------------------- Site Directory File(s) Format -------------------------------------------------------------- ftp.wku.edu [.madgoat] mgftp.zip ZIP ftp.spc.edu [.macro32.savesets] mgftp.zip ZIP ftp.kcl.ac.uk [.madgoat] mgftp.* VMS_SHARE -------------------------------------------------------------- Availability via Electronic Mail: -------------------------------------------------------------- Address Command to send Format -------------------------------------------------------------- VMSSERV @ KCL.AC.UK SEND MGFTP.PACKAGE VMS_SHARE FILESERV@ WKUVX1.WKU.EDU SEND MGFTP VMS_SHARE,MFTU.ZIP -------------------------------------------------------------- 4.5.2 >>>> C-KERMIT [10-OCT-1994] ------------------- Summary: File transfer over the current terminal connection to a host. Description: The KERMIT program is a widely used way of tranferring files over serial lines between systems. The user's terminal temporarily becomes a client and the user's host session temporarily becomes a server. The KERMIT protocol allows switching between terminal mode and file transfer mode, as well as sending or requesting files to be transferred. In the past, kermit has been able to set up terminal sessions, and run the file transfers, only over serial line connections. More recent versions have allowed the terminal connections, and hence the file transfers, to take place over telnet links by having direct TCP/IP support built in. The latest version of C-kermit supports direct TCP/IP connections and will work over the OpenCMU package. Pre-Requisites: The OpenCMU version requires a socket library specific to the transport on which it runs. For OpenCMU, the required socket library is LIBCMU. Author: Columbia University and many contributors around the world. Availability via Anonymous FTP: -------------------------------------------------------------- Site Directory File(s) Format -------------------------------------------------------------- kermit.columbia.edu kermit/b ckvvcmu.hex HEX of .exe kermit/test ckvvcmu.hex HEX of .exe -------------------------------------------------------------- NOTE: The OpenCMU version of kermit is currently a test version only so it is only worth looking in the kermit/test directory. 4.5.2 >>>> FSP [27-OCT-1994] -------------- Summary: File transfer over a lightweight UDP based protocol. Description: FSP is a simple file transfer protocol based around UDP rather than TCP protocols. It is designed to impose minimal load on the server and does not require the user to log in or identify themselves. Essentially, the client throws UDP packets at a server asking for a portion of a file or info about a file, and keeps throwing the same request at it until the server responds. Thus an FSP transfer is, in principle, resilient to server failure as it will retry until the server comes back on-line. It is said that FSP is what anonymous FTP should have been. This package is a port of the unix FSP client and server to VMS, and directly supports UCX, Multinet and CMU. It also supports the vendor independent SOCKETSHR library. Pre-Requisities: Either: LIBCMU For direct CMU support Or: SOCKETSHR For vendor independent TCP/IP support (recommended) NETLIB (required by SOCKETSHR) Author: Various. Availability via Anonymous FTP: -------------------------------------------------------------- Site Directory File(s) Format -------------------------------------------------------------- ftp.kcl.ac.uk [.default] fsp.* VMS_SHARE -------------------------------------------------------------- Availability via Electronic Mail: -------------------------------------------------------------- Address Command to send Format -------------------------------------------------------------- VMSSERV @ KCL.AC.UK SEND FSP.PACKAGE VMS_SHARE -------------------------------------------------------------- 4.6 >>>> NETWORK ARCHIVE SEARCH APPLICATIONS [10-OCT-1994] -------------------------------------------- There are many many sites around the world that allow public access to parts of the file system that contain freely available software. With so many sites and so many packages available, it can often be difficult to locate the appropriate site that holds the required software. ARCHIE was designed to ease this problem. A large number of sites are responsible for indexing all the other sites in the world and keeping track of what each contains. The ARCHIE mechanism allows a user to supply a keyword to the nearest archie host and have it return a list of software locations that contain the keyword somewhere in the directory/filename path. This usually results in a large list of potential places to search, which can then be interrogated using an FTP utility. 4.6.1 >>>> ARCHIE [10-AUG-1994] ----------------- Summary: A client used to interrogate the world-wide archive software database. Description: ARCHIE is a client for interrogating ARCHIE servers. Such servers maintain up to date information about what software is available on various FTP archives around the world and permit the client to ask where a particular item can be found. Given a keyword, ARCHIE will try to find all archives that contain files with the keyword as part of the name. Once located, FTP can be used to retrieve the item from the nearest archive. ARCHIE is configurable to use any one of a number of nearby archie servers with one selected at compile time as the default. Pre-Requisites: For OpenCMU usage, a socket library interface is required. There are two parallel versions or archie. One runs over the LIBCMU package, and the other runs over the SOCKETSHR package. Check the readme files with the software to see which is applicable. Author: Unknown. Many contributors. Availability via Anonymous FTP: -------------------------------------------------------------- Site Directory File(s) Format -------------------------------------------------------------- ftp.kcl.ac.uk [.archie] archie.* VMS_SHARE -------------------------------------------------------------- Availability via Electronic Mail: -------------------------------------------------------------- Address Command to send Format -------------------------------------------------------------- VMSSERV @ KCL.AC.UK SEND ARCHIE.PACKAGE VMS_SHARE -------------------------------------------------------------- 4.7 >>>> GOPHER APPLICATIONS [10-OCT-1994] ---------------------------- GOPHER is a protocol for requesting information from a remote system. GOPHER servers run on these systems to handle the incoming requests and GOPHER clients are necessary to interact with a user and generate the requests. Information is presented to the user in a menu format and allows information of many different types to be downloaded, viewed and/or saved. One GOPHER server can send back a pointer to a file of information that exists on a completely different system. This provides a generalised world wide browsing system NOTE: To a large extent, the functionality of GOPHER has been superceded by the World Wide Web but there are still a large number of gopher servers around. 4.7.1 >>>> GOPHER [10-OCT-1994] ----------------- Summary: A gopher client and server for VMS Description: The gopher client allows a user to request documents from any gopher server in the world. The gopher server allows a site to serve documents to the rest of the world. Pre-Requisites: The gopher client requires NETLIB, and will run over any of the supported TCP/IP transports. The gopher server specifically requires either UCX or MULTINET. There is no version for OpenCMU. Author: The University of Minnesota Availability via Anonymous FTP: -------------------------------------------------------------- Site Directory File(s) Format -------------------------------------------------------------- boombox.micro.umn.edu /pub/gopher/VMS gopher*VMS*.zip ZIP ftp.kcl.ac.uk [.gopher] gopher.* VMS_SHARE -------------------------------------------------------------- Availability via Electronic Mail: -------------------------------------------------------------- Address Command to send Format -------------------------------------------------------------- VMSSERV @ KCL.AC.UK SEND GOPHER.PACKAGE VMS_SHARE -------------------------------------------------------------- 4.8 >>>> FINGER APPLICATIONS [10-OCT-1994] ---------------------------- The FINGER protocol allows a client to `finger' another user on another system to find out basic information. For instance, fingering a system will give details of who is currently logged on. Fingering an individual username will give selected personal details (real name, location and any immediate plans). Note - some sites consider finger to be a security risk and do not run either the server or the clients. Thus it may not be possible to `finbger' some systems. 4.8.1 >>>> MADGOAT FINGER [10-AUG-1994] ------------------------- Summary: A FINGER Client and Server Description: FINGER provides both client and server facilities; This allows users to discover information about users on another system and for those users, in turn, to find out about local users. Pre-Requisites: FINGER requires the NETLIB library Author: Matt Madison and Hunter Goatley (C) MadGoat Software ltd. Availability via Anonymous FTP: -------------------------------------------------------------- Site Directory File(s) Format -------------------------------------------------------------- ftp.spc.edu [.macro32.savesets] mg_finger.zip ZIP ftp.kcl.ac.uk [.madgoat] mg_finger.* VMS_SHARE -------------------------------------------------------------- Availability via Electronic Mail: -------------------------------------------------------------- Address Command to send Format -------------------------------------------------------------- VMSSERV @ KCL.AC.UK SEND MG_FINGER.PACKAGE VMS_SHARE FILESERV@ WKUVX1.WKU.EDU SEND MG_FINGER VMS_SHARE,MFTU,ZIP -------------------------------------------------------------- 4.9 >>>> DOMAIN NAME SERVER APPLICATIONS [10-OCT-1994] ---------------------------------------- The Domain Name Server (or DNS) is responsbible for mapping system names into network addresses. It is sometimes useful to interrogate the DNS directly, perhaps to do fault determination or to track down a system name. 4.9.1 >>>> NSQUERY [10-OCT-1994] ------------------ Summary: Request information from the DNS Description: NSQUERY is a very useful utility that allows a user to interrogate any Domain Name Server for full site details. Pre-Requisites: Requires the NETLIB library. Author: Thanks go to Matt Madison for writing and mainting the NSQUERY software. Availability via Anonymous FTP: -------------------------------------------------------------- Site Directory File(s) Format -------------------------------------------------------------- ftp.spc.edu [.macro32.savesets] nsquery.zip ZIP ftp.kcl.ac.uk [.news] nsquery.* VMS_SHARE -------------------------------------------------------------- Availability via Electronic Mail: -------------------------------------------------------------- Address Command to send Format -------------------------------------------------------------- VMSSERV @ KCL.AC.UK SEND NSQUERY.PACKAGE VMS_SHARE FILESERV@ WKUVX1.WKU.EDU SEND NSQUERY VMS_SHARE,MFTU,ZIP -------------------------------------------------------------- 4.9.2 >>>> IPADDR [10-OCT-1994] ----------------- Summary: Convert name to IP Address and vice versa Description: IPADDR is a simple utility to map an IP address into its corresponding host name(s) and vice versa. Pre-Requisites: Requires the NETLIB library. Author: Andy Harper Availability via Anonymous FTP: -------------------------------------------------------------- Site Directory File(s) Format -------------------------------------------------------------- ftp.kcl.ac.uk [.default] ipaddr.* VMS_SHARE -------------------------------------------------------------- Availability via Electronic Mail: -------------------------------------------------------------- Address Command to send Format -------------------------------------------------------------- VMSSERV @ KCL.AC.UK SEND IPADDR.PACKAGE VMS_SHARE --------------------------------------------------------------