I'm afraid I disagree. 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.
If I allocate SYSUT1 with DCB=(RECFM=FBA,LRECL=121,BLKSIZE=16093) and
SYSUT2 with DCB=(REFM=FBA,LRECL=133,BLKSIZE=16093), where 121*133=16093,
then both the physical RECFM and data block lengths are the same for
SYSUT1 and SYSUT2. If I specify:
//IEBGENER EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//*
//SYSUT1 DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL121.BLK16093,
//* cannot override dataset's DCB on DASD via JCL, for INPUT:
// DCB=(RECFM=FBA,LRECL=133,BLKSIZE=16093)
//*
//SYSUT2 DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL133.BLK16093,
// DCB=(RECFM=FBA,LRECL=133,BLKSIZE=16093)
//*
<etc.>
I then still hit I/O errors without IEBGENER issuing message "IEB311I
CONFLICTING DCB PARAMETERS" and the DCB BLKSIZEs are compatible, i.e.
the physical data block size is not larger than the DCB BLKSIZE in the
JCL's override.
If instead I allocate SYSUT1 with
DCB=(RECFM=FBA,LRECL=121,BLKSIZE=16093) and SYSUT2 with
DCB=(REFM=FBA,LRECL=133,BLKSIZE=27930) and specify
//IEBGENER EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//*
//SYSUT1 DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL121.BLK16093,
//* cannot override dataset's DCB on DASD via JCL, for INPUT:
// DCB=(RECFM=FBA,LRECL=133,BLKSIZE=27930)
//*
//SYSUT2 DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL133.BLK16093,
// DCB=(RECFM=FBA,LRECL=133,BLKSIZE=27930)
//*
<etc.>
I then still hit I/O errors without IEBGENER issuing message "IEB311I
CONFLICTING DCB PARAMETERS" and the JCL's DCB BLKSIZE override for
SYSUT1 is now greater than its physical data block size on DASD (hence
there is enough buffer space allocated via the JCL DCB's override to
read in a SYSUT1's complete physical data block from DASD).
Hence your "For example, if your override was for a - larger - blocksize
it would have worked fine (other than perhaps IDCAMS/IEBGENER) warnings
about different block sizes." is not correct. An equal or larger
blocksize override in the JCL makes no difference.
What you are implicitly suggesting is that the I/O error has nothing to
do with the JCL or program DCB being in error. But if so, is it then the
one on DASD that is incorrect? I am saying that the DCB on DASD can be
overridden only during OUTPUT, not INPUT.
That the JCL or program DCB specifies a 'round hole' override into which
the DASD's 'square peg' DCB cannot fit does not imply that the JCL or
program DCB has successfully overridden the one on DASD, but rather that
the program or JCL DCB is wrong and cannot override the one on DASD.
Thanks anyway.
Chris Poncelet
Binyamin Dissen wrote:
On Sat, 30 Jul 2011 22:31:57 +0100 CM Poncelet <ponce...@bcs.org.uk> wrote:
:>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.
:>Consider the following JCL where
:>SYS1.RECFMVBA.LRECL137.BLK27998 has physical
:>DCB=(RECFM=VBA,LRECL=137,BLKSIZE=27998,DSORG=PS)
:>SYS1.RECFMFBA.LRECL137.BLK27948 has physical
:>DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948,DSORG=PS):
:>//IEBGENER EXEC PGM=IEBGENER
:>//SYSPRINT DD SYSOUT=*
:>//SYSIN DD DUMMY
:>//*
:>//SYSUT1 DD DISP=SHR,DSN=SYS1.RECFMVBA.LRECL137.BLK27998,
:>//* cannot override dataset's DCB on DASD via JCL, for INPUT:
:>// DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948)
:>//*
:>//SYSUT2 DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL137.BLK27948,
:>// DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948)
:>//*
:>//IDCAMS EXEC PGM=IDCAMS
:>//SYSPRINT DD SYSOUT=*
:>//*
:>//SYSUT1 DD DISP=SHR,DSN=SYS1.RECFMVBA.LRECL137.BLK27998,
:>//* cannot override dataset's DCB on DASD via JCL, for INPUT:
:>// DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948)
:>//*
:>//SYSUT2 DD DISP=SHR,DSN=SYS1.RECFMFBA.LRECL137.BLK27948,
:>// DCB=(RECFM=FBA,LRECL=137,BLKSIZE=27948)
:>//SYSIN DD *
:> REPRO INFILE(SYSUT1) +
:> OUTFILE(SYSUT2)
:>//*
:>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. But that is
:>not the case.
:>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. 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.
Not at all. It proves that the DCB - was - overridden.
Of course, the DCB override does not affect the physical data. If the actual
data block length is longer than the DCB block length there will be an I/O
error.
For example, if your override was for a - larger - blocksize it would have
worked fine (other than perhaps IDCAMS/IEBGENER) warnings about different
block sizes.
--
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
