I found out the following:
When reviewing journal data, a mysterious F IZ entry may be found. This entry is for INZPFM . However, an INZPFM was never done to the file.
This does not mean that an INZPFM was done to the file and no one is admitting to it. This entry is related to REUSEDLT records and concurrent writes. Concurrent writes improve performance to a file when several jobs attempt to write to a file at once. This is controlled by API QDBENCWT When several jobs are writing to a file, they each request a relative record number (RRN) to write to. They are assigned their RRN for the physical file; however, the actual journal entry write can occur in a different order. If the entry comes to the journal in a different order, an F IZ entry is used to initialize, or fill in, any unassigned RRNs in the journal.
The following is an example:
Job 1 gets assigned RRN 11.
Job 2 gets assigned RRN 12.
Job 3 gets assigned RRN 13.
Job 1 writes a journal entry for RRN 11.
Job 3 attempts to write a journal entry for RRN 13 but cannot leave a hole for RRN 12, so an F IZ for RRN 12 is written first.
Job 2 writes a journal entry for RRN 12.
A heavily modified SQL file can have occasional F IZ entries. It is done for performance reasons, and it is working as designed.
I ran multiple instances of an RPG program which was writing records to a file that was journalled and saw many F IZ entries. So it's not just SQL.