-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On
Behalf Of David Staudacher
Sent: Tuesday, March 23, 2021 2:17 PM
To: [email protected]
Subject: Re: "Wrong" Size Allocation with AVGREC?
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.
