3A55B Page 1
Sep 80
FTP - TRANSFERRING FILES ACROSS THE ICF NETWORK
CONTENTS page
1 BACKGROUND .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 2
2 IMPLEMENTATION . .. .. .. .. .. .. .. .. .. .. .. .. .. 2
3 REQUESTING A TRANSFER .. .. .. .. .. .. .. .. .. .. .. 2
4 THE FTP PROGRAM .. .. .. .. .. .. .. .. .. .. .. .. .. 3
5 EXAMPLES . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 5
6 REQUIREMENTS FOR OTHER HOSTS ON SERCNET .. .. .. .. .. 5
7 FILE ACCESS PERMISSION .. .. .. .. .. .. .. .. .. .. .. 7
8 INTERROGATING THE QUEUES .. .. .. .. .. .. .. .. .. .. 9
9 KILLING A REQUEST . .. .. .. .. .. .. .. .. .. .. .. .. 9
10 LISTING AVAILABLE HOSTS . .. .. .. .. .. .. .. .. .. .. 10
11 LOG OF TRANSFERS .. .. .. .. .. .. .. .. .. .. .. .. .. 10
12 REFERENCES AND FURTHER READING . .. .. .. .. .. .. .. .. 10
3A55B FTP-Transferring Files Across the Network Page 2
Sep 80
1. BACKGROUND
FTP stands for File Transfer Protocol, a protocol designed
to be network independent. It is implemented on the DEC-10
and allows the transfer of files between two DEC-10's
networked together via DECNET.
With the advent of the DECNET/SERCNET gateway (2) it becomes
possible to transfer files across both networks to similar
FTP processes on SERCNET hosts.
The version of FTP described here will be replaced later by
a more comprehensive system which will allow multiple
transfers and will be integrated into the Galaxy spooling
system. It will appear on the DEC-10 in 1981.
2. IMPLEMENTATION
This protocol has been implemented on the Edinburgh DEC-10
as a spooling system with requests for transfers being
generated by a monitor command called FTP. These requests
are subsequently processed by a spooler called FTPSPL which
is run as an operator job. It communicates with a similar
job on the destination machine. These spoolers handle the
actual transfer and check the validity of access to the
specified files. A note that the transfer has occurred is
sent to each user involved through a log file, FTP.LOG, in
their directory (see 9 below). There is no possibility of
file security being breached, as each user is able to
control who has permission to read or write files in their
directory and to limit the type of access allowed (see 7
below).
In general files may be transferred between any DEC-10 on
SERCNET and any other SERCNET host which supports FTP.
3. REQUESTING A TRANSFER
Note: It is necessary to read this section carefully
because the default conditions are designed to ensure
maximum file security across the network. Thus it may be
necessary to specify various switch settings, in order not
to be caught by file protection errors.
The preliminary conditions necessary for a successful
transfer are as follows:
- That the user has sufficient knowledge of the nature
of the remote computer's filestore, namely, the
format of file names, and whether a user identity
(eg: user name, number or PPN and password etc).
3A55B FTP-Transferring Files Across the Network Page 3
Sep 80
- That appropriate access permission has been granted
to the submitter by the sender and recipient of the
file(s) to be transferred (see section 7). If the
submitter of the request is either the sender or
recipient of the file, full access permission is
assumed.
- That the user is aware of the meaning and default
settings of the ACCESS and DELETE switches (see below
in this section).
4. THE FTP PROGRAM
This is run by issuing the monitor command FTP with
arguments as follows:
.FTP DESTINATION_SPEC/SWITCH1/SWITCH2/...
= SOURCE_SPEC/SWITCH1/SWITCH2/...
DESTINATION_SPEC and SOURCE_SPEC are specified as
NODE_FILESPEC;
NODE is the unabbreviated node name of the source or
destination computer, if no node name is given the current
host is assumed.
FILESPEC for a DEC-10 may be the full DEC-10 file
specification, eg:
ERCC_DSKA:FOO.TXT[100,101]
If no directory specification is given, one's own area is
used and if no destination file name is given then the
source file name is used.
FILESPEC for any other computer is a full file specification
which will be recognised by that computer's filestore and
takes no default values.
To read a file from another machine the source (input file)
side of the FTP commands should refer to that file. To
write a file to another machine the destination (output
file) side of the FTP command should refer to that file.
SWITCHES have the general form: /SWITCH:ARGUMENT, these
arguments are described in detail in Section 4 but a brief
description of the switch functions follows:
HELP type a list of the options available
LIST list the FTP queue of requests,
submitted on this machine
KILL:xxxx remove the given request from the queue
(xxxx is the sequence no of the request)
NODES type a list of the hosts which FTP
recognises
3A55B FTP-Transferring Files Across the Network Page 4
Sep 80
Switches associated with the DESTINATION_SPEC are PASSWORD
and ACCESS:
PASSWORD has as its argument the FTP password for the
output file. The passwords on the DEC-10 are
not those used by LOGIN but special ones for
FTP which are kept in a SWITCH.INI file in the
same directory as the destination file (see
section 7). The meaning of the password on
other hosts varies from system to system (see
section 6). The password switch may be
omitted; in which case the program will
prompt the user later for the password if it
is required.
ACCESS has the following permitted arguments which
control access to the files:
CREATE - create a new file only ( default)
WRITE - replace an existing file only
CWRITE - create or replace an existing file
APPEND - append to an already existing file
CAPPEND - create or append to an existing file
SUBMIT - enter file into the machine's batch
queue
PRINT - spool file to the specified output
device (default for device "LPT" and
"PLT")
Switches associated with the SOURCE_SPEC are PASSWORD and
DELETE;
PASSWORD has as its argument the FTP password in the
SWITCH.INI file in the same directory as the
source file (see section 6).
DELETE relates to the deletion of the source file;
it has three possible arguments:
NEVER - do not delete ( default).
AFTER - if deletion is to take place after
the transfer.
DURING - if deletion is to take place at the .
same time.
Deletion after the transfer will only result
if the transfer is successful.
The defaults for ACCESS and DELETE may be overridden by the
submitter of a request. The submitter's SWITCH.INI file may
contain a line for FTP giving the required switches. eg:
FTP/ACCESS:CWRITE/DELETE:AFTER
in a user's SWITCH.INI file would mean that every time a
request was submitted without giving an ACCESS or DELETE
3A55B FTP-Transferring Files Across the Network Page 5
Sep 80
switch the defaults taken would be CWRITE and AFTER
respectively.
5. Examples
5.1 A user [72,15] on the ERCC DEC-10 typing:
.FTP =UMIST_FRED.TXT[66,21]
would generate a request with the defaults set as follows:
ERCC_FRED.TXT[72,15]/ACCESS:CREATE =
UMIST_FRED.TXT[66,21]/DELETE:NEVER
Also the user would be prompted for the password for
UMIST[66,21], but not for the file on his/her own area.
5.2 The same user typing:
.FTP UMIST_JOHN.EXE[66,21]/ACC:WRITE=
JANE.EXE[27,14]/PASS:xyz
would generate the request:
UMIST_JOHN.EXE[66,21]/ACCESS:WRITE =
ERCC_JANE.EXE[27,14]/PASSWORD:xyz/DELETE:NEVER
and would be asked for the password for UMIST_[66,21].
5.3 To print a file on the UMIST line printer the user would
type:
.FTP UMIST_LPT02:=FRED.LST/DEL:AFTER
this would generate the request:
UMIST_LPT02:FRED.LST/ACCESS:PRINT =
ERCC_FRED.LST[72,15]/DELETE:AFTER
and no passwords would be required, being inappropriate for
a line printer.
6. REQUIREMENTS FOR OTHER HOSTS ON SERCNET
6.1 Introduction
For each type of host on SERCNET, the DEC-10 FTP prompts for
the necessary information required for that machine. The
user has only to provide the right values for each argument.
The arguments required from both the DEC-10 and the other
machine in question are given below.
3A55B FTP-Transferring Files Across the Network Page 6
Sep 80
Note that in the examples the computer prompts are in lower
case and the users replies are in upper case. Text
including and to the right of the ';' is comment only.
6.2 GEC 4000 series
Transfers to and from these machines require a filename, a
username and sometimes a password, eg:
.FTP RLGAF_=JONAH.DAT ;send a file to the
;RL GEC machine 'A'
GEC filename or <cr> for device for RLGAF_ : .XYZ ;give file
GEC login name for RLGAF_ :SMITH ;and username
GEC login password for RLGAF_ :<cr> ;user has no password
GEC account name for RLGAF_ :<cr> ;default to username
For transferring files from a GEC to the DEC-10, a filename,
a GEC user name and the appropriate DEC-10 FTP password must
be given:
ready ;GEC prompt
TRANSFER ;FTP transfer command
TRANSFER process for MAFS, version 4 ;title from GEC
remote computer?
NET.EDXAF ;the ERCC DEC-10
local filename? (null implies a device)
.XYZ ;the file name
remote filename? (null implies a device)
JONAH.DAT[72,15] ;the ERCC filename
remote username?
<cr> ;defaults to the GEC username
remote password? (this is not echoed)
MYPASS ;the DEC-10 FTP password on [72,15]
local username?
STOP ;do not prompt for any more arguments
options? (default is SEND, MAKE or APPEND)
FETCH ;read the file from the DEC-10 to the GEC
For a full description of the TRANSFER facility on the ICF
GEC MUMS see the OS4000 Reference Manual.(3)
6.3 The IBM 360/195 at Rutherford (called RLIAF)
Transfers to and from this machine require the user
identifier (ID) and user account name. In addition, it
should be noted that file transfers to and from RLIAF only
work for OS datasets. Attempts to transfer ELECTRIC
datasets will fail.
When transferring to RLIAF, it should be noted that access
can either be for normal file transfer or for submission of
batch jobs. See reference (1) for a description of the
format of file to send to the HASP system. An example might
be:
3A55B FTP-Transferring Files Across the Network Page 7
Sep 80
.FTP RLIAF_=IBMFOR.TXT ;send a job to the IBM
;batch system at RL
Dataset name for RLIAF_ : OCT.10*RGD
;not needed for batch job
IBM ID. (2 chars) for RLIAF_ : ID ;give the ID
IBM account (4 chars) for RLIAF_ : 1234 ;give a/c name
When transferring from the IBM to the DECsystem-10, it
should be remembered that although the ID and account name
are both prompted for, the account name is not echoed. An
example might be:
.FTP ERCC_IBMFOR.TXT=RLIAF_OCT.10*RGD
IBM ID. (2 chars) for RLIAF_OCT.10*RGD : ID
IBM account (4 chars) for RLIAF_OCT.10*RGD :
EXIT
At present it is only possible to initiate transfers to and
from the IBM from another host and not from the IBM itself.
6.4 PRIME machines
Transfers to and from these machines require a filename, a
username and sometimes a password, eg:
.FTP RLPBF_=JONES.DAT ;send a file to the
;RL PRIME machine B
PRIME filename for RLPBF_ : _ABCD ;give suitable name
PRIME login name for RLPBF_ :SMITH ;and username
PRIME login password for RLPBF_ :XYZ ;user password
For transferring files from a PRIME to the DEC-10, a
filename, a PRIME account name and the appropriate DEC-10
FTP password must be given.
ok, ;PRIME prompt
FTP ;FTP command
ftp v.6.4: default parameters(without passwords):
remote site = rlpa local treepath = ......> ;FTP header
> SITE EDXA ;specify ERCC DEC-10
> REMOTE username password ;DEC-10 username and
;FTP password
> ACCOUNT accountname ;PRIME account name
then either:
> SEND _ABCD JONES.DAT[72,15] ;send file _ABCD to DEC-10
or:
> FETCH JONES.DAT[72,15] _ABCD ;get file _ABCD from DEC-10
>QUIT ;return to command level
3A55B FTP-Transferring Files Across the Network Page 8
Sep 80
For a full description of the PRIME FTP facility on the ICF
PRIME MUMS see the PRIME Reference Manual.(4)
7. FILE ACCESS PERMISSION
Access to files in a DEC-10's directory is determined either
by an FTP entry in a SWITCH.INI file in that directory or by
the standard DEC-10 file and UFD protection system if no FTP
entry is given in SWITCH.INI.
The access in SWITCH.INI is governed by the setting of two
switches : PASSWORD and USERS:
PASSWORD takes as a value, up to 12 alphanumeric
characters A password is needed by anyone
other than the user who wishes to read or
write in the users area.
USERS specifies those who may access your directory
and what type of access they may have. Its
value is a list of other users, and access key
letters, separated by commas and enclosed in
round brackets.
DEC-10 users are specified by node name and
project-programmer number, which may include
wild project or programmer numbers.
SERCNET users are specified either by their
SERCNET title or the global name 'GATEWAY' and
the user name or user identifier, or '*' for
all users.
The access key letters may be a subset of the
following:
R - read
D - delete after read
C - create new files
W - write - replace old versions
A - append
* - all of the above
eg:
/USERS:(ERCC_[100,*]=*,GATEWAY_SMITH=RWC,GATEWAY_*=CW)
Two or more USERS switches maybe used but in the absence of
any, no access privileges are assumed.
When attempting to read or write a file, if no SWITCH.INI
file is found, or PASSWORD and USERS switches are not
present then the 'all-other-users' field of the directory
and file protection codes are used to determine access
3A55B FTP-Transferring Files Across the Network Page 9
Sep 80
permission.
A typical SWITCH.INI file might look as follows:
LOGIN/DSKFUL:PAUSE/PAGE
FTP/PASS:friends/USERS:(UMIST_[100,*]=
RC,UMIST_[*,*]=R,GATEWAY_*=RCW)
FTP/ACCESS:CWRITE/DELETE:AFTER
This would allow anybody logged on to UMIST with project
number 100 to read files from this directory and create new
files, anybody else from UMIST to read them only and all
users on a host on SERCNET (excluding the UMIST DEC-10) to
read, create and write files. For security reasons, it is
important that the user should protect his/her SWITCH.INI
file against being read by unauthorised persons.
Where the /USERS switch is used, the scan stops once a match
is found for a node and user. Therefore, in the above
example, access for user UMIST_[100,100] would be RC and not
R. It is therefore neccesary to specify individual users
before wild specifications in the list.
The other two FTP switch settings in the example above are
redefining the default settings for /ACCESS and /DELETE.
8. INTERROGATING THE QUEUES
The FTP command, if given on its own or with the /LIST
switch, will list the queue of files waiting transfer to or
from the Edinburgh DEC-10 but not those queued on any other
machine. For example if the queues are interrogated after
the previous example transfers have been requested the
output would look as follows:
.FTP/L
Seq User Destination Source
*UMI168 [72,15] ERCC_FRED.TXT[72,15]=UMIST_FRED.TXT[66,21]
UMI653 [72,15] UMIST_JOHN.EXE[66,21]=ERCC_JANE.EXE[27,14]
UMI358 [72,15] UMIST_LPT02:FRED.LST=ERCC_FRED.LST[72,15]
RLG446 [72,15] RLGAF_.XYZ=ERCC_JONAH.DAT[72,15]
RLI465 [72,15] RLIAF_OCT.IDFRED=ERCC_IBMFOR.TXT[72,15]
RLP284 [72,15] RLPBF__ABCD=ERCC_JONES.DAT[72,15]
Where * indicates the job being transferred
3A55B FTP-Transferring Files Across the Network Page 10
Sep 80
9. KILLING A REQUEST
A file transfer request may be removed from the queue by
appending the switch KILL to the FTP command. This switch
takes as its value the sequence number given when the queue
is listed. A request can only be killed by the submitter of
the request or by the operator. Thus to kill the second
request shown in Section 4 above, one would type:
.FTP/KILL:UMI653
the system would respond:
Killed
10. LISTING AVAILABLE HOSTS
The switch NODES appended to an FTP command will cause the
current set of hosts which offer an FTP service to be
displayed at the terminal eg:
.FTP/NODES
List of nodes to which file transfer is possible
Node type node type node type
UMIST DEC10 ERCC DEC10 YORKF DEC10
KELVIN DEC10 IBMTST IBM IBM IBM
NEGAF GEC BRGAF GEC RLGCF GEC
.
.
.
.
11. LOG OF TRANSFERS
A note of each transfer which has taken place is left in a
log file FTP.LOG in the directory of the submitter of the
request, and in the source and destination directories. The
log includes an indication of whether or not the transfer
was successful and if not, why it failed. Thus it is
possible to keep track of who has been reading files from
your directory and why a transfer to your directory failed.
A log file for ERCC_[72,15] after the requests shown in
section 8 had been proccessed would looks as follows:
12:45:56 10-Apr-79
<<RECEIVING<< FRED.TXT[72,15] from UMIST_FRED.TXT[66,21]
for user ERCC_[72,15] Unsuccessful - file already exists.
13:23:45 10-Apr-79
>>SENDING>> JANE.EXE[27,14] to UMIST_JOHN.EXE[66,21]
for user ERCC_[72,15] Success
3A55B FTP-Transferring Files Across the Network Page 11
Sep 80
15:14:23 10-Apr-79
>>SENDING>> FRED.LST[72,15] to UMIST_LPT02:FRED.LST
for user ERCC_[72,15] Success queueing file succeeded
10:24:54 14-Jul-80
>>SENDING>> JONAH.DAT[72,15] to RLGAF_.XYZ
for user ERCC_[72,15] Success
11:04:05 15-Jul-80
>>SENDING>> IBMFOR.TXT[72,15] to RLIAF_
for user ERCC_[72,15] Success
11:05:16 14-Jul-80
>>SENDING>> JONES.DAT[72,15] to RLPBF__ABCD
for user ERCC_[72,15] Success
12. REFERENCES AND FURTHER READING
References.
(1) 3A55A - Submitting IBM Jobs From the DECsystem-10
(2) 3A55C - The DECsystem-10 Network Gateway
(3) OS4000 Reference Manual - Interactive Computing
Facility. Rutherford Laboratory, Chilton, Didcot,
Oxon. OX11 0QX.
(4) PRIME Reference Manual - Interactive Computing
Facility. Rutherford Laboratory, Chilton, Didcot,
Oxon. OX11 0QX.
Further Reading.
(5) A Network Independent File Transfer Protocol, High
Level Protocol Group - EPSS Liaison Group. Dec 77