Found this one looking through technotes today, really interesting. I often set up servers to run off-line maintenance on dB and often have servers running 32bit Domino on 64bit Windows. I have not yet run into a case where I noticed the additional errors that might pop up but is it good to now that I can ignore them. I like my off-line maintenance routines and do not want to have to change them.
IBM Unknown errors running utilities – United States.
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:
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
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.