iCan Blog Archive

This week, I thought I’d write about some enhancements that have been made to the history log in recent releases. While these changes have been available for some time, they are well hidden because they were generally small changes on existing interfaces. The history log, as we all know, can be very valuable for understanding what has happened on the system, but it can also be a little overwhelming to deal with because of the potential volume of messages that get logged.

History Log Size – *DAILY

In V5R4, we made a little enhancement to the History Log Size (QHSTLOGSIZ) system value. A special value of *DAILY was added. This option allows for a new version of the history log to be created each day, rather than based upon size. If you have a busy system and reach the maximum number of records in a day, you will get a new log version when that occurs, so on these busy systems, you may have more than one log version a day even if you specify *DAILY for the system value.

I’ll make an observation about the values allowed for the history log size. IBM i allows you to specify a size of 1. I have no idea why this is, but it’s silly! In fact, if you do specify 1 for the QHSTLOGSIZ system value, the system actually uses 10 – which is still ridiculously small. The default size is 5,000, and that is also too small for today’s environments! I like the capability to have history logs created on a daily basis and that approach eliminates the need to play around with log size values.

Open List of History Log Messages API

In the 6.1 release, we added the Open List of History Log Messages (QMHOLHST) API. The API provides a programmatic interface to access history log messages. Prior to the 6.1 development of this API, your choices for accessing history log messages were either through the Display Log (DSPLOG) interface or directly by reading the history log files.

There are several advantages to using the API:

  • It’s a formal programming interface; prior to the introduction of the API, you had to read from the files directly to programmatically access the history log messages.
  • You can retrieve many messages with one invocation of the API, as opposed to reading the files record by record
  • Using the API, you can filter on message severity or you can filter on the message type; in addition you can specify with the filters to either include or omit the filtered data
  • You can also identify specific message IDs that should be retrieved or omitted
  • This API can be used to get messages from the QHST message queue into the history log files. Sometimes you need to do a DSPLOG twice in order to see the latest messages, but that is not the case when using the API.


I wrote a blog Automat Monitoring With Watches some time ago. Using watches you can watch for messages that are sent to the history log. But be careful! Do not watch for common messages (such as job started/job ended messages) since those will be matched frequently. If you do need to watch for a commonly sent message, qualify it with a comparison data so the match criteria are more selective.

If you have a need for real-time notification of messages sent to the history log, using watches is more effective than using the API or the DSPLOG command. Note that while Navigator for i has message monitors, you cannot monitor the history log messages with these message monitors. In fact, to monitor the history log, you used to have to use file monitors through Management Central, which is no longer supported. Use watches!

Print Second Level Message Text

Way back in V5R3, support was added to the Display Log (DSPLOG) command to allow you to print the second level text of messages from the history log. This was done by extending the keywords on the Output (OUTPUT) parameter to support *PRTSECLVL.

This blog post was edited for currency on February 1, 2020.

This blog post was originally published on IBMSystemsMag.com and is reproduced here by permission of IBM Systems Media.