PI84838: WLM CLASSIFICATION OF IMS TRANSACTION BY IMS TRANSACTION CLASS NOT ALWAYS CONSIDERED 17/07/24 PTF PECHANGE

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Observing incorrect assignment of WLM Service and Report Classes
  based on IMS Transaction Classes.
  -
  Over 50% of all IMS Transactions covered by IMS Default Service
  and Report Class instead of the current configured
  Classification policy defined by WLM.
  

Local fix

• no
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * All users of IMS v14                                         *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * 1.  WLM service classes for IMS transactions may be assigned *
  * incorrectly.                                                 *
  * 2.  Incorrect data in 56FA log record due to overlay of      *
  * DFSTLS block.IN                                              *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * INSTALL CORRECTIVE SERVICE FOR APAR/PTF                      *
  ****************************************************************
  Two issues are addressed in this apar.
  1.   In DFSYTIB0, the service class may be reported incorrectly
  to WLM.  This occurs because the expansion of the DFSWLMY macro
  uses R13 as a base register for SMBCLASS_PTR, even though, at
  this point in the code, R13 is being used to point to a save
  area to be used by WLM.
  
  2.  An incorrect length is used for the DFSTLS block.  In some
  cases, a length of 218x is used instead of the correct length of
  260x.  APAR pi51948 increased the length of the block from 218x
  to 260x.  This results in an overlay of the section of DFSTLS
  beyond offset 218x.  Because this is the section added by
  pi51948, used to store processor usage data, this can cause
  incorrect processor usage data to be written to the 56FA log
  record and/or reported to WLM on the DFSWLMN service call.
  

Problem conclusion

• 1.  In APAR pi51948, we needed to change the handling of save
  areas in DFSYTIB0 to account for the fact that the 64 bit
  version of the WLM Classify service (IWM4CLSY) expects r13 to
  point to a 216-byte save area.  This was accomplished by
  temporarily copying the dynamic storage address in r13 to r9
  across the DFSWLMY call, and having r13 point to the 216 byte
  save area.  The problem this introduces is that the compiler
  used r13 as a base register for SMBCLASS_PTR in the DFSWLMY
  macro expansion, when r13 is no longer pointing to the dynamic
  storage area.
  
  This is fixed by adding a USING statement in gen code to tell
  the assembler that R9, not R13, contains the address of the
  dynamic storage area during the DFSWLMY call.
  
  2.  The DFSTLS length is incorrect because some modules that
  reference TLSLEN were not recompiled in pi51948.  Those modules
  are recompiled by this APAR.  They are:
  DFSCDMP0
  DFSDTTA0
  DFSSDA30
  DFSMINI0
  DFSPSTB0
  DFSTMAS0
  DFSSDA20
  DFSABND0
  DFSFDMP0
  

Temporary fix

Comments

APAR Information

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

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

  PI84889 UI49649

Modules/Macros

• DFSYTIB0 DFSABND0 DFSPSTB0 DFSSDA20 DFSSDA30 DFSCDMP0 DFSMINI0
  DFSTMAS0 DFSDTTA0 DFSFDMP0
  

Fix information

• Fixed component name

  IMS V14

• Fixed component ID

  5635A0500

Applicable component levels

• R400 PSY UI49649

     UP17/09/01 P F708 {

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.