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

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.

Sincerely,

The Db2 for z/OS team

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

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

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

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.

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.

Hi
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

Von: cae4c35ac7ce10f1f7c9625e-bigblue@iad-prod1.mailer.aha.io
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

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.

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

This implementation is very important for problem determination and correction.