$ cat restart
rm *.gld *.dat *.mj*
mumps -run GDE exit >& gde.out
mupip create >& mu_cre.out
mupip set -journal="enable,on,nobefore,epoch_interval=2" -reg "*" >& setjnl.out
mumps -run x
mupip journal -extract -noverify -detail -forward -fences=none mumps.mjl >& jnlext.out
grep -E "EPOCH|SET" mumps.mjf
$ cat x.m
set ^x=1 hang 8
set ^x=2 hang 5
set ^x=3 hang 1
set ^x=4 hang 1
set ^x=5
quit
Below is the output of the above test
0x000100d0 [0x00b8] :: EPOCH \64874,50932\1\1175120456\595\0\1\0\98\101\1
0x00010278 [0x0040] :: SET \64874,50932\1\3485712716\596\0\0\0\0\0\0\^x="1"
0x000102b8 [0x00b8] :: EPOCH \64874,50938\2\3647418316\596\0\0\0\96\101\1
0x00010370 [0x0040] :: SET \64874,50940\2\215069095\596\0\0\0\0\0\0\^x="2"
0x000103b0 [0x0040] :: SET \64874,50945\3\556710171\596\0\0\0\0\0\0\^x="3"
0x000103f0 [0x0040] :: SET \64874,50946\4\900332931\596\0\0\0\0\0\0\^x="4"
0x00010430 [0x00b8] :: EPOCH \64874,50947\5\301624417\596\0\0\0\96\101\1
0x000104e8 [0x0040] :: SET \64874,50947\5\3236711807\596\0\0\0\0\0\0\^x="5"
0x00010528 [0x00b8] :: EPOCH \64874,50948\6\4135141905\596\0\0\0\96\101\1
Notice that the epoch-interval is set to 2 seconds which means we expect at least one EPOCH record to be written between any updates that are separated by >= 2 seconds. But in the above case, we have the SET of ^x=2 done at 64874,50940 and the SET of ^x=4 done at 64874,50946 which are separated by 6 seconds (a lot more than the epoch-interval of 2 seconds) but still no EPOCH is written.
This is a regression introduced in GT.M V6.3-002 (most likely as part of GTM-8708).
Draft Release Note
The epoch_interval setting in a journal file is honored in all cases. That is, if two updates to the journal file are separated by N seconds where N is the epoch_interval setting, then the two updates are guaranteed to be separated by at least one EPOCH records in the journal file. Previously (starting GT.M V6.3-002), this setting was not honored in some cases (e.g. when an idle/free epoch got written) resulting in delaying the EPOCH by as much as 6 seconds.
Final Release Note
Description
Below is a test case that demonstrates the issue.
Below is the output of the above test
Notice that the epoch-interval is set to 2 seconds which means we expect at least one EPOCH record to be written between any updates that are separated by >= 2 seconds. But in the above case, we have the SET of ^x=2 done at 64874,50940 and the SET of ^x=4 done at 64874,50946 which are separated by 6 seconds (a lot more than the epoch-interval of 2 seconds) but still no EPOCH is written.
This is a regression introduced in GT.M V6.3-002 (most likely as part of GTM-8708).
Draft Release Note
The epoch_interval setting in a journal file is honored in all cases. That is, if two updates to the journal file are separated by N seconds where N is the epoch_interval setting, then the two updates are guaranteed to be separated by at least one EPOCH records in the journal file. Previously (starting GT.M V6.3-002), this setting was not honored in some cases (e.g. when an idle/free epoch got written) resulting in delaying the EPOCH by as much as 6 seconds.