Syncpoints in MQSeries for Compaq NonStop Kernel applications

When using MQSeries for Compaq NonStop Kernel, transaction management is performed under the control of the Compaq NonStop Kernel TM/MP product, rather than by MQSeries for Compaq NonStop Kernel itself.

The effects of this difference are:

The default SYNCPOINT option for the MQPUT and MQGET calls is SYNCPOINT, rather than NO_SYNCPOINT.
To use the default (SYNCPOINT) option for MQPUT, MQGET, and MQPUT1 operations, the application must have an active TM/MP Transaction that defines the unit of work to be committed. An application initiates a TM/MP transaction by calling the BEGINTRANSACTION() function. All MQPUT, MQPUT1, and MQGET operations performed by the application while this transaction is active are within the same unit of work (transaction). Any other database operations performed by the application are also within this unit of work (UOW). Note that there are system-imposed limits on the number and size of messages that can be written and deleted within a single TM/MP transaction. When the application has completed the UOW, the TM/MP transaction is ended (the UOW is committed) using the ENDTRANSACTION() function. If any error is encountered, the application can cancel the TM/MP transaction (backout the UOW) using the ABORTTRANSACTION() function. Consequently, the standard Version 2 functions MQCMIT() and MQBACK() are not supported on this product. If they are called, an error is returned.
If an application uses the NO_SYNCPOINT option for MQPUT, MQGET, and MQPUT1 operations, WebSphere MQ starts a TM/MP transaction itself, performs the queuing operation, and commits the transaction before returning to the application. Each operation is therefore performed in its own UOW and, once complete, cannot be backed out by the application using TM/MP.
A TM/MP transaction does not need to be active for MQI calls other than MQGET, MQPUT, and MQPUT1.
Because TM/MP can cause previously performed MQGET, MQPUT, and MQPUT1 operations to be backed out without notification, the current queue-depth and input-and-output-open counts of queues can become inaccurate. The WebSphere MQ Status Server (MQSS) corrects these periodically. You can configure the time interval used. However, you should code applications to allow for errors in these quantities, especially where there could be backed-out transactions.
The back-out count attribute cannot be maintained in the same way as on standard Version 2 implementations. Also, the harden backout count attribute is not used.
The MQRC_SYNCPOINT_LIMIT_REACHED reason code is used by MQSeries for Tandem NonStop Kernel V2.2.0.1 to inform an application that the system-imposed limit on the number of I/O operations within a single TM/MP transaction has been reached. If the application specified the SYNCPOINT option, it should cancel the transaction (back out the UOW) and retry with a smaller number of operations in that UOW.
The MQRC_UOW_CANCELED reason code informs the application that the UOW (TM/MP transaction) has been canceled, either by the system itself (TM/MP imposes some system-wide resource-usage thresholds that will cause this), by user action, or by the initiator of the transaction itself.

Using MQGET wait interval and channel DISCINT and HBINT

When performing MQGET using MQGMO_NO_SYNCPOINT, a TM/MP transaction is started and ended by MQSeries only when a persistent message is available that satisfies the retrieval criteria. No consideration needs to be given by applications to the value of WaitInterval for no syncpoint operation.

For an MQGET issued with the MQGMO_SYNCPOINT or MQGMO_SYNCPOINT_IF_PERSISTENT option, the TM/MP transaction is under the control of the user application which issues the BEGINTRANSACTION. The wait interval should not exceed the TMF Autoabort timeout value and ideally should be small to avoid pinning a significant amount of the TM/MP audit trail (values under a minute should normally be used). Specifying wait unlimited on a lightly used queue or a queue that is idle overnight may cause the autoabort timeout to be exceeded and a MQRC_UOW_CANCELED (2297) to be returned to the MQGET when a message becomes available on the queue. Having a high wait interval or using unlimited can cause TMF audit trails to be pinned, eventually leading (if uncorrected) to the TM/MP subsystem disabling transactions on a system-wide basis.

Similarly the DISCINT value and HBINT value for sending channels controls the length of a TM/MP transaction. Channels are capable of cycling transactions when idle to allow long disconnect intervals, without having a detrimental affect on TM/MP audit trails.

A parameter, MQTRANSACTIONLIFE, can be used to control the refreshing of the TM/MP transaction for channel disconnect intervals and heartbeats that are zero. This is useful if a longer or shorter TM/MP transaction life is desired or to change the amount TM/MP activity the idle channel produces. A higher value will produce less, a lower setting more.

Add to each MQSeries MQS-ECxx PATHWAY server class:

PARAM MQTRANSACTIONLIFE <number>

where <number> is a number such as 100.

This parameter overrides the use of the 10 second default TM/MP transaction refresh interval. For example, a channel with a disconnect interval unlimited without the parameter would cause a refresh approximately every 10 seconds while it waits for a message to arrive.