Shmuel Metz (Seymour J.) wrote:
In <4e34784d.2020...@bcs.org.uk>, on 07/30/2011
at 10:31 PM, CM Poncelet <ponce...@bcs.org.uk> said:
What I am saying is that, on INPUT, a dataset's physical DCB
attributes from its DSCB on DASD cannot be overriden by a JCL or
program DCB.
Yes, and what you are saying is wrong.
No, what I am saying is correct. What matters is not whether a program
can open a DCB for input (trivial), but whether that DCB then actually
works.
According to you, the DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948) on
SYSUT1 (opened for input) should override the dataset's
DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS) on DASD.
Correct.
But that is not the case.
Yes it is.
No it isn't. What matters is whether the DCB opened for input *also*
works when reading data from a dataset, when its attributes
(RECFM=,LRECL=,BLKSIZE=) do not match those of the physical dataset on
DASD.
If you set up and run the jobsteps above, both IEBGENER and IDCAMS
report "IEB351I I/O ERROR <etc.> SYSUT1, READ, WRNG.LEN.RECORD,
etc." when reading SYSUT1.
Proving that the DCB information in the DD statement *did* override
the DSCB.
in theory, but not in practice.
This is because the dataset's DASD DSCB/DCB
attributes override those coded in the JCL (and would also override
the programs's DCB, if hard-coded), for INPUT.
No; if they overrode the DCB then you wouldn't get the I/O error.
semantics ...
To say that the order of priority for INPUT is 'program DCB -> JCL
DCB -> DASD DCB' is meaningless if neither the program DCB nor JCL
DCB can modify/override the DASD's DSCB/DCB to avoid physical I/O
errors on INPUT.
To say that your name is Poncelet is meaningless if the Sun is an
apple.
argumentum ad hominem?
I don't think I 'got it wrong' ...
Then RTFM.
I don't need to.
----------------------------------------------------------------------
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
