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
