From the screen of iCluster's WRKCSMON command, I notice only one file being suspended.  This file is being journalled to iCluster's HADJRN journal.  (Most files have their own journals created by the application itself.)  When I look at iCluster job (with a name of the replication group I create) at the Backup node that covers this suspended file, I find many instances of the following message in its job log :

Message ID . . . . . . :   CPF4759       Severity . . . . . . . :   30      
Message type . . . . . :   Sender copy                                      
Date sent  . . . . . . :   25/08/23      Time sent  . . . . . . :   22:15:01
                                                                            
Message . . . . :   Write operation to member PZFACTJB failed. (C I)        
Cause . . . . . :   The write operation failed because a record at relative 
  record number 10 of member PZFACTJB file PZFACTJB in library LIBA   
  already exists.                                                           
Recovery  . . . :   Type C to cancel the job or type I to ignore the request
  to write and continue the job.  For some applications, you may change the 
  relative record number and try the request again.                         
Possible choices for replying to message . . . . . . . . . . . . . . . :    
  C -- The request is canceled.                                             
  I -- The request is ignored.                                              

This surprises me as I could not understand why iCluster writes to the target file at the Backup node with RRN?    What is the reason to use write with RRN?   Am I correct to assume this happen only for a special reason? 

------------------------------
Satid Singkorapoom
IBM i SME
Rocket Forum Shared Account
------------------------------

Hi Satid,

Thank you for the question.

First let me say that it appears from the message issued that you have shared that the file PZFACTJB is out of sync and needs to be resynced.  iCluster provides several methods for syncing a file which you are probably familiar with.  Unless this file is very large and needs special handling the easiest method to resync the file would be to activate the file with a 'refresh' action.  Command similar to this:  DMACTOBJ GROUP(ABCGROUP) OBJ(SMEU3PYZW/PZFACTJB) OBJTYPE(*FILE) will initiate the REFRESH action.  Once the resync is complete, normal replication will resume.

I would also suggest, although not required, that you set up a default journal for each replication group that is outside the iCluster library.  In the future, maintenance and backing up the iCluster library will be much less painful if you avoid using the HADJRN and HABSFJRN in the iCluster library.

To answer your question regarding RRN, this is the method iCluster uses (as default) to update the target file.  Relative Record Number can be relied upon to update the target file and keep the replication with a high degree of accuracy.  iCluster does support keyed replication however the configuration is much more complex and requires the file(s) have an index for referencing the correct record.  RRN replication is very easy for you to manage and provides an indication when the files are out of sync when an update fails.

Dear Mark

>>>> I would also suggest, although not required, that you set up a default journal for each replication group that is outside the iCluster library.  In the future, maintenance and backing up the iCluster library will be much less painful if you avoid using the HADJRN and HABSFJRN in the iCluster library. <<<<<

Does this mean that I explicitly specify the default database journal name rather than *CLUSTER  in DMADDGRP command ?