Description of the QDBSRVxx System Jobs

Resolving The Problem

At each IPL, numerous system jobs that start with the name of QDBSRV are activated.

The following is an overview description of the functions performed by these jobs:

QDBSRVXR - This job maintains each of the system cross-reference files in QSYS with the exception of the field cross-reference file, QADBIFLD (QDBSRVXR2 handles that one)

These files contain cross-reference information about data base files and SQL information across the system.
The files all begin with the name of QADB in library QSYS.
The primary file that must be maintained is QADBXREF - this file is the cross-reference file.
It contains a record for each physical and logical file on the system.
Create, change, or delete of any file will cause the QDBSRVXR job to become active.
This job is also used to find the short name given a long name ( typical of SQL applications).

QDBSRVXR2 - This job maintains the only system cross-reference file that is not maintained by QDBSRVXR, the field cross-reference file QADBIFLD

This file contains a record for every field of every physical and logical file on the system.
Create, change, or delete of any file causes the QDBSRVXR job to become active.

QDBSRV01 - This job can be viewed as the database maintenance task dispatcher. Typically, it will be the most active immediately following the restore of a library that contains database files. Its function includes the following:

o	Signaling to the SMAPP (System Managed Access Path Protection) LIC tasks that new access paths have been restored. SMAPP then determines if these access paths must be protected.
o	Sending data queue entries to the QDBSRVXR job of new database files that were restored.
o	Sending data queue entries to the QDBSRVXR2 job of new database file fields that were restored.
o	Preparing the list of access paths that are required to be rebuilt because the access paths were not restored. This is the list that is viewed by running the EDTRBDAP command.

QDBSRV02, QDBSRV03 - These two jobs perform access path maintenance on system files. Typically, the jobs are inactive.

QDBSRV04, QDBSRV05 - These two jobs perform access path maintenance on user data files. Typically, these jobs are inactive. One set of jobs for each processor runs at priority 16 and handles DB operations;
the other set of jobs for each processor runs at priority 52 and handle rebuilding access paths The access paths that are being maintained can be viewed by running the EDTRBDAP command. Some reasons why these jobs could be active are as follows:

o	Restore of database files that were not saved with access paths.
o	Restore of logical files that are not in the same library as the physical file they are based upon.
o	Canceling of a RGZPFM command while in process. If a reorganize is canceled before it is finished, a subsequent reorganize with the same parameters will typically continue the reorganize from where it ended. If the number of changes that have occurred since the reorganize was canceled is too large, the reorganize may be restarted rather than continued.
o	Invalidation of an index due to damage found upon it.
o	Processing SMAPP initiated action.

QDBSRV06-nn - On systems with additional processors, additional system jobs are started to allow for additional concurrent access path rebuilds. There are two jobs started for each processor, consequently nn could be any number. These jobs perform the same tasks as QDBSRV04, QDBSRV05



NOTE: You can now control how many QDBSRV* jobs are started in SYSASP. You should refer to V7R1 APAR SE51094 for additional details (when this support was first introduced). This will NOT control how many jobs are started for an iASP (see below for that option) Changes are effective at next IPL.

APAR SE51094 Summary:

To let the system calculate the number based on both the maximum configured processors and the current processors, type the following command:

ADDENVVAR ENVVAR(QIBM_WC_QDBSRV_JOBS) VALUE(*CALC) CCSID(*HEX)
LEVEL(*SYS)

To let the system calculate the number based on the maximum configured processors only, type the following command:

ADDENVVAR ENVVAR(QIBM_WC_QDBSRV_JOBS) VALUE(*MAX) CCSID(*HEX)
LEVEL(*SYS)

To let the system calculate the number based on the current processors only, type the following command:

ADDENVVAR ENVVAR(QIBM_WC_QDBSRV_JOBS) VALUE(*CURRENT)
CCSID(*HEX) LEVEL(*SYS)

You can also specify the number of QDBSRV jobs that are to be started. The value must be between 5 and 99.

For example, to start 15 QDBSRV jobs:

ADDENVVAR ENVVAR(QIBM_WC_QDBSRV_JOBS) VALUE(15) CCSID(*HEX)
LEVEL(*SYS)

When the value is set to an even number, one additional QDBSRV job may be started.
Note that the estimation time for access path recovery during IPL may not be accurate when using the QIBM_WC_QDBSRV_JOBS environment variable to start a different number of QDBSRV jobs beecause the estimation tools are based on the old number of system jobs started rather than the new calculation.



NOTE: You can now control how many QDBSRV* jobs are started for an iASP. You should refer to V7R2 APAR SE63213 for additional details (when this support was first introduced). Changes are effective at next iASP vary on.

APAR SE63213 Summary:

A new environment variable was created called
QIBM_IASP_QDBSRV_JOBS. This environment variable will function
the same way as the QIBM_WC_DBSRV_JOBS environment variable
does, except that it deals with IASP Database server jobs.