GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


archive:computers:ftp2uk23.inf

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:<msdos.info>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:

  1. 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:<msdos> 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:<msdos.filedocs>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:

  1. 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:<msdos.filutl>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:<msdos> 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:<msdos.filedocs>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:<msdos> 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


  1. 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 <ENTER>

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 <msdos.starter>SIMTEL20.INF
  /pdget <msdos.starter>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:<msdos.arc-lbr>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]<ENTER>

  The ageing Local Area Switching System awaits input!
  I tentatively press the <ENTER> 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) <ENTER>

  My Warwick Unix host reports my usual terminal configuration and
  awaits for confirmation or the name of an alternative.
  I press <ENTER> 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:<ANONYMOUS>

 [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:<msdos.arc-lbr>

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

  Wow! Can't even change directory at SIMTEL20 without permission.
  I remember Keith's advice and press the <ENTER> 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:<MSDOS.ARC-LBR>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 <default> ascii (input b or a): Do you want binary or <default> ascii (input b or a): b

  I'm sending a zip file - it must be binary.

OK binary it is - input word size <default 8>: OK binary it is - input word size <default 8>:

  Well, it says default, so I'll just press <RETURN>

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:<unix-c.file-mgmt>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 <RETURN>, 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 <ENTER>

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:<msdos.starter>SIMTEL20.INF
  pd1:<msdos.starter>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:<msdos.arc-lbr>  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:<msdos.arc-lbr>
      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:<msdos.arc-lbr>

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:<unix-c.networks>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:<msdos.filedocs> 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

  1. want MSDOS public-domain and shareware files from SIMTEL20,
  2. want the convenience of delivery to their own site in one-step,
  3. 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:

  1. a well-supported unix host at your site (as in Section 4.5)
  2. a well-supported VMS host at your site,
  3. 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:<msdos.starter>SIMTEL20.INF
  pd1:<msdos.starter>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:<msdos.arc-lbr>"
                                                           arc-lbr.dir
hhcp -L -b ftb:"wsmr-simtel20.army.mil::pd1:<msdos.arc-lbr>fv138.zip"
                                                           fv138.zip

You have asked for

  • the directory <msdos.arc-lbr> 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:<msdos.$1>"  $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:<msdos.$1>$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


/data/webs/external/dokuwiki/data/pages/archive/computers/ftp2uk23.inf.txt · Last modified: 2001/11/08 10:19 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki