PM94000: FOR CICS RESOURCE CLASS MONITORING RECORDS WRITEQ TO MAIN STORAGE ARE COUNTED INCORRECTLY AS WRITEQ AUX STORAGE.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• The problem is in DFHTSQR. There is a local variable in that
  module called STYPE. STYPE says whether a PUTQ was to Main or
  to Aux. The problem is that it is typically initialized (to
  Main or Aux) in a routine (invoke_xtsqrin) which is only
  invoked if the XTSQRIN global user exit is active. Since XTSQRIN
  is not active, STYPE is typically not initialized to Main or
  Aux.
  
  Instead it is just initialized (on entry to DFHTSQR) as 0.
  (Main is 1 and Aux is 2.)
  .
  So then, typically, when we go to do the DFHMNFUI
  Accumulate_Resource_Clock in Monitor_Request_Completion, we ask
  if STYPE is set to Main (which is 1), and since it is not set
  to 1 we take the else clause and do the
  Accumulate_Resource_Clock against DFHTEMP which indicates it
  was a write to Aux.
  .
  The one exception to this is on the first write to a brand new
  queue. In that case control goes to tsqr_create_empty_queue
  which has some code to set STYPE correctly to Main or Aux.
  .
  So the result is that for Resource Class Monitoring purposes.
  The 1st WRITEQ to MAIN will get recorded properly as a Write to
  Main.  But then all subsequent Writes to Main get recorded as
  Writes to Aux.
  .
  Note that for Performance Class Monitoring purposes (which are
  done in a different part of DFHTSQR) everything is correct. In
  the customer doc, the Performance Class Reports correctly
  counted all the WRITEQs as going to Main.
  
  
  Additional Symptom(s) Search Keyword(s): KIXREVSVR
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICS users.                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: WRITEQ requests for MAIN temporary      *
  *                      storage queues are incorrectly          *
  *                      attributed to AUXiliary temporary       *
  *                      storage queues in CICS SMF monitoring   *
  *                      data.                                   *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  CICS is running with resource monitoring active. WRITEQ requests
  for MAIN temporary storage queues can be attributed to
  DFHTEMP 46 (representing AUXiliary temporary storage) instead of
  DFHTEMP 47 (MAIN temporary storage).
  This problem does not occur if the temporary storage user exit
  XTSQRIN is active, or on the first write to a new TS Queue.
  .
  Additional Keywords: DFHTEMP46 TSPUTACT
                       DFHTEMP47 TSPUTMCT
  

Problem conclusion

• DFHTSQR has been amended to initialise the storage type
  correctly, and thereby ensure that TS WRITE and REWRITE requests
  resulting from EXEC CICS WRITEQ TS requests will update the
  correct monitoring field.
  DFHEITS has also been updated to pass the storage type on the
  domain call to DFHTSQR for rewrite requests.
  

Temporary fix

• FIX AVAILABLE BY PTF ONLY
  

Comments

APAR Information

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

  PM93061

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

  UK97730

Modules/Macros

• DFHEITS  DFHTSPT  DFHTSQRT DFHTSQR
  

Fix information

• Fixed component name

  CICS TS Z/OS V5

• Fixed component ID

  5655Y0400

Applicable component levels

• R800 PSY UK97730

     UP13/09/28 P F309

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.