🚀 go-pugleaf

John Levine <jo...@taugh.com> writes:
> I read somewhere that someone put handshake code in OS/MFT so that if
> it were running under VM\/370, when it page faulted CP would send a
> virtual interrupts to MFT so it could switch tasks rather than
> waiting.  This got the effect of VS1 but with a competent virtual
> memory system, and the option to run other stuff under VM.

re:
http://www.garlic.com/~lynn/2018.html#91 Honeywell 200
http://www.garlic.com/~lynn/2018.html#92 S/360 addressing, not Honeywell 200

from Melinda's VM History:

Dewayne Hendricks(109) reported at SHARE XLII, in March, 1974, that he
had successfully implemented MVT-CP handshaking for page faulting, so
that when MVT running under VM took a page fault, CP would allow MVT to
dispatch another task while CP brought in the page.  At the following
SHARE, Dewayne did a presentation on further modifications, including
support for SIOF and a memory-mapped job queue.  With these changes, his
system would allow multi-tasking guests actually to multi-task when
running in a virtual machine.  Significantly, his modifications were
available on the Waterloo Tape.

Dewayne became the chairman of the Operating Systems Committee of the
SHARE VM Project.  Under his guidance, the Committee prepared several
detailed requirements for improvements to allow guest systems to perform
better.  At SHARE XLV, in 1975, the Committee presented IBM with a White
Paper entitled Operating Systems Under VM/370,(110) which discussed the
performance problems of guests under VM and the solutions that customers
had found for these problems.  Many of the solutions that Dewayne and
others had found, such as PAGEX, made their way into VM fairly quickly,
apparently as the result of customers' persistence in documenting them.
By SHARE 49, Dewayne was able to state that, "It is now generally
understood that either MFT or MVT can run under VM/370 with relative
batch throughput greater than 1."(111) That is to say, they had both
been made to run significantly faster under VM than on the bare
hardware.  Dewayne and others did similar work to improve the
performance of DOS under VM.  Other customers, notably Woody Garnett and
John Alvord, soon achieved excellent results with VS1 under VM.

... snip ...

Endicott added VM/370 PAGEX & VS/1 Handshanking along with ECPS ...
http://www.garlic.com/~lynn/94.html#21 370 ECPS microcode assist

Endicott even tried to get corporate to agree to having VM/370 preinstalled on
every 138/148 shipped (sort of like LPAR does today) ... but this was in
period when POK was convincing corporate to kill VM/370 product and
transfer all people to POK to support MVS/XA development (or otherwise
MVS/XA wouldn't ship on time 7-8 yrs later). Eventually Endicott
managed to rescue the VM/370 product mission ... but had to recreate
a VM/370 development group from scratch.

Note VS1 under VM/370 could run faster than on stand alone machine.
Part of VS1 running faster under VM/370 was VS1 still used 370 2kbyte
pages (option used to better squeeze into small real storage machines)
... as hardware scaleup there was much larger real storage and the
trade-off of 2k versus 4k pages was overhead of 2k paging was greater
than any benefit for squeezing into small real storage. The other was my
page replacement algorithm in VM/370 was much more efficient than the
page replacement algorithm in VS/1. page replacement posts
http://www.garlic.com/~lynn/subtopic.html#wsclock

Part of MVT running faster under (originally CP/67 and then) VM/370 was
the same justification for all 370s moving to virtual memory ...
i.e. MVT very poor application storage management ... requiring regions
to be four times larger than actually used (extreme storage
fragmentation and needing lots of contiguous addressing) ... virtual
memory allowed to have much larger address space (than real storage),
being able to have four times the regions (concurrent applications and
larger multiprogramming level allowing more activity overlapped waiting
for I/O) ...  also referenced in upthread, previous post
http://www.garlic.com/~lynn/2011d.html#73 Multiple Virtual Memory

for other drift ... at SJR ... after they upgraded the 370/195 to
370/168 for MVS and 370/158 VM/370 ... all (physically) sharing common
DASD pool ... but there was rule that certain 3830/3330
controller/strings were dedicated to MVS and others dedicated to VM370
... and MVS 3330s were not allowed to be mounted on VM370 strings.  One
day MVS operations violated the rule and almost immediately datacenter
was getting irate VM370/CMS user calls about enormously degraded CMS
interactive response. The issue was MVS extensive use of multitrack
search to the (mis-)mounted 3330 was interferring with VM370 I/O.
MVS operations said they wouldn't move the mis-mounted 3330 until
2nd shift.

Woody's VS1 3330 was mounted on MVS string, running under (heavily
loaded) VM370 (158) and some applications started ... even under heavily
loaded VM370 158 ... the VS1 multi-track searches were able to bring MVS
168 to its knees ... significantly slowing down the MVS activity
intererring with VM370 throughput and alleviating the degraded CMS
iteractive response. MVS operations then immediately agreed to move the
offending MVS 3330 off VM370 string. recent ref/post (in ibm-main
mailing list)
http://www.garlic.com/~lynn/2018.html#46 VSE timeline [was: RE: VSAM usage for ancient disk models]

CKD, FBA, multi-track search, etc posts
http://www.garlic.com/~lynn/submain.html#dasd

-- 
virtualization experience starting Jan1968, online at home since Mar1970