Partner TechTip: Finding Hidden IFS Error Logs

System Administration
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Does your team manually open IFS error logs for your application? If you run EnterpriseOne, SAP, Domino, WebSphere MQ, or M3, it's time to automate.


Traditionally, IBM applications were written only for IBM i, sending all their error messages to QSYSOPR. However, UNIX-based applications have been migrating to IBM for the last 15 years or so. These applications may have some errors—such as a file full message— that go directly to IBM i QSYSOPR, but it's likely they also have other errors that are hidden in a log file within a directory on IBM i. How does your team manage these?


Some teams are aware of these error logs and check them periodically, but it's usually a manual process that takes place independent of the operations team. The application might have a user interface that offers feedback or provides a view into this data, but you don't have time to waste remembering to check for potential exceptions.


You also don't want to wait for end users to complain that something doesn't look right in one of these applications, and you definitely don't want your developers to be responsible for day-to-day operations. What you need is a solution that takes care of application monitoring for you automatically.


Automation Is the Answer

Error logs are nothing more than a text file stored in the Integrated File System (IFS). With a little automation and string comparison, like what's available in Robot CONSOLE, you can easily get around the process of manually looking at this information. Robot CONSOLE has the ability to periodically read a file in the IFS and look for strings or phrases that indicate an application error has occurred.


With Robot CONSOLE, you can define a directory and generically read any new log files. Filters are then applied so that error messages or other strings of text can be identified and converted using the escalation procedures in Robot CONSOLE. If the filter matches, a record is placed into a message center and a corresponding rule can escalate the event. Along with monitoring QSYSOPR, this can shed some light on errors stored in the IFS log file on IBM i.



Figure 1: Robot CONSOLE monitors the IFS directory for new error logs in EnterpriseOne.



Figure 2: Filters can check for error messages in an EnterpriseOne log file.


Where Are the Logs on IBM i?

Google is a great tool for finding information about IFS error logs for your application. Here are a few that might come in handy:


 These are the IFS directories:

  • /QIBM/UserData/mqm/errors
  • /QIBM/UserData/mqm/qmgrs/<queueManagerName>/errors
  • /QIBM/UserData/mqm/qmgrs/&SYSTEM/errors (not used at V6 and higher)


The error log files are named AMQERR01.LOG, AMQERR02.LOG, and AMQERR03.LOG.

The system log can be displayed with transaction SM21. In case of errors, the log shows the error implementing SAP applications on the IBM System i platform with an IBM i5/OS message, information about where in the application the error occurred, a reference to a so-called short dump, and the qualified job name of the job that received the error.


The system log entries for an instance are in the '/usr/sap/<SID>/<instance>/log/SLOG<nn>' file.


Check for Errors Automatically

Robot CONSOLE monitors the traditional items on IBM i—including messages, resources, and system logs—with no problem, but it can also dig deeper into obscure application errors from SAP, EnterpriseOne, WebSphere MQ, Domino, and other UNIX-based applications.


To see how you can be more proactive in serving your application team, request a free 30-day trial of Robot CONSOLE.