IBM Support

PM22871: CPSM API TASKS HANG IN CMAS, WAITING TO BE POSTED COMPLETE. MALALREADY COMPLETED BUT IN ERROR

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • If a CMAS ships a MAL to a lower-level (either lower CICS
    release or lower maintenance level of same release) and that MAL
    must be converted, CPSM creates a new copy of the MAL.
    .
    Since the MAL requires conversion, we build a copy of the MAL to
    ship to the other CMAS.  If the transmission eventually fails
    due to the link terminating, we correctly mark the copied MAL
    that it failed transmission (in CLFX), but we don't update the
    original MAL.  When we do cleanup for the copied and original
    MAL, we base whether we need to notify a waiting task on the
    status of the original MAL, not the copied MAL, and since the
    original MAL was not updated with transmission failure (or any
    other Kernel type error) we don't think we need to inform a
    waiting task.  This may leave an API task waiting for a POST
    that will never occur.
    .
    In the case that raised this APAR, the API task was doing a GET
    for WLMAWORK objects with a filter of STATUS=ACTIVE.
    .
    Additional Symptoms / Keywords:
    KIXREVSVR
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All CICSPlex SM V4R1M0 Users                 *
    ****************************************************************
    * PROBLEM DESCRIPTION: API, WUI and CICS Explorer requests may *
    *                      hang if a CMAS connection terminates    *
    *                      while the request is active.            *
    ****************************************************************
    * 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.                               *
    ****************************************************************
    When a CMAS connection is terminated, method EYU0CLFX (CLFX) is
    called to process all requests that are queued to be sent over
    the connection.  CLFX marks the parameter list (message argument
    list - MAL) for each request with an indication that
    transmission failed for the request, and then calls method
    EYU0CTRC (CTRC) to perform cleanup for the control blocks
    associated with the request.  As part of its cleanup processing,
    CTRC calls method EYU0CTAM (CTAM).  CTAM checks the MAL for the
    request, and if it indicates that an error has occurred, it will
    post the requestor with the error information.
    
    If the connection that has terminated is from a CMAS that is
    running at a higher CPSM release or maintenance level than its
    partner CMAS, then a copy of the original MAL is made.  This
    copied MAL is the one marked in error by CLFX.  However, CTAM is
    passed the original MAL.  Since CLFX only marks the copied MAL
    as in error, the original MAL does not indicate an error has
    occurred, and CTAM does not post the requestor.  This results in
    the requestor hanging.
    

Problem conclusion

  • CLFX has been updated to determine if the MAL it is processing
    is a copied MAL.  If so, CLFX will make the same updates to the
    original MAL as it made to the copied MAL.
    
    A similar change has been made to method EYU0CTDM (CTDM), which
    processes requests that have already been sent to a partner CMAS
    but have not completed before the connection has terminated.  In
    this case CTAM would correctly notify the requestor, but the
    requestor would not know why the request failed.  This would
    return an exception to the caller, instead of an indication that
    a request could not be transmitted.
    
    CTAM has been updated to include some additional tracing.
    

Temporary fix

  • FIX AVAILABLE BY PTF ONLY
    

Comments

APAR Information

  • APAR number

    PM22871

  • Reported component name

    CICS TS Z/OS V4

  • Reported component ID

    5655S9700

  • Reported release

    60M

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2010-09-20

  • Closed date

    2010-10-26

  • Last modified date

    2010-11-02

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

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

    UK61660

Modules/Macros

  •    EYU0CLFX EYU0CTAM EYU0CTDM
    

Fix information

  • Fixed component name

    CICS TS Z/OS V4

  • Fixed component ID

    5655S9700

Applicable component levels

  • R60M PSY UK61660

       UP10/10/30 P F010

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

Document Information

Modified date:
02 November 2010