SET $ZGBLDIR inside a trigger does the switch the first time. That changes the dollar_zgbldir.str
mstr to point to the new global directory. But once the trigger returns, the update process
switched gd_header back to what it was before the trigger was invoked (done as part of GTM-8789
in GT.M V6.3-003). But this does not switch dollar_zgbldir.str back to point to the original
gbldir. This out-of-sync situation means that future trigger invocations that do the SET $ZGBLDIR
to the same new global directory as before will incorrectly conclude (in op_svput) that
dollar_zgbldir.str already points to the gbldir of interest and so return prematurely. This means
that updates which happen inside the trigger will go to the original gbldir (with which the update
process started) and not the gbldir indicated in the SET $ZGBLDIR.
This is now fixed by doing a dpzgbini() call when gd_header is restored after a trigger returns.
This will result in dollar_zgbldir being in sync with gd_header.
SET $ZGBLDIR inside a trigger does the switch the first time. That changes the dollar_zgbldir.str mstr to point to the new global directory. But once the trigger returns, the update process switched gd_header back to what it was before the trigger was invoked (done as part of GTM-8789 in GT.M V6.3-003). But this does not switch dollar_zgbldir.str back to point to the original gbldir. This out-of-sync situation means that future trigger invocations that do the SET $ZGBLDIR to the same new global directory as before will incorrectly conclude (in op_svput) that dollar_zgbldir.str already points to the gbldir of interest and so return prematurely. This means that updates which happen inside the trigger will go to the original gbldir (with which the update process started) and not the gbldir indicated in the SET $ZGBLDIR.
This is now fixed by doing a dpzgbini() call when gd_header is restored after a trigger returns. This will result in dollar_zgbldir being in sync with gd_header.