Understanding the Agent Log

The GroupWise POA is a multithreaded server application that performs large numbers of operations each second. The log files can be confusing. An entry indicating that something was received for processing might not be immediately followed by an entry indicating that the spawned process was completed.

Log Line Format

To help make sense of the log, each line in the agent log is divided into four main parts.

The first of these is the timestamp. Anyone who can read a 24-hour digital clock can make sense of thisit is in HH:MM:SS format. This is the hour, minute, and second of the day that the event in this log entry occurred.

The second part is the process number. This is more complex. The process number is typically a three-digit number identifying the process or thread that performed the operation described in this log entry. If you are trying to follow a thread in the log, you must do so by finding the next occurrence of this number. If process 118 attempts to deliver a message, and the next line indicates that process 244 encountered an error, the error was not with the message in the previous line. Look for the next occurrence of process 118 to determine whether the message was delivered.

The third part, which is not always present, is the process type. This is a three-letter string that identifies the admin engine or the message transfer engine. When the POA processes updates to the post office database (administration messages), the string is ADM. Message transfer events (connections to the MTA for transmitting or receiving messages of any type) use the string MTP.

The fourth part of the log entry is the event description. This might be short and cryptic, but after you have seen a few of these descriptions, you can easily make sense of them. It might be an error message, or it could announce the user ID of the user who just logged in.

Common Log Entries and Explanations

This section offers a look at some examples of log entries. In all of these examples, the log level was set to verbose so that the maximum amount of useful information was captured without overburdening the POA.

Message Delivery

The following sequence tracks delivery of a mail message from tkratzer to gbrown:

20:44:20 1EC Distribute message from: tkratzer 20:44:20 1EC Begin distribution to 1 users 20:44:20 1EC Distributed: GBROWN

Notice that all three entries have the same process number, 1EC. That's how you know that the transactions are related.

Administration Update

This next sequence is the result of the administrator's changing the telephone number for user ecornish:

21:02:40 237 MTP: Receiver thread started: 1 running 21:02:40 262 MTP: Received file: WWWFS1\SYS:/CORP/CORPPO\wpcsout\ofs\2\aec15d70.001, Size: 1010 21:02:40 251 Processing aec15d70.001 21:02:40 251 Processed OK 21:02:40 255 ADM: Completed: Update object in post office - User MFG.MFGPO.ECORNISH (Administrator: (WWW_TREE_1) TKRATZER.AMERICAS, Domain: MFG)

It looks confusing, but only because so much information has been packed into the event description. POA server process 237, which was running the MTP subprocess of the POA, received a message from the domain MTA, and placed the message in the post office\WPCSOUT\OFS\2 directory. A POA routing process, numbered 251, looked at the header of the message and determined that the message was an administrative message. The POA routing process then moved the message from the wpcsout\ofs\2 directory to the wpcsout\ads\2 directory (this is not logged in the log file, but it is mentioned to help you understand the flow of administration messages). The routing process then tickled the POA's administration thread called ADM running as POA server process 255. The ADM process committed the phone number change to the WPHOST.DB file. The log shows that the object updated was user ECORNISH in the MFGPO post office of the MFG domain.

The code in parentheses is especially useful. With this information, you can audit your administrators, ensuring that they are accountable for the changes they make to your system. The administrator who made the change was authenticated to the WWW_trEE_1 eDirectory tree, and used the TKRATZER account in the AMERICAS context. You can also see that the operation was performed while ConsoleOne was connected to the MFG domain's WPDOMAIN.DB database.

Tip

Although you can determine who makes administrative changes, you might find that sometimes the information recorded is incorrect. What will happen is the administrative update will actually reflect the person who made changes to this object, just prior to the person who made the latest administrative change. For example, if last week Glenn Brown modified Eva's object, and then Tay Kratzer modified Eva's object, it may show that GBROWN modified Eva's object.