iBoost Turbo-Charges Slow i/OS Batch Jobs

System i shops suffering from long-running batch jobs may be able to speed up those jobs by a factor of 10 with a new product from iBoost Systems. Called iSTREAM, the product uses command substitution techniques to split single-streamed batch jobs into multiple streams that can better utilize System i horsepower. The product–which was vetted by IBMers in Rochester, Minnesota, to ensure it doesn’t do anything untoward–is being distributed in the U.S. through iBoost’s new partner, Midrange Performance Group.

iBoost Systems was formed in the European country of Cyprus late last year to market and sell i/OS performance tools–primarily iSTREAM, but also BSTAR, which is an older version of iSTREAM that was developed years ago to speed the end-of-day processing for banks that use the i/OS-based banking application from Misys, called Equation. iSTREAM is an updated and more generic version of BSTAR that doesn’t feature the Misys-specific hooks, and can be used with a wider range of batch jobs in i/OS applications.

The problem of long-running batch jobs is particularly troublesome for banks, which typically calculate interest, generate statements, and perform other critical activities at the end of each business day. If the bank relies on a single-stream batch job to execute the end-of-day processing, it may not be able to complete the task for all of its accounts in time to open the following day, which can be a huge problem. BSTAR provided a much-needed boost for Misys customers, and now iBoost is trying to do the same thing for other i/OS applications with iSTREAM.

Iain Coles, director of iBoost Systems, tells IT Jungle how iSTREAM works. “We’re using command substitution, and implementing parallelism where it doesn’t already exist,” he says. “We create a kind of a shell around the batch process, and create a duplicate program [with the same] program name as that process. We also configure appropriate specifications on how the job should be broken into streams.

“We define those [streams] and assign them to different threads if you like, or strings, and then submit multiple jobs with the same name as the original program,” he says. “So they all run in parallel utilizing however much processor you’ve actually got to throw at the job, and at the end of that we would then have an application that merges the results of this process.”

Some ISVs have already built this type of technology into their applications. But for those that haven’t–or for System i shops interested in exploring the possibilities of turning single-threaded batch jobs into multi-threaded jobs–iSTREAM provides the capability to do this without opening up the source code, Coles says.

The performance boost that iSTREAM or BSTAR can provide will vary from customer to customer, Coles says. One bank in Moscow that implemented the technology–after overnight batch jobs prevented it from opening on time the following day–experienced a seven-to-10 times increase in the speed of its end-of-day processing, he says.

Coles and the other owners of iBoost decided to formally launch the company at the recent COMMON conference in Orlando, Florida, in part because of the impact that the global financial crises is having on IT purchases.

“Up until recently the typical response to a long-running batch job has simply been to invest in more hardware, to upgrade to a bigger server,” he says. “It’s expensive, but a reasonably efficient strategy. Of course we’re now coming out of the economic crisis, which is part of the reason for the timing of what we’re doing. Organizations typically don’t have the budget they used to have for that kind of thing, so people with pain are having to find alternative, cheaper solutions.”

The new Power 7 servers provide another incentive for considering iSTREAM, according to Coles. While it is true that IBM has doubled the number of threads per core and doubled the number of cores per processor, Coles argues that some customers will be unhappy with the performance of Power 7 because the clock speeds are actually lower on Power 7 than on Power 6.

“The caching is better [on Power 7], so there is a little compensation,” Coles says. “But it basically means, if you’re running a single-stream batch process, you may not get much benefit from Power 7 compared to older machines. You’ll get benefits in other areas, particularly the interactive side and the networking. But in terms of specific types of jobs, you may well not get any benefit at all. We’ve even had a discussion with IBM here in central Europe where they’re telling their salesmen that if they need to, they can recommend iSTREAM to customers.”

And while it is true that some i/OS applications may be able to take advantage of the additional processing threads that Power 7 supports by simply re-compiling the application using the new compilers, not all applications lend themselves to this approach.

“It’s not necessarily clear that that’s going to happen,” Coles says of the capability for IBM compilers to automatically enable applications for multi-threading. “There’s certain kinds of applications that lend themselves to multi-threading, and they will be converted. It’s my understanding that certain kinds of applications don’t lend themselves to multi-threading. If you did that, and some arbitrary process in the operating system went ahead and multi-threaded a banking operation, and started doing it based on, for example, the alphabetical listing of customer names, it would be a complete mess.”

Of course, whenever one starts dealing with performance-enhancing products for the System i platform, the conversation invariably leads to Fast400, the Barry Bonds of the AS/400 world. The Fast400 saga, which thankfully ended nearly five years ago, involved a company based on the Isle of Mann that basically hacked (or “patched”) the kernel (or “SLIC”) to remove the 5250 governor (or “CFINT”) that IBM placed on interactive processing, thereby giving AS/400 customers processing power they had not paid for.

Coles is familiar with the story. “Yes there was a concern,” says Coles, who works and lives in Austria (the company is based in Cyprus for “technical reasons.”) “I think this is part of the reason why it was important for us to go there, [to IBM’s lab in Rochester] and show that we’re not [doing anything untoward]. We do need their support. It’s invaluable for us to have their support. That concern was cleared. We’re not doing that. We’re working entirely externally to the code as it were, and utilizing tools and APIs that they’ve made available to the market.”

There are some caveats to iSTREAM, as you might expect. For one, it doesn’t work with Java-based batch processes; only applications written in RPG, COBOL, and C++ will work.

But there are other benefits, as well. For example, customers can speed their nightly backups using one of the iSTREAM components. The component utilizes IBM journaling and remote journaling, and can completely replace existing backup processes with a much faster approach. And, thanks to the command substitution technique, users can take advantage of save-while-active functionality. iBoost also offers a performance analysis tool, called ANSPROF, that prospective customers can use to see what kind of a performance boost they can expect with iSTREAM.

Midrange Performance Group, a Boulder, Colorado-based provider of performance analysis tools for the System i server, has an exclusive 12-month deal to sell the iBoost products in the United States. For more information, see www.iboostsystems.com or www.mpginc.com.

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot