On 04/30/2017 06:58 AM, Scott Chapman wrote: > On Sat, 29 Apr 2017 11:17:43 -0500, Paul Gilmartin <paulgboul...@aim.com> > wrote: > >> On Sat, 29 Apr 2017 12:39:00 +0200, Peter Hunkeler wrote: >>> AVGREC is a funny beast. it specifies the multiplier to be applied to the >>> primary and secondary space figures. The resulting number is the number of >>> records that must fit into the final space allocation. To calculate this >>> value, the system needs the (average) record length. This value, however, >>> is not taken neither from the LRECL, nor from the BLKSIZE. In JCL, it is >>> the first sub-operand of the SPACE= specification. >>> >> This is a nightmare. >> >> When they say "record" do they mean "block? Usually? > I can't say for sure, but I believe, and the way we always used, going back > to the c. 1994 when we started using it, was that the design goal for this > support was to give the application programmer a way of space that they > understood. After all, they should inherently have an idea of how many > records that their job creates or consumes because that has some sort of > business connection that they understand. I.E. this job normally processes > "x" accounts, each account has "y" records in this file, so we need a file > that can hold about x*y records. > > If you have fixed-length records, you know the length of each record. But if > you have variable length records, it's a little more variable. But the > application programmer should have a decent idea of the average length of > those records. > > From there you need to convert those numbers to some number of tracks based > on the block size and the average number records per block based on their > average record length. By using the AVGREC allocation method, the application > programmer can just give the information to the system and let it figure it > out instead of doing the math themselves. Which seems like it should make > life easier for everybody. > > At least that seems like a good theory. In practice I found a distressing > number of application programmers who didn't actually know the business > numbers--i.e. that they were going to process x accounts each night. To me > this seems to be a larger problem than just not being able to allocate space > correctly. One might argue that if one is guessing at space allocations, it > doesn't really matter what units one is guessing in. > > Over 20 years later, disk is drastically cheaper and larger and so the need > to allocate the data set size correctly is probably reduced in many shops. > But my guess is that most also don't want every space allocation to be > SPACE=(CYL,(1000,1000)). > > Having extensively used the AVGREC allocation method 20+ years ago I probably > knew the answer to your questions at one time, but the only one I remember > for sure is that it works fine with SMS. > > Scott Chapman > > In the context of AVGREC, "record" really was intended to refer to logical record size, not block size. In my experience, this type of allocation was typically used with System Determined Blocksize (SDB), which means that the actual block size may even be unknown to the JCL writer. The values in "SPACE=(size,(pri,sec))" are just used (together with any AVGREC multiplier) to calculate primary and secondary bytes-of-data, which are translated into tracks or cylinders by SMS conventions under the assumption that SDB will result in an optimum block size with minimal wasted space per track. When AVGREC is coded, the convention is that "size" would be average record length; in the absence of AVGREC "size" was intended by older conventions to be average block length. Although that is the convention, there is nothing that forces that convention or forces any consistency with actual block size -- it is only important that the product of any AVGREC value and size*pri and size*sec result in a reasonable estimate of the total space requirements in bytes. In both instances when dealing with RECFM=VB data sets, values used for average record size or average block size are not required to be accurate, only reasonable enough to get adequate data set space allocated.
If through some serious oversight (like coding something that forces RECFM=F when RECFM=FB was intended) one forces usage of a very inefficient block size, then the space allocated based on total byte requirements under the assumption an efficient block size would be used may be seriously inadequate if the actual block size results in wasting much more space in every track. -- Joel C. Ewing, Bentonville, AR jcew...@acm.org ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
