Working with z/OSMF runtime log files

During normal operations, z/OSMF collects its runtime data (log messages and trace messages) in log files. z/OSMF runtime data is created on the server (server side) or sent to the server by the client (client side). Both types of messages are written to the z/OSMF runtime log files.

z/OSMF creates the log files in the product logs directory, which is, by default, /var/zosmf/data/logs. z/OSMF names the log files IZUGn.log, where n is a numeral from 0 to 9.

z/OSMF creates log files in a "cascading" manner. The most current log file is always named IZUG0.log. When this log file reaches its predefined limit, z/OSMF saves it as IZUG1.log and begins writing to a new IZUG0.log file. When the IZUG0.log file is again full, z/OSMF saves it as IZUG1.log after renaming the existing IZUG1.log file to IZUG2.log. z/OSMF continues this process, saving each log file under the next available name, up to a maximum of ten log files. Thereafter, z/OSMF discards the oldest log file (IZUG9.log) whenever a new log file is to be created.

The z/OSMF runtime log files are written in English only, and are tagged as ASCII, using the ISO8859-1 code page. You can view the log files in ASCII format through ISPF option 3.17, using the VA action (View an ASCII file). Other viewing options, such as OBROWSE, or tools such as vi, emacs, or grep, might require that you first convert the files to EBCDIC. To have ASCII files converted to EBCDIC automatically prior to browsing, set the z/OS® UNIX System Services environment variable _BPXK_AUTOCVT to "ON".

To work with the logs, you require a user ID with z/OSMF administrator authority (that is, a user ID defined to the z/OSMF administrator group). Changing the level of logging and activating trace are performed through the IZUPRMxx parmlib member. For information, see Optionally creating a IZUPRMxx parmlib member.

For examples of z/OSMF runtime log data, and a description of the log file format, see Examples of working with z/OSMF runtime logs.

Managing log lock files

When z/OSMF initializes, the log file handler creates a file named IZUG0.log.lck. This file represents a "lock" on the log data. Usually, lock files are cleaned up automatically as part of application shutdown. If the z/OSMF server ends abnormally, however, the lock files might remain. If so, the log file handler appends numbers to the normal lock file name to find a file that is free.

If the server ends abnormally, inspect the log directory and delete the lock files. If additional locks and log files were created, you can sort the files in the directory by timestamp to determine which files are the most recent. Back up these files if you want to preserve them, then clear the logs directory to conserve space.

If the IZUG0.log file cannot be accessed

If the current IZUG0.log file becomes unavailable, z/OSMF writes its runtime data to the z/OSMF server logs directory until the problem is resolved. Specifically, z/OSMF writes log and trace data to the following locations:
  • Messages are written to the message.log file, which is located in /var/zosmf/data/logs/zosmfServer/logs/messages.log
  • Trace data is written to the trace.log file, which is located in /var/zosmf/data/logs/zosmfServer/logs/trace.log

If client data cannot be written to the server

If a communication problem prevents the client's critical error log data from being written to the z/OSMF logs directory, the unlogged client data is displayed to the end user in a separate browser window. This failover action allows for the client data to be retained until the communication with the z/OS system can be restored. In some situations, IBM Support might request this data for diagnostic purposes. If the browser window is closed, the client data is not retained.

Other log files in z/OSMF

Do not confuse the z/OSMF runtime log file with the job log files that are created during the configuration process. In contrast to runtime data, configuration log data is written to a file in the z/OSMF user file system, which is, by default /var/zosmf. If a problem occurs with the configuration log file, the log data is written instead to the directory specified by the /tmp parmlib statement.