Mainframe Limericks... 3829

Shmuel Metz , Seymour J.

re:

refers to posting

refers to abbreviated quote from Melinda's history paper at:

the following is a little more detail from that referenced extract (regarding 16 percent went to work for DEC):

Boston and its suburbs provided other opportunities that didn't require the VM developers to move away from the bright lights and disrupt the lives of their families. By the end of 1976, sixteen percent of the former Burlington personnel were working for DEC. Forty-seven percent had found IBM positions that didn't require them to move to Poughkeepsie. To make matters worse, several of the most knowledgeable CP people who did go to Poughkeepsie, including privates Newson and Per Jonas, were put into a separate group whose purpose was to build a tool that could be used for the development of MVS-XA. Pete Tallman, of VMA fame, also joined what came to be known as the ``VM Tool'' project as soon as it moved to Poughkeepsie. Starting with VM-370 Release 3, PLC 06, the VM Tool group began building a fast, stripped-down CP that would create XA virtual machines on a real 370 so that the MVS developers could test MVS-XA.

... snip ...

something similar happened with os-360 operating system virtual memory development ... the earlier os2-vs2 svs prototype work with MVT incorporating some of the cp67 virtual address space support was done on 360-67 ... and then moved to "virtual 370s" and much later "real 370s".

370 was originally announced w-o virtual memory support and 360 operating systems ran with very little changes.

however, one of the early uses of the internal network technology

was joint development project between the science center

and endicott to modify cp67 (running on 360-67) to provide 370 virtual machines (including support for 370 virtual memory architecture that had hardware tables different than what was defined for 360-67).

the initial set of updates were the "cp67-h" changes to a standard cp67 kernel that added 370 virtual machine option (to existing 360 & 360-67 virtual machine options). then there were a set of "cp67-i" changes (on top of the "cp67-h" changes) that change the kernel to run on 370 hardware.

now because 370 virtual memory support hadn't been announced, it was being treated as super corporate secret. complicated the matters was that the science center cp67 system was also providing service to various non-employee students (and others) at various educational insbreastutions in the boston area. so typical operation was

360-67 hardware standard "cp67-l" system running on 360-67 hardware providing 360 VMs "cp67-h" running in 360 virtual machine providing 360 & 370 VMs "cp67-i" running in 370 virtual machine providing 370 VMs CMS running in 370 virtual machine

as a countermeasure to accidental leakage about 370 virtual memory to the public.

cp67-h & cp67-i were in regular use a year before the very first engineering 370 with hardware virtual memory was reading for testing (a engineering 370-145 in endicott). in fact, booting cp67-i on the engineering 370-145 was one of the first tests of the virtual memory hardware support. as it turned out, the first boot failed. a little more examination showed that the hardware had reversed the op-codes in a couple of the new B2xx instructions ... while cp67-i had it correct. the cp67-i kernel was patched to correspond to the (wrong) hardware implementation and then booted succesfully.

there was a different problem leading up to 370 virtual memory announcement. pok engineers had to design virtual memory hardware retro-fit for 370-155 and 370-165 machines. they were falling something like six months behind. finally there was an escalation meeting in POK, where the 165 engineers said that if they could eliminate some of the new features defined for 370 virtual memory they could pickup six months ... and allow 370 virtual memory to be announced six months earlier. there was a decision to drop the additional features ... and other models that had already done their implementations had to drop the features.

one of the features dropped was shared segment protection (different than the 360 storage key protection). cms had been reworked to take advantage of the feature (i.e. different virtual address spaces could share the same physical pages in real memory and enforce storage alteration protection). as a result, cms had to revert to a real gludge using 360 storage key protect for different virtual address spaces sharing the same physical pages.

a few old posts mentioning cp67-h and cp67-i work supporting 370 virtual memory. System-390 - do we need it? than modern crap ! virtualization in general boundaries and NonStop OS ? DISAPPOINTMENT

a few old posts mentioning the 165 schedule delays resulting in dropping 370 virtual memory features in order to catchup. not 32 bit? Parity - why even or odd) Microcoded Microcoded Microcoded Microcoded above the line boundaries Bits: what does it really mean? in S-370