Moving buttembler programs above the line 508

note that this was further aggrevated by smp support. the gimick with allowing cms with shared segments to be run with the 158-168 microcode buttist ... effectively involved the ruse that the "protected" pages became private for the duration of the running task ... and then the scan would revert any modified pages to their original, unmodified version (paged in from disk).

smp allowed multiple tasks to run concurrently with the same shared segments ... so it was no longer possible to maintain the ruse that the pages were private to the task running (a 2-way processor might have two virtual machines concurrently referencing the same virtual pages).

the smp stuff that i had done maintained the pre-release3 gimick of playing games with storage protection keys

besides the vamps implementation

where it was possible to modify the microcode to support the original shared segment protection ... i also deployed the smp support (with key protect hack) on the hone systems:

hone was the internal vm-based (originally started with cp67) time-sharing service that eventually was used to support all world-wide marketing, sales, and field activities.

so there was two hacks for shipping smp to customers ... one was that that much of the smp implementation was based on code in the resource manager

and the other was creating replicated shared segment pages, one for each processor in an smp configuration (that continued the "protection" ruse of scanning shared pages for changes at task switch times).

as previously mentioned ... the smp support issue with the resource manager had to do with priced software. Up until the resource manager, application software was priced, but kernel software was free. The resource manager was chosen as guinea pig for pricing kernel software. I got to work with the business people one and off over six month period working on business practices for pricing kernel software. The guidelines that were come up with was that kernel software not directly involved in supporting hardware could be priced (i.e. nominally the resource manager had improved scheduling algorithms and so was not considered directly required for hardware support).

the problem with shipping smp support ... was that it was obviously directly needed for hardware support ... and therefore had to be free; however, if it had a prereq of the resource manager ... that violated the business practices. the solution (for shipping the smp code) was to remove 80-90 percent of the code from the original resource manager (that was required for smp support) and incorporate it into the "free base".

ok, so why couldn't the scanning of shared pages (at task switch) just be dropped? ... and the system revert to the protection hack based on storage protection keys.

well, the vm microcode buttist for 168 cost something like $200k. customers that were guest operating system intensive bought the buttist because it improved the performance of their guest operating system (svx, vs1, mvt, etc). leading up to release 3 ... a number of cms intensive shops were told that now vm microcode buttist would enhance their performance also ... and it would be worthwhile spending the $200k on the buttist (even tho by the time the support had shipped, the number of shared pages to be scanned had at least doubled and the performance trade-off comparison numbers were no longer valid).

In any case, it was considered too much of a gaffe to go around and tell all the CMS-intensive shops who had bought the 168 microcode buttist that it wasn't worth it ... and VM was dropping support (reverting to the key protection hack).

--