Manually Unloading GWAVA 4 Modules (NetWare)

  • 7019665
  • 30-Jun-2008
  • 07-Aug-2017

Environment

GWAVA 4 (all builds) on Netware

Situation

GWAVA module(s) not unloading after GWAVADN and KILLGWAVA

Resolution


Before reading this document, you should have a good knowledge of how address spaces work in GWAVA 4.  This brief article will explain which modules are loaded into which address spaces, which will help you determine which address space may need to be unloaded (if any):  https://support.microfocus.com/kb/doc.php?id=7019663


The steps described in this article should only be taken after the normal methods of unloading GWAVA has failed.  Please read first:  https://support.microfocus.com/kb/doc.php?id=7019652.  Also, keep in mind that it can take up to 5 minutes or more for all GWAVA modules to release, so be patient before continuing to the next steps.

If the normal means of unloading GWAVA has failed, here are the steps you'll want to take to try to force the offending GWAVA modules to unload:

1)  Determine which GWAVA module is hung.  If you've just tried to run GWAVADN, the last module that is listed is the one that is trying to be unloaded.

2)  Determine which address space the offending module is contained in.  You can do this by typing 'module', then the name of the GWAVA module in the NetWare System Console.  For instance, 'module gwavaman.nlm'  will show you if gwavaman.nlm is loaded and give you information on which address space it's loaded in.  Another easy way to determine which address space to kill is to refer to the above mentioned article on GWAVA 4 address spaces:  https://support.microfocus.com/kb/doc.php?id=7019663

3)  Now that you know which address space is having the problem, we can kill it by typing this in your System Console:

       unload kill address space=nameofaddress

This should kill the whole address space and all modules contained therein.

4)  Now that the offending process is gone, run GWAVADN again to continue to unload any other modules that may still be running.  If another module won't unload after giving it sufficient time, then continue with Step 1 again.

***NOTE:  Although killing an address space may be necessary at times, there are risks associated with unloading GWAVA abruptly like this.  Some of the possible risks include:  corrupt configuration database (gwavaman.db), corrupt Quarantine databases (qms_data.db, etc.), loss of recently process spam and ham for training.  While corrupt dbs can usually be restored from backup or rebuilt, this isn't always possible and data can be lost.  Keep these things in mind before killing an address space.  More often than not GWAVA will eventually unload of it's own accord without these measures.

See also these related articles:
GWAVADN failing - https://support.microfocus.com/kb/doc.php?id=7019652

NetWare address spaces - https://support.microfocus.com/kb/doc.php?id=7019663

NetWare commands - https://support.microfocus.com/kb/doc.php?id=7019651

 

Additional Information

This article was originally published in the GWAVA knowledgebase as article ID 307.