PK70812: HIGH NUMBER OF L8 TCBS WHEN USING TRANSACTION ISOLATION FOR TASKS WHICH ISSUE DB2 CALLS INFREQUENTLY.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• There might be up to several hundred active L8 TCBs although the
  peak of active users tasks is far less. The problem is caused by
  the fact that the tasks running with TRANISO are associated with
  particular subspaces. A free L8 TCB is required if those tasks
  are going to issue a DB2 Call. If there is no free L8 TCB with
  with a matching subspace, then CICS is creating a new TCB rather
  than using an existing one.
  .
  CICS maintains TCB histories for every transaction which execu-
  tes. The problem is that the TCB history information gets
  'decayed' if a specific task did several runs without issuing
  a DB2 call.
  From this point on, the subspace allocated to new transactions
  will not be associated with an L8 TCB anymore and a new TCB has
  to be created on next DB2 call if there is no active L8 TCB with
  a matching subspace.
  

Local fix

• Decrease the MAXOPENTCBS value.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All.                                         *
  ****************************************************************
  * PROBLEM DESCRIPTION: CICS creating L8 TCB's unnecessarily.   *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  In the reported problem, a CICS system was running with
  transaction isolation active.  A transaction (TRA1) ran
  repeatedly.  Sometimes it would make DB2 calls (requiring
  an L8 TCB), sometimes it did not.
  
  CICS maintains TCB histories for every transaction which
  executes. When TRA1 ran and used an L8 TCB, the history was
  updated. For the next few runs of TRA1, the subspace allocated
  to TRA1 was one which had an association with an L8 TCB. So if
  TRA1 attempted to switch to an L8 it would have switched to an
  already attached L8 TCB which matched the subspace for the
  running TRA1.
  
  However, for runs made much much later, TRA1 did not make any
  DB2 calls and the TCB history information was 'decayed' every
  20 executions (open_history_decay_threshold) of the transaction.
  Eventually the TCB history indicated that TRA1 did not use an
  L8 TCB at all.
  
  As a consequence, the subspace allocated to a new TRA1 was not
  associated with an L8 TCB. This was acceptable until the next
  invocation of TRA1 which did require an L8 TCB. In this case,
  CICS searched the TCB history for an L8 TCB matching the
  subspace for the new TRA1, it failed to find one and this
  resulted in the attach of a new L8 TCB.  This process was
  repeated many times hence the leak of L8 TCBs into the system.
  
  Keywords: L9 OPENAPI
  

Problem conclusion

• The procedure that decays the TCB history in DFHXMTA
  (process_open_tcb_history) has been modified so that the
  frequency to decay (open_history_decay_threshold) the OPEN
  TCB has been altered to reflect the influence of the MAXOPENTCBS
  parameter.
  

Temporary fix

• FIX AVAILABLE BY PTF ONLY
  

Comments

APAR Information

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

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

  UK42430 UK42431

Modules/Macros

•    DESXMAT  DFHXMTA
  

Fix information

• Fixed component name

  CICSTS V3 Z/OS

• Fixed component ID

  5655M1500

Applicable component levels

• R400 PSY UK42430

     UP08/12/16 P F812

• R500 PSY UK42431

     UP08/12/16 P F812

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.