Ditch DSPLOG—History Log Info Is Superior

The history log is a great repository of messages on your IBM i partition; all messages sent to QSYSOPR, QSYSMSG and QCFGMSGQ are also sent to the history log. There are many functions that log additional messages to the history log, although they may not send those messages to the system operator message queue. Mining information from the history log allows you to track down mysteries of what happened on the system. The traditional interface to the history log, DSPLOG, is useful, but the IBM i Service, QSYS2.HISTORY_LOG_INFO is far superior.

While the history log is filled with useful information, it’s also filled with noise, but sometimes that noise has value. Using DSPLOG to pull pieces of information out of messages and summarize that information in meaningful ways is a painful process. If you need to search history log for message tokens, replacement text, or second level text, the DSPLOG interface does not provide that flexibility. Using the traditional history log interfaces, you either need to parse the spooled output from DSPLOG, use the Open List of History Log Messages (QMHOLHST) API or access the QHST* files directly and write code to parse the message information.

With the advent of the QSYS2.HISTORY_LOG_INFO service, you can use the power of SQL to access the information of interest in the messages and summarize the data into useful information.

The list below includes most of the messages I consider to be “noisy” messages. When you’re reviewing messages in the history log for specific information or errors, you probably want to exclude these messages. However, these “noisy” messages contain useful information about what’s happening on the system and the QSYS2.HISTORY_LOG_INFO service is a great way to summarize data from these messages.

• CPF1124 – Job started
• CPF1164 – Job ended
• CPIAD09 – User connected to host server job
• CPIAD0B – Sign on server processing request
• CPI3E34 – User connected to DDM server job
• CPF7020 – Journal receiver detached
• CPC7011 – Journal receiver created
• TCP2617 – TCP/IP connection to remote system closed

Below are a few examples of how history log info can be used to get additional insight into what is happening on your partition.

• IBM provides an example service called History Log – Study job longevity, which uses both the CPF1124 and CPF1164 messages. This example lists jobs that have run the current day, ordered by the longest running jobs at the top.You can expand on this example to group the jobs so you can see how many jobs had various runtimes; perhaps you want to know how many jobs ran less than a second, or how many jobs ran more than an hour. Or maybe you want to focus only jobs run by a specific user or jobs within a specific subsystem.
• Perhaps you want to limit CPU time and temporary storage utilization for interactive users, but you’re unsure how you should set these parameters in the class object. Trial and error is one approach, but you can get data to make better decisions by analyzing the CPF1164 messages, which includes the maximum temporary storage and the CPU time used by the job. You can create a query for all CPF1164 messages for jobs named QPADEV* and summarize the results by the maximum CPU time or maximum temporary storage used. This would give you some information on how to set the MAXCPU or MAXTMPSTG parameters in the class object.

• CPIAD09 is logged each time a user connects to a host server job. This message may be logged millions of times each day on busy systems. However, the CPIAD09 message is very useful in understanding workload rates, particularly for database server jobs. You can create various queries to identify a user currently connected to these jobs, the subsystem in which the server jobs run, the IP address from which they are being sent, the distribution of the connections over time, and more.

A unique feature of QSYS2.HISTORY_LOG_INFO is the ability to generate syslog events; syslog events are typically fed into Security Information and Event Management (SIEM) solutions. If you have an SIEM solution and need to send history log messages to your SIEM server, HISTORY_LOG_INFO can help. The blog post IBM i Embraces Syslog provides more information on syslog support.

The QSYS2.HISTORY_LOG_INFO service can poll for new messages with the eof-delay parameter. The eof-delay specifies how long to sleep, in seconds, before retrieving new messages. When using eof-delay, history_log_info will not end until you cancel it. This removes the burden of writing code to continually check for new messages. This is useful for those who want to continually send syslog information to their SIEM server.

If you plan to run many different queries over a similar set of data, it makes sense to copy the subset of data from the history log to a temporary file; this will make the queries run faster since they are not running over all the data in the history log files. For example, if you’re doing analysis of CPF1164 or CPIAD09 messages, creating a temporary file with only those messages will make subsequent queries run faster.

Using SQL and QSYS2.HISTORY_LOG_INFO is a faster and more powerful way to query the data in the history log. If you have further questions please reach out to me at dawnmayican@outlook.com.

---