What I noticed
A DBA ran a CLRPFM on the source IBM i system a routine maintenance operation to clear out a physical file member. Nobody told the CDC team. A few minutes later, the target table was empty. No errors. No alerts. No explicit delete commands in the application logs. Connect CDC had replicated the clear exactly as designed, and the target reflected it faithfully.
IBM i journals changes natively. CDC simply reads this journal it does not query source tables, does not use triggers, and has zero impact on source application performance.The IBM i journal records entry types by code. For Record-level entries, the relevant types are: PT for Insert, UB for Before Update, UP for Update (After), and DL for Delete. When CLRPFM runs on a journaled IBM i table, the IBM i journal records that operation and CDC reads it from there.
The CLRPFM (Clear Physical File Member) command clears IBM i tables. This clear is then replicated to the target table. If the target database supports the truncate command, a truncate occurs. On databases that do not support the truncate command, an SQL DELETE statement is used to clear the table. This is used with copy and replication requests and overrides the setting in the Process Definition Properties dialog.
The setting that controls this behaviour is the Replicate CLRPFM parameter. This option must be set from the Mapping tab of the Table Properties page, and one of the following must be selected: Use Default uses the process default, where the Change Selector default values are derived from the values specified on the Process Definition Properties Advanced tab dialog; Yes always replicate the CLRPFM journal entry, No do not replicate the CLRPFM journal entry.
There are also hard boundaries on this feature. A CLRPFM command done by rpuser is ignored. CLRPFM is not available for bi-directional mappings. For non-journal mappings, all calls for value from data enhancement for a CLRPFM operation are bypassed.
One more boundary that catches people off guard: the Replicate CLRPFM setting on the Change Selector Process Definition Properties, Advanced page will have no effect on whether the remote journal entry is replicated. The per-table mapping setting on the Table Properties Mapping tab is what actually controls it not the process-level default when a remote journal is involved.
Why this design works
- Predictability: Connect CDC reads the IBM i journal as the authoritative source of truth. CLRPFM emits a journal entry. CDC reads that entry and acts on it. The behavior is consistent with every other operation CDC replicates.
- Reliability: If a clear physical file member occurs and is replicated, the target table will be cleared to match what occurred on the source table. If a clear physical file member occurs but is not replicated, any subsequent changes made to the source table could be updating the incorrect target columns, unless the table is resynchronized. Both outcomes are documented and intentional.
- Operational Safety: The per-mapping control exists precisely because different tables have different protection requirements. Staging tables that get cleared frequently are different from transaction tables that should never be cleared at the target without explicit intent.
What's different for SQL targets / remote journals / bi-directional mappings
There is one extra step.
- For SQL targets that support TRUNCATE CDC issues a TRUNCATE, which is fast but may affect transaction log behavior differently than a DELETE.
- For SQL targets that do not support TRUNCATE CDC issues a DELETE statement. SQL transaction log growth is a concern when fallback DELETE operations are used to clear tables during replication. DELETE operations consume transaction log space in a way that TRUNCATE does not. Size this correctly if CLRPFM runs frequently on large tables.
- For remote journal configurations the per-table Replicate CLRPFM mapping setting controls the behaviour, not the process-level Change Selector property.
- For bi-directional mappings CLRPFM replication is not available. If a CLRPFM occurs on a table included in a bi-directional mapping, it is not replicated in either direction.
- Copy operations can be interrupted when CLRPFM events occur on IBM i systems, affecting Capture Server behavior. If CLRPFM runs during a copy phase, the timing and interaction with the capture server needs to be understood before running maintenance during active replication windows.
Why this matters in production
CLRPFM is a common IBM i maintenance operation. It is often run by DBAs or batch jobs outside of application context. It does not look like a DELETE from the application layer. It leaves no SQL trace at the source. But it produces a journal entry that Connect CDC reads and acts on and the target responds immediately.
If you ever see a target table empty after a quiet maintenance window on the source IBM i, it is not a CDC error. It is Connect CDC doing exactly what it was configured to do and the question is whether the Replicate CLRPFM setting was configured to match your intent.
The setting is per-table, on the Mapping tab of Table Properties. The default inherits from the process. If you have not explicitly set it per table, the process default determines what happens and the default may not match your expectations for every table in the model.
What changed for me
I used to treat CLRPFM as an IBM i administration operation that was invisible to replication. It is not invisible. It produces a journal entry. CDC reads journal entries. The connection is direct. I now confirm the Replicate CLRPFM setting for every table during model review especially for staging tables, load tables, and any physical file that operations teams clear on a schedule. The setting is easy to miss because it is per-table and not visible at the distribution or request level.
Takeaway
CLRPFM emits a journal entry on IBM i. Connect CDC reads that entry and replicates the clear to the target as a TRUNCATE if the target supports it, or as a DELETE if it does not. The Replicate CLRPFM option on the Table Properties Mapping tab controls this per table. The process-level default applies when no table-level override is set. CLRPFM is not available for bi-directional mappings, and the remote journal process property does not override the table mapping setting.
Have you encountered unexpected target table clears caused by CLRPFM events on IBM i and how did you adjust the per-table mapping settings to protect the tables that matter most?
*Precisely Software Inc.