Alan Altmark writes:
> It depends on your definition of of "operating system". The classical
> definition is the chunk of software that manages the real system
> resources, allocating them to application programs. That is, the
> gatekeeper for access to the CPU, memory, and I/O devices. That would
> be, again classically, just BCP: the thing that holds the SVCs.
>
> Of course, as computing has gotten more sophisticated (has it?) the
> definition has become far more complex. Is JES *really* part of the
> operating system? Or is it just an application with the same
> privileges as the operating system itself? Hmmmm.... What about apps
> that run authorized only for performance reasons? Are they part of
> the OS? There must be a PhD dissertation on this *somewhere* out
> there.... ;-)
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-passing 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
passing 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 passing paradigm between applications and real kernel
services) and csa taking five megabytes (allowing pointer passing
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 passing paradigm
http://www.garlic.com/~lynn/2006b.html#25 Multiple address spaces
http://www.garlic.com/~lynn/2006b.html#28 Multiple address spaces
http://www.garlic.com/~lynn/2006b.html#32 Multiple address spaces
http://www.garlic.com/~lynn/2006i.html#33 virtual memory
http://www.garlic.com/~lynn/2006j.html#38 The Pankian Metaphor
http://www.garlic.com/~lynn/2006k.html#44 virtual memory
for a somewhat different take ... the vm370 had spool file operation
embedded in the kernel. as mentioned in this posts:
http://www.garlic.com/~lynn/2006e.html#36 The Pankian Metaphor
http://www.garlic.com/~lynn/2006k.html#51 other cp/cms history
http://www.garlic.com/~lynn/2006o.html#64 The Fate of VM - was: Re: Baby
MVS???
i was running into severe thruput bottleneck with the vm spool file
implementation in conjunction with the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet
and our high-speed backbone (part of our hsdt project)
http://www.garlic.com/~lynn/subnetwork.html#hsdt
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).
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
