The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main as well.
patrick.oke...@wamu.net (Patrick O'Keefe) writes: > I think that logic may not apply. It all depends on how the emulation > works. The "wasted" track space may not take any space on the > real hardware. We may be protected from our old stupidity (but I'm > sure there is lots of new stupidity to make up for that). > > It's still complicated. Now you have to know which old guideleines > still hold, which can be discarded, and what new guidelines are > needed. cyl/track & ckd architecture are left over from 1960s trade-offs ... cyl/track provided a direct 1:1 logical/physical correspondance so that uses (application developers) could wring every possible bit out of the infrastructure. ckd allowed for leaving information data structure indexes out on disk ... rathing than caching them in real-storage. this traded-off i/o channel, controller, and device thruput against extremely (much more) scarce and expensive real stroage. the ckd architecture trade-off was already shifting in by the mid-70s ... where bottleneck had significantly switched from being real storage to i/o thruput (and starting to see use of electronic storage for caching and/or staging information to compensate for the increasing bottlenecked i/o resources). I was being called into some number of severe thruput bottlenecked customer situations where the problem turned out how to minimize the use of PDS directory & VTOC multi-track search. at the same time, the disk price/bit was drastically dropping ... so the cost effort to optimize every last bit of disk space was starting to cost more than the disk bits saved. FBA bascially addressed both issues; 1) it drastically simplified the logical structure users and application developers had to deal with and 2) eliminated the whole search infrastructure; recognizing that it was more efficient to cache/save high use data structures in electronic storage so that I/O read/write operations would directly specify required record. I was told that even if I provided fully developed, tested, and integrated MVS FBA support ... it would still cost (an additional) $26M to ship (changes to documentation, education, etc). Supposedly I had to show incremental revenue/sales as result of shipping MVS FBA support (i.e. on the order of $200m-$300m in incremental disk sales). The theory was customers were buying as much disk as they required and the only thing that MVS FBA support would provide would be the disks sold would be FBA rather than CKD (but no incremental sales). Any argument about infrastructure and long-term life-cycle savings with any MVS shift to FBA was discounted (as well as indirect sales because of simpler/faster development) I also was pontificating about how relative system disk thruput had dropped by factor of ten times over a period of yrs. Eventually some executive in the disk division asked their performance group to refute my statements. After several weeks, they came back and basically said that I had slightly understated the issue; i.e. disks may have gotten five times faster ... but with fewer arms and/or more data/arm to access, the avg. thruput per access (because of higher loading and queuing issues) was possibly only three times better. At the same time, processor had gotten possibly 50 times faster (processors 50 times faster, disks 5 times faster ... ratio of disk:processor thruput had declined by order of magnitude). Applications using 60s disk i/o techniques weren't able to keep the processors busy ... w/o heavy leveraging of electronic storage. In any case, the disk performance group turned the study around into a SHARE presentation recommending how to optimize disk configurations (basically attempting to mitigate the thrutput bottlenecks). In the meantime trying to get ECKD debugged and working as a subset solution for the multi-track search overhead ... was a monumental undertaking. lots of past posts mentioning ckd, multi-track search, fba, etc http://www.garlic.com/~lynn/submain.html#dasd semi-related, misc. past posts mentioning getting to play disk engineer in bldg 14 (disk engineering) & bldg 15 (disk product test). http://www.garlic.com/~lynn/subtopic.html#disk then as all physical disk technology shifted to "FBA" ... there was another major effort required to continue to emulate CKD infrastructure on top of an underlying infrastructure that is fundamentally FBA. slightly related to the technology paradigm trade-off CKD/FBA shift was the discussions in the '70s between the STL IMS group and SJR system/r relational database group (original relational/sql) http://www.garlic.com/~lynn/submain.html#systemr The IMS group position was that direct record pointers as part of the data infrastructure required half the disk space as System/R (relational, later sql/ds, db2, etc) and significantly fewer disk i/os. Basically the internal index structure used by relational doubled the space required on disk and required quite a few disk i/os to eventually acquire the pointer to the record containing the data. System/R response was that the eliminating record pointers as part of the exposed data significantly simplified the administrative and application process. Going into the 80s, administrative and application development costs were significantly increasing (and becoming scarce resource). disk space costs were significantly declining (mitigating the doubled disk space associated with relational index). The amount of electronic storage also significantly increased (and cost decreased) allowing much of the index to be cached ... eliminating much of the additional physical I/Os "index" penalty. In any case, relational paradigm started to become much more cost effective (because of changes in the people costs for administration & development vis-a-vis hardware costs). -- 40+yrs virtualization experience (since Jan68), online at home since Mar70 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
