If a trigger in the update process does a SET $ZGBLDIR to switch global directories from say GBLDIR1 to GBLDIR2 (without doing a NEW $ZGBLDIR), the update process switches back to the original global directory GBLDIR1 on return from the trigger but it does an incomplete job of switching back so future SET $ZGBLDIR commands which switch to GBLDIR2 in the trigger prematurely return without switching the global directory resulting in all following updates in the trigger happening in GBLDIR1 instead of the intended GBLDIR2. GT.M V6.3-003 is when the code was fixed to switch back the update process to GBLDIR1 after a trigger return (as part of GTM-8789) but the fix was not complete in that it did not take SET $ZGBLDIR into account (it fixed a SIG-11 in NEW $ZGBLDIR).
Draft Release Note
The Update Process operates correctly when a trigger issues a SET $ZGBLDIR to switch the current global directory (without doing a NEW $ZGBLDIR). Previously it used to switch the global directory correctly the first time the trigger was invoked but later invocations of the trigger did not switch the global directory resulting in any updates in the trigger code unintentionally happening in the primary global directory with which the update process was started. A workaround in prior versions was to do a NEW $ZGBLDIR before the SET $ZGBLDIR in the trigger code.
Final Release Note
Description
If a trigger in the update process does a SET $ZGBLDIR to switch global directories from say GBLDIR1 to GBLDIR2 (without doing a NEW $ZGBLDIR), the update process switches back to the original global directory GBLDIR1 on return from the trigger but it does an incomplete job of switching back so future SET $ZGBLDIR commands which switch to GBLDIR2 in the trigger prematurely return without switching the global directory resulting in all following updates in the trigger happening in GBLDIR1 instead of the intended GBLDIR2. GT.M V6.3-003 is when the code was fixed to switch back the update process to GBLDIR1 after a trigger return (as part of GTM-8789) but the fix was not complete in that it did not take SET $ZGBLDIR into account (it fixed a SIG-11 in NEW $ZGBLDIR).
Draft Release Note
The Update Process operates correctly when a trigger issues a SET $ZGBLDIR to switch the current global directory (without doing a NEW $ZGBLDIR). Previously it used to switch the global directory correctly the first time the trigger was invoked but later invocations of the trigger did not switch the global directory resulting in any updates in the trigger code unintentionally happening in the primary global directory with which the update process was started. A workaround in prior versions was to do a NEW $ZGBLDIR before the SET $ZGBLDIR in the trigger code.