Workload classification

Figure 1 shows a basic overview of the subsystems through which z/OS® Explorer, z/OS Debugger, and Developer for z/OS workloads are presented to WLM.

RSE daemon (RSED), Debug Manager (DBGMGR) and JES Job Monitor (JMON) are z/OS Explorer and z/OS Debugger started tasks (or long-running batch jobs), each with their individual address space.

RSE daemon spawns a child process for each RSE thread pool server (which supports a variable number of clients). Each thread pool is active in a separate address space (using a z/OS UNIX initiator, BPXAS). Because these are spawned processes, they are classified using the WLM OMVS classification rules, not the started task classification rules.

The clients that are active in a thread pool can create a multitude of other address spaces, depending on the actions done by the users. Depending on the configuration of Developer for z/OS, some workloads, such as the TSO Commands service (TSO cmd), can run in address spaces with a different classification.

The address spaces listed in Figure 1 remain in the system long enough to be visible, but you should be aware that due to the way z/OS UNIX is designed, there are also several short-lived temporary address spaces. These temporary address spaces are active in the OMVS subsystem.

Note that while the RSE thread pools use the same user ID and a similar job name as the RSE daemon, all address spaces started by a thread pool are owned by the user ID of the client requesting the action. The client user ID is also used as (part of) the job name for all OMVS-based address spaces stated by the thread pool.

More address spaces are created by other services that Developer for z/OS uses, such as z/OS UNIX REXEC (z/OS UNIX System Services build).