When copying an existing dataset, why not use the LIKE JCL parameter?

> -----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.
> 
> ----------------------------------------------------------------------
> 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

Reply via email to