Table 1 lists the
number of processes per address space that is used by z/OS® Explorer. “u”
In the “Address Spaces” column indicates that the amount
must be multiplied by the number of concurrently active users using
the function.
Table 1. Process
count
Processes
Address spaces
Description
User ID
1
1
JES Job Monitor
STCJMON
3
1
RSE daemon
STCRSE
1+1
2
RSE daemon APF-authorized
STCRSE
2
(a)
RSE thread pool
STCRSE
1
(a)
RSE thread pool APF-authorized
STCRSE
1
1u
TSO (Interactive ISPF Gateway)
<userid>
2
(b)
TSO (Legacy ISPF Gateway)
<userid>
1
1u
TSO (APPC)
<userid>
1
1u
z/OS UNIX shell
<userid>
Note:
(a) There is at least 1 RSE thread pool address space active.
Refer to Address space count to
determine the actual number of RSE thread pool address spaces.
RSE daemon and all RSE thread pools use the same user ID.
(b) In normal situations, and when using the default configuration
options, there is 1 ISPF Gateway active per user. The actual number
can vary, as described in Address space count.
Most MVS™ data set-related
actions use the TSO Commands service, which can be active in the ISPF
Gateway or an APPC transaction, respectively.
All listed processes stay active until the related address space
ends, unless noted otherwise.
Use the formula in Figure 1 to
estimate the maximum number of processes used by z/OS Explorer. Figure 1. Maximum
number of processes
Where
“6” equals the number of
processes used by permanent active server address spaces.
“A” represents the number of RSE thread pool address
spaces.
“N” represents the maximum number of concurrent users.
“x” is one of the following values, depending on the
selected configuration options.
X
TSO (Interactive ISPF Gateway)
TSO (Legacy ISPF Gateway)
TSO (APPC)
1
Yes
No
No
2
No
Yes
No
1
No
No
Yes
“z” is 0 by default, but can increase depending on
user actions:
Add 1 when a z/OS UNIX shell is opened. This process
stays active until the user logs off.
"10 + N*0.05" adds a buffer for temporary processes. The required
buffer size might differ at your site.
Use the formula in Figure 2 to estimate the maximum
number of processes used by STCRSE, the RSED started task user ID
(not counting the undocumented temporary processes). Figure 2. Number of processes
for STCRSE
Where
"6" equals the number of processes used by the RSE daemon and
RSE APF authorized address spaces.
"A" represents the number of RSE thread pool address spaces.
Use the formula in Figure 3 to estimate
the maximum number of processes used by a z/OS Explorer client
(not counting the undocumented temporary processes). Figure 3. Number of processes
per client
Where
"x" depends on the selected configuration options and is documented
for the formula to calculate the maximum number of processes (Figure 1).
“z” is 0 by default, but can increase depending on
user actions, as documented for the formula to calculate the maximum
number of processes (Figure 1).
The definitions in Table 2 can
limit the actual number of processes.
Table 2. Process limits
Location
Limit
Affected resources
BPXPRMxx
MAXPROCSYS
Limits the total number of processes
BPXPRMxx
MAXPROCUSER
Limits the number of processes per z/OS UNIX UID
OMVS segment
PROCUSERMAX
Limits the number of processes for a user ID
Note:
RSE daemon and the RSE thread pools use the same user ID. Since
RSE daemon starts a new thread pool whenever needed, the number of
processes for this user ID can grow. So MAXPROCUSER must
be set to accommodate this growth, which can be formulated as 6
+ 3*A.
The MAXPROCUSER limit is per unique z/OS UNIX user
ID (UID). Multiply the estimated per-user process count by the number
of concurrently active clients if your users share the same UID.
The PROCUSERMAX limit is unique per
user ID, and is defined in your security software, in the OMVS segment
of the user ID.
