|
View previous topic :: View next topic
|
| Author |
Message |
vaibhavjadhav
New User
Joined: 27 Jul 2007
Posts: 33
Location: mumbai
|
|
|
|
Hello,
The production job failed with DJ status code, I did checked and found that there was a GHU call first following a REPL CALL where it failed with DJ. There wasn't any checkpoint and rollback call in between GHU and REPL CALL. I even tried to check the values from both the calls but somehow it is using same I/O area so after the failure the values were spaces.
Can you please assist me here as I need to find out what would have actually caused the job to fail with DJ as in the abend aid as well i couldn't find out the reason for DJ?
Please do help me here as it is a critical job which was holding whole of the production schedule because of failure. |
|
| Back to top |
|
 |
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
from the IMS messages and codes manual ...
| Quote: |
DJ
Explanation
The program issued a DLET or REPL call that was rejected because the segment was not currently in hold status. Some possible reasons for this status code are:
The segment had not been previously retrieved with a Get Hold call.
The segment was already deleted using this PCB. After one Get Hold call, multiple REPL calls or a DLET call following a REPL call are valid, but multiple DLET calls are not.
The segment was obtained using a secondary index as the processing sequence. A subsequent DLET or REPL call using either this PCB or another PCB within the PSB caused the current secondary index entry for this PCB to be deleted.
A checkpoint call was issued following the Get Hold call and preceding the REPL or DLET call.
A rollback call was issued following the get hold call and preceding the REPL or DLET call.
Programmer response
Correct the program so that the segment is in hold status when a DLET or REPL is issued.
|
| Quote: |
| I did checked and found that there was a GHU call first following a REPL CALL where it failed with DJ. There wasn't any checkpoint and rollback call in between GHU and REPL CALL. |
the only suggestion that anybody outside of Your organization can give is ...
keep investigating
unfortunately in these cases the IMS perception of things and events is the right one |
|
| Back to top |
|
|
vaibhavjadhav
New User
Joined: 27 Jul 2007
Posts: 33
Location: mumbai
|
|
|
|
Thanks for your reply Enrico....
I understand it would be difficult for you to give a solution but would you mind to provide me pointers for exactly where to look for please.... |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India
|
|
|
|
| Quote: |
| There wasn't any checkpoint and rollback call in between GHU and REPL CALL. |
How did you verify this? If you got a dump at the end of failed Job, the last number and types of DLI-calls should be found. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
Can you please assist me here as I need to find out what would have actually caused the job to fail with DJ as in the abend aid as well i couldn't find out the reason for DJ?
Please do help me here as it is a critical job which was holding whole of the production schedule because of failure. |
Your FIRST problem is that you think you know what is going on and that the computer is wrong. Sorry, but the computer is telling you what the problem is -- HOW it got to be the problem, I don't know. But as long as you insist your interpretation is correct and the computer is wrong, you will not be able to resolve the issue -- period.
Your SECOND problem is that this is a volunteer forum -- people answer when / if they can, not on your schedule. Nobody here cares if this is a production critical job -- if it is so important, you would not be posting on a voluntary response forum; you would escalate the issue internally in your organization, or you would open an issue with the vendor. |
|
| Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3053
Location: NYC,USA
|
|
|
|
| Update calls needs a HOLD of a segment and somehow that has been not achieved, are you sure this PSB is only used by once by the current program and no where else? |
|
| Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3053
Location: NYC,USA
|
|
|
|
| also see if , REPL was issued without issuing a previous successful Get- Get Hold command. |
|
| Back to top |
|
|
vaibhavjadhav
New User
Joined: 27 Jul 2007
Posts: 33
Location: mumbai
|
|
|
|
Thanks for your reply Guys....
Yes the PSB is used in only this job.
Also as mentioned above the program is using same I/O area so I couldn't tell if the previously GHU was successful. |
|
| Back to top |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007
Posts: 2455
Location: Hampshire, UK
|
|
|
|
| vaibhavjadhav wrote: |
| Also as mentioned above the program is using same I/O area so I couldn't tell if the previously GHU was successful. |
If you do not check the code returned from the GHU before doing the next action then why do you expect the next action to work? Any and every database action should have the return code checked - that is what it is there for. |
|
| Back to top |
|
|
pmartyn
New User
Joined: 28 Feb 2013
Posts: 3
Location: USA
|
|
|
|
Just about everybody is pointing to a logic error. To be honest it sounds like you have a missing period somewhere. However, there is a way to solve this. Throw the program into BTS, place a breakpoint at the GHU call, and step through the program to the REPL call. Something small can be easily missed when you are under a lot of pressure with a production problem so be sure to take a deep breath before you start.
This may not have been the 'quick and simple' answer you were looking for but it is a 'rock solid' way of finding out what happened.
Best of luck
PM |
|
| Back to top |
|
|
Ed Goodman
Active Member
Joined: 08 Jun 2011
Posts: 556
Location: USA
|
|
|
|
DJ causes I've seen
-Code did not check the status of the GHU call, which failed
-GHU was a path call, but did not get all the segments
-GHU call has a weird command code
-REPL is on segment that had the key changed (it's probably this)
-The SSA got changed between the two calls
Easy way to test it? Use DLI TRACE!
Add to bottom of DFSVSAMP card:
DLITRACE COMP
Add new JCL DD:
//DFSTROUT DD SYSOUT=*
It should become obvious what happened. |
|
| Back to top |
|
|
|
|
