IBM's Cics transaction processing subsystem has been the dominant choice for large scale transaction processing systems for over 30 years. Virtually every IBM mainframe user, large and small, runs it.
As recently as 1999, Cics systems processed more transactions every day than the entire World Wide Web, and still today it plays a dominant role in keeping the world of commerce ticking over. According to IBM, Cics systems process over 30 billion transactions a day, worth over $40bn.
As a result, IBM mainframe users have a massive investment in Cics applications, and also in the people skills required to keep them going, with one million Cics programmers worldwide.
But Cics is showing its age. First introduced in 1969, it started life when batch processing was the norm and online transaction processing was still in its infancy, and punched cards were still the usual way of getting data into a computer. So, not surprisingly, it looks a little antiquated to anyone who has come into IT more recently.
As Erik Pattenden, sales and marketing manager at QED Business Systems, puts it: "Green on black Cics screens, clumsy application development methods, and difficult-to-use debugging tools, are just a few of the things making the mainframe world positively Stone Age to anyone brought up in the PC era."
So Cics users have a problem; they do not wish to discard their investment in tried and trusted mission-critical systems, but they do want to move into the world of e-commerce, and to do that they need developers familiar with modern development methods.
Nobody coming out of the education system today knows anything about green screens or Cobol programming. IBM's response to this problem is twofold. For users who wish to develop new systems that do not need to access existing Cics logic and code, the company has WebSphere Application Server (AS).
This offers much of the transaction processing management capability of Cics, but is designed for the e-business world, and employs up-to-the-minute development methods.
For users who do wish to re-use existing Cics applications, IBM has been steadily equipping Cics with modern development techniques, built around the Java programming language, and in many cases provided through WebSphere AS.
The latest step in this process came in March, with launch of Cics Transaction Server for OS/390 and z/OS Version 2. This, for the first time, introduces support for the Enterprise Java Beans (EJB) programming model, which allows component based programming.
According to IBM Cics technical strategy manager Andy Dean: "The step forward with EJB is that you start bringing in a more general purpose open standards programming model, which IBM is seeing as key across all its server lines."
A key element is the use of a connector framework. This allows building of Java applications that can access programs running on subsystems such as Cics in the same way across different platforms. Initially Cics TS V2 features IBM's proprietary Common Connector Framework.
When the necessary standards have been ratified, it will be replaced by the Java Connector Architecture (JCA), which was formally announced by Sun at the JavaOne conference in San Francisco in June.
For this reason, Cics TS V2 is being introduced in two stages. The initial version, Release 2.1, is for business partners, and for users who have a pressing reason to move to EJB programming straightaway. IBM does not regard it as a production release, and is encouraging mainstream users to wait for Release 2.2, which will incorporate JCA. No release date for 2.2 has yet been set.
In the meantime, most MVS and OS/390 users (and such few z/OS users as there are) will continue to use earlier releases. Most of them will be on one of the three releases of Cics Transaction Server Version 1. This was initially introduced in 1996, and was a major change. Up to that point, the focus of IBM development of Cics had been on performance and scaleability.
With Cics TS, IBM changed direction, and started to focus on added functionality for, initially, client-server transaction processing, and then e-business transaction processing. Cics Transaction Server is a package, consisting of Cics itself, plus client code, plus additional features, such as the CicsPlex SM system management package, and also the Cics Transaction Gateway, which opens up Cics for access by other systems.
As time has gone on, IBM has steadily added Java capability to Cics TS, starting with client-side access, and moving onto Java server capability. Users of Cics TS can evolve Cics applications in a number of ways. First, they can add modern Windows or browser based user interfaces to replace the green screens, using Cics Web Support, which provides EBCDIC to ASCII conversion.
As QED's Erik Pattenden puts it: "Web-enablers at last have a simple way to give their users applications with modern browser style interfaces, which access enterprise data on the mainframe." This is fine up to a point, but does not do anything about the fact that Cics applications were not typically designed for the e-commerce world.
Browser users are therefore likely to find Cics systems much less satisfying to use than purpose-built e-commerce systems. To overcome that, users need application code that is written in a more modern language, such as Java, where building in the facilities expected by Web browsers is easier.
Cics TS allows Java programs to access or combine with Cics logic in several ways. First, you can connect via a Web server running in a non System 390 processor, via the Cics Transaction Gateway. That provides access from Web browsers. Second, you can connect via a Web server that is actually running on a 390, such as IBM's WebSphere Application Server, or BEA Systems' WebLogic. Third, from Cics Transaction Server 1.3 on, users can write Cics programs using Java as a source code language, which can then run alongside existing Cobol and PL/I applications.
Such applications are still inherently procedural, rather than object-oriented. The provision of EJB support and a connector architecture in Cics TS V2 remedies that deficiency. According to Walker Interactive UK vice-president of research and development, Peter Willson: "With this type of application you'll typically have 80% new code, and 20% Cobol code with a Java wrapper around it."
The facilities added to IBM by Cics are complemented by independent companies such as QED, which sells a product called FireXML. This interfaces with CicsWeb, and through it with mainframe databases such as DB2, and formats the results into XML for subsequent Web based processing.
Seagull Software is another company in this market with its product Transidiom; this also converts Cics transaction data into a form useable by e-commerce applications such as IBM's own WebSphere Commerce Suite.
For IBM the strategy is very much one of preserving existing user investment, not of promoting the use of Cics to any user who is not already familiar with it. As IBM Cics business unit manager John Graham says: "It's about re-use, not only of applications and data, but re-use of skills."
Case Study: Abbey National
The Abbey National bank is one long-term Cics user that has successfully moved into the e-world; the finance house now derives more than half of its business from non-traditional activities.
One legacy application the company has evolved in line with modern internet based business practice is the processing of non-invoiced payment requests. Between 6 and 8% of all payment requests received by Abbey National's Accounts Payable department do not involve an invoice, for example travelling expense claims by job applicants and bonus payments to employees for money saving ideas.
These forms were until recently manually filled in, manually signed and approved, and manually keyed into the system. Abbey National decided it was time to automate this procedure by replacing the batch processing procedure with online data entry via the corporate intranet.
The firm chose to install a packaged system from Walker Interactive, Walker SelfServe, to provide the necessary electronic forms logic. SelfServe interfaces to Cics at the back end via the Cics Web Interface, and to the user at the front end via a browser.
According to Paul Duester, Abbey National manager of corporate systems: "What you eliminate is the manual keying of the requisitions, delivery through internal post, opening up of internal post, the batch preparations and so on. If you multiply this process by 800 times per month, the time and money saved becomes considerable."