Wpcsin 0 1 2 3 4 5 6 7 Wptools Wpgate: Domain Directory Directories Description

Domain Directory
Directories Description
<Domain> Domain directory structure
WPCSIN MTA input queue directory
0 Live interactive requests
1 Other interactive requests
2 High priority messages
3 High priority status responses
4 Normal priority messages
5 Normal priority status responses
6 Low priority messages
7 Low priority status responses
WPTOOLS Supporting program directory
WPGATE GroupWise gateway directory
API<xx> API Gateway (NLM and OS/2)
ASY<xxx> Async Gateway (NLM and OS/2)
CCML Gateway for cc:Mail**
FAXPRT<xx> Fax/Print Gateway
MHS<xxx> MHS Gateway (NLM)
NOTES Gateway for Notes**
OVVM OV/VM Gateway
PAGER Pager Gateway (NLM and OS/2)
SMTP SMTP/MIME Gateway
SNADS SNADS Gateway
VINES Banyan VINES** Gateway
X25 X.25 Gateway
X400 X.400 Gateway
WPCSOUT MTA output queue directory
ADS Administration Agent input queue directory
0 ADA restart requests
1 Directory synchronization requests
2 Database updates
3 Reserved; not currently used
CSS MTA input queue for administrative messages
0 MTA restart requests
1 Statistics requests
2 Other non-priority administrative requests
MTAALM MTA address lookup module directory
PROBLEM 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:
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.
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
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
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.

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.
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.

WordPerfect Corporation (WPCorp). Hence, the WP in WPDOMAIN.DB. Some naming
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.

WordPerfect Corporation (WPCorp). Hence, the WP in WPDOMAIN.DC. Some naming
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.

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.

WordPerfect Corporation (WPCorp). Hence, the WP in WPDOMAIN.DB. Some naming
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.

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
<Post office> Post office directory structure
WPCSIN MTA input queue directory
GWDMS Document Management Services directory
dmsh.db Shared Document Management Services database
LIB<0-FF> Library directories
INDEX QuickFinder* index for library
ARCHIVE Archive directory for library
DOCS 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 messages
OFFILES GroupWise* attachment store
FD<0-7F> Subdirectories for GroupWise 5* attachments
FD<0-FF> Subdirectories for GroupWise 4.x attachments
OFWORK GroupWise working directory
OFDIRECT Remote direct connection directory.
WPCSOUT MTA output queue directory
OFS Post Office Agent input queue directory
ADS Administration Agent input queue directory
0 ADA restart requests
1 Directory synchronization requests
2 Database updates
PROBLEM 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.
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.

(WPCorp), was named WP Office. Hence, the OF in OFUSER. Some naming conventions
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.

(WPCorp), was named WP Office. Hence, the OF in OFFILES. Some naming conventions
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.

(WPCorp), was named WP Office. Hence, the OF in OFWORK. Some naming conventions
OFDIRECT directory
The <post office>\OFWORK\OFDIRECT directory is used by the GroupWise client for

direct connections in remote mode.
(WPCorp), was named WP Office. Hence, the OF in OFDIRECT. Some naming conventions
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.

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
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
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.

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

MSLOCAL MTA local working directory
<mmddxx>.<nnn> MTA log files
MSHOLD MTA holding directory
DOMAINMS Processing directory for MTA
<0-7> Priority subdirectories
<POSTx> Holding directories for post offices
<GATEWAYx> Holding directories for gateways
<DOMAINx> Holding directories for other domains
MSIBOUND Input queue for TCP/IP connections
MTACONV Work area for GroupWise 5* to 4.x conversion
TRANSMOD 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
<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.
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
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.
called the Message Server (MS). Hence, the MS in DOMAINMS. Some naming conventions
<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.
called the Message Server (MS). Hence, the MS in MSIBOUND. Some naming conventions
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
<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
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.
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.
Directory.
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:
Creates a copy of the message in the appropriate priority 0-7 subdirectory of the POA input
queue.
Directory.
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.
Directory.
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:
Directory.
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.
Directory.
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:
Directory.
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.
Directory.
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.
Directory.
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.
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.
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.
Directory.

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.
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.
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
MTA input queue.
Directory.
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.
Directory.
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
MTA input queue.
Directory.
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.
Directory.
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

Wpcsin 0 1 2 3 4 5 6 7 Wptools Wpgate: Domain Directory Directories Description

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Wpcsin 0 1 2 3 4 5 6 7 Wptools Wpgate: Domain Directory Directories Description

Transféré par

Droits d'auteur :

Formats disponibles

Domain Directory

Historical Note: WP Office**, the predecessor of GroupWise, was originally designed by

Priority 0 subdirectory for MTA

Priority 1 subdirectory for MTA

Priority 2 subdirectory for MTA

Priority 3 subdirectory for MTA

Priority 4 subdirectory for MTA

Priority 5 subdirectory for MTA

Priority 6 subdirectory for MTA

Priority 7 subdirectory for MTA

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

Historical Note: WP Office, the predecessor of GroupWise, was originally designed by

Historical Note: WP Office, the predecessor of GroupWise, was originally designed by

The <domain>\WPCSOUT\ADS directory is the ADA input queue in each domain. It

Priority 0 subdirectory for ADA

The <domain>\WPCSOUT\ADS\0 subdirectory of the ADA input queue is for service

Priority 1 subdirectory for ADA

The <domain>\WPCSOUT\ADS\1 subdirectory of the ADA input queue is for service

Priority 2 subdirectory for ADA

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

The <domain>\WPCSOUT\CSS directory is processed by a specialized MTA thread that

Priority 0 subdirectory for CSS

The <domain>\WPCSOUT\CSS\0 subdirectory is for service requests that demand an

Priority 1 subdirectory for CSS

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

Priority 2 subdirectory for CSS

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

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

Historical Note: WP Office, the predecessor of GroupWise, was originally designed by

Historical Note: WP Office, the predecessor of GroupWise, was originally designed by

Historical Note: WP Office, the predecessor of GroupWise, was originally designed by

Historical Note: WP Office, the predecessor of GroupWise, was originally designed by

Historical Note: WP Office, the predecessor of GroupWise, was originally designed by

Post Office Directory

Historical Note: WP Office**, the predecessor of GroupWise, was originally designed by

Priority 0 subdirectory for MTA

Priority 1 subdirectory for MTA

Priority 2 subdirectory for MTA

Priority 3 subdirectory for MTA

Priority 4 subdirectory for MTA

Priority 5 subdirectory for MTA

Priority 6 subdirectory for MTA

Priority 7 subdirectory for MTA

The <post office>\GWDMS directory is the Document Management Services (DMS)

Historical Note: An earlier version of GroupWise, designed by WordPerfect Corporation

Historical Note: An earlier version of GroupWise, designed by WordPerfect Corporation

Some personal client program settings

Historical Note: An earlier version of GroupWise, designed by WordPerfect Corporation

The array of FD<0-FF> subdirectories in OFFILES contain attachments that originated in

Historical Note: An earlier version of GroupWise, designed by WordPerfect Corporation

The <post office>\OFWORK\OFDIRECT directory is used by the GroupWise client for

Historical Note: WP Office, the predecessor of GroupWise, was originally designed by

Priority 0 subdirectory for POA

Priority 1 subdirectory for POA

Priority 2 subdirectory for POA

Priority 3 subdirectory for POA

Priority 4 subdirectory for POA

Priority 5 subdirectory for POA

Priority 6 subdirectory for POA

Priority 7 subdirectory for POA

Priority 0 subdirectory for ADA

Priority 1 subdirectory for ADA