Journal sequence number reset attempt - CPF7018 Reason Code 1

Hello All!

We are at 7.1.

We run our jobs 7/24 with minimal downtime. We use journaling to replicate the database to our DR site.
The receiver is defined as *MAXOPT2, allowing us maximum sequence number of 9,999,999,999.

The journal manager normally resets the sequence number at around 2 billion. If it fails, then the reset is attempted every 5 minutes.

All worked fine for a long time(many years), but not any longer. The system is not able to reset the sequence number, which is at around 7 billion now.

The error message is always the same: CPF7018 with Reason Code 1:

1 -- A journaled object associated with the current journal receiver chain has changes that have not been forced to auxiliary storage.


We have over 200 jobs in this environment and there are over 3000 objects included into this replication. We tried to identify jobs/objects causing this problem, but without success.

Now we will bring down the whole environment for a brief time - this will resolve the issue for sure.

My question is: is there a way to identify which objects are causing RC 1? I mean, by looking to somewhere, can we see the list of objects which have pending changes but have not been forced to auxiliary storage?

Knowing this information, we can ask the developers to improve the code, if possible.

Or is there a way to force these pending changes to be written to disk without closing the programs?

Many thanks,
Andras Cser