|
View previous topic :: View next topic
|
| Author |
Message |
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Howdy,
"Forever" Syncsort has been used here to copy files using the DCB info of the input for the output.
One (at least) of the normal nightly copies has been found to Not use the input file DCB info. The input is Variable but the output file is Fixed. The JCL used follows:
| Code: |
//COPYSTEP EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SORTIN DD DSN=MY.VSAM.VENDR.MSTR,DISP=OLD
//*
//SORTOUT DD DSN=MY.CP.VENDR.PROD.PERM(+1),
// DISP=(NEW,CATLG,KEEP),
// UNIT=3390,
// DATACLAS=DCLMTP7,
// SPACE=(CYL,(1200,600),RLSE)
//*
//SYSIN DD *
OPTION COPY
//* |
The input is a VSAM file and the output is a PS GDG.
This has been running regularly for multiple years and some new requirement has come up and when the GDG was used vas input, the V/F discrepancy was discovered.
I'll dig some more in the Syncsort doc, but this rings no bell with me . . . 
Thoughts?
Thanks,
d |
|
| Back to top |
|
 |
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
I would check the DATACLAS definition
and if the data amount is reasonable try with a different utility
( IDCAMS REPRO for example ) |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
If any DCB-info is specified in the JCL, it overrides. However, that would mean that the COPY is doing it without CONVERT/VTOF, I'm not sure why that would be.
Can you post the sysout? Review the options? The DATACLAS must have been changed at some point, either name or content, if it worked originally. I guess. Any recent upgrade of SyncSort? |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Nope. no dcb-info in the jcl (unless dataclas counts). What I posted is what is submitted.
I'll try to intercept the sysout next time it is run.
I plan on finding the storage management people and asking if there is anything special/specific with this.
In the last several months,. Syncsort was upgraded from 1.1 (yup, Not a typo) to 1.4 on this system. Much of the software is let sit Way too long. They just upgraded Easytrieve to 6.4 (which has been out of support for years).
I have this horrible fear that using this copy has not been done for a long while, if ever. . .
Thanks for the replies and when anyone thinks of something else, i'll surely be interested  |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Just noticed the VSAM in the SORTIN DSN.
There should have been a RECORD statement with a TYPE=V. VSAM doesn't have an RDW, and TYPE=V tells SORT to pretend the records have an RDW.
The lack of a failure message implies that RECFM has been supplied on the output (where SORT is going to look to know how to treat the input, fixed or variable), I think. RECFM=F/FB.
If the step ever worked, at some point the RECFM was changed to F/FB. Or a RECORD TYPE=V was dropped. Perhaps something else. Perhaps never worked.
Good news is that, I think, all short records will have been padded. Unless there is an LRECL on the output which is shorter than the maximum record-length of the VSAM, the data should be recoverable. I think. FTOV with VLTRIM for the pad character (binary zero)?
Need the sysout. It should be "clear" there. |
|
| Back to top |
|
|
|
|
