Display Active Prestart Jobs

The Display Active Prestart Jobs (DSPACTPJ) command can be very helpful to determine the values to use for those configuration parameters.

In my last blog, I wrote about Prestart Job Configuration Settings. The Display Active Prestart Jobs (DSPACTPJ) command can be very helpful to determine the values to use for those configuration parameters.

The DSPACTPJ command displays statistics and performance information for active prestart jobs associated with a prestart job entry in an active subsystem. 

In my example, I’m reviewing the QZDASOINIT jobs in the QUSRWRK subsystem; on my system, this prestart job entry is using the default values.

DSPACTPJ displays three sets of information:

• Prestart jobs.
  This set of values shows statistics for all of the active QZDASOINIT prestart jobs regardless of whether the prestart jobs are be waiting for work or if they are actively servicing client requests.
• Prestart jobs in use.
  This set of values shows statistics for the QZDASOINIT prestart jobs that have serviced client requests.
• Program start requests.
  If you refer back to my first blog on the Introduction to Prestart Jobs, you’ll recall the term “Program start request” comes from the original SNA use of prestart jobs and this terminology is still used. The program start requests section summarizes wait information for the incoming client requests as well as the number of requests accepted and rejected.

Let’s review the information from DSPACTPJ and how you can use it to tune your prestart job configuration settings.

Looking at the Prestart jobs in use section, the most important value is the Peak number, which I have highlighted below in red. This peak number, plus your THRESHOLD value, is a good starting point for the INLJOBS parameter. However, if your peak workload is high but infrequent, you may want to set INLJOBS to a smaller value.

Prestart jobs:                                          
  Current number . . . . . . . . . . . . . . . . :   4  
  Average number . . . . . . . . . . . . . . . . :   8.6
  Peak number  . . . . . . . . . . . . . . . . . :   28 
                                                        
Prestart jobs in use:                                   
  Current number . . . . . . . . . . . . . . . . :   2  
  Average number . . . . . . . . . . . . . . . . :   6.8
  Peak number  . . . . . . . . . . . . . . . . . :   26 

Setting the INLJOBS parameter to a good value is important. The initial number of jobs is the number of jobs started when the subsystem starts (or the STRPJ command is used); but this value is also used to determine if there are an unnecessary number of waiting prestart jobs. If there are too many waiting prestart jobs (above the INLJOBS value), the subsystem will automatically end the excess jobs. If the INLJOBS value is too small, the subsystem periodically starts jobs because there are too few and end jobs because there are too many, causing unnecessary work just to start and end these prestart jobs.

Next, let’s look at the Program start requests section, where you can see the wait information for your prestart jobs. This wait information is very important as you do not want client requests to wait for a prestart job.

Review the Peak number waiting value (in red below); if this value is not zero you will want to adjust your THRESHOLD configuration setting. Finding a good value for the THRESHOLD parameter is sort of a guess—you want the THRESHOLD to be a bit larger than the number of client requests that can be received while the subsystem is starting additional jobs.

 Program start requests:                                         
   Current number waiting . . . . . . . . . . . . :   0          
   Average number waiting . . . . . . . . . . . . :   .0         
   Peak number waiting  . . . . . . . . . . . . . :   0          
   Average wait time  . . . . . . . . . . . . . . :   00:00:00.0 
   Number accepted  . . . . . . . . . . . . . . . :   127        
   Number rejected  . . . . . . . . . . . . . . . :   0 

ADLJOBS is the number of additional prestart jobs that are started when the THRESHOLD value is hit; if you have your INLJOBS set to near your peak workload, you can have ADLJOBS be a relatively small number. Starting additional prestart jobs is done by the subsystem monitor job. If you have ADLJOBS set to a large number, the subsystem cannot handle other work requests while starting those prestart jobs. Given that, it’s generally better to have ADLJOBS be a small number to ensure the subsystem can handle other requests as needed.

While the DSPACTPJ command can help you tune your prestart job entries, you may need additional information on your workload. In a future article in this series, I’ll review how you can use Collection Service data with the Performance Data Investigator to gain more insights into your use of prestart jobs.

What I have summarized in this blog is documented in more detail in the following references. The experience report on tuning prestart job entries may have been written some time ago, but the material is still relevant, and in fact, is mostly covered in the Knowledge Center article.

• Knowledge Center article on Tuning Prestart Job Entries
• Experience report on Tuning prestart job entries

---