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
NOTICE TO EU RESIDENTS: per EU Data Protection Policy, if you wish to remove your personal information from the IBM ideas portal, please login to the ideas portal using your previously registered information then change your email to "firstname.lastname@example.org" and first name to "anonymous" and last name to "anonymous". This will ensure that IBM will not send any emails to you about all idea submissions