Novell Home

My Favorites

Close

Please to see your favorites.

The Definitive C05D and C067 TID.

This document (7002351) is provided subject to the disclaimer at the end of this document.

Environment

Novell GroupWise 6.5
Novell GroupWise 6
Novell GroupWise 5.5 Enhancement Pack
Novell GroupWise 5.5
Novell GroupWise 7
Novell GroupWise 8

Situation

Error: "C05D" on POA
Error: "C05D" on Client
Error: "C067" on POA
Error: "C067" on Client
The Definitive C05D and C067 TID.
 
Many user and message databases change from .db to .trn after running a GWCHECK with "storelowercase" while the POA is loaded.

Resolution

To manually fix a C05D follow these steps:
  1. Ensure that Verbose logging is enabled on the POA
  2. Find the line in the log where the C05D is reported  - here it is possible to see the specific database the the C05D is being reported against.
  3. Start the standalone version of GWCheck and fill in the Post Office information.
  4. In the User/Resource field enter the database name that you noted in Step 2, like USERxxx.DB.
  5. In Action select Structural Rebuild
  6. Select Run

If the check is successful you will see an Error 26 in the GWCheck log.  This means that the database registry entry has been removed from the guardian database (ngwguard.db).  It may be necessary to restart the POA as the problem database (or lack thereof) has been cached.

The only time that this has not worked is in the following scenario:

  1. A database has been manually renamed for some other problem, however, the file extension was left as .DB.  For example USERXYZ.DB was renamed to USERXYZOLD.DB
  2. A contents check was run on this Post Office which had the undesired effect of adopting the USERXYZOLD.DB in the guardian

The only solutions in this scenario are either a restore of the NGWGUARD.DB from backup or opening an incident with Novell Technical Services to have the problem entry removed from the guardian database.

UPDATE: This error can also be seen after a migration from NetWare to Linux.  It is a CASE issue and is the result of the case stored in the NGWGuard.db not matching the case of the database stored on disk.  If the instances of this error are few after a migration then the easiest solution is to simply reverse the case of the file, so USERXYZ.DB should be renamed to userxyz.db.

To prevent the problem in the first place on a migration use DBCOPY -m to move the data from NetWare to Linux - this should rename the files as they should be.  Note: Make sure you back up the post office directory before the next step, as in some cases GWCheck will delete the databases instead of changing the name to lower case. There is a support option in GWCheck that will swap the case of the files - STORELOWERCASE - make very sure to only use this option on POAs or standalone GWChecks newer than May 15 2006 as a serious issue was fixed that could have resulted in data loss.
 
Another solution would be to restore the ngwguard.db from a backup prior to the storelowercase being run. Rename all of the .trn files (in ofuser and ofmsg directories) to .db - e.g., userxyz.trn should be renamed back to userxyz.db

To manually fix a C067 follow these steps:

  1. Ensure that Verbose logging is enabled on the POA
  2. Find the line in the log where the C067 is reported  - here it is possible to see the specific database the the C067 is being reported against.
  3. Start the standalone version of GWCheck and fill in the Post Office information.
  4. In the User/Resource field enter the database name that you noted in Step 2, like USERxxx.DB.
  5. In Action select Analyze/Fix Databases - make sure Contents and Fix Problems are selected.
  6. Select Run

This should adopt the database into the guardian and the problem should be solved.  Again, a restart of the POA may be necessary to clear any cached entries.

Another way to solve this problem is as follows:

  1. Ensure that Verbose logging is enabled on the POA
  2. Find the line in the log where the C067 is reported  - here it is possible to see the specific database the the C067 is being reported against.
  3. Stop the POA
  4. Browse to the Post Office directory structure and rename the database that the C067 was reported against, ensuring that the extension is not left as .DB.
  5. Restart the POA and log in as the same user that generated the error.  Perform the same action that the user was performing.  This will create a new, empty version of the problem database.

At this point there are 2 choices:

  1. Continue with the empty database - nothing more needs to be done.
  2. Rename the original database back to .DB so no information is lost.  The POA will need to be stopped again for this.

Additional Information

"storelowercase" should never be run while the POA is loaded. NOTE: The server GWCHECK launched through ConsoleOne that is run BY the POA will run a storelowercase. This has been reported to engineering. Do NOT EVER run storelowercase as an option from the ConsoleOne launched Mailbox Maintenance, as the POA will not be able to rename many open databases, resulting in similar results as these.

The C05D and C067 errors are flip sides of the same coin. 

The C05D is always that the database in question is registered in the Guardian database but is not on disk. 

The C067 is always that the database in question is found on disk but is not registered in the guardian database.  In both cases the POA is not able to resolve the problems on it's own so manual intervention is needed.
Formerly known as TID# 10074228

Disclaimer

This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.

  • Document ID:7002351
  • Creation Date:12-JAN-09
  • Modified Date:12-DEC-12
    • NovellGroupWise

Did this document solve your problem? Provide Feedback