The DCB coded in the program over-rides everything.
If a data set has VB 133, 1330 and the program has FB 80,800 and opens
it for either input or output, the DSCB will be changed to that coded in
the program.
It's always been that way. (Except the Fujitsu equivalent MSP Operating
system put out warnings, or optionally wouldn't let you change certain
attributes.)
Cheers,
Clem
CM Poncelet wrote:
Rick Fochtman wrote:
--------------------------------------<snip>----------------------------------
I'm afraid I disagree.
Because you are confusing the DSCB with the blocks written in the
dataset.
We are arguing semantics ...
----------------------------------<unsnip>------------------------------------
NOT HARDLY!
--------------------------------------<snip>----------------------------------
What it proves is not that the DCB on DASD was overwritten by the
one in the JCL, but that the DCB in the JCL was
incorrect/incompatible with the one on DASD.
Why would you get an I/O error if the DCB information on the DD
statement did not take precedence over that in the DSCB?
Why would a square peg not fit in a round hole if the round hole did
not take precedence over the square peg?
----------------------------------<unsnip>----------------------------------
If the attributes in the JCL are equally wrong, you'll still get that
I/O error.
... because the DCB on DASD takes precedence over any coded in the JCL
or in the program, in that order. The DCB attributes on DASD have the
'final say' in whether an input I/O will complete successfully. That a
program can populate its own DCB from the JCL's DCB attributes, and
then open it for input *before* having to deal with the real DCB on
DASD, is irrelevant if the JCL DCB's attibutes are inconsistent with
those of the physical dataset on DASD. It is the physical dataset's
DCB attributes on DASD, and not those of the DCB opened by the
program, which determine whether the I/O is successful. If those of
the program's opened DCB do not match those of the physical dataset on
DASD, the I/O fails - because the DCB on DASD 'overrides' (or 'takes
precedence over' etc.) the DCB in the program when it is opened for
input and the program then issues a read.
Much of this 'discussion' has been akin to arguing that a bridge made
of string and bamboo was correctly designed because, when a car tried
to cross over it, the bridge broke and the car fell into the ravine
... and the car could not possibly have fallen into the ravine if the
bridge had not been hanging across it in the first place - "QED".
Read up on the handling and formats of FIXED vs. VARIABLE vs.
UNDEFINED records. What you apperantly don't know CAN hurt you!
I don't need to be distracted by reading other people's opinions when
I can think for myself. What I don't know can indeed hurt me - but
what I know can't.
Cheers, Chris
Rick
----------------------------------------------------------------------
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
