What part of zOS is the OS 4388

Alan Altmark writes:

so one of the motivation for original dual-address space ... was that lots of mvt services (like hasp-jes) ran outside the kernel ... but used the same pointer-pbutting paradigm as a "real" kernel service.

in the transition to mvs ... all the different things outside of the kernel got their own virtual address space ... this made pointer pbutting paradigm somewhat problematical for services running in a different address space. common segment was the initial solution ... but for larger 168 mvs shops ... it wasn't unusual to find the mvs kernel taking up 8mbytes of every virtual addresss space (preserving the pointer pbutting paradigm between applications and real kernel services) and csa taking five megabytes (allowing pointer pbutting paradigm to work between applications and services in different virtual address spaces). this was starting to put significant constraint on some applications ... leaving only maximum of 3mbytes out of every application virtual address space ... for actual application use.

access registers then generalized the dual-address space support introduced with the 3033.

a few posts this year mentioning common segment in support of pointer pbutting paradigm

for a somewhat different take ... the vm370 had spool file operation embedded in the kernel. as mentioned in this posts: MVS???

i was running into severe thruput bottleneck with the vm spool file implementation in conjunction with the internal network

and our high-speed backbone (part of our hsdt project)

so my take was to take the majority of the vm kernel spool file function, move it to a "service" virtual machine, re-code it in pascal-vs and increase the thruput by an order of magnitude ... eliminating many of its thruput constraints.

one of the long term issues with virtual machine hypervisor was the original code (from cp67) was very small, compact, and consistent. the early philosophy was that unless it couldn't absolutely be done any other way ... it didn't belong in the kernel. It was a highly efficient micro-kernel. The downside was that for people with more of a traditional operating system background ... they found the concise, compact implementation easy to understand and modify. The result was a tendency to take the easy way out and add new feature-function into the kernel code itself.

this met that w-o stringently enforced microkernel standards ... the micro-kernel tended to become extremely bloated, starting to resemble the kernels of more traditionally implemented operating systems ... becoming more and more bloating and much more difficult to maintain and modify (the ease of modification somewhat leading to its own downfall).