Consider the following example:
GTM>set c=$ztrigger("S") ;trigger name: A#1# cycle: 1 +^A -commands=S -xecute="set ^B=200" ;trigger name: B#1# cycle: 1 +^B -commands=S -xecute="set $ztval=$ztval+1 " GTM>set ^A=100,^B=100 GTM>write ^A 100 GTM>write ^B 201
![]() | Note |
---|---|
Within trigger code, any SET operation on ^B recursively invokes trigger B#1. Therefore, always set $ZTVALUE to change the value node during trigger execution.GT.M executes the triggering update and all associated triggers within the same transaction, whether or not the original command is inside a transaction. This means that although the trigger logic sees the updated value of the node, it is not visible to other processes until the outermost transaction commits to the database. If there is a conflicting update by another process, GT.M RESTARTs the explicit or implicit transaction to resolve the conflict. |
Consider the following trivial example:
^Acct(id=:,disc=:) -commands=Set -xecute="Set msg=""Trigger Failed"",$ETrap=""If $Increment(^count) Write msg,!"" Set $ZTVAlue=x/disc"
![]() | Important |
---|---|
$ZJOBEXAM() dumps the context of a process at the time the function executes and the output may well contain sensitive information such as identification numbers, credit card numbers, and so on. You should secure the location of files produced by the MUPIP error handler or set up appropriate security characteristics for operating MUPIP. Alternatively, if you do not want MUPIP to create a $ZJOBEXAM() file, explicitly set the gtm_trigger_etrap environment variable to a handler such as "Write !,$ZSTATUS,!,$ZPOSITION,! Halt". Other key aspects of error handling during trigger execution are as follows: |