QZRCSRVS jobs and their impact on performance

 

Job monitors connect to a QZRCSRVS job for each job that is being monitored for the Job Log Messages and the Job Status metrics. The more jobs that are being monitored for these metrics, the more QZRCSRVS jobs are used.

QZRCSRVS jobs are not Management Central jobs. They are i5/OS™ TCP Remote Command Server jobs that the Management Central Java™ server uses for calling commands and APIs. In order to process the API calls for the Job Log Messages and Job Status metrics in a timely fashion within the job monitor's interval length, the APIs are called for each job concurrently at interval time.

When both metrics are specified on the same monitor, two QZRCSRVS jobs are started for each job. For example, if 5 jobs are monitored for Job Log Messages, 5 QZRCSRVS jobs are started to support the monitor. If 5 jobs are monitored for Job Log Messages and Job Status, then 10 QZRCSRVS jobs are started.

Thus, it is recommended that for standard systems, when you are using the Job Log Message and Job Status metrics, you limit the number of jobs monitored on a small system to 40 jobs or less. (With larger systems more jobs may be monitored. However, have a clear understanding of the resources that are used when monitoring more jobs and determine the affordable number to monitor. ) Also, severely limit using these two metrics for monitoring subsystems, as doing so can cause a large number of QZRCSRVS jobs to run. (A job monitor that uses just the other metrics and does not use Job Status or Job Log Message, does not use QZRCSRVS jobs.)

 

Tuning QZRCSRVS jobs

For jobs that pass work to the QZRCSRVS jobs, the subsystem that is specified on the QWTPCPUT API determines where the QZRCSRVS jobs run. QWTPCPUT is called during the processing of the QYSMPUT API. This API retrieves the subsystem information from the QUSRSYS/QYSMSVRE *USRIDX object and uses it on the QWTPCPUT call. As shipped, QZRCSRVS jobs are prestart jobs that run in the QUSRWRK subsystem and this is where the connections are routed.

If you end the prestart jobs in QUSRWRK with the ENDPJ command, then the QZRCSRVS jobs start as batch-immediate jobs in the QSYSWRK subsystem whenever a connection is requested. No jobs start in advance of the connection.

You can configure your system so that prestart jobs can be run from any subsystem. You can also configure your system to prevent batch-immediate jobs from being used at all. If the job monitor server jobs are calling Java Toolbox functions to pass work to QZRCSRVS, then they are using the QYSMPUT API, and the work must run in whichever subsystem is stored in the user index.

 

QZRCSRVS cleanup

A cleanup thread runs once an hour to determine whether a QZRCSRVS job is still being used by a Job Monitor. It determines if the job was used at least twice within the maximum job monitor interval length. If the job is not used during the previous two hours, it is ended. Java time stamps are used for this comparison, so it is imperative that the time zone value used by Java is correct (system value QTIMZON). QZRCSRVS jobs are automatically removed two hours after the job it supports ends. Likewise QZRCSRVS jobs will end if the Job Monitor that created them stops, or if Management Central ends.

Since the Management Central Job Monitor monitors active jobs, you might see messages like "Internal job identifier no longer valid" in the QZRCSRVS job. This normally happens when a monitored job with Job Log Messages or the Job Status metric ends while the monitor is running.

 

Parent topic:

Job monitors and Collection Services