On Tue, Mar 13, 2012 at 7:19 AM, Paul Gilmartin <[email protected]> wrote: <deleted> > I suppose the same could be achieved for CKD data sets by > maintaining a bitmap of used tracks, which would add only > .00025% overhead to the size of a data set. > > -- gil
You have the VTOCIX free space map, one bit per track. How about adding a track written map, one bit per track. After implementing the PTF, a VTOCIX with a free space map but without a track written map would copy the free space map to the track written map, assuming all allocated tracks have been written on. Releasing space sets the bit to not written on. Allocating space would retain the not written on bit. Reading the track would be blocked, as if there were no records on the track. Writing a record on the track would change the bit to written on, to allow subsequent reads. A delayed erase could be attempted also. When you release the space, go ahead and set the free space indicator, but not the track written on bit. A low priority task scans each volume's the free space table and track written tables. If free but track written on, write a null value full track record and set the track as not written. If you allocate the space, set both the allocated and not written bits to bypass the erase but block the read. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
