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,
Post an idea
Upvote ideas that matter most to you
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.
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 ---
Do not place IBM confidential, company confidential, or personal information into any field.