What is the reason of PXM3200 message and how to avoid it in Detector 19.0?.

Document ID : KB000010144
Last Modified Date : 14/02/2018
Show Technical Document Details
Introduction:

After the upgrade to Detector 19.0 and working with USECOLLTASKS(Y) parameter in R190.CDBAPARM(PDT) member to work with zIIP processors suddenly the following message is displayed in Xmanager output.
 
PXM3200 DETECTOR COLLECTION TASKS LOST     nnn SQL CALLS (   .nnnnnn% OF DATA) DURING THE LAST 5 MINUTES.
         DB2=SSID
 
What is the reason of PXM3200 message and how to avoid it?. 

Instructions:

With Detector 19.0 there is a new SQL Collection Process, you can read in the following link a description about how this works.

- Redesigned SQL Collection Process

https://docops.ca.com/ca-detector-for-db2-for-z-os/19-0/en/product-information/enhancements

You have to work with USECOLLTASKS parameter in R190.CDBAPARM(PDT) member to enable or disable this new Collection Process. If you have zIIP processors in your site this parameter is recommended as you will offload some of the collection process to zIIP processors and SQL performance will be improved, some of the collection task will be performed in the zIIP processors instead of the CP processors.

A lot of times PXM3200 messages are caused by a wrong Dispatching Priority for Xmanager address space, Xmanager address space needs a higher dispatching priority over any DB2 address spaces (DBM1, DIST, MSTR and CICS/TSO/IMS/WebSphere allied address spaces). Please read in the following link an explanation about it.

- Assign Dispatching Priority or a WLM Service Class

https://docops.ca.com/ca-database-management-solutions-for-db2-for-z-os/19/en/installing/complete-product-configuration/executing-product-specific-tailoring/customize-xmanager/assign-dispatching-priority-or-a-wlm-service-class

As a first step check with the Systems Programmer that Xmanager has the higher priority over any other address space executing SQL statements, with the new Collection Process design only IRLM address space needs a higher priority than Xmanager address space.

For the values for USECOLLTASKS, USEZIIP and COLLTASKSCNT in R190.CDBAPARM(PDT) member with zIIP processors available you can start with the following values:
USECOLLTASKS (Y)
USEZIIP (Y)
COLLTASKSCNT (0)

The COLLTASKSCNT (0) default value will calculate the number of zIIP processors available, this should be fine if all other parameters are configured correctly.

You should review values for z/OS parameters IIPHONORPRIORITY, ZIIPAWMT, and HIPERDISPATCH in the SYS1.PARMLIB(IEAOPTxx) member as well. The default values are the right ones to start.

You can read about this in PXM3200 message documentation in the following link:

https://docops.ca.com/messages-ca-database-management-solutions-for-db2-for-z-os/en/common-functions-messages/pxm-messages/pxm3200

Based on 'z/OS MVS Initialization and Tuning Reference' manual default values are:
IIPHONORPRIORITY=YES
ZIIPAWMT=3200
HIPERDISPATCH=YES

The most important ones are IIPHONORPRIORITY=YES and ZIIPAWMT=3200. With IIPHONORPRIORITY=YES will tell the WLM to fall back to CP processor instead of zIIP processor after the wait time if the zIIP processor cannot process the request. If the request cannot work on a zIIP processor or on a CP processor then data will be lost and it will appear in the PXM3200 message.
 
To avoid PXM3200 messages normally problem does not depend on the number of tasks started, it depends on those tasks are dispatched with enough priority to not lose the data.