-----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Tom Marchant Sent: Tuesday, March 31, 2009 5:23 PM To: [email protected] Subject: Re: "A foolish consistancy" or "3390 cyl/track architecture"
On Tue, 31 Mar 2009 15:54:09 -0500, Eric Bielefeld wrote: <Snip> When I worked at Wayne State University in Detroit, we bought an RVA. That was IBM's re-branded Iceberg. AFAIK, Sun also sells it as the SVA. On that box, all data stored on disk was compressed. Because any new data written to a track may not fit in the same location, every time data on a track was written, the track was written to a new location, and only the disk space required for the compressed data was used. There was a special utility used to report on how much of the back-end disk storage was used. IIRC, it was called Net Capacity Load. Allocating another volume or creating a snapshot did not increase the NCL. The micorcode has garbage collection routines that accumulate track areas that are no longer used and background tasks that move data around in order to maintain a contiguous area where new tracks can be written. It is a marvelous feat of engineering. And it is no wonder that the Iceberg was so much later getting to markket than originally planned. In order for any DASD subsystem to be insensitive to blocksize, it would have to do something similar, compressing out the gaps and storing the track in discontiguous locations. AFAIK, the rest of modern DASD subsystems allocate specific locations for each logical volume, and therefore for each logical track. There has to be sufficient disk space to store the maximum amount of data in each track location. If short blocks are written, less data will fit in that logical track. <SNIP> Wouldn't this effectively defrag DASD units? But then we would still have to run some kind of defrag just to fix the VTOC (so it wouldn't have so many extent entries for data sets), right? Regards, Steve Thompson -- Postings by this poster may not reflect the views or opinions of poster's employer. -- ---------------------------------------------------------------------- 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
