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:
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
Help IBM prioritize your ideas and requests
The IBM team may need your help to refine the ideas so they may ask for more information or feedback. The product management team will then decide if they can begin working on your idea. If they can start during the next development cycle, they will put the idea on the priority list. Each team at IBM works on a different schedule, where some ideas can be implemented right away, others may be placed on a different schedule.
Receive notification on the decision
Some ideas can be implemented at IBM, while others may not fit within the development plans for the product. In either case, the team will let you know as soon as possible. In some cases, we may be able to find alternatives for ideas which cannot be implemented in a reasonable time.
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.