Admin Alert: Moving a Subsystem into its Own Shared Pool

i5/OS subsystems are segmented system environments where work (jobs) is submitted and executed. Subsystems can be customized for the type of work being done (batch, interactive, server), how much work is simultaneously executed, and what resources are used for job execution. This week, I’ll look at how you can use shared pools to assign dedicated i5/OS main storage and active threads for subsystem job execution, without having to share these resources with another subsystem.

How Subsystem Shared Pools are Created and Assigned

For newer i5 administrators, this first section discusses how system shared pools are put together and provides some basics on how to configure them. If you are a long-time i5, iSeries, and AS/400 professional, you may find something new to learn in this part, but if this information is more basic to you, then you may feel more comfortable skipping to the next section, where I cover how to change shared pool assignments for a subsystem.

i5/OS and OS/400 main storage and the maximum number of allowable threads are collectively assigned to different subsystems by splitting total main storage into separate shared pools, which are then assigned to a subsystem (main storage is the i5/OS term for working memory, which is equivalent to a PC’s system RAM). Shared pools group the following configurable items together for subsystem assignment.

1.     Shared Pool Name: In i5/OS V5Rx, the system contains 64 predefined shared pools, which can be allocated to any number of subsystems. Shared pools are also defined as storage pools in the system, and the two terms mean the same thing.

Your system’s shared pool values can be displayed by running the Work with Shared Pool command (WRKSHRPOOL) from a green-screen:

WRKSHRPOOL

If you want to print out your shared pool values, you can run the WRKSHRPOOL command like this:

WRKSHRPOOL OUTPUT(*PRINT)

In iSeries Navigator, you can also view and change shared pools by opening the Work Management –> Memory Pools –> Shared Pools node under your operating system.

Of the 64 pools that are available, four pools are predefined and pre-allocated by IBM for specific system work. These pools are:

• *MACHINE: The Machine shared pool, which the operating system uses for system jobs.
• *BASE: The base shared pool, which is the default shared pool that is allocated to all shipped subsystems.
• *INTERACT: The interactive pool, which is assigned as the second default shared pool for interactive jobs running in the QINTER subsystem (the default subsystem for processing interactive work). The first default QINTER shared pool is *BASE.
• *SPOOL: The spooling shared pool, which is assigned as the second default shared pool for all printer/writer jobs running in the QSPL subsystem. The first default shared pool for QSPL is *BASE.

The remaining 60 shared pools are labeled as *SHRPOOL1 through *SHRPOOL60. Each of these pools can be assigned its own dedicated segment of main storage and a maximum number of active threads that can access the system CPU at one time.

All the shared pool settings are configured or changed through the WRKSHRPOOL command or inside iSeries Navigator.

2.     Defined Size (M): The amount of i5/OS or OS/400 main storage (in megabytes) that is currently allocated to each shared pool. Memory can be allocated to a pool on a dynamic basis, where shared pool memory needs are recalculated and adjusted periodically through i5/OS performance tuning. You can also assign a fixed amount of main storage to a shared pool (fixed defined sizes are not affected by performance tuning). This field is not changeable for the *BASE shared pool, as the system will assign all leftover storage not allocated to any other shared pool to *BASE.

3.     Maximum Active: For each shared pool, this field defines the maximum number of threads for shared pool jobs that can concurrently use the system processor. Like the shared pool’s defined size, you can set a fixed value for the pool’s maximum active value or it can automatically be changed if performance tuning is turned on.

4.     Paging Option: This setting determines whether each shared pool is dynamically adjusted according to the system’s performance tuning function (*CALC) or whether it contains a fixed value that cannot be adjusted for its defined size (*FIXED) and maximum active threads. Different shared pools can contain different Paging Options and you are not limited to designating all of your shared pools as either *CALC or *FIXED.

5.     Tuning Data Parameters: Each shared pool contains six other parameters that affect how performance tuning (if turned on) automatically adjusts each pool in order to keep the system running smoothly. Like the other parameters, each setting is configured for each individual shared pool.

• Priority: The shared pool priority tells performance tuning how valuable it is to automatically adjust this pool’s main storage and maximum active thread allocations in relationship to the other pools. Pool priorities can be set from 1-14, and the performance tuning function will analyze and adjust lower priority shared pools first.
• Minimum and Maximum shared pool main storage size %: Expressed in percentage terms, these shared pool parameters tell performance tuning how low a shared pool’s main storage allocation can be set during idle periods and how high it can go when the pool is busy servicing jobs. Entering a value of *DFT for any minimum or maximum percentage will cause that value to change to the system’s default value for these settings.
• Minimum, Maximum, and Thread Page Fault per second values: These three values are also used by the system for each shared pool when automatic performance adjustment is turned on (as designated by the Performance Adjustment system value, QPFRADJ, being set to either ‘2’ or ‘3’). The Minimum and Maximum Faults/Second parameters tell the adjuster what minimum and maximum page faults should be used as a target guideline for changing pool size and maximum active threads to increase performance. The Threads parameter tells the performance adjuster what the guideline should be for page faults/per second for the active threads that use this shared pool.

The Tuning Data parameters are included on the panel display that appears when you call the iSeries Navigator Shared Pools function. If you are adjusting your shared pool parameters by using the green-screen WRKSHRPOOL command, enter the command and then press F11 to get to the Tuning Data parameter screen.

Now that you have a basic idea of how shared pools are defined in the system, let’s put this knowledge into practical use and go through an exercise that changes the shared pool assignment values for a commonly used subsystem.

Changing Shared Pool Values for a Subsystem

In order to illustrate how you modify an existing shared pool and assign it to an existing subsystem, let’s look at the default shared pool values for the QSNADS subsystem (which is shipped with all i5/OS systems) and change those values to use a private shared pool that we configured specifically for that subsystem. Here are the tasks we are going to perform when doing this exercise:

1. Use the Display Subsystem Description command (DSPSBSD) to identify which shared pool (or pools) the subsystem is currently using.
2. Modify an existing unused system shared pool (one of the shared pools labeled *SHRPOOL1. *SHRPOOL60) to contain a new default main storage size and the maximum number of threads in this pool that can concurrently access the processor.
3. Change the subsystem description to use the modified shared pool that was defined in step two. This new shared pool definition will replace the existing shared pool assignment that was retrieved in the first step above.

And here are the details on how you can accomplish these tasks through an i5/OS green-screen. Note that all the detailed examples shown here can easily be modified to change shared pool definitions for any subsystem. Please also note that you should make a backup copy of the QSNADS subsystem before running this exercise in case you need to restore that subsystem at a later date.

1.     Use the Display Subsystem Description command (DSPSBSD) to identify which shared pool (or pools) the subsystem is currently using. To retrieve the shared pool information, including the shared pool ID numbers, that are currently assigned to a subsystem, you can first run the DSPSBSD command, like this:

DSPSBSD SBSD(subsystem_lib/subsystem_name)

To view the subsystem description for the QSNADS subsystem, run the command this way:

DSPSBSD SBSD(QSYS/QSNADS)

Running this command displays the following Display Subsystem Description menu:

Select one of the following:

1. Operational attributes
2. Pool definitions
3. Autostart job entries
4. Work station name entries
5. Work station type entries
6. Job queue entries
7. Routing entries
8. Communications entries
9. Remote location name entries
10. Prestart job entries

Select option 2, Pool Definitions, and the command will show you the current subsystem Pool IDs, as well as the Storage Size (in kilobytes) and the activity level assigned to each pool ID. Selecting option 2 showed me that the following pool definitions were assigned to my QSNADS subsystem.

Subsystem description:   QSNADS         Status:   INACTIV
                                                         
Pool        Storage     Activity                         
 ID        Size (K)      Level                           
  1           *BASE     

What this means is that this subsystem uses only the *BASE shared pool for its main storage and maximum number of threads that can access the processor. Since *BASE is the default shared pool for most subsystems in the i5/OS operating system, QSNADS shares *BASE with a number of other subsystems and QSNADS internally identifies *BASE as subsystem pool ID 1 (this number will be important later).

If you are checking shared pool definitions for another subsystem, you may find more than one shared pool entry. In that case, simply write down all the Pool ID numbers of the shared pool definitions that you want to replace with another pool definition.

2.     Modify an existing unused system shared pool (one of the shared pools labeled *SHRPOOL1 – *SHRPOOL60) to contain a new default main storage size and the maximum number of threads in this pool that can concurrently access the processor.

In order to set up an unused shared pool that can be configured and assigned to your subsystem, you first must view and work with your pools by using the WRKSHRPOOL command:

WHRSHRPOOL

This screen will show each of the possible 64 shared pool definitions that can be assigned to your QSNADS subsystem. Since you want to replace the *BASE shared pool assignment in QSNADS with another shared pool that is only used by QSNADS, you need to locate a shared pool on WRKSHRPOOL that has no defined size or activity level set up in your system.

Once you locate the shared pool you want to use (*SHRPOOL1 – *SHRPOOL60), determine what main storage size (Defined Size setting) and Maximum Active threads (Max Active setting) that you want to assign to the pool. If your pool will be assigned a Paging Option of *CALC (which means that you are using i5 performance tuning), my recommendation is to enter smaller values into these fields as the performance tuner will adjust these values to a more appropriate figure as it analyzes the work running through the system.

If your shared pool Paging Option will be equal to *FIXED, which means that whatever values you put into the Defined Size and Max Active settings for the pool will never be changed, then you will need to think carefully about what values to enter, as these values will remain with your subsystem forever.

Whichever option you decide upon, enter your shared pool starting values for the Defined Size, Max Active, and Paging Option and press ENTER. i5/OS will retain the values for the shared pool. However, it will not allocate them from main storage until the shared pool is assigned to at least one subsystem and the subsystem is active. For our example, let’s assume that we will want to change our pool ID to use *SHRPOOL1 for the QSNADS subsystem.

Also note that, if you want to replace a second pool ID in a subsystem with a different shared pool, repeat this process for as many independent shared pools as you want to configure for your subsystem.

3.     Change your subsystem description to use the modified shared pool that you defined in step two.

Once you have identified your subsystem’s pool ID that you want to replace and you have set up a replacement shared pool for your subsystem, it’s time to attach that shared pool to your subsystem. To do that for our QSNADS example, we can use the following Change Subsystem Description command (CHGSBSD)

CHGSBSD SBSD(QSNADS) POOLS((1 *SHRPOOL1))

If you have multiple pool IDs in your subsystem that you want to replace, you can run this command as many times as you want, pointing different subsystem pool IDs to different share pools that you have already configured on your system. If you display option 2, Pool Definitions, for the QSNADS subsystem after making this change, the pool definitions should now look like this:

Subsystem description:   QSNADS         Status:   INACTIV
                                                         
Pool        Storage     Activity                         
 ID        Size (K)      Level                           
  1         *SHRPOOL1 

If QSNADS is active when you run this command, the shared pool change will occur instantly and your subsystem will begin running with the new dedicated shared pool. If QSNADS is not active when you make this change, it will begin using the new shared pool the next time the subsystem starts.

If you wanted to remove an additional pool ID from your subsystem, you can also run the CHGSBSD command to delete pool IDs. If I had a second pool ID number 2 in my QSNADS subsystem, I can easily remove that pool identifier by running the following CHGSBSD command:

CHGSBSD SBSD(QSNADS) POOLS((2 *RMV))

Note, however, that in order to remove a pool definition from a subsystem, the target subsystem must be ended first or the command will fail. In this case, I would first have to end the subsystem with the following command:

ENDSBS SBS(QSNADS)

Easier Than You Think

Once you understand the basics of subsystem shared pool allocation, it’s easy to change pool definitions, allowing you to create customized and dedicated memory options for your subsystem. If you are using performance tuning, these dedicated shared pools will be automatically altered to fit changing system workloads.

RELATED STORIES

Creating a Private Subsystem

Four Steps to Creating a Subsystem

Setting Up OS/400 Subsystems to Run Multiple Batch Jobs

Two OS/400 Performance-Adjustment Settings to Check