By Rich A.
As anyone familiar with LCM+L knows, the museum initially grew out of Paul Allen’s personal collection of vintage computers. Many of the larger systems in the collection reflected his own experiences with computers beginning in when he was still in high school. Among the systems he used then were System/360 mainframes manufactured by IBM, most of them stodgy batch processing systems with little appeal for a young man who had been exposed to interactive computing on systems from General Electric and Digital Equipment Corporation. There was, however, one member of the family which was different, IBM’s entry into the world of timeshared interactive computing, the System/360 Model 67.
The heart of the difference between the 360/67 and other members of the System/360 family is the operating system, composed of two independent parts. CP-67, the control program, provides timeshared access to all of the system’s features in the form of “virtual machines”; CMS, the Cambridge Monitor System, runs in each user’s own virtual machine and provides the interactive facilities for programming, text editing, and everything else the user might want to accomplish. The combination was known as CP/CMS.
I came to work for Paul Allen in 2003, to improve and expand his collection and eventually to turn it into a museum. The wish list we developed was large, and of course included several models of the System/360, including and especially the 360/67. The quixotically intense search met with minimal success for years because IBM almost never sold their large computers, instead leasing them to customers so as to control the supply: IBM did not want to compete against their own products for market share. This meant that retired systems rarely made their way into the hands of collectors; they were instead sold overseas, leased to new customers, or scrapped. For a while, the best we could do was the lights panel from the console of a 360/91 from which all circuitry (rich in gold) had been removed.
The first major break came with a story on the Australian Broadcasting Company’s web site about the impending demise of systems owned by the Australian Computer Museum Society. My colleague Keith Perez contacted the ACMS and learned that they owned a 360/40, which they were not interested in deaccessioning. This conversation continued for a while, then tapered off until 2011, when Keith encountered an acquaintance of Tony Epton, president of the ACMS, while on a business trip to Sainte-Nazaire, France. The ensuing renewed discussions resulted in another colleague, Ian King, making a side trip to Perth in February before returning from a trip to Adelaide to have a look at an IBM 7090 system. Ian visited the barn in which the ACMS was storing two 360/40 systems, and recommended that we purchase one of them. The system arrived in Seattle in September 2011.
Once the 360/40 arrived, we brought in a retired IBM Customer Engineer to assess its prospects for restoration. At this point we learned something important about IBM mainframes of the 1960s and 1970s: No two are exactly alike, and without the system specific Automated Logic Diagrams (ALDs) which document how it was assembled, the chances of restoring one to operating condition are greatly reduced. The former CE also noted the amount of dust caked on the circuitry–the system had been stored in a barn in a desert–which would decrease the likelihood of a successful restoration. He passed on the opportunity to work on the project.
In 2012, we acquired three IBM systems (a 360/20, a 360/44, and a 360/65) from the American Computer Museum in Montana, none in working condition: The internal disk drive in the Model 44 had broken loose from its housing and was held in place by a piece of rope, and the internal console cables of the Model 65 had all been cut. The 360/65 was particularly painful: More than a dozen bundles of 50 to 100 identical wires each were made useless. Neither system could be repaired with our facilities.
Bob Barnett, the museum’s business manager, also located a 360/65 in Virginia which belonged to one of the principals at Sine Nomine Associates, David Boyes. David had contacts within IBM who he believed could be helpful in arranging for LCM+L to obtain licenses for the software we wanted to run, and was eager to help us put up a large System/360.
The 360/20 is a 16-bit minicomputer only marginally related to the main System/360 line. As a stopgap, to be able to say we had a running System/360, the one we acquired from the American Computer Museum was restored to running condition by an enthusiastic pair of contractors, Glen Hermmannsfeldt and Craig Arno, with help from Keith Hayes and Josh Dersch of LCM+L; it was displayed in the Computer Room from 2015 to 2017, initially while the restoration work was done and then as an example of a small batch system. As is often done for vintage systems at LCM+L, virtual peripherals–a card reader and punch–were created for the 360/20.
By 2015, the desire for an IBM system capable of providing a timesharing experience led to the acquisition of a 4341 system from Paul Pierce of Portland, Oregon. By this time, we had established an ongoing dialogue with the team who had successfully restored an IBM 1401 at the Computer History Museum (CHM) in California. One of the members of the team introduced us to Fundamental Software Inc. Faced with the task of restoring 40-year-old tape and disk drives, or creating our own emulations, we decided that we would instead acquire an FSI FLEX-CUB to provide disks, tapes, and terminal services to the 4341.
Jeff Kaylin was given the task of making the 4341 CPU run. Beginning in July 2015, he spent seven months getting the power system into working condition; first power up was on 12 February 2016.
Once the system was working to this extent, we ordered a FLEX-CUB from FSI and began attaching 3278 terminals to the built-in controller for testing. Also at this time, David Boyes informed us that he had arranged licensing for the VM/SP HPO operating system for us.
The FLEX-CUB arrived at LCM+L on 1 June 2016, with a minimal VM/370 installation in place courtesy of our friends at FSI. After some phone consultations with FSI Support, we were able to IPL the system into VM/370. Three weeks of getting additional terminals configured followed, with discussions of the OS configuration between FSI and me, replacements of capacitors and CRTs in terminals, and so on. Progress halted on 20 June, when Jeff arrived on a Monday morning to find the system halted with the words CHECK STOP and an error code on the console.
We obtained an 8in diskette with diagnostics from FSI. Memory tests showed that the memory was working; swapping of boards with spares commenced. The power sequence was a suspect for a long time. Jeff began making schematics for the various boards in order to understand where faults might occur that matched the diagnostic callouts. For two months, Jeff wrestled with the system with no progress.
Our consultant from CHM advised Cynde Moya, our Collections Manager, of the existence of 4341 and 4361 systems housed in a warehouse in Sacramento, California. I spoke with the owner, Daniel de Long, and learned that he had a working 4361 plus spares in the form of another 4361 and two 4331s. I traveled to Sacramento a week later to have a look, seeing the 4361 IPLed and running under DOS/VSE. After some discussion, the 4361 equipment began arriving at LCM+L on 2 November 2016.
In December 2016, Jeff began pulling the power supplies out of the 4361, to check the capacitors. All were within tolerance, but since 2004 our policy has always been to replace all aluminum electrolytic capacitors in any device we restore. The new capacitors were installed and the power supplies replaced in the chassis in the remaining weeks of 2016.
In mid-January 2017, the newly refurbished 4361 replaced the 4341 in the Computer Room. FSI, who have been very helpful throughout the project, advised us on how to cable the FLEX-CUB to the new system. A different power outlet was installed to accommodate the different plug on the 4361.
When the power button was pushed, the built-in floppy drives’ motor spun, but stopped as soon as the button was released. Jeff tried attaching the operator console, with no change in behavior. A phone call to Dan de Long revealed that the system was wired for 230V rather than 208V, necessitating either a change in the room wiring or a reconfiguration of the system’s power supplies; the latter was a simple matter of changing jumpers on four transformers to provide single-phase 208V, after which the system powered up and stayed up.
Power issues continued to plague Jeff. The first supply in the system would come up, with its test point providing 1.5V as expected, and all the proper voltages supplied; the second and thrid supplies showed no voltages. Going through the ALDs allowed him to trace through all four supplies with no luck in determining the problem.
After a couple of weeks, I suggested that Jeff contact Dan again, who pointed out that the system requires that a printer be attached in order to complete the power sequence. We ordered capacitors for the printer, and had additional outlets installed under the raised floor. The printer was ready to go a month later, after degraded old foam insulation was replaced along with the power supply rebuild.
With the printer installed, the system would now power up, but the printer would not stay powered on. A long correspondence, with pictures, commenced between Jeff and Dan. This went on from mid-March to mid-May, when a suggestion to swap the cables on the floppy disk drives led to the replacement of one drive. The system would now perform an Initial Microcode Load (“IML”), after which it suggested running the Problem Finder diagnostic tool. Progress! A few more days of fiddling about (bad breakers in the power supplies, etc.) led to the indicator lights on the console keyboard signalling “Power Complete”.
Jeff cabled the FLEX-CUB to the 4361, and changed some system settings on the console to allow it to run VM/370 instead of DOS/VSE. I sent the FLEX-CUB configuration which had been set up for the 4341 to Fundamental Software; they sent one back which had the proper incantations for the 4361 instead and installed it for us remotely.
After I checked over Jeff’s revised settings on the console, we tried to IPL the system, which could not find the configured IPL device. The Problem Finder tool likewise did not find it. I reviewed the FLEX-CUB configuration, and did not find anything problematic there, so stopped for the evening, asked Jeff to locate the Operating Procedures manual for the 4361, and sent pictures to FSI of the console screen showing the Unit Control Words (UCWs) defined for the devices attached to the system. The next day, I got back suggestions for updated UCWs and updated the settings on the console while Jeff moved the channel cables to their new places. Although the system still did not come up, it did report channel status on the console so we knew the system was alive.
The next day, I revised the UCWs again on advice from FSI, to change the controllers on all disks and tapes to 3880s. Several attempts to IPL the system were unsuccessful, but in the mean time we attached more 3278/3279 terminals and got the correct keyboards on them. A day later, after telling the system that the 3279-2A display was a 1052 Selectric-style printing terminal with no printer attached and another IPL, we were prompted for date and time; FSI advised issuing the command CP ENABLE ALL to make the attached terminals live in the system. FSI did little more configuration on the FLEX-CUB, and they and I were able to log on to the MAINT account! That was the end of May, 2017.
Now my task of installing a full operating system began. Several weeks of reading manuals ensued, along with the installation of the Hercules emulator on a Windows desktop and on a Linux server. By the end of June, 2017, I had the public domain VM/370 running on both, a task made simpler due in equal parts to the existence of turnkey installations and an active Hercules community. In particular, the members of the Hercules-VM group have been very helpful over the last year, offering suggestions, advice, software, and general excitement for our project.
I reached out to David Boyes to ask that he put us in touch with his IBM contact for licensing VM/SP, the preferred version of VM/CMS for our hardware. David wrote back to me that his contact was no longer at IBM, but that he would try to find us the proper person to talk to; he also told me that the tapes he had preserved had been shipped off to CHM a while back, and that he was asking that images be made. A week later, I had the name of IBM’s Product Manager for z/VM and Related Products, George Madl, and sent him a message outlining LCM+L’s mission and place of the 4361 and VM/SP in the museum’s offerings. He forwarded the request to Glenda Ford in IBM’s licensing department. Glenda shepherded the request through IBM’s processes for four months and by mid-November had worked out a very favorable license with reasonable restrictions (no support, no commercial use of the system, no fees).
While waiting for an answer to the license question, I moved on with planning for VM/SP, starting with a review of the differences between VM/370 and VM/SP installation. As the weeks went by, I proposed a backup plan in which we would begin by installing VM/370, and upgrade to VM/SP when the licensing came through. This took us to the end of 2017.
In January 2018, with help from FSI, I configured eight 3350 disk drives on the 4361. As we worked together to finalize the new setup, they set up a production VM/370 system on three drives, along with an emulated card reader and punch and an emulated printer. (We even uncovered a bug in the FLEX-CUB software, so the benefit was not all in one direction!) I set up guest accounts for two users who had been asking since the 4341 restoration began, and collected their impressions.
For further planning, I returned to the Hercules emulator, looking at access to language processors and other utilities. I planned to provision our new VM/370 from the prebuilt Hercules disk images, so had to learn the ins and outs of DDR (the DASD Dump/Restore program). I added three more 3350 disks to the system, in order to hold the desired contents from the Hercules ready-built VM/370 system. I had to remember to re-IPL the system in order to make the new drives available; the 1970s had no concept of “plug-and-play” peripherals.
It became clear that the integration of the Hercules “6-pack” (made up of six 3350 disk images) was very tight, and the simplest way forward might be to install these images onto our FLEX-CUB disks via DDR. I consulted with the H390-VM mailing list, who concurred in that idea. However, at this point two people came forward with offers of assistance.
One of the architects of the Hercules “6-pack VM” system had available the installation tapes for VM/SP Release 5, which was our original target for the 4361. He provided us with images of the tapes and images of 3350 disks onto which the installation files had been placed, and gave us a hand from the UK in getting things set up under Hercules.
The other is Drew Derbyshire, one of the VM/370 beta testers. Drew is a contract programmer with 10 years’ experience in the VM/CMS world, including a long stint working on the CP nucleus for IBM. He is also local to Seattle, and a member of LCM+L, so was well placed to help us move forward with the installation and configuration of VM/SP for our particular purpose.
On 1 March 2018, I was able to IPL the 4361 under VM/SP, having copied the installation disk images over to the FLEX-CUB with help from FSI and our helpers. These were still 3350s, so I created sixteen new 3380-K disk images on the FLEX-CUB, a total of just under 20GB of storage space, as the first step in making the system available to the public by 1 April.
At this point Drew, as a contractor, and I began a fruitful working relationship, trading configuration notes, ideas for further work, and so on. Drew set up a Hercules mimic of the 4361’s exact configuration in order to experiment when the museum was not open. This was helpful when the 4361’s disks were clobbered due to errors in configurations, and Drew did the artwork for the VM/SP splash page on display terminals connecting to the system.
Over the next 10 weeks, Drew and I built CP nucleuses with different parameter settings, different numbers of terminals defined, 3380 disks instead of 3350, and so on. In mid-May, the 4361 had a machine check, which Jeff and I traced down over the next week to a memory issue. Jeff pulled memory modules from the 4341 to replace those called out by the IBM diagnostics; I began backing up all the disks to tapes, taking the system down every night and bringing it up the next morning.
The interruption was annoying because the developer/maintainer of the Stanford Pascal Compiler was installing his program on the system when the memory fault occurred. Once that was repaired, Drew and he completed testing of the installation and declared it good.
I booted the 4361 on Friday evening, 18 May 2018, for a test run over the weekend. Drew accidentally crashed it from a remote location on Saturday morning, but brought it back up during open hours at LCM+L. The system ran for a week without incident, so I posted an invitation to the H390-VM list for anyone interested to apply for a beta account. This was as much to test the account management software Drew had written as to shine a light on any blind spots we had with regard to software for the casual user.
Since 1 June 2018, Drew has installed the PL/I Optimizing Compiler, Fortran/VS, and other pieces of software to make the system more hospitable. In addition, one of the beta test users installed a version of the IND$FILE file transfer program by cutting and pasting a hexadecimal dump of the binary program into his directory, then let us know about it to install for general use. Drew has made great use of it to make updates from his Hercules testbed to the running 4361.
Future possibilities include installing RSCS and NJE, the remote-job entry subsystem for VM, to create a BITNET-style network site, and creating subsidiary virtual machines running other interactive operating systems such as the Michigan Terminal System or the McGill University MUSIC timesharing system, so stay tuned for further developments!