Jim Rhyne, an IBM distinguished engineer, is the company's lead architect for non-Java application development tools and CICS, IBM's enduring mainframe transaction-processing middleware, which recently celebrated its 35th birthday.

As part of his job, Rhyne works with customers to modernise their old mainframe environments. He spoke with Computerworld's Robert L. Mitchell about CICS, Web services and the future of the mainframe.

IBM's CICS transaction-processing middleware is now 35 years old. What is its future?
At the beginning, CICS was a very crude set of libraries built for what was then the IBM 360 operating system. Over the years, it has matured from a programming library into something that's strikingly similar to what we have in WebSphere today. It provides application containers that not only support transaction behaviour but resource management. It supports scale-out.

It's going to remain as a high-end, high-speed, high-throughput atomic transaction-processing system. You'll find WebSphere taking over the low end of the transaction-processing marketplace and much of the middle as well. [CICS] is going to be a full player in this on-demand integrated computing environment that IBM is promoting. You'll find aggregations of software designed to handle Web browsers, designed to handle external interactions mediated by Web services. Behind that will be transaction-processing databases, and we expect CICS to be one of the premier solutions that we offer.

What emerging technologies are affecting CICS and mainframes?
XML and Web services, service-oriented architectures -- this is the big thing that's hitting the mainframe. If you look at the composition of SOA, there is a universal connectivity part, then there is componentization -- taking monolithic applications and breaking them down into reusable chunks of business logic. That was easy to apply to user interface and client-side programming. Now we're getting around to using it in a serious way on the server side.

How do you bridge mainframes with Web services?
The integration software [for CICS] is going to be J2EE and Java. CICS applications change, and when they do, there's an outward ripple into the WebSphere environment.

From a development point of view, if I make a change to a CICS application, it's not easy to find and change the corresponding set of WebSphere applications that use it. What you have is a mixed workload application. From a management point of view, I want to manage this as a single entity. The most important thing [programmers] can do is to understand the other technologies you have to interface with. It's a lot easier for these communities to operate as teams if they understand each other's technologies.

Is the CICS installed base still growing?
The customer base is increasing slowly, and if you measure the use of CICS in terms of transactions per second, that's growing at double-digit rates. The reason has to do with the rise of e-commerce. Ultimately, almost any transaction you do ends up being handled on a mainframe. If you take the Fortune 1,500, we're in every one of those accounts with mainframes. Their computing needs can't be satisfied by a smaller platform.

Companies such as eBay seem to be doing quite fine without a mainframe, and they have very large databases. Can you explain?
In fact, one of the things eBay doesn't do is payment processing. So it will match a buyer and a seller using its own hardware. But if there's a payment involved, that eventually gets offloaded to one of their partners, and almost all of the partners that do financial transaction processing use mainframes.

IT organisations continue to migrate many functions off mainframes. How do you respond to that situation?
Historically, a lot of mainframe applications were developed in environments that were single-layer topologies. All parts of the application ran on the mainframe. That's not the most cost-effective. The mainframe is extremely good at high-rate transaction processing and batch processing. It's not good as an integration platform. In terms of cost/performance, you can do better with other platforms. The stuff going off the platform is the stuff that doesn't make sense to be there.

The historical fact that mainframe software hasn't been very malleable works against it. We're on the way to fixing that. Our proposal is that we take these applications and restructure them into component-style applications that are assembled by some sort of script.

How will you do that?
The difficulty is getting applications that run on [the mainframe]. In the market, it's less custom development and more packaged software. ISVs [independent software vendors] want a good-sized customer base and would like it if they could reuse the same software they've developed for other platforms. That's the struggle.

The way it will be resolved is that ... the mainframe will look like a more standard computing platform. One of the ways it's happening is through the ubiquity of Java. It's supported by WebSphere, and you can write Java applications that run on the mainframe. You can write Java-stored procedures for DB2 databases.

If the mainframe is coming back, why is IBM the only vendor left selling them?
We use a terrific amount of commodity silicon. Ten years ago, when we had substantial competition, this wasn't the case. We were struggling at that point in time to maintain any kind of profitability of these things, because the cost of developing was so expensive. Fujitsu and Hitachi concluded that it was too expensive to compete. We were pretty close to the point of saying, "There isn't enough money unless we can figure out a way to cut costs." The way was to exploit commodity technologies.

Where will the mainframe be in five years?
It's difficult to predict. Part of the reason is that on hardware, we seem to be approaching a discontinuity. For years, we've had a Moore's Law, given that machines consume less power and they run faster [as time goes on]. Well, we're getting close to the end now.

At that point in time, if you look at how you are going to meet the demands for computing, the only option left is to go into large-scale multiprocessing -- thousands of parallel processors, or even tens of thousands -- instead of the few dozen we have today.

My guess is mainframe applications will have to undergo a substantial amount of change because they were built essentially as single-threaded software. The mainframe will be hit by this, a lot of the Unix applications will be hit by this, and the Mac OS and Windows are also going to be hit by this. It will be a big game-changer, and my [crystal] ball is pretty cloudy about what's going to happen.