OA42103: VXPAB QUEUES GETS CORRUPTED AND IS NOT CLEANED LEAVING WORK UNDISPATCHABLE.

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as fixed if next.

Error description

  • Recovery of a corrupted VXPAB work queue can be improved to
    allow further work elements to be processed correctly.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All                                          *
    ****************************************************************
    * PROBLEM DESCRIPTION: When VXPAB queue gets corrupted, PSS    *
    *                      does not dispatch any work on that      *
    *                      queue.                                  *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    This problem may be described as follows:
    Note: This is a follow-up APAR to address VTAM's ability to
          recover from a queue corruption which occurs on a
          very extended (VX) PAB.  See APAR OA41951 for details
          related to the events which led to the queue corruption.
      1. Very extended PAB queue has the pointer to the first
         work element and pointer to last work element.
         One of the work elements on the PAB, a RUPE in the
         original problem, becomes mismanaged which resulted in an
         ABEND0A9 RC 7075.
      2. This mismanaged work element, caused VTAM to
         unintentionally clear the pointer to the first work
         element on very extended PAB in error. But the pointer
         to the last work element was valid.
      3. Another VTAM process issued TPQUE macro to queue the work
         element to the Very extended PAB. It queued the work
         element to the non-pss queue.
      4. ISTAPCVX received control to move the work elements from
         the non-pss queue to the very extended PAB queues. It
         found the last work element on very extended PAB queue
         and it added the new work element to the last work element
         of the queue.
      5. ISTAPCPD received control to dispatch the work from the
         very extended PAB. Since the first work element on the VX
         PAB queue was zero, ISTAPCPD interpreted this as no work
         queued to this specific PAB level. As a result, no work
         queued to this PAB level ever got dispatched.
      6. The step 3 through 5 repeated many times. This caused waits
         in many VTAM processes.
    

Problem conclusion

Temporary fix

Comments

  • This APAR is being closed FIN (Fixed If Next) with concurrence
    from the submitting customer. This means that a fix to this
    APAR is expected be delivered from IBM in a release (if any)
    to be available within the next 36 months.
    

APAR Information

  • APAR number

    OA42103

  • Reported component name

    VTAM V4 MVS/ESA

  • Reported component ID

    569511701

  • Reported release

    1D0

  • Status

    CLOSED FIN

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2013-04-30

  • Closed date

    2013-05-21

  • Last modified date

    2013-05-21

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

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

Modules/Macros

  • ISTAPCVX ISTDIE
    

Fix information

Applicable component levels

  • R1D0 PSY

       UP



Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

z/OS family

Software version:

1D0

Operating system(s):

z/OS

Reference #:

OA42103

Modified date:

2013-05-21

Translate my page

Machine Translation

Content navigation