Problem with Multiple instance job
Moderators: chulett, rschirm, roy
Problem with Multiple instance job
Hello friends,
We have a multiple instance job which is triggered 3 times, in sequence, by 3 different Sequencers.
JOB A
SEQUENCE1
SEQUENCE2
SEQUENCE3
The problem is once in a while the control of the job is not transfered to the next SEQUENCER.
For example, on a given day
JOB A is triggered by SEQUENCE1 and after completion it (JOB A) is triggered by SEQUENCE2 and then by SEQUENCE3
The problem is sometimes JOB A which is triggered by SEQUENCE1 shows completed in DataStage Designer but the Director shows as it is still running.
Meanwhile SEQUENCE2 waits for ever to trigger the job
Any ideas what's causing this?
Thanks a lot in advance
Yamini
We have a multiple instance job which is triggered 3 times, in sequence, by 3 different Sequencers.
JOB A
SEQUENCE1
SEQUENCE2
SEQUENCE3
The problem is once in a while the control of the job is not transfered to the next SEQUENCER.
For example, on a given day
JOB A is triggered by SEQUENCE1 and after completion it (JOB A) is triggered by SEQUENCE2 and then by SEQUENCE3
The problem is sometimes JOB A which is triggered by SEQUENCE1 shows completed in DataStage Designer but the Director shows as it is still running.
Meanwhile SEQUENCE2 waits for ever to trigger the job
Any ideas what's causing this?
Thanks a lot in advance
Yamini
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Look in the log for JOB A. Look for processes associated with JOB A (in Cleanup Resources). Has JOB A aborted without being able to update its status and log records? (If so, you won't find any process associated with it, in which case clear its status file and look in &PH& directory for any error report.)
Does each sequence (note: "sequence", not "sequencer") run the job with the same invocation ID?
Does each sequence (note: "sequence", not "sequencer") run the job with the same invocation ID?
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
If you do find processes executing, look at before/after job/transformer routine calls. If the transformer is executing an after routine, the links may be green but the call could still be open. Also, look at any large log file purging that could be happening. Your &PH& directory could be full and you're waiting on the job to wrap up. Make sure that any before/after routines aren't trying to lock some resource and hanging on that.
We've seen/heard/read a lot of ways valid jobs "hang".![Shocked :shock:](./images/smilies/icon_eek.gif)
We've seen/heard/read a lot of ways valid jobs "hang".
![Shocked :shock:](./images/smilies/icon_eek.gif)
Kenneth Bland
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
Rank: Sempai
Belt: First degree black
Fight name: Captain Hook
Signature knockout: right upper cut followed by left hook
Signature submission: Crucifix combined with leg triangle
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
"&" is a meaningful character to the shell. You must escape or quote it.
or
Code: Select all
cd \&PH\&
Code: Select all
cd '&PH&'
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
It's extremely unusual that &PH& is empty but for these two files. Do not delete .uvnolsmap (since it specifies the NLS map to be used for file names in that directory). If &PH& is otherwise empty you can delete .Type1, which is an indicator to DataStage how to treat this directory in BASIC.
If &PH& is empty that suggests that CLEAR.FILE has been executed against it. Ordinarily every job run will leave a file in &PH&. The name of that file is DSD.RUN_xxxxx_yyyyy where xxxxx and yyyyy are the time and date (in internal format) that the job was run.
Can you check the individual job logs to determine whether they actually ran, and the invocation IDs? Can you also post the second last entry from the job sequence log (the "summary" event)?
If &PH& is empty that suggests that CLEAR.FILE has been executed against it. Ordinarily every job run will leave a file in &PH&. The name of that file is DSD.RUN_xxxxx_yyyyy where xxxxx and yyyyy are the time and date (in internal format) that the job was run.
Can you check the individual job logs to determine whether they actually ran, and the invocation IDs? Can you also post the second last entry from the job sequence log (the "summary" event)?
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
InvocationID should be in the "job started" entry in the log.
Please advise, when reporting errors, whether kill has been used. It opens an entire extra set of possibilities.
Even better, don't use kill on DataStage processes.
Please advise, when reporting errors, whether kill has been used. It opens an entire extra set of possibilities.
Even better, don't use kill on DataStage processes.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.