In the first article in this series, I introduced the concept of debugging authority failures and described how the operating system determines whether an executing job should be allowed to access an object. Armed with this information, the topic of this second article, data needed to debug authority failures, will make much more sense. In my third article, I will describe how and where to find this information.

Data needed for debugging authority failures can be classified into the following categories: Who, What, When, Which, and Why. Some of this information helps you find other pieces of data. All of

Note: The code accompanying this article is available for download here.

A job log is a wonderful thing to have when you’re trying to figure out why a good program went bad. The problem with job logs is that the few messages that point out what went wrong are entombed within myriad irrelevant messages. And job logs can be long. Just recently I dealt with one that was over 400 pages. I wrote a utility to help me make sense of job logs. Maybe it will help you, too.

My utility, which I call Convert Job Log (CVTJOBLOG), reads

Concerning your article about debunking cache battery rumors, did you know that there’s another way to see cache battery information without going into System Service Tools (STRSST)? IBM is offering a new program called QSMBTTCC that allows you to display cache battery status from the command line. It’s enabled by PTFs.

–Steve

As a refresher, IBM uses batteries in its disk controllers to provide caching for its disk drives. The batteries have a useful life of about 2.75 to 3 years and the system will start sending warning messages to change your batteries when your controller cache batteries are