Below is the step which is giving S179 abend. The file in SORTIN and SORTOUT are of the same format (VSAM KSDS).
This step is in a production job, and it is working fine everyday except one day on which it abended with S179. The only difference I see on that day was the SORTIN contained around 6500 recs (on an average it contains 2000 records). Is this the cause?
Thanks Frank. But alas I couldnt get any clue from the link and other manuals i had.
Can you pls tell me how to raise a problem with IBM service. (I registered myself and tried to find, but again unlucky..)
Also I suspect my way to merge the file is wrong? Is whatever I am doing in the above step of JCL correct for merging a small transaction file into a similar layout but large file. Is there any alternate and better way to do this?
Well, you say that your job works sometimes, but not other times, yet you don't seem to be able to pinpoint anything different between the times it works and the times it doesn't, so that's kind of confusing.
I'm also confused by your use of MOD and COPY for KSDSs. A KSDS has to be in order by the binary key defined for the cluster. So I would think that your SORTIN and SORTOUT data sets, if valid, would each already be sorted by the key and you should MERGE them on that key (using SORTIN01 and SORTIN02 for the input files and another file for SORTOUT) to keep them in order.
Your technique of trying to COPY with MOD a KSDS at the end of another KSDS doesn't seem valid to me as it would seem to result in the keys being out of order for the resulting SORTOUT KSDS unless the SORTIN KSDS keys just happen to all be greater than the original SORTOUT KSDS keys.
You must have had a different situation involving a sort application. SORTWKnn data sets are ONLY used for a sort application. Since Vinod is doing a copy application, the SORTKWnn data sets are NOT used and are irrelevant.