A Forum reader recently asked:
"I tried running a standalone GWCheck and found some
corrupt e-mails in the database. After fixing them, I started a new scheduled job on the post office, only on user databases, but the problem has appeared once again. I found a lot of *.ckl files for every user in WPCSOUT\CHK. What should I do with them?"
And here's the response from Gary Whaley ...
We had a very similar problem a while ago. In our case I tracked the problem to code 83: "Items that have failed to archive". Basically, our users set up their archive directories on a mapped Novell home directory that has a 1GB quota. When this directory fills up, and if users have some sort of auto-archive configuration enabled, GWCheck will pickup tons of these errors when running scheduled maintenance.
Here's what I did:
1. Found which user was experiencing the problems.
2. Increased the quota on the archive location.,
3. Allowed GroupWise to flush what it wanted to the
This enabled my GWCheck jobs to run again.
You may be able to find the problem user by looking at the .ckl files that are left behind, If you find one that is significantly larger than the others and is time- stamped about the same time as when your agent dies in protected memory, that's probably the one.
Every time this happened to me, I would have to follow TID
10077790 to manually clean up after the GWCheck job failed, so the scheduled maintenance would run again.
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.