30 years ago, in the early days of SMS, when all the "logical space stuff"
appeared, It crossed my mind that it might be "nice" to have a construct
whereby space could be based on specifying the number of records, rather
than a particular logical or physical space quantity.
e.g. SPACE=(RECS,(20,10)),AVGREC=M equating to 20Million records primary,
and 10million records secondary.
That way, you could let the system do the hard work of calculating the
actual space needed, based on LRECL (and yes, VB would make things
"interesting").
The prime benefit being that you could have Dataclasses defined with
defaults based on the number of records, and overriding the LRECL would
adjust the space requirements accordingly.
Whilst you can effectively do this "manually" by specifying AVGVAL as the
LRECL you are using, you dont get the benefit of the LRECL override in the
Dataclass case, which was the main thought at the time, with the setup &
promotion of use of dataclasses going on then.
I forget whether I raised a SHARE requirement for it.
On Mon, 19 Apr 2021 at 21:35, David Staudacher <dlstaudac...@gmail.com>
wrote:
> > 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
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
