PM69655: AOR BECOMES QUIESCED TO WORKLOAD WHEN LOCAL TOR IS STARTED

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• ERROR DESCRIPTION:
  In an environment consisting of 2 lpars, LPARA and LPARB, the
  following scenario occurs:
      On lparA, start CMAS, WUI and AORs with DYNROUTE=NO
      On lparB, start CMAS, WUI and TOR
      The WLMAWAOR view shows the AORs as QUIESCED in both WUIs
      On lparB, ACTIVATE AORs via WLMAWAOR view
      Verify WLMAWAOR view in both WUIs shows AORs as active
      On lparA, start TOR
      On lparA, WLMAWAOR now shows AORs as Quiesced
      On lparB, WLMAWAOR now shows AORs as Active
  
  There is a discrepancy between the two LPARs and the status of
  the AORs baswed on when the TOR is started from where it
  obtains the status of the AOR(s).
  
  
  
  
  
  
  Additional Symptom(s) Search Keyword(s): KIXREVGJT
  

Local fix

• Run with DYNROUTE=YES
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICSPlex SM V4R2M0 Users                 *
  ****************************************************************
  * PROBLEM DESCRIPTION:    You define your target regions with  *
  *                      'Target region active at startup'       *
  *                      (DYNROUTE) set to "No".  When bringing  *
  *                      up your workload, you start a routing   *
  *                      region (TOR) on LPAR A and one or more  *
  *                      target regions (AORs) on LPAR B.  After *
  *                      all MASes have initialized and a new    *
  *                      active workload has been created, owned *
  *                      by the CMAS on LPAR A, you log on to    *
  *                      the Web User Interface (WUI) on LPAR A  *
  *                      and activate your target regions.  You  *
  *                      see that the target regions are seen to *
  *                      be active from the WUI on both LPARs.   *
  *                         You then start a routing region on   *
  *                      LPAR B.  In the joblog of the CMAS on   *
  *                      that LPAR you see messages:             *
  *                      .                                       *
  *                         EYUWI0080I  WLM Workload query       *
  *                              process for context (myplex)    *
  *                              has been started - directed to  *
  *                              CMAS (mycmasa).                 *
  *                      .                                       *
  *                      and                                     *
  *                      .                                       *
  *                         EYUWI0081I  WLM Workload build       *
  *                              process for context (myplex)    *
  *                              has been completed - initiated  *
  *                              by CMAS (mycmasb).              *
  *                      .                                       *
  *                      For each target region on LPAR B, you   *
  *                      see message:                            *
  *                      .                                       *
  *                         EYUWM0437I  Target region (mytarget) *
  *                              has been quiesced for Workload  *
  *                              (myspec) because it is already  *
  *                              quiesced for Context (myplex).  *
  *                      .                                       *
  *                      When you examine the target region's    *
  *                      state through the WUI server on LPAR A  *
  *                      they are seen to be active, but from a  *
  *                      WUI server on LPAR B the target regions *
  *                      they appear to be quiesced.             *
  ****************************************************************
  * RECOMMENDATION: After applying the PTF that resolves this    *
  *                 APAR, all CMASes must be recycled to pick    *
  *                 up the new code.  Note that regions do not   *
  *                 need to be brought down and restarted at     *
  *                 the same time.                               *
  ****************************************************************
     When a workload is imported into a CMAS an AOR Descriptor
  (WAOR) is built for each active target region in the workload.
  Its state is set from data requested from Topology.  Message
  EYUWM0437I is issued if DYNROUTE=NO was specified in the CSYSDEF
  resource for the region.  Later, module EYU0WMQU (WMQU - Update
  Queried Workload) is called to update the initialized WAORs with
  information from the CMAS from which the workload is being im-
  ported.  However, a logic error causes the AOR status to reflect
  the initial state of the AOR as defined by Topology, not the
  current state in the imported data.
  

Problem conclusion

•    Module EYU0WMQU was modified to set the AORs state from
  the imported data, and to issue one of messages EYUWM0423I
  or EYUWM0436I if the AOR's final status is different than
  the value set when the WAOR was initialized.
  

Temporary fix

• FIX AVAILABLE BY PTF ONLY
  

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  UK81283

Modules/Macros

•    EYU0WMQU
  

Fix information

• Fixed component name

  CICS TS Z/OS V4

• Fixed component ID

  5655S9700

Applicable component levels

• R70M PSY UK81283

     UP12/08/25 P F208

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.