Ted MacNEIL wrote:
I put the heavily hit loadlibs such as SYS1.LINKLIB on one side of the VTOC,
and the ISPF libraries on the other side of the VTOC. With todays heavily
cached dasd, that probably will buy you very little anymore.
Very little.
Especially, since it's been over 15 years since IBM stopped recommending placing
the VTOC (VTOCIX, VVDS, & Catalogue [if there is one]) elsewhere than at the
beginning of the pack.
for os/360 releases 11 & 14 system builds .... i had carefully reodered
stage-2 sysgen to achieve optimal placement ... not only of datasets but
also members within pds. i had given presentations at share (on
the results of both the customized release 11 and 14 system builds) ... that for
the university workload, i could achieve nearly three times increased
thruput. i had also asked for being able to specify vtoc location ... which
showed up in release 15/16 (release 15 slipped and there was a combined
release 15/16).
one of the problems was applying normal system maintenance ... replacing
members in pds libraries like sys1.linklib could detrimentally affect
the carefully ordering .... and over a period of six months, thruput
could degrade by a third or more (and might require a new "build" of
critical pds libraries).
reference to old presentation that i had made a aug68 share
meeting in boston (this particular presentation also included
some measurements after i had rewritten several critical
sections of the cp67 kernel):
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
http://www.garlic.com/~lynn/94.html#20 CP/67 & OS MFT14
however, going into the mid-70s, it was becoming apparent that overall
system thruput (processor and memory) was increasing much faster than
disk technology thruput was increasing. as a result there was starting
to be more and more reliance on mechanisms (like more use of various
kinds of caching technology) to compensate for the relative system
degradation of disk thruput.
at one point, i had made the observation that relative system disk
thruput had degrading by a factor of ten times over a period of
years. this upset some of the people in the disk division ... and
the disk division performance group was assigned to refute the observation.
after several weeks, they came back and effectively said that i
had slightly understated the amount of relative system thruput
degradation (i.e. disks were getting faster, but overall systems
were getting also getting faster, much faster than disks were getting
faster). in any case, the work by the disk division performance
group eventually turned into a share presentation ... not on
how slow disks are ... but on how to organize data on disk
to improve overall system thruput.
as caching technologies became more and more wide used ... nearly all
of the work on careful ordering of "highly used" disk records (that i
had done as undergraduate in the 60s) was obsoleted since such high-used
records would now be found in the electronic caches.
some number of old posts mentioning gpd finding that i had
slightly understated the degree of disk technology relative
system thruput degradation over a period of years
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/2001f.html#68 Q: Merced a flop or not?
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/2001m.html#23 Smallest Storage Capacity Hard Disk?
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/2002i.html#16 AS/400 and MVS - clarification please
http://www.garlic.com/~lynn/2003i.html#33 Fix the shuttle or fly it unmanned
http://www.garlic.com/~lynn/2004n.html#22 Shipwrecks
http://www.garlic.com/~lynn/2004p.html#39 100% CPU is not always bad
http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
http://www.garlic.com/~lynn/2005k.html#53 Performance and Capacity Planning
http://www.garlic.com/~lynn/2006m.html#32 Old Hashing Routine
http://www.garlic.com/~lynn/2006x.html#13 The Future of CPUs: What's After
Multi-Core?
----------------------------------------------------------------------
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
