1 of 1 people found this helpful
You could try placing the CTRNORST DD statement in every step of the job. For more information see 'Control-M/Restart User Guide' - Indicating non-restartable steps.
The only other way I can think of is via security, however rerun security is at an owner level so it might not be granular enough:
1 of 1 people found this helpful
1. Use a Control or Quantitative Resource.The Resource would be consumed by the job and released it after completing successfully. If the job abends, the Resource would unavailable until manually reset. so any restart should fail. Not 100% about this idea, needs testing.
2. Update the job's alert to inform the operator that manual restarts aren't allowed.
In my shop, manual intervention instructions are described in the job's Operational Documentation (maintained by the application support teams) which the operators refer to when investigating job failures and recovery actions. If the job can't be manually restarted, it would be indicated in the documentation.
Thank you very much for your reply. I have read about this in CTM/Restart manual. Anyway, I have tried to test it for non restartable job. My object is to secure job to be restarted form any step. We had already two production incidents, when the operator wanted restart job from abended step. Unfortunatelly, this job is non restartable, because of the name of a procedure in a step and it is unable to restarted froim abended steps.
Because the operator is already in Restart menu, he need to change Confirm to N, if he want to cancel the restart. Unfortunatelly, the opoarator just click on F3 function key (cancel, exit), which behave as ENTER and confirm restart from the beginning.
I have tested NONRESTARTABLE STEP with CTRNORST DD. It works fine, if you choose to restart job from specific step. But if you do restart job from the beggining, this doesn't work.
Anyway, identification of non-restartable steps makes a sence to secure job to be restarted from any step.
Yes that's correct. A 'restart' and a 'rerun' are treated differently. I think the only way you can avoid the rerun is:
- Use of a resource like Andrew Wong suggested
- Perhaps include a step that references a dataset using the run number as part of the dataset name (PROD.CHECK.R%%RN), and only PROD.CHECK.R00001 is defined so anything else will abend
- have some conditional logic in the JCL to test the run number %%RN
- Use an IOATEST step at the start to set a return code equal to %%RN and setup COND statements for subsequent steps so they don't run if the IOATEST is greater than C0001
One last idea along the lines of Andrew's.
Have a 'not' in condition on the job. When the job abends, the 'not' condition is added. When the operator performs a rerun the job will be in a wait state and the condition could have a name like 'PROD-DO-NOT-RERUN-UNDER-ANY-CIRCUMSTANCE' :-)
thank you for your ideas. We already use Control resources for this kind of jobs to secure jobs needs to END OK before next run is submited on specific time.
I am sure you are right. It would be possible to use resources for this kind of request.
About the jobs alert. Do you mean WTO message to operator? Something like : ERROR - This job is NONRESTARTABLE!!! Contact SUPPORT....
WTO or WTOR message would work fine. It might be combined with setting a variable, for example number of run, as Paul have mentioned.
Unfortunatelly, we have no Operational Documentation in our shop:( We should start to think about something like that.
Thank you very much
Great idea about NOT condition on the job, if it END NOT OK: I love it! It is so simple and works fine. About your idea about refering to dataset - it also works fine.We are allocating new dataset when the jobs started - *.%%JOBNAME. Of you restart it, it just failed on duplicities.
Conditional logic is next level of security. I lookinbg forward to try it !
Thank you very much for a great ideas!!!