2.4.5 Types of log files that cannot be monitored

The following types of log files cannot be monitored by the log file trapping function:

• Files in which log information is recorded to the top of the file each time

  

• Files that are filled with null characters that were output during creation of the files, and in which null characters are overwritten with log information each time the log information is output (except for monitoring of a multi-process trace file (HTRACE))

  

• Files in which only a part of the log information that has already been output is deleted when data is wrapped around

  

• Wrap-around files (WRAP1) whose modification time is not updated when new data is added, or whose modification time is updated even when new data has not been added

  When a log file trap reads a wrap-around file (WRAP1) or a UPD type log file, it references the date and time when the file was last modified. Monitoring this type of file might cause the log file traps to operate incorrectly.

• Files that contain binary data

  A log file that contains records with binary data other than the end-of-line character.

• Files with unpredictable names (excluding UPD type log files)

  A file whose file name contains values (such as process IDs) that change from time to time.

• Network file

  Operation cannot be guaranteed if a network error or delay occurs when a file on a remote computer is accessed by a file share or other method.

• Log file containing only one line of data

  A log file that always has only one line of data.

• File accessed in lock mode

  Log file traps open log files in read mode. A log file cannot be monitored if it is not accessible in read mode. In Windows, some logging programs write log data to files in lock mode. In such a case, the logging programs might fail to write log data because they cannot lock files.

• File output in a language not supported in JP1/Base

  In Windows, JP1/Base supports the following languages: MS932, Unicode (UTF-8 and UTF-16), and C. For details about the languages supported by JP1/Base in UNIX, see 3.4.2 Setting the language (for UNIX).

When monitoring sequential files (SEQ3):

A log file trap might be unable to monitor log entries correctly if the program that outputs the log information does not meet the following criteria:

• After outputting log data, the program does not delete the log file for a certain period of time (at least one second longer than the monitoring interval).

  As shown in Figure 2-22, if the program deletes the log file immediately, the log file trap might not have time to read the logs that were output before the file was deleted.

• If an error occurs when the program switches the output log file (by deleting or re-creating the file), the program tries again.

  In Windows, an attempt by a program to switch log files might fail while a log file trap is reading the current log file (that is, while the file is open).

  During the monitoring interval, the log file trap leaves the log file closed. This gives the outputting program time to retry the operation if log file switching fails. Thus, log output might fail if the application program does not have the ability to retry log switching.

  Figure 2‒21: Scenarios in which log output to sequential files (SEQ3) cannot be monitored

To Page Top