> Will keep poking away at this and let you know what I find.
I'm satisfied the discrepancies I saw must have been due to something peculiar
to using DFSORT for the copy process as I could not recreate the problem
[output larger than input copying one file to another using (1) AVGREC and (2)
RLSE on SPACE parm] using a method other than DFSORT.
Thanks everyone for your guidance! I'm especially grateful to Andrew Rowley
for his insight, ignoring the literal meaning of AVGREC ("average record size")
and simply using it as a way to specify multiples of "K" or "M". His example:
> //DD1 DD DISP=(NEW,CATLG),
> // DSN=ANDREWR.TEST.DATASET,
> // SPACE=(2,(3,4)),AVGREC=M,
> // LRECL=80,RECFM=FB,DSORG=PS,BLKSIZE=27920,
> // UNIT=SYSDA
>
> ISPF 3.4 dataset information shows:
>
> Organization . . . : PS
> Record format . . . : FB
> Record length . . . : 80
> Block size . . . . : 27920
> 1st extent megabytes: 6 [ note primary = 6M ( 2 x 3 = 6) ]
> Secondary megabytes : 8 [ note secondary = 8M ( 2 x 4 = 8) ]
Such usage makes the AVGREC method SO much easier to understand!
=> "AVGREC={M|K},SPACE=(x,(y,z))" where "x" = units of M or K, "y" = Primary
multiplier and "z" = Secondary multiplier.
If only IBM had used some term other than "AVGREC" [e.g.
"BASE=M,SPACE=(2,(3,4)"?] or even let {M|K} be a suffix [e.g.
"SPACE=(2M,(3,4))"] SO much confusion could have been avoided as to how it
actually works! Now that I understand it this way, the explanation given in
the IBM manuals seems positively Ptolemaic:
http://ibm.com/docs/en/zos/2.2.0?topic=requirements-average-record-length
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
