A log message in general is a text string with an abundance of contextual information. Some of that information is passed to the logging calls through direct or default mechanisms with the rest being obtained from the operating system as part of the process of generating the log message at large. The usage and source of the various fields are discussed below:
Message type
The first six message types are essentially severity codes while the others are special case types. The message type is passed in by the calling code.
| Verbose | Basic logging of clutter. Dumping function args, vars, etc. |
| Information | Basic logging of events. |
| Status | Basic logging of 'significant' events. |
| Warning | User or system errors(?), bad function return codes(?), etc. |
| Error | User or system errors, bad function return codes, etc. |
| Bug | Actual bugs. Invalid parms, out of bound array indices, etc. |
| Regression test | Used specifically and solely for before/after regression testing. |
| Comment | Used internally and by PBLog.exe to insert user comments. |
| Internal | Internal message from Paul Bunyan. Out of memory, sem failed, etc. |
| User | Custom user messages. |
Date/Time
Log messages have three time fields: Source, Local, and GMT. Timestamps are obtained internally when the log message is created.
Component
The component the message was created under. This is provided either explicitly on the logging call or implicitly via the usage of thread or module defaults.
Context
The context the message was created under. This is provided either explicitly on the logging call or implicitly via the usage of thread or module defaults.
Machine
This is the name used to identify the machine where the message was generated. Paul Bunyan gets the machine name from the operating system but can also accept an override if specified. This makes it easier to keep track of machines in situations where the IT department wants to call a computer MSP6J179 but everyone else wants to see the name come up in the viewer as ‘Production - B’. See "Server name" in the Configuration Settings appendix.
Process
This is the full path and filename of the executable file used to create the logging process. This information is obtained from the WIN32 API function GetModuleFileName called with a module handle of NULL. E.g. ‘W:\Bin\MyProcess.exe’
Module
Full path and filename of the executable file containing the module that generated the log message. Again, this information is obtained from the operating system call GetModuleFileName, but it is more specific than the process field. If the Paul Bunyan library is linked into a DLL, this field will reflect the DLL’s file name and the process field will give the name of the executable that loaded the DLL. When the library is linked into an ordinary executable, the module field will repeat the information given in the process field.
File
Source code filename. This is passed on the logging call albeit somewhat automatically via C preprocessor macros. (It is a manual operation when using the COM interface from Visual Basic and the like.) Note that since it is just passed as a text string it is relatively easy to override the usual automatic behavior to manually pass any string desired.
Line
Line number of the source code. As with the file name, it is generated via C preprocessor macros and passed in automatically.
Process ID
Integer uniquely identifying the logging process, obtained from the operating system.
Thread ID
Integer uniquely identifying the logging thread, obtained from the operating system.
Message
This is a free form text string. It can be any text or data desired and to the limits of machine resources pretty much any length desired. See "IPC buffer size" in the Configuration Settings appendix for further information on maximum sizes of log messages.
Binary attachment (Note)
This is a free form byte array. It is used for display of binary information as well as for the transmission of binary data through Paul Bunyan to message handlers. Like the message text field, the binary attachment may also be pretty much any length desired within the limits of machine resources.