Mike Schwab wrote on 3/13/2012 5:59 AM:
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.
How would this work when the system tells the control unit that the
user's channel program is allowed to read or read/write multiple
tracks? In the case of a single extent data set, I believe the
control unit is now told about the whole data set. Even if the system
fudged the extent limit sent to the control unit, how would you set
different extent limits for reading vs writing?
/Leonard
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
