For the faster AS/400 processors (B60 and above), reducing the interactive timeslice is a quick change that may improve performance on your system.
IBM recommends in the Work Management Guide that the timeslice value should be set so that about 90% of the transactions can complete within that time interval. Unfortunately, the guide does not explain why this should be so, or how to accomplish the task.
Put another way, IBM is recommending that you let 10% of your interactive transactions reach timeslice end. First, the assumption being made is that about 10% of your interactive transactions are atypical in some way. The usual culprit is batch-type work occurring in the interactive subsystem. Therefore, if on the faster AS/400s all your transactions are being completed during the default timeslice, the only way to achieve that 90% to 10% mix is to reduce the timeslice.
Since the faster AS/400 CPUs can essentially do more work in less time, the default timeslice value of 2000 for interactive work (QINTER class) could allow the atypical long-running transactions to cause the others to be unduly delayed. By reducing the timeslice, you can lessen the impact of CPU hogs, especially during peak load conditions. The reduced timeslice will allow the CPU to process more jobs in a given period of time.
During job creation on the AS/400, the job class (*CLS) object specified in the subsystem description is referenced for the timeslice value. This value defines the maximum CPU time in milliseconds that a job can have after it comes out of a long wait.
Interactive jobs routinely go to long waits when waiting for workstation input. Batch jobs typically never go to long wait. Therefore, the example given here will be reducing the timeslice of QINTER. QINTER is the name of the default interactive class and subsystem description supplied by IBM.
First, observe response times during peak load or near-peak load conditions. Second, print WRKACTJOB (Work With Active Job) reports, paying special attention to the jobs that have a plus (+) after their run priority. This indicates jobs that were not able to complete their transactions during their timeslice. OS/400 has slightly reduced their priority (by 1/128) so that other work may complete. Hence, you will see 20+ as the run priority for these jobs. Also, print WRKSYSSTS (Work With System Status) reports, paying special attention to the transition data.
These reports will serve as your benchmark. You must document the current status of your system before you attempt any changes; otherwise you will not know if your changes were successful. Additionally, you can start the performance monitor (STRPFRMON) if you are comfortable interpreting the output of that utility.
All users in QINTER must sign off. End subsystem QINTER. From the console, enter:
Rename the QINTER *CLS object QINTERBK:
RNMOBJ OBJ(QINTER) TYPE(*CLS) NAME(QINTERBK)
Create a new class called QINTER to replace the original:
CRTCLS QINTER TIMESLICE(nnnnnnn) RUNPTY(20) +
TEXT('Interactive subsystem class')
where the timeslice parameter is a value from 1 to 9999999.
Start the QINTER subsystem:
Monitor the results.
As an example, my company's B60 currently uses a timeslice of 1200 for all interactive users.
Try reducing the timeslice 200 milliseconds at a time and observe interactive response times during peak load conditions. Monitor WRKACTJOB making sure that the 20+ jobs are not increasing. Monitor WRKSYSSTS observing that the active-wait and wait-ineligible counts do not significantly increase. Repeat the process until you arrive at an optimum timeslice value.
Steven Kontos Woodbury, New York