Why is error 15771 on Replication enabled target databases important?

Why is error 15571 on Replication enabled target databases important?
Will Informational error 15571 at replication target database startup cause issues?
Why must the source -L, -Mn and -n database startup parameters be used to start the target replication database?

Target database starts with a warning 15771 related to different startup parameters for -L or -Mn and -n
Why does Error 15571 care about the Lock Table when the replication target database is opened read-only (-ERO)
Why does the target database use the Lock Table at all when it’s updated in single-user mode?
All client sessions are connected to the target database in the read-only mode that do not require record or table locks.
Why does the Replication Agent (RPLA) need to create the entry in the Lock Table when nobody else can update or delete records on the target.

Informational error 15771 is written to the replication enabled Target database lg file when it is started with a Transaction Table size smaller than that of the source database.

Replication is AI based, specifically AI Transaction Notes are forward processed and these have transaction numbers. Transaction numbers are based on the Transaction Table in shared memory, which is sized by the database startup parameters :

• -L, Lock Table Size
• -Mn, Maximum Number of Servers + -n, Maximum Number of Users
• (and -maxxxids for JTA enabled databases from OpenEdge 11.3 and above)

When the forward processing begins, if the transaction number from source is not a transaction number that the target database can handle the target database will run into trouble with forward transaction processing. Which is why the target database is started with this warning.

It is possible the RPLA will not be able to complete synchronisation under these conditions. The consequences are described in Article:

•  Fathom Replication Agent is abnormally ending on function dsaAIApplyNote rlRecordGetLockManage 

It is advised to use higher values for the Lock Table  on the target database as the source database, which does use the Lock Table, will dynamically increase this value under Lock Table overflow (915) conditions, or otherwise may have been increased online explicitly with: PROUTIL -C increaseto -L <newvalue>.  Further discussion is provided in Article:

•  (15771) Message on replication target may be caused by source database increasing limit of -L by pulling from -Mxs pool.  

Since OpenEdge 12.2, the 15771 message is no-longer needed.

Enhancements have allowed a lot more database parameters that can be increased online with PROUTIL -C increaseto, PROMON or the _DbParams  VST. Apart from -L, -Mn and -n (max users) are among these new database parameters.

•  How to query Database Startup Parameters that can be modified with VST's?   

To this end, the transaction table size is no longer scoped or based on the parameters the database was started with. Instead, the transaction table is simply scoped to it's maximum size and be-done. This alleviates the overhead of having to additionally scale the transaction table on the source database, should related parameters be increased online in this version (onward).

Prior to OpenEdge 12.2: The 15771 Warning is important

In order to assure that AI transaction notes can successfully be forward processed:

1. Shutdown the target replication enabled database at the next earliest convenience
2. Change the database startup parameter values for -L, -Mn and -n to be greater than or (at least) equal to those of the source database, with special consideration for the Lock Table value as outlined above.

Progress Article:

Does a replication target database require the same parameters as the source database?