Mark H. Young wrote:
Seymour, was SVS and/or VS1 what you ran on a 360 or 370 processor with a
DAT box? Or did MVT or MFT run native on those systems with a DAT box?
SVS prototype started out as adding virtual tables and CCWTRANS (from cp67) cut
into the side of MVT ... with otherwise minimumal changes to how MVT otherwise
operated (i.e. minimum amount of work and effort to get MVT running with
virtual memory turned on). So nearly all EXCP channel programs had to get
translated via CCWTRANS ... very much as if MVT was running in virtual machine.
Lots of MVT kernel was fixed so that kernel code didn't have to worry about
page faults. Application page faults were handled at very low level with
least amount of disturbance to the application ... again almost as if MVT
was running in a virtual machine. Recent post mentioning Ludlow working
on SVS prototyping ... somewhat hacking various pieces from CP67 into
MVT kernel.
http://www.garlic.com/~lynn/2007e.html#27 IBM S/360 series operating systems
history
so you could sort of say that MVT ran native with a DAT box with a bunch of
stuff
from CP67 hacked into the MVT kernel ... but they changed its name to SVS.
Something similar but different had been done earlier to MVT by some customers
... but running in virtual machine under CP67 called "hand shaking" ... CP67 would
present a page fault interrupt to MVT under certain conditions
(i.e. virtual problem state, non-key-zero) ... which allowed MVT to perform
a task-switch. Later when missing page had been fetch ... MVT would be
presented a new kind of interrupt as indication that missing page was
now in real storage.
Later the VM370 and VS1 would have similar modifications as part of VS1
"handshaking"
support. In this case, something like a 4mbyte virtual machine would be defined
for VS1. VS1 would then build a 4mbyte virtual address space table ... where
there
was a one-for-one mapping between each VS1 virtual page and the virtual machine
page. In effect, VS1 would no longer have any paging responsibility ... having
turned it all over to the VM370 kernel. VM370 would present page interrupt
to VS1, allowing VS1 to perform task switch ... while waiting for vm370
to perform the page operation. when the page operation was complete, vm370
would present a psuedo page i/o complete interrupt to vs1. For a lot of
workloads ... this (and misc. other stuff) allowed VS1 to run faster in a
vm370 virtual machine than it did running directly on the hardware w/o vm370
... at least on processors with the ECPS VM microcode assists (started with
370 138s & 148s) ... old post discussing ECPS
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
There actually had been an earlier modification to MVT release 13 done by
Boeing Huntsville running on 360/67 SMP ... (I believe partitioned running
as two uni-processors). MVT had virtual address space the same size as
real storage (slightly analogous to the VS1 configuration) ... and did no
paging and/or page fault operations. The issue was to handle storage fragmentation.
MVT had horrendous problem with storage fragmentation ... especially with
long running applications. Boeing Huntsville machines were primarily being
used for long-running 2250 display/design applications ... would would
experience large amounts of storage fragmentation. The use of virtual
address space ... wasn't to make it look like there was more memory
than really available ... but to re-arrange storage locations to appear
contiguous. recent posting mentioning Boeing Huntsville hack to MVT-13.
http://www.garlic.com/~lynn/2007b.html#45 Is anyone still running
----------------------------------------------------------------------
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
