Florian Bilek wrote: > Would be interesting to format an USB device in ECKD mode. Is this > possible ??? ;-) > > Probably that goes only together with an FICON attached USB-Reader > costing only 250.000$ allowing for ONE USB stick at a time. Great ;-) > > -- > Best regards > > Florian Bilek
No, it is not possible. Thank Poughkeepsie. It WOULD be possible if the burden of ECKD emulation were on z/OS. But that shift has again been deferred. [details and opinion follow - you have been warned] ECKD (today) is an IBM hardware solution for a software problem. Originally, CKD exposed not only counts and keys (thus the acronym) but more significantly tracks and records. NO ONE but MVS (and TPF) has a firm requirement for that. What I mean is that CP and VSE can at least tolerate a lack of tracks and records. (They can run from IPL to shutdown on things like SAN.) More significantly, CMS, Linux, and Solaris (or UTS or AIX or USS) explicitly THROW AWAY the track and record semantics that our precious storage subsystems worked so hard to present on the channel. They can't use it! They just care about the data on the disk, not its geometry. When 3390s were new, someone said it would be the last of that generation of disk. (They were really big platters!) I didn't understand. Now I do: Storage was moving away from physical platters and towards "just data" that could be managed more effectively. Look at a contemporary disk frame ... it's all a bunch of SCSI disks with nothing but blocks. The physical disks are sliced up and/or concatenated (and RAIDed, of course) to provide a volume of the exact size you require. And then that silly ECKD stuff is applied. What a waste. If z/OS wants tracks and records and counts and keys, then let z/OS convert the raw storage. It's absurd that the rest of us have to UNDO that effort. Do you see the overhead? The physical media is pre-blocked. ECKD semantics are applied by the storage subsystem. And then the operating system has to discard the ECKD semantics ... even in z/OS. (Not for all, but for much. It's true!) Once upon a time, there was the idea that z/OS would talk to a SAN. If that had happened, this emulation pain would have shifted, and the access methods within z/OS would have been turned upside-down, direct I/O would have been to the raw data (theoretically USS and possibly VSAM would have become more efficient) and geometric access would have been performed at a higher level, entirely the responsibility of z/OS. That which is now done in the storage subsystem would have been done within the z/OS operating system, a SW solution for this SW requirement. And why would they do this? Does the Poughkeepsie crowd actually *want* to run on flat disk like HP, Microsoft, and Sun? Hardly. They're just out of space in ECKD addressing. Now with the advent of "big ECKD" (EAV), the requirement has quietly gone away. But the need for z/OS to play nice with SAN was never truly a z/OS requirement. It's about interoperability. It's a DATA CENTER requirement. If other platforms could use "geometric" disk (CKD), fine. But they can't. And I for one would be on the bandwagon if ECKD helped anything (on the other platforms), but it doesn't. So if you want your mainframe to use the same disk everyone else uses, you'll have to fight for it. EAV has provided another way to marginalize the mainframe. But, "We believe in the interconnectedness of all things.". ECKD is for disk what motor generators were for power. We don't miss MGs and we won't miss ECKD. Today, there are two ways that you can run VM and/or Linux on other than ECKD: You can use SAN, but there are some remaining issues, I cannot lie to you, fond as I am of VM's SAN capability. You can also get 9336 (or something like it) from at least one storage vendor. Really! After searching for more than a decade, I found it last week in Austin. The particular storage subsystem can talk 9336 or 3370 to FICON while presenting the same volume on the SAN. Nice! That's interoperability. So ... ummm ... yeah. Your USB stick could be "formatted in ECKD mode" if it had an ECKD emulator layer. Odds are that it doesn't. And it would be useless on your PC if it were doing ECKD, not interoperable. There ... and I said it all without using a certain 3-letter acronym. -- R;
