Think of all of the code within z/OS that actually depends upon device geometry. The C and H in CCHHR, etc. A hallmark of z/OS has been backward compatibility. If this code were to be changed, all of that backward compatibility would go poof! For what benefit. Customers have revolted against making massive changes to support "arbitrary" hardware design changes.
Another reason is that back in the SLED days, every new device type had a different geometry, and caused massive JCL changes to accommodate that new geometry efficiently in terms of space utilization, and indirectly $$$. 1/2 track block size (27998) on a 3390 (track length 56664) will waste about 40% of the available space if used on a 3380 (track length 47476). That is the reason a few vendor products are still distributing source/load modules with a approx. 6k block size, as opposed to 1/2 track blocking. A 6k block size is fairly efficient (although sub-optimal) on both 3380 and 3390. A secondary effect of the geometry issue is the reason for 3390-9, 27, 54,.... To get around some of the other limitations imposed by volume limits arising from the basic 3390-3 configuration. These other volume sizes are compatible with the CCHHR format of a 3390-3. IBM has stated that future devices will be compatible with 3390 geometry to prevent the need for mass JCL changes. <snip> That leads to a question that I've been thinking about for some time. Since the 3390 geometry is emulated by modern storage control units, why then are the inefficiencies of small blocks emulated also? There are not SLEDs actually storing the data, why are IBG's, sectors, and all the other CKD nastiness emulated that makes 80 byte blocks such a bad idea? IOW, why can't the control unit simply store 708 * 80 byte blocks on a 56,664 byte 3390 track? Does zos's calculations take these inefficiencies into account and only write 78 of these blocks per track? The "C" in CKD stands for "count" and this is some information about the amount of data following in the next data block (the amount may vary from block to block). Likewise "K" in CKD stands for "key" and some access methods are using key data that is stored before the actual data. So, both are bits of information that are used and thus cannot be dropped. </snip> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
