Yesterday We had strange failure in a DFSORT step which was running daily for last six months...
Below is SYSOUT...
Code:
ICE000I 1 - CONTROL STATEMENTS FOR 5694-A01, Z/OS DFSORT V1R10 - 03:33 ON WED
ICE010A 0 NO SORT OR MERGE CONTROL STATEMENT
ICE751I 0 C5-K90025 C6-K90025 E7-K62201
ICE052I 3 END OF DFSORT
Below is SYSIN.. Well I feel.. in this particular case it is not that relevant...
Escapa,
Since your sort cards are stored in the PDS, did something else turned to production the day the job abended?
Reason I am asking is because, if other jobs reading the same PDS, used DISP=OLD, locks "may be" issued. Again reason I say "may be" is because access is managed and control by Security. Theoritically your job would have to wait until other jobs released the lock or the system would have placed request in the queue. However, in any case, if such locking indeed had happened, you should be able to view warning messages in the JESMSGLG.
As far as research is concerned, I would start with searching proc library for any procs using the same PDS with DISP=OLD and then research to see if that same job was running at the same time, your sort job abended. If you do find a job running at the same time and using DISP=OLD, that is your answer.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Easy to check for the living/dead - just the date/time on the member. OK, easy if you have it.
What about a scheduled backup/reorg? If someone naughtily runs that as disp=shr, can get you that way. What else was on the system at the time? If "something" is updating the directory while your job is trying to read the same directory block, it would look like this.
If not something like that, then you get into "weirdness"...
Joined: 07 Dec 2007 Posts: 2205 Location: San Jose
ESCAPA,
I would start with checking the complete JES messages (IEFxxx) of the failed job to see if there is an issue with the PDS containing the control cards.
I would start with checking the complete JES messages (IEFxxx) of the failed job to see if there is an issue with the PDS containing the control cards.
Both IEF* and IGD* messages are as usual..
IGD103I and IGD104I mesages are shown up for that dataset
@Expat.. Same case here.. Nobody is pestering at the moment..
Any update on this? I'm feeling nervous about our questioners beginning to believe magic can happen...
Bill, I know.. there is nothing called magic.. Everything has reason....
Just not getting hold of it yet...I am keen on it too..
...
I scanned all the job procedures and none uses access old for that PDS..
And I was negative about this possibility as there wasn't any warning also about dataset getting held...
Now I am suspecting online program creating PDS member into that PDS and then sumbitting job from program at that time. (Its M204 programming language) ... ....
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
OK. Gerry's idea seems to be the all-in-one-place possibility.
I think the DISP=OLD was a red-herring, as if DISP=OLD job is running, yours would have not got on, and vice-versa. DISP=SHR is another kettle... whoops, in deference to your Avatar, I won't complete that thought.
If you can't find anything, I suggest deletion of the whole topic, and no-one ever mention it again :-)
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello,
Something really awful to track down is when "someone" changed something in the pds (while the job was running or just before) and then made another change removing all traces of the change. . .
Is this a pds or a pdse? Can you tell if the problem member has been moved about (look at the ttr) if you can or ask the system support people to look a this.