If you are looking for a 1megabyte multiplier, just specify CYLinders and multiply by 1.3, since 30 half track blocks is 839,940 bytes, and 5 cylinders is 4MB. That gives you about a 5% margin for lower efficiency block size.
On Tue, Mar 23, 2021 at 4:17 PM David Staudacher <[email protected]> wrote: > > Using Steve Pryor's IEBDG suggestion, I think I found an explanation for the > case where a copy of a "SPACE=(TRK,1)" file filled with 698 80-byte records > ends up with 2 tracks when copied using DFSORT to a second file with > "AVGREC=U,SPACE=(80,698),DISP=(,CATLG)". > > First, using IEBDG *did* work to create a 1 TRK file of 698 80-byte records > using "AVGREC=U,SPACE=(80,698)" and IEHLIST *did* show 1 track. That was a > bit of a surprise given how consistent the symptoms were that I'd been seeing. > > However, when I used DFSORT to copy that file to another file using > "AVGREC=U,SPACE=(80,698)" on the SORTOUT DD, again I got 2 tracks instead of > 1. > > I found the explanation when I used DITTO to dump the file and saw an EOF > mark after the last record (taking up the next whole track all by itself!) > which DFSORT obviously put there after writing out the last record. IEBDG > apparently doesn't do that. > If I remember correctly from when I was trying to learn EXCP coding, a file > doesn't necessarily need an EOF mark to indicate end of file. End of extent > on the last (or only) extent also works. > > I still don't have an explanation for the case where copying a 100 CYL file > with 1,047,000 records to a second file allocated using a DD with > "AVGREC=M,SPACE=(80,1),DISP=CATLG" ends up 1707 tracks instead of 1500. For > that case, I'm hoping 3380 mapping can explain it, but I'm not sure it holds > up any more, given how the 1 track file explanation turned out. I *do* know > we had UNIT=VIO mapped as 3380 up until a couple years ago when I pointed it > out and they changed it. I'm hoping AVGREC turns out the same so my trust in > the precision and consistency of z/OS can be restored. Will keep poking > away at this and let you know what I find. > > = = = = = = = = = > > From Steve Pryor: > > I think we need to 'see the work'. You mention 'copying' the dataset. But > allocation doesn't depend on the program being executed - only the SPACE > specification. So if you allocate something like: > > //DG2 EXEC PGM=IEBDG > //SYSPRINT DD SYSOUT=* > //SEQOUT DD DSN=SJP.AVGR.DATA,DISP=(,CATLG), > // LRECL=80,BLKSIZE=27920,RECFM=FB,DSORG=PS, > // SPACE=(80,698),AVGREC=U > //SYSIN DD * > DSD OUTPUT=(SEQOUT) > FD NAME=FIELD1,STARTLOC=1,LENGTH=4,PICTURE=4,B'0001',INDEX=1 > CREATE QUANTITY=698,NAME=FIELD1 > > And then run an IEHLIST against the resulting dataset, it should occupy one > track: > > CONTENTS OF VTOC ON VOL SMS007 <THIS IS AN SMS MANAGED VOLUME> > ---------------DATA SET NAME---------------- SER NO SEQNO DATE.CRE > DATE.EXP DATE.REF EXT DSORG RECFM OPTCD BLKSIZE > SJP.AVGR.DATA SMS007 1 2021.082 > 00.000 2021.082 1 PS FB 00 27920 > SMS.IND LRECL KEYLEN INITIAL ALLOC 2ND ALLOC EXTEND LAST > BLK(T-R-L) DIR.REM F2 OR F3(C-H-R) DSCB(C-H-R) > S 80 TRKS 0 0BY 0 2 > 170 0 1 7 > EATTR > NS > EXTENTS NO LOW(C-H) HIGH(C-H) > 0 4 13 4 13 > ----ON THE ABOVE DATA SET,THERE ARE > 0 EMPTY TRACK(S). > > One possibility is that the Default Device Geometry in the your SMS > configuration is 47476 rather than 56664 (i.e., 3380 rather than 3390). If > you're copying the dataset with an application such as Sort or something > similar, the application may alter the output allocation or may automatically > taken another extent. Another possibility is a vendor product such ours (ACC) > or others (from BMC, CA, etc), that might automatically alter certain > allocations. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
