7 Replies Latest reply on Jun 24, 2019 3:12 AM by Pavel Grund

    NonRestartable job in Control-M Restart for z/OS

    Pavel Grund
      Share:|

      Hello to everyone,

       

      We had already the second production incident, when somebody Restarted job, which should not be restarted. Does anyone of you have already been thinking about the jobs, which are defined in CTM and should not been restarted? There are some conditions which should be always TRUE.

       

      The job may run only once a day

      In case of an abend, there should be possible only manual interventionj instead of usage CTM-Restart ( Nonrestartable steps etc.). After the correction of problem, Force OK would be fine.

       

      Does some of you have any idea?

       

      Thank you

       

       

      Pavel

        • 1. Re: NonRestartable job in Control-M Restart for z/OS
          Paul Robins

          Hi Pavel,

          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:

          $$JOB2RRN.qname.owner

          Regards,

          Paul.

          1 of 1 people found this helpful
          • 2. Re: NonRestartable job in Control-M Restart for z/OS
            Andrew Wong

            Pavel,

             

            Ideas:

            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.

             

            Andrew

            1 of 1 people found this helpful
            • 3. Re: NonRestartable job in Control-M Restart for z/OS
              Pavel Grund

              Hello Paul,

               

              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.

               

              Thank you

               

              Pavel

              • 4. Re: NonRestartable job in Control-M Restart for z/OS
                Paul Robins

                Yes that's correct. A 'restart' and a 'rerun' are treated differently. I think the only way you can avoid the rerun is:

                • Security
                • 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
                • 5. Re: NonRestartable job in Control-M Restart for z/OS
                  Paul Robins

                  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' :-)

                  • 6. Re: NonRestartable job in Control-M Restart for z/OS
                    Pavel Grund

                    Hello Adrew,

                     

                    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

                     

                    Best regards

                     

                    Pavel

                    • 7. Re: NonRestartable job in Control-M Restart for z/OS
                      Pavel Grund

                      Dear Paul,

                       

                      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!!!

                       

                      Best regards

                       

                      Pavel