The Evolution of CICS: CICS Support of Client/Server Applications (1995)

Choosing 1995 as a starting point for discussing CICS support of client/server applications is a bit misleading, or unfair to the history and evolution of CICS. If we began instead in the late 1970s, we should remember that CICS introduced support for Intersystem Communication (ISC) and Multi-Region Operation (MRO). ISC and MRO certainly provided support for distributed systems. which could loosely include client/server applications, if only in concept.

In 1980, CICS introduced its support for Advanced Program to Program Communications (APPC) and this certainly qualified as a form of client/server support. Using LU6.2 protocols, CICS and any other system supporting APPC or CPI-C (Common Programming Interface for Communications), could behave in a client/server relationship.

With APPC, either node could initiate the conversation, either node could request that a syncpoint (commit) be taken, and through programming, the roles of the client and server could be reversed dynamically. Sending and receiving of data was driven by the application's use of the APPC/CICS programming protocols. Either node could be a sender or receiver of data.

Ah, but one might argue, that's fine but it wasn't the common definition of a client/server configuration. Many people believed that client/server involved an intelligent workstation connected to the mainframe. Okay, in 1991 CICS OS/2 1.20 offered support for workstations to participate in distributed applications with the mainframe.

That year CICS OS/2 introduced support for External Call Interface (ECI), which enabled non-CICS workstations or computers to dynamically invoke CICS applications on the workstation. An example might be a workstation, with an application using a a Graphical User Interface (GUI) such as PowerBuilder or VisualBasic, and that application invoked CICS applications on CICS OS/2.

The CICS OS/2 support of ECI was complemented in 1993 with the addition of support for External Presentation Interface (EPI) by which CICS applications could interoperate with other nodes dealing in 3720 data streams. For instance, an application running CICS OS/2 could use EPI to construct a 3270 data stream and appear to the connected host as a 3270 display terminal. Conversely, CICS OS/2 provided inbound support for 3270 data streams (from a host, for example).

By 1995, the interest in CICS support of ECI and EPI was sufficient to offer those functions packaged as a separately orderable offering called the CICS Client. The CICS Client was later to evolve to the CICS Common Client and still later it became the CICS Universal Client. With the 1995 offering, the CICS Client code could be run on IBM or non-IBM workstations, and applications there could invoke a full function CICS system using any combination of ECI or EPI. Truly client/server.

During the same mid-1990 period, mainframe CICS provided still other support which could be used to assist in the implementation of client/server applications. Some people considered CICS OS/2 or the CICS Client to be proprietary code and expected CICS to support the more generic case of Remote Procedure Calls (RPC) in which the client simply issued a call and provided call parameters to a server.

CICS delivered support for RPC in two forms. In 1995, CICS delivered its support of Open Network Computing (ONC) RPC, and earlier, in 1992, CICS delivered support of Distributed Computing Environment (DCE) RPC. A non-CICS node could now interoperate with CICS using either the CICS Client support (ECI/EPI), ONC RPC, DCE RPC, or APPC.

In 1996, the CICS Client support evolved into its Version 2 offering. In 1998, this evolved to a Version 2.0.4 offering. As the CICS Client began to support more client platforms, it was soon incorporated into the newly announced CICS Transaction Gateway product in 1998 and renamed the CICS Universal Client.

As the CICS Transaction Gatway asserted itself as a means of host connectivity, for a short duration, it appeared that there was no need for a separate CICS Client offering. That didn't last very long because many customers continued to want/need a client/server form of connectivity to full function CICS systems, hence the CICS Universal Client is offered as either an integrated function of the CICS Transaction Gateway, or as a separately orderable, stand alone CICS Client offering.

In its early days, the CICS Client provided function on LU6.2 (APPC) links to full function CICS nodes. A number of customers were concerend about the prerequisite software that would be needed since the CICS Client required a SNA/LU6.2 connection to the host. Coincident with the release of CICS Transaction Server Version 2.2., CICS clients can now use ECI across a TCP/IP link. This obviates the need for fee-based software on the client for SNA connectivity, simplified maintenance on the client and reduced education requirements.

Many customers were slow to realize the potential of the CICS Client. Two examples come to mind. First, there is the notion of extended units of work, and secondly, the notion of asynchronous processing. In the first case, a client application may issue multiple requests to the host, perhaps each performing some update, but instead of the host committing such work on each invocation, the host could wait for an explicit or implicit request from the client before commiting updates performed in this conversation.

In the second case, there is asynchronous processing. A client application may invoke CICS on the host and cause a transaction to begin execution. The client need not wait for a reply but instead might perform other meaningful work. At a later time, the client could issue another call to CICS on the host, inquiring as to the outcome of the previous request. Asynchronous processing is a form of multi-processing.

The CICS Client functions of ECI and EPI continue today as important aspects of CICS connectivity. The Universal Client, being part of the CICS Transaction Gateway, performs an important role as far as providing strategic connection from possibly non-IBM, non-CICS environments into full function CICS systems.

Copyright © 2003 - Yelavich Consulting, Sparks, NV
Click here for other articles regarding the evolution of CICS.