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 Under review
Workspace Db2 for z/OS
Created by Guest
Created on Feb 15, 2022

DB2 Return Code Differentiate for Deadlock and Timeout via Subsys Normal Call Exit

DB2 presents IMS ( via Subsystem Normal Call Exit ) with the same return code (4) for:

DB2 resource deadlocks

DB2 resource unavailable conditions

Example, lock timeouts on object locks, such as are taken by DB2 utilities and those caused by lock escalation

The IMS action for this return code is to handle it as a deadlock, abend the unit of work, and if message driven, requeue the input message to be retried.

This is appropriate for actual resource deadlocks, but in the case of many resource unavailable conditions, the condition is actually persistent and will occur

again when IMS reprocesses the message. This can cause reprocessing loops, which are very expensive and cause excessive and futile resource consumption in IMS.

In these cases, it would be better to abend the unit of work without requeuing the input message for reproccessing.

IMS is not passed any information about the cause of the return code (4) and so has no way to make a better determination.

We are requesting that DB2 use a different return code for deadock than other 'resource unavailable" situations. This would allow IMS to handle the

situation more efficiently

Needed By Yesterday (Let's go already!)
  • Admin
    Janet Figone
    Mar 25, 2022

    Hello Sercan, Just a friendly update - our Db2 for z/OS development team is still actively reviewing this idea.

  • Guest
    Feb 24, 2022


    Actually this is very old issue for us. We have two IMS members and four DB2 members on sysplex. Two of these DB2 members are connected to IMS DB/DC as a subsys.

    We face this problem(lack of communication between DB2-IMS) when persistent locks occur on DB2 objects such as a row of a table(locksize row). For example; We are a bank, our most common case occurs after salary payments. Our salary application pays salary, right after each payment, the other applications(money transfer, bill payment etc.) are triggered. We see high volume of DB2 timeouts on specific rows(accountid, branch no) of DB2 tables. Our last occasion was on 07.02.2022 during busy interval(10:30-11:30). The availability of bank decreased because of these high volume of timeouts.

    Because IMS TM does not know the db2 problem in detail(deadlock or timeout), which is the topic of this Idea, IMS re-schedules the transactions which are db2 timeout victims. Therefore, all of these timed out transactions are re-scheduled, and then most of them failed again. But IMS TM still does not know it is deadlock or timeout, IMS keeps trying to re-schedule timed out transactions. Each transaction can be requeued infinitely until they end successfully, this will cause boost of queueing on IMS and locks all IMS regions which are trying to get db2 lock.

    I'm uploading IMS queue trend graph, number of db2 timeouts&deadlocks and their lists. We believe if DB2 passes different return code to IMS, IMS TM can decide more accurately.


  • Admin
    Janet Figone
    Feb 24, 2022

    Can you please provide more information (e.g. Salesforce case# ) where this issue originated from? Which lock resource was involved to trigger this Aha! Idea?

    Thank you.