In past years, we have been talking a lot about what DataKinetics can do for mainframe shops—from mainframe cost reduction, mainframe performance improvement, Db2 application performance improvement, Db2 database performance improvement to IMS performance improvement and batch performance improvement, the list goes on. All that is still true (and if you’re feeling some pain or a desperate need in any of those areas, please contact DataKinetics!)
But rather than immediately drilling down on problems that we solve, and frankly, a lot of stuff you already know, let’s go back to the basics and talk more about what our flagship product—tableBASE—does, and how it can help you to make your problem applications run 100 times faster.
tableBASE is a “pure” in-memory table manager—it does not replace anything that you have in your mainframe datacenter right now—it augments what you have, and makes applications run faster, while cutting costs at the same time. By accelerating your database applications, it makes your database seem to run faster—for example, if your Db2 applications run faster, the outcome will be that your Db2 database will be running faster.
So, how does that work? Great question. Your Db2 applications access the database all the time – that is what they were built for, and they are well designed. And most of those reads and writes actually run pretty fast as they are now. However, there are typically small database tables that get accessed many times during every transaction your system processes – and that can add up to millions of accesses per hour. Collectively, these table accesses can be very costly in terms of resource usage—repeated I/Os can suck up resources very quickly. (We’re talking about I/O’s themselves, and the overhead involved for each I/O.)
The tricky thing is that these tables might look pretty innocuous based on the lines of code they represent, and it can be a challenge to see that they are the true bottlenecks in your transaction processing.
So what do you do? Use the tools you have at hand—your basic SMF data—or more visual tools like SMTData’s IT Business Intelligence (ITBI) toolset, or IBM’s own OmegaMon toolset to identify smaller tables that experience 100 or 1000 times more reads than writes.
Then, it’s a simple task to copy that table data from Db2 (or IMS, etc.) into tableBASE pure in-memory tables, and access it from memory there using a tight little API and an extremely short code path. (You can easily update these tables from the database, or update them directly in memory.)
What’s with the short code path? Well, it avoids the database access overhead for just that data that gets read millions of times per hour. It’s a simple SQL change. None of your actual program code needs to change at all—just a small number of SQL calls.
And what difference can that make? It can be incredible—applying tableBASE usage under the right conditions, a batch run can take 15 minutes instead of 12 hours. A CICS application can run 25 times faster, again under the right conditions.
So, going back to basics is what we’re doing from now on—our “pure” in-memory technology can save you money on your monthly bill, make your mainframe applications run much faster, and use far fewer system resources. All you need to do is to change a handful of SQL calls. What’s not to like about that? For more information, see www.dkl.com.