In-Depth

CICS Support of the Internet

• 03/01/1999

This article provides a simple introduction to CICS support of the Internet. It may beadvantageous to present this information in a somewhat chronological sequence because someusers may still be on older releases of CICS and not have access to the latest support.

It should be noted that all CICS support of the Internet delivered thus far is free tothe user. There is no license charge for any of this support. Some of this support may bephysically shipped with a given release of CICS, such as CICS Transaction Server forOS/390 (CICS TS). Most of the code and documentation can be downloaded from the CICS Website at www.software.ibm.com/ts/cics.

Overview

CICS provides Internet access in three basic forms. A Web browser may be 1) connectedto a Web server on a machine outboard to the CICS host and it then connected to the CICShost, 2) connected directly to a CICS region on an MVS host, or 3) connected to an MVS Webserver, which in turn can connect to a designated CICS region on that MVS image (seeFigure 1).

In the first case, a Web broswer (i.e., Netscape, WebExplorer, etc.) can make referenceto a URL, which will be directed to a "Web server" residing on some outboardserver, such as OS/2, NT, AIX, etc. At that machine, CICS provides an IBM-written, CICSClient application program, which in turn will use either the CICS Client-provided ECI(External Call Interface) or EPI (External Presentation Interface) call statements tocontact a CICS region on an MVS host. The CICS Internet Gateway and the CICS Gateway forJava are examples of support which require an outboard server.

An ECI call is one in which a call parameter list will be presented to a target CICSsystem as parameters in a COMMAREA. ECI is similar, but not identical to other CICSfunctions such as Distributed Program Link (DPL) and External CICS Interface (EXCI). Morewill be said about this later. An EPI call presents a 3270 data stream to the target CICSsystem.

The CICS Gateway for Java supports the use of either ECI or EPI calls. The CICSInternet Gateway supports only EPI calls. This will be more relevant as we examine CICSsupport of the Internet further.

Initial support for direct access from a Web browser to an MVS CICS region wasdelivered with CICS/ESA 4.1, and later enhanced with CICS Transaction Server for OS/390.No outboard server is required. This support is referred to as the CICS Web Interface(CWI).

Access to CICS via an MVS Server has varied since its initial support; however,essentially the access path continues to be from a Web browser directly into an MVS serverand from there to a CICS region on that MVS image. Early support used the MVS InternetConnection Server (ICS), which was later improved as the MVS Internet Connection SecuredServer (ICSS). Still later, the MVS Web server was renamed the Domino Go Server, and mostrecently it has been renamed WebSphere.

The customer's primary interest in using the MVS server path is one of security. TheMVS server offers encryption/ decryption which is considered to be essential for integrityand message protection.An alternate scheme for security might be the use of so-calledproxy machines being in a configuration between browsers and hosts.

CICS Internet Gateway

The first support of the Internet provided by CICS was something called the CICSInternet Gateway. It's purpose is to provide Web browser access to host CICS 3270applications. This support does require an outboard server (OS/2, NT, etc.) in order toexecute the IBM-provided CICS Client application program which uses the EPI call tocontact the MVS CICS region containing the 3270 application to be executed.

Some customers do not like the idea of a three-tiered environment (browser, outboardserver and host) because it may require new hardware, staffing, education, maintenance,etc. Other customers do not object to this because they favor offloading processing andthey may already have justified the outboard server for other purposes.

The IBM-provided CICS Client application's purpose is to convert the Web brower'sHTTP/HTML data streams into 3270 data streams to be sent to the host, and on output toconvert 3270 data streams to HTTP/HTML data streams for presentation at the Web browser.

The IBM-provided CICS Client application is not customizable. What you see is what youget; namely, the 3270 output is displayed as a "best effort" on the Web browser.This support does not provide any exploitation of GUI functions, such as radiopushbuttons, pop-up displays. For this reason, some customers are not interested in theCICS Internet Gateway because they want exploitation of the GUI-capable workstation.

CICS Gateway for Java

Before beginning a discussion of the CICS Gateway for Java, be sure that you understandthat this support resides on an outboard server and is not be be confused with the supportannounced later with CICS TS 1.2 called the CICS Gateway for Java on OS/390.

Java is becoming increasingly popular for a number of reasons. Perhaps foremost is thenotion of platform independence, sometimes referred to as write once, run anywhere. Theuser's motivation is to write an application and not have to rewrite or somehow modifythat application just to run it in some new environment (e.g., a different kind ofworkstation and operating system).

Designing and writing applications using the Java programming language can be done intwo forms. An Applet is a restricted form of the Java language which affords platformindependence. When the application is produced it contains bytecodes which are interpretedat execution time on a specific platform. In a CICS Gateway for Java example, the Javaapplet is stored on an outboard server and downloaded to the web browser on demand. Notonly does the end user receive data to be displayed, but programmed intelligence isdownloaded in the form of the applet so as to act on and manipulate the data withoutfurther reference to the server.

An applet which must be interpreted prior to execution may appear to introduce aperformance overhead concern; however, this is more than offset by the elimination ofbrowser/server interactions (network flows) for simple functions such as page up or down,find specific data, re-order the data, etc.

An applet is restricted in the sense that once downloaded to the browser's machine, itcannot access any data except that which was downloaded with the applet (application). Theintegrity of the applet is verified before execution begins. The other form of using Javais to design and compile full Java applications, which differ significantly from anapplet. A Java application can be compiled as machine code rather than bytecodes whichmust be interpreted at execution time, and full Java applications are not functionallyrestricted and can access any data at execution time. Full Java applications will not bediscussed in this article.

Application versioning and maintenance is an interesting aspect of Java applets.Applets are not retained on individual browers, so that should the application be changed,for whatever reason, only the server copy need be updated. Browsers will always get thelatest copy of the application (applet).

An applet written for use with CICS will contain Java language statements primarily butwill be complemented by CICS-provided statements which can invoke "classlibrary" sub(routines) stored on the CICS server ­ in this case, a server outboardfrom a CICS host. The logic of the Java applet will contain Java statements, and then,where appropriate, a CICS request can be made, which will be executed by the CICS-providedclass library routine. This would include such functions as getting a record from a CICSfile on the host system, or accessing a transient data or temporary storage queue on thehost system.

The CICS Gateway for Java, residing on an outboard server, enables the user-writtenapplet to make requests that can use either the ECI or EPI CICS Client calls. That is, aJava applet can cause a CICS host application to be invoked as though it were LINKed toand given parameters in a COMMAREA (ECI), or it can be invoked and given a 3270 datastream (EPI).

CICS Web Interface (CWI)

The CICS Web Interface was initially delivered with CICS/ESA 4.1, and then laterenhanced with CICS Transaction Server for OS/390. The initial support enabled a Webbrowser to communicate directly with a CICS region on a given MVS image. CWI supportcontains a CICS-provided "TCP listener" MVS subtask to send and receive HTTP/HTML data streams between the Web browser and the CICS region. In a manner of speaking,CICS has provided a Web server (see Figure 2).

When input is received from a Web browser it causes a CICS-provided infrastructure toexecute. A CICS-provided program called the Alias will execute and deal with HTTP inputsand responses. User-written code can be invoked to customize the use of CWI. The user maywish to perform data manipulation in addition to the HTML/EBCDIC conversion done by CWI,or if the user wanted to pass native HTML data streams onto the target CICS application,no data stream conversion need be done.

The initial support of CWI, in contrast to the support introduced with CICS TS 1.2, waslimited to using a CICS LINK command to enter the target CICS application. This support issometimes incorrectly labeled as ECI but in fact an actual EXEC CICS LINK is used to enterthe target application. Assuming the input HTML data stream is converted to EBCDIC, theinput can be parsed into parameters and passed as part of a normal CICS COMMAREA. If theinput HTML data stream is not converted, then the target application must be a relativelynew application, capable of dealing directly in HTML data streams, for some applicationpurpose or objective.

A number of customers were pleased with the introduction of CWI with CICS/ESA 4.1,because it offered a direct path into an MVS CICS region. Some were disappointed, however,because the initial CWI support offered only ECI-like functions and not EPI. That is, somecustomers wanted a direct path to CICS in order to execute CICS 3270 applications, andthis was not possible with the initial CWI support.

CICS Bridge Transaction

A number of major enhancements to the CICS Internet support were delivered as part ofCICS Transaction Server for OS/390 Release 2 (1.2). Among these enhancements were therestructuring of CWI to offer a new interface called the Business Logic Interface (BLI)and also the introduction of the CICS 3270 Bridge transaction and facility (see Figure 3).

BLI now affords input from other than Web browsers to pass through much of the same CWIcode as Web browsers, except not that which deals uniquely with HTTP/HTML data streams.For instance, input may arrive from an MVS batch region or perhaps from an MQSeriessource. BLI enables the user to manipulate input/output data from whatever its source inorder to make it correct for the target CICS application to be entered. CICS applicationsoriginally written to be invoked via a LINK and given a COMMAREA can now also be invokedfrom other sources.

The CICS Bridge Transaction and facility now satisfies the customer wanting directaccess to CICS via the CWI, but with the intent to invoke a CICS 3270 application. Withcorrect resource definitions, a CICS 3270 application can be initiated to run undercontrol of the Bridge transaction and its facilities. The application program is unchangedand can continue to use Basic Mapping Support (BMS) or native Terminal Control (TC) logicto communicate with what it thinks is a real 3270.

BMS or TC commands executed by the CICS 3270 application running under control of theBridge facility are intercepted and User Replaceable Modules (URMs) can be invoked tomanipulate the data to conform to the real source of the transaction's invocation (i.e.,Web browser, MQSeries, MVS batch, etc.).

The CICS TS 1.2 enhancments now enable the customer to have direct connections from Webbrowsers to CICS, without the requirement of an outboard server, and cause execution ofnew or existing CICS 3270 applications. CICS 3270 applications may also now be driven fromother sources such as MVS batch and/or MQSeries.

Access to CICS via an MVS Web Server

Many customers wanting to provide Web access to host systems have always placed a highpriority on security. From the onset, these customers looked to the MVS-provided Webserver for its encryption/decryption services on data streams flowing between Web browsersand any MVS application.

Early support for Web access to CICS regions using an MVS server entailed the writingof something called a "CGI" program (Common Gateway Interface program). IBMprovided a number of examples via ITSO Redbooks and CICS SupportPacs distributed via theCICS Home page on the internet. Whether using an IBM-written sample, or writing one ofyour own, the CGI program would execute as an MVS task and invoke a CICS application usingthe CICS EXCI function (External CICS Interface).

The initial MVS Web server support provided the desired connectivity however itsarchitecture was not suitable for high volumes. The MVS Internet Connection Server (ICS)would attach/ detach MVS subtasks for each Web browser input received. Later MVS Webserver support now provides multi-tasking and reusable MVS task support so as to improveits useability and performance characteristics.

The security aspects of the MVS Web server were emphasized with its new name, the MVSInternet Connection Secured Server (ICSS) (see Figure 4). The MVS Web server has beenfurther enhanced with the incorporation of Domino Go Server and WebSphere facilities.

Assuming a Web browser connects initially to the MVS Web server, a connection from MVSto a given CICS region and program can be made using CICS's EXCI. EXCI is similar to butnot identical to other CICS facilities, such as ECI and DPL. Taken literally, DPL is onlybetween two CICS systems. Taken literally, ECI is between a CICS Client (residing on someoutboard machine (OS/2, NT, etc.) and CICS. EXCI is between a non-CICS MVS region/task andCICS.

Some literature and presentations which intend to describe the MVS interface to CICSperhaps mistakenly refer to it as "ECI" or "ECI-like" but, in fact, itis EXCI which is used. This is technically significant with CICS TS 1.2 or earlier,because if a CICS application alters a protected resource, that update must be committedas part of the return to the non-CICS MVS task. Users with a requirement for long runningapplications should look to CICS TS 1.3 and its new support for Transactional EXCI toremove the restriction of mandatory syncpoints as part of a CICS return to an EXCI caller.

As an aside, DPL and ECI with extend mode can both be used for repetitive calls as partof a long running, conversational, recoverable application.

Prior to CICS TS 1.2, the user was responsible for coding an MVS CGI program tocommunicate with MVS and the Web browser, as well as invoke EXCI and pass parameters in aCOMMAREA to the target CICS application. CICS TS 1.2 now provides assistance in thisregard with the introduction of a CICS-provided DLL which uses MVS' ICAPI (InternetConnection Application Programming Interface).

CICS Gateway for Java on OS/390

The CICS Gateway for Java, on an outboard server, was discussed earlier in thisarticle. Like the CICS Internet Gateway, early customer feedback was appreciative of theCICS support of Java, but some customers did not want a configuration which required anoutboard server (OS/2, NT, etc.).

CICS TS 1.2 has now delivered the CICS Gateway for Java on OS/390. Conceptually, thisoffers the same support as the outboard version, however there is at least one notabledifference. The CICS Gateway for Java on OS/390 resides on OS/390 (MVS) and its supportsonly ECI. That is, unlike the Java support on the outboard server which supports the useof either ECI or EPI in the Java applets, the Java Gateway on OS/390 supports Java appletsuse of ECI only (see Figure 5).

ECI is a bit of a misnomer in this context. The Java applet will contain an "ECIrequest," but it is actually an EXCI request, which is used to communicate from theCICS Gateway for Java on OS/390 to the designated CICS region.

The CICS Gateway for Java on OS/390 does not require an outboard server. Java appletswill be stored on OS/390 and downloaded on demand. The CICS-provided class libraries whichcontain (sub)routines which can be invoked by Java applets are also stored on OS/390.

To Sidebar