TechTip: Grab Control of the DB2 QSQSRVR Jobs

  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Apply subsystem work management techniques to the QSQSRVR jobs used by DB2.


Assigning jobs to a specific subsystem is a common IBM i work management technique to allocate memory and provide a degree of isolation to jobs with similar processing characteristics or response time requirements. Until some recent PTFs were delivered, DB2 for i's usage of QSQSRVR jobs for processing SQL statements didn't fit well with the methodology of using subsystems to isolate and control jobs.


The reason for this bad fit was that the QSQSRVR jobs always run in the QSYSWRK subsystem—even when the application that executes the SQL statement is running in a different subsystem. This default behavior holds true for applications running in an IBM-provided or user-defined subsystem.


The DB2 for i SQL interfaces that can utilize the QSQSRVR jobs are the DB2 SQL Call Level Interface (CLI) or the Native JDBC driver that's part of the IBM Developer Kit for Java. SQL CLI's usage of QSQSRVR jobs is limited to only those CLI applications specifying the server mode environment attribute. Applications using these interfaces to execute SQL statements have a high propensity for their SQL processing to be performed in the QSQSRVR jobs running in the QSYSWRK subsystem.


New PTFs from IBM provide an environment variable that enables the user to have the QSQSRVR jobs run in the same subsystem as the application issuing the SQL requests. These PTFs can be applied by just loading the latest Database Group PTF for V5R4 or V6R1 or by applying the following individual PTFs:


  • V6R1 PTF—SI33949
  • V5R4 PTF—SI33298

QIBM_SRVRMODE_SBS is the name of the new environment variable. When this environment variable has a value of '*SAME' or '', DB2 will execute the SQL request with a QSQSRVR job running in the same subsystem as the application. DB2 only looks at the environment variable upon the first usage of a QSQSRVR within the application's job, and the subsystem choice for the QSQSRVR job does not change for the life of the application's job.


The Add Environment Variable (ADDENVVAR) command can be used to specify this new environment variable. Here's an example invocation:




A value of *JOB can be used for the LEVEL parameter when the subsystem choice for the QSQSRVR job needs to be made a job level instead of system-wide level. The Remove Environment Variable (RMVENVVAR) command can be used to eliminate the usage of the QIBM_SRVRMODE_SBS environment variable.


In a future IBM i release, IBM plans to simplify this support by providing connection properties for the CLI and Native JDBC interfaces to enable the application to just specify the name of the subsystem that should be used for the QSQSRVR jobs. These connection properties will eliminate the need to use the environment variable.


Consideration should be given to performance before using this environment variable on your server. If you're not aware, the default QSQSRVR jobs in the QSYSWRK subsystem rely upon prestart job entry. Prestart jobs improve performance since DB2 doesn't have to wait for a QSQSRVR job to start before using it to execute an SQL statement. As a result, you may want to create prestart QSQSRVR job entries for the subsystem used by the application to deliver optimal performance. If a prestart job entry does not exist for QSQSRVR within the subsystem, DB2 will start up a QSQSRVR job as a Batch Immediate job (BCI).


Let's look a couple scenarios to better understand the impact of running applications with the QIBM_SRVRMODE_SBS having a value of '*SAME'.


Scenario #1: Application Running in QINTER Subsystem


1. User enters call to program using CLI server mode from QCMD line: CALL MYLIB/MYCLIPGM.


2. DB2 starts QSQSRVR BCI job in QINTER subsystem since this subsystem contains no prestart job entries.


3. CLI connection and associated SQL statements run in the newly started QSQSRVR BCI job within the QSQSRVR subsystem.


4. CLI connection ends, and DB2 ends the QSQSRVR BCI job.


5. Program call ends.


Scenario #2: Application in MYSBS Subsystem


1. To ensure optimal performance, prestart job entries for QSQSRVR jobs are added to the MYSBS subsystem. (This step is a one-time configuration step and would not be performed for every application call.)








2. Call to program using CLI server mode submitted to MYSBS subsystem.





3. CLI connection and the associated SQL statements run in one of the pre-started QSQSRVR jobs in the MYSBS subsystem.


4. CLI connection ends, and DB2 recycles the QSQSRVR job, making it available for the next CLI connection made within the MYSBS subsystem.


5. Program call ends.




Notice that neither scenario follows the default behavior of using QSQSRVR jobs from the QSYSWRK subsystem. Any memory allocated to the application's subsystem will be the memory utilized by the QSQSRVR jobs in the application's subsystem.


The QIBM_SRVRMODE_SBS environment variable is ignored whenever the name of the application subsystem is 'QHTTPSVR' or 'ZEND'. These two subsystems are used by the IBM DB2 Web Query and the Zend PHP products. Both of these products utilize SQL CLI for accessing DB2 for i databases.


Maybe you are unsure if QSQSRVR jobs in QSYSWRK are even used on your system. In this case, use the DB2 database monitor to detect the usage of QSQSRVR jobs. A database monitor collection can be started just for the QSQSRVR jobs by utilizing the job-level filter introduced in the V5R4 release. Here's a sample invocation:




Running this type of database monitor activity will make it fairly easy to determine the applications utilizing the QSQSRVR jobs on your system and the SQL requests running within these jobs. The job-level filter can also be specified on the SQL Performance Monitor's interface within the System i Navigator toolset.


With this new capability, you now have the power to apply the subsystem work management methodology to the QSQSRVR jobs used by DB2.