Control Data 6000 serie SCOPE 3.4 / NOS/BE console commando’s
* Vooralsnog wordt geen vertaling in het Nederlands van deze pagina voorzien
The system console / 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 serie 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.
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”. In fact, the HB combination was the one used most frequently. One-letter commands meant to show the named display on the left tube, retaining the right display.
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 70’s! When a command was determined to be completed, it was displayed in an 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 – condensators) character generator. This caused the zeroes sometimes to appear as “shrinked 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 related to batch job intervention, change 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”.
The following displays were available to console users. Most displays were used infrequently, even by system programmers.
|A||System dayfile, 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 dayfile and the Control Point (or C.P.)-dayfile of an executing control point.
|B||Control point statusdisplay. 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 was 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 dayfile 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 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
|D||Central memory display identical to C, but with its own separate base address.|
|E||Equipment status table (EST) display containing one line for each device on the system. Each included the following information:
|F||File Name Table display. Each file in the FNT was displayed, with a designation of L for non-permanent local file, C for common file, and P for permanent file. Queue files showed size in number of RBRs and 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, terminal id of the ‘owner’ (a TNO extension showed the number of RBR’s already printed/plotted, together with the size in RBR’s).|
|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 forms 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 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. A number of L-display games were available in “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:
where xx was the two-character pool ordinal of a job to drop. MDROP would kill a job and place in its dayfile 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 P-display also showed a prioritized list of jobs and their VSN-requests begin eligible as 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 aging 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 initials; they were recorded in the system dayfile. This provided some accountability. comment was an English description of why you were using dangerous commands.|
|LOCK.||Undid a LOCK command. 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.|