PK20429: YTIB STORAGE CREEP IN SHARED QUEUES ENVIRONMENT WHEN EXPRESS PCB ISRT DONE ON BE IMS. (FE IMS STORAGE GROWTH)

APAR status

• Closed as program error.

Error description

• Customer application flow is :
  Tran A -> ISRT by Express PCB -> Tran B -> reply IOPCB.
  This flow, when run CM1, is an OTMA protocol violation.
  Since PQ39980 in IMS V6, the input YTIB would be deleted
  at syncpoint and Tran B scheduled asynchronously. This avoided
  YTIB storage creep if Tran B did a GU before Tran A terminated
  and unlocked the YTIB (and thus scheduled asynchronously).
  For MQ input this is not a problem as MQ doesn't care if it
  gets CM0 asychronous response to CM1 synchronous input.
  However, this flow has an issue if Tran A runs on a BE IMS
  in shared queue group. A YTIB is created on the FE IMS at
  input time and waits for a synchronous response messaage from
  the BE application processing. When Tran A ISRTs Tran B via
  EXPRESS PCB on the BE IMS, this will force Tran B to run
  CM0 asynchronously and send the response to the FE IMS
  asynchronously. This leaves the FE IMS YTIB stranded again.
  (The BE YTIB created at GU time on BE is freed).
  A process needs to be built to free the FE YTIB in this case
  when Tran A terminates on the BE IMS.
  

Local fix

• Run the entire flow CM0 instead of CM1.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All IMS R810 OTMA users in a Shared Queues   *
  *                 Enviromnent with Express PCB's.              *
  ****************************************************************
  * PROBLEM DESCRIPTION: IMS Front End YTIB storage is not       *
  *                      released when a transaction running on  *
  *                      the Back End does a program-to-program  *
  *                      switch using an express PCB.            *
  ****************************************************************
  * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF      *
  ****************************************************************
  In a shared queues environment, when a transaction running on a
  back end (BE) IMS system does a program-to-program (P2P) switch
  using an express, and does not do an insert (ISRT) back to the
  IOPCB, the BE YTIB is freed. However, the front end (FE) is left
  allocated. This results in a storage leak which could lead to an
  IMS storage abend such as ABEND878, or ABEND80D.
  

Problem conclusion

•  AIDS: RIDS/DCS RIDS/CNTRL DCS CNTRL
    DEP: NONE
    GEN:
  POSTREQ PK37310
  
  SYSPLEXSQ
  
  *** END IMS KEYWORDS ***
  DFSYLUS0 was modified to send a request to the FE to release the
  YTIB and cleanup.
  
  DFSYTIB0 was modified to process the request from the BE to
  release the YTIB and cleanup.
  

Temporary fix

• *********
  * HIPER *
  *********
  

Comments

• REPINNED RP07/01/11 (ATXT) TO ADD POSTREQ PK37310 INFO.
   **** PE07/01/11 PTF IN ERROR. SEE APAR PK37310 FOR DESCRIPTION
  
  ž**** PE07/01/11 FIX IN ERROR. SEE APAR PK37310  FOR DESCRIPTION
  

APAR Information

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

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

Modules/Macros

•    DFSYLUS0 DFSYTIB0
  

Fix information

• Fixed component name

  IMS V8

• Fixed component ID

  5655C5600

Applicable component levels

• R800 PSY UK15287

     UP06/06/16 P F606