Martin Kline wrote:
| //BUILD EXEC PGM=IEBGENER
| //SYSUT1 DD *
| RECORD 1 PLUS SOME EXTRANEOUS CHARACTERS > 40
| RECORD 2 PLUS SOME EXTRANEOUS CHARACTERS > 40
| RECORD 3 PLUS SOME EXTRANEOUS CHARACTERS > 40
| RECORD 10 PLUS SOME EXTRANEOUS CHARACTERS > 40
| RECORD 11 PLUS SOME EXTRANEOUS CHARACTERS > 40
| RECORD 12 PLUS SOME EXTRANEOUS CHARACTERS > 40
| //SYSUT2 DD DISP=(,PASS),SPACE=(TRK,1),
| // DSN=&ORIG,
| // RECFM=FB,LRECL=80,BLKSIZE=8000
| //SYSIN DD DUMMY
| //SYSPRINT DD SYSOUT=*
| //*----------------------------------------------
| //* COPY THE FIRST 40 BYTES OF EACH INPUT RECORD
| //*----------------------------------------------
| //SORT1 EXEC PGM=SORT
| //SORTIN DD DISP=(OLD,PASS),DSN=&ORIG
| //SORTOUT DD DISP=(,PASS),UNIT=SYSDA,SPACE=(TRK,1),
| // DCB=(RECFM=FB,LRECL=24,BLKSIZE=2400),
| // DSN=&TEMP1
| //SORTMSG DD DUMMY
| //SYSIN DD *
| SORT FIELDS=(1,8,CH,A)
| OUTREC FIELDS=(1,40)
| //*-----------------------------------------------
| //* EXPAND THE RECORDS FROM THE COPY
| //*-----------------------------------------------
| //SORT2 EXEC PGM=SORT
| //SORTIN DD DISP=(OLD,PASS),DSN=&TEMP1
| //SORTOUT DD DISP=(,PASS),UNIT=SYSDA,SPACE=(TRK,1),
| // DCB=*.SORT1.SORTIN,DSN=&TEMP2
| //SORTMSG DD DUMMY
| //SYSIN DD *
| SORT FIELDS=(3,7,CH,A)
| //*
> how many bytes will be in the output TEMP2 file?
The answer centers around the answers to two questions:
(1) What DCB characteristics will the SORTOUT data set
in step SORT2 actually end up having?
(2) How does the SORT utility behave with that DCB?
The answers are as follows:
(1) DCB=*.SORT1.SORTIN on the SORTOUT DD statement in
step SORT2 is useless, because there is no DCB in
the JFCB to copy (because there was no DCB on the
referenced DD statement). And there will still be
none after the step executes, because that DDNAME
will have been OPENed for INPUT.
Consequently, data set &TEMP2 will be allocated
with undefined DCB characteristics (of interest).
It is possible that SMS or installation controls
or OEM products could cause this to be different,
so not all sites will necessarily experience the
same results.
(2) In step SORT2, ICEMAN will discover that the output
data set has "missing" DCB characteristics and will
copy the DCB characteristics from the &TEMP1 data
set referenced by DDNAME SORTIN. I don't know what
SYNCSORT will do but it should probably do exactly
the same thing (at least it used to do so, in my
memory).
Thus, the DCB of &TEMP2 will, I predict, end up being
LRECL=24. Hence, with 6 input records, there will be
6 * 24 = 144 bytes in the &TEMP2 data set.
Ulrich Krueger wrote:
> I suspect that your TEMP2 dataset ended up with a LRECL=80
> (as requested by the DCB=*.SORT1.SORTIN referback),
Nope. It will end up being LRCEL=24 as discussed above.
> but you only had 24 bytes of data in each record (as
> truncated by the DCB of SORT1.SORTOUT).
That is true, but only because the SORT utility normally
ensures that the SORTOUT data set will have an LRECL that
is consistent with the SORTIN data set (and NOT because
of the DCB=*.SORT1.SORTIN referback).
The key to understanding all of this is the fact that
the DCB=*.SORT1.SORTIN parameter on the SORTOUT DD
statement in step SORT2 accomplishes exactly nothing.
--
WB
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
