On Sunday, 09/10/2006 at 02:21 AST, Richard Troth <[EMAIL PROTECTED]> wrote: > The real advantage is probably channel speed. And it may be that we'll see > FICON leap-frog past FCP in the future. Speculation. > > I've argued for years that tracks and records are artificial and impose useless > overhead on AIX (remember that?), CMS, Linux, UTS, and even VSE and CP. The > backing store in contemporary DASD is FBA, which is exactly what these > operating systems want. 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 suspect that CKD overhead is heavier on the DASD end, but that's tough to > measure. Still, the measurable difference is probably more in the channels. Other than in the mathematical conversion of block number to CCHHRR based on disk geometry and back, I would expect little to no difference on a typical CCW chain. The cycles spent converting between block number and CCHHRR are dwarfed by all of the cycles spent elsewhere, both in the CPU and the device controller. And the conversions in the controller have not been shown to be causing a bottleneck in dasd access, have they? 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. And, finally, it represents another programming interface that must be tested and documented. "Uselessness" is in the eye of the beholder. :-) Alan Altmark z/VM Development IBM Endicott ---------------------------------------------------------------------- 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
