"Jeff Gribbin, EDS" <[EMAIL PROTECTED]> writes: > David, > Not sure if this might be OT - you did specify, "VM Function" - but > there were various constraints regarding using non-relocate-0 > minidisks (that is, a minidisk whose virtual cylinder zero doesn't > correspond to a real cylinder zero) for OS guests 'way back when. > > As a youth I was taught that non-relocate-0 OS packs should have one > track VTOCs and should not have ISAM files on them. I think that > ISAM is now no more than a fond(?) memory for all except Hercules > hobbyists and I'm pretty sure that the combination of modern > hardware and software has lifted the one track VTOC constraint - but > they definitely existed as issues to consider back in '370 days. > > Maybe this'll be enough to tempt Mr Wheeler out of his shell with some > definitive explanations regarding the practical constraints and the > architectural basis for them (along, with, no doubt, a few anecdotes for > us all to enjoy) :-)
some number of collected past posts mentioning dasd architecture, vtocs, pds directories, multi-track searches ... including stories of shooting major performance problem for large national retailer ... that was purely mvs and didn't really involve vm at all. there are also a couple examples of mvs multi-track search (vtoc and pds directory) penalty in shared dasd environment between mvs system and vm system (in one specific case, production environment at sjr in bldg. 28) http://www.garlic.com/~lynn/subtopic.html#dasd basically vtoc & pds directory were disk resource trade-off against real memory resource from the early 60s. multi-track search would consume enormous amounts of I/O (channel, controller, disk) resource at the saving of having to consumer real-storage caching the information. however, by at least the mid-70s (if not early 70s) ... that trade-off was no longer valid ... and i/o resources were more constrained than real storage sizes. ISAM was another such trade-off. ISAM could create enormously complex, self-modifying CCW programs ... where the structure of the information was resident on disk ... and CCWs could read CCHHR from various disk-based structures, which would then be used in later in the channel program. the virtual memory model (not just a characteristic of vm) simulating real i/o paradigm required pre-translating channel programs before actual activation. in cp67, ccwtrans would create a "shadow channel program" from the CCWs in the virtual address space ... prefetching & fixing required virtual pages into memory, converting virtual addresses to real addresses, etc. the channel program that was actually executed was the translated shadow CCWs, not the CCWs from the virtual address space. note that for original os/vs2 prototype ... I have some recollection of being in POK machine room 3rd shift ... where Ludlow(?) was cobbling together an MVT system with a little bit of glue that laid it out in a 16mbyte virtual address space (and handled page fault interrupt) and was hacking CCWTRANS (from cp67) into the MVT supervisor to do the required channel program translation (on a 360/67). if the self-modifying channel program i/o ... actually modified subsequent CCWs ... all bets were off ... since the modifications would be done against the CCWs in virtual memory ... not the shadow CCWs. however, there was a limited subset of self-modifying channel programs that only involved the CCHHR information. nominally, shadow channel program also involved shadow CCHHR to handle the case of relocated minidisk cylinders (start and also not going past the end). there was a special case made for full pack minidisk where the start and end were the same was the real disk ... and therefor the CC fields didn't need twiddling ... and there was no need to enforce checking on I/O extending past the end of the user's allocated minidisk. note that vm as well as the other mainframe operating systems that evolved from real-memory heritage all made special channel program case for V=R ... where the original CCWs could be directly executed w/o translating and execution of shadow CCWs (vm added the additional requirement for disk i/o that it required full pack minidisk ... to eliminate both the starting cylinder relocation as well as the ending cylinder verification check). vtocs (& pds directories) should not have been an issue ... since they just did normal multi-track searches ... but stayed on cylinder boundaries. they became an enormous performance issue ... but wouldn't represent an integrity issue as long as minidisks allocation was restricted to cylinder boundaries (there were some customer modifications that allowed for minidisk allocation that weren't on cylinder boundary and integral number of cylinders). isam was an issue (for other than full-pack minidisk) because the channel program could read CCHHR information that would be used in subsequent part of the same channel program (and wouldn't have been modified by the initial channel program translation). misc. past postings about the transition from real memory constrained configurations to i/o constrained configurations: http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door http://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other irrelevant concepts http://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to Today's Micros? http://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?) http://www.garlic.com/~lynn/98.html#46 The god old days(???) http://www.garlic.com/~lynn/99.html#4 IBM S/360 http://www.garlic.com/~lynn/2001d.html#66 Pentium 4 Prefetch engine? http://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that ran as slow as today's supercomputers? http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts) http://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts) http://www.garlic.com/~lynn/2002.html#5 index searching http://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching) http://www.garlic.com/~lynn/2002b.html#20 index searching http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates? http://www.garlic.com/~lynn/2002e.html#9 What are some impressive page rates? http://www.garlic.com/~lynn/2004p.html#39 100% CPU is not always bad -- Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
