IBM i > TIPS & TECHNIQUES > SYSTEMS MANAGEMENT

An Introduction to Job Watcher Green-Screen Commands

Although Job Watcher now has a GUI, green screeners won’t be left out with four new green-screen commands.

Although Job Watcher now has a GUI, green screeners won’t be left out with four new green-screen commands.

Job Watcher debuts as a set of stand-alone commands in the IBM i 6.1 base operating system after several releases of being embedded in the iDoctor suite of tools. Job Watcher is used for detailed analysis of jobs and tasks. This article focuses on these four new Job Watcher green-screen commands. For more on using the Web-based Job Watcher, see “Web Power.” But if you’re using green screen, read on to take advantage of the new commands.

To collect data with Job Watcher, you must first create a Job Watcher definition with the Add Job Watcher Definition (ADDJWDFN) command and then use it in the Start Job Watcher (STRJW) command. This is the same method used with the Performance Explorer and Disk Watcher tools.

Add Job Watcher Definition Command

The main factors to consider when creating a Job Watcher definition are the interval, the type of data to collect, and which jobs and tasks to include in the collection (see Figure 1).

Interval—Job Watcher is interval based, but the collection interval isn’t restricted to a set of predefined values as with Collection Services. You can use any interval between 0.1 and 3,600 seconds. Keep in mind that if you specify a relatively small interval (say, less than the 10-second default) the time needed to collect the data may be longer than the requested interval. Therefore, it’s possible for the collection intervals to vary in length. The QAPYJWINTI file contains information on the start and stop time of each interval. Instead of an interval, you can use the keyword *NODELAY, which starts a new collection immediately after the current one has concluded. Note that in practice, *NODELAY is functionally the same as extremely small interval specifications.

Type of data collected—A set of standard data will always be collected and written to nine different files. Additional data can be collected with the Additional Data Categories (ADDDTACGY) parameter. The additional categories are optional because they involve more overhead during the collection process. Table 1 lists all Job Watcher files, whether standard or not, and which categories are used to produce them.

Wait-based call-stack data—Job Watcher can conditionally collect call-stack data during intervals when a conflict wait or an abnormal wait occurs. A conflict wait is either a seize or a wait for a lock, mutex or gate that’s being held by another job or task. An abnormal wait is one associated with problem conditions or taking an excessive amount of time to complete. You can have Job Watcher collect call-stack data for either of these conditions by specifying *CONFLICT or *ABNWAIT for the “Wait-based call stack data” (WAITSTK) parameter. In the “Minimum duration (microsecs)” field, you provide the minimum duration the wait must have for a call-stack record to be created.

Jobs and tasks to include—The default specification when creating a Job Watcher definition is to collect data for all jobs and tasks. You may use wild-card characters in the job or task specification. Note that collecting data for all jobs and tasks on a very busy system can harm its performance. Using very short intervals or the *NODELAY option can also cause problems. Use these with care, especially if you’re running Job Watcher for the first time.

If you don’t use JOB(*ALL) and TASKNAME(*ALL), you can selectively add jobs and tasks to the collection based on their task dispatching element (TDE) number or current user profile, or the subsystem or storage pool in which they’re running.

Additional parameters—By default, database file records will be written at the end of each collection interval. If you specify *CALC for the Force Record Write (FRCRCD) parameter, the system will determine the most efficient timing for writing out the records. They may not be written out at interval end time, but they will all be available after the collection has ended.

Normally, inactive jobs and tasks (those that didn’t accumulate any CPU time during the interval) won’t be reported. You can change this by specifying *YES for the “Include inactive jobs/tasks” (INCALLFST) parameter.

Job Watcher continuously monitors the storage used by the auxiliary storage pool (ASP) receiving Job Watcher data and (if different) the system ASP. Job Watcher will end if either exceeds the values specified in the To File ASP Threshold (TOASPTHLD) or the System ASP Threshold (SYSASPTHLD) parameters, respectively. You can specify a value smaller than the system-specified one by setting a percentage (from 1 to 99) for either parameter.

I’ll outline additional parameters that can control the conditional collection of data in detail in a future article.

Job Watcher is interval based, but the collection interval isn’t restricted to a set of predefined values.

Dave Legler is a staff software engineer with IBM. Dave can be reached at dfl@us.ibm.com.


comments powered by Disqus

Advertisement

Advertisement

2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

IBM i > TIPS & TECHNIQUES > SYSTEMS MANAGEMENT

Analyzing Disk Watcher Data

Knowing how to collect and analyze your performance data can help improve your system’s performance

An Introduction to Job Watcher Green-Screen Commands

Although Job Watcher now has a GUI, green screeners won’t be left out with four new green-screen commands.

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
IBMi News Sign Up Today! Past News Letters