MQBACK - Back out changes

Syntax

MQBACK (Hconn, Compcode, Reason)

Parameters

Hconn

Type: MQHCONN - input

This handle represents the connection to the queue manager. The value of Hconn was returned by a previous MQCONN or MQCONNX call.

Compcode

Type: MQLONG - output

The completion code; it is one of the following:

MQCC_OK

Successful completion.

MQCC_WARNING

Warning (partial completion).

MQCC_FAILED

Call failed.

Reason

Type: MQLONG - output

If CompCode is MQCC_OK:

MQRC_NONE

(0, X'000') No reason to report.

If CompCode is MQCC_WARNING:

MQRC_OUTCOME_PENDING

(2124, X'84C') Result of back-out operation is pending.

If CompCode is MQCC_FAILED:

MQRC_ADAPTER_SERV_LOAD_ERROR

(2130, X'852') Unable to load adapter service module.

MQRC_API_EXIT_ERROR

(2374, X'946') API exit failed.

MQRC_ASID_MISMATCH

(2157, X'86D') Primary and home ASIDs differ.

MQRC_CALL_IN_PROGRESS

(2219, X'8AB') MQI call entered before previous call complete.

MQRC_CF_STRUC_IN_USE

(2346, X'92A') Coupling-facility structure in use.

MQRC_CONNECTION_BROKEN

(2009, X'7D9') Connection to queue manager lost.

MQRC_ENVIRONMENT_ERROR

(2012, X'7DC') Call not valid in environment.

MQRC_HCONN_ERROR

(2018, X'7E2') Connection handle not valid.

MQRC_OBJECT_DAMAGED

(2101, X'835') Object damaged.

MQRC_OUTCOME_MIXED

(2123, X'84B') Result of commit or back-out operation is mixed.

MQRC_Q_MGR_STOPPING

(2162, X'872') Queue manager shutting down.

MQRC_RESOURCE_PROBLEM

(2102, X'836') Insufficient system resources available.

MQRC_STORAGE_MEDIUM_FULL

(2192, X'890') External storage medium is full.

MQRC_STORAGE_NOT_AVAILABLE

(2071, X'817') Insufficient storage available.

MQRC_UNEXPECTED_ERROR

(2195, X'893') Unexpected error occurred.

For detailed information about these codes, see Messages and reason codes

Usage notes

1. You can use this call only when the queue manager itself coordinates the unit of work. This can be:
   • A local unit of work, where the changes affect only MQ resources.
   • A global unit of work, where the changes can affect resources belonging to other resource managers, as well as affecting MQ resources.
   For further details about local and global units of work, see MQBEGIN - Begin unit of work.
2. In environments where the queue manager does not coordinate the unit of work, use the appropriate back-out call instead of MQBACK. The environment might also support an implicit back out caused by the application terminating abnormally.
   • On z/OS, use the following calls:
     • Batch programs (including IMS batch DL/I programs) can use the MQBACK call if the unit of work affects only MQ resources. However, if the unit of work affects both MQ resources and resources belonging to other resource managers (for example, Db2® ), use the SRRBACK call provided by the z/OS Recoverable Resource Service (RRS). The SRRBACK call backs out changes to resources belonging to the resource managers that have been enabled for RRS coordination.
     • CICS® applications must use the EXEC CICS SYNCPOINT ROLLBACK command to back out the unit of work. Do not use the MQBACK call for CICS applications.
     • IMS applications (other than batch DL/I programs) must use IMS calls such as ROLB to back out the unit of work. Do not use the MQBACK call for IMS applications (other than batch DL/I programs).
   • On IBM® i, use this call for local units of work coordinated by the queue manager. This means that a commitment definition must not exist at job level, that is, the STRCMTCTL command with the CMTSCOPE(*JOB) parameter must not have been issued for the job.
3. If an application ends with uncommitted changes in a unit of work, the disposition of those changes depends on whether the application ends normally or abnormally. See the usage notes in MQDISC - Disconnect queue manager for further details.
4. When an application puts or gets messages in groups or segments of logical messages, the queue manager retains information relating to the message group and logical message for the last successful MQPUT and MQGET calls. This information is associated with the queue handle, and includes such things as:
   • The values of the GroupId, MsgSeqNumber, Offset, and MsgFlags fields in MQMD.
   • Whether the message is part of a unit of work.
   • For the MQPUT call: whether the message is persistent or nonpersistent.
   The queue manager keeps three sets of group and segment information, one set for each of the following:
   • The last successful MQPUT call (this can be part of a unit of work).
   • The last successful MQGET call that removed a message from the queue (this can be part of a unit of work).
   • The last successful MQGET call that browsed a message on the queue (this cannot be part of a unit of work).

5. The information associated with the MQGET call is restored to the value that it had before the first successful MQGET call for that queue handle in the current unit of work.

   Queues that were updated by the application after the unit of work started, but outside the scope of the unit of work, do not have their group and segment information restored if the unit of work is backed out.

   Restoring the group and segment information to its previous value when a unit of work is backed out allows the application to spread a large message group or large logical message consisting of many segments across several units of work, and to restart at the correct point in the message group or logical message if one of the units of work fails.

   Using several units of work might be advantageous if the local queue manager has only limited queue storage. However, the application must maintain sufficient information to be able to restart putting or getting messages at the correct point if a system failure occurs.

   For details of how to restart at the correct point after a system failure, see the MQPMO_LOGICAL_ORDER option described in MQPMO - Put message options, and the MQGMO_LOGICAL_ORDER option described in MQGMO - Get-message options.

   The remaining usage notes apply only when the queue manager coordinates the units of work.

6. A unit of work has the same scope as a connection handle. All MQ calls that affect a particular unit of work must be performed using the same connection handle. Calls issued using a different connection handle (for example, calls issued by another application) affect a different unit of work. See the Hconn parameter described in MQCONN - Connect queue manager for information about the scope of connection handles.
7. Only messages that were put or retrieved as part of the current unit of work are affected by this call.
8. A long-running application that issues MQGET, MQPUT, or MQPUT1 calls within a unit of work, but that never issues a commit or backout call, can fill queues with messages that are not available to other applications. To guard against this possibility, the administrator must set the MaxUncommittedMsgs queue manager attribute to a value that is low enough to prevent runaway applications filling the queues, but high enough to allow the expected messaging applications to work correctly.

C invocation

MQBACK (Hconn, &CompCode, &Reason);

MQHCONN  Hconn;     /* Connection handle */
MQLONG   CompCode;  /* Completion code */
MQLONG   Reason;    /* Reason code qualifying CompCode */

COBOL invocation

CALL 'MQBACK' USING HCONN, COMPCODE, REASON.

**   Connection handle
 01  HCONN     PIC S9(9) BINARY.
**   Completion code
 01  COMPCODE  PIC S9(9) BINARY.
**   Reason code qualifying COMPCODE
 01  REASON    PIC S9(9) BINARY.

PL/I invocation

call MQBACK (Hconn, CompCode, Reason);

dcl Hconn     fixed bin(31);  /* Connection handle */
dcl CompCode  fixed bin(31);  /* Completion code */
dcl Reason    fixed bin(31);  /* Reason code qualifying CompCode */

High Level Assembler invocation

CALL MQBACK,(HCONN,COMPCODE,REASON)

HCONN     DS  F  Connection handle
COMPCODE  DS  F  Completion code
REASON    DS  F  Reason code qualifying COMPCODE

Visual Basic invocation

MQBACK Hconn, CompCode, Reason

Dim Hconn    As Long 'Connection handle'
Dim CompCode As Long 'Completion code'
Dim Reason   As Long 'Reason code qualifying CompCode'