Multi-Processor Mainframe
Key words: Multi Processor Mainframe, System boot, Print driver, Operator
assistance, Source code highly visible to customers, Interruptive Trace
This experience may be older than some of my readers. Please keep in mind
that the CDC 6000 series mainframes were conceived in the late 50’s by Seymour
Cray. The CDC 6600 was first marketed in 1964. Its core memory could deliver
data in 400nSec with a read/restore cycle complete in 1000nSec.
The SCOPE operating system on which I worked was primarily a batch operating
system. Users submitted card decks to computer operators and picked up printouts
after their jobs finished. In the software development environment where I
worked one could often get 4 to 6 job turnarounds per business day. The Palo
Alto and then Sunnyvale development center had 4 mainframes – 3 of which were
available in hour-long blocks. Longer blocks could be used on the graveyard
shift.
CDC 6000 series mainframes consisted of 1 or 2 fast (by historical standards)
number crunching CPUs. They also contained 7 to 20 totally autonomous Peripheral
Processor Units or PPUs but everybody called them PPs. The CPU(s) had no I/O
capability. At best, the CPU could ask a willing PP to perform I/O.
In my six years at Control Data I was responsible for Job
Processing, Deadstart and Tape
Staging II. For the most part these were parallel responsibilities.
(Tape Staging II was added to my plate after I got familiar with the operating
system.)
Interruptive Trace. To learn the CDC 6000 CPU I wrote an
interruptive trace subroutine. When called as tron() it saved all
registers and pretended to return control back to its caller. Instead of
returning control it picked up the next instruction and faked its execution
printing a line for each instruction. When the user called troff() tracing
stopped. Because it was possible to execute many thousands of interpreted
instructions in a short time I built in several limits. After 1000
instructions I restored all registers and did a real return to where I left off.
Tracing could only be turned on 30 times before tron() became a simple return.
After a total of 3000 lines were printed tracing would turn off and stay off.
That machine had no good way to save all registers. It also had no good
way to restore all registers. Each method forced me to think seriously
about the CPU. I was able to do the register save all by myself. I
did the register restore after I got a hint (use the floating point pack
instructions) from someone maintaining one of the FORTRAN compilers.
My trace was actually used by the FORTRAN compiler people. They needed to
see exactly what was going on in a very tricky section. My trace helped
find the problem.
Low-level management experience. From the moment I replaced a
guy who left to climb mountains in Peru I had a more junior programmer working
with me. As much as possible I involved him in everything we did.