RFC 490

RFC 490 ✨ SURROGATE RJS FOR UCLA-CCN 🎀

• Series: Network Working Group 🌸
• Author: John R. Pickens, UCSB 💖
• Date: 6 March, 1973 📅
• NIC #: 15355
• References: RFC # 436 and RFC # 477 🔗
• Obsoletes / updates: the header doesn't list anything this one obsoletes or updates, and it doesn't state a category or status 🤷‍♀️

---

Okay so bestie, by using UCSB's Network Standard RJS* you can now get to UCLA-CCN's RJS without converting to the UCLA protocol 💅 No more making files on some random middle-man host either, which is so iconic 🙈 For example, TIP users can run hot card readers and printers through UCSB's Remote Job Server and have their jobs execute at UCLA-CCN 🖨️✨ The downsides compared to connecting directly to UCLA are:

1. A small amount of additional JCL is required to route jobs from UCSB to UCLA. 📝
2. A UCSB batch account must be opened. 🧾
3. Turnaround time includes waits in UCSB batch queues. ⏳
4. The current implementation requires separate submission and retrieval steps. 🔁
5. The RJS terminal used for submission/retrieval at UCLA-CCN should not be accessed online until all transfers to/from UCSB are complete. 🚫📵

Hopefully these downsides are outweighed by the super convenient interface to standard RJS 🥹💜

Attached is the document which describes this procedure to access UCLA-CCN. 📎🦋

_________________________________

*RFC #436 announces RJS at UCSB and RFC #477 describes its use. 📣

---

UCLA REMOTE JOB SUBMISSION FROM UCSB 🦋

Introduction

Users of the IBM 360/75 at UCSB can now route jobs to and from UCLA-CCN (IBM 360/91) 🚀 Only the reading, printing, and punching happen at UCSB, while the scheduling, allocation of resources, and execution happen at UCLA. This program works by setting up operator and data connections with UCLA's Remote Job Service over the ARPA Network and sending operator commands to control job submission and retrieval. So you can run jobs on UCLA's 360/91 almost like you're sitting right there at UCLA 😭🧚

Procedure

Submission and retrieval are two separate phases, and the user must start each one for every UCLA-bound job 🙃 Usually two UCSB jobs are needed for the two phases of one UCLA job. The exceptions are the BATCH options described below, and jobs with a guaranteed fast UCLA turnaround (e.g. QUICKRUN jobs.) ⚡

Commands go through JCL to the local process, and the results and messages get recorded in the RJS system log on the user's listing. The user must be aware of the timing of their commands. For example, asking to retrieve print output for a specific job will throw an error if that job hasn't finished running at UCLA 🥴 The available commands are READ, PRINT, PUNCH, STATUS, and TERMID.

The error diagnostics are fairly readable, though that isn't always possible 🫠 Error conditions are described in the section "ERRORS".

Job Submission

The READ command sends jobs to UCLA. It's the default if no other command is given 💌 Multiple UCLA jobs can be batched together under a single read operation. Be super careful to end the batch with the correct delimiter (see DD Cards below) so that any following non-UCLA jobs don't get sent to UCLA by mistake 😬 If you're submitting from the campus computer center, a good move is to put the intended destination on the job submission card. If UCLA accepts the job, UCLA will record a message showing the job name and the number of cards received ✅

Single Job Retrieval

PRINT (JOBNAME) and PUNCH (JOBNAME) explicitly fetch print and punch output, respectively. The UCLA RESET command sets all job priorities to the same value, and then the named job's priority gets bumped to the highest value 👑 An unknown command, HEREIAM, is used for synchronization purposes only 🤝 If the named job isn't ready for output, the local process will terminate with a timeout error (the current timer is set at one minute) ⏰💀

Multiple Job Retrieval

PRINT (*) and PUNCH (*) fetch all waiting output 🗂️ These commands should always be preceded by the TERMID command. Users who have their own RJS terminal assigned to them will use this mode 🖥️💖

UCSB Job Control Cards

EXEC Card

The catalogued procedure to be executed is named UCLARJS. Parameters specify which functions get performed. The general form of the execute card is:

        //anyname EXEC UCLARJS, PARM.RJS-'...functions...'

PARM Field

Here's the list of allowable parameters and what they do. Every parameter runs in sequence and they're separated by commas 🧁

READ - Open the reader channel and send 80 column records from the SYSIN data set.

PRINT(JOBNAME) - Set the indicated job's priority to highest value and retrieve the print output to the SYSPRINT data set. Records over 132 characters get folded to the next line.

PRINT (*) - Retrieve all print jobs.

PUNCH(JOBNAME) - Set the indicated job's priority to highest value and retrieve 80 column punch output to the SYSPUNCH data set.

PUNCH (*) - Retrieve all punch jobs.

STATUS - Ask UCLA about the status of all jobs assigned to this RJS terminal.

TERMID(NAME-PASSWORD) - Sign on as the named RJS terminal. PASSWORD is optional and should only be declared if the terminal has a password. The local process always signs on initially as NETUCSB. 🔐

DD Cards

1. Reader - The SYSIN data set should have the following format so it can send JCL and /* cards:

       // RJS.SYSIN DD DATA,DLM=$$,DCB=(RECFM=F,LRECL=80,BLKSIZE=80)
                       .
                       .
                       .
                    job(s)
                       .
                       .
                       .
       $$ (note, this special delimiter is required)

2. Printer - The default RJS.SYSPRINT data set is specified as SYSOUT=A 🖨️
3. Punch - The default RJS.SYSPUNCH data set is specified as SYSOUT=B 🃏
4. RJS log - The default RJS.MESSAGES data set is specified as SYSYOUT=A 📜

Problems and Errors

Most problems fall into one of these categories 🫣

1. UCLA-CCN or ARPANET down. 📡💔 This usually shows up when the local process tries to connect to UCLA. The error message is usually:

INITIAL CONNECTION OPEN ERROR.

2. RJS terminal in use by a non-UCSB-jobshop process. 🙅‍♀️ This can happen if a user submits a job but signs on to their UCLA RJS terminal online before the local batch process starts running. It's usually spotted by this message, with completion code 252:

FAILURE OR TIMEOUT IN OPERATOR, PRINT OR PUNCH CHANNEL

3. Job not ready to be retrieved. ⏳ The local process tries to set the priority of the indicated job but gets no successful response. This also shows up as the message above, with completion code 252.
4. UCLA is unable to retrieve output because of an age-old bug. 🐛😤 Unfortunately this can happen even with very small amounts of output. It's usually noted by the message "BEGINNING RETRIEVAL OF" followed by "(PROBABLE UCLA BUG).. PREVIOUSLY GOOD CONNECTION NOW HAS STATUS = 8". The output in this case is usually lost 💔

Cases 1 through 3 get fixed by waiting and then trying again 🔄 Other error messages may need a look at the NETWORK USER GUIDE or a chat with Computer Center or Computer Systems Lab personnel 🧑‍💻

Examples

1. Submit a job to UCLA-CCN through RJS terminal NETUCSB. 🚀

//SUBMIT JOB (0000,ROBERTS),'PSYCH BOX'
//STEP1 EXEC UCLARJS
//RJS.SYSIN DD DATA,DLM=$$,DCB=(RECFM=F,LRECL=80,BLKSIZE=80
//AAA000IC JOB......
            .
            .
            .
            .
            .

$$
//

2. Retrieve print job AAA000IC from terminal NETUCSB. 🖨️

//RETR JOB (0000,ROBERTS),'PSYCH BOX'
//STEP1 EXEC UCLARJS,PARM.RJS='PRINT(AAA000IC)'
//

3. Retrieve all print jobs from terminal NETRAND0. 🌈

//RETR JOB (0000, ROBERTS),'PSYCH BOX'
//STEP1 EXEC UCLARJS,'TERMID(NETRAND0),PRINT(*),STATUS'
//

---

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Alex McKenzie with ] [ support from GTE, formerly BBN Corp. 9/99 ] 💜