3A55B                                                     Page 1
                                                          Sep 80


                       CONTENTS                            page 

1  BACKGROUND  .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..  2

2  IMPLEMENTATION  . .. .. .. .. .. .. .. .. .. .. .. .. ..  2

3  REQUESTING A TRANSFER   .. .. .. .. .. .. .. .. .. .. ..  2

4  THE FTP PROGRAM   .. .. .. .. .. .. .. .. .. .. .. .. ..  3

5  EXAMPLES  . .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..  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