This portal is to open public enhancement requests against products and services offered by the IBM Data & AI organization. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Search existing ideas
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updateson them if they matter to you. If you can't find what you are looking for,
Post your ideas
Post ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,
Post an idea
Upvote ideas that matter most to you
Get feedback from the IBM team to refine your idea
Specific links you will want to bookmark for future use
Distributed Thread cancelled due to Idle Thread Timeout or MONITOR IDLE THREADS not writing record to SYS1.LOGREC
We noticed that every DB2 distributed thread that is cancelled because:
1) Idle thread timeout value that is specified by Db2 subsystem parameter IDTHTOIN in macro DSN6FAC is exceeded;
2) ATTRIBUTE2 value in a row with KEYWORD value MONITOR IDLE THREADS in the SYSIBM.DSN_PROFILE_ATTRIBUTES table, for a profile that monitors the thread is exceeded;
writes a record in LOGREC with ABEND S04E and Reason Code 00E50013.
In certain operational environments, sometimes we have lots of distributed threads falling into IDLE "state" and being cancelled when one of the limits above is exceeded. This causes a lot of records being written to LOGREC.
For certain DB2 environments, we would like to limit the amount of records like these (Abend S04E and RC 00E50013 for distributed threads) being written to
LOGREC or even suppress them. I understand that the writing of these records is not controlled by subsystem parameter SUPERRS today.
We would like that SUPERRS subsystem parameter could be enhanced (or a new zPARM parameter) to manage the writing of SYS1.LOGREC records mentioned
above (produced by distributed threads falling into IDLE "state" and being
cancelled), allowing to limit and/or suppress them.
The advantage is not having a flood of these records being written and offending SYS1.LOGREC file. These several records in general only means that a distributed thread was cancelled. Just a few of them could be relevant to the analysis, but they are repetitive in many cases.
Do not place IBM confidential, company confidential, or personal information into any field.