The 'acid test' is whether the same program DCB (ignoring the MACRF= and
EODAD=) can be used *both* for OUTPUT and for INPUT (with a change in
MACFR= and adding EODAD= when opening for INPUT), when the dataset's
physical DCB attributes on DASD are *different* from those specified in
the program.
If this DCB is opened for OUTPUT (MACRF=PM|L), then the program's DCB
attributes override those on DASD - and the program's DCB attributes
then also become those stored on DASD, all without causing I/O errors.
This is because the program's DCB attributes override the dataset's
existing DCB attributes on DASD when opened for OUTPUT.
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 - 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. If the program's DCB
attributes do not match those on DASD for INPUT, it's just another case
of garbage-in / garbage-out. A program's DCB attributes do *not*
override an existing dataset's DCB attributes on DASD when opened for INPUT.
Hence, if opened for OUTPUT, the priority order is "program DCB -> JCL
DCB -> DASD DCB".
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 - because the
DCB attributes on DASD override those hard-coded in the program on INPUT
(and not, as has been suggested, the other way round). 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 but
cause I/O failures.
For the sake of expediency, "DCB" includes "DSCB" etc. - because this
discussion topic is about DCBs.
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 (subject to the appropriate MACRF= etc. being specified
on the DCB in each case). 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.
Thanks,
Chris Poncelet
Binyamin Dissen wrote:
On Sun, 31 Jul 2011 18:19:11 -0400 Gerhard Postpischil <gerh...@valley.net>
wrote:
:>On 7/31/2011 12:35 PM, CM Poncelet wrote:
:>> The program's DCB attributes take priority over (i.e.
:>> 'override') the DCB attributes on DASD for OUTPUT, and the DCB
:>> attributes on DASD take priority over (i.e. 'override') the
:>> program's DCB for INPUT. If a program 'disagrees' with that and
:>> tries to override the DCB attributes on DASD anyway, with its
:>> own DCB attributes and for an INPUT, it crashes with an I/O
:>> error. Crashing with an I/O error indicates that the program's
:>> DCB was unable - not able - to override the DCB attributes on DASD.
:>What we have here is a failure to communicate. Your statement
:>above makes it evident that you are using "DCB attributes on
:>DASD" as applying to the format of the data, whereas the other
:>participants in this merry-go-round are referring to the DCB
:>parameters in the format 1 DSCB (DS1RECFM, DS1LRECL, DS1BLKL).
Yes, that was what I was trying to point out to him.
--
Binyamin Dissen <bdis...@dissensoftware.com>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
----------------------------------------------------------------------
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
----------------------------------------------------------------------
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
