Skip to content
Manuals
GT.M Programmer's Guide
$ZQGBLMOD()

$ZQGBLMOD()

$ZQGBLMOD()

The $ZQGBLMOD function enables an application to determine whether it can safely apply a lost transaction to the database. A lost transaction is a transaction that must be rolled off a database to maintain logical multisite consistency. $ZQGBLMOD() always applies to data-level (level-0) nodes.

The format for the $ZQGBLMOD function is:

$ZQGBLMOD(gvn)
  • The subscripted or non-subscripted global variable name (gvn) specifies the target node.
  • A return value of zero (0) means the value of the global variable has not changed since the last synchronization of the originating and replicating instances.
  • A return value of one (1) means the value of the global variable may have changed since the last synchronization of the originating and replicating instance.

$ZQGBLMOD function produces an error if you submit an argument that is not a global variable name.

Internally, $ZQGBLMOD (gvn) compares the GT.M transaction number in the database block in which the global variable name is (or would be) stored with the value in the Zqgblmod_Trans field stored in the database file header.

For example, if x is the transaction number of the level-0 database block in which gvn resides, and y is the value of Zqgblmod_Trans of region reg containing gvn, then the following is true:

  • If x <= y, no transaction modified the level-0 database block z in which gvn resides since the originating and replicating instances synchronized with each other. $ZQGBLMOD() returns a zero (0).
  • If x > y, some transaction modified z, but not necessarily gvn, after the originating and replicating instances synchronized with each other. $ZQGBLMOD() returns a one (1).

If a transaction is a lost transaction that has been rolled back and it is determined that for all the M globals set and killed in the transaction $ZQGBLMOD() is zero (0), it is probably safe to apply the updates automatically. However, this determination of safety can only be made by the application designer and not by GT.M. If the $ZQGBLMOD() is one (1) for any set or kill in the transaction, it is not safe to apply the update.

The test of $ZQGBLMOD() and applying the updates must be encapsulated inside a GT.M transaction.

Another approach to handling lost transactions would be to store in the database the initial message sent by a client, as well as the outcome and the response, and to reprocess the message with normal business logic. If the outcome is the same, the transaction can be safely applied.

If restartable batch operations are implemented, lost batch transactions can be ignored since a subsequent batch restart will process them correctly.
$ZSYSLOG()$ZSEARCH()