Created On: 09 November 2010
Problem:
The Enterprise Server journal file format is not documented in the product documentation.
Resolution:
The format of the jounal file is as follows:
Entry (sequence number) Time (timestamp) Requester (depends on source) Event (pid:tid:ppnnnns text)
The bolded text above appears in the on-line view of the journal file. The text in brackets is described below:
sequence number - the event ID (its index in the list),
depends on source - see Requester Sources below
timestamp - the date and time of the event,
pid:tid:ppnnnns text
where "pid" is the process ID, "tid" is the thread ID, "pp" is a message prefix code, "nnnn" is the message number, "s" is the message severity code ("I" for informational, etc), and "text" is the message text.
Requester Sources
There are three primary sources:
1) Events logged due to incoming UDP traffic (the event text is displayed in green via the MFDS journal GUI). Much of the legacy CCI support and MLDAP API generated traffic uses UDP, by default.
In this case the format is:
([MRPI major version].[MRPI minor version].[session id]) [client IP addr]:[client port]
...if the client is using the MLDAP API and has issued a successful m_ldap_bind() and established an authorized session with MFDS, or...
[client IP addr]:[client port]
...if the UDP packet is from an unbound client.
2) Events logged due to incoming HTTP traffic (the event text is displayed in red via the MFDS journal GUI). This could be in response to a browser GUI request, or it could be due to incoming MLDAP API traffic over TCP using the HTTP protocol. In which case the format is:
([session id])
In both cases, [session id] is composed of:
[MFDS version level]:[some:numbers]:[MFDS IP address]:[MFDS port]:[time]:[bind id]
where [some:numbers] may or may not appear. The [session id] may be truncated (there is a limit of 48 bytes), and so unfortunately the [bind id], which is very useful in identifying who initiated the session is often incomplete. (You can track back to the original bind request to identify what credentials were originally used, though.)
3) Events logged in response to the MFDS process logic (the event text is displayed in black via the MFDS journal GUI). These are essentially internal function trace calls.
There is lots of useful information logged in the MFDS journal. It is particualrly useful when trying to identify connection problems between an MFDS client and the MFDS process. But it is only a small part of the overall Enterprise Server infrastructure -- to diagnose and understand Enterprise Server instance (region)-specific issues, the console.log, log.html, and other standard data captures are of much greater significance.
Please note, this information was correct at the time of writing, however as this information is for internal Micro Focus use all information about the MFDS journal entry format is subject to change without notice.
Entry (sequence number) Time (timestamp) Requester (depends on source) Event (pid:tid:ppnnnns text)
The bolded text above appears in the on-line view of the journal file. The text in brackets is described below:
sequence number - the event ID (its index in the list),
depends on source - see Requester Sources below
timestamp - the date and time of the event,
pid:tid:ppnnnns text
where "pid" is the process ID, "tid" is the thread ID, "pp" is a message prefix code, "nnnn" is the message number, "s" is the message severity code ("I" for informational, etc), and "text" is the message text.
Requester Sources
There are three primary sources:
1) Events logged due to incoming UDP traffic (the event text is displayed in green via the MFDS journal GUI). Much of the legacy CCI support and MLDAP API generated traffic uses UDP, by default.
In this case the format is:
([MRPI major version].[MRPI minor version].[session id]) [client IP addr]:[client port]
...if the client is using the MLDAP API and has issued a successful m_ldap_bind() and established an authorized session with MFDS, or...
[client IP addr]:[client port]
...if the UDP packet is from an unbound client.
2) Events logged due to incoming HTTP traffic (the event text is displayed in red via the MFDS journal GUI). This could be in response to a browser GUI request, or it could be due to incoming MLDAP API traffic over TCP using the HTTP protocol. In which case the format is:
([session id])
In both cases, [session id] is composed of:
[MFDS version level]:[some:numbers]:[MFDS IP address]:[MFDS port]:[time]:[bind id]
where [some:numbers] may or may not appear. The [session id] may be truncated (there is a limit of 48 bytes), and so unfortunately the [bind id], which is very useful in identifying who initiated the session is often incomplete. (You can track back to the original bind request to identify what credentials were originally used, though.)
3) Events logged in response to the MFDS process logic (the event text is displayed in black via the MFDS journal GUI). These are essentially internal function trace calls.
There is lots of useful information logged in the MFDS journal. It is particualrly useful when trying to identify connection problems between an MFDS client and the MFDS process. But it is only a small part of the overall Enterprise Server infrastructure -- to diagnose and understand Enterprise Server instance (region)-specific issues, the console.log, log.html, and other standard data captures are of much greater significance.
Please note, this information was correct at the time of writing, however as this information is for internal Micro Focus use all information about the MFDS journal entry format is subject to change without notice.
Incident #2482494
Old KB# 32180
#MFDS
#EnterpriseDeveloper
