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. -- Tom Marchant ---------------------------------------------------------------------- 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
