IBM Workload Automation & Workload Scheduler

 View Only

 Behaviour not expected when a job fails

Francis Rakoto's profile image
Francis Rakoto posted 04/22/26 11:46 AM

I created a jobstream that needs to be run from 9:00 AM to 11:00 PM every day. this jobstream must launch a job every 10 min so in IWS  i put the below definition :

SCHEDULE TEST_JOBSTREAM 
 ON RUNCYCLE EVERYDAY
 AT 0900 
 CARRYFORWARD
 LIMIT 10
ONOVERLAP ENQUEUE
:
TEST_JOB
  UNTIL 2300 ONUNTIL SUPPR 
  EVERY 0010

 END

When the Jobstream is launched and the jobs end with success every 10 mins, everything is fine, but once the job fails, the behavior describe below is not what i expected:

  • the satus of the jobstream stays in "Ready"
  • the job status is in "Error"
  • Even the predecessor job fails in error, 10 min after another job is launched and it continue like this until the end.

So can you please tell me the modification that needs to be done to have the following behaviour  when one job fails : 

  • the status of the jobstream is in "Error" not in "Ready" (the best scenario is "Hold")
  • the job status is in "error" and the next job is launched after 10 min but stay in "Hold" 

thank you by advance for your help

Veronica Tesei's profile image
Veronica Tesei posted 04/27/26 09:28 AM

Hello Francis!

Based on your requirements to interrupt the execution flow and change the job stream status upon failure, the recommended solution is to use the ABENDPROMPT keyword.
By adding a prompt to the job definition, you can force the scheduler to stop the cycle until a manual intervention occurs. Update your definition to include the ABENDPROMPT and RECOVERY STOP as shown below:

SCHEDULE EU-HWS-LNX104#TEST_JOBSTREAM
DESCRIPTION "Added by composer."
ON RUNCYCLE RC1 "FREQ=DAILY;"
AT 0900
CARRYFORWARD
LIMIT 10
ONOVERLAP ENQUEUE
:
EU-HWS-LNX104#TEST_JOB
 DOCOMMAND "invalid
command"
 STREAMLOGON twsuser
 DESCRIPTION
"Added by composer."
 TASKTYPE WINDOWS
 RECOVERY STOP
  ABENDPROMPT
"Job failed!"
 UNTIL 2300
 EVERY 0005
END

In this way, when a job instance fails, the following occurs:

  • The job stream status will move to STUCK. This indicates the flow is blocked due to an internal failure, fulfilling your requirement for a state similar to "HOLD" or "Error."
  • The EVERY frequency is interrupted. The next scheduled instance will not launch as long as the prompt is unanswered.
  • The job will remain in ABEND status.
  • Once an operator manually responds to the prompt, for example, confirming the error is managed, the job stream status returns to READY. The scheduler will then wait for the EVERY interval and the next job instance is scheduled.

Regarding your requirement: 'the job status is in "error" and the next job is launched after 10 min but stay in "Hold"', we would like to request a brief clarification.
In IWS, when a job is defined with an EVERY interval, the next instance is automatically rescheduled. However, the HOLD status is typically a state that lasts only a few seconds while the scheduler prepares the next execution.
Could you please clarify if you expect the job to remain in HOLD indefinitely (requiring manual intervention to release) or if you are referring to a different specific behavior?

Regards, 

Veronica Tesei

Francis Rakoto's profile image
Francis Rakoto posted 05/04/26 11:36 AM

Hello Veronica,

Thank you for your reply. 

Regarding your question: Could you please clarify if you expect the job to remain in HOLD indefinitely (requiring manual intervention to release) or if you are referring to a different specific behavior?

Yes the job must remain in HOLD indefinitely until a manual intervention will release it.

FYI, the definition of my job is a little bit different because it is an "executable" instead of  a"Windows task" (behind the "executable" déclaration, it is an UNIX shell script, so I really don't understand why they have declared as a "task"...)

The only remaining issue is the prompt but it is ok because once there is an error, the job stop "on error" and the jobstream is "stuck".

And after correction, in DWC, we can "re-execute" the job and everything works correctly.

Thank you very much for your help Veronica.

Regards,

Francis R

Related Content