Intel AS/400 RISC Server - Manual (Page 313)

Chapter 20. General Performance Tips and Techniques
This section's intent is to cover a variety of useful topics that "don't fit" in the document as a whole, but
provide useful things that customers might do or deal with special problems customers might run into on
iSeries. It may also contain some general guidelines.
20.1 Adjusting Your Performance Tuning for Threads
History
Historically, the iSeries and AS/400 programmers have not had to worry very much about threads. True,
they were introduced into the machine some time ago, but the average RPG application does not use them
and perhaps never will, even if it is now allowed. Multiple-thread jobs have been fairly rare. That means
that those who set up and organize AS/400 subsystems (e.g. QBATCH, QINTER,
MYOWNSUBSYSTEM, etc.) have not had to think much about the distinction between a "job" and a
"thread."
The Coming Change
But, threads are a good thing and so applications are increasingly using them. Especially for customers
deploying (say) a significant new Java application, or Domino, a machine with the typical
one-thread-per-job model may suddenly have dozens or even hundreds of threads in a particular job.
Unfortunately, they are distinct ideas and certain AS/400 commands carefully distinguish them. If
iSeries System Administrators are careless about these distinctions, as it is so easy to do today, poor
performance can result as the system moves on to new applications such as Lotus Domino or especially
Java.
With Java generally, and with certain applications, it will be commonplace to have multiple threads in a
job. That means taking a closer look at some old friends: MAXACT and MAXJOB.
Recall that every subsystem has at least one pool entry. Recall further that, in the subsystem description
itself, the pool number is an arbitrary number. What is more important is that the arbitrary number maps
to a particular, real storage pool (*BASE, *SHRPOOL1, etc.). When a subsystem is actually started, the
actual storage pool (*SHRPOOL1), if someone else isn't already using it, comes to life and obtains its
storage.
However, storage pools are about more than storage. They are also about job and thread control. Each
pool has an associated value called MAXACT that also comes into play. No matter how many
subsystems share the pool, MAXACT limits the total number of threads able to reside and execute in the
pool. Note that this is threads and not jobs.
Each subsystem, also, has a MAXJOBS value associated with it. If you reach that value, you are not
supposed to be able to start any more jobs in the subsystem. Note that this is a jobs value and not a
threads value. Further, within the subsystem, there are usually one or more JOBQs in the subsystem.
Within each entry you can also control the number of jobs using a parameter. Due to an unfortunate turn
in history, this parameter, which might more logically be called MAXJOBS today is called MAXACT.
However, it controls jobs, not threads.
IBM i 6.1 Performance Capabilities Reference - January/April/October 2008
©
Copyright IBM Corp. 2008 Chapter 20 - General Tips and Techniques 313