Old Hashing Routine 3831

Jim Mulder

re:

in past posts i've told the story both ways ... both of the unused bits by architecture allowing PTEs to address up to 2**14 4k real pages (64mbyte) or one unused bit by 3033 to support 2**13 4k real pages. I remember lots of 32mbyte 3081s but don't remember any 64mbyte 3081s.

part of this is my scenario about dasd had declined in relative system performance by a factor of ten times over 10-15 yr period i.e. rest of the system resources-thruput increased by 40-50 times while dasd increased by only 4-5 times.

at least by the time i release the resource manager ... 11may76, you were starting to see real storage used to compensate for system thruput being constrained by dasd performance. i had done much of the work as an undergraduate in the 60s for cp67 ... which then got dropped in the morph from cp67 to vm370 ... but then was allowed to rerelease it as the resource manager

i had a comparison of cp67 360-67 configuraiton and a vm370 3081 configuration ... and observed if overall system thruput had kept pace with the cpu, the typical number of users would have gone from 80 on 360-67 to over 2000 on 30831 ... but in fact, typical 3081 configurations tended to be more like 300-400 users ... which represented the change in dasd thruput between 360-67 and 3081.

this is the story about initially the san jose disk division buttigned their performance group to refute the claims ... but they came back a couple weeks later and explained that i had actually understated the problem.

the other issue is that ckd dasd from the 60s ... traded off i-o thruput with extended (& multi-track) searches for real memory use ... i.e. more real memory intensive tended to cache indexes to specific disk location ... while vtoc & pds multi-track search spun the disk to find location. Some of the IMS ccw programs took this to the extreme with long ccw programs searching and finding fields in disk-based index structures ... which then were read and used for further searching ... all in a single channel program.

i've often repeated story about being called into a large national retailer with a large complex of vs2 processor complex ... basically loosely-coupled with processors dedicated to each region. they were experience sever performance degradation. turns out they had a large application program library shared across all processors in the complex with a three (3330) cylinder PDS index. aggregate number of I-Os to (across all processors in the complex) avg. about 6.5-sec ... because they were doing avg 1.5 cylinder search of the PDS index. the multi-track search of the first cylinder at 3600rpm-19cylinders was about .3secs elapsed time (i.e. being limited to approx three application program member loads per second aggregate across all the processors in the complex).

the other place that you saw real memory compensating for dasd performance was with the emergance of rdbms in the 80s. there were arguments between STL (60s physical database) and SJR ... original relational-sql database implementation

the 60s paradigm had direct record pointers imbedded as part of the database infrastructure and exposed to application programmers. this allowed going directly from one record to the next relatively efficiently. however, there was heavy people and skill resource overhead for management of the structure.

system-r abstracted away the direct pointers with the relational paradigm ... subsbreastuting internal index tree structure managed by the dbms (no longer requiring direct administrative and application support). this significantly decreased the people and skill resources needed to manage the infrastructure. however, it might take 5-6 disk reads of index structure to find the disk record pointer to the actual record needed. the other argument was that the on-disk index structure could double the physical disk space required for relational implementation vis-a-vis a "60s" physical dbms implementation.

what happened in the 80s was that disk space became increasingly less expensive ($$-mbyte which has now shifted $$-gbyte) and the explosion in real memory sizes allowed much of the relational index to be cached in real memory (eliminating a lot of the additional disk reads to get to the actual record).

various past posts discussing the STL-SJR argument over "60s" physical databases (with direct record pointers) and relational which created a dbms metaphor that eliminated the direct record pointers from the database abstraction: filesystem? Engines? Engines? (w-o RM-SQL) hierarchic databases Tables as Types, and all that

various past posts about the two unused bits in the 370 PTE and using them to increase the number of real pages that could be specified (greater than 2**12 4k real pages past 16mbytes): 32-bit processor for small clusters addressing boundaries

various posts describing the cp67 360-67 with vm370 3081 comparison and the increasing disk system thruput constraint: out the Door other irrelevant concepts to Today's Micros? past?) that ran as slow as today's supercomputers? Disk? rates? rates? please new?