Nov 29 ’10

Connecting CICS to the Internet: An Overview of Available Options

by Editor 

IBM introduced the first CICS Internet connection option in CICS/ESA 3.3, with support for the CICS socket interface option of TCP/IP for MVS. Since then, with each new release—and often between releases via SupportPac offerings—IBM has continued to provide CICS with new Internet connectivity capabilities and features, generating so many support features that it’s difficult to keep up with them all.

This article won’t attempt to cover all the various interface options available to the CICS developer; there are simply too many. Instead, we’ll focus on the most popular, provide a brief overview of the capabilities of each, and list the basic pros and cons. The functions covered are:

A brief discussion of terminology is required before we consider the Internet options. A confusing aspect of discussing CICS connection options is that the phrases often used to describe CICS Internet functionality in general mean something quite different when used technically. The three most significant terms are:

Common misuse of the terms “CICS Web services” or “CICS Web support” to mean CICS Internet support in general, causes confusion and should be avoided.

The 3270 Bridge

Introduced in CICS TS 1.2, the 3270 bridge supports creation of an HTML front-end for 3270-based Basic Mapping Support (BMS) applications without requiring application code changes. The bridge provides for a one-to-one mapping of a 3270 screen to an HTML Web page, but additional functionality can be built into the HTML the utility produces.

Using the 3270 bridge requires minor changes to affected CICS regions; these are documented in the CICS External Interfaces Guide. To enable a program to use the 3270 bridge, reassemble the program’s BMS map using the DFHMAPT procedure found in SDFHPROC. DFHMAPT adds an Application Data Structure (ADS) to the map load module and places an HTML template in the DFHHTML data set. If you don’t have the source for your map, IBM supplies a utility that can create source from the load module, DFHBMSUP, and that generated source can then be used as input for the DFHMAPT proc.

Once DFHMAPT has generated the HTML and related control information, the transaction’s Web front-end can be used in place of the 3270 simply by entering a transaction-specific URL on any Web browser. The HTML, as generated by the DFHMAPT utility, is designed to emulate the look and feel of a 3270 and, as such, is usually inappropriate for end-user access. Fortunately, the HTML generated is fully customizable and you can change it to improve both appearance and usability. For example, you can change the HTML to use a standard company intranet template, change Programmable Function (PF) keys to icons, remove unneeded fields, add drop-down lists of formerly cryptic processing options, etc. Using the 3270 bridge, a fully functional Web front-end to an existing CICS application can be developed and implemented in an afternoon, without any coding changes required.

While there are significant limitations to the 3270 bridge that you must consider before using it, it does support rapid development of Web interface capability at minimal cost.

Besides the functionality previously described, the 3270 bridge facility also includes the “linkable” bridge. The linkable bridge provides the ability to go beyond the 3270 bridge’s one page per 3270 screen limitation by providing an interface where a customer-provided program initiates multiple calls to the 3270 bridge facility to gather several 3270 screens’ worth of data before formatting a single Web page for the end user. For example, the new program could call the linkable bridge to initiate a customer inquiry transaction and then issue “next page” transactions to acquire all of the information about the customer to present to the end user on the same page.

CICS Web Support

CICS Web support refers to the set of Web connectivity features described in the CICS Internet Guide. Additionally, several shared components that are required for CICS to communicate with the Internet are considered part of CICS Web support, including TCP/IP support provided by the sockets domain and UNIX Systems Services support.

The service features provided by Web support include:

To provide the functionality required by these services, CICS Web support includes several utility programs called at various points in the process. CICS Web support lets customers replace the IBM-supplied version of these programs with user-written programs to customize the data flow process. While these aren’t CICS User Replaceable Modules, they do provide a similar service.

IBM provides sample programs for the:

IBM doesn’t provide a sample Converter Program. CICS Web support will function as documented without changing these programs, but you can replace them with a user-written version.

CICS Socket Interface

The CICS Socket Interface (CSI) was the first IBM-supported method to connect CICS to the Internet. CSI is a feature of the z/OS Communication Server; it isn’t part of CICS and doesn’t use the CICS Sockets Domain. It was first supported by CICS/ESA 3.3, and provides an interface to let CICS programs interface directly with the z/OS TCP/IP sockets manager.

CSI uses the CICS Task Related User Exit (TRUE) to interface between the CICS application task and the CSI code running under z/OS Task Control Blocks (TCBs). As originally delivered, CSI managed its own pool of TCBs; with z/OS 1.7, CSI converted to use the CICS Open Transaction Environment (OTE) and now runs on L8 TCBs as a threadsafe resource.

Because CSI isn’t a CICS component, it doesn’t use the EXEC CICS API, but instead uses a call-level interface, where the programmer issues a CALL to a CSI program, passing parameters that describe the request. This interface is extremely fast, has low overhead, and (for z/OS 1.7 and above) provides CICS QR TCB CPU constraint relief by running on an L8 TCB. With this combination of qualities, CSI can support large-volume, strategic applications that require fast response times. Further, because CSI uses the native sockets interface, it can provide a connection to any device or platform that supports TCP/IP.

Information on setting up CICS to run CSI appears in the z/OS Communications Server IP CICS Sockets Guide. The CICS Sockets Guide also contains documentation on using the CSI API and writing programs to support sockets.

CICS Web Services

As we mentioned earlier, CICS Web services is the CICS implementation of the functionality of Web services as defined by the WS-I. Web services is, at its core, an implementation of Service-Oriented Architecture (SOA) that’s devoid of any proprietary methods or architecture. All major technology vendors support it, and it has a robust capability for future growth.

Web services uses the Web Services Descriptor Language (WSDL) to provide a language- and platform-independent method of defining the request and the data that will be passed between the service requester and the service provider. Additionally, all of the information within the WSDL is maintained in XML format, allowing for access by any language that supports XML.

CICS provides utilities to reduce the effort required to add Web services provider support to existing applications by creating the XML and WSDL required from the COBOL data definitions the program uses. Also, a CICS-provided utility will generate COBOL data definitions from existing WSDL, reducing the effort required to add Web services requester capabilities to a CICS program. There are limitations to the capabilities of these utilities, and you should review the functionality of the application before using them.

CICS Web services provides run-time support to automatically parse incoming XML and map its data into the COBOL data layout. Conversely, outgoing data streams will be parsed so CICS can build the XML to hold the data before completing the request.

CICS Web services’ use of industry standard, non-proprietary technology makes it a superb choice when implementing a Business-to-Business (B2B)-type communication capability. Using WSDL insulates both the service requester and provider from application or infrastructure changes; using SOAP and XML provides a standard interface that works across all hardware and software platforms.

Conclusion

Since the initial introduction of CICS support for TCP/IP sockets nearly 20 years ago, IBM has regularly enhanced and expanded CICS Internet connection functionality. CICS support for Web services (the current industry standard for B2B communication) shows that IBM is committed to continuing this process, while its continued support for CSI shows it understands the need to support its customer’s existing software investment.

The wide variety of Internet connection options lets customers select the one that meets their needs, rather than having to settle for a one-size-fits-all solution. For example, high-volume, resource-intensive, strategic applications requiring fast response time may be best-suited to a CICS Sockets Interface solution, while external clients can be offered the industry standard Web services option. For all these needs, CICS Internet support is robust, diverse, and ready to go.