I realize that the OP has been able to resolve the problem, but I
think a couple of points need to be raised.
1) AMASPZAP is not needed to print the contents of a member, nor is it
necessary to change the DCB attributes of the existing PDS. If the PDS
member is allocated with a DD with the DCB attributes desired (or via
dynalloc) neither of which actually change the attributes of the
existing dataset, then IDCAMS PRINT will print the contents. I've been
through this many times in the past.
2) There is a difference between the relative priority of DCB
information, and the actual mechanism involved. The order of priority
was stated correctly, but the exact mechanism is a little more complex
and does depend on
a) whether the DISP is NEW (or MOD if the dataset is not found and
must be created), or OLD/SHR(or MOD if the dataset is found)
b) whether the file is opened for INPUT or OUTPUT.
Unless some UNIX programmers are lurking in the woodpile since I was
current in this area, There is a "forward merge" (from dataset to JFCB
to DCB) and a "reverse merge" of DCB information (from DCB to JFCB to
dataset). The stated priority is observed (which is why one can
TEMPORARILY override the dataset attributes with a DD card if the OPEN
is for INPUT, or why using a BLOCK CONTAINS clause with other than 0
on a COBOL input file is asking for problems). The "forward merge"
from the dataset to the JFCB obviously cannot be done with a newly
created dataset, and the "reverse merge" from the JFCB to the dataset
is only done for a DISP=NEW or for an OPEN OUTPUT. which is why I can
READ an existing dataset using a bogus DCB parameter without actually
changing the dataset attributes, but since, as has been pointed out, a
PDS has only one set of DCB attributes, adding a member to a PDS using
a JFCB/DD or DCB with invalid attributes corrupts the PDS and makes
members unreadable. It can even be more complex when such antics as
RDJFCB are employed (there was a recent thread that got bogged down
over confusion due to the way the old Linkage Editor (perhaps the
Binder as well?) distinguished between DISP=SHR and DISP=MOD. Beware -
all this is based on my admittedly rusty memory).
That said, the advice to use PDSMAN or the CBT PDS command is well
taken and is the best solution to the problem. The best long-term
solution to the problem is to either remove the offending programmer
from the gene pool, apply some behavior modification in terms of
education, or use some proactive guard against modifying the DCB
parameters of FB PDS's (I seem to recall a function of MIM which might
do this), or make sure of frequent backups and frequent monitoring of
the dataset's attributes.
Dale Miller
----------------------------------------------------------------------
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
