Bank of America

 

I worked for Mason McDuffie for several years until they brought in a new boss who managed to alienate the entire programming staff; the whole staff ended up resigning within the course of a few months.  I went to Bank of America.  What a change!  Instead of one computer, and a small one at that, BofA had rooms full of computers, including the largest models IBM made. 

 

I have mentioned OS/360 and DOS as two IBM operating systems I had worked on.  By the time I got to BofA the System/360 had given way to the System/370.  The major difference was that the 370s included virtual memory.  Likewise the operating systems had changed to OS/VS1 and OS/VS2 from OS/360, and DOS/VS from DOS.  To understand why there were two versions of OS/VS, we have to look back at the three variants of OS/360 that had emerged:  First was PCP (Primary Control Program) which ran one program at a time.  Then there was MFT (Multiprogramming with a Fixed number of Tasks).  In this second variant, memory was statically divided into “partitions” of specified size.  The operator could reconfigure the size of these partitions, but there were significant constraints on what could be done unless all programs in all affected partitions were stopped.  Each partition could run a separate program.  Finally there was MVT (Multiprogramming with a Variable number of Tasks).  In this version the OS dynamically allocated memory to each program as it ran.  MVT also included the capability to run “sub-tasks”—what we would call “threads” today.

 

When the System/370 was introduced, PCP disappeared, MFT became OS/VS1 and MVT became OS/VS2.  OS/VS2 eventually evolved into SVS (Single Virtual Storage), and MVS (Multiple Virtual Storage).  Previous virtual-storage OSes had continued the notion of a single address space as had been the case for real-storage Oses.  But since the OS can change the page tables that define virtual storage whenever it wants, why not have separate and distinct page tables for each process?  Thus, in MVS, each process had its own virtual address space, a concept which is universal today. 

 

There was actually one model of System/360 that had virtual storage (although I don’t think it was called that).  The model was the model 67.  Since IBM’s commercial operating systems didn’t make use of virtual storage, a group of researchers at the IBM Cambridge Scientific Labs devised a new OS specifically for the model 67 called Control Program 67 (CP/67).  CP/67 not only provided virtual memory, it provided entire virtual machines.  In each virtual machine one could run a separate copy of an OS (OS or DOS).  Each virtual machine appeared to have its own memory, CPU, and I/O devices, all simulated by CP/67.  You used a terminal as a console for each virtual machine.  This meant as many people could interact with computer as there were terminals and virtual machines.  But the OSes being run were not inherently interactive—they only had an operator command language for controlling batch jobs.  So the designers of CP/67 came up with a small interactive OS with a single command language integrating both operator commands and additional commands for running programs and managing disk files.  This OS could be run on a real computer, but due to the fact that real computer time was still expensive, it was primarily designed to run in a virtual machine.  The OS was called the Cambridge Monitor System (CMS). 

 

When the System/370 came along, CP/67 was redone to become a commercially available operating system, rechristened VM/370.  It still consisted of a Control Program (CP) that ran the real computer and created the virtual machines, plus CMS, now called Conversational Monitor System. 

 

In addition a third special-purpose OS was included, called Remote Spooling Communication Subsystem (RSCS).  RSCS was designed to interact with remote batch terminals that contained card readers and printers.  Eventually IBM created a way for a virtual card punch on one real system to be connected via RSCS to the virtual card reader on another real system, thus creating a primitive way of networking two or more System/370s together.

 

At BofA I worked on two third-party commercializations of CP/67 and later on VM/370.  It was such a thrill to be able to directly interact with the computer through a terminal, instead of having to submit batch jobs on punched cards.

 

Most of the interactive terminals we used at first were Texas Instruments “Silent 700” terminals.  They weren’t really silent but they were very quiet compared to teletype machines, with which they were compatible.  They ran at the blinding speed of 30 characters per second.  Even though we were in the same building (but not the same room) as the computer to which we attached, we still used dial-up phone lines and acoustic couplers to connect to the computer.  The Silent 700 used thermal paper and “burned” the characters onto the paper.  If you left a printout in your car on a hot day, it turned black.

 

There were also some terminals made from IBM Selectric typewriters.  These were noiser, and slower (15 characters per second) but they produced nicer looking output. 

 

Finally, we had what we called “glass teletypes”.  These were terminals that didn’t have a print mechanism, but had instead a CRT screen.  Because they   had no mechanical parts, they could go faster, 120 characters a second.  But they required faster modems.

 

VM/370 was able to connect to these same types of terminals, but was more frequently used with IBM 3270 terminals.  Like the glass teletypes, they used a keyboard and CRT screen.  However the protocol the computer used to control them was not the same as that used for the earlier terminals, i.e. it was not compatible with the protocol used for teletypes.  These terminals were locally attached to the computer and as a consequence could display data much faster.