The r124/jnlunxpcterr subtest (written for #284) failed in internal testing once in around
1000 runs with a JNLBADRECFMT error from MUPIP JOURNAL EXTRACT. This is not expected after
the original fixes for #284 which ensured no JNLUNXPCTERR error is issued.
Turns out in the test failure, the EOF record was overwritten and we saw a good first half
of the EOF record in the EXTRACT process but saw an invalid second half. The 4-byte record
suffix did not point back to the beginning of the record or have the 0xeb journal record
end byte marker. While it is not exactly clear how such an error is possible in the test
failure where we know for sure the EOF record did not straddle an offset that is a multiple
of the filesystem block size (0x1000), it is definitely a known issue if the EOF record did
straddle such an aligned boundary and so we handle that by skipping this badly formatted
record and extracting whatever else is possible after this record and treating the situation
as a JNLREADEOF if this badly formatted record is the last known valid record in the journal file.
The r124/jnlunxpcterr subtest (written for #284) failed in internal testing once in around 1000 runs with a JNLBADRECFMT error from MUPIP JOURNAL EXTRACT. This is not expected after the original fixes for #284 which ensured no JNLUNXPCTERR error is issued.
Turns out in the test failure, the EOF record was overwritten and we saw a good first half of the EOF record in the EXTRACT process but saw an invalid second half. The 4-byte record suffix did not point back to the beginning of the record or have the 0xeb journal record end byte marker. While it is not exactly clear how such an error is possible in the test failure where we know for sure the EOF record did not straddle an offset that is a multiple of the filesystem block size (0x1000), it is definitely a known issue if the EOF record did straddle such an aligned boundary and so we handle that by skipping this badly formatted record and extracting whatever else is possible after this record and treating the situation as a JNLREADEOF if this badly formatted record is the last known valid record in the journal file.