John McKown wrote:
I just had a Webinar with Dino software on z/OS 1.10 and ICF catalogs. Very interesting. The most interesting thing to me was how IBM implemented Extended Address Volumes. There is a 4 byte area in the CCW. Historically this is the CCCCHHHH (in nybbles) field. What IBM has done is take the high order 3 nybbles of the HHHH and made it part of the cylinder address, but although physically after the historical cylinder address, it is logically the first 3 nybbles of the cylinder address. I.e. C0C1C2C3H0H1H2H3 has become C3C4C5C6C0C1C2H0 (wish I could do subscripts properly).
Not the CCW, the disk address. The old, familiar CCCCHHHHR is now CCCCcccHR on EAV where the effective cylinder address is cccCCCC.
Now, why is 14 tracks per cylinder so sacrosanct? Why didn't IBM create a new DASD with 2^16-1 (x'FFFF') cylinders where each cylinder has 2^16-1 (x'FFFF') tracks? Is it due to not wanting to "mess around" with the ECKD emulation in the physical DASD array? Is there some code deep within z/OS which is so crufty that to consider touching it sends paroxsyms of terror in the hearts of the DFP developers? <grin> And what makes 56K per tracks so sacred also? Is this just a case of "how to make a really large volume while making the absolute minimum number of software changes"?
There are tremendous advantages to keeping the 3390 geometry stable. You might not remember how much hassle it was in the past to transition from e.g., 3330 to 3350, to 3380, to 9345 (for some of us), to 3390. Over two decades ago, IBM promised there would be no more geometry changes. And, they've stayed true to their word.
It's the same reason we have tri-modal addressing in z/Architecture: 24-bit, 31-bit, and 64-bit. Upward compatibility is important. IMHO, IBM does it better than any other vendor.
The new disk addressing scheme can describe a single volume with up to 268,435,456 3390 cylinders--or nearly 223 TB--without changing the 3390 geometry one iota. Impressive!
Oh, well. I would still prefer that z/OS kick ECKD to the curb and go FBA, using standard FCP (Fibre Channel) connection to the SAN fabric. z/Linux can do it. So the hardware is capable. I guess this is yet another case of cost vs. perceived benefit.
De-support ECKD? Not likely. Instead, new I/O architectures like zHPF (FCX) solve ECKD's performance issues without changing *any* applications. Also, *darn* impressive!
-- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [email protected] http://www.phoenixsoftware.com/ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
