What does the driver's "Write Time Stamps?" publisher parameter do? The driver documentation and configuration have a general description about this parameter, but I don't know enough about it to enable or disable this parameter for my Notes driver configuration.
Regarding the "Write Time Stamps?" parameter, the documentation states: "Whether ndsrep writes special driver time stamp on synchronized Notes parameter. Set to True to have ndsrep write a driver specific time stamp on all Notes objects that are synchronized. This special driver time stamp is used to more accurately determine Notes object attribute updates. Set to False to have ndsrep determine Notes object attribute updates based on existing Notes object time stamps."
And the configuration states: "Select true to attach a Notes Driver specific timestamp to each object that is modified by the Notes Driver, to improve the Driver's capabilities of detecting object changes from replicated databases. Select false to disallow any special timestamps from being attached to Notes objects."
The actual publisher-option parameter passed to the NotesDriverShim is "write-timestamps-flag" and stores a Boolean value. The NotesDriverShim writes this parameter to the ndsrep configuration file dsrepcfg.nsf. It is stored there as a field named WriteTimeStamps_number, which can be read and utilized by ndsrep. This "Write Time Stamps?" parameter was initially incorporated into the driver as a debugging parameter and tool. A customer could set it, run the driver, and then have a time-stamp discussion with Novell support engineers to remove many of the communication problems concerning the different time stamps associated with a Notes document. The parameter continues to be available within the driver as an option to IDM administrators and Novell support engineers that may have a need to understand, control, or debug time stamp and data synchronization issues for the driver.
ndsrep uses polling to determine what Notes documents (objects) and fields (attributes) within a Notes database have changed. ndsrep polls the synchronized database and asks for all the documents that have changed since the last polling cycle. Obviously, time stamps are used to determine which objects have been changed and if those changes represent an add or a modify event. If the "Write Time Stamps?" publisher parameter is set to true, then the Notes Driver will write its own 'time stamp' field value on the synchronized Notes documents. The field is named $NDSREPLastProcessedTime. This timestamp value can then be utilized by ndsrep for object polling analysis.
What are the drawbacks of the "less accurate" write-timestamps-flag='false' mode?
Contrary to the description in the documentation, I really don't know if writing the $NDSREPLastProcessedTime field time stamp is actually less or more accurate than not writing it. One difference is that the process writing the time stamp is also the same one that is reading, comparing, and analyzing it. In this way, a Notes driver using a $NDSREPLastProcessedTime field is less prone to suffer from time stamp 'mis-interpretation' on Domino servers that are experiencing time synchronization problems.
Am I going to lose events if write-timestamps-flag='false'?
It's doubtful. If your Domino servers are not experiencing time sync issues, then setting the value to 'false' is the recommended option. This is the recommended option because it is less intrusive to the Notes object data. In other words, there is no need to write $NDSREPLastProcessedTime fields on all the objects ndsrep touches, if the existing Notes document time stamps are working just fine for your Notes configuration.
How is write-timestamps-flag='true' handled with multiple drivers?
The Notes Driver's publisher channel write-timestamps-flag='true' setting/feature has undefined results when running multiple versions of ndsrep against the same Notes database.
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.