33803390 Conversion DISAPPOINTMENT

cp-67 on 360-67 had to translate ccws from the virtual machine ... and use data-chaining where the virtual machine CCW virtual data address was contiguous ... but the virtual pages from the virtual machine were scattered around memory.

moving to 370, IDALs were provided in lieu of data-chaining to break up virtual contiguous areas into non-contiguous pages. part of this is that the standard channel architecture precluded pre-fetching CCWs (they had to be fetched and executed syncronously). on 360, breaking a single ccw into multiple (data-chaining) CCWs introduced additional latencies that could result in timing errors. on 370, non-contiguous areas could be handled with IDALs ... and channel architecture allowed prefetching of IDALs ... supposedly eliminating the timing latencies buttociated that could happen with data-chaining approach.

This issue of channels working with real addresses necessitating CCWs built with virtual address ... to be translated to a shadow set of CCWs with real addresses ... affects all systems operating with virtual memory (which support applications building CCWs with virtual memory addresses ... including the virtual address space area may appear linear ... but the corresponding virtual pages are actually non-contiguous in real memory).

The original implementation of os-vs2 was built using standard MVT with virtual address space tables and page interrupt handler hacked into the side (for os-vs2 svs ... precursor to os-vs2 mvs ... since shorten to just mvs). It also borrowed CCWTRANS from cp-67 to translate the application CCWs (that had been built with virtual addresses) into "real" CCWs that were built with real addresses for real end.

This version of CCWTRANS had support for IDALs for running on 370s.

Typically, once MVS had shadowed the application CCWs ... creating the shadow CCWs with IDALs giving the non-contiguous page addresses ... then any VM translation of the MVS translated CCWs was strictly one-for-one replacement ... an exact copy of the MVS set of translated CCWs ... which only differed in the real, real address spacified.

all the virtual machine stuff and cp67 had been developed by the science cneter

there was a joint project between cambridge and endicott to simulate virtual 370s under cp67 running on real 360-67 (for one thing the 370 virtual memory tables had somewhat different hardware definition, the control register definitions were somewhat different, there some different instructions, etc).

the base production system at cambridge was referred to as cp67l. the modifications to cp67 to provide 370 virtual machines (as an alternative option to providing 360 virtual machines) was referred to as cp67h. Then further modifications were made to cp67 for the kernel to run on real 370 (using 370 hardware definitions instead of 360 hardware definitions). This cp67 kernel that ran "on" 370 hardware was referred to as cp67i. cp67i was running regularly in production virtual machine a year prior to the first engineering 370 model with virtual memory hardware became available (in fact, cp67i was used as a validation test for the machine when it first became operational).

cms multi-level source update Debt Management was developed in support of cp67l-cp67h-cp67i set of updates.

also, the cp67h system ... which could run on a real 360-67, providing virtual 370 machines ... was actually typically run in a virtual 360-67 virtual machine ... under cp67l on the cambridge 360-67. This was in large part because of security concerns since the cambridge system provided some amount of generalized time-sharing to various univ. people in the cambridge area (mit, harvard, bu, etc). If cp67h was hosted as the base timesharing service ... there were all sorts of people that might trip over the unannounced 370 virtual memory operation.

about the time some 370s (145) processors became available internally (still long before announcement) a couple engineers came out from san jose and added the device support for 3330s and 2505s to the cp67i system (including multi-exposure support, set sector in support of rps). also idal support was crafted into CCWTRANs. part of the issue was that the channels on real 360-67s were a lot faster and had lot lower latency ... so there were much fewer instances where breaking a single CCW into multiple data-chained CCWs resulted in overruns. However, 145 channel processing was much slower and required (prefetch'able) IDALs to avoid a lot of the overrun situations.

a few past posts mentioning cp67l, cp67h, and cp67i activity: listings System-390 - do we need it? future virtualization in general boundaries cp67 and NonStop OS ? caches

misc. past posts mentioning cp-67 CCWTRAN needed for a computer to Love? Re: Itanium benchmarks ... instructions (was Re: Did Intel Bite Off More Than It Can Chew?) Hardware operating systems operating systems Was Re: Yamhill nothing". Re: Multics Concepts For multi-programming before the invention of the PC? interconnect addressing survey above the line above the line Idea volsers