> ROTFL, Rick! If it were that easy, we wouldn't be having this discussion.
I admit to taking unfair advantage of the discussion thread to pursue my own evangelistic designs and agenda. :-! Phfaww! > Think, man: If the benefits of teaching all of the dasd management, > specification, and reporting mechanisms in MVS and its subsystems and > applications (read: databases) to understand FBA was worth the expense, > ignoring the intangible values of Goodness and Light, but taking into > account the affect on Storage, then it would have been done already. With juicy Carribean accent, "Think, mon!". You're so good. ;-) Benefits ... I work for a software house. Don't tell me that "it would have been done already" strictly on business grounds. It has more to do with the psychology of both sides of the MVS business: IBM and customers. They simply CHOSE to reject FBA technology, Alan. It would be fine except for the consequences that choice imposed on the VM and VSE (and now Linux) market space. Incentives! What incentive is there for IBM (or any SW vendor) to get it right? None. The only incentive is that bottom line. It is up to US to change the rules, to steer the incentives like a high pressure system steering a hurricane. Where is MVS data? IMS can use QSAM (OSAM and whatever other access methods there are that I do not know about). Not so for DB2. DB2, as I understand, must use VSAM, and VSAM does to CKD the same as CMS/EDF and EXT2. So ... how much of the MVS world is IMS and how much is DB2? THAT is the question. And the more that is DB2, the less value there is for count key DASD. In fact, the less real optimization based on record and track trickery (with QSAM), which is now effectively zero, the less value there is for count key DASD. -- R; ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
