PH47735: CPU CONSUMPTION INCREASES AFTER ACTIVATING A MONITORING POLICY

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• After a client installed system and task monitoring policies
  they found that the CPU attributed to
  long running (in their case, MQ listener) tasks doubled.
  Analysis of SMF data confirmed this increase.
  
  
  A review of a CICS trace confirmed that the extra CPU was
  being spent maintaining policy counts in
  temporary storage error processing. Further analysis revealed
  the following repeating sequence of events :
  
  (1) The long running transactions issued a START tranid and also
  a WRITEQ TS to a temporary storage queue
  (2) The queue was full (32767 items on it) and these requests
  failed with an IMTEMERR
  
  As part of ITEMERR processing, CICS then sees that MP policies
  are active, and wants to update its MP counters.
  CICS needs to establish which type of TS queue (AUX or MAIN) is
  in use - so that it can update the correct counters.
  Because of the ITEMERR condition, CICS doesn't know the queue
  type - so needs to call DFHTSBR to establish it.
  That call to DFHTSBR adds the extra CPU, as reported.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICS users.                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: CPU usage increases when a CICS         *
  *                      Policy is active, and an application    *
  *                      issues many WRITEQ TS requests which    *
  *                      return ITEMERR.                         *
  ****************************************************************
  CICS is running with a Policy Bundle active.
  An application issues multiple WRITEQ TS requests to a
  temporary storage queue which is full,
  CICS needs to update its policy counts, and needs to
  determine whether the queue is MAIN or AUX, but that
  state is not available because the queue is full.
  CICS makes a DFHTSBR domain call to establish the queue type;
  this domain call uses a small amount of CPU time.
  CICS returns the ITEMERR condition to the application.
  This sequence is repeated many times - and the extra CPU
  usage is noticed by the user.
  

Problem conclusion

• This APAR changes CICS Temporary Storage Policy processing to
  find the queue type when ITEMERR is reported, without calling
  DFHTSBR to establish the type.
  

Temporary fix

Comments

APAR Information

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

  PH45544

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

  UI81656

Modules/Macros

• DFHEITS  DFHTSAM  DFHTSBR  DFHTSCL  DFHTSDM  DFHTSDUC DFHTSDUF
  DFHTSDUS DFHTSPT  DFHTSQR  DFHTSRM  DFHTSST
  

Fix information

• Fixed component name

  CICS TS Z/OS V6

• Fixed component ID

  5655YA100

Applicable component levels

• R400 PSY UI81656

     UP22/07/27 P F207

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.