How to increase performance by grouping users into separate storage pools -- Part III

In Part I of this series we discussed the benefits of putting high-activity users in their own storage pool. (A high-activity user is one that presses the Enter key all day long, such as an order-entry employee.) Such users alone can be responsible for a majority of the transactions that your system processes each day. Making sure those employees never have to wait on the CPU is key to making them efficient.

In Part I, we learned about private storage pools and shared storage pools, and how to route users to the storage pool you want. In Part II, we discussed how to calculate values for the two parameters that govern the performance of jobs in a storage pool, activity levels ,and pool size. Now let's take a look at how you use these values to configure a private storage pool and how you route certain users into that storage pool.

Ron Turull

How to set up a private storage pool
Once you have determined your initial values for the pool size and the number of activity levels, you can create the pool. (For the example assumptions that we used in Part II, we calculated a pool size of 20MB with two activity levels.)

To create a private storage pool in subsystem QINTER, execute the following command:

CHGSBSD SBSD(QINTER) POOLS((3 20000 2))

The POOLS parameter, is used to create, delete or change a subsystem's pools. The first element, 3, specifies the pool identifier. This is the pool identifier within the subsystem, not the system-level pool identifier that gets assigned when the subsystem starts and memory is actually allocated to the pool. This example assumes that there is not a pool 3 already existing in QINTER. (Use the WRKSBS command to get an overview of the current active pools on your system.)

The second element on the POOLS parameter is the size of the pool in kilobytes (20000 in the example above, which is 20MB).

The third element is the number of activity levels, 2.

If your order-entry users run in different subsystems (e.g., some run in QINTER and others run in QINTER2), you can create a shared storage pool. We'll discuss that next time.

How to assign users to a separate pool
Once the pool is created, we need to set up a routing entry so the order-entry users will be routed to and execute in the new pool. When a job starts in a subsystem, the routing entries for that subsystem are checked in order from 1 to 9999. The routing data specified for the job is checked against the compare values specified in the routing entries. When a match is made, that routing entry is used to route the job to the storage pool associated with that routing entry. (Note: The routing entry is also used by the system to determine the class and the initial request-processing program for the job.)

To create a routing entry for the order-entry users, execute the following command:

ADDRTGE SBSD(QINTER) SEQNBR(499) CMPVAL(ORDER_ENTRY) PGM(QCMD) CLS(QGPL/QINTER) POOLID(3)

The sequence number 499 is arbitrary and can be anything you want as long as it is not being used by another routing entry. The compare value is 'ORDER_ENTRY'. The pool identifier (POOLID) should match the pool identifier that you assigned to the pool using the CHGSBSD command (see above). The rest of the parameters are duplicated from the routing entry with a compare value of 'QCMDI'. (This is a default routing entry shipped with the QINTER subsystem as routing entry number 10.)

The key to putting this all together is to create a new job description for the order-entry users. To make things easy, simply duplicate the job description they currently use (check their user profile to determine the current job description) calling it something like ORDENTJOBD. Then, just change the routing data in the new job description. For example, use the following commands:

CRTDUPOBJ OBJ(FromJOBD) FROMLIB(FromLIB) OBJTYPE(*JOBD) TOLIB(ToLIB) NEWOBJ(ORDENTJOBD)
CHGJOBD JOBD(ORDENTJOBD) RTGDTA(ORDER_ENTRY)

Finally change all the order-entry user profiles to use this new job description. The next time they sign on, the new job description will be used. The routing data in the job description (ORDER_ENTRY) will be used to find a matching routing entry in the subsystem. ORDER_ENTRY will match the compare value of the newly created routing entry 499, and the job will be routed to pool number 3.

-----------------------------------
About the author: Ron Turull is editor of Inside Version 5. He has more than 20 years' experience programming for and managing AS/400-iSeries systems.

==================================
MORE INFORMATION
==================================

• Designate resources to the QUSRWKR subsystem
  One Search400.com member wanted to know the best way to allocate more resources/memory to the QUSRWKR subsystem. Systems management expert Rich Belles was on hand with some advice.
• How to use WRKSYSSTS to monitor your system -- Part I
  A well-tuned machine pool is essential for good performance. Use the Work with System Status (WRKSYSSTS) command to monitor and maintain it, as well as other pools on the iSeries.
• How to use WRKSYSSTS to monitor your system -- Part II
  There are two "meters" of performance on the Work with System Status (WRKSYSSTS) display: page fault rates and job transition rates. Making sure those fall within acceptable levels is the essence of using the WRKSYSSTS display to tune your system.

• How to increase performance by grouping users into separate storage pools – Part IV
  Five steps to setting up a shared storage pool
  You've learned about the advantages of putting active users in their own storage pool, you've learned how to create a private storage pool, and you've learned how to route users to that pool. Now let's talk about how to set a shared storage pool.