Setting the maximum task specification (MXT)

The MXT system initialization parameter limits the total number of concurrent user tasks in the CICS® system. It also affects the amount of storage allocated to the kernel stack segment.

Effects

MXT primarily controls virtual storage usage, particularly to avoid short-on-storage (SOS) conditions. It also controls contention for resources, the length of queues (this can avoid excessive processor usage), and real storage usage.

MXT controls the number of user tasks that are eligible for dispatch. When MXT is set (either at startup, when an EXEC CICS SET SYSTEM command is processed, or when using a CEMT transaction) the kernel and dispatcher attempt to preallocate sufficient control blocks to guarantee that MXT user tasks can be created concurrently. The majority of the storage used in this preallocation is obtained from the CDSA or ECDSA, although a small amount of MVS™ storage is required for each task (approximately 256 bytes above the 16MB line, and 32 bytes below the 16MB line for each user task). It is interrelated with the DSA size limits that you set (DSALIM, EDSALIM).

Limitations

If you set MXT too low, throughput and response time can suffer when system resources (processor, real storage, and virtual storage) are not constrained.

If you set MXT too high at startup, CICS forces a smaller maximum number of tasks consistent with available storage.

If you set MXT too high while running, you get the error message: "CEILING REACHED".

For more information about MRO considerations, and the secondary effects of the region exit interval (ICV), see Tuning the region exit interval (ICV).

Recommendations

Initially, set MXT to the number of user tasks you require concurrently in your system by totaling the following:

How implemented

The MXT system initialization parameter has a default value of 5, and a minimum setting of 1. It can be altered with either CEMT or EXEC CICS SET SYSTEM MAXTASKS commands while CICS is running.

How monitored

The CICS transaction manager statistics show the number of times the MXT ceiling has been reached.

Related tasks
Virtual and real storage: performance considerations
Tuning CICS virtual storage
Splitting online systems: virtual storage
Using transaction classes (MAXACTIVE) to control transactions
Specifying a transaction class purge threshold (PURGETHRESH)
Prioritizing tasks
Adjusting the limits for dynamic storage areas
Using modules in the link pack area (LPA/ELPA)
Choosing aligned or unaligned maps
Defining programs as resident, nonresident, or transient
Putting application programs above the 16MB line
Allocating real storage when using transaction isolation
Limiting the expansion of subpool 229 using VTAM pacing
[[ Contents Previous Page | Next Page Index ]]