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).
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"? 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. -- John ---------------------------------------------------------------------- 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
