|Communication Details||Problem Determination|
The table below describes some syncpoint terminology:
|Commit Coordinator||Controls syncpoint processing. Responsible for notifying application of syncpoint processing.|
|Recoverable Resource||A resource which can perform dynamic rollback and which may or may not implement forward recovery and/or syncpoint failure recovery. A database system is a common example of a recoverable resource.|
|Unit-of-work||Work which is performed against a Recoverable Resource between syncpoints. "Work" is anything which affects the status of the resource. For example, setting a lock by issuing a retrieval call to a database system.|
|In-flight and in-doubt||A unit-of-work is in-flight until syncpoint processing begins. Once syncpoint processing begins, the unit-of-work is in-doubt until syncpoint processing completes and results are returned to application program or user.|
IMS Option acts as the Commit Coordinator. It initiates syncpoint processing based on the rules for IMS applications. For example, GU to the IO PCB, a normal return to IMS and a Checkpoint call all initiate commit processing. It initiates backout processing if an application requests rollback with a ROLL or ROLB call or if the application program (or possibly IMS Option itself) terminates abnormally.
The IMS Option Commit Coordinator uses a "Two-Step" commit process. The Commit Coordinator issues a "prepare" to each resource registered as a Two-Step resource prior to sending the "commit". If all prepares succeed, commit processing begins, if any prepare fails, backout starts.
The Remote IMS Requester registers as a Two-Step resource with the Commit Coordinator. The IMS Option Fileshare databases and SQL systems are also registered to the Commit Coordinator. See the chapter IMS Syncpoint Coordination for a complete description of the Commit Coordinator and syncpointing.
It is called Two-Step to distinguish it from the Two-Phase commit protocol used by IMS/ESA for its resources. Two-Step shares some of the same benefits as Two-Phase but does not provide recovery from failures which may occur during backout processing, during the second phase of commit processing or failures to the Commit Coordinator itself. See the chapter IMS Syncpoint Coordination for details.
The main benefit of Two-Step over a single-phase commit protocol is that it can recover from failures to a resource which occured between the last time an application used a resource and the time that commit processing begins. The "prepare" step catches any failures which occur during this interval and cause backout processing to other resources.
A failure to the communications link causes immediate backout in the Remote Server and initiates backout processing in Commit Coordinator. The Requester completes its backout heuristically since it cannot send an explicit rollback request to the Server.
A failure to the Remote Server initiates backout processing in the Commit Coordinator. IMS/ESA will backout in-flight work during its recovery if the Remote Server failed due to IMS failing. IMS/ESA will backout immediately if the Remote Server abends. The Requester completes its backout heuristically since it cannot send an explicit rollback request to the Server.
Most errors in IMS Option or the application can be trapped and initiate backout processing. For example, memory access violations (traps), pseudo-abends and the process being closed or killed. If the rollback sent to the Server should also fail, a heuristic completion occurs. This could occur, for example, if the communications link failed.
However, there are some cases where IMS Option cannot control the backout process. For example, the PC becomes hung or is powered off. In these cases the Remote Server will backout because it is notified by VTAM of the failed partner program. Note that any other recoverable resources being managed by the Commit Coordinator may or may not complete backout successfully - it depends on the resource and what other failures may occur. Since the Commit Coordinator could not complete, the results of the syncpoint are not readily known. This is similar to failures while in-doubt, however, with a typical client/server architecture failure to the client often results in backout of server resources as servers detect "lost partner" and backout accordingly if in-flight.
A failed commit results in a heuristic completion if no database update calls were sent in this unit-of-work. A commit can only fail if the preceding "prepare" from the Requester succeeded. If the prepare was not successful it would cause the Commit Coordinator to begin backout processing. In other words, the window for commit failures is relatively small.
A failed rollback always completes heuristically. Note that a rollback only occurs while in-doubt if some other resource being managed by the Commit Coordinator responded negatively to the "prepare" request.
A commit failure which had updates outstanding is reported to the user as a "mixed outcome" by the Commit Coordinator. If Remote IMS is the only resource being managed by the Commit Coordinator this is somewhat misleading. It is also misleading if Remote IMS is the only resource that was updated in this unit-of-work. It is misleading because IMS/ESA ensures the data was either all committed or completely backed out. But, the Requester cannot tell which action IMS/ESA took so it is reported as a mixed outcome. That is, the Requester does not know if there was an error in sending the commit request to the Server or whether the Server processed the request and the error occurred in receiving the response. If you are updating multiple resources in the same unit-of-work an actual mixed outcome can result. See the chapter IMS Syncpoint Coordination for complete details on mixed outcomes and syncpoint error reporting.
Heuristic syncpoint completions enable the Requester and IMS Option to report a successful syncpoint even when a problem occurs exchanging syncpoints between the Requester and the Server. These are described as heuristic completions because, even though the Requester does not get an explicit response from the Server, it knows what happened to the IMS/ESA databases. It knows this from the way the Server program was coded and from how IMS/ESA handles CPI-C driven transactions.
A heuristic completion is simply the Requester informing the Commit Coordinator that the request completed successfully - even though there were some unexpected problems while processing the request. For example, consider a case where an application has no DL/I update calls outstanding in a unit-of-work. If the subsequent commit fails due to a communications error, the Requester informs IMS Option the commit succeeded anyway. It can do this because it knows the Server issued a backout in response to the Requester seeing the communications failure. This backout gives the same effect as a successful commit. That is, the database record locks are released. If the communications failure was actually a result of IMS/ESA failing, the effect is still the same. IMS/ESA does not restart CPI-C driven transactions so when IMS/ESA recovers the record locks do not exist.
Heuristic completions can also occur during rollback (backout). The main difference between heuristic commit and rollback is that rollbacks can complete heuristically even when DL/I updates are outstanding. This is because both the Server and IMS/ESA will backout in response to failures.
When a heuristic completion occurs you see a message box from the Requester informing you of this action. This message is issued after all other resources are committed or backed out by the Commit Coordinator.
Heuristic commit and rollback completions can be disabled by changing a configuration flag in the Remote IMS Server. You must disable them if you customize the Server program by adding DL/I or SQL statements to it which invalidate the Requester's knowledge of what occurred on IMS/ESA. See the section Heuristic Syncpoint Completion in the chapter Advanced Server Configuration for details.
Copyright © 1999 MERANT International Limited. All rights reserved.
This document and the proprietary marks and names used herein are protected by international law.
|Communication Details||Problem Determination|