Good morn.. er, uh ... Good afternoon from Hurricane Alley. I'm going to pick on Tom's point about emulating CKD.
On Fri, 23 Sep 2005, Tom Duerbusch wrote: > I looked at FCP and just couldn't deal with it. Yes, there is some mental gyration involved, which is unfortunate. I will try to refrain from repeating my sermon about how IBM should have presented fixed block devices on-the-channel. (bootable CDs and such) What we now have is a different class of channel. Complicated. We even have a whole new way to IPL. Very compicated indeed! > When VM emulated CKD on FCP, we could use the normal VM type products. The storage vendors have been emulating CKD for years now and I've been missing "real fixed block" on-the-channel that whole time. Linux and CMS (and probably most of CP and possibly VSE) gain nothing from using CKD, emulated or real. CMS has always squashed the track and record geometry into blocks. Linux does too. So fixed block is a natural for these operating systems. And IBM tried once to get the mainframe into the fixed block millenium. MVS would not have it. Since the backing store for STK, EMC, and IBM storage boxes is really a bunch of fixed-block disks, why do NONE OF THESE present that directly as 9336 on-the-channel? I just do not get it. It is only MVS where count-key or records or tracks are used. Even there, MVS itself (given the heavy use of VSAM) squashes out the CKD geometricks into blocks ... er, uh ... pages. In this context, count key emulation is wasted storage and wasted DASD subsystem time. The time required for the DASD subsystem to do CKD emulation is a double loss for any fixed-block use as the target op sys must then discard track and record info when crunching channel progs. Why then are we using CKD? We still use CKD because of a handful of MVS routines that have never been updated. VM doesn't need CKD. VSE and Linux do not need CKD. CKD is a waste of time, processor, bandwidth and drain on the mental resources of us systems programmers. But in the future, MVS will bear its own CKD emulation load. In the future, zLinux and z/VM will increasingly use FCP/SAN/SCSI and MVS will have to grok that too! So ... think beyond CKD! > But when z/Linux was using native FCP, VM and it's products were > out of the picture. ... This is a problem. But it is NOT a CKD problem per se. VM products are happy with FBA, and VM can make FCP DASD look like FBA. Don't be fooled. Don't let your customers be fooled. > The DS6800 can be partitioned into CKD and SAN sides. ... WHAT WOULD BE SWEET is for the DS6800 to be partitioned into FBA (ala 9336) and SAN sides. Think about it! SAN side uses FCP. FBA side uses FICON. Let the channels compete head-to-head. But the blocks of data would be byte-for-byte the same, and no geometry to emulate or lose. -- 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
