Global System Services Corporation (GSS) - The leading provider of email and messaging, directory services, and groupware consulting and professional services

Jan,

Since you have NFT errors from varying sources, it sounds like you may have some underlying system design or network issues. Note that once an actual corruption has occurred, every cc:Mail Router, client, and gateway may report and "NFT error reading." This is because there is a bad CRC in the database, perhaps it's just the CRC, perhaps there is a real corruption.

If there is a real corruption, it may be trivial or very serious depending on where in the post office the corruption is. With some minor corruptions, you could run CHKSTAT with the "NFT/C" parameter and bring the PO back on line immediately. This is never recommended. You wouldn't know the nature of the problem unless you ran ANALYZE. Of course, most minor problems are corrected by CHKSTAT with the "DIAGNOSTICS/R" parameter. Remember that CHKSTAT with the "NFT/C" parameter does NOT fix anything -- it merely recalculates the CRCs whether there is a real corruption or not.

If you see many entries for "NFT Error reading" from the same file and offset (CLANDATA sector 0, for example), then you already have a corruption or at least a bad CRC. In the log, go back before these redundant errors began. Find the last error before the stream of "NFT Error reading" entries. Often, you'll find an error writing or verifying that kicks off the stream of NFT Errors reading.

To analyze NFT errors more carefully, determine the location of the machines producing the errors on a detailed network diagram. Check if they are on the same segment, sharing a common hub, routed through a common router, crossing a common backbone, etc.. For the cc:Mail Router that keeps appearing in the log, check if it's coming in over your WAN. This is a common system design error: mapping network drives over a WAN and using Type I Router connections rather than Type II connections.

You say that you don't have a traffic problem because users are on a 20-user 16Mbps Token Ring. I want to ask, where is the server and what is the route to it in your physical LAN? Is the server across a WAN from the users? Is it on the other side of an overloaded Router? Is traffic from your WAN traversing the seemingly quiet 20-user Ring? Perhaps there are 700 SAP broadcasts from connected networks every 60 seconds. The only way you can know is by measuring and monitoring traffic and network errors on each segment or Ring from the problem users to the server.

I am also wondering what version of cc:Mail for Windows you have. If you are getting significant numbers of users reporting GPFs, you need to look for a pattern in the error: a certian time of day; a specific server; a specific area of the network.

I have found that there are sometimes serious traffic problems or extremely high server utilization when large numbers of users are reporting NFT and Mail Engine errors. I see widespread GPFs almost never, at least not with recent versions of the cc:Mail for Windows. Do you have a standard workstation configuration? What is it? The GPFs may be unrelated to the NFT errors in which case we should be looking at the Windows workstations. How are the Windows resources (GDI, USER, and system memory)?

I commonly find a series of related but not obvious system design problems where there is a laundry list of errors. In your case the list is NFT errors, cc:Mail for Windows GPFs, and actual post office corruptions. I think you should first do more to isolate the problems you are seeing and second review your system design and deployment of cc:Mail.