Skip to Main Content
IBM Data and AI Ideas Portal for Customers

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:

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,

  1. Post an idea

  2. Upvote ideas that matter most to you

  3. 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.

Additional Information

To view our roadmaps:

Reminder: This is not the place to submit defects or support needs, please use normal support channel for these cases

IBM Employees:

The correct URL for entering your ideas is:

Status Delivered
Workspace Db2 for z/OS
Created by Guest
Created on Mar 14, 2019

DSNT376I message don't supply total information to solve the problem analisys

I found that as soon as the DB2 Lock Escalation message occurred (DSNI031I), DB2 seems to begin rejecting the ESS SQL calls against this tablespace, *immediately* without waiting the DB2 lock timeout interval.            
This probably explains why there is no DSNT376I message.                
The queuing is caused by IMS abending the transaction U0777 and then putting it back on queue to be reprocessed, where the same sequence will certainly happen again.
Actually, immediate rejection is better than waiting the timeout interval, but the lack of any DB2 message to indicate what's going on makes it hard operationally, to determine corrective action.  


This action will get benefits on problem detection, MIPS reduction and business disponibility.


Itau Unibanco S/A 

  • Admin
    Janet Figone
    May 31, 2022

    Hello, We are pleased to inform you this enhancement request is delivered in Db2 13 for z/OS which is generally available as of today.


    The Db2 for z/OS team

  • Admin
    Janet Figone
    Jul 19, 2021

    Thank you, Paulo. I have notified the Db2 engineer currently assigned to this idea of your above additional information.

  • Guest
    Jul 19, 2021

    Hi, Janet.

    After discussion with our Db2 advocate, Maria Sueli Almeida, we are providing a detailed background information on the reason for this requirement:

    The issue that lead to opening this Idea (RFE) was:
    1. An EXCLUSIVE LOCK ESCALATION occurred for tablespace DB2OI000.TSOI00G;

    2. IMS transactions started to be immediately rejected, receiving SQLCODE -911 and abend U0777, without waiting for IRLM resource timeout;
    3. In pmr 29472,228,631, it is informed that this situation may occurs in the following scenario:

    1. The object involved is PBG object and have more than one part.
      2. The SQL calls are insert statements.
      In this case, INSERT will do conditional lock request on all parts. If
      inserts can't get conditional lock on all parts, the SQL call would
      fail immediately and DB2 will return to the user with timeout SQLCODE
      -911 or -913.
      For IMS, it seems that IMS handles timeout as deadlock and will do
      reschedule. So lock escalation should be the cause of the IMS queuing.
      Customer should fix the program and avoid lock esclation which blocks all the other transactions.

    In our issue, the object that is target of an EXCLUSIVE LOCK ESCALATION (DB2OI000.TSOI00G) is a PBG defined with MAXPARTITIONS 3 and today using 2 partitions.
    I understand that there were IMS transactions trying to INSERT INTO this table and having this INSERTs failing due to this TS to be EXCLUSIVED LOCKED as a result of a ESCALATION. As mentioned above ,this transactions were immediately rejected without waiting for IRLM resource timeout and TIMEOUTs (and messages DSNT376I) didn’t occur.
    In pmr 29472,228,631 is also informed that:

    “In this case, INSERT will do conditional lock request on all parts. If
    inserts can't get conditional lock on all parts, the SQL call would
    fail immediately…”

    If this scenario of immediate rejection is valid today in DB2 12 when a conditional lock on all parts fails, our request in DB24ZOS-I-919 is

    When INSERTs are unsucessful in a scenario like described above (failing after trying conditional lock on all parts), and SQL calls are immediately rejected (without TIMEOUT), is it feasible to issue a message (in ssnmMSTR/SYSLOG) indicating that “conditional lock” was not possible, so that, looking at messages in ssnmMSTR/SYSLOG, we could have a hint of what is causing IMS transactions failing with abend U0777 ?

    Regards, Paulo R. Petrachini

  • Admin
    Janet Figone
    Aug 14, 2020

    Hi Paulo, Thank you. I have asked the Db2 developer assessing this Idea if there is any further clarification needed.

  • Guest
    Aug 14, 2020

    Hi, Janet.

    Did you see and analyze/understand our last comment (posted in 20 Feb) ?

    Our focus is on the lack of messages that could link the timeouts occurring on IMS and abnormal EOTs (DSN3201I) occuring on DB2 to the lock escalation. We would appreciate if we had messages that could link these events.

    What is the further information you need once this IDEA is NEED MORE INFORMATION status.

  • Guest
    Feb 20, 2020

    Janet, the message DSNT376I doesn't come up at all. The issue is that we don't have a DSNT376I or DSNT501I message so we don't see any timeouts on our side even though IMS gets a timeout (SQLCODE -911). The only message we get is DSN3201I (abnormal EOT) wich makes it difficult to link the lock escalation with a timeout on IMS.

    This RFE was opened because of the PMR 29472,228,631.

  • Guest
    Jul 10, 2019

    I thought that this is fixed or I confuse something

    PMR 89589

    Messages DSNT408I with SQLCODE -911, Reason 00C9008E and resource type 00000210 but no timeout message in MSTR Joblog
    Hi Mr Hagmann,
    The PTF (v12) UI63124 is now available.
    I think the actions on this pmr are now completed, but please let me know if I miss something?
    Thanks very much.
    Best regards, Karen

    Gesendet: Mittwoch, 10. Juli 2019 01:01
    An: HAGMANN Manfred
    Betreff: Janet Figone responded to idea DB24ZOS-I-919 DSNT376I message don't supply total information to solve the problem analisys

  • Admin
    Janet Figone
    Jul 9, 2019

    Db2 for z/OS development has begun reviewing this Idea, and would like to request some additional information.

    1. Is the problem that the T376I message does not provide enough information for problem determination?

    2. Or is that it does not come up fast enough?

    It seems the customer systems see the DSNI031I message and wait for the T376I message to come up. Some clarification on the scenario and what would help with the problem determination would be helpful.

  • Guest
    Mar 30, 2019

    I agree with Nelson Duval comment, this implementation will help us.

  • Guest
    Mar 18, 2019

    This implementation is very important for problem determination and correction.