FTP2UK23.INF SIMTEL20 by FTP from UK JANET sites Notes for PC/MSDOS users at UK JANET sites - last revised 27 Apr 92 Some of the methods below are no longer in my current repertoire. If you think the advice has become out of date, please send me a message with details. Hylton Boothroyd, Warwick Business School, bsrdp@warwick.ac.uk UK readers can find the latest version of this file in the directory ibmpc/simtel20/info at uk.ac.ic.doc.src ------------------------------------------------------------------------ Contents: 0. Background to this file 0.1 JANET (NIFTP) methods v. Internet FTP 1. Practical alternatives, and why 1.1 Lancaster 1.2 Imperial College, London 1.3 TRICKLEs 1.4 FTP from mirrors and quasi-mirrors outside the UK 1.5 FTP variations available 2. Getting a file from SIMTEL20: two-stage FTP via London 2.1 Scope of advice 2.2 Authorizations 2.3 Outline and limitations 2.4 Getting information files before you start 2.5 An annotated example of Warwick - NSF.SUN(London) - SIMTEL20 3. Getting a file from SIMTEL20: FTP direct 3.1 Scope of advice 3.2 Authorizations 3.3 Outline and limitations 3.4 Getting information files before you start 3.5 Automation of FTP file collection 4. Getting a file from SIMTEL20: one-step file request via FT-RELAY 4.1 Scope of advice 4.2 Authorizations 4.3 Outline and limitations 4.4 Getting information files before you start 4.5 An example of a request to FT-RELAY 5. File history ------------------------------------------------------------------------ 0. Background to this file --------------------------- These notes were originally prepared for Keith Petersen, the SIMTEL20 archivist, to meet a steady stream of requests for information from UK JANET sites with the basic query: Can I get SIMTEL20 files in the UK by FTP? How? Now that all JANET sites can get SIMTEL20 files over JANET from the SIMTEL20 collection maintained at Imperial College in London, the advice here has served its original purpose. However, until late 1993, and perhaps beyond that, the working methods discussed in this file will continue to be of interest to UK users wanting files publicly available by FTP from other non-UK sites. When FTP is mentioned on the net by people outside the UK, it usually means the programme at a site on Internet (a network of networks) that can be used * to establish a connection with a distant site, * to inspect the contents of distant directories, * to transfer files along the connection. When networks and sites are not busy it is fast and fluent. JANET is too unlike other networks for it simply to join Internet en bloc. JANET sites therefore either have to join Internet individually in their own right or have to rely on indirect access. Until mid-1991, scarcely any JANET sites were on Internet. By the end of 1993 most JANET sites will have joined, though cost may keep some sites off Internet indefinitely. If you are at a JANET site that is already on Internet, the flavour of working methods can be sampled from sections 2.5.4 (manual interactive) and 3.5 (manually started scripts and automatically repeated scripts). And you can take your advice on FTP from anywhere in the world. If you are at a JANET site that is not yet on Internet you have to connect with special Internet interfaces at other UK sites to act as your end of the Internet connection. You can get an idea of the several stages of manually collecting a file from SIMTEL20 to your PC from the long annotated example in section 2.5, which is mostly a straight account of my first experience of FTP in all its JANET awkwardness but also includes a sprinkling of afterthoughts. Unfortunately, connections between JANET sites are not produced by a single widely implemented package. There is a medley of packages with little in common in their user interfaces. And there is only patchy guidance on what to put into each package to produce the desired JANET message. A complete advice file on indirect connection with Internet would have to have a complete set of recipes for each package in the medley. That is beyond my capacity. So the accounts here are based on my preferred connection to the world: before Internet at my site - PC+Kermit -----> Unix host ----+---> JANET -> Internet interfaces | PC+Rainbow --+ [ I already had many utilities on the unix intermediary, and liked its multiple streaming of parallel jobs, so I was not drawn to the obvious alternative PC+Rainbow ------------------> JANET -> Internet interfaces ] after Internet at my site - PC+Kermit -----> Unix host ----+---> Internet | PC+Rainbow --+ PC+Kermit leaves plenty of room on a standard 640K PC for doing things at the PC end during a connection. PC+Rainbow uses so much space that only the most trivial operations are feasible - its chief advantages are built-in methods for direct use of JANET and its speed of file transfer. Since UK JANET methods can be awkward to use, there is some advantage in wrapping up the painful details in scripts and/or set-up recipes once you have established them. So far I only have recipes for using unix hosts. Brief examples are included below, but more ambitious methods are in the companion file pd1:FTP2UK23.ZIP . In using the advice below: * be prepared to replace my account of what I do with something suited to your own hardware and software; * replace the variants of my email address with similar variants of your own. 0.1 JANET (NIFTP) methods v. Internet FTP ----------------------------------------- There are two modes of linking with a distant site: * interactive manual control, * sending a complete request message. In FTP there is no difference in what can be done in the two modes - a complete request message simply mimics interactive manual control. On JANET there are differences in what can be done in the two modes, and you need to switch between them. At best the two modes are managed within a menu-driven front-end, as in the PC-Rainbow package. At worst there is an unrelated and different-looking utility for each mode, as on a typical unix host. Interactive manual control offers the following basic facilities: FTP JANET Yes Yes List a distant directory on screen No* Yes Read a distant text file on screen Yes No Have a distant text/binary file sent to you Yes No Have a distant directory sent to you as a file No Yes Direct access to remote site from PC (via Rainbow) * on some systems, but not on the London interface, FTP allows quick and easy interruption to inspect files collected from a distant site. A stand-alone request message offers the following basic facilities: FTP JANET Yes Yes Have a distant text/binary file sent to you Yes No* Have a distant directory sent to you as a file No Yes Direct file receipt on PC from remote site (via Rainbow) * many JANET sites partly compensate for the lack of directory-as-file by periodically updating separate textfiles of directory listings, but there is no standard method for naming and locating them. ----------------------------------------------------------------------------- 1. Practical alternatives, and why ----------------------------------- SIMTEL20 has probably the largest publicly-accessible actively-managed up-to-date collection of serious MSDOS software in the world, both public domain (PD) and shareware (SW). BUT ... * a large mature UK repository of PC software now exists at Lancaster, with full time staff who are: - pro-active in collecting it from sites like SIMTEL20 and cataloguing it, - funded partly to avoid the overloading of gateways to international networks and the international networks themselves; * a reasonable mirror of SIMTEL20's pd1: directory is now maintained at Imperial College, London; * an email service of SIMTEL20 files is still available via a network of caches/servers around Europe and near-Europe - the TRICKLE servers; * it is often easier and more reliable to connect with mature non-UK sites that keep up-to-date copies of SIMTEL20 files. I don't aim to include stand-alone guides to alternatives to SIMTEL20, but here in section 1 are some pointers to those that seem to be reliable together with a quick overview of the three methods available for reaching SIMTEL20 and other FTP sites. 1.1 Lancaster ------------- The "National Software Archive" at Lancaster offers in its own format virtually everything that is added to SIMTEL20. The archive is accessible to *all* JANET users by email and JANET methods. In November 1991 it became accessible by FTP. To get started either send an email message of the form: From: bsrdp@uk.ac.warwick.cu To: archive-server@uk.ac.lancs.pdsoft Subject: Anything you like, or leave out the whole line send help or call the archive interactively over JANET and follow the instructions on screen - on my unix host I simply need to enter pad lancs.pdsoft ( a limited range of unix-like commands is available: for example, 'more' but not 'less'); or, if you have direct FTP, use methods similar to the manual interactive method described in section 2.5.4 or to the automated methods described in section 3.5 - a suitable first script would be: verbose open 148.88.64.2 user anonymous bsrdp@warwick.ac.uk ascii dir * lancs.dir get docs/pdintro lancs.docs.pdintro get micros/ibmpc/dos/index lancs.dos.index bye Good and bad features from the point of view of SIMTEL20 users are: + has a separate standardized descriptive file for each application, which % often tells you enough to avoid an unsuitable archive, % reports the commercial status - PD or which of the many varieties of SW - in April 1992 about 45% of the MSDOS list was SW; + publishes four regular email newsletters ( dos, windows, os2, and deskview ) which include the information files for the latest additions together with full pathnames; - is a chronological collection with uninformative directory names and file names - I find I need both a printed and a local online copy of /micros/ibmpc/dos/index to navigate comfortably - if you accidentally call dir /micros/ibmpc you will after some minutes get a directory listing of about 2000 names running from f001 to h999 and be no wiser; - has no cross-referencing to SIMTEL20; - repackages all archives in a .BOO format, but offers DEBOOing tools if your site does not have them; - lags perhaps 7/10 days behind SIMTEL20, but ... + accepts requests for expediting; + avoids adding to traffic on international networks, - low rate of first time FTP connection. If you are at a JANET site without Internet FTP, then: + physically available 24 hours a day, + high rate of first time connection. 1.2 Imperial College, London ---------------------------- The UKUUG archive at Imperial College started a new section in August 1991. By April 1992 a complete set of MSDOS files from SIMTEL20 appeared to be in place. The archive is accessible to *all* JANET users by email and JANET methods, and is also accessible by FTP. JANET users should make this the standard site for collecting their up-to-date copy of pd1:SIMIBM.ARC which is held as ibmpc/simtel20/filedocs/simibm.arc . To get started either send an email message of the form: From: bsrdp@uk.ac.warwick.cu To: info-server@doc.ic.ac.uk Subject: Anything you like, or leave out the whole line request: index topic: help request: end or call the archive interactively by JANET methods outside office hours and follow the instructions on screen - on my unix host I simply need to enter pad ic.doc.src ( a rather wider range of unix-like commands is available than at Lancaster, including 'less' and file location calls); or, if you have direct FTP, use methods similar to the manual interactive method described in section 2.5.4 or to the automated methods described in section 3.5 - a suitable script to check the current range of directories would be verbose open src.doc.ic.ac.uk user anonymous bsrdp@warwick.ac.uk dir ibmpc/simtel20/. ic.simtel20.dir bye ( the numeric form of the address is 146.169.3.7, and the address you offer as your password must include @ ). Good and bad features from the point of view of SIMTEL20 users are: + uses SIMTEL20's directory structure and filenames, so announcements on comp.binaries.ibm.pc.archives can be translated directly into requests; - at April 1992 additionally carried about 20% extra detritus from months of development using buggy communications and/or buggy local name processing, including: % many extra buggily-named directories with old and/or buggily-named versions of SIMTEL20 files, % a tendency to miss the deletion of superseded versions of software within current SIMTEL20 directories, % a scattering of programmes which have additionally or alternatively been subject to unix compress, so % it can confidently be used to call files for which you have a correct directoryname+filename from SIMIBM.ARC, % it is best not used for browsing until it is tidier - get an up-to-date copy of SIMIBM.ARC and browse in that; + lags only one or two days behind files being added to SIMTEL20 + has a high rate of first-time connection; + avoids adding to traffic on international networks. If you are at a JANET site without Internet FTP, then: - physically unavailable for manual interactive working during normal office hours (0830-1730 Mon-Fri), + high rate of first time-time connection. 1.3 TRICKLEs in Europe and near-Europe -------------------------------------- There is a slowly changing list of about 10 sites on the EARN/BITNET network in Europe, ranging from Spain to Denmark to Israel, with automatic servers which together manage a substantial cache of SIMTEL20 material of current interest. The cache has no duplication in it, except transiently during file distribution. I think it will now mainly be of interest only if the Imperial College mirror becomes unavailable for any reason. But some users in unusual circumstances may still need it. Although the TRICKLE system is primarily for direct connection of sites on the EARN/BITNET network, one of the TRICKLEs, currently that in Austria, provides a complete email service for UK users. On receiving a request for a SIMTEL20 file, the Austrian TRICKLE will: * mail it if it is in the Austrian cache, * ask each other TRICKLE to mail it, and report, * if all report negatively, place an order for the file and mail it on arrival. To get started, send an email message of the form From: bsrdp@uk.ac.warwick.cu Reply-To: bsrdp%cu.warwick.ac.uk@UKACRL To: trickle@awiwuw11.earn Subject: Anything you like, or leave out the whole line /help and in the help file that arrives ignore all references (TELL etc) to the direct access methods available to sites that are on EARN. You might be OK without the Reply-To line. I made it standard when it became clear that the TRICKLEs were not always in a state where they could form an adequate version of my address - UKACRL is the EARN interface for all JANET sites. Some good and bad features from the point of view of SIMTEL20 users are: + uses SIMTEL20's directory structure and filenames, so announcements on comp.binaries.ibm.pc.archives can be translated directly into requests; - usually lags about 3 days behind newsgroup announcements in updating its directory and accepting requests, but has occasional hiccoughs when it lags by another week, particularly at periods of excitement and/or crisis on the networks; + exact copies of SIMTEL20 .ZIP files and .ARC files are translated into mailable form, often in several parts, and arrive with no effort on your part, although ... - it can be the weekend before the big parts arrive in term time ( if a file is sent in n parts, the first n-1 are big and the final part may be) - UK users must specifically ask for mailings of archive files (.ARC, .LZH, .ZIP, .ZOO ...) to be xxencoded, and must have the tools for xxdecoding, which can can be a bit messy - downloading the set of separate parts to your PC and using Richard Mark's uudecode pd1:UUEXE510.ZIP is an alternative to writing supporting perl/awk scripts for a unix host. 1.4 FTP from mirrors and quasi-mirrors outside the UK ----------------------------------------------------- Sites in various parts of the world aim at keeping reasonably up-to-date copies of SIMTEL20's MSDOS files and offering an FTP service to the world at large. They may be of little interest once the Imperial College coverage is thoroughly debugged, except insofar as they are actively managed collections. Mirror sites, a minority, have: * a tree of directories somewhere in their own directory structure that exactly matches the pd1: directory tree on SIMTEL20, * files that are exact copies of the files on SIMTEL20, * an identical set of files to those on SIMTEL20, typically managed by automatic overnight off-peak calling of new files, and therefore typically in a state that lags a day or two behind SIMTEL20. What I prefer to call quasi-mirror sites, although they are usually described as mirrors, depart in some respects from being true mirrors, but may have other qualities to recommend them. The Imperial College collection of SIMTEL20 files described in section 1.2 is intended to be a true mirror. Mirrors and quasi-mirrors do not usually have the same operating system as SIMTEL20, so the appearance of directory names and filenames is somewhat different. For example, at the first site described below the SIMTEL20 file pd1:SIMIBM.ARC is held as /mirrors/msdos/filedocs/simibm.arc Four unix sites are worth looking at from the UK, and can be accessed by the methods for accessing SIMTEL20 in sections 2, 3, and 4 below. wuarchive.wustl.edu Offers a true mirror in its directory /mirrors/msdos and + usually lags by only about one day, + has a high rate of first-time connections, + usually operates more quickly than other sites, + in 1991 was the source for the mirror at Imperial College, London. oak.oakland.edu Offers a true mirror in its directory /pub/msdos and + usually lags by no more than a day, and is managed by the SIMTEL20 msdos archivist, - has a lower rate of first-time connections than wuarchive. nic.funet.fi Offers a quasi-mirror in its directory /pub/msdos though the directory also has several sub-directories not related to material from SIMTEL20's pd1: directory. Some good and bad features from the point of view of SIMTEL20 users are: - within /pub/msdos there is an extra layer of sub-directories into which the SIMTEL20 directories are grouped, though ... + a group of thematically related directory names can then conveniently be presented in a single screenful, - .ARC and .ZIP files are repackaged into .LZH archives, which requires yet another verification tool on a unix host - however, once you have the .LZH archive on your PC ... + archives in .LZH format are a little smaller; - lags behind wuarchive.wustl.edu garbo.uwasa.fi Offers a quasi-mirror in its directory /pc though the directory also contains some non-SIMTEL20 material. Some good and bad features from the point of view of SIMTEL20 users are: + competes to make most worthwhile things available quickly, and indeed to persuade software authors to make it a repository of first resort, but ... - adds only a subset of what is added to SIMTEL20, though I guess that users will find at least 90% of what they want; + holds only about 20% of what is on SIMTEL20 - as an active utility writer the moderator excludes also-ran's and me-too's, so the average quality of general utilities is high; - holds only about 20% of what is on SIMTEL20 - so some applications topics are entirely missing; - repacks some .ARCs to .ZIPs, with SIMIBM.ARC as /pc/filelist/simibm.zip ; +/- accepts some .LZHs ( see nic.funet.fi above for comments ) - uses a thematic directory structure coarser than that of SIMTEL20, with subtly different directory names and sometimes different filenames, but ... + announces details of additions quickly, with full pathname (but look out for corrections) and often with evaluative comments, on comp.binaries.ibm.pc.archives; + maintains an index list /pc/filelist/garboidx.arc with brief descriptions similar to SIMIBM.IDX but perhaps a little more evaluative; - has no cross reference from SIMTEL20 pathnames; - often (50%+ of my requests) declares itself unable to provide a directory listing using 'dir' (a persistent bug) though a list of names-only is available using 'ls'; - despite being geographically nearer to the UK is connected through busy networks that make file transfers noticeably slower than from wuarchive and oak. 1.5 FTP variations available ---------------------------- Distant connection by FTP is seductive, so it is perhaps worth saying: * the software and hardware at FTP sites are not usually maintained principally for the benefit of distant callers, though in the long run there is a very rough quid pro quo in what is made available to archive sites by the networking community; * even if you are not physically prevented from accessing a distant site during its normal daytime office hours, you should try to respect requests for considerate use; * operators and/or funders of distant sites may call, Enough, and pull the plug. For JANET users the three methods of FTP connection currently available are: two-stage connection through the London FTP interface ----------------------------------------------------- + available to all JANET sites, + well-established, + allows you during a single FTP session in London to move easily between: % listing directory contents (complete with files sizes), % pulling a copy of any file to London, - everything has to be transferred from London to your own site before you can inspect it, - has no facility for you to build supportive scripts for pulling files to London or for sending them to your own site, - often busy and often with limited capacity for incoming files, though this is temporarily easing as sites with their own Internet connections discontinue their traffic, - requires two substantially different methods of distant computer access and file transfer, one within the UK to reach London, and ordinary Internet FTP from London to the rest of the world, + direct PC-London access with the UK 'Rainbow' package from certain types of local network; ordinary FTP ------------ - not yet available at some JANET sites, + should be relatively bug-free proven technology, + allows you during a single manually controlled FTP session to move easily between: % listing directory contents (complete with files sizes), % pulling a copy of any file, % briefly inspecting pulled files, + can be automated to various degrees; one-stage file-relay service via FT-RELAY ----------------------------------------- + available to all JANET sites, + delivers files to your own site, and operates the FTP connection itself, + very fast, like direct FTP, IF lines to FT-RELAY are free AND FT-RELAY is not busy AND the networks to the remote site are not busy AND the remote site can accept you, - experimental, with scope of future behaviour not yet defined, and fairly sharp changes in the degree to which it will persist with a request - at a particular test date in August 1991 I noted: % each request for a directory listing and each request for a file is the subject of a separate message to FT-RELAY and separate re-connection to the remote site, % directory listings lack file sizes, % terminates the request under many conditions where I would want it to persist - can be very tedious, % some key online descriptions only in a news file that has garbled characters in key passages. These three alternatives are described more fully in Sections 2 ,3 and 4. -------------------------------------------------------------------------- 2. Getting a file from SIMTEL20: two-step FTP via London --------------------------------------------------------- This section has the fullest sequence of advice, since it is the only method by which all JANET users can achieve interactive FTP connection. To avoid repetition, later sections in places point back to section 2. 2.1 Scope of advice ------------------- For UK people at any JANET site who * want MSDOS public-domain and shareware files from SIMTEL20, * want a proven method of access to SIMTEL20 itself, including online inspection of directories to see filenames and filesizes, * are not at a site offering direct FTP, * are new to FTP, and want a framework of understanding, not just a recipe. You will need to find people at your own site who can adapt the methods for the link with London, since this will vary from site to site. Broadly you are likely to be reaching London from one of three kinds of platform: * a well-supported unix host at your site (as in Section 2.5) * a well-supported VMS host at your site, * a PC linked to a suitable high-speed local network using something like the UK Rainbow package to give direct access to a JANET 'pad'. The London-SIMTEL20 link is standard for everybody, and is an example of what the rest of the world understands as FTP. 2.2 Authorizations ------------------ At most UK universities and polytechnics, both staff and students in principle have unrestricted access to international email and to the UK's substitute for FTP that links JANET sites. So all that is needed is locally authorised access to * a mainframe linked to JANET, or * a PC linked to a net linked to JANET, plus some specific information on distant sites and some knowhow. For the London interface with internet you need to know address : uk.ac.nsfnet-relay.sun or nsf.sun login : guestftp password: guestftp other : use a short form of your JANET email address as your reference for the session For SIMTEL20 you need to know address : wsmr-simtel20.army.mil login : anonymous password: anything - operator suggests 'guest' other : if asked for passwords during the session press Since, many UK and international facilities are close to capacity and prone to downtime, access in practice is resource-limited. 2.3 Outline and limitations --------------------------- A straightforward method is: * connect your site to the London interface, * connect the London interface to SIMTEL20, * transfer a copy of the file you want from SIMTEL20 to London, * close the link to SIMTEL20, then either * address a copy of the file to yourself at your own site, * close the link to London, or * close the link to London, * send to London for the file to be sent to you and deleted in London. and finally * wait. The first alternative uses a rather cumbersome special facility at NSF.SUN, though its use is identical for all JANET users. The second alternative depends on JANET file transfer utilities in use at your site, but can be streamlined and is usually quicker. The London interface does not connect your site directly to Internet. You are given a modest workspace in London to use as your base for FTP connections on Internet. London has to be used as a temporary intermediate store for files. It does not have much free space; it refuses entry when there is less than 1Mb free to share between users. Like any FTP connection, the connection between London and SIMTEL20 is in some ways a very limited affair. In particular: * you cannot ask SIMTEL20 to display help/info files on your screen - you have to bring them to London. However, the interface in London offers fewer facilities than you normally get when connected to another JANET site. In particular: * having got the SIMTEL20 help/info files to London you cannot ask London to display them on your screen - you have bring them to your own site. Although you may have read about automated FTP, there are no ready-made scripts suitable for you-London or London-SIMTEL20. 2.4 Getting information files before you start ------------------------------------------------ You may find the example in section 2.5 sufficient, but it is preferable to send two email messages in the following format, with your own email identity substituted for mine, and to read and perhaps to print the replies: 1 From: bsrdp@uk.ac.warwick.cu To: info-server@uk.ac.nsfnet-relay Request: guestftp Topic: userguide Request: end 2 From: bsrdp@uk.ac.warwick.cu Reply-To: bsrdp%cu.warwick.ac.uk@UKACRL To: trickle@awiwuw11.earn Subject: Anything you like, or leave out the whole line /pdget SIMTEL20.INF /pdget QUICKREF.LST The final @UKACRL refers to the JANET/EARN interface; from the point of view of EARN it is a part of every UK address. This second message should yield * Keith Petersen's standard file of information on SIMTEL20, including information about what to do when you get an ftp connection; * a list of the main MSDOS directories at SIMTEL20. 2.5 An annotated example of ftp from SIMTEL20 --------------------------------------------- I could connect my PC direct to the London interface, but I prefer to use one of Warwick's Unix mainframes as my base for communications. It has PD versions of ARC and UNZIP, and also ZOO, DEBOO, UUDECODE and XXDECODE which I need for the other routes. It is also where I keep an up-to-date copy of SIMIBM.ARC and scripts for partly automating some of the processes. So I will start at my PC and collect from SIMTEL20 pd1:FV137.ZIP , via my Warwick Unix host. I know of the existence and pathname of the file from a news announcement. [ A later version is now current, but I have left this annotated example unchanged ] To establish a style of presentation I will start with the familiar. I will sometimes use [ ] to enclose brief summaries of what appears on the screen, so I can concentrate on the key moves. I will also number the various sections for reference later in the file. Here goes: 2.5.1 --- WARWICK PC --- a:> a:>kermit MSDOS on my PC awaits input - no hard disk today, it failed physically during the week. I start an old small version of my PC communications package. Kermit-MS> Kermit-MS>c MSKERMIT on my PC awaits input. I ask to be connected to the network my PC is physically plugged into. [blank screen] [blank screen] The ageing Local Area Switching System awaits input! I tentatively press the key. Please select computer Please select computer anemone I enter the local name for the Unix host I use. 2.5.2 --- WARWICK UNIX HOST --- login: login: bsrdp My Warwick Unix host awaits a username. I enter my own username. Password: Password: I enter my own password - it isn't echoed! [variety of login info] TERM = (vt100k) TERM = (vt100k) My Warwick Unix host reports my usual terminal configuration and awaits for confirmation or the name of an alternative. I press to confirm my terminal type, although I'm not sure my PC end really is vt100 today! However, nothing goes wrong later in the session, and no other machine asks about terminal type. 41: 41: pad nsf.sun My Warwick Unix host awaits input. I ask to be connected to the London interface with Internet. 2.5.3 --- LONDON NSF.SUN --- Connected, break in character is ^p To enter command state type ^p followed by 'a' University of London Computer Centre (uk.ac.nsfnet-relay.sun) X.29 Service login: login: guestftp NSF.SUN awaits a username. I enter the standard username for public access to NSF.SUN The two lines referring to ^p have nothing to do with London but were printed by, and refer to, a process that was started by "pad" on the fast communications network at Warwick between my Warwick Unix host and NSF.SUN. Password: Password: guestftp NSF.SUN awaits a password. I enter the standard password for public access to NSF.SUN Warning - only 1723 Kbyte available for the whole service Do you still want to use use the service at the present time ? ( y or n ) Do you still want to use use the service at the present time ? ( y or n )y The limited space message appears if there is less than 4Mb of disk space left. If there is less than 1Mb then I am allowed on only to list the names of my files and/or delete some. I decide to go ahead. Enter your reference for this session: Enter your reference for this session: bsrdp@warwick NSF.SUN awaits the name of a directory to be created to hold my files. I enter a name in the recommended form for NSF.SUN - a short form of my JANET address. guest-ftp> guest-ftp> help NSF.SUN awaits input. I decide to ask for information, correctly guessing what the command might be. [List of commands and files] It takes a while before I realise that I have entered the GUEST-FTP HELP environment, that I shall stay in it until I type in a command to leave it, and that typing a listed command name now does not activate the command but simply causes information about it to appear on the screen. I spend a few minutes reading about commands and making a note of those I might want. I also read the short text files on offer. A reminder of how to leave the GUEST-FTP HELP environment is continually renewed on screen. guest-ftp> guest-ftp> ftp I ask for an ftp session to be started. 2.5.4 --- LONDON NSF.SUN FTP --- ftp> ftp> help NSF.SUN FTP awaits input. In this FTP session, what I get on my screen is similar to what users in the rest of the world see when they use FTP, and similar to what is directly available at selected JANET sites. I decide to ask for information, again correctly guessing the command. [Longer list of commands] It takes a while before I realise that this time I have not entered a help environment, and that typing a command name activates the command. To learn about "ascii" I must now type "help ascii". I spend a few minutes reading about commands and making a note of those I might want under the impression that I shall leave London behind when I connect to SIMTEL20. Later I discover that I do not leave London during distant connections - ftp is an armslength affair, and this help facility remains available throughout the connection to SIMTEL20. ftp> ftp> open wsmr-simtel20.army.mil I ask to be connected to SIMTEL20. ftp: connect: Network is unreachable ftp> NSF.SUN FTP could not make the connection and now again awaits input. Busy? Broken? Back soon? May be days? No information is obtainable. Later I discover that it is easier to get connected to SIMTEL20 in the morning before the USA wakes up! Later still I discover that the wsmr-simtel20 address is sometimes declared to be unknown - this happens when parts of Internet become inaccessible, and the server that confirms the army.mil addresses is not reachable. Seven hours and several attempts later ... Connected to 192.88.110.20 220 WSMR-SIMTEL20.ARMY.MIL [....] Name (192.88.110.20: guestftp) Name (192.88.110.20: guestftp) anonymous SIMTEL20 announces itself and awaits a valid username. I enter the standard username for public access to SIMTEL20. Later I learn that this is the usual username for FTP access around the world. ANONYMOUS user ok, send real identity as password Password: Password: guest SIMTEL20 accepts the username and awaits a password. I ignore the on-screen request and enter one of the suggestions from Keith Petersen's advice file - it isn't actually echoed. Later I discover that some FTP sites are quite fussy about the password and expect a valid email address containing @ . ftp> ftp>dir NSF.SUN FTP and SIMTEL20 await input. I ask NSF.SUN to ask SIMTEL20 to display a list of files in the current directory on SIMTEL20. 200 Port ... accepted 150 List started PS: [List of files in current directory on SIMTEL20] 226 Transfer completed Processes at SIMTEL20 clunk away giving a series of numbered progress reports and produce the information I want. Numbered reports are a general feature of FTP; each represents a phase that can fail and therefore cause the remaining phases to be aborted. ftp> ftp> cd pd1: I ask NSF.SUN FTP to ask SIMTEL20 to change directories so that I can look for the file I want in case it has been replaced by a newer version. I follow the notes I made from Keith Petersen's information file. 331 Default name accepted. Send password to connect to it. 331 Default name accepted. Send password to connect to it. Wow! Can't even change directory at SIMTEL20 without permission. I remember Keith's advice and press the key. [acceptance message] ftp> ftp> dir SIMTEL20 changes the directory. I ask NSF.SUN FTP to ask SIMTEL20 to display a list of files. [Two or three screens of file information roll by, including the target] So far, I only seem to be able to control output by using the Ctrl-S/Ctrl-Q keys to stop/start screen output on my PC. Later I discover that at some FTP sites I can reduce the list of names by specifying a unix-like target for the file by something like: dir fv* or dir fv*.* ftp> ftp> hash Transfer will take place silently and I won't have any indication of how it is going, so I ask for a # to be put on screen every so many bytes. There are so many linkage points between London and SIMTEL20 that transfer can be interrupted for 20-30 seconds at times (longer usually means the connection has been lost). Later I discover that directory listings are peppered with # signs if I forget to type hash again after a binary transfer. Hash mark printing on (1024 bytes/hash mark) ftp> ftp> type binary I ask NSF.SUN FTP to arrange that, until further notice during this session, files are to be despatched from SIMTEL20 in 8-bit binary format, to be treated like that on the way, and to be held in London in that format for re-transmission to Warwick. Despite Keith's strong advice to ask for TENEX mode, I find that ZIP/ARC files arrive in perfect condition. 200 Type I ok ftp> ftp> get fv137.zip SIMTEL20 agrees. I ask NSF.SUN FTP to ask SIMTEL20 to send a copy of the file I want. 200 Port 4.224 at host accepted 150 Retrieve of PD1:FV137.ZIP.1 (4 pages, 8128 8-bit bytes) 226 Transfer completed. 8128 bytes transferred 8128 bytes received in 17 seconds SIMTEL20 thinks it worked. NSF.SUN FTP is non-committal, but at least its byte count agrees. ftp> ftp> quit NSF.SUN FTP awaits input. I ask it to close the link with SIMTEL20 and to end the FTP session. For sites where direct FTP is available, this point marks the end of an FTP session. 2.5.5 --- LONDON NSF.SUN --- [Closing message from SIMTEL20] guest-ftp> guest-ftp>dir NSF.SUN awaits input. I ask for the files in my London directory to be listed. [one filename - fv137.zip] guest_ftp> guest_ftp> push It's there! NSF.SUN awaits input. I call a very basic transmission utility to send the file to my Unix host at Warwick. It is a tedious method. For regular use I prefer the sort of streamlined method described in Section 2.5.7. But the steps here are: * independent of facilities at your own site, * usable by a beginner from any host with a registered JANET address. Okay lets push a file using NIFTP Give local filename: Give local filename: fv137.zip NSF.SUN starts up a utility for sending files. I quote the file name in my directory on NSF.SUN. Later I discover that if I make a mistake it is simplest to answer nonsense to the remaining questions - NSF.SUN then rejects the request and I can start again. Give remote filename: Give remote filename: nsf.fv137.zip I quote the name I want the file to have on my Unix host to remind me of its origin until I'm sure it is OK. Give NRS name of remote host: Give NRS name of remote host: uk.ac.warwick.anemone I quote an address down to the actual machine that holds my home filespace at Warwick. Do you want binary or ascii (input b or a): Do you want binary or ascii (input b or a): b I'm sending a zip file - it must be binary. OK binary it is - input word size : OK binary it is - input word size : Well, it says default, so I'll just press Give user name on remote host: Give user name on remote host: bsrdp I quote my usual username for my Unix host. Give user password on remote host: Give user password on remote host: I quote my usual password for my Unix host - it isn't echoed Re-type password to make sure: Re-type password to make sure: I re-quote my password - again it isn't echoed Push status..please wait.. Push status..please wait.. OK - Request sent to the Spooler - use "q" to check guest_ftp> guest_ftp> q A message from the push utility unfolds as it puts my request into NSF.SUN's queue of jobs to be done. Later I discover that various checks are done, and that other messages may unfold. In particular, NSF.SUN checks whether the name of the "remote host" (my Unix host) is on its list of acceptable addresses. I accept the invitation to see my request in the list of waiting jobs. Sorry - this command has been disabled for the time being !!! guest-ftp> guest-ftp>exit NSF.SUN declines to do what it has just offered - presumably lists get horribly long. Since there is no means of checking, I shall just have to return to Warwick and wait to see what happens. I close the connection to London. 2.5.6 --- WARWICK UNIX HOST --- 42: 42: ls My Warwick Unix host awaits input. I ask for a list of files in my home directory. [ No sign of nsf.fv137.zip ] I get on with something else. About an hour later I notice a copy of the file has arrived and that the file size looks about right. About six hours after that a mail message arrives saying that the file has been transferred. I find the message next day. Later I discover that the copy of the file on NSF.SUN is deleted as soon as NSF.SUN thinks that it has succeeded in sending a copy. 94: 94: unzip -t nsf.fv137.zip I ask for the integrity of the zip file to be tested using a PD unix version of unzip that was circulated on the net some time ago. To get your own copy of unzip, collect the source code as a binary file from SIMTEL20 pd6:UNZIP.TAR-Z then rename it unzip.tar.Z uncompress, detar, and compile it. [each file in the zip reported to be OK] 95: 95: mv nsf.fv137.zip fv137.zip Now I know it is genuine, I no longer want to show where it came from. That's it for now - I'm not sure I've got the right configuration today for the next stage. But with my usual copy of kermit on the PC the final stages would start ... 96: 96: kermit s8 fv137.zip Request binary transfer to PC. With the software nowadays normally present at the two ends, I no longer have to bother swapping between 7-bit and 8-bit settings at the PC end. On completion of the transfer I would - test the integrity of fv137.zip on the PC (though this never goes wrong unless I fail to tidy up after interrupting an earlier transfer), - return to my Warwick Unix host to delete the copy there, - close the link to my Warwick Unix host. End of example 2.5.7 --- STREAMLINING NSF.SUN TO OWN SITE --- The NSF.SUN administrator recommends you not to push files from NSF.SUN, but to to pull them from your own site. It is good advice. At your own site you can store all the unchanging transfer data and avoid repeating it manually for each file pulled from NSF.SUN . However, recipes for pulling files from NSF.SUN depend on whichever of the medley of JANET file transfer methods is/are installed at your site. I can only show you what is possible and leave you to adapt it for your context. Here is a revised transcript of the relevant part of the session described in Sections 2.5.5 and 2.5.6, and then a brief guide to how on my Unix host I provided the new command used in the transcript. Revised transcript: [Closing message from SIMTEL20] guest-ftp> guest-ftp>dir NSF.SUN awaits input. I ask for the files in my London directory to be listed. [one filename - fv137.zip] guest_ftp> guest_ftp> exit It's there! I ask to end the connection to London. 42: 42: nsfget fv137.zip The Warwick unix host awaits input. I ask for the file to be collected from NSF.SUN using a new command I have created for this purpose. I have written the command so that if I have more than one file, I simply add extra names in one long line. fv137.zip:transfer id is 004756 43: 43: hhq My command calls hhcp, a file transfer utility often available on unix systems; hhcp sends my request to join the general queue of transfer requests to and from Warwick and reports the reference number of my request. No further information will be sent to me about the progress of this request unless it still hasn't been successfully completed in several days time, but there are means of checking its progress. I ask to see the state of the general queue. [list of requests in the queue without mine among them] 43: 43: ls -l Looks as though everything might have happened so fast that the transfer is complete. I ask to see a list of files in my current directory. [list which includes fv137.zip with a date and time more or less now ] End of revised transcript The sequence of steps to make the new command nsfget available on my Unix host was: * make a permanent record of the transfer parameters by entering hhstore nsf.sun and then completing the offered entry lines as shown, or skipping them by pressing , to read transfer authorization: guestftp transfer password: guestftp account name: account password: file password: output device type: output device type qualifier: mode of access: read and remove binary word size: 8 special options: * create a unix script file 'nsfget' specific to me since it includes the name of my temporary directory at NSF.SUN #!/bin/sh #`nsfget' to get my files from nsf.sun [ $# -ne 0 ] || { echo 'Ownuse: nsfget [ file ... ]' exit 1; } for i do hhcp -L -b -a nsf.sun:bsrdp@warwick/$i $i done exit 0 #End of nsfget * make the script executable by chmod u+x nsfget -------------------------------------------------------------------------- 3. Getting a file from SIMTEL20: FTP direct -------------------------------------------------------------------------- 3.1 Scope of advice ------------------- For UK people at those selected sites which have direct access to FTP and who * want MSDOS public-domain and shareware files from SIMTEL20, * are new to FTP. Much of the relevant advice is a subset of Section 2, and the longer sections of that are simply pointed to and not repeated here. 3.2 Authorizations ------------------ At UK universities and polytechnics in which direct FTP is being installed, both staff and students are in principle expected to have unrestricted access to FTP via mainframe hosts. Direct access from PCs may not be generally supported. To get access to SIMTEL20, you need to know address : wsmr-simtel20.army.mil ( or 192.88.110.20 ) login : anonymous password: anything - the operator suggests 'guest' other : if asked for passwords during the session press Accessing other sites is similar: the login response is identical, but * some sites insist that the password be a valid email address, * some sites insist that your site's Internet identity be in its own listing of Internet identities - this can be a dampener to your enthusiasm at a newly connected site. 3.3 Outline and limitations --------------------------- The method is simple: * connect to a suitable host as in section 2.5.1 above, * call ftp - on my unix host I simply enter ftp to start an FTP session as in section 2.5.4 above. Compared with the FTP session described in section 2.5.4 you have one important advantage on a unix host - during an FTP session you can start a subsidiary shell within which you have a minute or so to do things at your own site before the remote site closes the connection because of inactivity. In particular, this just gives adequate time to * run a verification of a .ZIP or .ARC binary just downloaded, * skim through a help/info file, * look through an annotated index of files from a particular directory. However, although this can be helpful for the first exploration of a distant site, it should not be regarded as a regular working method - a minute is a relatively enormous waste of network time. 3.4 Getting information files before you start ------------------------------------------------ Send email message#2 from section 2.4, or if you think the example in section 2.5.4 is enough, connect to SIMTEL20 and collect the two files pd1:SIMTEL20.INF pd1:QUICKREF.LST 3.5 Automation of FTP file collection ------------------------------------- The London interface in section 2.5.4 is limited in various important respects: it provides only a subset of normal FTP. At your own site, you can control how an FTP session is started, and in particular you can use ftp scripts to automate your connections to the distant site (section 3.5.1). This is * efficient and convenient for you, since you can repeat an attempted connection simply by calling the script again, * efficient for the distant site and the networks connecting you, since connect time excludes all the time you normally take to think and type during a connection. Typically an FTP exploration session then consists of many brief scripted connections with the results of one version of the script reviewed and edited into the next version. So for example, 60 minutes of clock time may need no more than 3 minutes of network time. More controversially, and with the risk that you might make a considerable nuisance of yourself, you may be able to automate the re-trying of connections if you often don't get through to the distant site first time (section 3.5.2). There is no satisfactory method of automating recovery from lost connections after file transfer has begun. The rest of this section supposes you are working from a unix host. In places the recipes that do or do not work for me may additionally depend on the fact that I am working in a csh environment under SunOS 4.1.1. I have chosen a style of working that unifies the approach in the two sections. If a distant site is almost always accessible first call then section 3.5.1 is preferable; if connection regularly requires several retries, section 3.5.2 is more convenient. 3.5.1 Scripts for ftp connections A script simply consists of a complete set of ftp commands to open, operate, and close an ftp connection, similar to those that you use for a manual connection but with some important differences: * the first few lines have their own special format, * the script must be complete - make sure you end with bye or close, * the script must be plain text - don't use a wordprocessor file with hidden formatting characters, * the script must be correct - build up your knowledge of a distant site by a series of modest information requests, and develop a habit of corect spellling. To get a directory listing from SIMTEL20, first prepare a text file, say 'simlist,' containing commands in this style: verbose open wsmr-simtel20.army.mil user anonymous guest dir pd1: arc-lib.dir bye Then enter the command line ftp -in < simlist and watch on-screen reports of the progress of the connection. If all goes well, you will in a few seconds have a new file 'arc-lib.dir' containing the directory listing from SIMTEL20. If you fail to connect successfully with the distant site, a retry simply consists of typing the command line again. If you are working in an environment with command history, like csh, this can be reduced to something like !ftp or even less - all you need after the ! is an opening scrap long enough to reach back uniquely through the history log. To get a binary file from SIMTEL20 you have to change to the directory containing the file you want and have to make sure that 8-bit rather than 7-bit transmission is used. So edit 'simlist' to contain commands in this style: verbose open wsmr-simtel20.army.mil user anonymous guest binary hash cd pd1: get fv138.zip bye On my unix host the specification of 'binary' is sufficient to get uncorrupted binaries from SIMTEL20. You may have to use 'tenex' as recommended in the advice file in section 3.4. Note that the current version of fvnnn.zip on SIMTEL20 may now be later than 138. You can include several small requests in one script, but until networks are more reliable big files are probably better handled with a separate script for each. In section 3.5.2, verbose is an essential command. Without it, your retry process will collect the same information over and over again. But for manually started scripts you can leave it out, and then you will only have a brief, though perhaps insufficiently informative, message if the connection fails. As your confidence/skill increases, you will be able to use the scripts in different ways. Here are two ideas. Idea 1 If you are unlikely to want a file copy of a directory, omit the filename for your end, for example dir pd1: and call the script with the command line ftp -in < simlist | less which releases network connections quickly, but allows you to browse up and down the listing at leisure. Idea 2 Make the ftp session a background process while you do something else. You might think of just entering the command ftp -in < simlist & but that sends progress reports to the screen, and if anything goes wrong the background process will be indefinitely suspended unable to send its error report to the screen. Use a command of the form ftp -in < simlist >>& ftp.log & so all messages are added to a general log that you can inspect and scrap from time to time. You would no longer need hash in your scripts, but keep verbose in. 3.5.2 Automating tries and re-tries For an automatic method of re-trying failed requests, it is difficult to devise rules to strike an efficient and responsible balance between persisting and stopping (an unresolved problem for the developers of FT-RELAY). A reasonable user-developed attempt at managing retries on unix hosts can be found on SIMTEL20 as pd6:BATCHFTP.TAR-Z Its management of the retries themselves seems to be sound, but it is * sensitive to the flavour of unix under which it is used, * critically dependent on the script being correct if it is to terminate and tidy-up properly, * unable to recover if a connection is lost once file transfer has started. Each of which means that unless you know how to inspect and manage unix processes on your system it is probably better left alone. To use it, collect it as a binary file and rename it batchftp.tar.Z uncompress, detar, and compile it. To avoid problems until you are experienced with it: * keep the scripts in a special directory, * change to the directory before calling the programme, * give the incoming files plain filenames without a path. You can experiment with relaxing these conditions if and when you have seen it deal successfully with a wide range of connection problems. An appropriate script, say 'simb', for getting a directory with batchftp would read: { verbose open wsmr-simtel20.army.mil user anonymous guest dir pd1: dir.filedocs bye } which is simply an ftp script from section 3.5.1 with new first and last lines, and in which * the verbose command is essential since it provides the data with which batchftp controls retries, * the bye/close command is essential in my system to ensure termination and file tidying after a successful connection. The script would be run as a background process by the command line batchftp -i simb & If you know you know that now is a bad time of day/week to launch batchftp, then rather than adding to network traffic by repeating tries that are almost bound to fail, put the command line itself into a one-line command file, say 'dosimb', reading batchftp -i simb and then enter commands like chmod u+x dosimb at 2330 Sat dosimb to arrange for it to be launched for its first try when networks are quiet. The temporary and permanent message files of batchftp are slightly infelicitous, lacking a final carriage return and linefeed. However, their format is critical to the operation of the programme. -------------------------------------------------------------------------- 4. Getting a file from SIMTEL20: one-step file request via FT-RELAY -------------------------------------------------------------------------- Although the examples in section 4.5 are for calling files from SIMTEL20 itself, those who use FT-RELAY usually aim at a mirror site like wuarchive.wustl.edu because: * there is usually a much better chance of first-time connection, * the peculiarities of pathnames at SIMTEL20 make it harder to include them in general shell scripts designed to save the tedious repetition of standard details to several remote sites. 4.1 Scope of advice ------------------- For UK people who have access to JANET and who - want MSDOS public-domain and shareware files from SIMTEL20, - want the convenience of delivery to their own site in one-step, - do not have access to direct FTP and do not want to operate manually at the London interface. You will need to find people at your own site who can adapt the methods for the link with FT-RELAY, since this will vary from site to site. Broadly you are likely to be reaching FT-RELAY from one of three kinds of platform: - a well-supported unix host at your site (as in Section 4.5) - a well-supported VMS host at your site, - a direct access point to a network at your site. Since action consists entirely in formulating and sending an appropriate message to FT-RELAY, the on-screen appearance of these three environments is likely to strike the beginner as having nothing in common! If you do not use a unix host you may find it easier to ignore section 4.5 and to start from scratch with the information in section 4.4. 4.2 Authorizations ------------------ As in section 2.2. 4.3 Outline and limitations --------------------------- The method is to send a message to your site's outgoing message queue and wait! On a unix host, an appropriate medium is an hhcp command which takes its turn in the list of outgoing messages, and stays there until: * deleted by FT-RELAY, or * deleted by you. In August 1991 it was true to say FT-RELAY deletes your message if: * it meets your request, or * the distant site says that the content of your request cannot be complied with, or * it fails to connect with the distant site [ which means that FT-RELAY does not have to keep long lists of unfilled requests, but also means that you have to make a lot of resubmissions if networks and/or sites are congested ], and FT-RELAY preserves your message if * the distant site says it is too busy. But the behaviour is still subject to experiment. For example, in Sep 1991 file requests to SIMTEL20 were kept alive for several hours until successful, though directory requests were dropped after one failure. To do this, FT-RELAY did *not* maintain a backlog of requests: it simply used a reply code that caused software at my site to keep the request in the queue of outgoing messages. That seems a reasonable behaviour. It would not, I think, be wise to press for FT-RELAY to hold its own backlog of requests. Although that might be convenient for people using background methods on an intermediate host, it would make a direct PC-JANET link impractical. 4.4 Getting information files before you start ------------------------------------------------ For information on SIMTEL20, send email message#2 from section 2.4, or if you think the example in section 4.5 is enough, send to FT-RELAY for the the two files pd1:SIMTEL20.INF pd1:QUICKREF.LST The general principles of how to use FT-RELAY are available on-line in JANET NEWS. Starting from my unix host, to read the advisory files I enter pad janet.news and follow the on-screen instructions to directory GATEWAYS, sub-directory FTRELAY, for the file files INTRO, CBS, and FTAM ; and to directory NETWNEWS, file NEWS33, for the original announcement which was garbled in the relevant section (each opening quote became a U and each closing quote became a T). 4.5 An example of a request to FT-RELAY --------------------------------------- The advice as it appears on JANET is almost ready-made for direct PC to FT-RELAY connection using the PC Rainbow utility. But implementing the advice on a unix host is trickier, particularly if you want to reach SIMTEL20 itself - directory names on SIMTEL20 use characters which on a unix system do powerful things. On my unix host I eventually implemented what is described as method B in NEWS33 . It works for both SIMTEL20 and unix mirrors. So here is the recipe. First establish a name, say ftb, for all future requests to FT-RELAY using this particular method, so that you can later experiment with other methods: hhalias UK.AC.FT-RELAY ftb Next, record the parameters that you want to be used every time you use this method, filling in or skipping the lines that appear automatically after the first command: hhstore ftb transfer authorization: anonymous transfer password: bsrdp@warwick.ac.uk mode of access: binary word size: 8 Although hhstore is not something to trust with confidential personal authorizations to a remote site, these standard formats are effectively public. Now you are ready to make your first two specific requests, one for a directory and one for a binary file. In practice each request is entered on a single line although I show them here using two lines each: hhcp -L ftb:"wsmr-simtel20.army.mil::(D)pd1:" arc-lbr.dir hhcp -L -b ftb:"wsmr-simtel20.army.mil::pd1:fv138.zip" fv138.zip You have asked for * the directory to be sent to you as a file, and to be given the name arc-lbr.dir on your system, * the file fv138.zip to be sent and given the same name. Notice the placing of the double quotes which contain the complete specifications for SIMTEL20 - for the topmost directory at a site the specification stops after (D). Notice too that the problem of directory management during file transfer is left to FT-RELAY. The unix host replies quoting the reference number for each one-line message and you are then free to continue. You can inspect the state of the message queue with hhq to see whether they have yet been dealt with ( tries are typically made at 5 minute intervals for half an hour, and after that the intervals typically double every six tries ). You can also inspect a detailed log of connection attempts from you to FT-RELAY with hhlog both while waiting, and after finding a message has been dropped without the requested file having arrived. To avoid re-typing long standard parts of the command line you can create simple executable shell scripts: for example, here are separate scripts for calling directory listings and calling binary files from SIMTEL20: #!/bin/sh # hhd - script to call a sub-directory listing case $1 in "") echo My use: hhd directoryname ;; * ) hhcp -L ftb:"wsmr-simtel20.army.mil::(D)pd1:" $1.dir ;; esac exit 0 #end of hhd #!/bin/sh # hhb - script to call a binary file case $2 in "") echo My use: hhb directoryname filename ;; * ) hhcp -L -b ftb:"wsmr-simtel20.army.mil::pd1:$2" $2 ;; esac exit 0 #end of hhb With these available, and the transfer authorizations permanently stored by hhstore as earlier in section 4.5, the two examples simply become hhd arc-lbr hhb arc-lbr fv138.zip It is possible to construct more elaborate scripts - see the companion file FTP2UK23.ZIP -------------------------------------------------------------------------- 5. File history - main revisions -------------------------------------------------------------------------- Version 2.3 Apr 1992 Updated information on Lancaster and Imperial College. Added oak.oakland to list of non-UK sites of interest. Version 2.2 Oct 1991 Added section 0.1 on file transfer on Internet and JANET. Revised sections 2.5 to 2.7 on getting files home from NSF.SUN. Version 2.1 Sep 1991 Added mirror at src.doc.ic.ac.uk Thanks to Lee McLoughlin for information on the IC mirror, and to Nino Margetic for significant suggestions on FT-RELAY scripts. Version 2.0 Aug 1991 Restructured to include mirrors at wuarchive.wustl.edu and nic.funet.fi one-step file request via FT-RELAY, direct FTP from selected sites. Thanks to Tim Clarke and Rob McMahon for advice on FTP and FTP-RELAY at Warwick, and to Dirk Reuver and Andrew McClean for significant suggestions on routes and methods. Version 1.0 Jul 1991 First public version covering alternatives - Lancaster, Trickle's, mirror at garbo.uwasa.fi two-step FTP via London. Version 0.1 May 1991 First draft of a response to an enquiry by Keith Petersen about FTP connection between the UK and SIMTEL20. Limited circulation of complete draft to various experts: Tony Bates , i/c NSF.SUN Keith Petersen , i/c SIMTEL Tim Clarke , i/c Comms at Warwick and of part of draft Turgut Kalfaoglu , i/c TRICKLEs in Europe Alan Phillips , i/c UK National Software Archive, Lancaster Timo Salmi , i/c VAASA . Thanks to all for advice and comment - errors remain my responsibility! ----------------------------------------------------------------------------- Hylton Boothroyd h.boothroyd@warwick.ac.uk or, if necessary: Warwick Business School Janet: h.boothroyd@uk.ac.warwick University of Warwick Internet: h.boothroyd%warwick.ac.uk@nsfnet-relay.ac.uk COVENTRY, CV4 7AL Uucp: h.boothroyd@warwick.uucp Phone (+44) 203 523523 Earn/Bitnet: h.boothroyd%uk.ac.warwick@UKACRL ------------------------------------------------------------------------------