Joined: 23 Nov 2006 Posts: 19245 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
Joined: 09 Mar 2011 Posts: 7310 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)?