---------------------------------------<snip>--------------------------------------------
It is a misdesign that the OS allows this ever to happen. The
principal use of this facility is to correct errors that were
introduced by its earlier inadvertent use. Simply, any OPEN for
WRITE with overriding attributes where the label contains different
nonzero attributes should ABEND for inconsistent attributes.
If the programmer feels compelled to change attributes the
recourse should be:
o ZAP the VTOC, or
I use the same mis-design to reset it back to the original blocksize. If the change was recent (last couple of days), I make an attempt to find the culprit and have them fix their jcl. Zapping the vtoc is the last (*very* reluctant) resort and only to be done by a very select few.
----------------------------------<unsnip>---------------------------------------------
IIRC AMASPZAP will ask the operator for permission before allowing this
sort of ZAP. Our operators were told that under NO CIRCUMSTANCES were
they to allow this. I had a special (private) version of AMASPZAP that
did not issue the operator query and via RACF Program Protection, the
use of that version was limited to exactly two people, who could not
both be on vacation at the same time (for a variety of reasons.)
For this particular problem, we just used IEBGENER to copy a dummy
member into the dataset and provided the correct dataset attributes on
the DD statement. I had a "quick and dirty" program to determine the
size of the largest block in the dataset, and the member name, so that I
could affect the necessary corrections.
Rick
----------------------------------------------------------------------
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
