, IBM Mainframe Discussion List wrote:
In a message dated 9/26/2007 10:21:58 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
Wouldn't it depend on home many DD's were defined and the location of the
datasets?
<snip>
The old trick of allocating vol specific temp dsn to turn on DIRF bit
still
work?
This has nothing to do with running code above the bar, how many DDs are
defined, or the location of the data sets. I don't know about this trick. I
don't understand why you would want to turn on the DIRF bit. I used to have to
turn it off sometimes with IMASPZAP.
<snip>
The DIRF (DADSM Interrupt Recording Facility) bit was once (and is
likely still) turned on prior to every DADSM VTOC update and turned off
after completion. If a new data set allocation happened and the bit was
on, DFP would rebuild the F5DSCB (free space) chain for a nonindexed VTOC.
Changing the VTOC to nonindexed, zapping on the DIRF bit (after manually
figuring out what to do with data extents--what to keep and what to
delete--and perhaps salvaging some data by adding a new F1DSCB with
superzap) allocating a data set, and converting the VTOC back to indexed
used to be "the way" to fix corrupted VTOCs.
DSF's REFVTOC has thankfully replaced the need to muck about with zap
and DIRF, but of course any overlapping data extents still need to be
fixed by a person who knows what (if anything) to try to salvage and
which data seems more likely to be valid.
It's worth noting that making sure all your shared DASD is defined as
shared in HCD pretty much eliminates the need to worry about any of this
unless DADSM code abends or the system fails in the midst of a VTOC
update--both pretty rare events nowadays.
Thus far I have consistently lost the argument about removing the
possibility of defining unshared DASD, but maybe someday I'll win it...
--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
[EMAIL PROTECTED]
----------------------------------------------------------------------
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
