A new enhancement allows you to track and identify the QSQSRVR jobs that are being used by an application or a job.

The DB2 for i database has long been known as a relational database that is simple to manage and administer. This design goal is one of the reasons that IBM has improved the management of DB2 QSQSRVR jobs through recent enhancements. One of these enhancements is documented in the "Grab Control of DB2 QSQSRVR Jobs" TechTip. That management enhancement provides users the ability to change which subsystem the QSQSRVR jobs run in.

The most recent enhancement—and the topic of this TechTip—is an interface for finding the QSQSRVR jobs that are being used by an application or a job.

This enhancement is a nice benefit for those users who know that the application running in their IBM i job executes all of its SQL statements in QSQSRVR jobs but don't know which QSQSRVR jobs the application uses. Easier identification of the servicing QSQSRVR jobs for an application's job makes it simpler to review all of the system resources being used by the application and to troubleshoot performance problems or other errors.

Prior to this enhancement, the only way to associate a QSQSRVR job with an application job was to review the job log of the QSQSRVR jobs. When a QSQSRVR job is assigned to an application job, DB2 writes a CPF9898 escape message into the job log of the QSQSRVR job. Here's an example of a CPF9898 message generated in QSQSRVR jobs:

SERVER MODE CONNECTING JOB IS 306913/QDIRSRV/QUSRDIR. 

While this method does allow the user to associate a QSQSRVR job with an application job, it does not scale well on systems with hundreds of QSQSRVR jobs because it would take an administrator too much time to examine the job log of each QSQSRVR job.

The new interface that simplifies the tracking of QSQSRVR jobs is available with a system stored procedure: FIND_QSQSRVR_JOBS. This stored procedure is available on all currently supported IBM i releases by installing the following PTFs:

5.4 PTFs

• SI40098
• SI40084
• SI40083

6.1 PTFs

• SI40100
• SI40099
• SI40070
• SI40068

7.1 PTFs

• SI40101
• SI40102
• SI40025
• SI40024

As shown in the example below, the new system stored procedure takes a qualified job name as the input parameter:

CALL QSYS2.FIND_QSQSRVR_JOBS('210858/KMILL/QPADEV0002');

It returns two result sets containing performance and work management information for the QSQSRVR jobs assigned to the inputted application job. One output result set contains summary information on the associated QSQSRVR jobs, and the other result set contains detailed information.

Because the QSQSRVR job information is returned in stored procedure result sets, the FIND_QSQSRVR_JOBS procedure needs to be called from an interface that can display the contents of a stored procedure result set. Due to this requirement, the interface most likely to be used would be the Run SQL Scripts interface in IBM i Navigator. If the specified input job is not associated with any QSQSRVR jobs, the stored procedure call returns zero result sets.

Figure 1 contains a sample of the summary stored procedure result set. In this example, two QSQSRVR jobs are servicing the specified input job. Notice that performance metrics such as CPU Used and Temp Storage Used are included for each QSQSRVR. The last row in the result set aggregates these performance metrics for the specified input job.

Figure 1: Here's an example QSQSRVR summary result set. (Click images to enlarge.)

As you might expect, the detailed result set returned by the stored procedure contains a larger number of fields than the summary result set. Thus, the detailed result set cannot be easily displayed in a single figure. Figures 2 and 3 highlight some of the more interesting values returned in the detailed result set.

Figure 2: This part of the QSQSRVR detailed result set shows QSQSRVR job and current user information.

The first thing to notice in the detailed result set in Figure 2 is that it only contains a row for each QSQSRVR job. The result set does not contain a summary row for the inputted application job. The beginning of the detailed result set repeats the performance metrics from the summary result set while adding the current user value for each QSQSRVR job.

Figure 3: This part of the QSQSRVR detailed result set shows work management and SQL statement information.

The detailed result set fields shown in Figure 3 complement the performance metrics by returning additional details on work management settings and SQL statements executed by the QSQSRVR job. The work management settings include the name and identifier of the memory pool along with the time slice and default lock wait times. The SQL columns return the completion status and SQL statement text for either the SQL statement currently running in the QSQSRVR job or the last SQL statement to run in the QSQSRVR job.

A complete list of the fields available in the detailed result set is shown below:

• QUALIFIED JOB
• CURRENT USER
• SUBSYSTEM DESCRIPTION NAME
• RUN PRIORITY
• SYSTEM POOL IDENTIFIER
• TOTAL PROCESSING TIME
• PAGE FAULTS
• I/O  REQUESTS
• MEMORY POOL NAME
• TEMPORARY STORAGE USED
• TIME SLICE
• DEFAULT WAIT
• SQL APPLICATION LIBARY
• SQL APPLICATION PROGRAM
• SQL APPLICATION TYPE
• SERVER CONNECTING JOB
• SERVER CONNECTING THREAD
• STATUS OF CURRENT SQL
• CURRENT SQL STATEMENT TEXT

The majority of these field values were extracted with the QUSRJOBI system API using formats 100, 150, 200, 600, and 900. Consult the IBM Systems InfoCenter  for more information on this API.

With this new support, tracking and identifying the QSQSRVR jobs used by your application has never been easier.