Getting CICS on the Web
- By Sally J Cusack
- June 26, 2001
In the last two years, companies across
the globe have implemented Internet technology faster than you can say "CGI scripts." In fact, information
technology firms rank exploiting Internet/intranet technology as their top initiative or mandate. Companies such
as mail-order houses and retail catalog stores are now regularly using the Internet to achieve a return on investment
However, users of "hard-core" transactions -- banks, mortgage lenders, insurance firms and stock brokers,
for example -- are only beginning to see real dollars and cents attached to their company's investment in the Web.
These organizations, almost without exception, have many of their mission-critical corporate systems anchored
on IBM MVS mainframes running CICS or IMS. But before these companies can truly exploit the power and capabilities
of next-generation front-end systems and universal connectivity, some critical behind-the-scenes work must take
A recent survey of more than 350 I/S professionals across leading industries
reveals the hurdles I/S departments must overcome in order to meet objectives.
The study, conducted by SPG Analyst Services, Natick, Mass., found the
top five obstacles to be:
- Developer inexperience with new development tools/paradigms;
- Difficulty integrating new technology with
- existing systems;
- Need to retrain I/S staff;
- Excessive rate of change in technology standards and/or products; and
- Complexity of the development process.
These types of issues have led many enterprise organizations to leverage the value of mission-critical systems
by front-ending them with newer technologies capable of Internet access. One such early Internet transaction processing
success story is Charles Schwab & Co. Headquartered in San Francisco, Schwab was the first discount stock brokerage
firm to offer customers the ability to trade via the 'Net. The firm provides a wide range of financial products
and services -- from the purchase of mutual funds and equities trading to asset allocation and investment information
-- to more than 1.4 million active Web accounts, and services 6 million Internet transactions per day.
Schwab currently has five mainframes in operation: three are located at its data center in Phoenix, and two
are in the San Francisco office. Transaction throughput is mind-boggling, with an average of 1 million transactions
per hour processed under CICS for MVS/ESA 4.1 software. This makes Schwab one of the largest CICS-based shops in
the United States.
According to Adam Richards, director of technology integration at Schwab, the trading giant's early entry into
Web-based transactions can be credited to Charles Schwab himself. "He said, 'I want to be on the Web, and
I want to be there in a couple of months,'" said Richards. "We were fortunate. We had the CICS infrastructure,
which enabled us to go from Web to desktop to mainframe. This technology base allowed us to say this is just another
Of course, Richards added, there is a difference. Internal and external customers require different displays,
and online customer needs are different from those of the inside representatives. Writing the content and designing
the front-end material is important, he said, but to get real transaction processing onto the Web, most of the
development time is devoted to the back end. To help ease this task and to avoid rewriting proven, bet-your-business
systems, Schwab decided several years ago to port selected transaction systems from the mainframe to the IBM RS/6000
server platform running CICS for AIX.
The company restructured its existing Cobol programs by running Cobol on AIX; this also allowed Schwab to retain
actual CICS transactions. DB2/AIX was used for the database, while External Call Interface (ECI) acts as a gateway
so that non-CICS servers can gain access to this platform. This setup has also allowed Schwab to extend its existing
CICS infrastructure and CICS-driven business functionality to the distributed environment. According to Richards,
being able to restructure Cobol code as exposed APIs has simplified programmer access and contributed to productivity
improvements. In the future, Schwab plans to encapsulate Cobol programs within Java wrappers.
Using this approach, Schwab's I/S staff was able to port the firm's Sentry gateway to the RS/6000 platform.
This allowed the staff to implement the initial Internet trading application in approximately 90 days. Five months
later, Schwab was processing more than 60,000 transactions per day in the Web-trading environment.
From the customer's point of view, Web-trading business transactions are merely transactions that also include
simple queries, such as "How much am I worth right now?" In the stricter transactional definition, that
of two-phase commit, Schwab does a fair amount of read-only two-phase commit transactions, said Richards.
"In Web trading, we don't run a transaction every time you check the Dow. You sign on, [and] we manage
a conversation of transactions thereafter," he said. For example, Schwab will superimpose a conversational
motif on top of the inherently non-conversational Web environment. In effect, this overlays a conversation on top
of the Web browser. While the CICS box is essentially responsible for managing a conversational session between
the Web customer and Schwab, some engineering is required to make that happen.
When a Web customer signs on, said Richards, Schwab needs that to be a stateful operation. "We want to
know when they signed on, and for how long. In addition, we also have to implement security mechanisms, such as
authentication and verification." Users sign on to the Web site using tokens, which are then checked. Once
a token has been verified as valid, the level of service the customer is entitled to is then determined.
Schwab does not view the migration to CICS for AIX as an on-again, off-again project, but as an evolving strategy
to provide additional functionality to all of its customers. "We are continuing to add to the infrastructure,"
said Richards. Everything is constantly changing, he said, from content providing at the front end to increased
capacity for handling greater transaction loads on the back end. Because of this, it is an on-going process to
maintain and manage the infrastructure.
Reface, refine, reuse
Realizing that "one size" or solution does not necessarily fit all, IBM has worked to provide its
CICS enterprise customers with other ways to integrate legacy systems with newer applications via rapid application
development (RAD) techniques. This allows users to deploy Web browser front ends capable of leveraging Java. Using
a concept IBM has dubbed "application mining," customers will be able to reuse in-house skills and systems,
while leveraging newer technologies in order to meet business objectives.
Application mining is the result of a partnership between IBM and leading tools vendors, including Planetworks,
a software development firm based in New York City. Planetworks' Interspace Release 5.0 product, for example, provides
an application architecture and development framework that simplifies the process of building Web-enabled applications
on top of transaction processing or messaging-based middleware environments. Users can construct applications using
Java, PowerBuilder, C, C++ or emerging Web development tools, such as those offered by NetDynamics Inc., Menlo
Applications built in this manner provide true three-tier capabilities by spanning from the desktop to the server
and onto the mainframe. Furthermore, Planetworks' Interspace shields developers from the middleware layer, allowing
them to write middleware-integrated applications without having to deal with middleware code. The product provides
a variety of features, including 3270-based CICS transaction support. Using the Interspace 3270 Extended Programming
Interface (EPI) feature, customers can use basic desktop developer skills to reface and refine any CICS application.
This requires no actual change to the application itself. Additionally, Interspace allows for the import of BMS
maps and Cobol copybooks into the Service Catalog. Version 5.0 also provides full support for all messaging options
of IBM's MQSeries, allowing for more complete testing of MQSeries applications.
Targeted primarily at mainframe CICS customers looking to migrate 3270 "green screen" interfaces,
application mining is designed to provide a best-of-both-worlds option. The core business and data logic can remain
untouched, while customers decide the most optimal path to move it out to the desktop. For some customers, this
may involve the interim development of graphical user interface (GUI)-style PowerBuilder or Visual Basic front
ends, but all of these roads ultimately lead to full-fledged Web enablement.
Mining for sales
An early adopter that has had success with this approach is UniSure Inc., Cincinnati. Part of E.W. Blanch Holdings,
UniSure develops, markets and supports the Universal Reinsurance System (URS), software that manages reinsurance
transactions for major insurance institutions across the country. In order to win more sales among PC-based customers,
UniSure needed to find a way to put GUI front ends on its existing mainframe CICS 3270 application, without having
to rewrite the application itself. After looking at several products, the firm chose IBM's Application Mining Starter
Kit, which includes Planetworks' Interspace for Sun Solaris and Java, as well as Sunlink SNA connectivity.
David Sauer, senior systems analyst at UniSure, focuses on Cobol/CICS application development. He was brought
into the company a little over a year ago to help facilitate the organization's move to a three-tier environment.
While UniSure knew it needed an easy-to-use GUI front end, it wanted to achieve this while maintaining its extensive
and stable business logic on the back end. The solution was to develop GUI front-end data that could be passed
through middleware to the back-end system. Sauer was tasked with taking code on the existing system and transforming
it to take data calls on an ECI path. This triggers CICS programs to do data processing and updating, and to then
send the data and updates back along the same path.
Referring to this process as a mirror transaction, Sauer describes the ECI call as similar to a CICS program
linked to other CICS programs. The Java portion builds and packages the data in a class and then calls through
the middleware. The middleware, in this case, consists of the CICS Gateway for Java, Web software, the CICS client
and Planetworks' Interspace software. Through these programs, data is "massaged" into a package and then
put into a format that the back-end Cobol program can understand. The CICS client allows the program to initiate
an ECI call into CICS, while an SNA server is used to communicate with the mainframe.
The insurance industry still maintains a large contingent of OS/2 users, said Sauer, and the CICS/OS/2 combination
allows for the use of TCP/IP. The middleware portion runs on a Microsoft NT or Windows 95 platform, while the front
end will ultimately run on any Web browser with JVM 1.1. The back-end platforms will remain as is, running MVS
or IBM CICS OS/2.
A particularly useful portion of the Interspace middleware is the Painter feature, said Sauer. It allows the
developer to build request/reply interfaces that pass through a commarea (a CICS term denoting a common data area)
and then from program to program without having to go to an external data field. According to Sauer, users first
define their data elements and attributes. In Java, for example, a data field can be any size on a string. When
Java passes in this string of data, Cobol might expect 20 bytes, yet Java may only pass 5 bytes. The Painter will
then "pad out" everything expected by the Cobol program.
"We're still in the development phase," said Sauer, "and the speed of the software is not where
we want it to be." He added that his comfort level is increasing with the recent improvements to Java, and
technology like the JIT compiler will help. "The relative infancy of the [Java] language and the war between
the vendors has hindered us," Sauer said.
In an effort to speed the development process, UniSure has gone to third parties for class libraries. "Java
allows us to give our clients flexibility," said Sauer. "Being able to offer Java and the JVM to our
customers ... they don't have to change their entire network and operating system. They simply put the middleware
on NT and run a Java 1.1-compatible browser."
UniSure's application mining proof-of-concept took approximately three weeks to complete. Two weeks were spent
looking at the program and decoupling the 3270 interface software from the program itself, and an additional week
was spent working with Planetworks consultants who provided expertise in interacting with the middleware portion.
As far as UniSure is concerned, the ability to utilize a Java front end is critical to its long-term success.
As a software development company, UniSure, like many of its counterparts, has no way of controlling customer configuration.
Some customers might elect to use Microsoft Windows, and as previously mentioned, many are currently on IBM's OS/2.
UniSure even has one client in an Apple Macintosh environment. Because UniSure did not have to rewrite core applications,
the company saved untold amounts of time and money. The application mining approach also allows developers at the
host and front ends of the application to work in their own environments, interface with each other when necessary,
and does not
require them to be familiar with each environment.
"Customer ease of use is critical for us," said Sauer, a sentiment echoed by Schwab's Richards. Gone
are the days when companies could afford to spend years writing and rewriting application systems. For long-term
success, organizations need to put their efforts into creating and maintaining strong but flexible infrastructures
that meet today's needs and provide extensibility for tomorrow's demands. The ability to "value extract"
business logic from core systems, without rewriting code, and to reformat this logic to newer platforms, could
be a critical factor in many time-to-market decisions.
Management and scalability
At Schwab, the volume of Web trading is moving forward in leaps and bounds, said Richards. While this is good
for business, he points out another effect: As the number of Web transactions grows, so does the number of nodes
in the Unix mid-tier layer, and correspondingly, his management issues. He offers a rule of thumb for Web-enabled
transaction processing management: "The difficulty of managing a set of objects is related, in some way, to
the square of the number of those objects. Objects, in this definition, could be logical tiers or processing units."
But whether you manage dumb terminals, PCs or the Web, the same fundamental problems -- the growing demand for
processing power, and the need to cope with scalability issues, replication, myriad transient links and unit failures
-- occur. Companies therefore need sophisticated
algorithms that route around failures and implement load balancing. Fortunately, mainframe developers have some
of this experience, Richards said.
Environments such as IBM CICS have been built from the ground up to deal with load balancing, session management,
persistence, scalability and other issues that are now becoming more apparent to the I/S world at large. Customers
familiar with CICS functionality and reliability are not eager to trade this off to move to "new world"
distributed applications. Fortunately, they may not have to.
At the most basic level, there is a need to optimize client access and "modernize" the existing back-end
CICS application. As far as client access is concerned, simple refacing of the CICS applications involves the CICS
External Presentation Interface (EPI), which is designed to effectively utilize the original 3270 datastreams.
How-ever, a method such as CICS ECI or MQSeries, which uses program-to-program style calls, can be far more efficient.
Enabling CICS applications to be ECI-callable can be done in two ways. The first approach is when the presentation
logic is decoupled from the business and data logic, and interface code is then developed to support ECI calls.
The second way is to "wrapper" the entire CICS program with another program that supports interfacing
to 3270 datastreams. The choice in the second scenario is between using the CICS Front End Programming Interface
(FEPI), or for customers with CTS 1.2 systems, the CICS Bridge Program for 3270 applications. While individual
circumstances dictate which choice the customer employs, the most advantageous method for the majority is to decouple
the presentation logic on the back-end CICS application and then move to thin-client technologies at the front
In addition to the technology offerings mentioned in this article, IBM is working to provide a specific gateway
product with functionality based on current CICS client and Java gateway technologies. Currently referred to as
the CICS Transaction Gateway (CTG), this product is positioned as an e-Business Connector within IBM's Network
Computing Framework. The initial launch is scheduled for late 1998.
CTG's function will be based on advanced Java and HTML functionality, with an emphasis on performance, security
and manageability. At press time, word is the gateway product will include support for browser, network station
and equivalent clients; support for standard front-end protocols, such as HTTP, SSL and IIOP; and enhanced interfaces
and consistent object APIs. However, this is only a partial list of product features to date; the gateway will
provide many ease-of-use features, such as wizards, smartguides and installation aids, that have hitherto not been
found in the CICS environment.
Enhancements to the CICS Transaction Server (CTS) will include support for the execution of Corba-compliant
Java applications in release 1.3. IBM has also made
a serious commitment to supporting the Enterprise JavaBeans (EJB) spec.
In order for the CICS framework to support Java Application Components, CTS will be modified to support EJBs.
These modifications, built upon the basic Java and Corba support found in CTS 1.3, will initially enable support
for the EJB concept of "session beans." Session beans are beans that behave in a manner similar to today's
existing CICS transactions (for example, clients access servers, do some work and then disappear). If clients in
this scenario have a transactional context, then executable behavior is similar to a CICS conversational application.
Conversely, when no transactional context exists, behavior follows a pattern similar to a pseudo-conversational
The bottom line is this: IBM mainframe users may not have to give up the comfort, reliability and security of
their CICS applications to move into "New Age" distributed object computing. In the short term, this
could mean immediate savings in retraining and redevelopment costs. Over the long term, it could save firms millions
of dollars in dealing with distributed computing's infrastructure maintenance and scalability issues. These savings
cannot be ignored as Fortune 2000 firms search for new and better ways to beat the competition via a technological