Computer history: Control Data 6000 series SCOPE 3.4 / NOS/BE Console Commands


Control Data 6000 series SCOPE 3.4 / NOS/BE Console Commands

Cyber operator console
Cyber 6000 operator console

The system console or operator console was the computer operator’s main interface with the operating system. The console was controlled by the PP program DSD (Dynamic System Display), which displayed operator-selectable information straight from the system memory on the two physical displays (Cathode Ray Tubes or CRTs) on the 6000 series’ consoles or the larger single CRT of the Cyber 170 series type of consoles. The latter had a switch to select the left display, both displays or the right display.
Commands were entered via the attached keyboard. A deadstart button, hidden under the screen and protected against unintended activation, completed the console.

Console display A-B
Console display A (system) – B

There were about 24 different displays that could be shown, each denoted by a letter. Any of the screens could be shown on either of the two cathode ray tubes (CRTs) that constituted the 6000 series console display (10*10 inch display area) or on the larger single tube display.
DSD accepted commands from the keyboard. Commands consisting of two letters were commands to control which displays were active on the two CRTs. For instance, HB meant “Show the H display on the left tube and the B display on the right tube”. The HB combination was the one used most frequently. One-letter commands showed the named display on the left tube, retaining the right display.

Console display A-B
Console display A (system) – B

Characters typed in at the keyboard were echoed at the bottom of the left display. DSD implemented command completion; that is, it would automatically fill in the remainder of a command once that command could be uniquely determined from the characters already typed at the keyboard, quite advanced for the early 70s! When a command was determined to be completed, it was displayed in a rippling manner that is difficult to describe. When a complete command had been entered, DSD would update portions of the echoed command line more frequently than others. The characters being displayed more frequently would be displayed more brightly. Different characters were brightened successively at different times, causing the rippling effect. Pressing the carriage return key would cause the command to be executed.
Note that all characters in the early 6000 series systems were generated using a discrete (transistors – resistors – capacitors) character generator. This caused the zeroes sometimes to appear as “shrunken pears”.

DSD allowed you to type only characters that could result in a syntactically correct command. Any other character would cause “ILLEGAL ENTRY” to be flashed on the screen. ILLEGAL ENTRY occurred fairly often when inexperienced system programmers tried to type characters that had already been filled ahead by DSD’s command completion mechanism.

In practice, most use of the console was related to batch job intervention, changing queue priorities and mounting magnetic tapes. The system didn’t require a lot of active intervention on the part of the operators. System programmers probably made more extensive use of the console when they controlled the system for “system maintenance time”.

Console Displays

The following displays were available to console users. Most displays were used infrequently, even by system programmers.

A System day file, including accounting messages and hardware diagnostic messages. Usually, lines scrolled by very quickly. This display was useful to systems programmers but rarely to operators.
The A-display could be toggled between the (global) system day file and the Control Point (or C.P.)-day file of an executing control point.
B Control point status display. This was nearly always up on the right screen. It listed control points with their status: Clear, Next, or program running. For occupied control points, a lot of information was crammed into a few lines. Included were the user id, current job cost, memory use (current and max field length), CPU status (RCL=periodic recall, AUTO=automatic recall, WAIT=wants the CPU, CPU A=currently has the CPU), latest day file message, number of PPs currently at that control point, and a lot of others.

CPU programs could put up special flashing B-display messages which caused the job to be paused until the operator took action. This capability was normally used only by certain programs designed to run as control point jobs. (Control point jobs were those that were explicitly run at a given control point and did not leave the control point until they terminated).

C Central memory display, displaying 32 words from central memory, using absolute addressing. Each word was displayed as five groups of four octal digits, plus a display code. C had a base address associated with it that was remembered even while the display was not active.

The C display was organized into four groups of 8 words. The command
(0 <= x <= 3) set the base of the xth group to the octal address addr.
set the base of the entire display.
The + and – keys, when entered on an otherwise blank line, allowed a system programmer to change the base of the display to page through the full memory.
At TNO we only displayed non-sensitive areas to the operators. This security feature was deactivated once systems programming unlocked the console.

D Central memory display: identical to the C display, but with its separate base address.
E Equipment status table (EST) display containing one line for each device on the system. Each included the following information:

  • Device number
  • Type, a two-character identifier: FD for front-end computer, AY or single density 844 disk drives, etc.
  • ON/OFF/DOWN status
  • Channels attached to a device
  • Destination/route (for printers, etc.)
  • Visual pack id (for disks)
F File Name Table display. Each file in the FNT was displayed, with a designation of L for a non-permanent local file, C for a common file, and P for a permanent file. Queue files showed their size in the number of RBRs as well as their priority.
G Central memory display, very similar to the C display but with words shown as four groups of 5 digits, plus display code. This was more conducive for viewing the words as instructions.
H Input and output queue file display. ALL FNTs for I/O queue files showed the current status: size, disposition code, forms code, and terminal id of the ‘owner’ (a TNO extension showed the number of RBRs already printed/plotted, together with the size in RBRs).
I Request cards display. Requests for mounting tapes or disks were extracted from the control cards to be processed next.
J JANUS equipment status table display showing all print, plot, punch and card devices managed by Janus (PPs 1IR/1IQ). For instance, it contained the sequence number of the job currently printing on the line printer, the number of copies printed and to go, the form’s code and so on.
K Control statements at a given control point. This showed the current PRU (disk sector) of control statements for a job as long as it was at a control point. Unless the job was already executing the last control statement that happened to be in that PRU, this allowed you to look ahead to a few control statements to see what the job was going to do next. Sometimes the K display was used by operators to allow them to prefetch reels of tape for a tape-hungry job, as the Visual Reel Numbers were usually present in control statements. However, generally, the K display wasn’t used much.
K=0 or K-display for the system showed some system tables.
L User-programmable display. A CPU program running as a control point job could request to write to the L display. Several L-display games were available in the “public domain”, including a space program that could report a “broken coffee pot”: Chess, Life, Worm en Blob.
L stood for Left; the L display, when used, was only shown on the left screen because it could not fit in DSD’s right display maximum memory overlay size.
M Peripheral Processor communication areas display. M had one line for each of the physical PPs in the system displaying the name of the running PP program (if any) and the PP’s input and output “registers”. These were not physical registers, but small blocks of memory used by software to communicate with the PPs. The M display was fascinating to watch as during peak times over 300 PP programs per second were loaded and executed. Generally, the M-display was used only during testing (e.g. system step mode) or problem resolution to find PPs that were ‘hanging’.
N CPtask display. This was the central processor task analogue to the M display, mainly used for breakpointing the system.
O Listing of canned Operator Messages available for the DROP and some other commands. This command had the syntax:

(xx)DROP,msg#,operator comment.

where xx was the two-character pool ordinal of a job to drop. MDROP would kill a job and place in its day file a message plus an operator comment. The O display listed the English messages that corresponded to the message numbers entered by the operator.

The O display was rarely used because the DROP command was rarely used, and the operators probably had the commonly used message codes memorized anyway. The O display was one of the few completely static displays. The letter O would probably have been the first one to be recycled if a need had arisen to implement new displays.

P Tape status and VSN display. This contained information for each tape drive, including

  • the Volume Serial Number (VSN) of the tape mounted,
  • whether a write-enable ring was present,
  • the pool ordinal of the job that owned the drive,
  • other tape-related information.

The P-display also showed a prioritized list of jobs and their VSN requests begin eligible as the next programs to be run. This helped the operator to pre-fetch tapes from the vaults. The P display was used rather often by operators.

Q Status of INTERCOM lines display: ON/OFF/DOWN, line speed, synchronous or asynchronous.
R Job Descriptor Table (JDT) display.
Display of current job status, both active and swapped out. Time limits and CP, PP and I/O time used; memory utilisation and scheduling parameters as initial queue priority and ageing information.
S Job Control Area Display that showed properties of actual and maximum system job scheduling parameters. Examples: max. ECS, max. Field Length of jobs allowed to be run. Staging tapes ON/OFF.
T Transfer status display. Only on linked multi-mainframes.
U Logical ID display. Only on linked mainframes.
V Rotating Mass Storage (RMS) display. Disk set and disk status display showing the occupation and *Q, *PF, *SYS and *SCR properties of each of the disk sets as well as per disk. Also, allocation areas and utilization (current- versus max) were shown.
W Waiting pack display. Not used by us anymore after the 844-21 replaceable disks became obsolete.
X ECS display. Memory display showing the content of ECS, later UEM memory.
Y DSD command directory. The syntax (but alas, not the meaning) of each console command was listed here in alphabetical order. Typing a few characters at the console while the Y display was active caused the Y display to move to the part of its display that started with the characters typed.

DSD’s command fill-ahead made this display largely unnecessary. It would have been more useful if a description of each command had been included.

Z Index to displays. Z contained a one-line description of each lettered display.

Here is a very abbreviated list of DSD commands.

ACKNOWLEDGE. Used to clear a condition about which DSD is complaining. The bottom of the B display will contain the error text. This was supposed to be used with caution, as the warning condition being cleared might well be a serious system problem.
AUTO. Brought up the system in automatic run allowing 1AJ to advance jobs and new jobs to be scheduled.
UNLOCK BY xxx TO comment. “Unlocked” DSD to allow certain especially dangerous commands. xxx was your initial; they were recorded in the system day file. This provided some operator accountability. comment was a description of why you were using dangerous commands.
LOCK. Undid a UNLOCK command. The normal mode of operation.
addr,n,value. Set the n-th byte of central memory in at word absolute octal address addr to the octal value value. A byte was four octal digits, and there were five bytes per word, so n could be from zero to 4. Sample usage: 5727,3,7700. This is an example of a command that required UNLOCK.


170 series operator console (Photo courtesy Fredy Ferrari, Fides, CH)
170 series operator console (Photo courtesy Fredy Ferrari, Fides, CH)
Cyber 170 series operator console
Cyber 170 series operator console with two displays