Quite possibly; but it's a contrived case where the 2nd LRECL is a fixed
length multiple of the first (so there is one BDW and one RDW, and the
records follow each other consecutively in the buffer).
By 'general purpose' example I meant one where the LRECLs, RECFMs and
BLKSIZEs in the input source dataset are different, and independently
so, from those in the program's DCB - i.e. where they can be completely
random and yet still work. If the DCB is opened for output, the I/O will
complete successfully if the dataset and program DCB attributes are
chosen completely at random, without having to be multiples or divisors
of each other (excluding BLKSIZE if FB etc.); but if the DCB is opened
for input this is not the case, because the program's DCB attributes
must now be compatible with those of the source dataset on DASD to avoid
I/O errors. Hence, the assertion that DCB attribute override priority is
'program -> JCL -> DASD' is true if the DCB is opened for output; but it
is false (or at least 'it does not work', for the benefit of those who
can stomach only a politically correct version of the truth) if it is
opened for input, because it then hits I/O errors.
Dale R. Smith wrote:
On Mon, 1 Aug 2011 01:44:03 +0100, CM Poncelet <ponce...@bcs.org.uk> wrote:
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
OK, explain how this JCL works. I used JCL similar to the following for many years to
copy VM/CMS files to MVS that were longer than 80 but a multiple of 80 in length. In
this example, the records are 160 in length. They are split into two 80 byte records,
then "joined" into 160 byte records by overriding the LRECL of the disk file
via JCL.
//COPY EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=A
//SYSIN DD DUMMY
//SYSUT2 DD DSN=&&TEMP,DISP=(,PASS,DELETE),
// UNIT=SYSDA,SPACE=(1600,(10,10),RLSE),
// RECFM=FB,LRECL=80,BLKSIZE=1600
//SYSUT1 DD DATA,DLM='++'
PART1....
PART2....
PART1....
PART2....
++
//SORT EXEC PGM=SORT
//SYSOUT DD SYSOUT=A
//SORTIN DD DSN=&&TEMP,DISP=(OLD,DELETE),
// RECFM=FB,LRECL=160,BLKSIZE=1600
//SORTOUT DD DSN=MY.DATA.SET,DISP=(,CATLG,DELETE),
// UNIT=SYSDA,SPACE=(1600,(10,10),RLSE),
// RECFM=FB,LRECL=160,BLKSIZE=1600
//SYSIN DD *
SORT FIELDS=COPY
END
/*
The key for this to work is that the BLKSIZE has to be a multiple of 80 and 160. This will work for any records that are a multiple of 80, (160, 240, etc.). I needed to put the VM/CMS file inline so it had to be a multiple of 80 bytes to work. This example clearly shows that the JCL LRECL overrides the file setting and no error occurs.
----------------------------------------------------------------------
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
