The daily edition.

Scope: Rocket Enterprise Developer 12.0 for Eclipse (UNIX) documentation; Enterprise Server regions and the Rocket Software Communications Server (MFCS).

What the Communications Log records

The Communications Log is a cumulative, chronological list of all communications processes run by an enterprise server region. It holds messages from the communications manager and any associated listeners, each with a date and time stamp, and the messages show information about specific processes, including the addresses and port numbers used. When several communications processes are running, the timestamp is followed by an instance identifier in square brackets, for example [2]. The documented use is to review the communications of an individual region and to identify communications problems when troubleshooting. See Communications Log.

The log is written to a file named log-1.html in the region's system directory folder.

Default behavior: one file that only grows

By default there is one communications log per region. Messages generated for the region are added to the file during each session, producing a cumulative log of every communications process run on that server. The manual describes the housekeeping option for this default: the log can be manually archived and then deleted, so that a new one begins at the next server startup. The ESCWA page for the log describes the same file-growth behavior in another form: by default there is only one log file, and it grows continuously until an administrator deletes it. See Communications Log.

Rotating log files

To keep cumulative logs from growing to unmanageable sizes, the Enterprise Server administrator can activate the rotating log files feature. The mf-server.dat file, located in $COBDIR/etc, is the place to activate rotating log files and to change the level of logging. It uses the ini-file format: section tags in square brackets followed by name=value pairs.

With rotation active, MFCS uses multiple files named log-1.html, log-2.html, and so on:

1. When a log file reaches a configured size, MFCS moves on to the next file.
2. If that next file already exists, it is deleted first.
3. When the configured number of log files is reached, MFCS returns to log-1.html and overwrites it.

One consequence follows directly from this description: once rotation is active, the oldest entries are eventually overwritten, and the number of log-n files for a server may differ from the single-file default. The manual notes that enabling the feature "might change the number of log-n files for each server" and directs readers to their administrator for details. See Communications Log.

An opt-in message in the [logging] section

Among the options that can be placed in mf-server.dat is the [logging] section entry closed during initial receive, which controls whether the information message conversation closed during initial receive is logged.

closed during initial receive=enable-logging

• yes: log the conversation closed during initial receive information message.
• no: do not log the message. This is the default.

The same configuration can be added to mf-server.dat, to the region's Configuration Information field, or to the Custom Configuration field for the Communications Server Properties. See closed during initial receive.

More generally, the manual notes that the mf-server.dat options for logging and TLS passphrases are mostly options that must be set before MFCS contacts the Enterprise Directory Server, and that the logging options can be useful when there are problems with the connection between MFCS and EDS. See Securing Communications.

Viewing the log in ESCWA

While the region is in Start mode, open ESCWA, select the region in the tree view, and on the MONITOR drop-down list click Logs > Communications Log. See To view the communications log in ESCWA.

Include it in data capture

The minimum data-capture set for a failing region lists the communications process log file or files in the region's system directory, alongside the console log (console.log and console.bak), the trace diagnostic datasets (casauxta.rec and casauxtb.rec) and any system abend dump. The mf-server.dat file, if it exists in $COBDIR/etc, is also on the list. The manual adds that the capture process should be non-destructive and non-blocking. See Data Capture.

Takeaway

In Rocket Enterprise Developer 12.0 (UNIX documentation), the Communications Log is a single log-1.html that grows until it is archived and deleted, unless mf-server.dat in $COBDIR/etc activates rotating log-n.html files that cycle back to log-1.html and overwrite it once the configured number of files is reached; the mf-server.dat file belongs in a data-capture set together with the log files.