Model 204
USE OF AND ACCESS
TO PRODUCTS AND FEATURES ARE IN ACCORDANCE WITH THE TERMS AND CONDITIONS
OF THE USER’S SOFTWARE LICENSE. THE PRESENTATION OF MATERIAL HEREIN
DOES NOT, IN ANY MANNER, MODIFY SUCH TERMS AND CONDITIONS.
Introducing
the Model 204 KOMM Control Block
By James Damon
KOMM is Model 204’s common communications area and is central to every
process
performed in an Online or Batch204 job. KOMM contains information regarding
the current
state of the system: active user, active file, active server, system parameter
settings, user
parameter settings and a variety of flags, constants, and pointers. Information
in KOMM is
referenced and updated many thousands of times per second and, therefore,
efficient
access to this data structure is important for system performance.
Managing
KOMM
KOMM is 4096 bytes in length and is allocated above-the-line in z/VM and
z/OS operating systems. KOMM must be allocated below-the-line in z/VSE.
The CCAIN parameter, KOMMOPT, determines how many copies of KOMM are allocated.
KOMMOPT=0
The default, KOMMOPT=0, restricts the allocation of KOMM to one, 4096-byte
control block, shared by all users. When KOMM is shared, the system incurs
extra overhead when a user switch occurs. A user switch is the process of
dispatching the next, highest priority, ready-to-run user. This requires
that the current user’s KOMM be saved by writing it to his server before
the about-to-be dispatched user’s KOMM is read in from her server.
A user switch also increments the MOVE statistic by one. In a large system,
user switches can occur many hundreds of times per second and represent
a source of measurable overhead. Figure 1 illustrates the process.
Figure
1. A user switch
In Figure 1, User4
is the next user to be dispatched. However, before that can happen, User9,
the active user, must have his section of KOMM moved out (USEROUT) to his
server. When that move operation completes, User4’s section of KOMM
will be moved in (USERIN) from her server into KOMM and she will then be
dispatched.
Setting
KOMMOPT=1
If you set KOMMOPT=1,
then a 4096-byte KOMM is allocated for each user, plus each pseudo subtask,
and no KOMM sharing occurs. This reduces scheduler path length (CPU), thus
eliminating the delay associated with user switching, which improves perforamance.
It also reduces, by about 3K, the amount of data swapped during a server
swap since user KOMM is no longer part of the user’s server.
With KOMMOPT=1, the
process of switching users involves simply acquiring the address of the
next user’s KOMM with no data movement and only minimal scheduler overhead.
KOMMOPT=1 can be set
under all operating systems: z/OS, z/VM, and z/VSE. [Multiple KOMMs are
available for z/VSE and z/VM starting with Model 204 V6R1; and for z/OS
starting with Model 204 V5R1.] Note, however, that under z/VSE,KOMM
or multiple-KOMMs must be allocated below-the-line.
Figure 2 shows an Online
with KOMMOPT=1. Nine KOMMs are allocated in this Online, implying that NUSERS=9.
In addition to these nine KOMMs, a KOMM will be allocated for each pseudo
subtask (PST). The number of KOMMs allocated for psuedo subtasks will be
NSUBTKS.
Figure
2. KOMMOPT=1
While setting KOMMOPT=1
reduces CPU and improves performance, it does require more virtual storage.
The total virtual storage required is equal to:
(NUSERS + NSUBTKS) *
4096.
KOMMOPT=1 is required
when running MP/204, the multiprocessor version of Model 204, and is also
required when subtransaction checkpointing is enabled.
In
Summary
If you’re looking
for an easy way to squeeze a little extra performance out of your Model
204 Online system and you have sufficient virtual storage, consider setting
KOMMOPT=1 in CCAIN. The only cost is virtual storage and in an Online with
NUSERS=500,NSUBTKS=15, that’s a total of only 2.1 megabytes.
