OMVS

The OMVS workloads can be divided into two groups, RSE thread pools and everything else. This because all workloads, except RSE thread pools, use the client user ID as base for the address space name. (z/OS® UNIX will substitute "x" in the "Task Name" column by a random 1-digit number.)

• RSE thread pool

  An RSE thread pool is like the heart and brain of z/OS Explorer. Almost all data flows through here, and the miners (user specific threads) inside the thread pool control the actions of most other z/OS Explorer related tasks. You should specify a high-performance, one-period velocity goal, because the task does not report individual transactions to WLM. Resource usage depends heavily on user actions, and will therefore fluctuate, but is expected to be substantial.

The remaining workloads will all end up in the same service class due to a common address space naming convention. You should specify a multi-period goal for this service class. The first periods should be high-performance, percentile response time goals, while the last period should have a moderate-performance velocity goal. Some workloads, such as the ISPF Gateway, will report individual transactions to WLM, while others do not.

• Legacy ISPF Gateway

  The Legacy ISPF Gateway is an ISPF service invoked by z/OS Explorer to execute non-interactive TSO and ISPF commands explicitly issued by the client. Resource usage depends heavily on user actions, and will therefore fluctuate, but is expected to be minimal.

• z/OS UNIX shell

  This workload processes z/OS UNIX shell commands that are issued by the client. Resource usage depends heavily on user actions, and will therefore fluctuate, but is expected to be minimal.