Jane is the lead programmer on a team supporting an order entry application on the AS/400. The application currently supports about 200 telephone operators and, if business continues to grow, may support another 50 within the next six months. Unfortunately, the AS/400 is already experiencing performance problems and Jane has been assigned the task of improving the situation.

The first thing she does, of course, is get some objective measurements. Figure 1 shows the results. As the measurements indicate, the application performs well when the number of users is not too high, but after a certain number of users have logged on, the response time starts going up. After about 160 users, the AS/400 starts huffing and puffing. At 180, the response time really tanks. The order entry application is huge
and—because the operators handle many different types of calls—has a lot of functionality.

Jane determines that the maximum response time acceptable to the users is one second. This means that without major changes to the application or a hardware upgrade, she can currently support between 60 and 80 users. Yet she already has 200 users and is expecting 50 more within the next few months.

Jane does some additional research and finds out that the average “think time” is 20 seconds. That is how long the users spend before each press of the Enter key, engaging in such activities as talking to a customer or keying in data. If the AS/400 could process each request in one second, this would mean that only about 5 percent of the users who are logged on actually require resources from the AS/400 at any given time. Normally, this wouldn’t be a problem; however, once available memory becomes full, the AS/400 has to spend more time swapping in and out. In addition, as the number of jobs increases, so does the number of open files, which, in turn, increases the load on the system.

She takes a long look at the application. The different functions are coded as separate programs, and, in order to avoid file opens and closes, each program returns with the LR indicator off. This process leaves programs in memory with the files open. Jane has the programmers make a simple change to the programs to turn LR on before returning, an action that clears the program from memory and closes the files. However, each time the user requests that function again, the program has to be loaded and the files reopened, which takes time. As the number of users increase, so does the time required. The net result is no improvement.

Jane starts thinking about an upgrade.

Something Less Drastic

But then she has an idea. All of the users are running the same application. She moves the processing component of the application entirely to batch, where it runs as a server job. Because all of the components of the application are separate, callable modules, this is pretty easy to do. The interactive job, which is now relatively small, simply collects the data from the user and sends it to the batch server job, which processes the request and sends back the results. Each batch job needs to process only one request per second, so she needs only 20 batch jobs running. The impact on the system is the same that it would be if only 20 users were signed on. Her problem is solved.

Jane finds some other benefits as well. Because the interactive program is small and is only opening a workstation file, user logon is quick and painless, which means that a user will be more willing to log off for breaks. By increasing or decreasing the number of active batch jobs, she is able to tune the AS/400. If there is a sudden burst of activity she can kick up the number of batch jobs for a while. And although she avoids it, if she must replace a module during the day, it is no longer necessary to get everybody off. She simply has to end the batch server jobs, replace the module, and restart them. The users might be delayed a few seconds, but they are otherwise not affected.

A Batch Server Template

This story illustrates a technique that I have been using with good results for years. If you have an application like this that is used by many interactive users throughout the day, it could be a good candidate for the batch server model. In the remainder of this article, I describe some program templates that you can use to put the batch server process to work for you on your AS/400. You can download these templates from the Web at www.midrangecomputing.com/mc. The download contains compilable code for a working server and a client program to communicate with the servers.

Figure 2 (page 103) shows pseudocode for BCHSVR1, a program you can use to control the number of active batch server jobs. The program counts the number of batch server jobs that are currently active. It then either submits additional jobs or sends data queue entries to end existing jobs. Each job has a different name. All server jobs get submitted to the same job queue, so you must use a job queue that allows for a large number (or *NOMAX) for maximum number of jobs (MAXACT). To run this program, use the Control Batch Server (CTLBCHSVR) command, specifying the number of desired server jobs in the first (and only) parameter.

Figure 3 (page 103) shows the logic of BCHSVR2, the driver program for the batch server job itself. A separate copy of this program runs in each server job submitted by BCHSVR1. At the outset, BCHSVR2 allocates a data area with the same name as the job. This is a common technique to indicate that a job is active. I like to put all the data areas in a separate library because they don’t need to be backed up. If you desire, the library can be cleared during the IPL or nightly batch processing.

BCHSVR2 communicates with the interactive program by way of data queues. There are two separate data queues: one for incoming data and one for outgoing data. Because OS/400 doesn’t reuse deleted data queue entries, these data queues should be deleted and re-created on a regular basis. The outgoing data queue is keyed by a transaction ID, which is a unique value generated by the interactive program requesting the data. The requesting program looks for this same key value to retrieve the correct data, instead of retrieving data from another requestor. I like to put the data queues in the same library as the data areas.

Each of the batch server jobs stays in a loop waiting for requests to come in on the data queue (a special value of *EOJ indicates it’s time to end). Program BCHSVR2 breaks the data into fields, calls the program to process the data, concatenates the results, and

sends them to the keyed data queue. The interactive program receives the results and displays them to the user. I also log the time and program ID to a message queue. Taking this step makes it easier to track current activity and adjust the number of required server jobs.

Figure 4 (page 103) contains pseudocode for program BCHSRV3, which moves data between the calling program and the server by way of data queues. This program takes care of enqueuing and dequeuing data, which means the programmer need only code a simple CALL command in client programs. (Note that BCHSRV3 will timeout after 60 seconds with a message to the system operator if it doesn’t hear back from a server job. This keeps the job from hanging if the batch server jobs have not been started.)

Getting Started

If you are having performance problems in your shop, then it may be time to break up your application. These batch server utilities make it an easy thing to do.

Download the example code from the Midrange Computing Web site at www.midrangecomputing.com/mc. All the code is in one text file, but you will be able to divide it into separate members by following the instructions. Put all members in a source physical file called BCHSVR in library BCHSVRLIB. Compile and run the INSTALL program. Start the servers, call the client program, and you’re in business.

Number Response of Users Time 20 0.7 40 0.7 60 0.9 80 1.1 100 1.3

Number Response of Users Time 120 1.4 140 2.1 160 3.2 180 4.8 200 7.9

Figure 1: As users are added to the order entry application, response time becomes increasingly slow.

Input parameter: desired number of active batch server jobs
Create data queues if they don’t exist.
Determine how many batch server jobs are currently active.
Case
1. the number of active jobs > the desired number of jobs,
terminate some of the active jobs
2. the number of active jobs < the desired number of jobs
submit more batch jobs
end case

Figure 2: A single program is used to increase or decrease the number of active server jobs.

Indicate that the current job is active by allocating a data area
with the same name.

Create the data area if necessary

Attempt to allocate the data area.

If unable to allocate, exit program

Loop

Receive a message from the incoming data queue

If message is *EOJ, exit program

Log start of processing

Call the program to process the data

Log end of processing

Send the results back to the requestor by placing them on the

outgoing data queue
End loop

Figure 3: Each batch server job serves as a mediator between client programs and those that process data.

Copy data from input parameters to the data structure that will be sent to the data queue.
Build a unique key by combining the job number and current time.
Log the start of the request.
Send data to a batch server job via a FIFO data queue.
Wait 60 seconds to receive data from a batch server via a keyed data queue.
Log the end of the request.
If there was no response from the server within 60 seconds,

then notify system operator

else return the data to the calling program through parameters

Figure 4: Client programs that need to communicate with a batch server simply call an API.