Historical curiosity question

[Anne & Lynn Wheeler]

This is not important, but I just have to ask this. Does anybody know
why the original designers of VM did not do something for "minidisks"
akin to a OS/360 VTOC? Actually, it would be more akin to a "partition
table" on a PC disk. It just seems that it would be easier to maintain
if there was "something" on the physical disk which contained
information about the minidisks on it. Perhaps with information such
as: start cylinder, end cylinder, owning guest, read password, etc. CP
owned volumes have an "allocation map", this seems to me to be an
extention of that concept.

CP67 had a global directory ... that was indexed and paged ... so it
didn't need individual volume index.

it also avoided the horrendous overhead of multi-track search that
os/360 used to search the volume VTOC on every open. lots of past
posts mentioning multi-tract paradigm for VTOC & PDS directory was
io/memory trade-off ... os/360 target in the mid-60s was to burn
enormous i/o capacity to save having in-memory index.
http://www.garlic.com/~lynn/subtopic.html#dasd

that resource trade-off had changed by at least the mid-70s ... and
it wasn't ever true for the machine configurations that cp67 ran on.

the other characteristic was that both cp67 and cms treated disks as
fixed-block architecture ... even if they were CKD ... CKD disks would
be formated into fixed-blocks ... and then treated as fixed-block
devices ... and avoid the horrible i/o performance penalty of ever
doing multi-track searches for looking up location and/or other
information on disk.

recent thread in bit.listserv.ibm-main
http://www.garlic.com/~lynn/2007e.html#35 FBA rant
http://www.garlic.com/~lynn/2007e.html#38 FBA rant
http://www.garlic.com/~lynn/2007e.html#39 FBA rant
http://www.garlic.com/~lynn/2007e.html#40 FBA rant
http://www.garlic.com/~lynn/2007e.html#42 FBA rant
http://www.garlic.com/~lynn/2007e.html#43 FBA rant
http://www.garlic.com/~lynn/2007e.html#46 FBA rant
http://www.garlic.com/~lynn/2007e.html#51 FBA rant
http://www.garlic.com/~lynn/2007e.html#59 FBA rant
http://www.garlic.com/~lynn/2007e.html#60 FBA rant
http://www.garlic.com/~lynn/2007e.html#63 FBA rant
http://www.garlic.com/~lynn/2007e.html#64 FBA rant
http://www.garlic.com/~lynn/2007f.html#0 FBA rant
http://www.garlic.com/~lynn/2007f.html#2 FBA rant
http://www.garlic.com/~lynn/2007f.html#3 FBA rant
http://www.garlic.com/~lynn/2007f.html#5 FBA rant
http://www.garlic.com/~lynn/2007f.html#12 FBA rant

the one possible exception was loosely-coupled single-system-image
support done for HONE system. HONE mini-disk volumes had an in-use
bitmap directory on each volume ... that was used to manage "LINK"
consistency across all machines in the cluster. it basically used
a channel program with search operation to implement i/o logical
equivalent to the atomic compare&swap instruction ... avoiding having
to do reserve/release with intervening i/o operations. I have some
recollection talking to the JES2 people about them trying a similar
strategy for multi-system JES2 spool allocation. post from above
mentioning HONE "compare&swap" channel program for multi-system
cluster operation
http://www.garlic.com/~lynn/2007e.html#38 FBA rant

HONE was vm-based online interactive for world-wide sales, marketing,
and field people. It originally started in the early 70s with a clone
of the science center's cp67 system
http://www.garlic.com/~lynn/subtopic.html#545tech

and eventually propogated to several regional US datacenters ... and
also started to propogate overseas. I provided highly modified cp67
and then later vm370 systems for HONE operation for something like 15
yrs. I also handled some of the overseas clones ... like when EMEA
hdqtrs moved from the states to just outside paris in the early 70s.
In the mid-70s, the US HONE datacenters were consolidated in northern
cal. ... and single-system-image software support quickly emerge
... running multiple "attached processors" in cluster operation. HONE
applications were heavily APL ... so it was quite compute intensive.
With four-channel controllers and string-switch ... you could get
eight system paths to every disk. Going with "attached processors"
... effectively two processors made use of a single set of channels
... so you could get 16 processors in single-system-image ... with
load-balancing and failure-fallover-recovery.

Later in the early 80s, the northern cal. HONE datacenter was
replicated first in Dallas and then a third center in Boulder ... for
triple redundancy, load-balancing and fall-over (in part concern about
natural disasters like earthquakes).

lots of past posts mentioning HONE
http://www.garlic.com/~lynn/subtopic.html#hone

At one point in SJR after the 370/195 machine ... recent reference
http://www.garlic.com/~lynn/2007f.html#10 Beyond multicore
http://www.garlic.com/~lynn/2007f.html#11 Is computer history taught now?
http://www.garlic.com/~lynn/2007f.html#12 FBA rant

was replaced with mvs/168 system ... and vm was running on 370/158 ...
there were multiple strings of 3330 dasd ... with whole strings supposedly
dedicated to vm and other strings dedicated to mvs. there were "rules"
that mvs packs should never be mounted on vm "strings" (because of the
horrendous vtoc & pds directory multi-track search overhead hanging
channel, control units, string switches, and drives).

Periodically it would happen .. in specific instances ... users would be calling
the operator within five minutes claiming vm/cms interactive response and totally
deteriorated. Then it would require tracking down the offending MVS pack.
One of the events, the MVS operator refused to take down the pack and move it ...
because some long running application had just started. So to give them a
taste of their own medicine ... we brought up a highly optimized VS1 system
in a virtual machine on the (loaded) vm/158 with a couple packs on MVS string
and proceeded to start some operations that brought MVS to its knees ...
drastically inhibiting the long running MVS application from getting any useful
thruput (and effectively negating its debilitating effect of vm/cms interactive
response). The MVS operator then quickly reconfigured everything and aggreed
that MVS would keep its packs off VM disk strings.

some old posts retelling the sjr mvs/168 and vm/158 response story:
http://www.garlic.com/~lynn/94.html#35 mainframe CKD disks & PDS files (looong... warning)
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002d.html#22 DASD response times
http://www.garlic.com/~lynn/2002f.html#8 Is AMD doing an Intel?
http://www.garlic.com/~lynn/2002l.html#49 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2003.html#15 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003b.html#22 360/370 disk drives
http://www.garlic.com/~lynn/2003c.html#48 "average" DASD Blocksize
http://www.garlic.com/~lynn/2003f.html#51 inter-block gaps on DASD tracks
http://www.garlic.com/~lynn/2003k.html#28 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2003m.html#56 model 91/CRJE and IKJLEW
http://www.garlic.com/~lynn/2003o.html#64 1teraflops cell processor possible?
http://www.garlic.com/~lynn/2004g.html#11 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#51 Channel busy without less I/O
http://www.garlic.com/~lynn/2004l.html#20 Is the solution FBA was Re: FW: Looking for Disk Calc
http://www.garlic.com/~lynn/2004n.html#52 CKD Disks?
http://www.garlic.com/~lynn/2005r.html#19 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005u.html#44 POWER6 on zSeries?
http://www.garlic.com/~lynn/2006s.html#15 THE on USS?

[Anne & Lynn Wheeler]

The mini disk is an imperfect (but cheap) implementation of a low
level abstraction. The main "defect" is the number of cylinders, but
for many purposes the virtualization is good enough because the guest
can live with that.
But at considerable additional cost, VM could have been designed to
span a mini disk over multiple volumes. With such support, you could
give out more perfect 3390's (i.e. not being restricted by the actual
models on the hardware). And VM could have played tricks not to
allocate real disk space for unused tracks. This is exactly what was
done in the RAMAC Virtual Array.

re:
http://www.garlic.com/~lynn/2007f.html#20 Historical curiosity question

some long winded topic drift ...

as undergraduate i had done a lot of modifications to the cp67 kernel
... a lot oriented towards significantly improving pathlength for
os360 guest virtual machines, new resource management algorithms, and
dynamic adaptive resource control.

I had also looked at doing some stuff for CMS ... one of the things I
realized that CMS was simulating the operation of doing syncronous
disk transfers with overhead of sio/lpsw-wait/interrupt paradigm. so i
defined a new CCW opcode that would do syncronous disk transfers
... and the virtual machine would get back CC=1, csw stored on the SIO
operation ... indicating the operation had already completed.

This i got somewhat slammed on by the people at the science center as
having violated 360 machine architecture and principles of
operation. Eventually it was explained that it would be possible to
use the 360 "DIAGNOSE" instruction to implement such "violations"
... since the principles of operation defined the DIAGNOSE instruction
implementation as model dependent. Define an abstract 360/"virtual
machine" model and the way that the DIAGNOSE instruction work for that
"model". However, the pathlength improvement for the change was pretty
significant ... so the syncronous disk transfer operation was
eventually re-implemented with DIAGNOSE instruction.

Later when I joined the science center ... one of the things that i
did for cp67/cms (that never shipped in the product) was the cp67 and
cms changes to support page-mapped filesystem operation. This
was combined in general set of stuff that I referred to as virtual
memory management. Later it was some of the stuff that was ported
to vm370 ... old communication with reference
http://www.garlic.com/~lynn/2006v.html#email731212

a small subset of the virtual memory management stuff made it out in
vm370 as DCSS (but not the page mapped filesystem stuff or a lot of
other stuff) ... recent post
http://www.garlic.com/~lynn/2007f.html#14 more shared segment archeology

Note that even with the DIAGNOSE operation there was still a lot of
overhead related to emulated channel programs that require real
addresses for execution (shadows of the virtual channel program
created with real addresses of the virtual pages which have been
pinned in real storage). This is not only true for virtual machine
emulation ... but anything that has applications building channel
programs in a virtual address space. For reference, posts about
originaly prototype OS/360 to VS2 virtual memory operation by
hacking a copy of cp67's CCWTRANS into the side of MVT (to create
translated, shadow channel programs with real address and pinned
virtual pages)
http://www.garlic.com/~lynn/2007e.html#19 Cycles per ASM instruction
http://www.garlic.com/~lynn/2007e.html#27 IBM S/360 series operating systems history
http://www.garlic.com/~lynn/2007e.html#46 FBA rant
http://www.garlic.com/~lynn/2007f.html#0 FBA rant
http://www.garlic.com/~lynn/2007f.html#6 IBM S/360 series operating systems history

so the page mapped filesystem support, changes to both cp67 to provide
the DIAGNOSE instruction API) and changes to low-level CMS filesystem
function to use the cp67 API (pretty much leaving the high-level CMS
filesystem interfaces "as-is") ... eliminated most of the rest of this
channel program translation overhead gorp. It also moved the CMS disk
paradigm interface even beyond the simplifications possible with FBA
disks.

Having drastically simplified the disk paradigm interface ... the
implementation of a lot of other features became significantly easier.
For instance, it was possible to dynamically adjust how requested page
transfers were actually performed being able to dynamically do either
syncronous transfers and/or even asyncronous transfers (transparent to
the syncronous CMS virtual machine paradigm by fiddling the page
invalid bits).

The simple, original implementation just mapped a set of contiguous
page records ... to contiguous cylinders supported leveraging existing
minidisk definitions. However, it also become extremely
straight-forward to do other types of enhancements (having removed the
binding for the cms virtual machine to explicit ckd disk hardware
characteristics), like having multiple sequentially chained blocks of
pages ... at discontiguous locations on the same or different disks
... emulated a single set of (contiguous) page records (aka enabling
relatively trivial implementation support for various kinds of
cms filesystems spanning multiple disks).

A lot of this is analogous to the features that showed up in more advance
controllers and the logical volume manager (LVM for unix systems being
able to specify filesystems as possibly multiple discontiguous groups
of records ... either as concatenated discontiguous allocation or
various kinds of RAID operation).

lots of past posts mentioning (cms filesystem) page mapped work
http://www.garlic.com/~lynn/subtopic.html#mmap

I also later leveraged the kernel diagnose API for page mapping to do
a prototype implementation that moved the cp spoolfile system into a
virtual address space. part of it was I needed to speed up spool file
thruput for the vnet/rscs virtual machine by a couple orders of
magnitude to correspond with the high-speed backbone work ... misc
posts
http://www.garlic.com/~lynn/subnetwork.html#hsdt

and misc. pasts posts mentioning the spool file system prototype
work
http://www.garlic.com/~lynn/2000b.html#43 Migrating pages from a paging device (was Re: removal of paging device)
http://www.garlic.com/~lynn/2001n.html#7 More newbie stop the war here!
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2003b.html#33 dasd full cylinder transfer (long post warning)
http://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format (long post)
http://www.garlic.com/~lynn/2003b.html#46 internal network drift (was filesystem structure)
http://www.garlic.com/~lynn/2003g.html#27 SYSPROF and the 190 disk
http://www.garlic.com/~lynn/2003k.html#26 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2003k.html#63 SPXTAPE status from REXX
http://www.garlic.com/~lynn/2004g.html#19 HERCULES
http://www.garlic.com/~lynn/2004m.html#33 Shipwrecks
http://www.garlic.com/~lynn/2004p.html#3 History of C
http://www.garlic.com/~lynn/2005d.html#38 Thou shalt have no other gods before the ANSI C standard
http://www.garlic.com/~lynn/2005j.html#54 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005j.html#58 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005n.html#36 Code density and performance?
http://www.garlic.com/~lynn/2005s.html#28 MVCIN instruction
http://www.garlic.com/~lynn/2005s.html#46 Various kinds of System reloads
http://www.garlic.com/~lynn/2005s.html#50 Various kinds of System reloads
http://www.garlic.com/~lynn/2006.html#35 Charging Time
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???
http://www.garlic.com/~lynn/2006p.html#11 What part of z/OS is the OS?
http://www.garlic.com/~lynn/2006q.html#27 dcss and page mapped filesystem
http://www.garlic.com/~lynn/2006s.html#7 Very slow booting and running and brain-dead OS's?
http://www.garlic.com/~lynn/2006t.html#45 To RISC or not to RISC
http://www.garlic.com/~lynn/2007c.html#21 How many 36-bit Unix ports in the old days?

[Anne & Lynn Wheeler]

e:
http://www.garlic.com/~lynn/2007f.html#20 Historical curiosity question
http://www.garlic.com/~lynn/2007f.html#33 Historical curiosity question

"full-pack" minidisk footnote.

moving to fba-like devices ... you tend to have the device returning the number of
records on the device ... it eliminates the tight binding between device geometry
and other characteristics that have been part of the CKD device paradigm.

the place where (ckd) full-pack minidisks came into play was with applications
doing dynamic channel program modifications. they wouldn't actually be modifying the
channel program instructions but they could be dynamically modifying the
seek ccw channel program argument. CCWTRANS had to "shadow" the channel
program instructions in order to convert virtual address to real address
as part of executing the channel program. CCWTRANS would also shadow
seek ccw arguments ... converting virtual (cylinder/track) seek arguments to
"real" seek arguments. Minidisks that didn't start at real location zero
had the seek arguments appropriately incremented ... and minidisks that
didn't extend to end of device ... might have seeking past end of device
simulated for some seek argument. For full-pack minidisks (and/or dedicated
devices) ... the conversion/translation of seek arguments could be eliminated
(with the seek CCW pointing at the virtual seek argument in the the virtual machine
virtual address space ... instead of a shadow translated value).

This showed up with running ISAM in a virtual machine ... where the ISAM channel
programs could be dynamically modifying seek arguments. w/o full-pack minidisks
... the dynamic modification would be with respect to the copy in virtual machine
virtual memory ... and not the translated version that the shadow seek CCW was
pointing to. With full-pack minidisks (and/or dedicated devices), the shadow
seek CCW could be pointing at the copy in virtual memory (rather than a translated
copy) ... that potentially is the target of some read CCW possibly doing dynamic
seek argument modification.

recent posts mentioning "self-modifying" ISAM channel program:
http://www.garlic.com/~lynn/2007e.html#14 Cycles per ASM instruction
http://www.garlic.com/~lynn/2007e.html#19 Cycles per ASM instruction
http://www.garlic.com/~lynn/2007e.html#27 IBM S/360 series operating systems history
http://www.garlic.com/~lynn/2007f.html#4 ISAM and/or self-modifying channel programs