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

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

• The solution for this APAR is included in CS for zOS Version 2
  Release 2.
  

APAR Information

• 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