notes.ini variable – Tolerate Replication Errors


This is an interesting one that I have not come across before. We all know there are undocumented (or under-documented) notes.ini variables that can manipulate various aspects of the Domino server or the Noes client. The one I came across here today was new to me:

DEBUG_REPL_TOLERATE_ERRORS

What does it do?

Well, my current client has a rather large and very important application that we are trying to migrate to a new R8.5.2 server and we constantly running into replication errors. the reason for those errors are corrupted documents tat kill the replication process. I will not go into details as to the maintenance and othe attempts of fixing this dB we have done as it is not pertinent to the effect of the above variable.

IBM support gave us the variable with a hex code and asked us to enter it into the notes.ini via the Domino consoel nd the SET CONFIG command:

“set config DEBUG_REPL_TOLERATE_ERRORS=2C8”

I was not sure if a reboot is necessary but is appears that is not the case, it takes effect immediately, here is what the effects on replciation are:

sh config DEBUG_REPL_TOLERATE_ERRORS
DEBUG_REPL_TOLERATE_ERRORS=2C8
pull srv1 database.nsf
11/18/2011 11:40:05 AM  Remote console command issued by Victor Toal/xxx: pull srv1 database.nsf
pull srv1 database.nsf
11/18/2011 11:40:05 AM  Database Replicator started
11/18/2011 11:40:05 AM  Replicator is set to Ignore Database Quotas
GetTolerableErrors: adding 0x2C8=One or more of the source document's attachment are missing.  Run Fixup to delete the document in the source database.

As you can see, the variable adds a setting that lets the replicator ignore the indicated error – if that error appears in the replication stream the replicator task will simply skip over it and keep on going. From what I can tell right now you can only add one code at a time so I believe you cannot just add codes galore and have the replicator ignore every error there is.

The variable is not documented to receive the hex values that determine the codes the replicator will ignore you need to contact IBM support. But at least now you know that this variable exists and what it can do, armed with that knowledge you can request it when you next run into a similar situation and that this  might be a tool to help you solve your problem or correctly diagnose it.

Domino Crashes – capture data for later support calls and how to treat the notes.ini nice


I came across a technote (1447228 ) that was just updated – I actually have it in my personal knowledge dB where I keep allot of technotes that might be pertinent to the project I am working on at that time. The technote shows how to turn on debugging and the console log so that IBM support has some data to work with if you are dealing with a series of crashes.

I will not rehash the whole content of the technote but I want to point out one important topic: you do not have to restart the server for these settings to take effect – you can set them via the console.

Rule #1: never edit the notes.ini while the server is running.

I know it is technically possible (and easy to do) to use a text editing program to edit the notes.ini and more often than not it is not going to create trouble – however the Domino server relies heavily on this file and editing it without using the correct interface (= the server console) can cause the file to corrupt.

To us the notes.ini looks like a simple text file, for the Domino server it is a binary file that is expected to behave in a certain way. If the Domino server does not like the way the notes.ini just become corrupted then a whole lot of bodyly waste will hit the proverbial rotating blade and land on your lap.

The correct way to make ANY changes to the notes.ini WHILE THE DOMINO SERVER IS RUNNING is to use the [set config] command via the console. This rule is valid for all versions and OS releases of Domino. If the server is not running, you can use any text editor and make as many changes as you like, just keep the last line in the file an empty carriage return (= hit the enter key one) that is required.

Console Log and debugging information:

As the technote tells you, you need to turn the server console log on and enable debugging – AND you need to have NSD enabled via the server document.

If you are already dealing with outages, don’t bring the serve down once more – enable the settings via the server console:

start console log
set config DEBUG_THREADID=1

Incidentally, if you have an idea which part of the server is failing you can set additional debugging parameters for Domino via the server console as well.