General rule:
when you specify TRK or CYL you get it. Number of records is predictable
and depends of BLKSIZE and CKD voodoo. Of course you can find out before
you allocate new dataset or just check with some small (1 TRK/CYL) sample.
However when you specify records or kilobytes, the system assumes the
following:
a) you have only inkling about mainframe DASD
b) you want such and such number or kilobytes, megabytes or records. AT
LEAST.
Note: dataset allocation is not math exercise or game. It is a method to
assure that your data will fit in the prepared (allocated) space. A
little more is OK.
Last, but not least: it is rather rare you know *exact* number of
records in advance. I mean real production. Of course you should
anticipate order of magnitude - i.e. there is a difference between
number of clerks, number of customers and number of transfers. However
no exact numbers, because it's alive, changing.
So you predict a space for approx. 100M records FB 80. 349 rec/blk, 698
rec/trk. That means 143 266,47564469914040114613180516 tracks or
9 551,0983763132760267430754536772 cylinders (decimal point is comma).
So, I would specify ~10 000 cylinders and of course some secondary
space. Try this with AVGREC and I believe you will get similar size.
HTH
--
Radoslaw Skorupka
(looking for new job)
Lodz, Poland
W dniu 23.03.2021 o 09:10, David Staudacher pisze:
I've looked over all the IBM-MAIN posts referring to AVGREC and don't see that
anyone has ever brought this up before.
I've read the relevant manuals, so I'm familiar with AVGREC syntax and how it's
supposed to work.
My concern is how to explain the differences in size allocation using BLKS/TRK/CYL
allocation and what *should be* the AVGREC equivalent, according to the reference manuals
(e.g. z/OS 2.4 MVS JCL Reference "AVGREC Parameter"
http://ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ieab600/xddavgr.htm )
The discrepancies are consistent across multiple z/OS systems at different
sites, so I'm certain it is not site-specific.
Case 1 - SPACE=(TRK,1),DCB=(RECFM=FB,LRECL=80,BLKSIZE=27920)
With these specs and a 3390 (emulated) Device Type, the file will hold
*exactly* 698 records.
These 698 records are then copied to a second file allocated using these specs:
AVGREC=U,SPACE=(80,698),DCB=(RECFM=FB,LRECL=80,BLKSIZE=27920),DISP=(,CATLG)
But instead of occupying 1 track, the new file occupies 2 tracks. Why?
Case 2 - SPACE=(TRK,1),DCB=(RECFM=F,LRECL=27920)
Basically same as above - still 1 track - except now with only 2 records.
And again, if these 2 records are copied to second file using
AVGREC=U,SPACE=(27920,2),DCB=(RECFM=F,LRECL=27920),DISP=(,CATLG)
the new file occupies 2 tracks instead of 1. Why?
So far, I've run many test cases copying existing files to new files using
AVGREC and in every case, when the existing allocation is completely full, the
size allocated to the copy is *always* larger than what is necessary to
accommodate the input file. In the case of a 100 cylinder input file, the
excess allocation is over 13 cylinders!
I have no explanation for this behavior, so I'm hoping someone here will.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
