iCan Blog Archive

Last week I wrote about the basic performance information that had been added to the CPF1240/CPF1241 messages, and in that blog also mentioned the basic performance information in the CPF1164 message that is sent to the history log.

Reader Tim Hawkins commented:

If you really want granular performance information (without the overhead of the Performance Tools assuming you have it), use the Job Accounting journals, there are several tools available to convert them to DB files. Then query the data using your favorite tool.

Tim, not realizing it, was the “straight-man” for this week’s blog; although I didn’t state it, when I was writing last week’s blog, I was planning to write next about job performance data, the options available, and when you might chose which option.

IBM i has very rich features regarding performance metrics; while the capabilities are very comprehensive, it can sometimes be confusing as to what feature you should use when. Of course, the answer to every question related to performance is “It depends!” I’ve not written about much of these capabilities since I speak on them frequently, but you can be sure they are on my list of future topics.

This week, I’ll review the basic options for job performance data and provide brief guidance for when you might consider each option.

  • CPF1164, CPF1240/CPF1241 messages as reviewed last week.
  • Active Jobs, Server Jobs, System Status, etc…
    The commonly used interfaces used such as work with active jobs provide basic job performance information in an interactive interface (either via the command line interface or the graphical user interface). The GUI also has the ability to look at server jobs as a subset of active jobs. These interfaces are useful for a quick view of performance across a small set of jobs.

    There are also API interfaces to retrieve this information programmatically.
  • IBM i Job Notification Exit Point
    The Job Notification exit point can be used to log notification messages to data queues when IBM i jobs are placed on a job queue, a job starts, or a job ends.
    With the job notification exit point, when a job ends, you will have the date and time the job entered the system, when the job started, and when the job ended. You can also get the processing time used; no other performance data is available.

    The job notification exit point would be useful if all you need is awareness of jobs starting and ending, and possibly the processing time used.
  • IBM i Job Accounting
    The When to Use Job Accounting article in the Knowledge Center has a nice summarization of when you’d use job accounting data as opposed to when you would use the data in the CPF1164/CPF1240/CPF1241 messages.

    Job accounting data includes all the data in the above-listed messages. Job Accounting data includes additional metrics, such as print and communications information (note the communications information is for SNA communications).

    You would use job accounting if print and communications information is important to you or the ability to assign accounting codes is required.

    Also, the performance data in the CPF1164 message pre-dates the job accounting information and job accounting would be the preferred way to gather this type of job data today. If IBM were to add additional, basic performance metrics, it would be added to the job accounting data and not to the messages. IBM i developers are aware there are customers still using the old method of getting the basic performance data from the messages in QHST so it will continue to be supported.

    The Job Accounting Journal entry documentation details the information that is collected.
  • Collection Services Performance data

    Collection Services, which runs 24×7 by default starting with the 6.1 release, has comprehensive job performance data collected. This data is stored in the QAPMJOBMI and QAPMJOBOS database files. In addition to the job performance metrics, Collection Services also collects save/restore metrics for a job in the QAPMJOBSR file. Finally, wait information is also collected by Collection Services and provides the ability to determine Why you are Waiting.

    If you need low-overhead performance data collection with detailed performance data, Collection Services provides the best solution; when you run Collection Services, it will collect and save detailed job performance data before you know you need it! You can query the data from the files directly, or you can use the Performance Data Investigator to graphically Investigate Collection Services data.
  • PM for Power Systems
    You probably are familiar with PM for Power Systems from the “old” name of PM/400. PM for Power Systems summarizes data from Collection Services and optionally sends that summarized data to IBM. By choosing to use PM for Power Systems, you can get summarized trend analysis information on your system’s utilization and performance, plus job information (most frequent, processor time, I/O and print) on the top 10 low priority jobs. Remaining capacity is constantly calculated and the data are readily available to the IBM Workload Estimator for sizing future needs.
  • Job Watcher Performance data
    The Job Watcher performance data collector was added to the operating system in the 6.1 release. It provides the ability to obtain detailed job performance data and collects much of the same job data as Collection Services does, but it also collects additional information, such as call stacks, SQL statements, objects being waited on, and more.

    Job Watcher is used for detailed job performance analysis and diagnostics. You can view Job Watcher data with the Performance Data Investigator or the iDoctor performance tool.

As you can see, there are a number of alternatives available. Which one you chose will depend upon the specific requirements you have for why you need job performance information.

This blog post was edited to update links on February 27, 2020.

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