IBM Support

PK56207: PE28633 OPERATE VIEWS MAY PRODUCE INCONSISTENT RESULTS. RESOURCE S MISSING.

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • PE28633-F708
    After applying PTF UK28633 you see inconsistent results when
    displaying resources either from the EUI or the WUI. The
    inconsistency occurs when you connect to a different CMAS,
    your request for the same resource may be missing or return
    a different number of records.
    Additional Keyword(s) and Symptom(s): The base signature for a
    resmap is nulls.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All CICSPlex SM V3R2M0 Users                 *
    ****************************************************************
    * PROBLEM DESCRIPTION: Operational resources may be missing    *
    *                      from WUI displays or from API result    *
    *                      sets, and RTA events may not trigger    *
    *                      correctly, after applying PTF UK28633   *
    *                      for APAR PK49141.                       *
    ****************************************************************
    * RECOMMENDATION: After applying the PTF that resolves this    *
    *                 APAR, all CMASes must be restarted.  Note    *
    *                 that the restarts do not need to occur at    *
    *                 the same time.                               *
    ****************************************************************
    CPSM builds Topology resource maps to indicate what resources
    are installed in a MAS.  When an API/WUI/RTA request is made for
    a specific resource type , the resource maps are queried to
    determine where to send the request to retrieve the information.
    
    The maps are created for each resource type by the connecting
    CMAS, and sent to joining CMASes, so that all CMASes that help
    to manage a MAS can determine where to send API/WUI/RTA
    requests.  To cut down on the amount of traffic that is shipped
    between the connecting and joining CMASes, the maps are written
    (hardened) to the local data repository (EYUDREP).  To ensure
    that the maps are correct between the connecting and joining
    CMASes, each resource map has a signature, which indicates the
    SYSID of the CMAS that created the maps, along with the
    timestamp of when the maps were created.  When a CMAS joins a
    MAS, it compares the signatures of its hardened maps with the
    signatures of the connecting CMAS.  If the signatures match, the
    joining CMAS uses its hardened maps.  If they do not match, the
    joining CMAS requests the connecting CMAS's maps be sent during
    the join process.
    
    With UK28633, a connecting CMAS may create a null signature for
    a specific resource map for a MAS.  If this occurs, then the
    joining CMAS will not create maps for that resource type for
    that MAS.  If an API/WUI/RTA request is made for that resource
    type for that MAS through the joining CMAS, then no data will be
    returned for that resource class.  If subsequent resources are
    installed in the MAS for that resource type, the joining CMAS
    will build and harden an incomplete map for that resource type.
    This can result in some but not all resources being displayed
    for the MAS for that resource type.
    

Problem conclusion

  • Method EYU0XCRB (XCRB), which retrieves the hardened maps from
    the EYUDREP, has been updated to correct the logic flaw in
    UK28633 that can result in a null signature being built in the
    connecting CMAS.
    
    To ensure that any incorrect maps created by the application of
    UK28633 are fixed, the following changes have been made:
    
    -  Method EYU0TSSC (TSSC), which is called in the connecting
       CMAS, will verify that any existing signatures are non-null.
       If a signature is null, TSSC will update the signature to a
       valid value.
    
    -  Method EYU0TSRA (TSRA), which builds the list of map
       signatures that is passed from the connecting CMAS to the
       joining CMASes, has been updated to turn on an indicator to
       inform the joining CMASes that the maps on the connecting
       CMAS are valid.
    
    -  Method EYU0TSSJ (TSSJ), which is called in the joining CMAS,
       has been updated to determine if the connecting CMAS has
       valid maps.  If so, it will indicate to XCRB that the
       connecting CMAS has valid maps.
    
    -  In addition to the fix noted above, XCRB has been updated in
       the joining CMAS to request that the local maps be deleted if
       TSSJ indicates that the connecting CMAS has valid maps and
       XCRB determines that the local maps may be invalid.
    
       The parameter list for XCRB, EYUZXCRB, has been updated so
       that TSSJ can indicate that the connecting CMAS has valid
       MAPs.
    
    -  Method EYU0TSMH (TSMH), which requests that maps be hardened
       to the EYUDREP, has been updated to indicate that the maps
       are valid.  TSMH will indicate this if called in the
       connecting CMAS, or if called in the joining CMAS if the
       connecting CMAS also has the PTF on that resolves this APAR.
    
    -  Method EYU0XCRS (XCRS), which hardens the maps to the
       EYUDREP, has been updated to indicate that the maps are valid
       if TSMH indicates this.
    
       The parameter list for XCRS, EYUZXCRS, has been updated so
       that TSMH can indicate that the maps are valid.
    

Temporary fix

  •             *********
                * HIPER *
                *********
    FIX AVAILABLE BY PTF ONLY
    

Comments

  • Operational resources may be missing
    from WUI displays or from API result
    sets, and RTA events may not trigger
    correctly, after applying PTF UK28633
    for APAR PK49141.
    
    
    CPSM builds Topology resource maps to indicate what resources
    are installed in a MAS.  When an API/WUI/RTA request is made for
    a specific resource type , the resource maps are queried to
    determine where to send the request to retrieve the information.
    
    The maps are created for each resource type by the connecting
    CMAS, and sent to joining CMASes, so that all CMASes that help
    to manage a MAS can determine where to send API/WUI/RTA
    requests.  To cut down on the amount of traffic that is shipped
    between the connecting and joining CMASes, the maps are written
    (hardened) to the local data repository (EYUDREP).  To ensure
    that the maps are correct between the connecting and joining
    CMASes, each resource map has a signature, which indicates the
    SYSID of the CMAS that created the maps, along with the
    timestamp of when the maps were created.  When a CMAS joins a
    MAS, it compares the signatures of its hardened maps with the
    signatures of the connecting CMAS.  If the signatures match, the
    joining CMAS uses its hardened maps.  If they do not match, the
    joining CMAS requests the connecting CMAS's maps be sent during
    the join process.
    
    With UK28633, a connecting CMAS may create a null signature for
    a specific resource map for a MAS.  If this occurs, then the
    joining CMAS will not create maps for that resource type for
    that MAS.  If an API/WUI/RTA request is made for that resource
    type for that MAS through the joining CMAS, then no data will be
    returned for that resource class.  If subsequent resources are
    installed in the MAS for that resource type, the joining CMAS
    will build and harden an incomplete map for that resource type.
    This can result in some but not all resources being displayed
    for the MAS for that resource type.
    
    
    Method EYU0XCRB (XCRB), which retrieves the hardened maps from
    the EYUDREP, has been updated to correct the logic flaw in
    UK28633 that can result in a null signature being built in the
    connecting CMAS.
    
    To ensure that any incorrect maps created by the application of
    UK28633 are fixed, the following changes have been made:
    
    -  Method EYU0TSSC (TSSC), which is called in the connecting
       CMAS, will verify that any existing signatures are non-null.
       If a signature is null, TSSC will update the signature to a
       valid value.
    
    -  Method EYU0TSRA (TSRA), which builds the list of map
       signatures that is passed from the connecting CMAS to the
       joining CMASes, has been updated to turn on an indicator to
       inform the joining CMASes that the maps on the connecting
       CMAS are valid.
    
    -  Method EYU0TSSJ (TSSJ), which is called in the joining CMAS,
       has been updated to determine if the connecting CMAS has
       valid maps.  If so, it will indicate to XCRB that the
       connecting CMAS has valid maps.
    
    -  In addition to the fix noted above, XCRB has been updated in
       the joining CMAS to request that the local maps be deleted if
       TSSJ indicates that the connecting CMAS has valid maps and
       XCRB determines that the local maps may be invalid.
    
       The parameter list for XCRB, EYUZXCRB, has been updated so
       that TSSJ can indicate that the connecting CMAS has valid
       MAPs.
    
    -  Method EYU0TSMH (TSMH), which requests that maps be hardened
       to the EYUDREP, has been updated to indicate that the maps
       are valid.  TSMH will indicate this if called in the
       connecting CMAS, or if called in the joining CMAS if the
       connecting CMAS also has the PTF on that resolves this APAR.
    
    -  Method EYU0XCRS (XCRS), which hardens the maps to the
       EYUDREP, has been updated to indicate that the maps are valid
       if TSMH indicates this.
    
       The parameter list for XCRS, EYUZXCRS, has been updated so
       that TSMH can indicate that the maps are valid.
    

APAR Information

  • APAR number

    PK56207

  • Reported component name

    CICSTS V3 Z/OS

  • Reported component ID

    5655M1500

  • Reported release

    50M

  • Status

    CLOSED PER

  • PE

    YesPE

  • HIPER

    YesHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2007-11-08

  • Closed date

    2008-01-14

  • Last modified date

    2008-02-02

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

    PK56147

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

    UK32867

Modules/Macros

  •    EYUQXCRB EYUQXCRS EYURTISD EYURTRTD EYURXCRB
    EYURXCRL EYURXCRS EYUTRCHE EYUYXCRB EYUYXCRS EYUZXCRB EYUZXCRS
    EYU0TSMD EYU0TSMH EYU0TSRA EYU0TSRC EYU0TSSC EYU0TSSJ EYU0XCRB
    EYU0XCRS EYU9XCPU EYU9XCP3 EYU9XCP4
    

Fix information

  • Fixed component name

    CICSTS V3 Z/OS

  • Fixed component ID

    5655M1500

Applicable component levels

  • R50M PSY UK32867

       UP08/01/16 P F801 ®

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":"3.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":"3.2","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
02 February 2008