The point gets lost every time Alan and I butt heads on this: FBA disk is byte-for-byte copyable, stamp-it-on-a-CD capable. [E]CKD must retain "out of band" data when copied. But ... to the argument ...
> > ... CKD semantics must be simulated by the storage system > > and then peeled off at the O/S end. What a waste! > > Useless? While the operating systems may not be exploiting > the full power of ECKD, applications can. I don't know if DB2 > and VSAM still use keys on the disk to search for data or not. I should have re-iterated "tracks and records" (out of band), which is obviously useful IFF the applications have that level of access, but which are NOT USED by applications on CMS, Linux, or most other operating systems (going beyond zSeries here). So apps don't have access, so is rendered useless if not intrinsically so. If DB2 and VSAM are not using keys (and I believe the latter is not, but am not a VSAM expert) and they're not using the geometric magic (trakcs, records, and such), then they could comparatively run as well or better on FBA or SAN. > [some deleted for brevity] > > But remember that VM/VSE/Linux/UTS/AIX/anything DASD use pales in > comparison to z/OS. That means the mainframe dasd of choice is ECKD. We agree, Alan. > And, finally, it represents another programming interface that must be > tested and documented. "Uselessness" is in the eye of the beholder. :-) This point does not hold water: You support the FBA programming interface for V-DISK, not for (nor even in spite of) idealistic dreaming would-be customers. -- 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
