On 2 Mar 2007 14:42:07 -0800, [EMAIL PROTECTED] (Blaicher, Chris) wrote: >The limit for CKD volumes is a little more than 54GB. I come up with a >number closer to 500GB. Past that and IBM will need to go to logical >volumes on a physical volume. The reason is the CCHHR count field. > >Max CC is FFFF, which give 65536 cylinders (don't forget cylinder 0) >Max HH is E, which gives 15 tracks per cylinder > >That gives: >65536 cylinders times 15 tracks times 56664 bytes = 983040 tracks * >56664 >983040 tracks * 56664 = 557,053,378,560 > >My question is who is going to want that much data on a single volume? >In 10 years someone may want that much. I'll be glad to not have to >wait for that volume restore as I hope to be long retired.
I have seen ads for 500 gigabyte disks for PCs and PCs with 500 gigabyte disks. At the rate databases are growing and the product files have more and more pictures for Internet sales, I am sure someone will find uses and ways to back them up. In response to another posting, I realize that you could change some of the limits so that track size and cylinder size are larger but if pain is going to be caused, why perpetrate a file organization that is optimal only for sequential files? We are awkwardly shoe horning FBA access methods - VSAM, PDSE, and the various Unix file systems are all FBA oriented and fit awkwardly on CKD devices (using 4K or 8K blocks you utilize only 48k out the 56K theoretical maximum). There is additional path length in both the mainframe and the controller to accommodate CKD. The basic changes that would be needed in order to "functionally stabilize" CKD are finding a new spool arrangement (snitch one from Unix), enhancing ESDS so that it can be on tape (RCA did this with the Spectra 70) and have GDG like capability, allowing PDSE to be in the IPL link and LPA lists, coming up with new VTOC capabilities, a new IPL text mechanism and an upgraded way of handling SYS1.NUCLEUS. This could be the excuse to expand the data set name length and member name length as well as get rid of a lot of baggage. In the restructuring they should look at what the other IBM operating systems do and snitch any good ideas. > >Christopher Y. Blaicher >BMC Software, Inc. >Austin Development Labs >(512) 340-6154 >The comments made are my personal opinions. BMC Software, Inc. makes no >representations or promises regarding the reliability, completeness, or >accuracy of the information provided in this discussion; all readers >agree not to rely on this information or take any action against BMC >Software in response to this information. > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] >Behalf Of Edward Jaffe >Sent: Friday, March 02, 2007 4:13 PM >To: [email protected] >Subject: Re: FBA rant was Re: IBM S/360 series operating systems history > > >I agree with you Clark re: the short-sightedness of not supporting FBA >in MVS. Because of that dumb decision, z/OS is the only mainframe >operating system left in the 21st century that can't handle SCSI. :-( >That situation should be rectified! > >But, why do you say we need FBA in order to support volumes greater than > >54GB? Why can't ECKD be extended to support larger volumes? ---------------------------------------------------------------------- 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
