On 2016-08-12, at 08:56, Jesse 1 Robinson wrote: > VSAM was invented (shortly) before I got into this biz, so I cannot speak to > its roots, but I've always supposed that AVGREC (average record) was supplied > for the benefit of application designers who did not want to calculate > gearhead values like xxxO-bytes or--even worse--disk-dependent values like > tracks or cylinders. (This was lonnng before we had standardized on 3390 > architecture.) It might also simplify upgrading a cluster if the record size > changes. > > Once documented, this parameter would be more trouble to remove than it's > worth. Don't like it? Don't use it. But also don't carry it forward in any > new extension. > Thanks for the history lesson.
I believe that if I want blklgth>=2**16 or primary-qty>=2**24 I must use AVGREC. Yes, I don't like it, particularly when I'm generating JCL or arguments to BPXWDYN with a program. A simpler alternative such as enlarging the limits on blklgth should be provided (while retaining AVGREC for dusty deck compatibility). The existing limits were practical when we "got into this biz", but that's long since been Overcome by Events. When I'm computing those arguments with a program and know the simple (large) integer number of bytes I want, Lizette's concern about counting zeros is unimportant to me. Splitting that integer among AVGREC, blklgth, reclgth, and primary-qty is wearisome, even error-prone. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
