groupwise help

Domain Directory

Directories Description<Domain> Domain directory structureWPCSIN MTA input queue directory0 Live interactive requests1 Other interactive requests2 High priority messages3 High priority status responses4 Normal priority messages5 Normal priority status responses6 Low priority messages7 Low priority status responses

WPTOOLS Supporting program directoryWPGATE GroupWise gateway directoryAPI<xx> API Gateway (NLM and OS/2)ASY<xxx> Async Gateway (NLM and OS/2)CCML Gateway for cc:Mail**FAXPRT<xx> Fax/Print GatewayMHS<xxx> MHS Gateway (NLM)NOTES Gateway for Notes**OVVM OV/VM GatewayPAGER Pager Gateway (NLM and OS/2)SMTP SMTP/MIME GatewaySNADS SNADS GatewayVINES Banyan VINES** GatewayX25 X.25 GatewayX400 X.400 Gateway

WPCSOUT MTA output queue directoryADS Administration Agent input queue directory0 ADA restart requests1 Directory synchronization requests2 Database updates3 Reserved; not currently used4 Reserved; not currently used5 Reserved; not currently used6 Reserved; not currently used7 Reserved; not currently used

CSS MTA input queue for administrative messages0 MTA restart requests1 Statistics requests2 Other non-priority administrative requests3 Reserved; not currently used4 Reserved; not currently used5 Reserved; not currently used6 Reserved; not currently used

http://www.novell.com/documentation/gw52/tb400003.html#c3fcff24

http://www.novell.com/documentation/gw52/tb400003.html#000024ce

http://www.novell.com/documentation/gw52/tb400003.html#000024cd

http://www.novell.com/documentation/gw52/tb400003.html#000024cc

http://www.novell.com/documentation/gw52/tb400003.html#000024cb

http://www.novell.com/documentation/gw52/tb400003.html#000024a5






http://www.novell.com/documentation/gw52/tb400003.html#000015d9

http://www.novell.com/documentation/gw52/tb400003.html#00000ffc

http://www.novell.com/documentation/gw52/tb400003.html#00000ffb

http://www.novell.com/documentation/gw52/tb400003.html#00000ffa

http://www.novell.com/documentation/gw52/tb400003.html#00000ff9




http://www.novell.com/documentation/gw52/tb400003.html#00000fff

http://www.novell.com/documentation/gw52/tb400003.html#00000fd3

7 Reserved; not currently usedMTAALM MTA address lookup module directoryPROBLEM Directory for undeliverable messages

wpdomain.db Domain database

wpdomain.dc Data dictionary for GroupWise 4.x domain databases

wphost.dc Data dictionary for GroupWise 4.x post office databases

gwdom.dc Data dictionary for GroupWise 5 domain databases

gwpo.dc Data dictionary for GroupWise 5 post office databases

msmonitr Monitor file for backup MTA

<Domain>

Within the GroupWise* system, a domain is hierarchically the highest level object. It organizes post offices into a logical grouping for addressing and routing purposes. Each user in the domain has an address that consists of the domain name, the user's post office name, and the user's GroupWise user ID (<domain>.<po>.<userID>). The explicit name is not displayed in the Address Book, but is stored in the domain database.

WPCSIN directory

The <domain>\WPCSIN directory is the MTA input queue in each domain. It contains eight priority subdirectories to handle different types of message traffic.

Incoming user messages are queued by priority for routing to recipients' post offices in the local domain.

Incoming status messages are queued by priority for routing to senders' post offices in the local domain.

Outgoing administrative messages are queued for replication to other domains. In a routing domain, messages pass through this directory on their way to the next domain.

The MTA polls the priority subdirectories as scheduled by the Scan Cycle and Scan High settings in NetWare* Administrator. When a new message arrives, the MTA routes it to the appropriate destination.

Historical Note: WP Office**, the predecessor of GroupWise, was originally designed by WordPerfect** Corporation (WPCorp**). The Message Transfer Agent (MTA) was originally named the Connection Server (CS). Hence, the directory name WPCSIN for the MTA input queue. Some naming conventions have been preserved for backward compatibility.

Priority 0 subdirectory for MTA

The <domain>\WPCSIN\0 subdirectory of the MTA input queue is for service requests that demand an immediate response from the MTA. For example:


http://www.novell.com/documentation/gw52/tb400003.html#0000160b

http://www.novell.com/documentation/gw52/tb400003.html#000015df

http://www.novell.com/documentation/gw52/tb400003.html#000015de

http://www.novell.com/documentation/gw52/tb400003.html#000015dd

http://www.novell.com/documentation/gw52/tb400003.html#000015dc


http://www.novell.com/documentation/gw52/tb400003.html#000024ca

http://www.novell.com/documentation/gw52/tb400003.html



NetWare Administrator places restart requests and queue reconfiguration requests here for the MTA and gateways.

Other domains' MTAs route Busy Search requests through here when users in other domains check schedules of users in the local domain.

You can increase throughput for the 0 subdirectory using the /FAST0 startup switch of the MTA. This causes the MTA to monitor and process the priority 0 and 1 subdirectories independently, rather than in sequence. This helps avoid bottlenecks in the processing of different types of service requests.


The <domain>\WPCSIN\1 subdirectory of the MTA input queue is for service requests of the next highest priority. For example:

NetWare Administrator places directory synchronization requests here for the MTA to relay to the ADA for processing.

NetWare Administrator places statistics requests here for the MTA to relay to the message logging module for processing.

Other domains' MTAs route GroupWise* Remote requests through here when Remote users do not connect to the post office where their Master Mailboxes are located.


The <domain>\WPCSIN\2 subdirectory of the MTA input queue is for high priority messages. For example:

Other domains' MTAs place incoming high priority user messages here. The local MTA then routes the messages to recipients' post offices.

Other domain's MTAs place incoming administrative messages here to replicate database updates in the local domain.

The ADA in the local domain places outgoing administrative messages here to replicate database updates to other domains.


The <domain>\WPCSIN\3 subdirectory of the MTA input queue is for high priority status messages routed back to senders in local post offices.

For example, other domains' MTAs place status responses to high priority user messages here. The local MTA then routes the status messages to senders' post offices, so senders' Mailboxes can be updated with current message status.


The <domain>\WPCSIN\4 subdirectory of the MTA input queue is for normal priority user messages routed to recipients in local post offices.





For example, other domains' MTAs place normal priority user messages here. The local MTA then routes the messages to recipients' post offices. Most messages in your GroupWise system pass through the priority 4 subdirectory.

You can increase throughput for the 4 subdirectory using the /FAST4 startup switch of the MTA. This causes the MTA to monitor and process the priority 2 and 3 subdirectories separately from the priority 4 through 7 subdirectories. This helps avoid bottlenecks in the processing of administrative messages and high priority user messages versus regular and low priority user messages.


The <domain>\WPCSIN\5 subdirectory of the MTA input queue is for normal priority status messages routed back to senders in local post offices.

For example, other domains' MTAs place status responses to normal priority user messages here. The local MTA then routes the status messages to senders' post offices, so senders' Mailboxes can be updated with current message status.


The <domain>\WPCSIN\6 subdirectory of the MTA input queue is for low priority user messages routed to recipients in local post offices.

For example, other domains' MTAs place low priority user messages here. The local MTA then routes the messages to recipients' post offices.


The <domain>\WPCSIN\7 subdirectory of the MTA input queue is for low priority status messages routed back to senders in local post offices.

For example, other domains' MTAs place status responses to low priority user messages here. The local MTA then routes the status messages to senders' post offices, so senders' Mailboxes can be updated with current message status.

WPTOOLS directory

The <domain>\WPTOOLS directory contains programs that support GroupWise administration.

Historical Note: WP Office, the predecessor of GroupWise, was originally designed by WordPerfect Corporation (WPCorp). Hence, the WP in WPTOOLS. Some naming conventions have been preserved for backward compatibility.

WPGATE directory






The <domain>\WPGATE directory contains a subdirectory for each GroupWise gateway you have installed in your GroupWise system. The subdirectory names shown in this diagram are the default names; you may see different subdirectory names in your own GroupWise system.

WPCSOUT directory

The <domain>\WPCSOUT directory is the MTA output queue in each domain. It contains subdirectories which function as input queues for the processes to which the MTA delivers messages.

Historical Note: WP Office, the predecessor of GroupWise, was originally designed by WordPerfect Corporation (WPCorp). The Message Transfer Agent (MTA) was originally named the Connection Server (CS). Hence, the directory name WPCSOUT for the MTA output queue. Some naming conventions have been preserved for backward compatibility.

ADS directory

The <domain>\WPCSOUT\ADS directory is the ADA input queue in each domain. It contains priority subdirectories where incoming administrative messages are queued for processing.

The ADA polls the priority subdirectories as scheduled by the Directory Scan Cycle setting in NetWare Administrator. When a new administrative message arrives, the ADA performs the requested action.

Historical Note: The Administration Agent (ADA) was originally named the Administration Server (ADS). Hence, the directory name ADS. Some naming conventions have been preserved for backward compatibility.

Priority 0 subdirectory for ADA

The <domain>\WPCSOUT\ADS\0 subdirectory of the ADA input queue is for service requests that demand an immediate response from the ADA.

For example, when you create or delete a post office in NetWare Administrator, a restart request is placed here. The domain ADA processes the request and then restarts.


The <domain>\WPCSOUT\ADS\1 subdirectory of the ADA input queue is for service requests of the next highest priority.


The <domain>\WPCSOUT\ADS\2 subdirectory is for high priority administrative messages. For example:

The MTA places administrative messages from other domains here. The administrative messages may instruct the ADA to add, modify, or delete users, post offices, or other objects






in the domain. The ADA then processes the messages and makes the specified updates. When you use the Synchronize utility in NetWare Administrator, a synchronization request

is placed here. The ADA then resends the specified administrative messages to produce the required database updates.

CSS directory

The <domain>\WPCSOUT\CSS directory is processed by a specialized MTA thread that responds to requests regarding its own configuration. It contains the eight standard priority subdirectories.

Historical Note: In an earlier version of GroupWise, the Message Transfer Agent (MTA) was called the Connection Server (CS) and this specialized subprocess was called the Connection Server Server (CSS). Some naming conventions have been preserved for backward compatibility.

Priority 0 subdirectory for CSS

The <domain>\WPCSOUT\CSS\0 subdirectory is for service requests that demand an immediate response from the MTA.

For example, when you restart the MTA in the MTA screen or in NetWare Administrator, a restart request is placed here. The MTA processes the request and restarts.


The <domain>\WPCSOUT\CSS\1 subdirectory is for service requests of the next highest priority.

For example, each time the statistics are updated in the MTA screen, a statistics request is placed here. The MTA then gathers the statistics and displays them on the MTA screen.


The <domain>\WPCSOUT\CSS\2 subdirectory is for non-priority requests.

MTAALM directory

The MTAALM directory is created when you use the /addresslookup startup switch, which enables the MTA to handle messages from external systems that arrive without the standard <domain>.<post office>.<user> GroupWise address.

PROBLEM directory

The PROBLEM directory is where the MTA places message files that cannot be delivered because they are damaged in some way. Message files in the PROBLEM directory must be handled by the GroupWise administrator. See Message Is Dropped in PROBLEM Directory for assistance.

http://www.novell.com/documentation/gw52/tbook2ms.html







WPDOMAIN.DB file

The WPDOMAIN.DB file is the domain database. It contains all administrative information for the domain.

In the primary domain, the WPDOMAIN.DB file contains all administrative information for your entire GroupWise system (all its domains, post offices, users, and so on). Because the WPDOMAIN.DB file in the primary domain is so crucial, you should back it up regularly and keep it secure. (You can re-create your entire GroupWise system from the primary domain WPDOMAIN.DB file; however, if the primary domain WPDOMAIN.DB file becomes unusable, you can no longer make administrative updates to your GroupWise system.)

In a secondary domain, the WPDOMAIN.DB file contains administrative information about that secondary domain only.

In GroupWise 5* domains, the data dictionary for the WPDOMAIN.DB file is the GWDOM.DC file. In GroupWise 4.x domains, the data dictionary is the WPDOMAIN.DC file. As a result, WPDOMAIN.DB files have different structures (schema) depending on whether they were created for 5 or 4.x domains.

Historical Note: WP Office, the predecessor of GroupWise, was originally designed by WordPerfect Corporation (WPCorp). Hence, the WP in WPDOMAIN.DB. Some naming conventions have been preserved for backward compatibility.

WPDOMAIN.DC file

The WPDOMAIN.DC file is the data dictionary for rebuilding GroupWise 4.x domain databases (WPDOMAIN.DB files) in secondary domains.

If the WPDOMAIN.DC file is missing from the primary domain, you cannot rebuild GroupWise 4.x secondary domains. The original WPDOMAIN.DC file is located in the DOMAIN directory of the GroupWise distribution media.

Historical Note: WP Office, the predecessor of GroupWise, was originally designed by WordPerfect Corporation (WPCorp). Hence, the WP in WPDOMAIN.DC. Some naming conventions have been preserved for backward compatibility.

WPHOST.DC file

The WPHOST.DC file is the data dictionary for rebuilding GroupWise 4.x post office databases (WPHOST.DB files).

If the WPHOST.DC file is missing from a domain, you cannot rebuild GroupWise 4.x post offices in that domain. The original WPHOST.DC file is located in the DOMAIN directory of the GroupWise distribution media.

Historical Note: WP Office, the predecessor of GroupWise, was originally designed by WordPerfect Corporation (WPCorp). Post offices were originally called hosts. Hence, the




name WPHOST.DC. Some naming conventions have been preserved for backward compatibility.

GWDOM.DC file

The GWDOM.DC file is the data dictionary for creating and rebuilding GroupWise 5 domain databases (WPDOMAIN.DB files) in secondary domains.

If the GWDOM.DC file is missing from the primary domain, you cannot create or rebuild GroupWise 5 secondary domains. The original GWDOM.DC file is located in the DOMAIN directory of the GroupWise distribution media.

Historical Note: WP Office, the predecessor of GroupWise, was originally designed by WordPerfect Corporation (WPCorp). Hence, the WP in WPDOMAIN.DB. Some naming conventions have been preserved for backward compatibility.

GWPO.DC file

The GWPO.DC file is the data dictionary for creating and rebuilding GroupWise 5 post office databases (WPHOST.DB files).

If the GWPO.DC file is missing from a domain, you cannot create or rebuild GroupWise 5 post offices in that domain.

Historical Note: WP Office, the predecessor of GroupWise, was originally designed by WordPerfect Corporation (WPCorp). Post offices were originally called hosts. Hence, the name WPHOST.DB. Some naming conventions have been preserved for backward compatibility.

MSMONITR file

The MSMONITR file exists only if you are using a primary and backup MTA. The primary MTA must be started with the /primary startup switch. The backup MTA must be started with the /backup startup switch.

When the primary MTA starts, it writes to the MSMONITR file and continues to write to this file at one half the interval specified by the /heartbeat setting (that is, twice as often as the interval specified by the /heartbeat setting). The backup MTA checks the MSMONITR file at the /heartbeat interval. If the primary MTA doesn't write to the MSMONITR file at the proper time, the backup MTA starts processing messages.

When the primary MTA restarts, it resumes writing to the MSMONITR file. At this point, the backup MTA stops processing messages and the primary MTA takes over again.

Post Office Directory

Directories Description<Post office> Post office directory structureWPCSIN MTA input queue directory

http://www.novell.com/documentation/gw52/tb400004.html#0000160a

http://www.novell.com/documentation/gw52/tb400004.html#1392d2ea




0 Live interactive requests1 Other interactive requests2 High priority messages3 High priority status responses4 Normal priority messages5 Normal priority status responses6 Low priority messages7 Low priority status responses

GWDMS Document Management Services directory

dmsh.db Shared Document Management Services database

LIB<0-FF> Library directoriesINDEX QuickFinder* index for libraryARCHIVE Archive directory for libraryDOCS Large document directory for library

OFMSG Message database directory

msg<0-24>.db As many as 25 message databases

ngwdfr.db Deferred message database

OFUSER User database directory

user<xxx>.db User databases

pu<xxxxx>.db Databases for replicated items

INDEX QuickFinder index for messagesOFFILES GroupWise* attachment storeFD<0-7F> Subdirectories for GroupWise 5* attachmentsFD<0-FF> Subdirectories for GroupWise 4.x attachments

OFWORK GroupWise working directoryOFDIRECT Remote direct connection directory.

WPCSOUT MTA output queue directoryOFS Post Office Agent input queue directory0 Live interactive requests1 Other interactive requests2 High priority messages3 High priority status responses4 Normal priority messages5 Normal priority status responses6 Low priority messages7 Low priority status responses

ADS Administration Agent input queue directory0 ADA restart requests1 Directory synchronization requests2 Database updates3 Reserved; not currently used4 Reserved; not currently used5 Reserved; not currently used6 Reserved; not currently used

http://www.novell.com/documentation/gw52/tb400004.html#000016da


http://www.novell.com/documentation/gw52/tb400004.html#000016e2

http://www.novell.com/documentation/gw52/tb400004.html#000016b6






http://www.novell.com/documentation/gw52/tb400004.html#000016af

http://www.novell.com/documentation/gw52/tb400004.html#000016ae





http://www.novell.com/documentation/gw52/tb400004.html#00001689






http://www.novell.com/documentation/gw52/tb400004.html#0000168c


http://www.novell.com/documentation/gw52/tb400004.html#0000165f

http://www.novell.com/documentation/gw52/tb400004.html#0000165e

http://www.novell.com/documentation/gw52/tb400004.html#0000165d












http://www.novell.com/documentation/gw52/tb400004.html#0000162e

http://www.novell.com/documentation/gw52/tb400004.html#0000162d


7 Reserved; not currently usedPROBLEM Directory for undeliverable messages

wphost.db Post office database

ngwguard.dc Data dictionary for databases

ngwguard.db Guardian database

<Post office>

Conceptually, a post office contains Mailboxes for a set of network users. The users on the post office send and receive messages through their Mailboxes.

Physically, a post office is a directory structure on a network file server. The directory structure contains subdirectories and databases that store messages and the information used to distribute the messages.

WPCSIN directory

The <post office>\WPCSIN directory is the MTA input queue in each post office. It contains eight priority subdirectories to handle different types of message traffic.

Outgoing user messages are queued by priority for routing to recipients in other post offices.

Outgoing status messages are queued by priority for routing back to senders' post offices. Outgoing Busy Search requests are queued for routing to other post offices so users'

schedules can be checked. GroupWise Remote requests are queued for routing to Remote users' Master Mailboxes.

The MTA polls these priority subdirectories as scheduled by the Scan Cycle and Scan High settings in NetWare* Administrator. When a new message arrives, the MTA routes it to the appropriate destination.

Historical Note: WP Office**, the predecessor of GroupWise, was originally designed by WordPerfect** Corporation (WPCorp**). The Message Transfer Agent (MTA) was originally named the Connection Server (CS). Hence, the directory name WPCSIN for the MTA input queue. Some naming conventions have been preserved for backward compatibility.


The <post office>\WPCSIN\0 subdirectory of the MTA input queue is for service requests that demand an immediate response from the MTA.

For example, the GroupWise client places Busy Search requests here. The MTA then routes the requests to the appropriate post offices, so users' schedules can be checked.




http://www.novell.com/documentation/gw52/tb400004.html#000024fa






The <post office>\WPCSIN\1 subdirectory of the MTA input queue is for service requests of the next highest priority. For example:

GroupWise Remote with a direct connection places Remote requests here for routing to Remote users' Master Mailboxes.

The Post Office Agent places outgoing status messages to Remote users here for routing to the async connection.



The <post office>\WPCSIN\2 subdirectory of the MTA input queue is for high priority user messages routed to recipients in other post offices, domains, or systems.

For example, the GroupWise client places high priority user messages here. The MTA then routes the messages to the appropriate destinations.



The <post office>\WPCSIN\3 subdirectory of the MTA input queue is for high priority status messages routed back to senders in other post offices, domains, or systems.

For example, the GroupWise client and local POA place status responses to high priority user messages here. The MTA then routes the status messages to the appropriate post offices, so senders' Mailboxes can be updated with current message status.


The <post office>\WPCSIN\4 subdirectory of the MTA input queue is for normal priority user messages routed to recipients in other post offices, domains, or systems.





For example, the GroupWise client places normal priority user messages here. The MTA then routes the messages to the appropriate destinations. Most messages in your GroupWise system pass through the priority 4 subdirectory.



The <post office>\WPCSIN\5 subdirectory of the MTA input queue is for normal priority status messages routed back to senders in other post offices, domains, or systems.

For example, the GroupWise client and local POA place status responses to normal priority user messages here. The MTA then routes the status messages to the appropriate post offices, so senders' Mailboxes can be updated with current message status.


The <post office>\WPCSIN\6 subdirectory of the MTA input queue is for low priority user messages routed to recipients in other post offices, domains, or systems.

For example, the GroupWise client places low priority user messages here. The MTA then routes the messages to the appropriate destinations.


The <post office>\WPCSIN\7 subdirectory of the MTA input queue is for low priority status messages routed back to senders in other post offices, domains, or systems.

For example, the GroupWise client and local POA place status responses to low priority user messages here. The MTA then routes the status messages to the appropriate post offices, so senders' Mailboxes can be updated with current message status.

GWDMS directory

The <post office>\GWDMS directory is the Document Management Services (DMS) directory in each post office. It contains the document libraries associated with the post office.

DMSH.DB file

The DMSH.DB file is a database shared by all libraries in the post office. It contains a list of all available libraries and lookup tables for each library.

LIB-<00-FF> directories







The LIB<0-FF> directories contain the libraries for the post office, with one library per directory. A post office can have as many as 255 libraries.

The DMSD<XX><NN>.DB file in each library holds system data for the library, such as library configuration information.

The DMDD<XX><NN>.DB file in each library holds document data for the library. Document data consist of all information in each document's properties pages.

The DMDL<XX><NN>.DB file in each library holds document logging data for the library. Document logging data records all activities performed on documents in the library.

The <NN> in the filenames represents the library number, matching the number on the library directory in which the database is found.

The <XX> in the filenames represents the partition number, which is generated by a hashing algorithm to guarantee uniqueness.

INDEX directory

The INDEX directory in a DMS library contains the QuickFinder index for the documents contained in the library.

ARCHIVE directory

The ARCHIVE directory in a DMS library contains an array of subdirectories for holding archived documents. The subdirectories are numbered sequentially. When the first archive subdirectory reaches its maximum allowable size, archived documents are stored in the next sequential directory, and so on.

DOCS directory

The DOCS directory in a DMS library contains an array of subdirectories for storing documents that exceed the 2048 KB size limit for storage in the document database (DMDD<XX><NN>.DB file) in the library.

OFMSG directory

The <post office>\OFMSG directory contains as many as 25 databases where messages are stored. It serves as centralized storage for all users in the post office. A message needs to be stored only once to be delivered to any number of users in the same post office.

Historical Note: An earlier version of GroupWise, designed by WordPerfect Corporation (WPCorp), was named WP Office. Hence, the OF in OFMSG. Some naming conventions have been preserved for backward compatibility.

MSG<0-24>.DB files






The databases in the OFMSG directory are named MSG<xx>.DB, where xx is a two-digit number from zero to 24. A hashing algorithm takes each users' GroupWise file ID (FID) to derive which database the user's outgoing mail is assigned to. The contents of the messages databases are encrypted so the text of message can only be read through GroupWise.

Multiple users are assigned to the same message database. You can use the Check GroupWise program to determine which database a specific user has been assigned to.

To increase database efficiency, messages, attachments, and recipient lists equal to or greater than 2 KB are stored outside the MSG<xx>.DB files in an array of subdirectories in the OFFILES directory. After the 2 KB limit is reached, only pointers are stored in the message databases.

NGWDFR.DB file

The NGWDFR.DB file holds deferred messages that users have specified for delivery at a later time.

Historical Note: Earlier versions of GroupWise handled deferred messages through the OFPEND directory in the post office.

OFUSER directory

The <post office>\OFUSER directory contains a separate database (mailbox) for each GroupWise user.

Historical Note: An earlier version of GroupWise, designed by WordPerfect Corporation (WPCorp), was named WP Office. Hence, the OF in OFUSER. Some naming conventions have been preserved for backward compatibility.

USER<XXX>.DB files

The databases in the OFUSER directory are named USER<xxx>.DB, where <xxx> is each user's GroupWise file ID (FID).

A user database is a user's Mailbox, which the GroupWise client displays as the Mailbox. In addition, a user database contains:

Some personal client program settings Personal appointments Personal groups Personal notes Rules

Personal client settings that remain the same regardless of what workstation a user logs into are stored in the user database. Personal client settings that are customized for a particular workstation are stored in the Windows** Registry.

PU<XXXXX>.DB files





The <post office>\OFUSER\PU<XXXXX>.DB files are databases for replicated items such as shared folders. These databases prevent conflicts between user names of shared items from users in other post offices and user names in the local post office.

INDEX directory

The INDEX directory in a post office contains the QuickFinder index for the messages stored in the post office.

OFFILES directory

The <post office>\OFFILES directory contains subdirectories for messages, attachments, and recipient lists that are equal to or greater than 2 KB in size. These larger messages, attachments, and recipient lists are stored outside the actual message databases in the OFMSG directory to increase database efficiency.

Historical Note: An earlier version of GroupWise, designed by WordPerfect Corporation (WPCorp), was named WP Office. Hence, the OF in OFFILES. Some naming conventions have been preserved for backward compatibility.

FD<0-7F> directories

The subdirectories in the OFFILES directory are named FD000 through FD07F (representing hexadecimal numbers). The message databases (MSG<xx>.DB files) contain pointers to messages, attachments, and recipient lists stored in the subdirectories of OFFILES.

FD<0-FF> directories

The array of FD<0-FF> subdirectories in OFFILES contain attachments that originated in GroupWise 4.x. These directories do not exist in a GroupWise system that was originally installed at the 5 level. After users have deleted all messages with attachments that originated in GroupWise 4.x, these subdirectories can be deleted from your GroupWise 5 system.

OFWORK directory

The <post office>\OFWORK directory is a working directory for the GroupWise Remote client.

Historical Note: An earlier version of GroupWise, designed by WordPerfect Corporation (WPCorp), was named WP Office. Hence, the OF in OFWORK. Some naming conventions have been preserved for backward compatibility.

OFDIRECT directory

The <post office>\OFWORK\OFDIRECT directory is used by the GroupWise client for direct connections in remote mode.







Historical Note: An earlier version of GroupWise, designed by WordPerfect Corporation (WPCorp), was named WP Office. Hence, the OF in OFDIRECT. Some naming conventions have been preserved for backward compatibility.

WPCSOUT directory

The <post office>\WPCSOUT directory is the MTA output queue in each post office. It contains subdirectories which function as input queues for the other agents to which the MTA delivers messages.

Historical Note: WP Office, the predecessor of GroupWise, was originally designed by WordPerfect Corporation (WPCorp). The Message Transfer Agent (MTA) was originally named the Connection Server (CS). Hence, the directory name WPCSOUT for the MTA output queue. Some naming conventions have been preserved for backward compatibility.

OFS directory

The <post office>\WPCSOUT\OFS directory is the POA input queue in each post office. It contains eight priority subdirectories to handle different types of message traffic.

Incoming user messages are queued by priority for delivery to recipients' Mailboxes in the local post office.

Incoming status messages are queued by priority for delivery to senders' Mailboxes in the local post office.

Incoming Busy Search requests are queued for the POA to check users' schedules in the local post office.

The POA scans these priority subdirectories regularly. When a new message arrives, the POA processes the messages and performs the required actions.

Priority 0 subdirectory for POA

The <post office>\WPCSOUT\OFS\0 subdirectory of the POA input queue is for service requests that demand an immediate response from the POA.

For example, the MTA places Busy Search requests here so the POA can check recipients' schedules and quickly return the schedule information to the sender.


The <post office>\WPCSOUT\OFS\1 subdirectory of the POA input queue is for service requests of the next highest priority.

For example, the MTA places requests from Remote users for items in their Master Mailboxes here. The POA then processes the messages and returns the requested items.







The <post office>\WPCSOUT\OFS\2 subdirectory of the POA input queue is for high priority user messages being delivered to recipients in the local post office.

For example, the MTA places high priority user messages here. The POA then updates the message databases and recipients' Mailboxes.


The <post office>\WPCSOUT\OFS\3 subdirectory of the POA input queue is for high priority status messages coming back to senders in the local post office.

For example, the MTA places status responses to high priority user messages here. The POA then updates the message databases and senders' Mailboxes with current message status.


The <post office>\WPCSOUT\OFS\4 subdirectory of the POA input queue is for normal priority user messages being delivered to recipients in the local post office.

For example, the MTA places normal priority user messages here. The POA then updates the message databases and recipients' Mailboxes. Most messages in your GroupWise system pass through the priority 4 subdirectory.


The <post office>\WPCSOUT\OFS\5 subdirectory of the POA input queue is for normal priority status messages coming back to senders in the local post office.

For example, the MTA places status responses to normal priority user messages here. The POA then updates the message databases and senders' Mailboxes with current message status.


The <post office>\WPCSOUT\OFS\6 subdirectory of the POA input queue is for low priority user messages being delivered to recipients in the local post office.

For example, the MTA places low priority messages here. The POA then updates the message databases and recipients' Mailboxes.


The <post office>\WPCSOUT\OFS\7 subdirectory of the POA input queue is for low priority status messages coming back to senders in the local post office.

For example, the MTA places status responses to low priority user messages here. The POA then updates the message databases and senders' Mailboxes with current message status.

ADS directory







The <post office>\WPCSOUT\ADS directory is the ADA input queue in each post office. It contains priority subdirectories where administrative messages are queued for processing.

Typically, one ADA runs in a domain and gets its input from the <domain>\WPCSOUT\ADS input queue. However, if the ADA is not able to perform the required update to a post office database, it submits the administrative message to the MTA, which then routes it to the ADA input queue in the post office. Later, the ADA again attempts to update the post office database. The administrative message remains in the ADA input queue in the post office until the update to the post office database is successful.

If a post office has its own ADA, the domain ADA always routes administrative messages down to the post office ADA. In this situation, updates to the post office database are always performed by the local ADA in the post office.

Historical Note: The Administration Agent (ADA) was originally named the Administration Server (ADS). Hence, the directory name ADS. Some naming conventions have been preserved for backward compatibility.


The <post office>\WPCSOUT\ADS\0 subdirectory of the ADA input queue is for service requests that demand an immediate response from the ADA.

For example, when you restart an ADA running in a post office, a restart request is placed here.


The <post office>\WPCSOUT\ADS\1 subdirectory of the ADA input queue is for service requests of the next highest priority.

For example, a directory synchronization request that could not be performed when the ADA received it in its domain input queue would be placed here in the post office for later processing.


The <post office>\WPCSOUT\ADS\2 subdirectory of the ADA input queue is for high priority administrative messages.

For example, a database update request that could not be performed when the ADA received it in its domain input queue would be placed here in the post office for later processing.

PROBLEM directory

The <post office>\WPCSOUT\PROBLEM directory is a holding area for damaged message files. Problem files are marked with an extension indicating which GroupWise agent placed each file in the PROBLEM directory.





You should check this directory periodically for problem files, resolve, the problem, then place the files back into the appropriate queue for continued processing. See Message Is Dropped in PROBLEM Directory for assistance.

WPHOST.DB file

The WPHOST.DB file is the post office database. It contains all administrative information for the post office. It also contains the Address Book for the post office.

In GroupWise 5 post offices, the data dictionary for the WPHOST.DB file is the GWPO.DC file. In GroupWise 4.x post offices, the data dictionary is the WPHOST.DC file. As a result, WPHOST.DB files have different structures (schema) depending on whether they were created for GroupWise 5 or 4.x post offices.

Historical Note: WP Office, the predecessor of GroupWise, was originally designed by WordPerfect Corporation (WPCorp). Post offices were originally called hosts. Hence, the name WPHOST.DB. Some naming conventions have been preserved for backward compatibility.

NGWGUARD.DC file

The NGWGUARD.DC file is the data dictionary for building the following databases in the post office:

NGWGUARD.DB (guardian database) DM*.DB (document management databases) MSG<0-24>.DB (message databases) USER<XXX>.DB (user databases) PU<XXXXX>.DB (databases for replicated items like shared folders)

NGWGUARD.DB file

The NGWGUARD.DB file is the guardian database. It consolidates in one location information needed in common by the following other databases in the post office:

NGWGUARD.DB (guardian database) DM*.DB (document management databases) MSG<0-24>.DB (message databases) USER<XXX>.DB (user databases) PU<XXXXX>.DB (databases for replicated items like shared folders)

This consolidation of information provides faster access and less duplication of information.

The guardian database also serves as a registry of other databases in the post office.

Message Transfer Agent Local Directory






Directories DescriptionMSLOCAL MTA local working directory

<mmddxx>.<nnn> MTA log files

MSHOLD MTA holding directoryDOMAINMS Processing directory for MTA<0-7> Priority subdirectories

<POSTx> Holding directories for post offices<0-7> Priority subdirectories

<GATEWAYx> Holding directories for gateways<0-7> Priority subdirectories

<DOMAINx> Holding directories for other domains<0-7> Priority subdirectories

MSIBOUND Input queue for TCP/IP connections<0-7> Priority subdirectories

MTACONV Work area for GroupWise 5* to 4.x conversionTRANSMOD Directory for third-party transport modules

MSLOCAL directory (MTA)

The MSLOCAL directory is the MTA local working directory. The /work startup switch of the MTA specifies the location of the MSLOCAL directory. It must be located on the hard disk of the server or workstation where the MTA runs so it is always accessible. Adequate disk space must be available to hold messages going to destinations that are temporarily closed.

Typical locations for the MSLOCAL directory include:

SYS:\SYSTEM on a Netware server C:\ on an Windows NT** workstation WPCS subdirectory in the domain (if the MTA runs on the same server or workstation

where the domain is located)

To move the MSLOCAL directory, stop the MTA, copy the MSLOCAL directory, along with all its subdirectories, to the new location. Then restart the MTA and specify the new location using the /work startup switch.

Historical Note: In earlier versions of GroupWise*, the Message Transfer Agent (MTA) was called the Message Server (MS). Hence, the MS in MSLOCAL. Some naming conventions have been preserved for backward compatibility.

<MMDDXX>.<NN> files

The MTA creates log files to inform you of its processing and any problems it encounters. By default, these log files are created in the MSLOCAL directory.




http://www.novell.com/documentation/gw52/tb400005.html#00001e9c














The first two digits of the filename represent the month; the next two digits represent the day of the month; the next two bytes indicate what program created the log (MS for MTA, IP for TCP/IP transport module, and FC for File Copy transport module). The three-digit extension is a sequence number for multiple log files created on the same day.

Several startup switches of the MTA control how the log file functions:

/log redirects the log file to a specified location /logdays designates how many days old log files remain on disk /logdiskoff turns off disk logging /loglevel sets how much information is logged (Verbose, Normal, Off) /logmax controls the maximum amount of disk space for all MTA log files

MTA startup switches override any log settings provided in NetWare* Administrator.

Historical Note: In earlier versions of GroupWise*, the Message Transfer Agent (MTA) was called the Message Server (MS). Hence, the MS indicator representing the MTA. Some naming conventions have been preserved for backward compatibility.

MSHOLD directory

The MSHOLD directory is a holding queue for messages addressed to domains, post offices, or gateways that are currently closed or that are serviced by transport modules.

A facility might be closed because its server or workstation is down or because the MTA is unable to communicate with it for any other reason. When a closed facility is again open, the MTA moves messages from the holding queue back into the normal message flow.

Transport modules provide file transfer capabilities using standard or custom protocols, rather than capabilities specific to GroupWise. For example, a transport module for the standard TCP/IP protocol is available. Custom transport modules could be written by third parties to meet specific needs.

Historical Note: In earlier versions of GroupWise, the Message Transfer Agent (MTA) was called the Message Server (MS). Hence, the MS in MSHOLD. Some naming conventions have been preserved for backward compatibility.

DOMAINMS directory

The DOMAINMS directory is used for internal processing by the MTA. It does not contain any files a GroupWise administrator needs to access.

Historical Note: In earlier versions of GroupWise, the Message Transfer Agent (MTA) was called the Message Server (MS). Hence, the MS in DOMAINMS. Some naming conventions have been preserved for backward compatibility.

<POSTx> directories




Each post office in the domain serviced by the MTA has a corresponding subdirectory in the MSHOLD directory. If a post office is closed, the MTA routes messages for that post office into its holding queue. When the post office is open, the MTA moves the held messages back into the regular message flow.

The name of the holding queue for each post office consists of the first three characters of the post office name, followed by four hashed characters to ensure uniqueness.

Priority 0-7 subdirectories (MTA)

The priority 0-7 subdirectories in each holding queue correspond to the priority 0-7 subdirectories located in each domain, post office, or gateway. See the directory structure information for each GroupWise location for more information about its priority 0-7 subdirectories.

<GATEWAYx> directories

Each gateway in the domain serviced by the MTA has a corresponding subdirectory in the MSHOLD directory. If a gateway is closed, the MTA routes messages that need to pass through that gateway into its holding queue. When the gateway is open, the MTA moves the held messages back into the regular message flow through the gateway. For more information, see the message flow diagrams for the gateway.

The name of the holding queue for each gateway consists of the first three characters of the gateway name, followed by four hashed characters to ensure uniqueness.

<DOMAINx> directories

Each domain in your GroupWise system to which the current domain has a direct link has a corresponding subdirectory in the MSHOLD directory. If a domain is closed, the MTA routes messages for that domain into its holding queue. When the domain is open, the MTA moves the held messages back into the regular message flow. For more information, see the message flow diagrams for delivery to a different domain.

The name of the holding queue for each domain consists of the first three characters of the domain name, followed by four hashed characters to ensure uniqueness.

MSIBOUND directory

The MSIBOUND directory is the MTA input queue for messages that arrive at the GroupWise system through a TCP/IP link or other transport module.

Historical Note: In earlier versions of GroupWise, the Message Transfer Agent (MTA) was called the Message Server (MS). Hence, the MS in MSIBOUND. Some naming conventions have been preserved for backward compatibility.

MTACONV directory






The MTACONV directory is the working directory where the MTA converts GroupWise 5 messages to 4.x format for transfer to a GroupWise 4.x system. After the conversion is finished, this directory should be empty.

TRANSMOD directory

The TRANSMOD directory is for use by third-party transport modules.

GroupWise Administrator Installation Directory

Directories Description<LAN or WAN> Enterprise network

<NetWare 4.1 server> Server where you install GroupWise* Administrator

PUBLIC NetWare PUBLIC directory

nw<xxxxxx>.exe New NetWare Administrator executables

nw<xxxxxx>.dll New NetWare Administrator DLLs

gw<xxxxxx>.exe GroupWise Administrator executables

gw<xxxxxx>.dll GroupWise Administrator DLLs

*.dll Other supporting DLLs

NLS Multiple language subdirectories

<Windows PC> Workstation where you run NetWare* Administrator

<NetWare 4.1 server> Location where you can set up GroupWise domains, post offices, agents

<NetWare 3.1 server> Location where you can set up GroupWise domains, post offices, agents

<NT workstation> Location where you can set up GroupWise domains, post offices, agents

<LAN or WAN>

The network where GroupWise* is installed can consist of various kinds of servers and workstations. All can be managed from GroupWise Administrator.

<NetWare 4.1 server>

GroupWise* must be administered from NetWare* Administrator. Therefore, at least one NetWare 4.1 server is required in a GroupWise installation. However, domains, post offices, agents, and client software may reside on other platforms (for example, NetWare 3.1 or Windows NT**).

PUBLIC directory

http://www.novell.com/documentation/gw52/tb400011.html#000041af

http://www.novell.com/documentation/gw52/tb400011.html#8e2bd6f2



http://www.novell.com/documentation/gw52/tb400011.html#000041ae







The \PUBLIC directory on the SYS volume of a NetWare* server is the standard location for public accessible system files.

The ADMIN\PUBLIC subdirectory of the GroupWise* distribution CD contains all GroupWise Administrator files that are installed into the PUBLIC directory when GroupWise is installed on a NetWare server.

The NWADMIN\PUBLIC subdirectory of the GroupWise distribution CD contains new versions NetWare Administrator files, required for use with GroupWise, that are installed into the PUBLIC directory when GroupWise is installed on the NetWare server. However, if the existing NetWare files are newer than those included with GroupWise, the existing files are not overwritten.

If the PUBLIC directory of your NetWare server already has files with the same names as files in the ADMIN\PUBLIC and NWADMIN\PUBLIC subdirectories of the GroupWise software distribution directory, they are updated during GroupWise installation if the GroupWise files are newer.

NW<xxxxxx>.EXE files

The NW<xxxxxx>.EXE files are the newer versions of any NetWare* Administrator executables that are required for running GroupWise* Administrator. The newer versions will ship with the next release of NetWare.

NW<xxxxxx>.DLL files

The NW<xxxxxx>.DLL files are the newer versions of any NetWare* Administrator DLLs that are required for running GroupWise* Administrator. The newer versions will ship with the next release of NetWare.

GW<xxxxxx>.EXE files

The GW<xxxxxx>.EXE files are the GroupWise* Administrator executables accessed through NetWare* Administrator. Whenever you work with GroupWise objects in NetWare Administrator, you are using GroupWise Administrator.

GW<xxxxxx>.DLL files

The GW<xxxxxx>.DLL files make up the GroupWise* Administrator program that becomes integrated with NetWare* Administrator during GroupWise installation. Whenever you work with GroupWise objects in NetWare Administrator, you are using GroupWise Administrator.

*.DLL files

*.DLL files are dynamically linked libraries of program code used by executable programs. Language-independent *.DLL files are typically located in the same directory with the executable programs they support. Language-specific *.DLL files are grouped into subdirectories by language.






NLS directory

The NLS directory contains NetWare Language Support files, organized in language-specific subdirectories. The NLS files let NetWare* Administrator be displayed in many different languages.

<Windows PC>

The Windows* 3.1 NetWare* Administrator, required for GroupWise* administration, can be run on a Windows* workstation running either Windows 95** or Windows 3.1.

The Windows workstation must have a drive mapped to the NetWare server where you installed NetWare Administrator and GroupWise Administrator.


GroupWise* Administrator can manage domains, post offices, and agents set up on NetWare* 4.1 servers.


GroupWise* Administrator can manage domains, post offices, and agents set up on NetWare* 3.1 servers.

<NT workstation>

GroupWise* Administrator can manage domains, post offices, and agents set up on NT** workstations.

Post Office Access Mode: Client/Server






Stage : Sender

The user sends a message to recipients in the same post office. The Access Mode setting for the post office is Client/Server. Therefore, the GroupWise* client communicates with the post office by way of TCP/IP.

Stage : Sender's GroupWise Client

The GroupWise client uses TCP/IP protocol to communicate the message to the Post Office Agent (POA).

Stage : POA in Local Post Office

The POA receives the message by way of TCP/IP from the GroupWise client and performs the following actions for the sender:

Adds the message to the message database (MSG<0-24>.DB file) assigned to the sender. Creates a pointer in the sender's user database (USER<xxx>.DB file) so the message

appears in the sender's Mailbox. Places attachments larger than 2 KB in the <post office>\OFFILES\FD<0-7F> subdirectory

assigned to the sender and creates pointers from the message to its attachments. (For database efficiency, messages and recipient lists larger than 2 KB are also handled as attachments.)

For more information about databases and directories in the post office, see Post Office Directory.

http://www.novell.com/documentation/gw52/tbook402.html






The POA also performs the following actions for the recipient:

Creates a pointer in each recipient's user database (USER<xxx>.DB file) to the message in the message database (MSG<0-24>.DB file) so the message appears in the recipient's Mailbox.

Updates the message in the message database (MSG<0-24>.DB file) with a "Delivered" status for each recipient.



The POA uses TCP/IP protocol to communicate to the GroupWise client that a new message has arrived.

Stage : Recipient's GroupWise Client

The Notify component of the recipient's GroupWise client notifies the recipient that a new message has arrived.

Stage : Recipient

Each recipient opens the message in the GroupWise client.


Each recipient's GroupWise client uses TCP/IP protocol to communicate the "Opened" status to the POA.


The POA receives the "Opened" status by way of TCP/IP from the GroupWise client and updates the message in the message database with the "Opened" status for each recipient who opens the message.


The POA uses TCP/IP protocol to communicate the "Opened" status to the sender's GroupWise client.

Stage : Sender











When the sender checks his or her Mailbox in the GroupWise client, the message displays a status of "Delivered" for each recipient (and possibly "Opened" as well if the recipient has opened the message).

Post Office Delivery Mode: Use App Thresholds (exceeded)

Stage : Sender

The user sends a message to recipients in the same post office. The delivery mode setting for the post office is to Use App Thresholds, and the threshold is exceeded.

Because the threshold is exceeded, the POA will write to the recipients' databases instead of the GroupWise* client to return control to the client user more quickly. However, the GroupWise client still writes to the sender's databases.


The GroupWise client performs the following actions for the sender:



assigned to the sender and creates pointers from the message to its attachments. (For database



efficiency, messages and recipient lists larger than 2 KB are also handled as attachments.) Creates a copy of the message in the appropriate priority 0-7 subdirectory of the POA input

queue.



The POA also performs the following actions for the recipient:

Creates a pointer in each recipient's user database (USER<xxx>.DB file) to the message in the message database (MSG<0-24>.DB file) so the message appears in the recipient's Mailbox.





Stage : Recipient



Each recipient's GroupWise client updates the message in the message database with an "Opened" status for that recipient.

Stage : Sender


Post Office Delivery Mode: Use App Thresholds (not exceeded)










Stage : Sender

The user sends a message to recipients in the same post office. The delivery mode for the post office is set to Use App Thresholds, but the threshold is not exceeded.


The GroupWise* client performs the following actions for the sender:






The GroupWise client performs the following actions for each recipient:

Updates each recipient's user database (USER<xxx>.DB file) so the message appears in each recipient's Mailbox and updates the notification information in the user database so the recipient can be notified of the message.










Stage : Recipient




Stage : Sender


Post Office Delivery Mode: Client Delivers Locally







Stage : Sender

The user sends a message to recipients in the same post office. The delivery mode for the post office is set to Client Delivers Locally. Therefore, the GroupWise* client updates the databases of all recipients.

When a user sends a message to a large number of recipients, the user may experience a pause while the GroupWise client updates the databases. If the pause is unacceptable, set the delivery mode for the post office to Use App Thresholds.


The GroupWise client performs the following actions for the sender:






The GroupWise client performs the following actions for each recipient:

Updates each recipient's user database (USER<xxx>.DB file) so the message appears in each recipient's Mailbox and updates the notification information in the user database so the recipient can be notified of the message.





Stage : Recipient














Stage : Sender


Access between Post Offices: TCP/IP Link


Stage : Sender

The user sends a message to recipients in a different post office in the same domain.

In this diagram, the delivery mode in the local post office is set to Use App Thresholds and the threshold is not exceeded. See Message Flow Diagrams for alternative message flows within the post office.






Creates a copy of the message in the appropriate priority 0-7 subdirectory of the sender's MTA input queue.


If a different delivery mode were in effect in the post office, some or all of these actions would be performed by the POA instead of the GroupWise client. See Message Flow Diagrams for alternative message flows within the post office.

Stage : MTA in Sender's Post Office

The MTA in the sender's post office routes the message to the input queue for the TCP/IP transport module in the post office.

An MTA, with its associated MSLOCAL directory structure, is required in each post office where TCP/IP links connect the post office with the domain. See MTA Local Directory.

Stage : TCP/IP Module in Sender's Post Office

The TCP/IP transport module in the sender's post office communicates the message to the TCP/IP transport module in the domain.

Stage : TCP/IP Module in Local Domain

The TCP/IP transport module in the domain places the message into the input queue for the MTA in the domain.












Stage : MTA in Local Domain

The MTA in the domain routes the message into the holding queue for the recipient's post office.


The TCP/IP transport module in the domain picks up the message and communicates it to the TCP/IP transport module in the recipient's post office.

Stage : TCP/IP Module in Recipient's Post Office

The TCP/IP transport module in the recipient's post office places the message into the input queue for the MTA in the recipient's post office.

Stage : MTA in Recipient's Post Office

The MTA in the recipient's post office transfers the message into the input queue for the POA in the recipient's post office.

An MTA, with its associated MSLOCAL directory structure, is required in each post office where TCP/IP links connect the post office to the domain. See MTA Local Directory.

Stage : POA in Recipient's Post Office

The POA polls its input queue regularly. When it detects a new message, the POA in the recipient's post office performs the following actions:

Adds the message to the message database (MSG<0-24>.DB file) corresponding to the one assigned to the sender.

Creates a pointer in the recipient's user database (USER<xxx>.DB file) so the message appears in the recipient's Mailbox and updates the notification information in the user database so the recipient can be notified of the message.

Places attachments larger than 2 KB in the <post office>\OFFILES\FD<0-7F> subdirectory corresponding to the one assigned to the sender and creates pointers from the message to its attachments. (For database efficiency, messages and recipient lists larger than 2 KB are also handled as attachments.)

Creates a "Delivered" status message in the appropriate priority 0-7 subdirectory of the recipient's MTA input queue.













Stage : Recipient



Each recipient's GroupWise client creates an "Opened" status message in the appropriate priority 0-7 subdirectory of the recipient's MTA input queue.

Stage : MTA in Recipient's Post Office

The MTA in the recipient's post office routes the status response to the input queue for the TCP/IP transport module in the post office.

An MTA, with its associated MSLOCAL directory structure, is required in each post office where TCP/IP links connect the post office with the domain. See MTA Local Directory.

Stage : TCP/IP Module in Recipient's Post Office

The TCP/IP transport module in the recipient's post office communicates the message to the TCP/IP transport module in the domain.


The TCP/IP transport module in the domain places the status response into the input queue for the MTA in the domain.


The MTA in the domain routes the status response into the holding queue for the sender's post office.


The TCP/IP transport module in the domain picks up the status response and communicates it to the TCP/IP transport module in the sender's post office.

Stage : TCP/IP Module in Sender's Post Office

The TCP/IP transport module in the sender's post office places the status response into the input queue for the MTA in the sender's post office.










Stage : MTA in Sender's Post Office

The MTA in the sender's post office transfers the status response into the input queue for the POA in the sender's post office.

An MTA, with its associated MSLOCAL directory structure, is required in each post office where TCP/IP links connect the post office to the domain. See MTA Local Directory.

Stage : POA in Sender's Post Office

The POA in the sender's post office updates the sender's message database (MSG<0-24>.DB file) with the "Delivered" status information (and possibly "Opened" as well if the recipient has opened the message).

Stage : Sender


Access between Post Offices: Direct





Stage : Sender

















The MTA polls its input queue as specified by the Scan Cycle setting in Agent Settings in NetWare* Administrator. When it detects a new message, the MTA picks up the message from the sender's post office and transfers it to its output queue in the recipient's post office. The MTA output queue is the input queue for the POA in the recipient's post office.










Stage : Recipient














The MTA polls its input queue as specified by the Scan Cycle setting in NetWare Administrator. When it detects a status response, the MTA picks it up from the recipient's post office and transfers it to its output queue in the sender's post office. The MTA output queue is the input queue for the POA in the sender's post office.



Stage : Sender


Access between Post Offices Blocked: Delivery Delayed




Stage : Sender

















The MTA polls its input queue as specified by Scan Cycle in Agent Settings in NetWare* Administrator. When it detects a new message, the MTA picks up the message in the sender's post office. However, because the recipient's post office is blocked, the MTA cannot complete the delivery. Therefore, the MTA stores the message in its holding queue for the recipient's post office. See MTA Local Directory.

When the recipient's post office is open again, the MTA transfers the delayed message from the post office holding queue to the MTA output queue in the recipient's post office. The MTA output queue is the input queue for the POA in the recipient's post office.










Stage : Recipient















The MTA polls its input queue as specified by Scan Cycle in Agent Settings in NetWare* Administrator.

When it detects a new status response, the MTA picks it up in the recipient's post office. Because the sender's post office is open, the MTA can immediately transfer the status response to the MTA output queue in the sender's post office.

The MTA output queue is the input queue for the POA in the sender's post office.



Stage : Sender





groupwise help

Documents