IBM Support

PM10667: TRANSACTIONS ARE GETTING STUCK IN FCDWSUSP WAITS DURING INSERT ACTIVITY ON THE BASE CLUSTER AND READ ACTI 10/06/24 PTF PECHANGE

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • Transactions may enter FCDWSUSP waits and never exit.  This
    can occur when heavy insert activity takes place on the KSDS
    Base Cluster while heavy read activity take place on the Paths.
    The AIX and the Base records may temporarily get out of sync and
    the FCDWSUSP wait is used to temporarily delay requests until
    the Base and Paths can be brought into sync.  The FCDWSUSPs
    sould only last for a very short time.
      There are times when the sync process can be interrupted and
    the fctbc_0890_count along with the vswa_0890_post can become
    out of sync.  The end result will show up as transactions stuck
    in FCDWSUSP waits.  These waits should be very temporary.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All                                          *
    ****************************************************************
    * PROBLEM DESCRIPTION: Transactions stuck in FCDWSUSP          *
    *                      waits indefinitely.                     *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    Transactions may enter FCDWSUSP waits and never exit them. This
    can occur when heavy insert activity takes place on the KSDS
    base cluster while heavy read activity take place on its paths.
    The AIX (alternative index) and the base records may temporarily
    get out of step with respect to each other within VSAM, and
    the FCDWSUSP suspend is used to temporarily delay requests until
    the base and paths are synchronized again. These suspends are
    driven when VSAM returns an 0890 error, to indicate that the
    record being read is not present in the path. FCDWSUSP suspends
    should only last a short time, as when the update set work to
    complete the record insertion has completed, the record being
    read via the path should then be available.
      If a VSAM request experiences an exclusive control conflict,
    CICS calls routine ADDVSWA to process the VSWA for the request.
    Part of this involves freeing any VSAM resources before
    suspending the task. DFHFCVS preserves the content of
    vswa_0890_post around this call. This flag (if set on) means
    that the VSWA represents a request that may have led to an
    0890 being returned to a reader of the file. There is a
    corresponding count of such requestors maintained in the FCT
    (fctbc_0890_count). The intention is that when requests
    complete, and this count has reduced to 0, the tasks waiting
    on FCDWSUSP suspends are resumed, and can retry their requests.
      If FREE_VSAM_RESOURCES causes the value of vswa_0890_post
    to be changed (either to be set on if another task experiences
    an 0890, or set off, and the count decrement, if it had been on)
    then the restoration of the flag to its previous value when
    control returns to ADDVSWA will leave the flag and count in
    an inconsistent state. The count may now be 0 yet the bit
    still on, or the count now be 1 yet the bit off. Either way,
    the logic will not resume the tasks suspended on FCDWSUSP,
    and they will remain in the system indefinitely.
    

Problem conclusion

  • UK37688 UK47823
    DFHFCVS has been changed to no longer save and restore the value
    of vswa_0890_post around the call to FREE_VSAM_RESOURCES.
    

Temporary fix

  • FIX AVAILABLE BY PTF ONLY
    

Comments

APAR Information

  • APAR number

    PM10667

  • Reported component name

    CICSTS V3 Z/OS

  • Reported component ID

    5655M1500

  • Reported release

    500

  • Status

    CLOSED PER

  • PE

    YesPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2010-03-23

  • Closed date

    2010-06-29

  • Last modified date

    2010-08-02

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

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

    PM10588 UK58522

Modules/Macros

  •    DFHFCVS  DFHFCVS1
    

Fix information

  • Fixed component name

    CICSTS V3 Z/OS

  • Fixed component ID

    5655M1500

Applicable component levels

  • R500 PSY UK58522

       UP10/07/09 P F007

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 August 2010