The SYS1.PARMLIB(BPXPRMxx) parameters
If you use certain CICS® functions and run many CICS systems in an LPAR, the z/OS® UNIX System Services parameters, specified in BPXPRMxx members of SYS1.PARMLIB, might not be sufficient.
- Programs that run on open TCBs and use Unix System Services APIs, and programs that use other APIs that use Unix System Services, for example, IP CICS SOCKETS
- SSL TCBs specified by the MAXSSLTCBS system initialization parameters
- Java™ programs running in JVM servers
- Node.js applications
If you use Unix System Services, you must increase the MAXPROCUSER and MAXPROCSYS values. See Sizing MAXPROCUSER and Sizing MAXPROCSYS for guidance.
If CICS is configured to use SSL, you might have to increase the MAXTHREADS and MAXTHREADTASKS values.
If CICS is configured to use JVM servers, you might have to increase the MAXTHREADS and MAXTHREADTASKS values.
If you are running Node.js applications, each enabled NODEJSAPP resource requires a process and you should ensure that MAXPROCUSER and MAXPROCSYS are sized accordingly.
If your system uses two or more of these facilities, corresponding further increases in the values for these parameters is appropriate.
Sizing MAXPROCSYS
The z/OS MAXPROCSYS parameter specifies the maximum number of processes that can be active at the same time in the LPAR. MAXPROCSYS allows you to manage system resources by limiting the number of processes that the system is to support. If you set the MAXPROCSYS value too low, regions might abend because CICS cannot create a process when attempting to attach a TCB or when using a USS service. The value specified limits the total number of processes to be used across all address spaces on an LPAR, which includes other subsystems, utilities that use shell scripts, and so on.
CICS uses at least three processes for each CICS region. If you have many CICS regions in the LPAR, you must set your system limit to handle these processes. The following table explains which TCBs become processes, depending on the CICS system:
| TCB | Is the TCB always a process? | Description |
|---|---|---|
| Jobstep | Yes | The jobstep TCB is always created. |
| SO | Yes | The SO TCB is always created. |
| QR | Yes | The QR TCB becomes a process when an open TCB is attached (that is, L8, L9, X8, or X9). |
| SL | No | The SL TCB is created unless the system initialization parameter, TCPIP=NO, is specified. |
| SP | No | The SP TCB becomes a process, and the associated S8 TCBs are created and become threads only when SSL is used. |
| JVMSERVER (TP and T8) | Yes | Each enabled JVM server requires a single process regardless of how many threads it supports. |
| NODEJSAPP threads (one thread per NODEJSAPP) | Yes | Each NODEJSAPP runs as a process. |
| L8, L9, X8, and X9 open TCBs | No | If applications running on open TCBs use USS APIs, then a process is associated with the open TCB. The process is terminated when the open TCB is freed from the CICS task and returned to the dispatcher pool. An exception to this is when applications use the IP CICS Sockets interface, which uses USS APIs. With APAR PH29073 applied, CICS will not terminate the process associated with an L8 or L9 TCB when the TCB is returned to the dispatcher pool, if the IP CICS Sockets TRUE has been enabled in a CICS region. |
- A minimum of three processes is required for each CICS region but there might be a need for more, dependent on the type of workload the CICS region is processing. You must calculate for each CICS region on the LPAR. The maximum number of processes required for a region depends on which additional TCBs you are running and what open TCBs are used for. If USS services are not used either directly by applications or through use of services listed in Table 1, then the minimum of three processes per region will suffice. For example, that applies to a region using L8 TCBs only for the CICS-Db2® attach because processing Db2 work for a CICS application does not use USS services.
- A CICS region using IP CICS Sockets uses USS processes, so you must take into account the peak sockets workload. For example, a region with MAXOPENTCBS=100 and using IP CICS Sockets with OTE=YES set in the EZACICFG configuration file, may require 103 processes. This can be calculated by counting the three processes for the Jobstep, SO and QR TCBs, plus 100 for the L8 TCBs that could be used by the IP CICS Sockets feature. How many of the 100 possible L8 TCBs are used by the IP CICS Sockets is governed by the TCBLIM parameter set in the EZACICFG configuration file, so that 103 figure should be adjusted accordingly. Note that the IP CICS Sockets interface does not use L9 TCBs nor X8 or X9 TCBs. Note also that when the IP CICS Sockets feature is configured with OTE=NO, the NTASKS option in the configuration file determines the number of non-CICS TCBs used. Each of these non-CICS TCBs nevertheless will consume a USS process in the same way as an L8 TCB does and needs to be included in the calculation.
- In some cases, a CICS region that is not configured to
use IP CICS Sockets will still be consuming USS processes
because of other uses of USS.
For example, if a CICS region is configured to accept SSL requests using a TCPIPSERVICE and also contains a JVMSERVER, such a region would require three processes for the Jobstep, SO and QR TCBs, plus one for the JVM server's TP TCB, and one for the SP TCB. The JVM server's T8 TCBs and the S8 TCBs used for SSL are not counted because these TCBs are associated with threads not processes.
An example of further use of USS processes would be use of WEBSERVICEs as CICS pipeline processing involves reading configuration information from zFS files. In this case, the process is associated with an L8 TCB, so the peak number of L8 TCBs used for WEBSERVICEs needs to added to the process count. In these types of regions that do not use IP CICS Sockets, when the CICS task ends, the USS process is removed from the L8 TCB and is terminated. The act of terminating the process involves some asynchronous processing, which means that a so called
zombie process
will continue to be counted towards MAXPROCSYS momentarily until it is terminated. For heavy workloads, allow extra capacity in the number of processes to allow for these temporary zombie processes. - The use of USS by other products on the LPAR (for example, IBM® MQ channel initiator tasks) also needs to be factored in to the overall total for the LPAR.
D OMVS, A=addressspaceidD OMVS,LIMITSSizing MAXPROCUSER
The z/OS MAXPROCUSER parameter specifies the maximum number of processes that a single user (that is, with the same UID) can have concurrently active. To use USS, a z/OS user ID should be configured to have a z/OS UNIX UID, and therefore MAXPROCUSER specifies the maximum number of processes that a single user ID can have. For use of USS services within a CICS region, the UID used is always the one associated with the CICS region user ID, not the ID of the signed-on end user. For each region, calculate the maximum number of processes that can be used. Set MAXPROCUSER equal to or higher than the sum of the maximum number of processes for all regions running with the same region user ID. If you have multiple region user IDs, set MAXPROCUSER to the highest required across all region user IDs.
Related information
For more information about changing BPXPRMxx parameters, monitoring system limits, and calculating values for system resources, see z/OS UNIX System Services Planning.