NYU, ANL, and LBL Joining the Net
Proposal to implement remote job execution over FTP using special filenames.
Feinroth, Y. and R. Fink, "NYU, ANL, and LBL Joining the Net", RFC 551, DOI 10.17487/RFC0551, August 1973, <https://www.rfc-editor.org/info/rfc551>.
@misc{rfc551,
series = {Request for Comments},
number = 551,
howpublished = {RFC 551},
publisher = {RFC Editor},
doi = {10.17487/RFC0551},
url = {https://www.rfc-editor.org/info/rfc551},
author = {Y. Feinroth and R. Fink},
title = {{NYU, ANL, and LBL Joining the Net}},
pagetotal = 2,
year = 1973,
month = aug,
} RFC text
Network Working Group Y. Feinroth
Request for Comments: 551 NYU
R. Fink
LBL
August 27, 1973
New York University
Courant Institute of Mathematical Sciences
AEC Computing and Applied Mathematics Center
251 Mercer Street
New York, N.Y. 10012
ARPA Network Information Center
Stanford Research Institute
Menlo Park, California
Several Atomic Energy Commission installations are planning to
enter the network in the (hopefully) near future. These sites
include Argonne National Laboratory (IBM 360/195), Lawrence Berkeley
Labs, (CDC 7600), and New York University (CDC 6600). Our
applications make early implementation of an RJE facility imperative,
and although we are resigned to the necessity of implementing FTP, we
would like to avoid RJE protocol at least in the first go-around. We
would like to be able to use FTP to transfer a file, have it queued
for execution, and return output and status information.
To this end we propose to implement local conventions within the
site dependent PATHNAME parameter of the FTP. Specifically, the
following commands are specified:
STOR RJE.JOB<rest of pathname> queue this file for execution
(STOR/RETR) RJE.PR < > transfer remote job print file
(STOR/RETR) RJE.PU < > " " " punch "
(STOR/RETR) RJE.MT < > " " " magtape "
RETR RJE.STAT < > retrieve status of remote job
The job execution parameters are not part of the protocol, but
must be specified in the standard site dependent control cards which
are transmitted with the file. These parameters also determine the
output disposition, and the output can be retrieved by the user via
RETR, or (optionally) automatically by server initiation via STOR.*
The RETR RJE.STAT causes the server to create a file with the status
information and transfer it to the user. The FTP user/acct/pass
logon is used only to validate the data transfer, not the job's right
to execute, and to identify and distribute the output.
We are concerned that we may have overlooked some problems which
are obvious to more knowledgeable people and invite (and request)
comments.
* note that in this case the RJE server is an FTP user.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Tony Hansen 08/08 ]
AI ELI5
On this page
§1The Problem
Several Atomic Energy Commission installations were planning to join the ARPANET, including Argonne National Laboratory (IBM 360/195), Lawrence Berkeley Labs (CDC 7600), and New York University (CDC 6600). These sites had diverse research applications that made early implementation of remote job entry (RJE) capability essential. While they accepted the necessity of implementing FTP (File Transfer Protocol) to participate on the network, they wanted to avoid having to implement a separate RJE protocol in addition to FTP. This RFC proposes a solution that leverages FTP to accomplish RJE by using special filename conventions.
Three new computer sites wanted to join the network. They needed to be able to send jobs to their big computers from a distance, but they did not want to write a whole new program just for that.
§2The Proposed Solution
The proposal uses FTP with special local pathname conventions to implement RJE. To submit a job for execution, a user sends a STOR (store) command to a file named RJE.JOB followed by the rest of the pathname, with the job queued for execution. To retrieve a remote job's output, a user can retrieve files using STOR or RETR commands with special names: RJE.PR for print output, RJE.PU for punch output, and RJE.MT for magtape output. A user can check the status of a submitted job by sending a RETR command for RJE.STAT, which causes the server to create a status file and transfer it to the user. Job execution parameters are not part of the protocol itself, but instead are specified in standard site-dependent control cards that are transmitted with the job file. These control cards also determine where the output should go. The user's FTP login credentials are used only to validate the data transfer, not to determine whether the job has permission to execute.
When you send a file to a computer named RJE.JOB, it runs the file as a job. RJE.STAT gets you information about your job. This reuses the file-transfer system, so you do not need a new protocol.
§3Advantages of This Approach
This proposal allows research sites to implement remote job execution without developing a separate RJE protocol. By building on FTP, which sites must implement anyway, the protocol overhead is minimized. The use of reserved pathname conventions (RJE.JOB, RJE.PR, RJE.PU, RJE.MT, RJE.STAT) provides a clear semantic separation without requiring protocol changes. Site-dependent control cards and job parameters are handled through standard conventions, allowing flexibility in how individual sites configure job execution, priority, output handling, and resource allocation.
This way, sites do not have to build something brand new. They just add special filenames to their existing file-sending system, and it works for running jobs.