User Tools

Site Tools

Console Guide

Author Mark Riordan
Original Content

This document was written by me in 1980 and updated in 1984. This version was mechanically translated from the original 1980 version to HTML, and then hand-edited to make it like the 1984 version. (I had a faded and unscanable printout, but not a machine-readable copy, of the 1984 version.) In case you are interested, the mechanical translation was achieved by:

  • Reading the original 9-track PFDUMP tape to a PC file (done by Al Kossow)
  • Extracting the file MRRCONSOLEGUIDEEWFILE via the program CDCTap
  • Listing the EWFILE to an ASCII file via the program MSUEDList
  • Converting the resulting RNF-formatted file (RNF is similar to the Unix nroff) to HTML via the crude AWK script RNFToHTML.awk.

This was probably more trouble than it was worth, because the guide is rather specific to SCOPE/Hustler, and not very complete. However, it is probably mostly applicable to SCOPE 3.x and NOS/BE.

What follows is the original text of the 1984 version. There are a few recently-added comments in this style, surrounded by brackets.

Mark Riordan 3 January 2003 mrr (at)

Console Users Guide

(last updated on 28 June 1984)

This is an informal guide to using the operator's console on a Control Data 6000 or Cyber machine running under SCOPE/HUSTLER. It was initiated on May 21, 1980 by Mark Riordan in an attempt to record console techniques for information-starved consultants. Some day, perhaps, this set of notes will evolve into a real console operator's guide.

Note: I had added helpful hints to this guide slowly over the years. However, the descriptions of specific displays and console commands were added in a hurry on June 28, 1984 and may not be completely accurate. They are certainly skimpy in spots, due to being written largely from memory and four-year-old notes, with no console nearby for reference. However, the descriptions should be accurate enough to allow you to accomplish what you set out to do. Someday, I may spiff this up to be a real SMEMO or something.

Knowledge of the console consists of information of at least the following types:

  • Knowledge of the various lettered displays, and what information can be found on which.
  • Knowledge of the console commands and what each does.
  • Background information on what memory addresses to alter to do what, how to trace down links of addresses, and other advanced tricks of the trade.


Displays are tables of information, designated by a single letter, that can be “brought up” on either of the two physical console displays. “Bringing up” a display consists of typing a one- or two-letter command on the console keyboard. (All commands are terminated by a carriage return, of course.)

Typing: x will bring up display x on the left tube;

typing: xy will bring up display x on the left tube, and display y on the right tube.

Normally, the console has the X display up on the left tube, and the B display on the right tube. The Z display contains a brief description of each of the displays.

It is possible to bring up displays as “displayletter=n”, where “n” is a control point number. In most cases, the display named “displayletter” will be brought up with only information that's relevant to control point n displayed. For example, if you want to see control point 17's dayfile, type A=17. To restore the entire system dayfile display, type A=0.

The individual displays in alphabetical order:

ASystem dayfile, including accounting messages and hardware diagnostic messages. Usually scrolls by very quickly. Moderately interesting to Systems; rarely used by Operations.
BControl point display. Nearly always up on the right screen. Lists control points 1-17b, with their status (Clear, Next, program running). For occupied control points, a lot of information is crammed into a few lines. Included is user id, current job cost, 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 host of others. CPU programs (typically control point jobs) can put up special flashing B-display messages which cause the job to be paused until the operator took action. This capability is normally used only by certain programs designed to run as control point jobs. (Control point jobs are those that were explicitly run at a given control point and do not leave the control point until they terminate. The system backup program SELDUMP is an example.) The command B=n where n<>0 means to display only control point jobs and Hustler jobs that have been at a control point for over 5 seconds. [Or is that n seconds?]
CCentral memory display with each word displayed as 5 groups of 4 octal digits, plus display code. C has a base address associated with it that is remembered even while the display is not active. The C display is organized into 4 groups of 10b 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, allow you to change the base of the display and hence page through memory. The C display and other CM displays are used only by systems programmers (typically), and that only during debugging.
DCentral memory display identical to C, but has its own separate base address & hence supplements the C display. Note that these displays were designed over a decade before the current microcomputer “windowing” craze.
EEquipment status display. It contains one line for each device on the system. Each includes the following information for a device: Device number Type (two-character identifier: FD for front end computer, AY for single density 844 disk drives, etc.) ON/OFF status Channels attached to a device Destination/route (for printers, etc.) Visual pack id (for disks)
FFile Name Table display. FNT entries are displayed. The designation L is used for non-permanent local files, C for common files, and P for permanent files. Note the TTYxxx files at MANAGER's control point: they are the TTYTTY files for users xxx. There is little reason to use F during production.
GCentral memory display, very similar to the C display but words are shown as 4 groups of 5 digits, plus display code. This is more conducive for viewing the words as instructions.
HObsolete display. Before permanent file I/O queues, contained central memory-resident FNTs for input and output queue files.
IFWA and LWA+1 of many system tables. As is the case with many of these tables, the information could be gotten some other way, but in certain (fairly unusual) circumstances, it's nice to have the information readily available in an easily-digested format.
JStatus of ARGUS devices. For instance, it contains the sequence number of the job currently printing on a model 512 line printer. Contains HELP ME if the printer is out of paper or has other trouble. When there is something useful on this display, ARGUS puts up a B display message SEE -J- DISPLAY. The J display is named “Mickus Mouse Devices” for obscure historical reasons.
KControl statements at a given control point. This shows the current PRU (disk sector) of control statements for a job as long as it is at a control point. Unless the job is already executing the last control statement that happens to be in that PRU, this allows you to look ahead a few control statements to see what the job is going to do next. Sometimes the K display is used by operators to allow them to prefetch reels of tape for a tape-hungry job, as the Visual Reel Numbers are usually present in control statements. However, generally the K display isn't used a whole lot.
LUser programmable display. A CPU program running as a control point job can request to write to the L display. (“L” stands for Left; there is an “R” display that is very rarely used that might be used on the Right screen if you wanted to take over both screens from a CPU program.) The coded-file display utility PAGE uses the L display, for example. The Operations staff maintains a user library named L*CG (for Chuck Gillengerten) that has some programs that display status information on the L display; also, one of these programs displays a picture of Mickey Mouse.
MPeripheral Processor display. M has one line for each of the physical PPs in the system, with a display of the program running (if any) and the PP's input and output “registers”. Fascinating to watch on a loaded system, but generally used only during testing or problem resolution.
NCPtask display. This is the central processor task analogue to the M display. [Michigan State rewrote some of the CDC PP routines to run in the CPU for better performance. These were then dubbed CP tasks.]
OListing of canned Operator Responses available for the MDROP command. This command has the syntax (po)MDROP,msg#,operator comment. where po is the two-character pool ordinal of a job to drop. MDROP kill a job and place in its dayfile a message plus an operator comment. This is a dumb display–it always has the same thing: the English messages that correspond to the message numbers entered by the operator. If we start getting tight on displays, the O display might be one of the first to go. It is rarely used because the MDROP command is rarely used, and the operators probably have the commonly-used message codes memorized anyway.
PTape status display. This contains information for each tape drive, including the Visual Reel Number (VRN) of the tape mounted, whether a write-enable ring is present, the pool ordinal of the job that owns the drive, other information The P display is used rather frequently by operators.
QCPtask debugger display. Used to “expand” a CPtask to show its registers during debugging. Obviously, used only by systems programmers during testing.
RUser programmable display, intended to be shown on the Right screen. See the L display.
SNot implemented.
TPP Interpreter display. This has a list of each of the physical PPs in the system, like the M display. When a PP program is being interpreted, its P and A registers were displayed here. Needless to say, the operators don't use this much.
UPP Interpreter display. Contains a list of PP's Subject To Interpretation–usually none, of course.
VNext Sequence Number display. For each E/I 200 site, and for interactive and DISPOSEd jobs, there is a line containing the sequence number to be assigned to the next job coming from that source. Of very little interest to anyone..
WNot implemented.
XSystem status display. This is a catch-all display that normally sits on the left screen during production. The top part of the screen is dedicated to displaying available resources and the load on the system. This includes: free disk space the number of free FNT entries RBT FL the number of jobs on the input and output queues Below that were listed all the pool jobs, one per line. The + and - keys scroll this part of the display. Batch jobs are listed first, because they might ask for tapes and tape requests come up on this display. Also user jobs paused by user request are indicated here. The command X=n where n<>0 cause only jobs waiting for operator action to be displayed. Since tape mounting is the most common task of an operator, the X display is the one display to watch as an operator.
YDSD command directory. The syntax (but alas, not the meaning) of each console command is listed here in alphabetical order. Typing a few characters at the console while the Y display is active causes the Y display to move to the part of its display that starts with the characters typed. Sounds useful, but it seems to turn out that if you don't know what command you want, Y won't usually help you. If you do vaguely remember the command, DSD's command fill-ahead will help you get the syntax very quickly without having to refer to Y.
ZIndex to displays. Z contains a one-line description of each lettered display under DSD.


There are several types of console commands; commands that perform similar tasks tend to have similar syntaxes. For the purposes of the brief document, we'll classify commands (and syntaxes) as follows:

  • Commands to bring up displays. See DISPLAYS section.
  • Commands to perform functions at a particular control point. These commands usually act on operator-initiated jobs, and are frequently used for system-related tasks, or when a programmer is “fooling around”.
  • Commands that act on a job specified by pool id. These commands are frequently used on user jobs.
  • Other commands. (Quite a hodge-podge, but beyond the current scope of this document.)

Entering Commands

Type the characters of the command at the console keyboard. The characters you type will appear on the last line of the left screen. In most cases, the display PP will “fill ahead” the text of the rest of the command, when it has uniquely determined the command you want from the initial substring you have typed. In these cases, an attempt by you to type the entire text of the command will result in the display flashing “ILLEGAL ENTRY” on the screen–the PP driver will allow a character to be typed only if it knows that the string you have typed so far may result in a syntactically correct command, and in the case of filled-ahead commands, you do not have the option of entering characters that have already been filled ahead.

Commands must be terminated with a carriage return. A “left blank” (the blank key to the left of the equals sign) deletes the current command line, and a backspace deletes the last character entered.

Command Syntaxes

In describing command syntaxes, the following abbreviations will be used:

dvdesignates a two-digit octal number specifying a device. See the E disp for system devices.
ndesignates a control point.
podesignates a two-letter pool ordinal.
chdesignates a two-digit octal channel number.

A command format dictionary resides on the Y display. used to clear a condition about which DSD is complaining. The bottom of the B display will contain the error text. This is supposed to be used with caution, as the warning condition being cleared might well be a serious system problem.
ACNch.Activate channel.
DCNch.Deactivate channel.
FANch.Function the channel from the A register.
FCNch,mmmm.Function the channel with the value mmmm.
MCHch.Master clear on a channel. Useful only on channels connected to the 6684.
ATTENDED.Set the attended flag, which states that the system is running with operators on duty. This affects dayfile operation. The attended flag is queried by LOGIN, MENU, and a few other CPU programs. Don't set ATTENDED unless you know what you're doing.
UNATTENDED.Clears the attended flag.
AUTO.Brings up MANAGER at control point 1 (if control point 1 is clear) and if this is the main system in a multiple machine environment, brings up ARGUS at control point 2. [After the acquisition of the Cyber 750, the 750 and the older 6500 ran for some years in a two-machine cluster.] AUTO also sets control points 3-17b to NEXT, meaning that Hustler can schedule jobs to run at those control points.
BLITZ.Clears all control points, the opposite of AUTO. Useful for harmlessly freezing the system if you think something nasty is happening, such as disk space going into a tailspin. (AUTO will bring things back.)
CALL,ppname,nn,?.Allows you to call a PP.
CTB.Used by the C display–can't remember what for.
CB{0-4}.Also used by the C display.
DATE mm/dd/yy.Sets the system date. The 750 does this itself from the chronolog; the 6500 forces you to type this command in.
DCHch,ppnumber.Drops channel reservation for a PP.
RCHch,ppnumber.Reserves a real or pseudo-channel for a PP.
DIRECT,seqnum, {I|O|P},sourcechar.Changes the routing of an input, output, or punch job. For instance, suppose there is a print job with sequence number TB12345. This job is set to print at the usual “B” central site printer. DIRECT,TB12345,O,A. would route the job to the auxilliary “A” printer instead.
ENJS,sequence number.Sets an entry in the job sequence number table. (This table is displayed on the V display.)
EVICT,seqnum,{I|O|P}.Got rid of the named input, output (i.e., print) or punch job.
UNLOCK BY xxx TO comment.[“Unlocks” DSD to allow certain especially dangerous commands. xxx is your initials; they are recorded in the system dayfile. This provides some accountability. comment is an English description of why you are using dangerous commands.]
LOCK.[Undoes an UNLOCK command.]
addr,n,value.[Sets the n-th byte of central memory in at word absolute octal address addr to the octal value value. A byte is 4 octal digits, and there are 5 bytes per word, so n can be from 0 to 4. Sample usage: 5727,3,7700. This is an example of a command that requires UNLOCK.]



Put a ring in the tape, and mount it on a free tape drive with device number dv.

VRNdv,six character visual reel number.

Incidentally, you can sometimes save bad tapes by cutting off the first few hundred feet of the tape (the most heavily used part), installing a new load point, and reblanking the tape. Note that the load point goes on the outside surface of the tape (away from the reel), on the side of the tape away from the write ring.


It is rumored that MSU has the only ECS I unit still in production. And even for ECS I units, our has been unreliable. Therefore, you are going to encounter problems with ECS.

Fortunately, CDC designed Extended Core Storage with parity, even when they were designing the Central Memory without parity. Thus, if an ECS module goes bad, there a very good chance the reading from that module will signal a parity error.

Due to the fact that our ECS unit has been historically unreliable, Systems wrote much of MSU's ECS access code to provide error-correcting checksums for blocks of ECS. Hence, when an ECS parity error does occur, there's a reasonable chance that it can be corrected in software. When a correctable (“non-fatal”) ECS parity error occurs, the “ECS count”–which is displayed at the bottom of the B display and is normally 0–is incremented. When the count goes non-zero, the system automatically begins doing more checksumming, which increases the likelihood of being able to recover from an ECS parity error, but decreases system throughput. Hence, if the ECS count goes non-zero but stays at a fixed small number for a long time (an hour), then it is customary to assume that the problem was only a temporary glitch, and the count should be zeroed to restore more efficient system throughput.

Dealing with Non-Fatal ECS parity errors

The ECS count can be cleared by:

3.X FIXCARD. At this point, the control point B display says something like “Type GO when CD's are ready.” The CE's are often not around, so you can just type GO.
3.GOThe system will be placed in Step mode for the benefits of the CE's. A flashing B display message at the bottom of the screen will say something like “Type ACKNOWLEDGE when ready.” Unless engineers are actually working on ECS, you should type ACKNOWLEDGE as soon as possible.

Dealing with Fatal ECS parity errors

When an uncorrectable ECS parity error occurs, it's probably time to redeadstart under “half ECS”. There are switches on the physical ECS controller to indicate which part of ECS you want to use: all, first half (banks 0 & 1], or second half (banks 2 & 3). You can find out which half to use by trial and error, but it's better to figure them out the right way.

When the system is frozen on a fatal ECS parity error, the CPU P register will be looking in a very tight loop. The P register will be shown on the second line of the B display. It may, for instance, be seen as the digits 02525x, where x is spinning rapidly.

The few words in CM right after where the P register is pointing will contain the ECS addresses that are giving ECS parity errors. Bring up the C display to show the CM words being pointed at by P. (For instance, you might type C4,25250.) The ECS addresses will be one per CM word, right-justified, zero-filled. Bits 4 and 3 of the addresses contain the bank number that is failing.

For instance, you might see the ECS addresses 370774, 370775 & 370776 listed in consecutive CM words at, say, CM addresses 25252, 25253 & 25254. The addresses 37007x all specify bank 3 as the culprit, so you know that you have to go to the first half of ECS (banks 0 and 1) to avoid using the bad banks.

[The following topic was not in the final, 1984 version of the console guide. It may have been obsoleted by the implementation of PF I/O queues.


Frequently, it is desirable to transfer I/O (and other) queues between mainframes. Although there is no special console command to do this, this topic is of great enough interest to be included in this document. Conceptually, the process is rather simple: DMPQ copies system queues to a local or permanent file and empties those queues, and RESQ adds jobs to various queues from a DMPQ'ed file.

An attenuated description of the process:

n.X DMPQ,machdes,{PF=pfstring | LF=localfile}
n.CFO queuestring
n.CFO sourcestring


machdesis the machine designator of the machine you're dumping the queues to–M65 or M750.
pfstringis a string of characters used to create a permanent file name; during production, use a string of format RDx (x an alphabetic character). Operators keep track of DMPQ file names in the machine log. During systems' time, programmers traditionally use their initials.
queuestringspecifies which queues are to be dumped; legal characters in the string are I (input), O (output), P (punch), and R (Mistic retained files). Alternately, A alone means IOP, and E alone means IOPR.
sourcestring is a contiguous list of characters specifying the sources to be dumped. * indicates all sources.

Note that the operator must wait for a prompt on the B display before entering the n.CFO responses.

To retrieve queues that have been DMPQ'ed:

n.X RESQ,PF=pfstring
n.CFO queuestring
n.CFO sourcestring

A typical sequence of console commands to transfer jobs from the 6500 to the 750:

On the 6500, type:
3.CFO *

On the 750, type:
3.CFO a
3.CFO *



EVICT,sequence number,I


EVICT,sequence number,O


The trick is to run a control point job using DIS: you alter the PF Tape Permission bit in the control point area for the DIS job, request the tape as an S tape, skip past the trailer label, and do a COPYBF to another S tape. Some trickery is needed to give the resultant tape the proper (or nearly proper) header and trailer labels. The procedure is best done with a blank-labelled output tape. Note that the potential partial pf at the beginning of the output tape will be ignored by the PF utilities.

For nine-track tapes:

1762,4,4000                 set pf permission bit.  note that addr
KEEP52.                     depends on control point
3.X PFDUMP,PFN=anything,NT=output vrn.  creates correct header label.
X.SKIPF,OLD,1,17.                skip past header labels.
X.SKIPF,OLD,1,17.                skip past data--the pfs before the EOI
X.COPYCR,OLD,DISK.               skip past trailer label.
X.SKIPF,OLD,1.                   skip past probable parity errors.
                                 Repeat as necessary.
X.SKIPF,NEW,1,17.                skip past labels on output tape.
X.COPYBF,OLD,NEW.                do the actual copy.
X.SKIPF,OLD,2,17.                skip to trailer label set.
X.COPYBF,OLD,NEW.                copy trailer label (block count will
                                 be wrong, but that's OK)
X.RETURN,OLD,NEW.                all done.  should verify with PFLIST.


There are many approaches to this problem, depending on exactly what you want. If you want to find out what the password is, or if you don't want to purge or copy the file, use method 1. If all you want to do is access the file to copy it or purge and recatalog, use method 2. Obviously, there are many solutions to this problem–these are just two of the simplest.

Method 1:
PFDUMP the file in question to a VIM tape. (Actually, a UP tape will do, but it makes subsequent steps harder.) You can abort the PFDUMP after the first few tape blocks if you like. Then, FILEDMP the tape and look at the first few hundred words of the tape. The passwords are hidden in there somewhere–if they're not obvious, get a listing of SCPTEXT and figure out where the passwords must be, given the structure of the PFD and indexing off the permanent file name.

Method 2:
Attach the file with the universal control permission password (429777268), and once you've got it, alter the PF permission bits in the FNT. Then purge & recatalog the file, or just read it (or whatever).


5727,3,7700. (gives you all permissions.)


Occasionally, ARGUS will just sit on a card reader job, acting as if the job has not yet finished (that is, read all the way to a 6-7-8-9 multi-punch card). When operators detect this condition (sometimes by the presense of a line on the J display containing the card reader number and job sequence number, but no descriptive message), they will try to take corrective actions. Sometimes /EOFxx'ing the reader, or OFFxx'ing and ONxx'ing it will free up the job.

However, sometimes the cause of the problem is an unset complete bit in the FET for that job. In that case, you can find the FET by the somewhat complicated procedure below, and set the complete bit (bit 0 of word 0 of the FET). Use a procedure something like this:

C,0     Look at word 2 of ARGUS's field length.  Bits 17-0 will point
        to the first entry of a linked list of entries that apply to
        various devices.  Let's say this address is 000053.
C4,53.  The first two words of each entry are of interest.  Let's say
        000053=0456 2000 3301 3300 0076
        000054=7704 1206 4000 0404 0000
        Bits 23-12 of the second word (0404 in this case) contain
        equipment information.  The first 6 bits are the equipment
        type (04 for card reader) and the next 6 are equipment number.
        You are looking for 04xx, where xx is the number of the
        card reader that is hung.

        If the first entry doesn't apply to the card reader in question,
        move along the linked list.  The bottom 15 bits of the first
        word (00076 in this case) contain the address of the next entry.

        When you find the right entry, look in bits 29-15 of the first
        word (01330 in this case).  This is the address of the FET
        for this device.

        Look at this address and make sure it's a FET.  (The file name
        should be the sequence number of job that is hung, for instance
        IB87694).  If the complete bit is not set, set it:
1330,11024342414437000001.  (for instance)
        If this doesn't clear things up, you're on your own.


Ha! Disk errors are the bane of our system. We have a bunch of really old disk drives that we can't afford to junk, so we have to put up with their arthritic pains. Jerry McAllister (as of this writing in mid-1984) and the CDC customer engineers do most of the maintenance.

Sometimes, though, a disk controller can go crazy and write irrecoverable parity error sectors when there's really nothing wrong with the drive or pack. In this case, it is useful to run TMS (PP that resides on L*SYS with a HELP file that should be read) on the affected drives. TMS will methodically read all PRUs on a drive, and read errors wll be logged in the dayfile. You can then use DPE to find out what PRUs are bad, and PFLIST can be used to tell you what user files reside in those spots. That way, you can notify exactly those users who are affected and avoid having to say “Disk problems. Some user files damaged.”.

If you just want to get rid of irrecoverable parity error sectors, you can use TMS (which you've editlibbed into the system) to write zeros or whatever to the affected sectors. Note that PRU = sector, incidentally.

(End of console guide.)

cdc/scope/ · Last modified: 2023/09/02 14:56 by Site Administrator