Using TSO at CCN
A guide to accessing IBM TSO at UCLA CCN over the ARPANET.
Braden, R., "Using TSO at CCN", RFC 379, DOI 10.17487/RFC0379, August 1972, <https://www.rfc-editor.org/info/rfc379>.
@misc{rfc379,
series = {Request for Comments},
number = 379,
howpublished = {RFC 379},
publisher = {RFC Editor},
doi = {10.17487/RFC0379},
url = {https://www.rfc-editor.org/info/rfc379},
author = {R. Braden},
title = {{Using TSO at CCN}},
pagetotal = 5,
year = 1972,
month = aug,
} RFC text
NETWORK WORKING GROUP R.T. BRADEN
REQUEST FOR COMMENTS #379 UCLA/CCN
NIC 11121 AUGUST 11, 1972
CATEGORIES :
OBSOLETES:
UPDATES:
USING TSO AT CCN
IBM's Time Sharing Option ("TSO") is now available at CCN for use via
the Network with Telnet Protocol. TSO is not yet considered "production"
by CCN, since there are a number of restrictions and glitches to be removed
or documented. However, TSO is now quite stable and is up on a regularly
scheduled basis; the system will allow an experienced programmer to work
productively at CCN. To use TSO, you will need a valid CCN charge (billing)
number, and a user-id. To obtain a charge number (if you do not already
have one), or to obtain a TSO user-id, contact Barbara Noble at (213)
825-7438 or (213) 825-7452. At present we are not charging for TSO use
(although any batch jobs submitted from TSO will be charged to your account).
Barbara can assign on overhead charge number for experimental use of TSO if
you do not have a paid account.
Modes of TSO Use
----------------
(1) Conversational Remote Job Entry
-------------------------------
Using TSO you can prepare an OS job stream using the TSO EDIT command,
SUBMIT the job to batch execution, monitor its STATUS, and ship the
OUTPUT back to EDIT for examination. This allows those of you with
TIP'S to process jobs at CCN without using NETRJS via a friendly
TENEX machine. Any batch job can be submitted this way.
(2) Foreground Execution
--------------------
Many OS/360 programs can be run, with varying degrees of inconvenience,
directly from the terminal. There are TSO commands providing the
facilities of EXEC and DD cards; the output stream can be directed to
the user's terminal. There are some important limitations to fore-
ground operation, however:
(1) The foreground region size is limited; at present, it is
128K, though this will be expanded.
(2) All datasets referenced must be on resident disk packs;
no disks or tapes can be mounted.
(3) Since you are time-sliced and swapped, it can be very
slow.
There are two important cases of foreground execution:
(A) The TEST command provides DDT-like debugging capability
for foreground programs.
(B) The user's own program can interact with his terminal.
NOTE: It is not yet possible for a program, either in batch or foreground,
to open direct Network connections.
Hours of Operation
------------------
Monday through Friday, 6 A.M. - Noon PDT (or 9 A.M. - 3 P.M. EDT).
These hours will be extended before September 1, 1972.
Telnet Protocol
---------------
The document "USING TSO VIA ARPA NETWORK VIRTUAL TERMINAL", RFC #377
describes the use of a Telnet NVT to access TSO. There are some signi-
ficant differences from using a real 2741 locally. RFC #377 describes
the current server Telnet, complete with an annoying bug. A later
version will include the following capabilities not presently available:
(a) "FULL DUPLEX", i.e., CCN echoing.
(b) Lower case input.
(c) The special character translation included in NETRJS
users with Model 33 Teletypes. (see RFC #338).
(d) Optional specification of single CR or single LF as end-of-line
indication
(e) Hopefully, the input attention bug described in RFC #377 will
be fixed.
Disk Space
----------
TSO will automatically place datasets created in the foreground (e.g., by
EDIT or ALLOC) on the proper resident disk pack. All TSO datasets are
cataloged, and can be referenced by name alone (no volume or unit specifi-
cation is necessary). For most purposes, you can pretend we have one big
disk. --- ---
----
Dataset Names
-------------
The standard IBM version of TSO uses the TSO user-id as the highest
index of each dataset name. At CCN, the _two_ highest levels are the
charge number and the user-id of the person who created the dataset.
TSO has been modified accordingly.
Dataset Access Control
----------------------
In general, under TSO a user can access for reading, writing, or
execution any dataset named with the charge number with which he is
logged on. In addition, he can rename or scratch any dataset with the
logon charge number. There is no provision for public or read-only
datasets a present.
Logging On
----------
Most Network users will need only the simple form of LOGON:
logon <user-id>
EXAMPLE: NOTES:
------- -----
user: logon uid (Use your user-id)
TSO: LOGON UID (TSO repeats line for reasons of its own)
TSO: ENTER PASSWORD (TSO asks for password)
user: xyz
TSO: UID LOGON IN PROGRESS AT 11:37:43 ON AUGUST 9, 1984
TSO: LOGON PROCEEDING (It may take a while. This message will
come every 30 seconds.)
TSO: WELCOME TO TSO. GOOD LUCK
TSO: READY
User-id's are created in TSO with a blank password. To add or change your
password, use the CHANGE command. If you have TSO access under more than
one charge number, LOGON will prompt you for the charge number to be used
for the session.
Where to Get Help
-----------------
1. To obtain a list of TSO commands enter: "help commands"
2. To get detailed information on syntax and function of a particular
command, enter: "help <command name> <qualifiers>"
Type "help help" for details.
3. The SEND command may be useful for on-line help from PCN (Pete Nielsen)
or WDD (Bill Drain), when they are signed on. You can find out if PCN
or WDD is on by sending them a trial message.
EXAMPLE:
-------
User: send 'hello' user(wdd)
TSO: USER WDD NOT LOGGED ON
TSO: READY
user: send 'hello' user(pcn)
TSO: READY
user: send 'edit is acting funny' user(pcn)
TSO: READY
Here "PCN" was logged on and got your message. You can, therefore,
converse with him through SEND. The text in one SEND is limited to
115 characters.
4. You can also leave a message for wdd to receive when he logs on by
typing: send '<message>' user(wdd) logon.
5. To send a message to the CCN operator, enter simply: send '<message>'
6. You can call the CCN Telephone Consultant at (213) 825-7452, Monday
through Friday during the hours 10-12 A.M. PDT and 1-4 P.M. (except
3-4 P.M. on Thursday). If the consultant does not know the answer,
he/she will investigate and call you back.
7. You can call the general contact for Network user problems, Barbara
Noble, at (213) 825-7438. Barbara is also one of the Telephone
consultants.
8. If all else fails, call Bill Drain, the CCN Systems Programmer in
charge of TSO installation. His telephone is (213) 825-7474 (if no
answer, call my secretary at (213) 825-7518 and leave a message for
Bill).
9. You can also send a message to someone at CCN by submitting the
following pseudo-job through RJS at TSO:
//<charge number> JOB 'BIN=9906',MSGLASS=C
//* <message>
//*
//*
//*
//*
etc.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by BBN Corp. under the ]
[ direction of Alex McKenzie. 1/97 ]
AI ELI5
On this page
§1TSO at CCN
UCLA's Computing and Communications Network (CCN) made IBM's Time Sharing Option (TSO) available to network users via Telnet. The system was stable and ran on a regular schedule, though not yet considered production due to restrictions and bugs being fixed. Users needed a valid CCN charge number (billing account) and a TSO user ID. These could be obtained from Barbara Noble at (213) 825-7438 or (213) 825-7452. TSO usage itself was not charged; only batch jobs submitted from TSO were billed to the user's account.
UCLA opened its mainframe to network users. To use it, you need an account number and a user name, which UCLA hands out. It is still being polished, so it might act oddly.
§2TSO Modes
TSO offered two main modes. Conversational Remote Job Entry allowed users to prepare job streams with the EDIT command, SUBMIT them to batch, monitor their STATUS, and retrieve OUTPUT. This was useful for TIP users who wanted to submit any batch job without going through NETRJS on a TENEX machine. Foreground Execution let users run OS/360 programs directly from the terminal, though with limitations: the region was limited to 128K (to be expanded), all referenced datasets must be on resident disk packs, and execution was slow due to time-slicing and swapping. Two important foreground capabilities were the TEST command for DDT-like debugging and the ability for a program to interact with the user's terminal.
TSO works two ways: you can send a big job to the computer and come back for the answer later, or write a small program and run it right there while you watch.
§3Datasets and Telnet Protocol
TSO automatically placed datasets created in the foreground on the right resident disk pack, and all TSO datasets were cataloged by name. At UCLA, dataset names used the charge number and user ID as the highest-order indices, allowing the system to manage a large logical disk. Dataset access was controlled by the charge number: users could read, write or execute any dataset under their charge number, and could rename or scratch such datasets. The RFC noted that programs could not yet open direct network connections. For Telnet access, RFC 377 described how to use the Telnet Network Virtual Terminal to reach TSO, though the current implementation had a bug and lacked full duplex, lowercase input, and proper special character translation.
Programs store their work on the big disk, organized by who asked for it. The computer is still fixing Telnet so that typing on your terminal works better.