Simple C program tunes your system on the fly

The company controller comes back to your department and says, "The system is crawling and none of our batch jobs are running." You respond with " Our AS/400 is undersized. We need a memory upgrade and more DASD." The controller chuckles at your joke, and walks away commanding "See what you can do."

Glad that you have OS/400 release 3.0 installed, you pull up the WRKSYSSTS screen. Immediately, you see the problem -- a high rate of Database and Non-Database page faults. The machine pool has an average of 6 faults per second, *base has 7, and QINTER and QBATCH are also faulting. Command keying over to WRKACTJOB, you see that your operator is doing a restore, the reason the machine pool is overallocated. Adding half a meg to the machine pool will help that. You also see that a month-end job is running in QBATCH that requires an inordinate amount of memory, and that pool could use a couple hundred more K. You also make a mental note to put that batch job in the month-end nightly run. Returning to the WRKSYSSTS screen, you make all these simple changes to the system, press Command 10 to restart statistics and wait.

Those of you who know how to tune your system with the WRKSYSSTS screen are well-acquainted with this scenario; others who are unfamiliar with this may not be aware of how simple it is to tune the system with the WRKSYSSTS screen. I will describe this process in detail as well as provide an alternative method of system tuning.

Online Tuning

The WRKSYSSTS screen displays all the system pools, their sizes, activity levels, and statistical data (See 1). The statistical data that are used in the tuning process are database faults, non- database faults, and wait-to-ineligible. All of these items can be viewed at once by combining the view with Command 21. Based on this data, you can make decisions about what system modifications you need to make to tune your machine. Note that command key 11 toggles WRKSYSSTS to display all three of these on one screen. The release 3.0 version of WRKSYSSTS has two input-capable columns -- pool size and activity level. By modifying pool sizes and activity levels appropriately you can tune your system on-the-fly.

The WRKSYSSTS screen displays all the system pools, their sizes, activity levels, and statistical data (See Figure 1). The statistical data that are used in the tuning process are database faults, non- database faults, and wait-to-ineligible. All of these items can be viewed at once by combining the view with Command 21. Based on this data, you can make decisions about what system modifications you need to make to tune your machine. Note that command key 11 toggles WRKSYSSTS to display all three of these on one screen. The release 3.0 version of WRKSYSSTS has two input-capable columns -- pool size and activity level. By modifying pool sizes and activity levels appropriately you can tune your system on-the-fly.

A couple of odd things about the WRKSYSSTS screen before we move on: first, the activity level of the machine pool 1 cannot be changed and is displayed as all plusses; second, if you try to change the *BASE pool 2 size, the system will ignore the entry and leave the value at what it was before, so to increase or decrease the *BASE pool, you have to decrease or increase one of your other pool sizes.

The statistical data displayed on the WRKSYSSTS screen are per second averages. The average is based on the time passed since you first pulled up the WRKSYSSTS screen, or since you last pressed the Refresh key (Command 10). The "elapsed time" on the WRKSYSSTS screen displays the exact amount of time that has passed since you initially requested WRKSYSSTS or the last refresh.

But there are a number of problems involved with online tuning. First, you have to tune the system during normal processing hours -- remember, lunch hour, backups, and OPNQRYF are examples of nonstandard periods of system use. Second, to appropriately reset pool sizes and activity levels, WRKSYSSTS statistics should be accumulated for five minutes before and after each modification. This consumes a fair amount of time for each tuning session. Third, online tuning works great, but only for the current demand during that tuning session. You have to continually review the WRKSYSSTS screen, and use pool and activity level settings that seem to work best throughout all processing hours.

Dynamic Tuning

What we need is a dynamic method of tuning the system programmatically. A year ago, I spent some time researching this possibility. Rereading the AS/400 Work Management Guide, I discovered that by using the STRPFRMON command, I could accumulate a database of performance statistics. The problem with this is that the minimum time for the statistics to write to the database file is five minutes. This would be impractical for handling those temporary fluctuations in demand -- OPNQRYF, sign-ons, and online searches, to name a few. My next "brainstorm" was to use a facility in QUSRTOOL that put the WRKSYSSTS statistics *PRINT option to a database file. This method however, took up too many resources of its own to be effective.

Release 3.0 of OS/400 provided the solution with the availability of an API. This Application Program Interface allows quick and easy modification of pool sizes and activity levels based on data retrieved from a System/C MI call. This sounds complex and you may not have access to the System/C compiler anyway, but read on. The C program is quite simple, and the decision logic table is not only the basis for the tuning program, but it's also a good reference for online tuning.

Program Overview

The Freestanding/C, IBM's internal name for System/C, program-retrieves pool statistical data from the MATRMD MI call. The call is straightforward, but it does return a complex data structure. The structure is, however, provided in IBM's QFSC library, which makes program creation simple. Another MI call used, WAITTIME, simply stalls the program for a specified time before retrieving pool statistics again. Based on the statistics retrieved and the decisions outlined in the logic table, the QUSCHGPA API call is used to change pool attributes. The API requires only three parameters -- pool number, pool size, and activity level.

Standard Pool Configurations

My decision logic table and the Freestanding/C tuner are based on what has become a standard setup for storage pool configuration (see 2). As always, pool 1 is the machine pool and pool 2 is the base pool (*BASE or star-base). The machine pool is for direct machine functions, and *BASE is used for system transients. The subsystem, QINTER, is pool 3. QINTER has its own separate pool, so interactive job performance is not degraded by batch jobs. The subsystem, QBATCH, is pool 4, and also has its own pool. The activity level for QBATCH is set to one with job queues that are single-threaded. Single-threading batch jobs improve throughput in comparison to multiple-threaded batch pools. The subsystem QSPL is in the last pool defined, and separates writer activity from the other pools. All pools numbered, other than the machine and base pools 1 and 2, are numbered on the WRKSYSSTS screen, based on which subsystems were started first.

My decision logic table and the Freestanding/C tuner are based on what has become a standard setup for storage pool configuration (see Figure 2). As always, pool 1 is the machine pool and pool 2 is the base pool (*BASE or star-base). The machine pool is for direct machine functions, and *BASE is used for system transients. The subsystem, QINTER, is pool 3. QINTER has its own separate pool, so interactive job performance is not degraded by batch jobs. The subsystem, QBATCH, is pool 4, and also has its own pool. The activity level for QBATCH is set to one with job queues that are single-threaded. Single-threading batch jobs improve throughput in comparison to multiple-threaded batch pools. The subsystem QSPL is in the last pool defined, and separates writer activity from the other pools. All pools numbered, other than the machine and base pools 1 and 2, are numbered on the WRKSYSSTS screen, based on which subsystems were started first.

Many sites have also made *BASE the time-slice end pool. This system parameter allows any job that reaches time-slice end to be moved to *BASE. Interactive jobs that do not finish before their time slice is over cause the performance of other interactive jobs to diminish. Typically, there always seems to be one or two programs on a system that should be run in batch or reprogrammed for efficiency. QTSEPOOL will alleviate this problem somewhat.

Basic Tuning Thoughts

To tune your system effectively, you should keep the database and non- database faults, as well as the wait-to-ineligible count, at a minimum. The WRKSYSSTS screen displays the average per second per pool. In general, the total number of faults for all pools should not exceed 16. The machine pool is the most important, and faults should not average more than two. Star-base follows next in order of importance since this is where system transients and time-slice-end jobs run. Faults in here should not exceed 6-8. QBATCH can be a problem since the demand for memory in here varies from batch job to batch job. Often this pool may run idle, wasting memory. QINTER is typically where user complaints originate, and here I try to keep faults below 6 to 8.

One tuning method often overlooked is the modification of activity levels. A pool's activity level specifies the total number of jobs allowed in that pool's allocated main storage at the same time. QINTER and *BASE are usually the pools where activity levels are tweaked. An activity level cannot be set for the machine pool, and the batch pool's activity level should be set to 1 with the batch job's purge option set to *NO. For both QINTER and *BASE jobs the activity level should be set such that 90 percent of the active jobs complete each task before its time-slice ends. I control this by keeping the Wait-to-Ineligible on the WRKSYSSTS display at be less than .1. However, if the Wait-to-Ineligible is too far below .1, then you probably have the activity level set too low for the pool size.

To tune the activity level online with WRKSYSSTS, simply decrease it until the Wait-to-Ineligible shows zero, and then slowly increase it until .1 appears.

Outside of increasing main storage, disk, smoothing workloads, and redesigning applications, reallocating pool sizes and changing activity levels are the easiest methods of tuning your system. This is exactly how we improve/decrease fault rates in storage pools. With the WRKSYSSTS screen, you can simply modify the pool size or activity level, press Enter and wait, or let my FSC/Tuner do it all for you, all day long.

Decision Logic Table

Sizing pools is where all the confusion occurs. Basically though, you just have to "beg from Peter to pay Paul." But which pool is Peter and which is Paul? I have developed a decision logic table to ease this confusion with system tuning. I then used the table as a template for my FSC/Tuner program. The decisions were developed mostly from IBM's Work Management Guide, but also from firsthand experience. Tuning the system with either the WRKSYSSTS screen or an FSC program is easy if you follow my table.

I used the following generalizations when I developed the decision logic table for the system tuning program:

o The machine pool is the most important pool, so faults should be kept at a minimum.

o *BASE faults should be low, but since demand fluctuates, you should use only what memory you need to keep faults low.

o QBATCH should also only get what memory it needs.

o QINTER gets all memory that was overallocated to other pools; however, this is where we go to borrow memory for other pools.

o Qspl runs fine with little storage, but if faults get too high, the writers will print extremely slowly.

o Only one system attribute can be modified at a time since it may affect faults in other pools.

o Priority of conditions is in descending order of significance. The most important changes are made first.

The idea of using as little storage as possible in the machine, base, batch, and spool pools works great for the dynamic tuning program. This does, however, cause a problem for online WRKSYSSTS tuning. For this manual method, you need to set pool sizes to what generally works best over the course of the day. This means that memory, at times, is overallocated to some pools and underallocated to other pools. In dynamic tuning, pool sizes are constantly reviewed and modified at specified intervals. My FSC/Tuner program uses tuning intervals of 10 seconds. With this time interval, short fluctuations in demand will be handled dynamically.

FSC/Tuner Specifics

The logic of the C tuning program is quite simple, and basically just follows the decision logic table. The only area of complexity is in the data structure retrieved from the Materialize Resource Management Data MI call (MATRMD). IBM does provide the data structure specification in its QFSC library, though. I did, however, find an error in IBM's data structure source. To fix the error I copied the structure into the FSC program and corrected the faulty code annotated with the appropriate comments. I then deleted any extraneous information in the structure to shorten the program listing. Also, the length of the data structure names was so long that I opted to use the preprocessor #define to simplify and shorten the reference to pool statistical fields.

The FSC/Tuner program, very simply, sets the interval time , retrieves the beginning pool statistics, and begins a neverending loop. The loop starts with a 10-second wait, using the simple MI call WAITTIME. After the pause, another set of pool statistics is retrieved. Pool statistics are kept by the system as short (2 byte) binary numbers that increment for every fault and wait-to-ineligible occurrence. To get per-second averages, you need to subtract the last pool statistics retrieved from the most current and divide by the seconds that have transpired. The resulting fault and wait-to-ineligible averages are then compared and modified by a series of if/else statements. These lines of code are basically a rewrite of the decision logic table.

I created a subsystem explicitly for tuning so that I could easily start and end the FSC/Tuner program. I then added an auto-start job with a new job description that requested a router class of priority 19 (shown in 3). As a general rule, you should never have multiple jobs running in any pool with different run priorities. But, the FSC/Tuner program takes little resources and should have the top priority of user jobs. The job description has logging turned off to stop the generation of huge job logs. Still though, the tuning API sends a message to the history log and the operator's message queue for every modification. You should be using release 3.0 Operator Assistant's cleanup function to keep these from growing excessively.

I created a subsystem explicitly for tuning so that I could easily start and end the FSC/Tuner program. I then added an auto-start job with a new job description that requested a router class of priority 19 (shown in Figure 3). As a general rule, you should never have multiple jobs running in any pool with different run priorities. But, the FSC/Tuner program takes little resources and should have the top priority of user jobs. The job description has logging turned off to stop the generation of huge job logs. Still though, the tuning API sends a message to the history log and the operator's message queue for every modification. You should be using release 3.0 Operator Assistant's cleanup function to keep these from growing excessively.

I have a timed job start the FSC/Tuner subsystem at 8:00 am and another timed job end it at 5:00 pm before nightly processing. Like many shops, our AS/400 has little or no interactive use after 5:00 pm so the rules above all change. Leave a couple of megs in QINTER, put most of the system memory in QBATCH, and beef up the machine and base pools for the save commands.

I can think of 100 improvements to the FSC/Tuner program -- so there must be 1,000. The first thing that comes to mind is that you might have to rethink the idea of using a limited number of pools. With the dynamic tuner, unused pools would shrink down to a minimal size. Modifying the FSC/Tuner program for more pools would be straightforward. Another thought is to pass the currently hard-coded minimum and maximum pool sizes as parameters. One other idea is to accumulate a history of the FSC/Tuner-retrieved statistics and resulting modifications to a database file. Finally, I wrote the program for ease of comprehension. But this is one example of a program that should be designed for speed since it runs every 10 seconds.

Try tuning your system with my Decision Logic Table and your WRKSYSSTS screen. If you haven't attempted this yet, you will be pleased at the improvements. After a while you'll see the need for the dynamic tuner. If you do not have the System/C compiler, perhaps your IBM branch office or VAR will compile the tuner for you.

IBM has made a commitment to making more APIs available, most of which will require System/C to use. With this awareness, and knowing that more free System/C code will become available on BBSs like Midrange Computing's, you may even consider buying System/C.

Systems Tuning Utility

Figure 1 WRKSYSSTS screen

 Figure 1: WRKSYSSTS Screen Work with System Status YOURMACH 04/27/91 15:02:20 % CPU used . . . : 7.9 System aux stg . . . . : 2202 M Elapsed time . . . : 00:00:14 % aux stg used . . . . : 77.3965 Jobs in system . . : 266 Total aux stg . . . . : 2202 M % perm addresses . : 2.704 Current unprotect used . : 238 M % temp addresses . : 1.112 Maximum unprotect . . . : 279 M Sys Pool Rsrv Max -----DB----- ---Non-DB--- Act- Wait- Act- Pool Size K Size K Act Fault Pages Fault Pages Wait Inel Inel 1 __3000 2377 +++ .0 .0 .4 .9 .0 .0 .0 2 __1352 0 __5 .0 .0 .0 .0 .0 .0 .0 3 _10000 0 _20 .0 .0 4.6 8.6 4.0 .0 .0 4 __1900 0 __1 .0 .0 .0 .0 .0 .0 .0 5 ___132 0 __4 .0 .0 .0 .0 .0 .0 .0 ===>________________________________________________________________________ F11=Display pool data F21=Expand views 
 
 Systems Tuning Utility
 
 Figure 2 FSC/Tuner C code
 
 /* */ /* Warning! */ /* */ /* This code is not meant to execute as is. */ /* */ /* This code should not be used without carefully */ /* reading the article "System Tuning Utility," */ /* found on page 39 of the June 1991 issue of */ /* "Midrange Computing" magazine. You need to also */ /* read the IBM "Work Managemet Guide" (SC21-8078) */ /* and determine what tuning values are appropriate */ /* for your AS/400. */ /* */ /* After careful consideration the code in this */ /* program should be adjusted for the machine on */ /* which it will run. */ /* */ /* Begin of #include "QFSC/H/MIRSC" replacement code */ #include  typedef struct _MATRMD09_T { /* Individual main storage pool information */ int Size; /* pool size */ int Maint; /* pool maintenance */ int DB_Int; /* database interrupts */ int NDB_Int; /* nondatabase interrupts*/ int DB_Trans; /* database transfer */ int NDB_Trans; /* nondatabase transfer */ char reserved 8 ; } _MATRMD09_T; typedef _Packed struct _MATRMD_0x09_Template_T { /* Main storage pool information 0x09 */ short Min_Trans; /* Minimum transfer size */ short Max_Pools; /* Maximum Number of pools */ short Cur_Pools; /* Current Number of pools */ int Main_Stor; /* Main storage size */ char reserved 2 ; int Pool1_Min; /* Pool #1 minimum size */ /* _MATRMD09_T Pools;*/ /* Ind. Pool information */ _MATRMD09_T Pools 15 ; } _MATRMD_0x09_Template_T; typedef struct _MATRMD0A_T { /* Individual MPL class information */ short Max_MPL; /* Maximum MPL */ short Inel; /* Ineligible event thres*/ short Cur_MPL; /* Current MPL */ short Num_Inel; /* Number ineligible proc*/ short Num_Procs; /* # of procs in class */ short Active_To_Inel; /* Transitions */ short Active_To_MI; /* Transitions */ short MI_To_Inel; /* Transitions */ } _MATRMD0A_T; typedef struct _MATRMD_0x0A_Template_T { /* Multiprogramming level control 0x0A */ short Max_Class; /* Max MPL Class Number */ short Cur_Class; /* Current MPL Class # */ short Max_MPL; /* Maximum MPL */ short Inel; /* Ineligible event thres*/ short Cur_MPL; /* Current MPL */ short Num_Inel; /* Number ineligible proc*/ char reserved 4 ; /* _MATRMD0A_T _MATRMD0A_Classes;*/ /* Ind. Class information*/ _MATRMD0A_T _MATRMD0A_Classes 15 ; } _MATRMD_0x0A_Template_T; typedef struct _MATRMD0C_T { /* Individual Reserved Pool Information */ int Size; /* Pool Size */ int Machine; /* Machine portion o pool*/ short Load_Dump; /* # of load/dump session*/ char reserved 6 ; } _MATRMD0C_T; typedef struct _MATRMD_0x0C_Template_T { /* Machine Reserved Storge Pool Info 0x0C */ short Num_Pools; /* Current # of pools */ char reserved 6 ; _MATRMD0C_T _MATRMD0C_Pools 16 ; /* Ind. pool information*/ } _MATRMD_0x0C_Template_T; typedef struct _MATRMD_Template_T { /* Main MATRMD tempalte */ int Template_Size; /* Provided for materialize */ int Bytes_Used; /* bytes used by materialize*/ _MI_Time Time_of_Day; /* Time of day value */ union { _MATRMD_0x09_Template_T Main_Pool; _MATRMD_0x0A_Template_T MPL_Control; _MATRMD_0x0C_Template_T Reserved_Pool; } _MATRMD_Data; } _MATRMD_Template_T; /* Constants for the _Matrmd call */ #define _MATRMD_Main_Pool 0x09 #define _MATRMD_MPL_Control 0x0A #define _MATRMD_Reserved_Pool 0x0C /* Materialize Resource Management Data */ void matrmd(_MATRMD_Template_T *, void *Control); void __MImatrmd(_MATRMD_Template_T *, void *Control); /* End of "QFSC/H/MIRSR" replacement code */ #include  #include  #include  #include  #include  #include  #define CP Cur_Pool._MATRMD_Data.Main_Pool.Pools #define LP Last_Pool._MATRMD_Data.Main_Pool.Pools #define CMPL Cur_MPL._MATRMD_Data.MPL_Control._MATRMD0A_Classes #define LMPL Last_MPL._MATRMD_Data.MPL_Control._MATRMD0A_Classes #define RSV Rsv_Pool._MATRMD_Data.Reserved_Pool._MATRMD0C_Pools /* Begin of Machine specific defines */ #define Min_Mch 3000 /* System defined and available on WRKSYSSTS */ #define Min_Bas 300 #define Max_Bch 100 /* arbitrary ceiling */ #define Max_Bas 3000 /* " " */ #define Max_Spl 300 /* should never need more than 300 */ #define Max_Int_Atv /* approximately the total No. of signons */ /* End of machine specific defines */ enum { Mach, Base, Qinter, Qbatch, Qspl }; /* 0,1,2,3,& 4 */ _MATRMD_Template_T Cur_Pool, Last_Pool, Cur_MPL, Last_MPL, Rsv_Pool; unsigned char Control 8 ; /* Matrmd Option selection type field */ _MI_Time My_Time; main() { int hour, min, sec, hund; int Bch_Siz, Int_Siz, Mch_Siz, Bas_Siz, Spl_Siz; int Bch_Rsv, Int_Rsv, Mch_Rsv, Bas_Rsv, Spl_Rsv; short Options = _Wait_Normal; short Int_Atv = 20, Spl_Atv = 4; /* Activity Levels */ float Bch_flt, Int_flt, Mch_flt, Bas_flt, Spl_flt, Act2Wait; /* set binary MI time to 10 seconds */ sec = 10; mitime ( &My_Time, hour, min, sec, hund); /* set data structure size for corresponding Matrmd call */ Cur_Pool.Template_Size = sizeof(_MATRMD_Template_T); Cur_MPL.Template_Size = sizeof(_MATRMD_Template_T); Rsv_Pool.Template_Size = sizeof(_MATRMD_Template_T); /* retrieve Pool fault Statisctics */ Control 0 = _MATRMD_Main_Pool; matrmd( &Cur_Pool, Control); Last_Pool = Cur_Pool; /* save retrieved statistics */ /* retrieve Wait to ineligible statistics */ Control 0 = _MATRMD_MPL_Control; matrmd( &Cur_MPL, Control); Last_MPL = Cur_MPL; /* save last Wait-to-Ineligible stats */ /* infinite loop of retrieving statistics and changes attributes*/ while (1) { waittime( &My_Time, Options); /* wait 10 seconds */ Control 0 = _MATRMD_Main_Pool; matrmd( &Cur_Pool, Control); Control 0 = _MATRMD_MPL_Control; matrmd( &Cur_MPL, Control); /* get machine or system reserved pool amount for each pool we can't drop a pool's size below that amount */ Control 0 = _MATRMD_Reserved_Pool; matrmd( &Rsv_Pool, Control); Bch_flt= (float) (CP Qbatch .DB_Int - LP Qbatch .DB_Int) /(float) sec; Bch_flt+=(float) (CP Qbatch .NDB_Int - LP Qbatch .NDB_Int) /(float) sec; Int_flt= (float) (CP Qinter .DB_Int - LP Qinter .DB_Int) /(float) sec; Int_flt+=(float) (CP Qinter .NDB_Int - LP Qinter .NDB_Int) /(float) sec; Bas_flt= (float) (CP Base .DB_Int - LP Base .DB_Int) /(float) sec; Bas_flt+=(float) (CP Base .NDB_Int - LP Base .NDB_Int) /(float) sec; Mch_flt= (float) (CP Mach .DB_Int - LP Mach .DB_Int) /(float) sec; Mch_flt+=(float) (CP Mach .NDB_Int - LP Mach .NDB_Int) /(float) sec; Spl_flt= (float) (CP Qspl .DB_Int - LP Qspl .DB_Int) /(float) sec; Spl_flt+=(float) (CP Qspl .NDB_Int - LP Qspl .NDB_Int) /(float) sec; /* Sizes are reflected in 512 increments. To get pool size in K or thousands we simply divide by 2 */ Bch_Siz = RSV Qbatch .Size / 2; Int_Siz = RSV Qinter .Size / 2; Mch_Siz = RSV Mach .Size / 2; Bas_Siz = RSV Base .Size / 2; Spl_Siz = RSV Qspl .Size / 2; /* set pool reserved sizes */ Bch_Rsv = RSV Qbatch .Machine / 2; Int_Rsv = RSV Qinter .Machine / 2; Mch_Rsv = RSV Mach .Machine / 2; Bas_Rsv = RSV Base .Machine / 2; Spl_Rsv = RSV Qspl .Machine / 2; if (Mch_flt > 4) { QUSCHGPA ( Qinter+1, Int_Siz - 200, Int_Atv); QUSCHGPA ( Mach+1, Mch_Siz + 200, -1); } else if (Mch_flt < .4 && Mch_Siz - 200 > Min_Mch) { QUSCHGPA ( Mach+1, Mch_Siz - 200, -1); QUSCHGPA ( Qinter+1, Int_Siz + 200, Int_Atv); } else if (Bas_flt > 5 && Int_flt < 6 && Bas_Siz < Max_Bas) { QUSCHGPA ( Qinter+1, Int_Siz - 200, Int_Atv); } else if (Bas_flt < 1 && Bas_Siz - Bas_Rsv > Min_Bas) { QUSCHGPA ( Qinter+1, Int_Siz + 200, Int_Atv); } else if (Bch_flt > 5 && Bch_Siz < Max_Bch) { QUSCHGPA ( Qinter+1, Int_Siz - 200, Int_Atv); QUSCHGPA ( Qbatch+1, Bch_Siz + 200, 1); } else if (Bch_flt < .9 && Bch_Siz - Bch_Rsv >= 232) { QUSCHGPA ( Qbatch+1,Bch_Siz - 200, 1); QUSCHGPA ( Qinter+1, Int_Siz + 200, Int_Atv); } else if (Bch_flt < .9 && Bch_Siz > 32 && Bch_Rsv < 32) { QUSCHGPA ( Qbatch+1, 32, 1); QUSCHGPA ( Qinter+1, Int_Siz + Bch_Siz - 32, Int_Atv); } else Act2Wait =(float) (CMPL Qinter .Active_To_MI - CMPL Qinter .Active_To_MI) / (float) sec; /* total number of terminals */ if (Act2Wait < .05 && Int_Atv < Max_Int_Atv) { Int_Atv++; QUSCHGPA ( Qinter+1, Int_Siz , Int_Atv); } else if (Int_flt > 6 && Act2Wait >= .1 ) { Int_Atv--; QUSCHGPA ( Qinter+1, Int_Siz, Int_Atv); } else if (Spl_flt > 4 && Spl_Siz < Max_Spl) { QUSCHGPA ( Qinter+1, Int_Siz - 32, Int_Atv); QUSCHGPA ( Qspl+1,Spl_Siz + 32, Spl_Atv); } else if (Spl_flt < .9 && Spl_Siz - Spl_Rsv > 64) { QUSCHGPA ( Qspl+1,Spl_Siz - 32, Spl_Atv); QUSCHGPA ( Qinter+1, Int_Siz + 32, Int_Atv); } else if (Spl_flt < .9 && Spl_Siz > 32 && Spl_Rsv < 32) { QUSCHGPA ( Qspl+1, 32, Spl_Atv); QUSCHGPA ( Qinter+1, Int_Siz + 32, Int_Atv); } else Act2Wait =(float) (CMPL Qspl .Active_To_MI - CMPL Qspl .Active_To_MI) / (float) sec; if (Act2Wait < .05 && Spl_Atv < 4) { Spl_Atv++; QUSCHGPA ( Qspl+1, Spl_Siz , Spl_Atv); } else if (Act2Wait > .1 && Spl_Atv > 1) { Spl_Atv--; QUSCHGPA ( Qspl+1, Spl_Siz , Spl_Atv); } Last_Pool = Cur_Pool; Last_MPL = Cur_MPL; } /* while (1) */ } 
 
 Systems Tuning Utility
 
 Figure 3 Adding an auto-start job entry
 
 Figure 3: Adding an Auto-Start Job Entry CRTSBSD SBSD(YOURLIB/FSCTUNER) + POOLS((2 *BASE)) CRTCLS CLS(NINETEEN) RUNPTY(19) TIMESLICE(2000) ADDRTGE SBSD(YOURLIB/FSCTUNER) + SEQNBR(10) CMPVAL(NINETEEN) + PGM(QSYS/QCMD) CRTJOBD JOBD(YOURLIB/FSCTUNER) + JOBQ(QINTER) RTGDTA(NINETEEN) + RQSDTA(call yourlib/fsctuner) + LOG((4 00 *NOLIST) LOGCLPGM(*NO) ADDAJE SBSD(FSCTUNER) JOB(FSCTUNER) JOBD(YOURLIB/FSCTUNER) 
 
 Systems Tuning Utility
 
 Figure 4 Decision logic table
 
 Figure 4: Decision Logic Table Fault Conditions A B C D E F G H I J Constraints ------------------------------------------------------- Mach Pool > 4 * * None Mach Poll < 4 * * Mach Pool Size > Min *BASE > 5 * QINTER < 6 & Base < Max *BASE < 1 * Batch Size > Minimum QBATCH > 5 * * Batch Size < Minimum QBATCH < 1 * * Batch Size > 32 QINTER >6 * Activity Level > 1 QINTER Wait2Inel > .05 * Actv Lvl < Tot# sign-on Spool > 4 * * Spool Size < Maximum Spool < 1 * * Spool Size > 32 Spool Wait2Inel < .05 * Actv LvL < Tot# Writers Spool Wait2Inel > 1 * Activity Lvl > 1 A = Reduce QINTER B = Reduce QBATCH C = Reduce Machine Pool D = Reduce QSPL E = Increase QINTER F = Increase QBATCH G = Increase Machine Pool H = Increase QSPL I = Increase Activity Level J = Decrease Activity Level Qualifications: - Conditions are in order of importance. - QINTER gets all storage that was overallocated to other pools. - Minimums and maximums are machine specific. - 32 is the minimum pool size for other that Mach and *BASE. - Fault and Wait2Inel condition numbers may be modified.based on what works best for each machine. 

Don Denoncourt is a freelance consultant. He can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..

---

MC Press books written by Don Denoncourt available now on the MC Press Bookstore.

		Java Application Strategies for iSeries and AS/400 Explore the realities of using Java to develop real-world OS/400 applications. List Price $89.00 Now On Sale

Also Read

TD/OMS and Gravity “Milestone 1” Enhancements Streamline Efficiency and Advance Application Development Potential for Re...

Now Let’s Consider Vendor Maintenance

Know Where Your Maintenance Stands