This is not important, but I just have to ask this. Does anybody knowwhy 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 "partitiontable" on a PC disk. It just seems that it would be easier to maintainif there was "something" on the physical disk which containedinformation about the minidisks on it. Perhaps with information suchas: start cylinder, end cylinder, owning guest, read password, etc. CPowned volumes have an "allocation map", this seems to me to be anextention of that concept.

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

it also avoided the horrendous overhead of multi-track search thatos/360 used to search the volume VTOC on every open. lots of pastposts mentioning multi-tract paradigm for VTOC & PDS directory wasio/memory trade-off ... os/360 target in the mid-60s was to burnenormous 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 ... andit wasn't ever true for the machine configurations that cp67 ran on.

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

the one possible exception was loosely-coupled single-system-imagesupport done for HONE system. HONE mini-disk volumes had an in-usebitmap directory on each volume ... that was used to manage "LINK"consistency across all machines in the cluster. it basically useda channel program with search operation to implement i/o logicalequivalent to the atomic compare&swap instruction ... avoiding havingto do reserve/release with intervening i/o operations. I have somerecollection talking to the JES2 people about them trying a similarstrategy for multi-system JES2 spool allocation. post from abovementioning HONE "compare&swap" channel program for multi-systemcluster operationhttp://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 cloneof the science center's cp67 systemhttp://www.garlic.com/~lynn/subtopic.html#545tech

and eventually propogated to several regional US datacenters ... andalso started to propogate overseas. I provided highly modified cp67and then later vm370 systems for HONE operation for something like 15yrs. I also handled some of the overseas clones ... like when EMEAhdqtrs moved from the states to just outside paris in the early 70s.In the mid-70s, the US HONE datacenters were consolidated in northerncal. ... and single-system-image software support quickly emerge... running multiple "attached processors" in cluster operation. HONEapplications were heavily APL ... so it was quite compute intensive.With four-channel controllers and string-switch ... you could geteight 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 ... withload-balancing and failure-fallover-recovery.

Later in the early 80s, the northern cal. HONE datacenter wasreplicated first in Dallas and then a third center in Boulder ... fortriple redundancy, load-balancing and fall-over (in part concern aboutnatural disasters like earthquakes).

At one point in SJR after the 370/195 machine ... recent referencehttp://www.garlic.com/~lynn/2007f.html#10 Beyond multicorehttp://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 supposedlydedicated to vm and other strings dedicated to mvs. there were "rules"that mvs packs should never be mounted on vm "strings" (because of thehorrendous vtoc & pds directory multi-track search overhead hangingchannel, control units, string switches, and drives).

Periodically it would happen .. in specific instances ... users would be callingthe operator within five minutes claiming vm/cms interactive response and totallydeteriorated. 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 ataste of their own medicine ... we brought up a highly optimized VS1 systemin a virtual machine on the (loaded) vm/158 with a couple packs on MVS stringand proceeded to start some operations that brought MVS to its knees ...drastically inhibiting the long running MVS application from getting any usefulthruput (and effectively negating its debilitating effect of vm/cms interactiveresponse). The MVS operator then quickly reconfigured everything and aggreedthat MVS would keep its packs off VM disk strings.

The mini disk is an imperfect (but cheap) implementation of a lowlevel abstraction. The main "defect" is the number of cylinders, butfor many purposes the virtualization is good enough because the guestcan live with that.But at considerable additional cost, VM could have been designed tospan a mini disk over multiple volumes. With such support, you couldgive out more perfect 3390's (i.e. not being restricted by the actualmodels on the hardware). And VM could have played tricks not toallocate real disk space for unused tracks. This is exactly what wasdone in the RAMAC Virtual Array.

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

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

Later when I joined the science center ... one of the things that idid for cp67/cms (that never shipped in the product) was the cp67 andcms changes to support page-mapped filesystem operation. Thiswas combined in general set of stuff that I referred to as virtualmemory management. Later it was some of the stuff that was portedto vm370 ... old communication with referencehttp://www.garlic.com/~lynn/2006v.html#email731212

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

Note that even with the DIAGNOSE operation there was still a lot ofoverhead related to emulated channel programs that require realaddresses for execution (shadows of the virtual channel programcreated with real addresses of the virtual pages which have beenpinned in real storage). This is not only true for virtual machineemulation ... but anything that has applications building channelprograms in a virtual address space. For reference, posts aboutoriginaly prototype OS/360 to VS2 virtual memory operation byhacking a copy of cp67's CCWTRANS into the side of MVT (to createtranslated, shadow channel programs with real address and pinnedvirtual pages)http://www.garlic.com/~lynn/2007e.html#19 Cycles per ASM instructionhttp://www.garlic.com/~lynn/2007e.html#27 IBM S/360 series operating systems historyhttp://www.garlic.com/~lynn/2007e.html#46 FBA ranthttp://www.garlic.com/~lynn/2007f.html#0 FBA ranthttp://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 providethe DIAGNOSE instruction API) and changes to low-level CMS filesystemfunction to use the cp67 API (pretty much leaving the high-level CMSfilesystem interfaces "as-is") ... eliminated most of the rest of thischannel program translation overhead gorp. It also moved the CMS diskparadigm interface even beyond the simplifications possible with FBAdisks.

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

The simple, original implementation just mapped a set of contiguouspage records ... to contiguous cylinders supported leveraging existingminidisk definitions. However, it also become extremelystraight-forward to do other types of enhancements (having removed thebinding for the cms virtual machine to explicit ckd disk hardwarecharacteristics), like having multiple sequentially chained blocks ofpages ... at discontiguous locations on the same or different disks... emulated a single set of (contiguous) page records (aka enablingrelatively trivial implementation support for various kinds ofcms filesystems spanning multiple disks).

A lot of this is analogous to the features that showed up in more advancecontrollers and the logical volume manager (LVM for unix systems beingable to specify filesystems as possibly multiple discontiguous groupsof records ... either as concatenated discontiguous allocation orvarious kinds of RAID operation).

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

and misc. pasts posts mentioning the spool file system prototypeworkhttp://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 planhttp://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 diskhttp://www.garlic.com/~lynn/2003k.html#26 Microkernels are not "all or nothing". Re: Multics Concepts Forhttp://www.garlic.com/~lynn/2003k.html#63 SPXTAPE status from REXXhttp://www.garlic.com/~lynn/2004g.html#19 HERCULEShttp://www.garlic.com/~lynn/2004m.html#33 Shipwreckshttp://www.garlic.com/~lynn/2004p.html#3 History of Chttp://www.garlic.com/~lynn/2005d.html#38 Thou shalt have no other gods before the ANSI C standardhttp://www.garlic.com/~lynn/2005j.html#54 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAPhttp://www.garlic.com/~lynn/2005j.html#58 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAPhttp://www.garlic.com/~lynn/2005n.html#36 Code density and performance?http://www.garlic.com/~lynn/2005s.html#28 MVCIN instructionhttp://www.garlic.com/~lynn/2005s.html#46 Various kinds of System reloadshttp://www.garlic.com/~lynn/2005s.html#50 Various kinds of System reloadshttp://www.garlic.com/~lynn/2006.html#35 Charging Timehttp://www.garlic.com/~lynn/2006e.html#36 The Pankian Metaphorhttp://www.garlic.com/~lynn/2006k.html#51 other cp/cms historyhttp://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 filesystemhttp://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 RISChttp://www.garlic.com/~lynn/2007c.html#21 How many 36-bit Unix ports in the old days?

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

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

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