AS/400-iSeries Starter Kit

We've all found ourselves lost at some time or other. It's not that we're dumb. We've simply gone to an unfamiliar place without having the proper orientation.

You may have experienced a similar feeling of discomfort the first few times you signed on to your AS/400. Perhaps you submitted a job and then wondered, "How do I find that job?" or "Where did it go?" Although I'm sure you have progressed beyond these initial stages of bewilderment, you may still need a good introduction to the concepts of work management on the AS/400.

Work management on the AS/400 refers to the set of objects that define jobs and how the system processes those jobs. With a good understanding of work management concepts, you can easily perform such tasks as finding a job on the system, solving problems, improving performance, or controlling job priorities. I can't imagine anyone operating an AS/400 in a production environment without having basic work management skills to facilitate problem solving and operations. Let me illustrate two situations in which work management could enhance system operations.

Perhaps you are plagued with end users who complain that the system takes too long to complete short jobs. You investigate and discover that, indeed, the system is processing short jobs slowly because they spend too much time in the job queue behind long-running end-user batch jobs, operator-submitted batch jobs, and even program compiles. You could tell your operators not to submit jobs, or you could have your programmers compile interactively, but those approaches would be impractical and unnecessary. The answer lies in understanding the work management concepts of multiple subsystems and multiple job queues.

Perhaps when your "power users" and programmers share a subsystem, excessive peaks and valleys in performance occur due to the heavy interaction of these users. Perhaps you want to use separate storage pools (i.e., memory pools) based on user profiles so that you can place your power users in one pool, your programmers in another, and everyone else in a third pool, thereby creating consistent performance for each user group. You could do this if you knew the work management concepts of memory management.

Learning work management skills means learning how to maximize system resources. My goal for this and the next two chapters is to teach you the basic skills you need to effectively and creatively manage all the work processed on your AS/400.

Getting Oriented

Just as a road map gives you the information you need to find your way in an unfamiliar city, Figure 17.1 (401 KB - yes, 401! Might want to go have some coffee while you wait for it to download.) serves as a guide to understanding work management. It shows the basic work management objects and how they relate to one another. The objects designated by a 1 represent jobs that enter the system, the objects designated by a 2 represent parts of the subsystem description, and the objects designated by a 3 represent additional job environment attributes (e.g., class, job description, and user profile) that affect the way a job interacts with the system.

You will notice that all the paths in Figure 17.1 lead to one destination -- the subsystem. In the Roman Empire all roads led to Rome. On the AS/400, all jobs must process in a subsystem. So what better place to start our study of work management than with the subsystem?

Defining a Subsystem

A subsystem, defined by a subsystem description, is where the system brings together the resources needed to process work. As shown in Figure 17.2, the subsystem description contains seven parts that fall into three categories. Let me briefly introduce you to these components of the subsystem description.

• Subsystem attributes provide the general definition of the subsystem and control its main storage allocations. The general definition includes the subsystem name, description, and the maximum number of jobs allowed in the subsystem.
• Storage pool definitions are the most significant subsystem attributes. A subsystem's storage pool definition determines how the subsystem uses main storage for processing work. The storage pool definition lets a subsystem either share an existing pool of main storage (e.g., *BASE and *INTERACT) with other subsystems, establish a private pool of main storage, or both. The storage pool definition also lets you establish the activity level -- the maximum number of jobs allowed in the subsystem -- for a particular storage pool.
• Work entries define how jobs enter the subsystem and how the subsystem processes that work. They consist of autostart job entries, workstation entries, job queue entries, communications entries, and prestart job entries. Autostart job entries let you predefine any jobs you want the system to start automatically when it starts the subsystem.
• Workstation entries define which workstations the subsystem will use to receive work. You can use a workstation entry to initiate an interactive job when a user signs on to the system or when a user transfers an interactive job from another subsystem. You can create workstation entries for specific workstation names (e.g., DSP10 and OH0123), for generic names (e.g., DSP*, DP*, and OH*), or by the type of workstations (e.g., 5251, 3476, and 3477). Job queue entries define the specific job queues from which to receive work. A job queue, which submits jobs to the subsystem for processing, can only be allocated by one active subsystem. A single subsystem, however, can allocate multiple job queues, prioritize them, and specify for each a maximum number of active jobs. Communications entries define the communications device associated with a remote location name from which you can receive a communications evoke request. Prestart job entries define jobs that start on a local system before a remote system sends a communications request. When a communications evoke request requires the program running in the prestart job, the request attaches to that prestart job, thereby eliminating all overhead associated with initiating a job and program.
• Routing entries identify which programs to call to control routing steps that will execute in the subsystem for a given job. Routing entries also define in which storage pool the job will be processed and which basic execution attributes (defined in a job class object associated with a routing entry) the job will use for processing.

All these components of the subsystem description determine how the system uses resources to process jobs within a subsystem. I will expand upon my discussion of work entries in Chapter 18 and my discussion of routing entries in Chapter 19. Now that we've covered some basic terms, let's take a closer
look at subsystem attributes and how subsystems can use main storage for processing work.

Main Storage and Subsystem Pool Definitions

When the AS/400 is shipped, all of main storage resides in two system pools: the machine pool (*MACHINE) and the base pool (*BASE). You must define the machine pool to support your system hardware; the amount of main storage you allocate to the machine pool is hardware-dependent and varies with each AS/400. For more information about calculating the required machine pool size, see Chapter 2 and IBM's AS/400 Programming: Work Management Guide (SC41-8078).

The base pool is the main storage that remains after you reserve the machine pool. You can designate *BASE as a shared pool for all subsystems to use to process work, or you can divide it into smaller pools of shared and private main storage. A shared pool is an allocation of main storage where multiple subsystems can process work. *MACHINE and *BASE are both examples of shared pools. Other shared storage pools that you can define include *INTERACT (for interactive jobs), *SPOOL (for printers), and *SHRPOOL1 to *SHRPOOL10 (for pools that you can define for your own purposes).

You can control shared pool sizes by using the CHGSHRPOOL (Change Shared Storage Pool) or WRKSHRPOOL (Work with Shared Storage Pools) commands. Figure 17.3 shows a WRKSHRPOOL screen, on which you can modify the pool size or activity level simply by changing the entries.

The AS/400's default controlling subsystem (QBASE) and the default spooling subsystem (QSPL) are configured to take advantage of shared pools. QBASE uses the *BASE pool and the *INTERACT pool, while QSPL uses *BASE and *SPOOL.

To see what pools a subsystem is using, you use the DSPSBSD (Display Subsystem Description) command. For instance, when you execute the command

  DSPSBSD QBASE OUTPUT(*PRINT)

you will find the following pool definitions for QBASE listed (if the defaults have not been changed):

  QBASE  ((1 *BASE) (2 *INTERACT))

Parentheses group together two definitions, each of which can contain two distinct parts (the subsystem pool number and size). In this example of the QBASE pool definitions, the (1 *BASE) represents the subsystem pool number 1 and a size of *BASE, meaning that the system will use all of *BASE as a shared pool. A third part of the pool definition, the activity level, doesn't appear for *BASE because system value QBASACTLVL maintains the activity level. The second pool definition for QBASE is (2 *INTERACT). Because you can use the CHGSHRPOOL or WRKSHRPOOL commands to modify the activity level for shared pool *INTERACT, the activity level is not listed as part of the subsystem description, nor is it specified when you use the CRTSBSD or CHGSBSD commands.

Be careful not to confuse subsystem pool numbering with system pool numbering. The AS/400's two predefined system pools, *MACHINE and *BASE, are defined as system pool number 1, and system pool number 2, respectively. Pool numbering within a subsystem is unique to that subsystem, and only the routing entries in that subsystem use it to determine which pool jobs will use, based on the routing data associated with each job. As subsystems define new storage pools (shared or private) in addition to the two predefined system pools, the system simply assigns the next available system pool number to use as a reference on the WRKSYSSTS display. For example, with the above pools for QBASE and the following pools for QSPL,

  QSPL   ((1 *BASE) (2 *SPOOL))

the system pool numbering might correspond to the subsystem pool numbering as shown in Figure 17.4.

A private pool is a specific allocation of main storage reserved for one subsystem. It's common to use a private pool when the system uses the controlling subsystem QCTL instead of QBASE. If you change your controlling subsystem to QCTL, the system startup program starts several subsystems (i.e., QINTER, QBATCH, QCMN, and QSPL) at IPL that are designed to support specific types of work. Although using QBASE as the controlling subsystem lets you divide main storage into separate pools, using QCTL is inherently easier to manage and administer in terms of controlling the number of jobs and performance tuning.

IBM ships the following pool definitions for the multiple subsystem approach:

QCTL   ((1 *BASE))
QINTER ((1 *BASE) (2 *INTERACT)) 
QBATCH ((1 *BASE)) 
QCMN ((1 *BASE)) 
QSPL ((1 *BASE) (2 *SPOOL))  

As you can see, the initial configuration of these subsystems is like the initial configuration of subsystem QBASE, in that shared pools reserve areas of main storage for specific types of jobs. However, pool sharing does not provide optimum performance in a diverse operations environment where various types of work process simultaneously. In such cases, subsystems with private pools may be necessary to improve performance.

Look at the pool definitions in Figure 17.5, in which two interactive subsystems (QINTER and QPGMR) provide private pools for both end users and programmers. Both QINTER and QPGMR define specific amounts of main storage to be allocated to the subsystem instead of sharing the *INTERACT pool. Also, both storage definitions require a specific activity level, whereas shared pool activity levels are maintained as part of the shared pool definitions (using the CHGSHRPOOL or WRKSHRPOOL commands). The private pool configuration in this example, with private main storage and private activity levels, prevents unwanted contention for resources between end users and programmers.

Figure 17.5 also demonstrates how you can use multiple batch subsystems. Three batch subsystems (QBATCH, DAYQ, and QPGMRB, respectively) provide for daytime and nighttime processing of operator-submitted batch jobs, daytime end-user processing of short jobs, and program compiles. A separate communications subsystem, QCMN, is configured to handle any communications requests, and QSPL handles spooling.

The decision about whether to use shared pools or private pools should depend on the storage capacity of your system. On one hand, because shared pools ensure efficient use of main storage by letting more than one subsystem share a storage pool, it's wise to use shared pools if you have a system with limited main storage. On the other hand, private pools provide a reserved pool of main storage and activity levels that are constantly available to a subsystem without contention from any other subsystem. They are easy to manage when dealing with multiple subsystems. Therefore, private pools are a wise choice for a system with ample main storage.

Starting a Subsystem

A subsystem definition is only that -- a definition. To start a subsystem, you use the STRSBS (Start Subsystem) command. Figure 17.6 outlines the steps your system takes to activate a subsystem after you execute a STRSBS command.

First, it uses the storage pool definition to allocate main storage for job processing. Next, it uses the workstation entries to allocate workstation devices and present the workstation sign-on displays. If the system finds communications entries, it uses them to allocate the named devices. The system then allocates job queues so that when the subsystem completes the start-up process, the subsystem can receive jobs from the job queues. Next, it starts any defined prestart or autostart jobs. When the system has completed all these steps, the subsystem is finally ready to begin processing work.

Now that I've introduced you to subsystems, look over IBM's AS/400 Programming: Work Management Guide and make a sketch of your system's main storage pool configuration to see how your subsystems work. Chapter 18 examines work entries and where jobs come from, and Chapter 19 discusses routing and where jobs go. When we're done with all that, you'll find yourself on Easy Street -- with the skills you need to implement a multiple subsystem work environment.