Lund Performance Solutions

Workload Groups
The ability to track resource usage and other statistics on the basis of user-defined application workloads is one of the most powerful features of SOS/3000. Without workload definitions and descriptions for a system, it is nearly impossible to perform adequate capacity planning. Also, workloads have different service requirements. The more a workload demands of a resource, the more utilized that resource will be. This in turn, affects not only processes associated with that workload, but other workloads as well.

Understanding Workloads

An application workload is a group of individual users and programs or even a department within your company. You might think of an application workload as a virtual application, one that does not exist as a single program or user, but as an aggregate of programs and users on your system. A workload can be as simple as one user running one program or as complex as many users running many programs. Usually, workloads consist of users and programs that perform like tasks.
For example, let’s say that your finance department has the following financial functions under its umbrella:
Accounts payable (programs = AP002.PROG.FINANCE)
Accounts receivable (programs = AR001.PROG.FINANCE)
Let’s also say that the following users who operate the accounting department will be included no matter what programs they run. These folks might use an editor program in order to create a simple job stream for an accounting function. They might run a query program to perform ad hoc reporting. These users are therefore included in the finance workload although they do not always run the above-mentioned programs.
They log on as:


Another category of users we may include is upper management. A few high-level managers periodically inquire via their terminal into various on-line reports. These managers log on as:

So, to answer our question: “What is a workload?” consider the following for our FINANCE application:
  • Any user running various AP and AR programs.
  • A restricted number of users logging onto the FINANCE account.
  • Certain managers logging onto the BOSS account.
  • Now that we have described and defined our FINANCE application workload, let’s ask the next question: “What percentage of CPU, disc requests, etc., is the FINANCE workload as an aggregate unit consuming as compared to other workloads on my system?” This is an example of the type of question that many system managers and management personnel ask. SOS/3000 has the ability to track workloads at a terminal, in a batch job, and in a log file so you can download ASCII data into spreadsheets and graphics programs for further analysis.

    Defining Workloads

    SOS/3000 comes with three pre-defined workloads:
    JOBS - all batch jobstreams
    SESSION - all on-line terminal sessions
    SYSPROCS - all system processes
    Additional workloads can be defined by the user in the SOSWKDEF.PUB.LPS file. Use your favorite editor to create the SOSWKDEF file (QUAD.UTIL.LPS is included free of charge on our distribution tape).
    The basic format of SOSWKDEF requires the following three items for each workload defined:
  • Name of workload (up to 12 characters)
  • Type of workload (Job, Session or Both)
  • User specifications. A list of one or more of the following:
  • USER=(MPE logon User and Account for desired sessions)
    PROG=(MPE fully-qualified program file name)
    Following is a sample SOSWKDEF file:

    ACCOUNTREC !NAME of group (max 10 characters)
    !At least 1 blank line (required)
    USER=@.ACCTNG,AP !Specification
    !At least 1 blank line (required)
    GL !NAME
    USER=@.ACCTNG,GL !Specification
    LDEV=20-45 !Only ports 20-45 included
    COMPILING !Let’s track the programmers
    JOB !Catch job compiles
    PROG=REACTOR.PUB.@ !Any users on the entire system
    PROG=SPL.PUB.SYS !running either of these programs

    Figure 4.1 Sample SOSWKDEF File

    SOSWKDEF File Configuration Rules

  • A workload NAME is required. It may be up to 12 characters.
  • A workload TYPE specification is required to indicate which types of processes to include or exclude from the workload definition. This ensures that you can create two workloads for processes that run both interactively and in batch. For example, two FINANCE workloads: Batch and Session.
  • A group TYPE of “JOB” will only include batch jobs.
  • A group TYPE of “SESSION” will only include interactive processes.
  • A group TYPE of “BOTH” will include jobs and sessions, but not system processes.
  • It is required that workloads be separated by at least one or more blank lines within a definition file. Comments may be included on any line by preceding them with an exclamation mark (“!”) character.
  • Either a user or a program specification is REQUIRED. They must be entered one per line and consist of any of the following three types:
  • A program specification must contain a program, group and account:
    A user specification must contain a user and account, the session name and logon group are optional:
    The MPE logical device number or range of device numbers:
    LDEV=nnn or LDEV=nnn-nnn
    You may use an “@” sign for any of the criteria; it functions as a wild card just as it does within normal MPE rules (partial or full).
  • Ldev specifications means that you can capture activity on a terminal-by-terminal basis or even within a range of terminals. Use this option with caution!
  • There is virtually no limit to the number of USER, PROGRAM and LDEV specifications allowed for each workload.
  • Three workloads provided by default: JOBS, SESSION and SYSPROCS. Processes not falling into one of your defined workloads will fall into one of these. All processes will be assigned to one, and only one, workload group.
  • The NAME and TYPE specification lines are required. All other lines are optional. Important: In order to be considered a part of a workload group, a process must satisfy the PROG specification and the USER specification and the LDEV specification if all three are present. If one or more program specification line is included, a program has to satisfy only one of the program specifications to be included in the group. If no program specifications are entered, all process programs are considered to be in the group (unless the process is somehow disqualified by either USER or LDEV specification). The USER and LDEV specifications are resolved the same way.
  • For example, the following lines are entered into SOSWKDEF to define the workload called “WORKTEST:”

    WORKTEST !Workload name
    SESSION !Only terminals

    For a process to be included in the WORKTEST workload it has to satisfy just one PROG specification and one USER specification and one LDEV specification. Each is considered to be an “OR” condition. For example, a program INVEN01.PUB.MFG run by MGR.QTR at LDEV 56 would be counted in this workload.
  • Command Interpreter processes can be selected by specifying the program file name CI(PROG=CI). Spooler processes can be selected by specifying the program file name of “SP” (PROG=SP). All other system processes can be identified by name. When selecting any of these system type processes the program group and account must be specified as “@.”
  • Note: If you want to strip out Command Interpreters from the catch-all SESSIONS workload you must create a separate workload with the program name CI to have the response times for SESSION reflect what the users actually experience.
  • A process can belong to only one workload group. If it fits the criteria for two or more groups, it will be assigned to the first one in the file it qualifies for.
  • Keep in mind that you can also log workload information and utilize the logging facility to prepare ASCII data files to download to a PC or data may be exported into PERFORMANCE GALLERY from LPS.

    Lund Performance Solutions
    Voice: (541) 812-7600
    Fax: (541) 812-7611