Where should the type information be: in tags and descriptors 464

it depends when you are tallking about ... late 70s and continuing into the 80s, there was increasing bloat ... with more and more code migrating to the fixed kernel. also you have to consider the "working set" sizes of the applications that were also bloating (less & less space for paging because of fixed kernel requirements and larger and larger working set sizes as applications bloated).

original cp-40 with cms ran on 256k 360-40 (custom modified with virtual memory hardware) supporting multiple cms users. cp-40 then morphed into cp-67 with the availability of 360-67

here is some paging and and storage size benchmark from '68 ... where i artificially would reduce amount of pageable real memory

cp-67 fixed kernel size continued to grow over time. part of the issue was people from traditional operating system viewed the kernel as the place to implement function ... as opposed to the baseic cp-67 premise of being a hypervisor-microkernel.

the summer of '68 plus 1, i did a stint at recently formed BCS and started fealing that the kernel size was getting out of hand. As part of that i created the pageable kernel paradigm (which was not shipped as part of cp-67 ... but was picked up later for vm-370). The implementation didn't use virtual memory ... it just moved 4k hunks of kernel code to&from memory & disk.

In order to do it, I had to facture some number of low-useage routines that were much larger than 4k. One was console functions. Previously console functions had been one large module (with internal address constant pointers). With the fracture, the command lookup was in fixed kernel ... but most of the actual console command handling code was split out into individual routines (each less than 4k and package on 4k boundaries).

CP67 and CMS shipped effectively everything as source ... except for a modified BPS loader that was used for kernel initialization. The BPS loader still contained a limit of 256 entry symbols-points. With the facture of routines for 4k page packaging ... a lot of new entry symbolds were introduced which drive the total number of cp67 ESD entries over 256 ... causing the modified BPS loader to fail ... and you could no longer initialize the kernel. This caused me quite a fit.

In any case, by the end of the cp67 cycle ... I don't remember any 256k 360-67 still being used. Then there was the morph to vm-370. I don't remember the release 1 customers ... but I do remember being called down to NYC to a nowegian shipping company that was trying to get vm-370 running on a 256kbyte 370-125 ... and having huge difficulties. I did several things to (late release 2?) vm-370 fixed kernel to get it back comperable to cp67 kernel (aka under 100k bytes).

as i mentioned in the recent xt370 post ...

the original xt-370 going to ship with 384k (370) memory ... which was to hold both fixed kernel as well as all application paging. Benchmarking that I did on the machine showed almost everything you wanted to do resulted in some kind of page thrashing. The page thrashing was exacerbated by all I-O operations were handed off to CP-88 monitor ... running on dos which in turned translated it to dos i-o to a 100ms-operation hard disk.

on a real mainframe ... there were much faster hard disks ... and for big operations ... you could have large multi-block transfers ... which tended to mitigate human factor perception related to latencies.

Almost any interactive thing you might try and the xt370 side ... tended to compare very poorly with similar application designed specific for the resources available in typical dos environment.

--