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
Hello Gaston, Our Db2 for z/OS SME has indicated this idea has progressed and is now in plan.
Sincerely,
The Db2 for z/OS team
Hello Gaston, Thank you for contacting us. I am checking with the SME and will let you know as soon as they have provided an update.
Sincerely,
The Db2 for z/OS team
Is there any update about this?