Configure a user-defined value for disabling all IFI request and MONITOR trace processing after a number of abends

Hi Paulo, Thank you for the quick reply! I will share your feedback with Frank.

Hi Janet,

Thanks for the answer.

Actually we set an automation upon CDC message CHC9210E when reason code is 00E60831. If this happens,we issue a -DIS TRACE command to reenable monitor traces and IFI requests. But we depend on CDC to be active, which, OK, happens most of the time. But sometimes effect of monitor traces and IFI being stopped is commands failing in tools like DB2 Admin Tool, which is not so easy to capture and automate.

Then we tought an automation based on a DB2 message would be more effective.

Regards,

Paulo R Petrachini

Hi Paulo,

Thanks for the question.

Frank from our Db2 for z/OS develoment team looked through our history on sending a message out when the monitor traces stopped and it looks like we purposefully don't write a message because we rely on the subsequent incoming IFI request to be the notification as the facility will set IFCARC1 = IFCC0008 and IFCARC2 = IFCC0831.

This is the current direction. Is there a reason not to check and automate upon this action?

Thanks!

Frank from Db2 for z/OS development

Hi, Janet.

Thanks for the last update.

Is it possible to issue a DB2 message when IFI requests and MONITOR trace are disabled so that we can monitor it and create a homemade automation to issue a -DISPLAY TRACE and resume IFI processing ?

Thanks,

Paulo R Petrachini

Hello Paulo, Our Db2 for z/OS development team reviewed your update and provided the following feedback:

The difference between the AEXITLIM zparm and adding one for IFI requests is that the auth exit abends would be preventing a system issue outside of Db2 and thus changing the threshold would be up to the system operators discretion and would require a db2 restart after the fix to the exit is corrected.

Disabling IFI processing is a safety measure for abend occurring inside Db2 of incoming applications. Therefore, Db2 is trying to protect itself until the application has been corrected.

Sincerely,

The Db2 for z/OS Team

Thank you for your update, Paulo. I have shared it with our Db2 development team and asked that they take your additional feedback in to consideration when re-reviewing this idea as a potential candidate for delivery at a later date.

Sincerely,

The Db2 for z/OS Team

Dear Janet, thank you for answering to my enhancement request. I asked this enhancement because I thought it would be something similar to zPARM AEXITLIM, which controls how many abends can occur in DSNX@XAC befor it stops running. I thought implementation for MONITOR trace processing would be similar. But Ok for me if development team see risks in implementing this customer override.

A DISPLAY command seems to me a good idea, especially if in this DISPLAY I could see hard-coded threshold value and number of abends at the moment of DISPLAY, to know how far we are from stopping MONITOR trace processing.

Regards,

Paulo R Petrachini

Dear Paulo, Thank you for submitting this enhancement request. Our Db2 for z/OS development team reviewed it and provided the following feedback:

Allowing a customer override of the default/hard-coded abend count is a safety measure as almost all abends through MONITOR trace processing occurs on the customer/vendor applications. This is a fail-safe for Db2 trace facility.

As a stop gap, would it be ameanable if Db2 provides the current value through either a DISPLAY command or passed back in the IFCA? This would be less disruptive to customer systems.

We would like to hear your feedback. Also, please note that, due to other items already scheduled for our next 12 month delivery, we cannot address this item in the near future. We are placing it in Not under consideration but will review your response, and will re-review this request again when the next roadmap discussions begin.

Sincerely,

The Db2 for z/OS Team