Binyamin Dissen wrote:
On Sun, 31 Jul 2011 15:43:15 +0100 CM Poncelet <ponce...@bcs.org.uk> wrote:
:>I know that; but on input they do not override the DCB from DASD - and
:>that is regardless of their order
What do you mean by that statement?
Before the DCB on DASD can be accessed, the program's own 'completed'
DCB (including any missing DCB parms filled-in from a RDJFCB of the
JCL's DD and/or from an exit, if present) must be opened. This might
suggest that the program's DCB, within the above context, overrides the
one on DASD. But the DASD DCB attributes override the program's DCB
attributes when the data is actually read - in the sense that the data
on DASD will be INPUT without I/O error only if the opened program DCB's
attributes are the same as those on DASD. It is not the program's DCB
attributes (including any 'supplied' by exits etc.) but those on DASD
which take priority and 'decide' what the DCB attributes should be on
INPUT. If the program's DCB attributes could override those on DASD for
INPUT, the program's 1st read after opening the DCB for INPUT would not
fail with an I/O error if its DCB attributes were different from those
on DASD - just as there is no I/O error when the program opens a DCB for
OUTPUT and then writes to DASD (regardless of what the DCB attributes
are on DASD).
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.
Do you mean that they do not change the physical data already recorded? Nobody
would disagree. And that would equally apply to output.
On INPUT, the programs' DCB does not even change the RECFM, LRECL and
BLKSIZE on DASD - never mind the physical data.
On OUTPUT, the program's DCB does change the RECFM, LRECL and BLKSIZE as
well as the physical data on DASD - although a program would normally
leave the RECFM, LRECL and BLKSIZE on DASD 'changed' to what they
already are; otherwise we could get the sort of I/O errors which started
this discussion thread.
Do you mean that the program will have its non-zero DCB overlaid with the data
from the DSCB? You are wrong.
No, only its zero DCB attributes are overlaid - i.e. those which need to
be filled in to 'complete' the DCB.
--
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
