A possible solution to eliminate these difficulties is to add restart instructions in all appropriate Xnode members, so that these instructions are available in any job listing of any Xnode job that may have to be restarted.

Any failed Xnode job can then be restarted by operations control people, assuming they use a properly authorized TSO userid to do so. All that's needed (to know which member in which PDS is to be submitted) is to read the beginning of the job listing of the failed job.

Obviously you don't want to hardcode everything in each of the skeletons (CMN10, CMN11, CMN14, ... CMN64, CMN65) for which you want such restart instructions to be included. Instead you should implement this by writing a skeleton (let's call it ASZINFO) which is included where appropriate. Such skeleton should then use (display) specific skeleton variables made available during the creation of the Xnode datasets. The actual skeleton variables to be used can be found by looking in appropriate Xnode members for the values you want to get included (like the staging DSN, the MVS system ID, etc). Once you found these values, trace them back to the skeleton where they were created from. The variable(s) in the skeleton that generated the value you were looking for, is also the variable to use in your restart instructions.

Two more challenges to complete this topic:

1. How do you know in which skeletons to include such skeleton like ASZINFO in the sample above? The answer is straight forward: scan all Xnode skeletons that embed either of these skeletons: CMN$$SJN, CMN$$JNM or CMND2J. From the list in your scan results, decide which of these skeletons you really want the restart instructions to be included. At least you should consider the main skeletons like CMN10, CMN11, CMN20, CMN21, CMN30, CMN50, CMN55 and CMN65. And probably also the ones like CMN11, CMN14, CMN15, etc. But do you really want the include also in CMN18 or CMN19? But before you perform an embed of your ASZINFO-like skeleton in all of them, keep in mind that each embedded will (slightly) influence the resources and time needed to create the Xnode DSNs. Maybe you only want to embed the ASZINFO-like skeleton in those skeletons for which you ever got a support call (in the middle of the night)?
2. In which location should the embed statement for the ASZINFO-like skeleton be located? Another straight forward answer: Right after the embed statement of the skeleton CMN$$SJN, CMN$$JNM or CMND2J (so close to the beginning of the skeleton).

Checkout the Z-Files section to just download Dr.Chgman's solution for this issue.

VIEW     CMNP.R.STGRMT.CDXB.#001079.X.PRDC(CDXB2079) - 01.0 Columns 00001 00072
Command ===>                                                    Scroll ===> CSR
000022 //*)IM CMN$$SJN END
000023 //*)IM CMN20
000024 //*)IM ASZINFO - RESTART INFORMATION FOR OPERATIONS CONTROL
000025 //*
000026 //* ******************************************************************
000027 //* TO RESTART THIS JOB:
000028 //*    - LOGON TO THE MVS SYSTEM CMC.PROD
000029 //*    - RESTART THE JOB IN CMNP.R.STGRMT.CDXB.#001079.X.PRDC(CDXB2079)
000030 //*      USING AUTHORIZED USER ID CCMNPRD FROM THE FAILED STEP
000031 //*
000032 //* FOR MORE INFO CALL CHANGE MAN SUPPORT:
000033 //*    - PHONE: 0123/44.55.66 (BUSINESS HOURS)
000034 //*    - PAGER: 0123/11.22.33
000035 //* ******************************************************************
000036 //*
000037 //*EOF ASZINFO - RESTART INFORMATION FOR OPERATIONS CONTROL