Tom Marchant wrote:
On Mon, 1 Aug 2011 01:44:03 +0100, CM Poncelet wrote:
If the same DCB is opened for INPUT (MACRF=GM|L,EODAD=<etc.>), then the
program's DCB attributes do *not* override those on DASD
Right. No one said that they do.
and, as the
program's DCB attributes are inconsistent with those of the dataset on
DASD, they cause I/O errors ... because the dataset's DCB attributes on
DASD take priority over those of the program's DCB.
No. Because the attributes specified in the completed DCB are inconsistent
with the DATA on disk or tape.
Consider an unlabeled tape. A data set that was written previously to tape
is read by a program that specifies DCB attributes. If it specifies incorrect
attributes, the program may get I/O errors. This is not because the DCB
attributes on the tape override those coded in the DCB because there are
no DCB attributes on an unlabeled tape.
But if opened for INPUT, the priority order is "DASD DCB -> JCL DCB ->
program DCB". If the program's DCB attributes are then inconsistent with
the ones on DASD, on INPUT, the program hits I/O errors
It might very well
because the
DCB attributes on DASD override those hard-coded in the program on INPUT
No, because the data on DASD are not consistent with the DCB parameters
in the program. This would happen even of the DCB attributes in the DSCB
were zapped to be the same as those in the program.
If the program's
DCB attributes, for INPUT, are inconsistent with those of the physical
dataset stored on DASD, they do not override those stored on DASD
The attributes in the DCB of an input data set are not written to the DSCB.
That is correct. But for filling in the DCB, if a particular attribute is specified
in the program, that attribute from the DSCB is not used.
If I am wrong, please prove it by submitting verifiable 'general
purpose' examples of this (excluding 'reblocking' trivia). A 'verifiable
example' is one in which all the program's DCB attributes are different
from those of the dataset's physical DCB attributes on DASD - yet
override the dataset's DCB attributes stored on DASD *both* when the
dataset is opened and written for OUTPUT and also when it is opened and
read for INPUT
No one has claimed that the DCB attributes from the program are written
to the DSCB when the data set is opened for input.
If you cannot prove it by a 'verifiable
example', then you are arguing high-falluting semantics where the
interpretation of "DCB override" depends entirely upon what *you* mean
by that, and is not subject to what "DCB override" is actually
understood to mean in practice.
I think that you are the one who is using a non-standard definition of
what it means for a DCB attribute to be overridden.
Probably ... because my definition includes that the overriding DCB must
then also be able to read successfully the dataset whose DCB attributes
have been overridden - regardless of BDW, RDWs and data. Otherwise the
'standard' definition of "DCB override" is purely academic and of no
practical use. This 'standard' definition appears to mean that,
regardless of its attributes being consistent or not with those of the
dataset being read, the DCB which is opened first overrides the physical
dataset's DCB attributes (and if the dataset cannot then be read, that
is irrelevant). As I said earlier, 'DCB' includes 'DSCB' within the
context of my argument: I refer to them all as DCBs for the sake of
expediency.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
