Cadet 1st Class
Cadet 1st Class
1447 views

GW8 POA Repairs Database every time it starts

I have Groupwise 8 (fully patched) running on a Netware 6.5 server (fully patched). Every time the POA restarts at midnight, it checks the Guardian database. Then at 26 seconds past midnight, it gives me a data base repaired message.

When I attempt to do an analyze/fix using the standalone GWCHECK, I get an 8201 on Guardian. Here is the exact error:

STRUCTURAL VERIFICATION of system databases
STRUCTURAL VERIFICATION of database ngwguard.db
- Error checking file Guardian, IO_ACCESS_DENIED (0x8201)
- Guardian was successfully recovered from backup

This process takes 1 1/2 hours to recover the database. I abort the process as soon as I get the 8201, but it takes 1 ½ hours to stop.

I do know some things which are incorrect. My ngwguard.fbk is dated some time in 2004. My ngwguard.rfl is 24 meg. And my GUARDBAK ngwguard.fbk is also 2004. I know these things are wrong. When I investigated the 8201 error, it indicated that it could be because the owner does not exist. Well, that was true. The owner of some of my files was .[supervisor], this system is very old & has been updated thru many versions of netware & groupwise. I changed everything to .admin from .[supervisor] across the entire mail volume. I was hoping that this would solve the problem, but it does not. Something is still putting out messages owned by .[supervisor]. I have recently upgraded all of my nlm's to be owned by .admin as well as the groupwise software directory & the public directory. And yet, the new messages are arriving owned by .[supervisor].

I am not sure what the sequence of events is in GWCHECK. So, I am not sure where the analyze/fix is getting an error or what is causing the error. I see no other errors other than the one above.

I have several other NGWGUARD files which I am not sure of their usage. Following is a copy of the directory.


11/22/2003 03:45 PM <DIR> .
11/22/2003 03:45 PM <DIR> ..
04/13/2013 10:57 PM 1,798 0413CHK.LOG
04/14/2013 06:55 AM 1,020 0414CHK.LOG
04/15/2013 03:43 PM 766 0415chk.log
12/17/2008 02:46 AM 6,108 1130CHK.LOG
04/13/2013 03:02 AM 71,680 dmdd0108.db
04/13/2013 03:02 AM 38,912 dmdd0208.db
04/13/2013 03:02 AM 38,912 dmdd0308.db
04/13/2013 03:02 AM 77,824 dmdd0408.db
04/13/2013 03:02 AM 43,008 dmdd0508.db
04/13/2013 03:02 AM 45,056 dmdd0608.db
04/13/2013 03:02 AM 32,768 dmdl0108.db
04/13/2013 03:02 AM 32,768 dmdl0208.db
04/13/2013 03:02 AM 32,768 dmdl0308.db
04/13/2013 03:02 AM 36,864 dmdl0408.db
04/13/2013 03:02 AM 32,768 dmdl0508.db
04/13/2013 03:02 AM 38,912 dmdl0608.db
04/13/2013 09:58 PM 28,672 DMSD0008.DB
04/13/2013 03:00 AM 225,280 guard.DB
08/20/2005 07:18 PM 18,001 GWPO.BAK
03/23/2009 10:30 AM 19,122 gwpo.dc
03/21/1998 12:36 PM 15,828 Gwpo.dco
04/15/2013 04:03 PM 90,112 ngwcheck.db
01/31/2012 02:19 AM 86,016 NGWCHECK.old
03/08/2008 09:03 PM 113,209 NGWGUARD.BAK
04/15/2013 03:54 PM 225,280 ngwguard.db
04/15/2013 03:53 PM 225,280 NGWGUARD.DBA
04/04/2009 02:30 AM 102,648 ngwguard.dc
03/15/1998 06:22 AM 68,126 Ngwguard.dco
03/13/2004 09:00 PM 159,744 NGWGUARD.fbk
04/15/2013 03:53 PM 225,280 NGWGUARD.FBN
01/01/2004 10:00 AM 159,744 NGWGUARD.FBO
01/31/2012 07:45 AM 225,280 NGWGUARD.new
04/15/2013 03:53 PM 25,661,085 NGWGUARD.RFL
04/15/2013 03:53 PM 290,816 wphost.db
08/18/2004 10:23 PM 231,424 wphost.dbold
03/08/2008 09:03 PM 10,942 wphost.dc

As you can see. I have a .FBN & a .FBO file. The .FBN seems to be used during the GWCHECK.

Following is a copy of the flag for this volume:


Files DOS Attr NetWare Attr Status Owner Mode
-------------------------------------------------------------------------------
0413CHK.LOG [Rw---A] [-----------------] .Admin.tci N/A
0414CHK.LOG [Rw---A] [-----------------] .Admin.tci N/A
0415CHK.LOG [Rw---A] [-----------------] .Maureen.tci N/A
1130CHK.LOG [Rw----] [--P--Di----Dc----] .Admin.tci N/A
DMDD0108.DB [Rw---A] [--P--Di----Dc--Ds] .TCI_COMM.tci N/A
DMDD0208.DB [Rw---A] [--P--Di----Dc--Ds] .TCI_COMM.tci N/A
DMDD0308.DB [Rw---A] [--P--Di----Dc--Ds] .TCI_COMM.tci N/A
DMDD0408.DB [Rw---A] [--P--Di----Dc--Ds] .TCI_COMM.tci N/A
DMDD0508.DB [Rw---A] [--P--Di----Dc--Ds] .TCI_COMM.tci N/A
DMDD0608.DB [Rw---A] [--P--Di----Dc--Ds] .TCI_COMM.tci N/A
DMDL0108.DB [Rw---A] [--P--Di----Dc--Ds] .TCI_COMM.tci N/A
DMDL0208.DB [Rw---A] [--P--Di----Dc--Ds] .TCI_COMM.tci N/A
DMDL0308.DB [Rw---A] [--P--Di----Dc--Ds] .TCI_COMM.tci N/A
DMDL0408.DB [Rw---A] [--P--Di----Dc--Ds] .TCI_COMM.tci N/A
DMDL0508.DB [Rw---A] [--P--Di----Dc--Ds] .TCI_COMM.tci N/A
DMDL0608.DB [Rw---A] [--P--Di----Dc--Ds] .TCI_COMM.tci N/A
DMSD0008.DB [Rw---A] [--P--Di----Dc--Ds] .TCI_COMM.tci N/A
GUARD.DB [Rw---A] [--P--Di----Dc----] .Admin.tci N/A
GWPO.BAK [Rw----] [--P--Di----Dc----] .Admin.tci N/A
GWPO.DC [Rw----] [-----------------] .Admin.tci N/A
GWPO.DCO [Ro----] [--P--Di--RiDc----] .Admin.tci N/A
NGWCHECK.DB [Rw---A] [-----------------] .Admin.tci N/A
NGWCHECK.OLD [Rw---A] [--P--Di----Dc--Ds] .Admin.tci N/A
NGWGUARD.BAK [Rw----] [-----------Dc----] .Admin.tci N/A
NGWGUARD.DB [Rw---A] [-----------------] .Admin.tci N/A
NGWGUARD.DBA [Rw---A] [--P--Di----Dc----] .Admin.tci N/A
NGWGUARD.DC [Rw----] [-----------------] .Admin.tci N/A
NGWGUARD.DCO [Ro----] [--P--Di--RiDc----] .Admin.tci N/A
NGWGUARD.FBK [Rw----] [-----------------] .Admin.tci N/A
NGWGUARD.FBN [Rw---A] [-----------------] .Admin.tci N/A
NGWGUARD.FBO [Rw----] [--P--Di----Dc----] .Admin.tci N/A
NGWGUARD.NEW [Rw----] [-----------------] .Admin.tci N/A
NGWGUARD.RFL [Rw---A] [--P--Di----Dc----] .Admin.tci N/A
WPHOST.DB [Rw---A] [-----------------] .Admin.tci N/A
WPHOST~1.DBO [Rw----] [--P--Di----Dc----] .Admin.tci N/A
WPHOST.DC [Rw----] [-----------------] .Admin.tci N/A

I don’t know if the ownership by TCI_COMM.tci (server name) is causing the problem or not. So, I changed the ownership to .admin.tci & I ran another GWCHECK. Still an 8201 error as above. So, it did not help. The files owned by Maureen.tci are a result of the GWCHECK.

Any help would be greatly appreciated. I am attempting to solve these problems in anticipation of moving to a windows server.
Labels (2)
0 Likes
9 Replies
Micro Focus Expert
Micro Focus Expert

1) The file could be open by a Virus Scan utility. Virus utilities should not scan the Post Office directory, since the files are encrypted.

2) To check who has the file open, go to the server console, then Type Monitor | File open/lock activity, then browse to the NGWGUARD.DB file. Once the connection number is determined, you can go to Monitor | Connections, to see who has the connection, or to clear the connection. If it says connection 0, this is a server connection, and may require restarting the server to clear..

Cheers,
Laura Buckley

Views/comments expressed here are entirely my own.
If you find this post helpful, please show your appreciation and click on "Like" below...
0 Likes
Cadet 1st Class
Cadet 1st Class

I had checked that. But to make sure, I disabled my virus protection. NGWGUARD.DB was not open. I ran an analyze/fix of a user & got the 8201. So, it's not the virus protection. I will research it to make sure that my mail volume is not being scanned.

The interesting thing is that the ngwguard.DB appears to be good. I have no problems starting the POA, other than it recovers the DB each time i.e., there are no abends. It just seems that for whatever reason, either it cannot purge/write/recreate the NGWGUARD.FBK file or the NGWGUARD.RFL. The NGWGUARD.DB is being updated ( the date is always midnight of the start of day). I have to assume the problem is with the NGWGUARD.FBK file or the NGWGUARD.RFL file. When I check the attributes of the NGWGUARD.RFL, it shows 'Delete Inhibited' and 'Purge Immediate'. This does not seem correct. I will disable both of these attributes to see what happens, but I do need to wait 1 1/2 hours for the previous analyze/fix to complete. I'm hoping this is the problem. I will update later.
0 Likes
Cadet 1st Class
Cadet 1st Class

I reset the Purge Immediate & Delete Inhibit attributes and 8201 is still occurring. I also checked the GUARDBAK copy of the .FBK file, they do not have these attributes set.

After the current 1 1/2 hour test, I will see if renaming the NGWCHECK.DB file fixes the problem.
0 Likes
Micro Focus Expert
Micro Focus Expert

Keep us posted.

Cheers,
Laura Buckley

Views/comments expressed here are entirely my own.
If you find this post helpful, please show your appreciation and click on "Like" below...
0 Likes
Cadet 1st Class
Cadet 1st Class

Renamed the NGWCHECK.DB file and restarted MTA, POA & GWIA. Still the 8201 error.

Next I am going to try to rename the NGWGUARD.FBK & move the GUARDBAK NGWGUARD.FBK into its place. But again, must wait 1 1/2 hours.
0 Likes
Micro Focus Expert
Micro Focus Expert

Have you used "monitor" to see if anything else is holding the file open?

Cheers,
Laura Buckley

Views/comments expressed here are entirely my own.
If you find this post helpful, please show your appreciation and click on "Like" below...
0 Likes
Cadet 1st Class
Cadet 1st Class

Yes. I am looking at 4 files only. This may be a mistake. But it is all that I can glean thru TIDS, Forums, White papers etc.
NGWGUARD.DB - was open by no one. Now it is open by connection 0 which is the server & it isn't locked. But when I did your test, no one had it open. My Virus protecion is set not to scan DB files.
NGWGUARD.FBK - not opened.
NGWGUARD.RFL - not opened
NGWCHECK.DB - not opened

What I really need to know is what file is GWCHECK complaining about. It just says Guardian. This isn't helpful. I interpret Guardian to be NGWGUARD.DB. This file is being updated every day. My gut says this is the .FBK which is a problem or the backup FBK on GUARDBAK. This is the file which is not being updated. The FBK should have the DB at its last known 'safe' state. I would assume that this means that it should have a date of this morning at midnight. Other mail systems have both the .DB and .FBK set to midnight of the same day. The RFL is being updated on my system. I can't find any documentation on what the GWCHECK process is. The error occurs immediately. If I were doing the structural analyze/fix, I would try to create a new FBK file (this may be my FBN file as it is updated as GWCHECK is processing). I would then read the RFL file and update the new FBK file. At the end of this process, I should have a new FBK file which would be copied into a new DB file making both of these files in sync. My RFL should be purged/reduced/recreated as all of the messages have been incorporated into the FBK file. I don't think it is my RFL file because the error happens immediately. I would think that the 8201 would not happen immediately if the problem were the RFL file. It would happen at the end of the process when it was trying to empty the file. I do have an FBO file. This file is dated 1/1/2004. Maybe gwcheck it trying to purge this file & is getting the 8201 & when it can't, it creates the FBN file. I will try to rename this file & then rerun the gwcheck analyze/fix for my po. This file happens to have delete inhibit & purge immediate attributes set. I have cleared them will try again. Will update after the result.
0 Likes
Cadet 1st Class
Cadet 1st Class

That was it!!!! The FBO file (NGWGUARD.FBO) was set as delete inhibit & purge immediate. I removed these attributes & the structure analyze/fix took 3 seconds & my RFL file is 1K & my FBK file is set to today as of the last analyze/fix.

I always fix problems by talking to someone & Laura, you provided the perfect person that I could explain my problem. This allowed me to logically follow the path & come up with the solution. Thanks.
0 Likes
Micro Focus Expert
Micro Focus Expert

As far as I'm aware, no GroupWise file should have the Delete Inhibit attribute as that prevents the system from working with the file.

Cheers,
Laura Buckley

Views/comments expressed here are entirely my own.
If you find this post helpful, please show your appreciation and click on "Like" below...
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.