Admin Alert: More Information on Fixed Storage and WRKSYSACT
December 13, 2006 Joe Hertvik
|
Several readers have recently contacted me about inaccurate and missing information in previous columns regarding storage pools and WRKSYSACT. When readers provide new information, I sometimes revisit a topic to correct obvious flaws, provide better information, or to expand reader knowledge. With this new input, I have researched better techniques for creating fixed storage pools and for finding missing commands. In two parts, here’s my expanded take on these subjects. Part 1: No Virginia, You Cannot Create Fixed Storage Pools from the WRKSHRPOOL Screen, But. . . In my July column on moving subsystems into their own storage pools, I stated that the Paging Option field on the Work with Shared Pools command (WRKSHRPOOL) determines whether each storage pool is dynamically adjusted according to the i5 or iSeries performance tuning function. Echoing a view that I believed to be true and that I had found listed on other Web sites, I stated that setting a storage pool’s Paging Option to *FIXED sets the pool’s defined memory size to a fixed value that cannot be changed. I also stated that these fixed shared storage pools can be assigned to a subsystem as permanent working memory that can never be reallocated to another storage pool. Unfortunately, these statements are wrong. You cannot create fixed shared storage pools in WRKSHRPOOL or in its iSeries Navigator (OpsNav) equivalent function, even though the wording on those screens may mislead you into believing that is the case. However, there is a different way to do this and it involves creating private storage pools for a subsystem’s exclusive use. Reader Walt Clinch keyed me in to this mistake and set me on the path to figuring out what a Paging Option value of *FIXED really does. Here’s what wrong with this idea and how you can get to your actual goal of assigning a permanent storage pool for the exclusive use of one subsystem. What *FIXED and *CALC Really Do The Paging Option field for each shared storage pool on the WRKSHRPOOL screen refers to whether or not the Expert Cache feature in i5/OS is turned on for that storage pool. In iSeries Navigator (OpsNav), this value can also be set inside the Configuration tab on each Storage Pool’s Properties panel under the Work Management –> Memory Pools –> Shared Pools node for your system. Setting a pool’s Paging Option to *CALC in WRKSHRPOOL (or setting it to Calculated in OpsNav) turns Expert Caching on, while setting it to *FIXED (Fixed in OpsNav) turns Expert Cache off. Expert Cache can be individually set on or off for every shared storage pool on your system, and it has nothing to do with setting fixed storage pool sizes or dynamically allocating main memory to your storage pool. According to IBM, Expert Cache is a series of improved paging algorithms used for database files and related objects. Your best bet is to use Expert Cache for improving query completion time and reducing system paging and fault rates. Expert Cache optimizes the block size for reading large amounts of data into a storage pool, enabling you to cache more retrieved data for your applications at one time. Given Expert Cache’s strengths, which storage pools are good candidates for using this feature? In general, Expert Cache should be used for storage pools that are assigned to the following types of subsystems:
Expert cache should generally not be used for the *INTERACT storage pool (default storage pool for the QINTER subsystem) or any other storage pool that is used by an interactive subsystem. By their nature, interactive subsystems are not designed for processing large amounts of data at one time, and users who do that usually wind up choking the system and getting chewed out by system management. Private Pools: the Right Way to Create and Assign a Fixed Storage Pool to a Subsystem The proper way to create and assign an unshareable fixed-size storage pool to a subsystem is to create a private pool inside that subsystem. Private storage pools are defined within a subsystem description, and they are exclusively used by that subsystem. They have a fixed defined size and activity level that cannot be dynamically changed by the i5, iSeries, or AS/400 performance tuning function. A private storage pool’s memory is taken from total working memory when the subsystem is started and it is returned to working memory when the subsystem is ended. A fixed pool’s Paging Option is automatically set to *FIXED. Setting up a private storage pool is easy. If I wanted to create a fixed private pool for my QBATCH subsystem, here’s how I would do it. 1. I would check to see what storage pool definitions are already created for QBATCH. On the green screen, I could do this by running the Display Subsystem Description command (DSPSBSD) like this: DSPSBSD SBSD(QBATCH) On the menu that appears, I would select option 2, Pool definitions. This would show me all the Pool IDs for the subsystem, as well as which storage pools and activity levels are defined for each Pool ID. On an i5 V5R3 partition, QBATCH might have a Pool ID list that looks like this: Pool Storage Activity ID Size (K) Level 1 *BASE Meaning that QBATCH takes all of its memory from the *BASE storage pool. If I wanted to view my QBATCH storage pools in OpsNav, I would click on the QBATCH subsystem under the Work Management –> Subsystems –> Active Subsystems node. Then I would right-click on the QBATCH job name entry in the right-hand pane and select the Resources tab in order to view which storage pools are currently assigned to my subsystem. But be warned. Viewing storage pool information in OpsNav doesn’t seem to provide as much pool definition information as the green-screen DSPSBSD command does. 2. If I decided that I wanted to change QBATCH’s pool ID 1 assignment to a private pool that had a defined working memory size of 40000 KB and an activity level of 5, I could run the following Change Subsystem Description to perform that configuration: CHGSBSD SBSD(QBATCH) POOLS((1 40000 5)) If I then again take option 2, Pool definitions, from the DSPSBSD command for QBATCH, I would now see that QBATCH’s Pool IDs have changed to the following: Pool Storage Activity ID Size (K) Level 1 40000 5 This new allocation will immediately take effect for any new jobs that start running after the change was made. Existing jobs (including the QBATCH subsystem job) would continue to run out of the *BASE storage pool until those jobs are ended. Whenever QBATCH starts, it will allocate a 40 MB private storage pool from working memory for its own jobs. This private pool is not defined or shown on the WRKSHRPOOL screen, and it’s Expert Cache setting will be set to *FIXED (off). 3. Private pools work great for subsystems that have only one assigned storage pool ID. This task gets slightly trickier (but not impossible) when more than one default pool definition is assigned to a subsystem. Multiple storage pool definitions can be assigned to a single subsystem, and subsystem jobs can be assigned to different storage pools depending on the routing entry that is activated when each new job starts processing in that subsystem. For example, by default the QINTER subsystem has two pool definitions assigned to it: pool 1 and pool 2. Both definitions point to the default *INTERACT storage pool. If I run DSPSBSD over the QINTER subsystem, my storage pool definitions might look something like this: Pool Storage Activity ID Size (K) Level 1 *INTERACT 2 *INTERACT If I wanted to remove *INTERACT from QINTER’s pool definitions and replace it with a fixed private pool that has a defined pool size of 40000 KB and an activity level of 25, I could run the following commands:
CHGSBSD SBSD(QINTER) POOLS((1 40000 25)) The first command creates my new private storage pool for QINTER while the second command removes the second pool definition (pool ID 2) from my subsystem. If I again use DSPSBSD to view my QINTER pool definitions, my pool IDs will now look like this: Pool Storage Activity ID Size (K) Level 1 40000 25 When changing multiple pool definitions or removing a pool definition from a subsystem, I need to keep two issues to keep in mind. First, the subsystem must be inactive when I remove a pool definition. i5/OS will not let me remove a pool definition from an active subsystem because there may be subsystem jobs currently running that are still using that definition. The second pitfall is that the operating system assigns incoming jobs to use specific storage pools by checking the pool ID listed in the subsystem routing entry that is used to start that job. Each subsystem routing entry is coded with one of the pool definition IDs defined for the subsystem so it’s important that if you are going to delete a subsystem pool definition, you check to see whether that definition is referenced in any subsystem routing entry. If an entry uses the soon-to-be deleted definition, be sure to change that routing entry’s pool ID to another pool ID value that will still be active in the subsystem. To review my subsystem routing entries, I can once again run the DSPSBSD command for my target subsystem and select option 7, Routing Entries, to view the pool IDs that each routing entry is using. To change the pool ID on a specific routing entry, I can use the green-screen Change Routing Entry command (CHGRTGE). I was unable to find an equivalent function for changing Routing Entries in OpsNav. And that’s the lowdown on how to create fixed storage pools for a subsystem. Part 2: WRKSYSACT Is Not Necessarily Installed on Everyone’s i5 or iSeries Box After reading last week’s column about quick and dirty ways to find jobs gone wild, several readers wrote in to correct me on two points in the column. First, readers Dale Janus and Dale Fauber asked me why they couldn’t find the WRKSYSACT command that I mentioned in the article on their V5R3 i5 systems. In researching the subject, I found that IBM bundles the Work with System Activity (WRKSYSACT) command in with their Performance Tools–AS/400 product (5722-PT1) in some releases of the operating system. So if you’re looking for WRKSYSACT, check to see if 5722-PT1 is installed because on some operating system versions, you will not be able to run this command unless 5722-PT1 is present on your system. You can view which IBM licensed program products are installed on your system by bringing up the Work with Licensed Programs menu (GO LICPGM) from a green screen and selecting option 10, Display Installed Licensed Programs. The second correction from that article involved how to refresh the system activity data on the WRKSYSACT screen. In the article, I said that you can press the F5=Refresh key to reset your statistics when the only refresh function in this command is the F10=Refresh key. I apologize for the mix-up and thank reader Ernie McCormick for spotting this error for me. On Becoming a Guru While I try to avoid making mistakes, some errors will occasionally sneak through. However, every mistake also gives us an opportunity to broaden our knowledge and find new ways of doing things and discovering new capabilities. After all, nobody would be much of a Four Hundred Guru if we didn’t learn something new every once in a while. About Our Testing Environment All configurations described in this article were tested on an i5 box running i5/OS V5R3. The iSeries Navigator configuration (OpsNav) was tested by using the OpsNav version that comes with iSeries Access for Windows V5R3M0. However, you may notice variations in pre-V5R3 copies of these features, as well as on iSeries and AS/400 machines running OS/400 V4R5 and below. These differences may be due to incremental command improvements that have occurred from release to release. RELATED STORIES |
