Can’t I Just Upgrade?

Can’t I Just Upgrade?
You may be thinking, "This all sounds fine, but what must I do to implement concurrent job execution of the same job? It’s probably going to take some work; can’t I just upgrade the hardware?"
A proper hardware upgrade can usually provide real improvement in interactive and message-based processing without a lot of time and people investment on your part. This is the AS/400 n-way processors’ greatest benefit. If you want to increase the number of workstation transactions on your system but you’re currently maxed out, you’ll probably see a significant improvement in the total number of transactions you can process.
Just remember that moving to a model with multiple CPUs isn’t going to help a single batch job very much unless each CPU is much faster than your current system’s CPU. Getting a faster CPU usually requires moving to another model group (e.g., from 720 to 730, from 730 to 740).
The AS/400’s extendibility to multiple processors greatly facilitates the growth of interactive and server applications, which characteristically process each request in a relatively short time (compared to a batch job). Therefore, you can have a lot of them running simultaneously, each working on a separate transaction for several users. This isn’t the case with batch database processing, where a job runs for a long time.
For example, with bigger hardware, a bank can almost certainly process more teller and ATM transactions. But can it process all the customer records that must be handled and complete their backups before the bank opens the next morning? With more hardware, a payroll processing application can handle more employee record updates and online time-card processing. But can it also process the final payroll and disburse funds (as printed checks or fund transfers) to online accounts on time?
Most legacy batch applications and many new database update batch-processing applications are designed to run as single threads of execution. By this I mean that they read an input record, update a file (e.g., pay interest to a bank account, apply withdrawals and deposits), or generate a new database record for a file (e.g., add detail lines to a payroll file). Once the database processing is complete, they go into report-generation mode. In short, they do things one step at a time, and they aren’t designed to achieve execution-time parallelism.
If you can’t split the job into parallel execution strings, you can’t take much advantage of an n-way processor. It may help a little — but probably not enough to get the job to run with much higher volumes. What you’d probably see in this case is some of the System Licensed Internal Code (SLIC) tasks running on one processor and the single batch jobs running on another.
In both interactive and batch processing applications, a job or thread uses only one CPU at a time. But when a lot of jobs (e.g., multiple concurrent interactive or server jobs) are running, you can drive more than one of an n-way processor’s CPUs concurrently.