IBM Support

PM62717: NRM STATE FLAG NOT CLEARED AFTER MAS RESTART NRM STATUS IGNORED WHEN CALCULATING WLMATARG_ROUTEWGHT ATTRIBUTE

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • There are two problems which may be or may not be interconnected
    to each other:
    1) The NRM MAS condition of and abended/cancelled region
       does not go away after the region has been restarted and
       causes the region to be treated as "unhealthy" although
       everything is fine.
    2) CICS Explorer and WUI return display different WLM
       "routing weight" values for the target reagion that is
       erroneously treated as "unhealthy".
    

Local fix

  • *
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All CICSPlex SM V4R2M0 Users                 *
    ****************************************************************
    * PROBLEM DESCRIPTION: -  When a CPSM WLM target region is     *
    *                         terminated while in a non-responsive *
    *                         MAS (NRM) state, the state flag is   *
    *                         not cleared when the MAS restarts.   *
    *                         This can result in invalid routing.  *
    *                                                              *
    *                      -  The non-responsive MAS (NRM) state   *
    *                         of a CPSM WLM target region is       *
    *                         ignored when calculating the         *
    *                         WLMATARG_ROUTEWGHT attribute.  This  *
    *                         will not result in invalid routing.  *
    ****************************************************************
    * RECOMMENDATION: After applying the PTF that resolves this    *
    *                 APAR, all CMASes and MASes must be           *
    *                 restarted.  Note that the restarts do not    *
    *                 need to occur at the same time.              *
    *                                                              *
    *                 Additionally, all API programs that access   *
    *                 the EMSTATUS resource table should be        *
    *                 reassembled or recompiled pointing to the    *
    *                 libraries distributed by this APAR.          *
    ****************************************************************
    -  When a health sickness occurs in a CPSM WLM target region,
       the MAS's AOR descriptor control block (EYURWAOR) is marked
       to indicate this.  If the health condition exists when the
       region is terminated or the MAS agent is terminated in the
       region, the flag remains set.  When the region restarts or
       the MAS agent is restarted in the region, the first EMSTATUS
       resource table created by the MAS should reflect the current
       health status of the region.  This is passed to method
       EYU0WMAM (WMAM) in all CMASes that manage the plex that the
       MAS is associated with.  WMAM updates the EYURWAOR for the
       MAS appropriately.
    
       The EMSTATUS resource tables produced by a MAS contain the
       current health state for the maxtask (MXT), short-on-storage
       (SOS), system dump (SDUMP), transaction dump (TDUMP) and
       stall health conditions only.  Since it does not contain the
       current health state of the non-responsive MAS (NRM)
       condition, WMAM will not update the EYURWAOR's NRM status.
       If the MAS's EYURWAOR indicated that the MAS was in an NRM
       state when it terminated or when its MAS agent terminated, it
       will indicate it is in NRM state when it is restarted or its
       MAS agent is restarted, even if it is not NRM.  Since the
       EYURWAOR NRM flag is one of the factors used by CPSM WLM
       routing regions to determine whether or not to route to the
       target region, this can result in invalid routing.
    
    
    -  When WLMATARG records are requested, method EYU0WABB (WABB)
       is called to build the records.  While WABB does check the
       NRM state while building the record, it does not update the
       ROUTEWGHT attribute if the state is true.
    
       Note that this only affects the WLMATARG_ROUTEWGHT attribute.
       Since the WLMATARG table is not used by CPSM WLM routing
       regions to determine whether or not to route to target
       regions, this does not have any affect on routing decisions.
    

Problem conclusion

  • -  Updates have been made to include the current NRM state in
       EMSTATUS resource tables delivered by a MAS, and to use this
       to update the EYURWAOR for a MAS:
    
       -  Method EYU0CSLC (CSLC) and its method argument list (MAL)
          EYUZCSLC, have been modified to include a new function,
          LNKINQ, that can be called by a MAS to determine its NRM
          state.
    
       -  The EMSTATUS resource table has been modified to update
          the SYSCONDS attribute to contain a bit setting to
          indicate the current NRM state of the MAS.  The new bit
          flag is EMSTATUS_SYSCONDS_NRM.  The bit will be on if the
          current NRM state is true, and off if the current NRM
          state is false.
    
       -  Method EYU0NLHD (NLHD), which runs in a MAS every 15
          seconds and builds the EMSTATUS record which it then
          passes to its CMAS, has been updated to call CSLC to
          inquire on the current NRM state of the MAS.  It will then
          update the EMSTATUS record to indicate the current state.
    
       -  Method EYU0WMAM (WMAM), which runs in a CMAS and processes
          EMSTATUS records, has been modified to check the new
          EMSTATUS_SYSCONDS_NRM flag bit, and update the EYURWAOR
          control block for the MAS accordingly.
    
    -  Updates have been made to method EYU0WABB (WABB) to properly
       increase the WLMATARG_ROUTEWGHT value for a MAS if its
       EYURWAOR indicates that the MAS is in NRM state.
    

Temporary fix

  • FIX AVAILABLE BY PTF ONLY
    

Comments

APAR Information

  • APAR number

    PM62717

  • Reported component name

    CICS TS Z/OS V4

  • Reported component ID

    5655S9700

  • Reported release

    70M

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2012-04-18

  • Closed date

    2012-06-27

  • Last modified date

    2012-07-02

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

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

    UK79875

Modules/Macros

  •    CJA0NLHD CJB0NLHD CJC0NLHD EYUA2507 EYUC2507
    EYUL2507 EYUP2507 EYUT2507 EYUY2507 EYU0CSLC EYU0NLHD EYU0WABB
    EYU0WMAM EYU9CMRU EYU9CMR3 EYU9CMR4
    

Fix information

  • Fixed component name

    CICS TS Z/OS V4

  • Fixed component ID

    5655S9700

Applicable component levels

  • R70M PSY UK79875

       UP12/07/02 P F206

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.

[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSGMGV","label":"CICS Transaction Server"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"4.2","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"4.2","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
02 July 2012