Specifying numbers of threads

The DRA startup parameters, MINTHRD and MAXTHRD, specify the minimum and maximum numbers of threads that can process DBCTL DL/I or DEDB requests. The MINTHRD and MAXTHRD parameters are specified in the DRA startup table (DFSPZP).

See Defining the IMS DRA startup parameter table for more information on DRA startup parameters.

The IMS system generation parameter, MAXREGN, specifies the number of regions (or threads), to be allocated at startup, that DBCTL can handle for all connected CICS® systems and BMPs. The number can increase dynamically, to a limit of 999, as required.

The number you specify for MAXREGN should be no less than the sum of the MINTHRD parameters specified for active CICS systems, and for BMPs.

In Figure 1, the following threads are in use: one from BMPA, one from BMPB, five from CICSA and three from CICSB, making a total of 10 threads. A MAXREGN of 10 has therefore been specified for DBCTLA.

MAXTHRD can be used in DBCTL systems to ensure that, at peak loads, additional threads can be built in addition to those already allocated as a result of MINTHRD, thus avoiding waiting for threads. The maximum number of threads you can specify in DBCTL is 999. The default is 1 or the number defined by MINTHRD, whichever is the highest. MAXTHRD controls the maximum number of tasks for which this CICS system can have PSBs scheduled in DBCTL. Any requests to schedule a PSB when the MAXTHRD limit is reached is queued by the DRA. One thread is equivalent to one MVS™ TCB, thus giving more concurrency on multiprocessors. There is a storage allocation of about 9 KB per thread in the local system queue area (LSQA) below the 16 MB line. Because these threads are available for the duration of the DBCTL connection, there is no pathlength overhead for collapsing and reallocating thread related storage, and throughput should, therefore, be faster. The number of threads that you specify must be large enough for your system's needs, but if you specify a number that exceeds those needs, this will have an adverse effect on the performance of the DRA. If you specify a minimum thread value that is higher than your system's actual minimum activity, this will tie up threads unnecessarily, preventing DBCTL from allocating them to other CICS systems or BMPs. If you specify a minimum thread value that is too low, this can also affect performance; if the level of thread activity falls, this could cause the DRA to release threads down to the minimum value. These threads would then have to be reestablished if the thread requests increased again.

The number you specify for MAXTHRD should reflect what you consider to be the peak load of DBCTL threads needed. The number of threads you specify will affect performance. The larger the number you have preallocated, the more storage is needed. However, if threads are preallocated, the time needed to allocate them on demand is saved, thus improving response time and throughput. So, if your system is storage constrained, specify a lower value for MINTHRD, and use MAXTHRD as a safety valve. If response time and throughput are more important than storage requirements, specify a higher number for MINTHRD so that more threads are ready to be used.

After the MINTHRD limit is exceeded, threads continue to be built up to the MAXTHRD limit but, because each thread's control blocks are allocated during PSB scheduling, the pathlength is greater for the tasks running after the MINTHRD limit has been reached.

Also bear DBCTL thread activity in mind when specifying the MXT system initialization parameter. You use MXT to specify the maximum number of tasks that CICS will allow to exist at any time. With DBCTL, MXT should be enough to allow for the number specified in MINTHRD, plus the number you need for standard CICS tasks. With Db2®, there is no minimum number of threads. See Setting the maximum task specification (MXT) for general help on MXT.

To help you decide on the optimum values for minimum and maximum numbers of DBCTL threads, monitor thread usage and IMS task throughput (to see if tasks are being delayed), and IMS I/O rates. For details of thread statistics produced, including maximum and minimum thread usage, see DBCTL statistics. See DBCTL data returned to IMS log for details of data produced for monitoring IMS I/O rates. You can also use CICS auxiliary trace to check for queueing for threads and PSBs.