Where Have All The QSYSOPR Messages Gone?
March 4, 2015 Alex Woodie
In the old days, you could rely on IBM i applications to always send error codes to a predictable place, such as QSYSOPR. But with the proliferation of newer Web-based applications and apps developed in Java, PHP, and other languages, that is no longer the case. HelpSystems is addressing this dilemma with a new release of its Robot/CONSOLE message monitoring software that looks for errors and alerts that IBM i admins may otherwise miss.
While RPG remains by far the most popular language for developing IBM i applications, the number of IBM i apps written in more “modern” languages like Java, PHP, Ruby, and Node.js is definitely on the rise. It’s good for the platform to have diversity of languages, and a sign that application modernization is finally upon us.
But as HelpSystems development manager Jody Dahl explains, that diversity of technology that we’re seeing with application modernizations introduces its own set of problems. “As more things go Web- or Java-based. . . . it’s not quite as easy to put error messages into message queues, such as QSYSOPR, as it used to be on the IBM i,” Dahl tells IT Jungle. “That’s one of the challenges we’re hearing from our customers.”
It’s not that developers writing in Java or another popular language can’t send their error messages to QSYSOPR. It’s just that it would take additional steps to do so, Dahl says. And in Dahl’s experience, most developers aren’t bothering to do that. “The concept of QSYSOPR is very unique to the IBM i platform,” he says. “It would actually be much more difficult for them to put the message into QSYSOPR compared to a traditional RPG or C program that was written for the IBM i.”
The quick fix for this problem is to have an IBM i operator or administrator sit at the management console or screen for the application in question. By repeatedly pressing the F5 (or similar) key, he can continually refresh the log and immediately see when the application has thrown up an error or an alert. Of course, the administrator won’t be able to do much else while he’s staring at the screen, so this may not be the best solution at organizations that value efficiency.
As you may have guessed already, HelpSystems has come up with a better approach. With Robot/CONSOLE version 6, HelpSystems introduced a new application monitoring capability to help ensure that IBM i operators and administrators don’t miss critical errors or alerts occurring in their non-traditional IBM i applications. Robot/CONSOLE will now check for the presence of log files that a non-traditional IBM i application stores in the standard out queue, which would typically be located on the IFS.
“It can be as straightforward as looking for text in log files,” Dahl says of Robot/CONSOLE’s monitoring functionality. “If anywhere in the particular line, there is this text string, then you’ll be notified. Or it could be much more advanced, using almost regular expressions, to look for certain things in columns, to be able to pinpoint certain items and be alerted to them.”
When Robot/CONSOLE detects an error or an alert, it’s treated just as if it originated from the QSYSOPR. “Then you can use any of the escalation or remediation processes that exist in Robot/CONSOLE,” he says. “Say you want to escalate it up to the Robot/NETWORK product, or send out a page or an email using Robot/ALERT. You can do that.”
The customer could even configure Robot/CONSOLE to take certain steps automatically when it detects certain types of errors or alerts in a Java or PHP app. “Say something is down–you can go ahead and run OPAL to run command line processes to restart things,” Dahl says, referring to Help’s Operator Assistance Language, which is supported across multiple products.
Robot/CONSOLE is a key component of the Robot suite, as it does the grunt work of sorting through messages generated by various queues and logs–including QSYSOPR, QSYSMSG, QAUDJRN, QHST, printer message queues, media issues, FTP requests, and others. The software can be configured to automatically respond to certain messages, escalate them, or (most often) just ignore them.
In addition to the IFS log monitoring function, there are three other noteworthy enhancements in version 6: