POA Abends on Startup - 'Listening for Inbound Connections'

The Post Office Agent will not load or will abend on startup, specifically at the point when the POA screen reads: 'Listening for Inbound Connections'.

The POA will load correctly on a test server, but will not load when connected to its parent MTA and/or to its user and message database structure.

If the POA loads fine against a test system, but not against its own system, then it is something within the environment causing the problem. It is always best to remove pieces of the environment until the POA will load successfully.

1. Load the POA in a separate directory structure where it does not have access to its user and message databases. If it loads then it is a problem with those components.

2. Load the POA after removing the link to the MTA to see if the communication between the two is causing it to fail. If so, then validate the domain database and possibly rebuild the Domain and Post Office via ConsoleOne.

The problem in this instance was a user database that had grown to 4 GB in size. Look in both places 'ofuser' and'ofmsg' to find the problem database. Rename or remove the database and then drop it from the guardian as per TID-10062697 entitled 'How to Drop a User or Message or Other Database from the Guard'.

Log in as the user or send the user an email while the POA is loaded and the database will be recreated. If the bad database is a Message Database then the procedure is the same, except that the POA will automatically recreate the database once it receives a new message.

Restoring a User or Message Database from backup where the database is less than 2 GB in size will also work; however, this will lose the mail that was received from the recreate or restore date. Novell does not support data retrieval from databases that have reached the 2 GB limit, though administrators can try a couple of things to 'save' the database.

Usually databases that reach this size have done so because of looping mail or system-mail sent to specific users. Try the 'SUBJECTLIST' and 'SUBJECTPURGE' switches as per KB 7003293 titled 'GWCheck Special Options Available in 6.0.1 and Later Code'. If these steps do not work, Novell Support and even Novell Development most likely cannot save the databases.

At 2 GB in size, FLAIM databases are at their limit of functionality. This should never happen under normal circumstances with a user database as it contains only pointers and no actual attachments. 2 GB equates to over one million message pointers, contacts and appointments. This scenario is highly unlikely unless a message loop or other corruptive event has occurred. Message databases in GroupWise 6.5 and earlier would occasionally hit this limit when no email retention policy was in place so Novell development changed GroupWise such that it creates now 200+ message databases rather than the traditional 25.

In the observed issues surrounding the writing of this TID, the databases had reached 4 GB in size. A 4GB database demands special considerations in GroupWise, NetWare and all 32-bit applications/operating systems. Thus problems occurring from a 'working file' of that size might be partially unavoidable. Currently the abend phenonemon is under investigation by Novell development.