SCOPE/Hustler Console Guide

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) msu.edu

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

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:

CONSOLE COMMANDS

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:

A command format dictionary resides on the Y display.

SPECIFIC PROCEDURES

BLANK-LABELLING A TAPE

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

Type:
n.BLANKdv.
VRNdv,six character visual reel number.
n.GO.

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.

DEALING WITH ECS PARITY ERRORS

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:

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.

MOVING JOBS BETWEEN MAINFRAMES (DMPQ/RESQ)

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
n.CFO STOP

where:

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.CLEAR
3.X DMPQ,M750,PF=RDA
3.CFO A
3.CFO *
3.CFO STOP
3.NEXT

On the 750, type:
3.CLEAR
3.X RESQ,PF=RDA
3.CFO a
3.CFO *
3.NEXT

GETTING RID OF A JOB IN INPUT

EVICT,sequence number,I

DESTROYING A PRINT FILE

EVICT,sequence number,O

READING PAST EOI ON A PFDUMP TAPE:

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:

7.CLEAR
7.DIS
UNLOCKED BY xxx TO alter CPA.
C4,1762
1762,4,4000                 set pf permission bit.  note that addr
KEEP52.                     depends on control point
KEEP53.
ASSIGN52,OLD,S,Z,NS,PE.
X.REWIND,OLD.
*
3.CLEAR
3.X PFDUMP,PFN=anything,NT=output vrn.  creates correct header label.
3.NEXT
*
ASSIGN53,NEW,S,Z,NS,PE,RW.
X.REWIND,NEW.
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.REWIND,OLD.
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.
DROP.
LOCK.
7.NEXT

HOW TO ATTACH A PERMANENT FILE WHOSE PASSWORDS YOU DO NOT KNOW:

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). 

Example:
3.CLEAR
3.DIS
X.ATTACH,NINE,pfn,PW=429777268.
*
UNLOCK BY MRR TO ALTER FNT

5727,3,7700.  (gives you all permissions.)
LOCK.
*
X.PURGE,NINE.
X.CATALOG,NINE,pfn.
DROP

HOW TO UNHANG AN ARGUS CARD READER

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:

UNLOCK BY VMS TO SET CMP BIT
2.DIS
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.
DROP
LOCK.

HOW TO DEAL WITH DISK PARITY ERRORS

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.)

Back to CDC 6500 frameset