informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/computers/ftp2uk23.inf

1688 lines
69 KiB
INI
Raw Permalink Normal View History

Initial commit
2021-04-15 11:31:59 -07:00
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:
- 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:
- 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
------------
- 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
- 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: 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
------------------------------------------------------------------------------