The problem
A shop is exceeding its allotment of interactive processing power on its iSeries and the iSeries arbiter is kicking in and bringing the system to its knees. Understaffed and budget-constrained IT shops cannot afford the large charge to increase their interactive processing power nor can they afford to rewrite their applications to be client/server. Management is adding more users to the system, users are complaining, and it's up to you to get this problem solved ASAP. What can you do?
I have a friend that was in just this situation recently and asked me for some help on how to solve this problem. The solution is outlined here. I suspect his experience is fairly typical of those in this situation. In a nutshell, his solution was to leave most of his applications intact but pull out the parts of the program that were causing the arbiter to kick in and make those portions client/server. He needed a process that was repeatable, fast, easy to use and worked for a variety of functions. He also did this using standard iSeries functions that any programmer would be familiar with.
The solution
In these periods of slowdown, my friend's first step was to find his biggest problem applications. He did this by using WRKACTJOB and looking for several "red flags" about his interactive jobs. These were interactive jobs that stayed in a run state for more than a second or two and/or jobs that that had a high number in the CPU usage, interactive response time or auxiliary IO fields.
He then displayed the job and looked at the call stack to see what programs were being run. From there, he went on to find the parts of the program that were kicking in the arbiter. What he found was that most of his applications were pretty efficient, but parts of the application used a lot of CPU because the program was doing some complex calculations, had to read a lot of records for a summary, etc.
Those portions were critical to the operation of the program, so what he did was take those subroutines and make them into separate programs, along with any needed parms to run those subroutines as stand-alone programs. From his interactive program, he called a client/server process that would do the heavy work in batch and then return or create what was needed for his interactive program to continue processing. In a little more than a week, he solved his problem and he also noticed that some programs actually run faster than they did when they were all in one program.
Here is a high level overview of how this works:
- In your legacy program, call BCS001C to ensure the server process is started and to retrieve the names of your job specific data queues.
- Fill data structure BCSDS with your parm data. That includes the program to call in batch, any parms and the names of your data queues retrieved earlier.
- Send your data queue entry to the batch process.
- Receive your data queue entry, populate any variables and continue processing in your interactive program.
Here are more details on the individual programs, which can each be downloaded via the hyperlinks. Once these programs are setup, they will not change for any of your programs. You will need to make some minor changes to BCS001C and BCS002C to match the preferences of your shop.
Program BCS001C -– Ensures the client/server process is running, and if it is returns the name of the data queues that this job will use to communicate with it. In this program check the library, jobq and job description used in the submit job to match your preferences. The jobq should be capable of running multiple jobs at once, since any interactive job will have a corresponding server job.
Program BSC002C –- Batch/Server portion of this process. In this program check the library that you want your data queues to reside. This program creates two temporary data queues that are tied to your job. The first data queue is used to send information to the server portion, and the second data queue receives data from the server portion to your interactive job. It calls programs BCS002R and BCS003C.
BCS002R -– Calls and runs the batch portion of the job. It uses data structure BCSDS to pass the parms and call your server programs.
Program BCS003C -- Checks to see if the interactive user is still there. If it's not, it sends a parameter back to the calling program to do clean up and end the job. This program was retrieved from the Search400.com Web site and was supplied by Search400.com member Carolyn Kelly from Volex Inc. I made only a very small change to it to adapt it to our process, and it has worked flawlessly. Good job, Carolyn.
To illustrate how simple this process really is, I also included an example application called Legacy. It shows the basic parts that you would need to add to your program, and it demonstrates the speed of this process. The parts of this demo application are as follows:
---------------------------
About the author: Tim is vice president of Technical Services at Interlink Technologies in Maumee, Ohio, where he serves as chief architect for their warehouse management system. He has worked in the banking, insurance, healthcare and distribution industries in various positions, including programmer/analyst, systems analyst and DP manager. Tim has worked on IBM midrange platforms since 1983.
==================================
MORE INFORMATION
==================================
- Slow iSeries response time. What's going on?
This user has an iSeries 820 with V5R1 OS/400. He has been getting complaints from his users regarding slow response times. When this randomly happens, the iSeries becomes erratic and even becomes slower then his earlier 500 model. Why is this happening? Search400.com expert Jim Mason suspects the "interactive governor" is kicking in.
- Use CPU utilization guideline values to monitor high-priority (interactive) jobs
Don't wait until your system slows to a crawl before dealing with performance issues. By monitoring response times for critical applications, you can get warnings in advance of any problems.
- Can you still afford 5250?
Looking at the iSeries today, it's not clear how much longer companies can afford to run 5250 applications if they invest in new iSeries computers announced earlier this year. IBM has changed the packaging of software and features once again, and it's no longer a simple answer that a new iSeries server automatically offers better price/performance than an old one.
