A lot of this has to do with the amount of code that would need to be changed in z/OS and also in the microcode for the DASD controllers. The only DASD that supports EAV volumes are IBM DS8000 series. The existing 16 bit cylinder addressing (CCHH) CCCCHHHH (CCCC is the 16 bit cylinder number HHHH is the 16 bit track number) is near the theoretical limit of 65,535. The largest volume is 65,520. IBM came up with a new format to handle cylinder numbers greater than 65,520. The new 28-bit cylinder number is CCCCcccH (CCCC is low-order 16 bits of 28-bit cylinder number, ccc is high-order 12 bits of 28-bit cylinder number, H is 4-bit track number (0-14)). This is the format used by the DS8000, extent descriptors, access method, and channel programs to access a track. Of course there are new DSCBs to help protect existing programs; Format 8/9 DSCB. There are quite a few limitations on the first go around for EAS data sets. When z/OS 1.11 comes out, many of the limitations; such as a data set extending from track managed to cylinder managed, will be resolved. As with some of the bad things that go along with the new EAV volumes, EAV opens a world of opportunity for customers reaching the limit of 65,280 devices (the 4 digit device number) and other limitations that large installations face. DB2 appears to be a driving force with large table spaces becoming an issue for some IT organizations.
Michael Spencer BMC Software -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of John McKown Sent: Thursday, March 26, 2009 2:53 PM To: [email protected] Subject: "A foolish consistancy" or "3390 cyl/track architecture" 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 ---------------------------------------------------------------------- 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
