Behavior in undefined areas

I've told the story about the joint cambridge

endicott project for the cp67 H&I kernels. Basically the "H" cp67 updates were to create virtual machines that conformed to the 370 architecture definition (instead of 360-67 definition). The "I" cp67 updates were for the cp67 kernel to run on a 370 architecture.

In regular use was

CP67-L on real 360-67 providing 360-67 virtual machines CP67-H in 360-67 virtual machine providing 370 virtual machines CP67-I in 370 virtual machine providing 370 virtual machines CMS in 370 virtual machine

a year before the first 370-145 engineering machine was running.

when endicott finally got a 370-145 engineering machine with virtual memory hardware support running ... they wanted to have a copy of CP67-I kernel to validate the hardware operation.

So the kernel was booted on an engineering machine that had soemthing like a knife switch in lieu of a real "IPL" button ... and it failed. After some diagnostics ... it turned out that the engineers had implemented two of the new extedd "B2" opcdoes reversed.

Normal 360 instruction opcodes are one byte ... 370 introduced new "B2" opcodes ... where the 2nd byte is actually the instruction opcode. Some vague recollection was that the reversed "B2" opcodes were RRB (resert reference bit) and PTLB (purge table lookaside buffer). The kernel was then quickly patched to correspond to the (incorrect) engineering implementation and the rest of the tests ran fine.

the "L", "H", "I" designations come somewhat from the initial pbutt at doing multi-level source update system was being built to support the effort. this initial pbutt was hierarchical ... so "L" updates were applied to the base source, then the "H" updates could be applied, and then "L" source updates. recent multi-level source update posting

in the vm-370 release 3 time-frame, one of the vm370 product test people had developed an instruction end regression program to test vm370 compliance. however, running the full test suite would actually cause vm370 crash. in that time frame ... I got pegged to release a bunch of my system enhancements as the "resource manager"

we developed an automated benchmarking process where we could define arbitrary workloads and configurations for validating and calibrating the resource manager ... eventually we did a series of 2000 benchmarks that took over 3 months elapsed time

however ... leading up to that effort ... we found a number of defined workloads (extreme conditions) that also would reliably crash the kernel. so i undertook an effort to rewrite sections of the kernel to eliminate all the kernel failures by either our benchmark test or the instruction end regression program that the guy in product test had. these changes were also included as part of the released "resource manager" changes.

misc. past h-i postings:

--