The files aren't all that large (OK, the first one is rather popular) - input statistics are:
A.MAG90800.ACTLPREM(0) 53,742 tracks, 2,095,912 records
A.MAC90615.ACTLCLAM(0) 0 tracks, (empty)
A.MAC50615.ACTLCLAM(0) 834 tracks, 32,520 records
Joined: 22 Apr 2006 Posts: 6248 Location: Mumbai, India
And WER999A is very generic SyncSort messages - which just indicates that an error condition occurred, preventing the successful completion of the sort.
It might or might not mean that SyncSort was responsible for the error. So diagnostic info, I asked earlier might help us.
Joined: 05 Dec 2006 Posts: 177 Location: Seattle, WA
Well, the error can't be created today and the system programmers are scratching their heads.
The data storage gurus insist that it wasn't a DASD issue or we would have seen either a B37 or S0C4 (or was it S0C1?).
The SyncSort gurus have no idea.
However, both groups think we should output the sort to a tape file, and increase the exit parameter from 100,000 to 2,500,000 (E100000 to E2500000) since we are sorting around 2 million records.
So we've made the changes and we will see what happens.
This is a historical transaction file which grows about 150,000 - 200,000 records a night, and gets archived at the end of the month - when we start with a fresh, new empty file.
What's weird is that the file is no larger than it has been at this time of the month in the past and no abends occurred then. My personal vote is a resource contention issue that has since resolved since the SyncSort parameters have been static for over three years and SyncSort doesn't abend on a whim.
Joined: 05 Dec 2006 Posts: 177 Location: Seattle, WA
Well it turns out that no one is correct: this is a SyncSort issue for which they have a fix (PTF) that we can only install with an IPL (our next scheduled on is in September).
According to SyncSort: "The Abend066 is not a filesize issue. It’s a timing issue between two concurrent SRBs running and there is a window of opportunity when there are a number of instructions at one time. It could be related to a data pattern, but I could not say for sure."
So I guess the answer is, when you get an S066 abend, wait 15 to 30 minutes and resubmit the job!
Vendors - you gotta love them (because shooting them is illegal!).
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
Hello,
Possibly i've gotten lost.
Quote:
In a JCL sort with no Input Exits, the SIZE and FILSZ parameters are ignored because we can access the actual filesize from SORTIN.
Why might one prefer an estimated value over the "real" value when available? If there is nothing "dynamic" (i.e. user exit(s)) with the run, why should the sort bother with the estimates?
