Warning: Unable to set GroupWise timestamp for user database USERXXX.db. Error code: 0x47576530

Warning: Unable to set GroupWise timestamp for user database
USERXXX.db.
Error code: 0x47576530

The TSAFS automatic timestamp functionality requires that the GroupWise 6.5.3 or later engine be installed. GroupWise 6.5.3 is the first version to support the TSAFS timestamp functionality.

If loading GroupWise in protected memory you will need to load a separate instance of the Gwenn4.nlm in address space 0 (ring 0) for the Tsafs to work when backing up GroupWise. Address space 0 is the regular os address space where most nlms load by default, This can be done via the load script for the cluster resource, or, on a non cluster server you can add a load command to the Autoexec.ncf to load Gwenn4.

Syntax for loading gwenn4,nlm in address space 0 is:

load gwenn4.nlm

You can verify what address space nlms are loaded in by typing m on the server console.

Insure that you have the updated 6.5.3 or later Gween4.nlm in the sys:\system directory. In the event you are loading NLMs from some where other then system you are also updating the NLMs in a place other then system when you update the GroupWise system. This could leave you with an older version of Gween4 in the sys:\system directory. The TSA pulls the Gween4 it uses from the sys:\system directory.


FYI--For more information on loading nlms in protected address space, or ring3, please refer to TID:
TID2942300

The tsafs has enough functionality built into it (without the aid of GroupWise 6.5.3) to safely back up and restore the data.The backup timestamp supports the SmartPurge feature. If SmartPurge is not enabled, the backup timestamp is irrelevant. If SmartPurge is enabled and the backup timestamps are NOT updated, no data loss occurs. What does happen is that the system will not allow items to be purged whose timestamp is newer than the backup timestamp. This will eventually run the system out of disk space. In order to properly function, the value of the backup timestamp should be the time before the backup takes place. The difficulty, however, is that one does not want to set the backup timestamp until one is sure that a backup has been successful. In the software, we take note of the system time before trying to back up a database, then set the backup timestamp on the live copy of the database after the database has been successfully backed up (using the time value gathered before the backup commenced.) If one were to use the timestamp utility against the post office after a successful backup, there is the possibility that messages which arrived during the course of the backup would not be protected by SmartPurge. If one were to use the timestamp utility against the post office before a successful backup, all is well. If one were to use the timestamp utility against the post office before a failed backup, all messages in the system received after the most recent successful backup, but prior to the timestamp would be unprotected by SmartPurge. The timestamp utility allows the user to specify the time for the timestamp. Therefore, for proper use in this environment, one would note the time before starting the backup, and upon successful backup completion, use the timestamp utility to apply the 'backup start time' to the live system.