pkimpel.retro-b5500/WebUIUsingTheSPO.wiki

#summary Instructions for using the SPO (supervisory keyboard/printer) with the retro-B5500 emulator in a web browser.
#labels Burroughs,B5500,emulator,retro-b5500,operator,console,SPO,keyboard

= WebUI Using the SPO =
<wiki:toc max_depth="2"/>


Virtually all operational control of a B5500 system was done through the supervisory keyboard/printer, or SPO.

The term "SPO" is presumably an acronym for "supervisor print out" or "supervisory printer for operators," or something like that. Its use persisted with Burroughs systems long after the mechanical keyboard/printers were no longer used and the operator interface transitioned to a video terminal. Modern Unisys MCP system now refer to the SPO as the Operator Display Terminal, or "ODT."


= Background =

Initially on the B5000 and early B5500s, the SPO was a Smith-Carona electric typewriter, modified to interface with the system's I/O Control Units. Later, Burroughs started using a standard Teletype Model 33 KSR device, with a panel of control buttons installed where a modem would normally be. This was termed the B495 Supervisory Printer. The best picture we have of the B495 comes from the B100/200/300 Reference Manual:

    https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B495-SPO-Image.png

The printer and control buttons looked very similar to the interface we have developed for the web-based emulator:

    https://googledrive.com/host/0BxqKm7v4xBswRjNYQnpqM0ItbkU/B5500-SPO.png

The SPO was intended solely as an operational control device and not as a timesharing terminal. Programs could communicate with the SPO, but since the system typically ran multiple jobs at once, access to the SPO had to be shared on a non-conflicting basis. While it was possible to compile and run programs from the SPO (assuming the source or object code was already on disk), one did not sit at the SPO to, say, edit source code.

The SPO was a peripheral device, and interfaced both physically and electronically to the rest of the system the same way that a tape drive or card reader would. It sat on the short end of the L-shaped operator console desk. Below it was a logic rack that adapted the Teletype interface signals to those of the system's I/O Units.

Since the SPO was very slow -- 10 characters/second -- and completely unbuffered, it tied up an I/O unit for the entire time that it was either printing or waiting for the operator to finish entering a command. There were a maximum of four I/O units on a system (three was a more typical number), so continuous SPO activity could have a significant impact on overall system I/O performance. The MCP went to some trouble to compress SPO output by stripping multiple blanks, and limited the number of output messages that could be queued for printing. There was also an operator command (`BK` or `<mix>BK`) to flush the output queue for either the whole system or a specified job.

In order to read from the SPO keyboard, the system must to select an I/O unit and initiate a read operation to the SPO. To signal the MCP when this is needed, there is a special Keyboard Request interrupt, triggered by the *INPUT REQUEST* button on the SPO control panel, as discussed below.


= SPO Control Panel =

The Model 33 teletype had a rotary off/local/remote switch on its front bezel, below the keyboard. This was typically left in the "remote" position unless the system was being powered down completely. The emulator does not implement this.

The Model 33 had a space on the right side of its case where interface equipment could be installed. This was often used for a dial modem. The units for the B5500 had a special panel installed in this space that had ten button/light controls in two columns of five. Three of the button/lights were blank and unused. The rest were labeled as follows:

    * *POWER* -- this green light illuminates when power is applied to the device. In the web-based emulator, it is always illuminated, and otherwise non-functional.
    * *READY* -- this yellow light illuminates when the system initiates a read operation in response to the *INPUT REQUEST* button being pressed.
    * *REMOTE* -- this yellow button/light indicates the device is on-line to the rest of the system. If the device is off-line, pressing the button makes it on-line.
    * *LOCAL* -- this yellow button/light indicates the device is off-line to the rest of the system. If the device is on-line, pressing the button makes it off-line. When the device is off-line, you can type comments onto the paper, which will not be transmitted to the system.
    * *INPUT REQUEST* this yellow button/light is used to set the Keyboard Request interrupt. That interrupt in turn requests attention from the MCP so that it will initiate a read operation for the keyboard. When pressed, the button lights, and remains lit until the system initiates the read operation, at which point the light goes out, the *READY* light comes on, and the keyboard is enabled for input.
    * *END OF MESSAGE* -- after entering a command on the keyboard, press this yellow button to terminate the input and signal the system that the command is complete. This also extinguishes the *READY* light.
    * *ERROR* -- if you makde a mistake while entering a command, press this yellow button to cancel what had been entered. The MCP will discard your input to that point and reinitiate a read operation to the device. To cancel a partially-entered command and not reenter it, press *ERROR*, and then when *READY* comes back on, press *END OF MESSAGE*.

The emulated SPO supports a few user-interface features that the Teletype Model 33 device did not:

    # When the SPO window has the focus, you can press the ESC key instead of the *INPUT REQUEST* button to request input to the system. The *INPUT REQUEST* button will light as if it had been pressed.
    # You can press the Enter key on your keyboard instead of the *END OF MESSAGE* button to end a message.
    # When the *READY* light is on and the SPO window has the focus, you can press the ESC key to cancel your input instead of the *ERROR* button. In either case, the carriage will start a new line and the *READY* light will eventually come on again to allow you to reenter your command.
    # Lower-case letters will be translated to upper case as you type them. Neither the B5500 nor the Model 33 supported lower case.
    # When entering a command, you can press the Backspace key to correct errors. The Model 33 could not backspace.
    # You can type faster than 10 characters/second, which was physically impossible with a Model 33. The SPO echos your keystrokes at only 10 cps, but it will eventually catch up to what you have entered.


= Tips for Using the SPO =

When the system is powered on and the SPO window opens, the SPO will print a short message indicating the emulator version. Please wait for this message to finish printing before attempting to press the *LOAD* button on the operator console.

You may move and resize the SPO window, and minimize it, but _do not close the window._ The system will warn you if you attempt to do this. Closing the window will render the SPO inoperable until the emulator is reinitialized with the *POWER ON* button.

The frame representing the "paper" for the SPO has a 500-line scrollback. It is implemented as an HTML `<iframe>` element, so most browsers will allow you to save or print the contents of the window. You can also select text within the window and copy/paste it into another application on your workstation. Note, however, that when text from the "paper" is selected, the input focus is on the paper's frame, not the SPO window, so pressing ESC to request input will not work. In this case, you need to click the *INPUT REQUEST* button with your pointing device, or click somewhere on the SPO window outside of the "paper" frame before pressing ESC.


= An Overview of MCP SPO Commands =

The basic commands you will need to operate the B5500 emulator in a batch environment are listed below. This list does not include any of the data communications or timesharing-specific commands. More complete documentation for the SPO commands and output messages can be found in documents on bitsavers.org:

    * [http://www.bitsavers.org/pdf/burroughs/B5000_5500_5700/1031986_B5500_Handbook_Aug70.pdf B5500 Handbook (April 1970)] describes:
        * SPO commands starting on page 4-23
        * SPO output messages starting on page 4-1.
    * [http://www.bitsavers.org/pdf/burroughs/B5000_5500_5700/1024916_B5500_B5700_OperMan_Sep68.pdf B5500 Operation Manual (September 1968)] has somewhat older information:
        * SPO commands starting on page C-40
        * SPO output messages starting on page C-1
    * [http://www.bitsavers.org/pdf/burroughs/B5000_5500_5700/1058583_B5700_TSS_RefMan_Sep72.pdf B5700 Timesharing System Manual (September 1972)] has information relating to operation of the Timesharing MCP:
        * SPO commands starting on page 1-15

The B5500 MCP used a terse set of operator commands based on two-letter mnemonic codes. Some commands consisted only of their mnemonic code; other commands required operands after the mnemonic.

In the discussion below, the term _program_ refers to a executable file, i.e., a codefile. The term _job_ refers to an instance of a program executing (or having been scheduled for execution) in "the mix" -- the collection of jobs currently executing in the system. One program could be associated with multiple jobs in the mix and/or the schedule at the same time.

Commands that affected a specific job in the system must be prefixed by that job's "mix number," a one- or two-digit integer assigned to the job by the MCP when the job initiates. This mix number is identified as "`<mix>`" in the descriptions below.

Peripheral devices are referred to by a three letter mnemonic:

    * `SPO` -- the SPO
    * `CRA`, `CRB` -- card readers 1 and 2
    * `CDA`-`CD9` -- pseudo readers 1-32 (for spooled card decks -- letters `I` and `O`, and digits `0` and `1` not used)
    * `CPA` -- the card punch
    * `LPA`, `LPB` -- line printers 1 and 2
    * `MTA`-`MTT` -- magnetic tape units 1-16 (letters `G`, `I`, `O`, and `Q` not used)
    * `DCA` -- data communications adapter
    * `PRA`, `PRB` -- paper tape readers 1 and 2
    * `PPA`, `PPB` -- paper tape punches 1 and 2
    * `DKA`, `DKB` -- head-per-track disk control units 1 and 2
    * `DRA`, `DRB` -- drum units 1 and 2

If you enter an invalid SPO command, or one that has errors in its syntax or operands, the MCP typically responds with just `INV KBD` -- invalid keyboard entry.

|| `<mix>AX`    || "Accept" -- reply to an `ACCEPT` statement or a SPO file read executed by the specified mix index, e.g., `3AXNO`. The text following `AX` after stripping any leading spaces is made available to the program. ||
|| `<mix>BK`    || 'Break" -- clear messages queued only for the specified mix number, e.g., `5BK`. When used without a mix number, clears the SPO output queue for the entire system. ||
|| `CC`         || "Control Card" -- enter control card syntax directly on the SPO. "`?`" can be used instead of `CC`. Semicolons (`;`) can be used to delimit multiple control statements on one line (72 character, max). The MCP will continue issuing reads to the SPO until and `END` statement or a syntax error is encountered. ||
|| `CD`         || "Card Decks" -- list deck number and first card image of each "pseudo" card deck currently queued on disk by the `LDCNTRL/DISK` input spooler, e.g., `CD`. ||
|| `CL`         || "Clear Unit" -- reset the MCP status of the specified unit mnemonic (e.g., `CL CRA`, `CL MTB`) and DS-es (aborts) any job to which the unit is currently assigned. In the case of card readers, the MCP will read and ignore all cards until the next control card (one with an invalid character in column 1). ||
|| `<mix>CT`    || "Change Times" -- change the processor and I/O time limits for the specified mix number, e.g., "`3CT 300,60`". The integers specify limits for processor and I/O time, respectively, in seconds. Either time may be omitted, but the comma is required if the I/O time is specified. ||
|| `<mix>CU`    || "Core Usage" -- display memory use in words for the specified mix number, e.g., `3CU`. When used without a mix number, displays memory use for all jobs in the system. ||
|| `<mix>DS`    || "Discontinue" -- abort the job with the specified mix number, e.g. `2DS`. Pronounced "dee ess." ||
|| `DT`         || "Date" -- change the system date, e.g., `DT 7/20/83. The date must be written in month/day/year format, using either "`/`" or "`-`" as a delimiter between the date parts. The year must be two digits, and will be interpreted as a 1900-relative year. The B5500 was not Y2K compliant, as no systems were known still to be running in 2000. ||
|| `ED`         || "Eliminate Deck" -- discard a spooled card deck that has been assigned to the specified pseudo reader, e.g., `ED CDA`. ||
|| `<mix>ES`    || "Eliminate from Schedule" -- terminate a job that has been scheduled but not yet begun execution. `DS` cannot be used in this case because the job is in the schedule, not yet in the mix. The mix number is actually a schedule index, e.g., `3ES`. ||
|| `<mix>FM`    || "Form Message" -- reply to a `#FM RQD` message when output is to be printed on special forms by assigning a printer to the specified mix number, e.g., `5FM LPA`. Presumably the operator previously loaded the necessary forms into that printer. ||
|| `<mix>FR`    || "Final Reel" -- reply to a `#NO FIL` message for an unlabeled tape file to inform the system that no more reels of tape are to be read, e.g., `4FR`. This causes the job for the specified mix number to receive an EOF result on the pending read. ||
|| `<mix>IL`    || "Ignore Label" -- reply to a `#NO FIL` or `#DUP FIL` message when the system cannot find a peripheral unit with media labeled to match the file name requested by the job with the specified mix number. Assigns a specified unit to that job regardless of how the media on that unit is labeled, e.g., `3IL MTB` or `2ILCRA`. ||
|| `<mix>IN`    || "Insert Number" -- store a one-word binary unsigned integer value into a PRT location (designated in octal) for the specified mix number, e.g., `4IN 25=33`. This was typically used to asynchronously supply a dynamic parameter to a job, but the job had to sample the PRT location periodically in order to get the value. ||
|| `LD`         || "Load Decks" -- initiate the `LDCNTRL/DISK` input spooler to read decks from a card reader or magnetic tape labeled `CONTROL/DECK` and store them either on disk or another magnetic tape for ultimate use by a pseudo reader. `LD DK` stores decks on disk; `LD MT` stores decks on tape. See [WebUIUsingTheCardReader Using the Card Reader] for more information on how to label a card reader for use with this command. ||
|| `LN`         || "Log New" -- transfer the contents of the `SYSTEM/LOG` file to a new file, e.g., `LN`. The new file is named _mmddccc_`/SYSLOG`, where _mm_ is the current month, _dd_ is the current date of month, and _ccc_ is a log sequence number assigned by the MCP. ||
|| `MX`         || "Mix" -- list all of the jobs currently running in the mix, e.g., `MX`. Each job is listed as _p_`:`_mfid_`/`_fid_`=`_mm_, where _p_ is the priority (0=highest, 9=lowest), _mfid_`/`_fid_ is the program name, and _mm_ is the mix number. ||
|| `<mix>OF`    || "Optional File" -- reply to a `#NO FIL` message from a COBOL job when the requested file is not present and will not be provided to the job, e.g., `7OF`. This causes the `OPEN` statement in the COBOL program to succeed and for the program to receive an EOF result on the first read of the file. ||
|| `<mix>OK`    || "Okay, Try Again" -- reply to a job that has been suspended by the operator, or is waiting for some resource (such as a file or available space on disk) to be made available, e.g., `4OK`. If the program was suspended by the operator with a `ST` command, it resumes execution. If the program was suspended due to an unavailable resource, the system checks again for the resource. If it is available, the program resumes execution, otherwise it remains suspended. The system typically recognized newly-available resources and resumed suspended programs automatically, so this command was seldom required except to resume after an `ST` command. ||
|| `OL`         || "Observe Label" -- display the current status of the specified peripheral device, including the name of any media currently mounted on it, e.g., `OL MTD`. ||
|| `<mix>OT`    || "Output Value" -- display the value of a PRT location (specified in octal) for the specified mix number, e.g., `3OT26`. The first location available for variables declared in a program was octal 25. When compiling a program, `OT25` indicates the number of syntax errors encountered thus far. For most compilers, `OT27` indicates the sequence number of the record currently being scanned. ||
|| `<mix>OU`    || "Output Unit" -- reply to a `#LP RQD` or `#LP PBT MT RQD` message from the specified mix number to supply the physical output medium for a job's printer file if the `PBDONLY` option is not set and no line printer is currently available, e.g., `5OU MT` for a printer-backup tape. ||
|| `PB`         || "Print Backup" -- initiate printing of printer or punch data that has been spooled to disk or tape, e.g., `PB MTC` for a printer-backup tape, or `PB 231` for a backup file on disk. Printer- and punch-backup files on disk are named `PBD/`_nnnnsss_ and `PUD/`_nnnnsss_, respectively, where _nnnn_ is a backup-file number assigned by the MCP and _sss_ is a sequence number also assigned by the MCP. The _nnnn_ number is the one used with a `PB` command. Large printer files were broken up into multiple physical files on disk, all having the same _nnnn_ value but different _sss_ values. The MCP automatically prints all files having the same _nnnn_ value. ||
|| `PD`         || "Print Directory" -- list the names of files on disk matching the pattern specified by the operand. Disk files have two-level names, termed the multiple-file ID (MFID) and file ID (FID). Possible search patterns are `PD `_mfid_`/`_fid_, `PD `_mfid_`/=` (or `PD `_mfid_`=` or just `PD `_mfid_), `PD =/`_fid_ (or `PD =`_fid_), or `PD =/=` (or just `PD =`. ||
|| `PG`         || "Purge" -- purge a magnetic tape volume (reel) by writing a "scratch" label on it, and optionally assign a five-digit volume number in the process, e.g., `PG MTA` or `PG MTD-12345`, where `12345` is the volume number and the dash is required. ||
|| `<mix>PR`    || "Priority" -- change the priority of a job in the mix, e.g., `4PR=6`. The highest priority is 0 and the lowest is 9. ||
|| `<mix>PS`    || "Priority in Schedule" -- change the priority of a job that is in the schedule, similar to the `PR` command, e.g., `5PS=7`. The mix number is actually a schedule index. ||
|| `QT`         || "Quit Output" -- stop printing or punching the spooled file being output to the designated peripheral unit, e.g., `QT LPB` or `QT CPA`. Can also be entered with the mix number of the spooler job, e.g., `3QT`. The backup file on disk or tape is merely skipped, not purged. ||
|| `RD`         || "Remove Decks" -- removes spooled card decks from disk if they have not yet been assigned to a pseudo reader. The decks are identified by their deck number, as displayed by the `CD` command, e.g., `RD #203, #207, #216`. ||
|| `<mix>RM`    || "Remove" -- resolve a duplicate-file condition, where a job is attempting to lock a new file into the disk directory, but a file of the same name already exists on disk. If the command is entered in response to this condition (e.g., `3RM`), the existing file on disk will be replaced by the new one. The alternative is to `DS` the program, which will leave the existing file in place. ||
|| `RN`         || "Reader Number" -- set the number of active pseudo readers (input deck de-spoolers) for the system, e.g., `RN 2`. Setting the number to zero inhibits further decks from being de-spooled. Can also be entered with a deck number, e.g., `RN #204`, to load the specified deck into a pseudo reader. This latter form is normally used only with shared-disk systems. ||
|| `RO`         || "Reset Option" -- reset one of the MCP options, e.g., `RO USE AUTOPRNT` ||
|| `RW`         || "Rewind Unit" -- rewind and logically "lock" the tape drive designated by the operand, e.g., `RW MTB`. The unit must not currently be assigned to a job. A "locked" unit cannot be assigned to a job by the system until either the operator enters an `RY` command referencing the unit, or the unit is made not-ready and then ready again (so that the MCP would sense the status change). `RW` was often used to keep the system from using a mounted scratch tape until the operator was ready for it to be assigned to a specific job. ||
|| `RY`         || "Ready Unit" -- force the MCP to recognize a change in the status of the designated units, as if the units had been made not-ready and then ready again, so that the MCP would sense the status change, e.g., `RY MTD`, `RY CRA CRA CPA`. Readying a card reader that has been labeled but not yet referenced causes the `LABEL` or `?DATA` card to be ignored. ||
|| `SF`         || "Set Factor" -- set the Multiprocessing Factor for the system, a real number with at most two digits before and two digits after the decimal point, e.g., `SF 1.25`. This is essentially a fudge factor by which the amount of available physical memory is multiplied when determining whether a job can be moved out of the schedule and into the mix. ||
|| `SO`         || "Set Option" -- set one of the MCP options, e.g., `SO USE TIME` ||
|| `<mix>ST`    || "Suspend Task" -- suspend the job for the specified mix number, e.g., `5ST`. The job stays in the mix, but does not consume any processor time. The job may be resumed with an `OK` command or terminated with a `DS` command. ||
|| `SV`         || "Save Unit" -- mark a peripheral device as unavailable for assignment to a job. If the unit is currently assigned to a job, it becomes unavailable for further assignment when it is released by that job. ||
|| `TF`         || "Type Factor" -- display the current Multiprocessing Factor as set by the `SF` command. ||
|| `<mix>TI`    || "Times" -- display the running times for the job with the specified mix number, e.g., `3TI`. The processor, I/O (channel), and elapsed times, respectively, are displayed in _hours_:_minutes_:_seconds_ format, e.g., `CP= 1:41, IO= 8 IN 1:44` ||
|| `<mix>TL`    || "Time Limits" -- display the processor and I/O time limits for the job with the specified mix limit, e.g., `5TL`. ||
|| `TO`         || "Type Options" -- list all of the MCP run-time options and their current setting, e.g., `TO`. ||
|| `TR`         || "Time Reset" -- set the system time of day in 24-hour notation, e.g., `TR 1345`. ||
|| `TS`         || "Type Schedule" -- list all jobs currently in the schedule, e.g., `TS`. ||
|| `UL`         || "Unlabeled" -- reply to a `#NO FIL` message and assign a peripheral unit with unlabeled media to the job with the specified mix number, e.g., `4UL MTD`. ||
|| `WD`         || "What Date" -- display the current system date, e.g., `WD`. ||
|| `WI`         || "What Intrinsics" -- display the name of the current System Intrinsics file being used by the system, e.g., `WI`. ||
|| `WM`         || "What MCP" -- display the name of the current MCP file being used with the system and the compile-time options that are enabled for it, e.g., `WM`. ||
|| `WT`         || "What Time" -- display the current time of day, e.g., `WT`. ||
|| `<mix>WY`    || "Why Stopped" -- display the reason that the job with the specified mix index has suspended execution and the command mnemonics the MCP will accept to resolve the suspension, e.g., `5WY`. When used without a mix number, displays all of the jobs that are suspended and waiting for operator intervention. ||
|| `<mix>XS`    || "Execute from Schedule" -- force the job with the specified mix number from the schedule into the running mix, even though the MCP does not think it has sufficient memory to run that job, e.g., `2XS`. The mix number is actually a schedule index. ||
|| `<mix>XT`    || "Extend Times" -- extend the time limits for the job with the specified mix index, e.g., `5XT 360,190`. This command is similar to `CT`, but specifies the new limits relative to the existing ones, instead of setting absolute limits. The times are specified in seconds for the processor and I/O limits, respectively. Either time may be omitted, but if the I/O time is specified, it must be preceded by a comma. ||