DB2 Regions creating a lot of messages for AB/S004E SYSTEM ABEND CODE: 004E in LOGREC

It was reported thru GTIECSMFDB-10132  on both the SDPLEX and SBPLEX that the DB2 regions are producing thousands of error messages in the System Logrec  for   AB/S004E     SYSTEM ABEND CODE: 004E   each day. 

The following error messages are filling up the LOGREC message queue

ERROR DATE: 365.23
40246 CHARS 'AB/S004E'

ERROR DATE: 001.24
55976 CHARS 'AB/S004E'

ERROR DATE: 002.24
71961 CHARS 'AB/S004E'

Here is an example of the detailed LOGREC data:

DATE  002 24
15 51 32 54 D2D6DIST SFTABN 00 PIDS/5740XYR00 RIDS/DSNLILLM#L RIDS/DSNL
15 51 44 20 D2DBDIST SFTABN 05 PIDS/5740XYR00 RIDS/DSNLILLM#L RIDS/DSNL
15 51 58 85 D2DDDIST SFTABN 02 PIDS/5740XYR00 RIDS/DSNLILLM#L RIDS/DSNL
15 51 58 85 D2DDDIST SFTABN 02 PIDS/5740XYR00 RIDS/DSNLILLM#L RIDS/DSNL
15 52 12 79 D2D1DIST SFTABN 05 PIDS/5740XYR00 RIDS/DSNLILLM#L RIDS/DSNL
15 52 14 13 D2D6DIST SFTABN 00 PIDS/5740XYR00 RIDS/DSNLILLM#L RIDS/DSNL

Below is the research of this process

SEARCH ARGUMENT ABSTRACT

  PIDS/5740XYR00 RIDS/DSNLILLM#L RIDS/DSNLQCTL AB/S004E PRCS/00D3003E R

  RIDS/DSNLFRCV#R

  SYMPTOM             DESCRIPTION

  -------             -----------

  PIDS/5740XYR00      PROGRAM ID: 5740XYR00

  RIDS/DSNLILLM#L     LOAD MODULE NAME: DSNLILLM

  RIDS/DSNLQCTL       CSECT NAME: DSNLQCTL

  AB/S004E            SYSTEM ABEND CODE: 004E

  PRCS/00D3003E       ABEND REASON CODE: 00D3003E

   REGS/0C628          REGISTER/PSW DIFFERENCE FOR R0C: 628

   RIDS/DSNLFRCV#R     RECOVERY ROUTINE CSECT NAME: DSNLFRCV

Case TS015115488  was created about this topic and IBM explained that this is regular way of work of DB2 as follows

DB2 for z/OS supports a "KeepDynamic Refresh" concept. When packages are bound with KEEPDYNAMIC(YES), the DBAT/connection association must be maintained and hence there are fewer DBATs available to service other work. A refresh capability exists that causes the DBAT/connection combination to be terminated after one hour of use or 20 minutes of being idle, hence allowing a replacement DBAT to be created to service other work. To prevent this condition from impacting the remote application, this termination of the DBAT/connection only occurs if the client identifies itself with the ability to seamlessly move the client connection over to a new connection at the same member or a different member of a data sharing group. In supporting this KeepDynamic Refresh capability, a serviceability condition exists because no message is issued at the DB2 member indicating that this DBAT/connection termination event has occurred.

This resulted in sending messages DSNL027I/DSNL028I with reason codes 00D3003E and 00D3003F to the Db2 mstr-log. PM94885 changed this, to avoid these messages and record the events in logrec instead.

00D3003E records an event, when a KeepDynamicRefresh DBAT was used for more than one hour and therefore was refreshed

00D3003F records an event, when a KeepDynamicRefresh DBAT was idle for more than 20 minutes and

therefore was refreshed.

PH25529 applied prevents this messages to go to Master Region , and as this PTF was applied this is not happening.

 The Idea is to review is there is any way to prevent this messages of being send to LOGREC , or in case it is not , the interval of time in wich they are sent to LOGREC of this messages can be reviewed as we are getting 74K messages daily.

Please let me know in case of questions.

Best Regards

Gaston