Setting the maximum task specification (MXT)

The MXT system initialization parameter limits the total number of concurrent user tasks in the CICS® system.

The MXT parameter control unconstrained resource demand, particularly virtual storage usage in order to avoid short-on-storage (SOS) conditions. This parameter also affects the amount of storage allocated to the kernel stack segment and controls contention for resources, the length of queues (which can avoid excessive processor usage), and real storage usage.

The value of MXT affects the storage use in the CICS address space. You must ensure that enough storage is available for other users in the dynamic storage areas (DSAs).

The MXT parameter controls the number of user tasks that are eligible for dispatch. MXT can be set at startup, or by using the SET SYSTEM command. When MXT is set, the kernel and dispatcher attempt to preallocate sufficient control blocks to guarantee that the number of user tasks specified by the MXT value can be created concurrently. Most of the storage for this preallocation is obtained from the CDSA or ECDSA, although a small amount of MVS™ storage is required for each task (approximately 256 bytes in 31-bit storage, above the 16 MB line, and 32 bytes in 24-bit storage, below the 16 MB line, for each user task). The MXT value is interrelated with the z/OS REGION size, and the DSA size limits that you set (the DSALIM and EDSALIM parameters). See Setting the limits for CICS storage.

The MXT system initialization parameter has a default value of 250, a minimum setting of 10, and a maximum setting of 2000. Initially, set MXT to the total number of concurrent user tasks that you require in your system.

If you set the MXT value too high, throughput and response time can suffer when system resources (processor, real storage, and virtual storage) are constrained or resource contention occurs, for example file strings or buffers, DB2 threads, ENQs and so on. Also, if you set the MXT value too high at startup, CICS forces a smaller maximum number of tasks consistent with the available virtual storage.

Conversely, if you set the MXT value too low, throughput and response time can also suffer due to excessive queuing delays even though system resources (processor, real storage, and virtual storage) are not constrained.

Monitor the performance of the CICS region to ensure that the response time and other time components (such as dispatch time and suspend time) for your transactions are acceptable. In some systems, setting MXT too high might increase resource contention to a level that causes additional delays for transactions. You can use the transaction manager global statistics from the DFH0STAT and DFHSTUP utility programs to monitor the MXT value.

In addition, the following performance data fields in the DFHTASK group are useful to assess the relationship between the task load during the life of a transaction, and the performance of the transaction:
  • CURTASKS records the current number of active user transactions in the system at the time the user task was attached.
  • MAXTASKS records the current setting for the maximum number of tasks for the CICS region at the time the user task was attached.
  • MXTDELAY records the elapsed time waiting for the first dispatch when the delay is because the MXT value is reached.

To alter the MXT value while CICS is running, you can use the SET SYSTEM MAXTASKS command. If you set the MXT value too high while CICS is running, the error message: CEILING REACHED is displayed. The CICS transaction manager statistics show the number of times the MXT ceiling has been reached.

Note: If the MAXOPENTCBS or MAXXPTCBS system initialization parameters have not been specified then the MXT parameter also sets the MAXOPENTCBS and MAXXPTCBS parameters.
Important: Start of changeBefore you change the MXT value, review the information in Open TCB pools.End of change