Under transaction control, new space was reserved at the end of a variable-length file, and the preimage space received an entry that marked the space as deleted if the transaction was aborted. When a write to this space (say as part of an ADDVREC()) was made, still under the same transaction control, preimage received another entry. However, until either a commit or an abort, the new region appeared to other users to be simply ff-filled. When another user was scanning the variable-length file in physical order, e.g., with NXTVREC(), this would cause a VFLG_ERR (158), since 0xffff is not a valid record mark. A fixed-length file does not behave this way because ff-fill appears as a deleted record to be skipped during physical order scan.
In V8.14 this behavior was changed such that not only is preimage space updated with the deleted record mark, but also a write is issued to the actual file with the same contents. This option reverts that behavior.