A few years ago, I wrote a tip about my favorite way to debug programs using the Service Entry Point (SEP) feature of WDSC, which I have now replaced with RDP Rational Developer for Power Systems. If you’re a WDSC or RDP user and have somehow missed out on using SEPs for debugging, take a look at my tip.

If you don’t use WDSC or RDP, you probably didn’t pay any attention to that tip. As it turns out, SEPs aren’t just for the graphical toolset. You can use SEPs with the traditional STRDBG “green screen” debugger as well.

Literals have caused me grief on more than one occasion. Trying to figure out what a certain number or character literal means in a program has wasted too much of my time, and my time is more valuable to me than money. I have written about this topic before, but I have not talked about literals in SQL.

The example I’ve chosen may not be the best one, since the ratio of pounds to kilograms never changes. I chose it because it’s one most people should be able to relate to. The article I just referred to covers the

Last year, I wrote a two-part article outlining a basic plan for monitoring and answering IBM i error messages. But while it’s important to detect and answer error messages that require a response right now, it’s equally important to detect developing situations that will cause system problems if left alone. This week, I’ll discuss seven other things besides error messages that you should be monitoring for on your IBM i systems.

The Basics

For this article, let’s assume you are already using a system monitoring product to send out pager, email, or text alerts whenever an error message shows