In "Diving into Storage Pools," MC, October 1997, I described how storage pools affect the performance of your AS/400 and how to make changes to storage pool configuration. However, there is another system structure that affects the performance of your system: activity levels. Because of space constraints, I wasn't able to go into the issue of activity levels in that article. (This is a new month, though, so I have a new allocation of pages!) To fully understand the performance of your AS/400 so that you can make appropriate changes to improve throughput, you need to understand how activity levels work.

While storage pools essentially affect only the utilization of memory, activity levels influence performance at an even larger scope. Activity levels affect both the utilization of memory and the utilization of the processor. Clearly, understanding how activity levels work is vital to having complete control of your system's performance.

In this article, I'll describe activity levels-what the symptoms of activity level problems are and how you can make changes to the configuration of your system's activity levels. I make little assumption of your familiarity with performance tuning, just that you have a basic understanding of work management. So, if being able to tune your AS/400 is a goal of yours or you simply want to understand why your system performs the way it does, this article will give you another part of the equation. I'll start with a description of activity levels.

The primary purpose of activity levels is to control the number of concurrently executing jobs. You can control activity levels at a system level and at a subsystem level. Before I go into activity levels, I need to define an active job and describe other items that relate to activity levels.

An active job is any job in a subsystem. An active job is not in the job queue and is not an ended job with output. Active jobs are shown on the Work with Active Jobs (WRKACTJOB) display.

In the subsystem description, there are controls that allow you to limit the number of jobs that become active. For example, you can limit the number of jobs that are active from a specific job

queue by specifying a value in the MAXACT parameter of the job queue entry. These controls in the subsystem description determine when a job starts.

These controls are different from activity levels. Activity levels affect jobs that are already active. Activity levels don't prevent a job from starting; they control how the job behaves once it has already started. Activity levels help you control how active jobs vie for system resources.

For example, if an activity level control affects a job, it can prevent the job from continuing to execute. The system changes the state of the job when limited by an activity level.

An active job can be in one of three states: active, wait, or ineligible. In the active state, the job is currently using system resources. In the wait state, the job has paused for some reason. For example, an interactive job is in the wait state when the user is typing; that's called a display wait. In the ineligible state, the job wants to be using system resources; however, it is being prevented from doing so by activity level limits. On the WRKACTJOB display, ineligible jobs are shown with a status of INEL, which you can see an example of in Figure 1.

Activity level limits affect processor and memory utilization by making a job ineligible if there are no available activity levels for the job to use. If the job is ineligible, it will not use any additional processor or memory resources. So activity levels give you control if processor or memory resources are being overutilized.

When setting activity levels, you're trying to balance opposing goals. One goal is to have the maximum CPU utilization possible. The other goal is to make sure that the system doesn't spend more time managing jobs than actually executing jobs.

If the system is near or at 100 percent CPU utilization, you may want to lower the number of available activity levels. Having fewer jobs directly competing for limited resources can actually result in more work getting done. (The amount of work done is often called throughput.)

You balance these goals by watching two sets of values. The first value is CPU utilization. If CPU utilization is low, you can increase the number of jobs that are executing. You can do this by increasing the activity levels and by allowing more jobs to start executing in the first place.

The second value you want to watch is transitions to ineligible. The best place I've found to watch for problems in this area is from the Work with System Status (WRKSYSSTS) display. You can see an example of this display in Figure 2.

On this display, notice the columns labeled active to ineligible (Act Inel) and wait to ineligible (Wait Inel). The values in these columns tell you how many times per second the system is finding that there aren't enough activity levels available to execute the jobs that are active. In this case, there have been three transitions per second from active to ineligible.

An active to ineligible transition means that a job was executing and reached the end of its time slice. (Time slice is an allocation of CPU resources given to a job and is measured in milliseconds.) At that point, the system found there were no activity levels available for a job with its priority, so the system changed the job's state from active to ineligible.

A wait to ineligible transition means the job finished its wait state (for example, the user pressed

Enter after finishing typing). The job wants to become active, yet the system again finds no activity levels available for a job of that priority. So the system changes the state of the job from wait to ineligible, instead of from wait to active.

If you find that processor utilization is low and there are transitions to ineligible, you may want to increase the activity levels. This will allow more jobs to use the processor.

Another way to observe the problems with transitions to ineligible is by using the performance tools. The performance tools reports will tell you the number of transitions to ineligible and the CPU utilization at the time.

Although you can also use activity levels to control contention for memory resources, you typically handle this through sizing of memory pools.

The basic vehicle for controlling activity levels is a subsystem description. Specifically, for each pool you can specify an activity level. You can see an example of the activity level settings for a specific subsystem in Figure 3.

This figure shows the pool configuration for the subsystem QPGMR. For subsystem pool ID number 2, the activity level is set to 1, so only one job from this pool ID can have a status of executing. Check the routing entries in the subsystem description to see which pool ID a job will use. For shared pools, you can also use the Work with Shared Pools (WRKSHRPOOL) display.

There are also a couple of system values used to configure activity levels. The first system value used is QMAXACTLVL. This system activity level controls how many jobs can be executing for the system as a whole. Typically, this system value is set to *NOMAX. You normally want to use the configuration of the subsystems to control activity levels, not the system value.

Because the base pool, shown as pool ID 2 on the WRKSYSSTS display, is not configured in a subsystem description, a system value is used to control the activity levels of the base pool.

An easy place to configure activity levels is from the WRKSYSSTS command (Figure 2). Listed in the activity levels column is the activity level configuration for all subsystems. (Keep in mind that the system value that controls activity levels for the entire system is not shown on this display. Make sure you check that system value as well.)

If you have adequate authority, you can make changes to the activity levels from the display shown in Figure 2. For example, you need to have authority to the subsystem description in order to be able to make a change to the activity levels for that subsystem. Also, to change the activity levels for the base pool, you need to have authority to change system values.

As I discussed in "Diving into Storage Pools," the AS/400 has the capability to perform automatic performance turning. This is controlled with the system value QPFRADJ. If that system value is set to 1, 2, or 3, the system makes changes that affect activity levels at IPL, at IPL and dynamically, or just dynamically, respectively. (Setting QPFRADJ to 0 means the system will make no adjustments to activity levels.) So, if you have automatic performance configuration enabled, understand that the system may and can make changes to any settings regarding activity levels.

Now that you understand both storage pools and activity levels, you are better prepared to make changes to your AS/400 to improve performance. Make sure you're aware that the changes you make can have both positive and negative effects. Again, here are some suggestions to help reduce the possibility of problems.

o Make only one change at a time. If you change more than one performance factor at a time, it can be quite difficult to determine what worked and what did not. So change an activity level, watch the WRKSYSSTS display or performance reports, and see what effect your change had.

o Make sure that you understand your current configuration and that you fully document any changes you make. Unfortunately, many people do not understand the interrelated nature of subsystems and system values. However, with good documentation, even someone who doesn't understand those concepts stands a good chance of recovering from a mistake.

Storage pools and activity levels give you a great deal of control over the performance of your system. You may choose to let the system handle performance turning on its own, using the automatic performance adjuster. Alternatively, you may decide to control the performance of your system with powerful features like activity levels.

Jim Hoopes is a consultant, educator, and freelance writer. He specializes in client/server development and support, Internet and intranet technologies, the AS/400, and Windows NT He can be reached by email at This email address is being protected from spambots. You need JavaScript enabled to view it..

OS/400 Work Management (SC41-4306, CD-ROM QBJALG01)

Figure 1: One of the jobs in this display is ineligible.

Figure 2: You can monitor transitions to ineligible from the WRKSYSSTS display.

Figure 3: Activity levels are associated with subsystem pool descriptions.

Also Read

TD/OMS and Gravity “Milestone 1” Enhancements Streamline Efficiency and Advance Application Development Potential for Re...

Now Let’s Consider Vendor Maintenance

Know Where Your Maintenance Stands