Section 3(cbl) - COBOL Functions

ATMI COBOL Function Reference

USERLOG(3cbl)

Name

USERLOG() - write a message to the BEA Tuxedo ATMI central event log

Synopsis

01 LOG-REC.
 COPY User data. 
01 LOGREC-LEN PIC S9(9) COMP-5. 
01 TPSTATUS-REC.
 COPY TPSTATUS. 
CALL "USERLOG" USING LOG-REC LOGREC-LEN TPSTATUS-REC.

Description

USERLOG() places LOG-REC into a fixed output file—the BEA Tuxedo ATMI central event log.

The central event log is an ordinary UNIX file whose pathname is composed as follows:

If the shell variable ULOGPFX is set, its value is used as the prefix for the filename. If ULOGPFX is not set, ULOG is used. The prefix is determined the first time USERLOG() is called.
Each time USERLOG() is called the date is determined, and the month, day, and year are concatenated to the prefix as mmddyy to set the name for the file.
The first time a process writes to the user log, it first writes an additional message indicating the associated BEA Tuxedo version.

The message is then appended to the file. With this scheme, processes that call USERLOG() on successive days will write into different files.

Messages are appended to the log file with a tag made up of the time (hhmmss), system name, process name, and process-id of the calling process. The tag is terminated with a colon (:).
BEA Tuxedo system-generated error messages in the log file are prefixed by a unique identification string of the form:

catalog>:number>:

This string gives the name of the internationalized catalog containing the message string, plus the message number. By convention, BEA Tuxedo system-generated error messages are used only once, so the string uniquely identifies a location in the source code.
If the last character of the format specification is not a newline character, USERLOG() appends one.
If the first character of the shell variable ULOGDEBUG is 1 or y, the message sent to USERLOG() is also written to the standard error of the calling process.
USERLOG() is used by the BEA Tuxedo system to record a variety of events.
The USERLOG mechanism is entirely independent of any database transaction logging mechanism.

Portability

The USERLOG interface is supported on UNIX and MS-DOS operating systems. The system name produced as part of the log message is not available on MS-DOS systems; therefore, the value PC is used as the system name for MS-DOS systems.

Examples

If the variable ULOGPFX is set to /application/logs/log and if the first call to USERLOG() occurred on 9/7/90, the log file created is named /application/logs/log.090790. If the call:

01 LOG-REC PIC X(15) VALUE "UNKNOWN USER".
01 LOGREC-LEN PIC S9(9) VALUES IS 13.
CALL "USERLOG" USING LOG-REC LOGREC-LEN TPSTATUS-REC.

is made at 4:22:14pm on the UNIX named logsys by the program whose process ID is 23431, the following line appears in the log file:

162214.logsys!security.23431: UNKNOWN USER

If the message is sent to the central event log while the process is in transaction mode, the user log entry has additional components in the tag. These components consist of the literal gtrid followed by three PIC S9(9) COMP-5 hexadecimal values. The values uniquely identify the global transaction and make up what is referred to as the global transaction identifier. This identifier is used mainly for administrative purposes, but it does make an appearance in the tag that prefixes the messages in the central event log. If the foregoing message is written to the central event log in transaction mode, the resulting log entry will look like this:

162214.logsys!security.23431: gtrid x2 x24e1b803 x239: UNKNOWN USER

If the shell variable ULOGDEBUG has a value of y, the log message is also written to the standard error of the program named security.

Errors

USERLOG() hangs if the message sent to it is larger than BUFSIZ as defined in stdio.h

Diagnostics

USERLOG() returns values include the inability to open, or write to the current log file. Inability to write to the standard error, when ULOGDEBUG is set, is not considered an error.

Notices

It is recommended that applications' use of USERLOG messages be limited to messages that can be used to help debug application errors; flooding the log with incidental information can make it hard to spot actual errors.