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 Not under consideration
Created by Guest
Created on Mar 2, 2018

needs a quick detection solution about a connection loss without depending on TCP/IP

Please refer to the PMR 11064,69G,760.
Customer would like to detect a connection loss when HEARTBEATTIMEOUT=3M (3 minutes) is expired without depending on TCP/IP when the target server running LPAR is down.
Because the detection of the connection failure is delay and the recovery operation time expands due to the replication state is remained as 'REPLICATE CONTINUOUS'.
In our test, the detection of the target LPAR down took 15 minutes until TCP/IP retransmission timeout.
In the current design, IIDR for IMS heartbeat processing does not detect the broken connection until the TCP/IP send fails.
The enhancement called 'heartbeat death' in the PMR 11064,69G,760 is as follows.
--- start of the PMR quotation ---
What I think you're asking for here is a further enhancement to declare
"heartbeat death" if the source sends some number of heartbeats to the
target without a response. Currently, heartbeats are sent on the data
channel only when there is a lull in data flow for the subscription.
The data channel can be high volume, in-band with the data. To add
heartbeats into this flow could be problematic if there is a backlog of
changes to be processed by the target and a heartbeat is on the end of
that flow of data. It would be possible for replication to declare a
heartbeat death because the target isn't responding to the source's
heartbeat. Adding in heartbeat death (responses not received) could
lead to heartbeat timeouts in more ordinary situations where the target
isn't keeping up.

We would need to add the concept of a control channel to separate the
high-importance, low-volume messages like heartbeats from the
lower-importance, high-volume messages like database change messages.
This would allow the source and target to send heartbeats independently
at the heartbeattimeout and for each side to declare the other lost
after some frequency of sending a heartbeat without detecting a
receipt. This is beyond the scope of what was intended for the
original HEARTBEATTIMEOUT and not a trivial change. If I've accurately
captured what you're requesting you should open an RFE for that change.
--- end of the PMR quotation ---

  • Guest
    May 21, 2021

    [IBM Update]


    Thank you for filing this requirement and for your interest in keeping our IMS/VSAM Data Replication technologies vital and successful. We depend on your continued interest and ideas to help ensure our products keep pace with market needs and industry standards.

    Although we do agree that your request is valid, after monitoring your request for more customer demand over the last few years and applying other relevant evaluation criteria, unfortunately we won't be able to accept your request at this time. However, if there is still an important business need, we encourage you to file a new idea accompanied with any additional information that could help us prioritize the requirement in the future.