Re: Journal Code F - Type IZ - INZPFM

It is indeed mysterious. More so in that it doesn't happen in ALL files.
Nor is it all updates.

I thought it may be an SQL table thing. But other files are DDS. One series of files are written to via DDM. Others are local.

From https://www.ibm.com/support/pages/sql-insert-causes-f-iz-entry-journal:

"Problem
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.

Resolving The Problem
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'm not sure I understand that, but it sounds like the seize function you mentioned.



_____________________________________________________________________
Spirax-Sarco Engineering Plc. This e-mail has been scanned for viruses by Cisco Cloud Email Security.