FLASH - PI93525 (UI55004/UI55005) requires special handling

Content

PTF UI55005 – PI93525 INSTALLATION

          First check whether the PTFs for PI93525 and related HIPER maintenance is already

installed -- see https://www-01.ibm.com/support/docview.wss?uid=ibm10735855 

1. Installation steps for PTF UI55004/UI55005 (Apar PI93525)

• Purge the controller (/P xxxx)   after submitting a REPLAN job with TYPRUN=HOLD or ensuring that the REPLAN JCL is available to be submitted outside of IWSz
• Apply PTF UI55004/UI55005  and also this additional related HIPER maintenance:
•   PTF             APAR

  UI56464    PI98960

  UI59216     PI98362 

  UI58124     PH01229

 UI58650      PH02407 

• Run a REPLAN with CHECKSUBSYS(NO) in BATCHOPT 

NOTE :  If you are running an end-to-end environment with fault-tolerant capabilities, comment out  TPLGYPRM. If you are also using the DB2 archive history, comment out JRUNHISTORY. (See the PARM library of the EXTEND job for the plan).

• Set JOBSUBMIT(NO) and FTWJSUB(NO) in JTOPTS

• Restart the controller with CURRPLAN(CURRENT) in JTOPTS.
• Check all is ok and then set all the SUBMITs back to YES.  For example do some MCP (modify current plan) activity and check for any problems afterwards.

NOTE:  If you are running an end-to-end environment with fault-tolerant capabilities - If you modified TPLGYPRM and JRUNHISTORY, set them to their original values and run a CP REPLAN or CP EXTEND  (PGM=EQQDRTOP or PGM=EQQDNTOP ). 

NOTE: If you are running a STANDBY controller on another LPAR, or move the controller to another LPAR as part of a "rolling IPL" sequence you must take care that each LPAR has the UI55005 code installed on it.  Once you have started running your current plan with the UI55005 code installed you cannot go back to running the controller WITHOUT the UI55005 code installed unless you follow the BACKOUT procedure below

 NOTE:  If you migrate from an older release to 9.3 with UI55005 installed, or any higher release that has UI55005 in its base code you must follow the special MIGRATION PROCEDURE detailed below 

RECOVERY ACTIONS (if needed)

2.  If you applied the PTF UI55004/UI55005 WITHOUT run a REPLAN  you could take one of following abends:

1. U3999 in MCP
2. U3999 in EM

Following are the steps to run in such situation:

• Purge the controller (/P xxxx) 
• Run replan with CHECKSUBSY(NO)  in BATCHOPT , 

NOTE :  If you are running an end-to-end environment with fault-tolerant capabilities, comment out TPLGYPRM. If you are also using the DB2 archive history, comment out JRUNHISTORY. (See the PARM library of the EXTEND job for the plan).

• Set JOBSUBMIT(NO) and FTWJSUB(NO) in JTOPTS
• Restart the controller with CURRPLAN(CURRENT) in JTOPTS.  

• Check all is ok and then set all the SUBMITs back to YES.

NOTE: If you are running an end-to-end environment with fault-tolerant capabilities - If you modified TPLGYPRM and JRUNHISTORY, set them to their original values and run a CP REPLAN or CP EXTEND  (PGM=EQQDRTOP or PGM=EQQDNTOP).

 3. If you did NOT apply ALL the PTFs listed in step 1  ONE OF FOLLOWING situations MIGHT HAPPEN 

 ABEND IN NMM 0C4 or 878 -  Solved by installing the HIPER APAR PI98960   PTF  UI56464 

ABEND MCP 0C4 – Solved by installing the HIPER APAR PH01229   PTF  UI58124

 Message in CP REPLAN or CP EXTEND EQQMLOG:

EQQ0954E GU   FAILED FOR OCP  LOGICAL FILE, CALLING MODULE IS EQQDPOLT         

 or messages such as the following in the CONTROLLER EQQMLOG: 

EQQN043E UNSUCCESSFUL VSAM I/O REQUEST. DETAILED INFORMATION FOLLOWS:         

EQQN043I ACTIVE TASK IS GS EXECUTOR 01  . LOAD MODULE IS EQQGSBEX             

EQQN043I I/O REQUEST IS FROM EQQGSGAO 18/04/05 11.51.26 UI55005  AT OFFSET +0222

EQQN043I REQUESTED FUNCTION IS GU   ON LOGICAL FILE CP  , DDNAME EQQCP1DS       

EQQN043I VSAM RETURN CODE IS 8, REASON CODE IS 0016, KEY IS 03.ÚK.              
EQQN043I                               HEXADECIMAL ZONES    FF0FD0444444        
EQQN043I                               HEXADECIMAL DIGITS   030E20000000  

These messages indicate some CP corruption may have occurred because UI58124 was not applied. This procedure can be followed:

 a) stop controller                                            
 b) Install UI58124                                                       
 c) In JTOPTS statement set JOBSUMIT(NO)                                  
 d) start controller with currplan(new)                                   
    This will create a new CP from NCP and JT datasets                    
    (can take a while when having big CP)                                 
 e) After the controller is up and running, Run a replan job              
 f) change again from currplan(new) to currplan(current)               

1. 4. STEPS FOR ROLLING BACK FROM PTF UI55005 – PI93525 in case of problems

In case after installing the PTF UI55005, you might want to roll back because one abend occurred you can perform the following steps:

• Purge the controller (/P xxxx)
•  At this point is where the fall back to the OLD (pre UI55005) maintenance is done.  This may require an IPL:
• Point back to the pre-UI55005 level SEQQLMD0 - this could require that an IPL is performed.  If you do IPL be sure that the controller is not started after the IPL  since the REPLAN must be run first (before starting the controller) 
• Set JOBSUBMIT(NO) and FTWJSUB(NO) in JTOPTS
• Run a REPLAN with VALEACTION(WARN) and CHECKSUBSY(NO)

NOTE :  If you are running an end-to-end environment with fault-tolerant capabilities, comment out TPLGYPRM. If you are also using the DB2 archive history, comment out  JRUNHISTORY. (See the PARM library of the EXTEND job for the plan).

• If the REPLAN ends with RC > 0  and there are some occurrences corrupted listed in the output:
  a)  restart the controller by setting CURRPLAN(CURRENT) in JTOPTS and remove the occurrences after verifying the involved job status and dependencies
  b) Run a REPLAN resetting VALEACTION(ABEND) and CHECKSUBSY(YES)
• Check all is ok and then set all the SUBMITs back to YES.

NOTE: If you are running an end-to-end environment with fault-tolerant capabilities - If you modified TPLGYPRM and JRUNHISTORY, set them to their original values and run a CP REPLAN or CP EXTEND  (PGM=EQQDRTOP or PGM=EQQDNTOP ) .

1. 5. STEPS FOR MIGRATION to 9.3 or higher with UI55005  already installed

If you migrate from any release older than 9.3  to a 9.3 environment where UI55005 is installed (or any release HIGHER than 9.3 and the release being migrated from does not already include UI55005) there  are special considerations because there is no way to run a REPLAN with the controller down prior to starting the controller on the new release.  Consider if possible backing out the UI55005 PTF first (for 9.3 only) then performing the migration and then implement the UI55005 PTF as outlined above.   If this is not possible (including migration to IWSz higher than 9.3) then follow this procedure:

• Ensure that the IWSz 930 Code level to be installed (if not the base) includes all the PTFs listed above (UI56464, UI58124, << UI59216, UI58650 >>)
   and all the HIPER APARS.
• Run all the migration steps as normal
• Start for the first time the Controller after the migration, as normal, keep the job (ALL the kinds of jobs) submissions off (set JOBSUBMIT(NO)  FTWJSUB(NO)….. in JTOPTS)
• Verify that the migration of the data went ok BUT do not perform any Modify Current Plan action (and reduce the possibility to have MCP events like status changes or ETT processed in that time frame).
• Then purge it (check that it closes in a clean way)
• Follow all the steps as indicated in the Flash:
  • Run replan with CHECKSUBSYS(NO)  in BATCHOPT ,
    NOTE :  If you are running an end-to-end environment with fault-tolerant capabilities, comment out TPLGYPRM. If you are also using the DB2 archive history, comment out JRUNHISTORY. (See the PARM library of the EXTEND job for the plan).
  • Restart the controller with CURRPLAN(CURRENT) in JTOPTS.
  • Check all is ok and only then set all the SUBMITs back to YES.
    NOTE: If you are running an end-to-end environment with fault-tolerant capabilities - If you modified TPLGYPRM and JRUNHISTORY, set them to their original values and CP REPLAN or CP EXTEND  (PGM=EQQDRTOP or PGM=EQQDNTOP ) .
  • Once restarted all should work. If instead it is not, and IWSz is getting any of the known problems (U3999, S0C4, S0C1…), it would be needed to perform the recovery actions as indicated above (item 2).

This special migration process should be tested on a non-production environment first (such as a demo or "sandbox" system or test system) and verify all the steps, before migrating  a production system.  Also this migration should be scheduled at a time with as little activity as possible to reduce the possibility of some ETT or PIF process updating the current plan before the REPLAN is run.