Simtel MSDOS 1992 June/SIMTEL_0692.cdr/msdos/info/ftp2uk23.inf

Text File | 1992-04-29 | 67.8 KB | 1,688 lines

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, [e-mail]

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:
          - 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: [e-mail]
    To:  [e-mail]
    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 [e-mail]
                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: [e-mail]
        To: [e-mail]
        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 [e-mail]
                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: [e-mail]
         Reply-To: bsrdp%cu.warwick.ac.uk@UKACRL
         To: [e-mail]
         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
------------
    -   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: [e-mail]
    To: [e-mail]-relay

    Request: guestftp
    Topic: userguide
    Request: end

  2
    From: [e-mail]
    Reply-To: bsrdp%cu.warwick.ac.uk@UKACRL
    To: [e-mail]
    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
  - 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:<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: [e-mail]
        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        [e-mail]     or, if necessary:
Warwick Business School Janet:    [e-mail]
University of Warwick   Internet: [e-mail]
COVENTRY, CV4 7AL       Uucp:     [e-mail]
Phone [phone]  Earn/Bitnet: h.boothroyd%uk.ac.warwick@UKACRL
------------------------------------------------------------------------------