Nov 29 ’10
Connecting CICS to the Internet: An Overview of Available Options
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:
- The 3270 Bridge
- CICS Web Support
- The CICS Socket Interface
- CICS Web services.
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:
- CICS Web services relates specifically to CICS support for Web services functionality as defined by the Web Services Interoperability Organization (WS-I) Basic Profile 1.1 Web Services statement.
- CICS Web support relates to a specific subset of CICS-provided services, which are designed to facilitate communication between CICS application programs and the Internet.
- CICS Sockets Interface defines the CICS-specific support provided by the z/OS Communication Server, and not to any functionality provided by CICS or the CICS Sockets domain.
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:
- The EXEC CICS WEB and EXEC CICS DOCUMENT Application Program Interfaces (APIs). Application programs can use these commands to interface with the Internet via HTTP. For example, a programmer could design a Web page to call CICS, passing an HTTP stream to a Web-aware program. The CICS program would then use the WEB commands to analyze the incoming HTTP and identify the request. After processing the request normally, the program would then use the WEB and DOCUMENT commands to build an output HTTP stream that would present request results to the user. This functionality can be used to make CICS an HTTP client, too, allowing a CICS program to access data or services available on the Web but not on the mainframe.
- For existing CICS programs that return data to a calling program via Commareas, CICS Web support provides for a user-written “converter” program that intercepts the transmission from the Web, converts it into an acceptable Commarea format, LINKs to the application processing program, and then converts the returned Commarea back into an HTTP stream for transmission to the original requester.
- For existing CICS applications using 3270 displays, CICS Web support provides several alternatives that let the programmer convert incoming HTTP to a 3270 data stream, pass that data stream to the application program (as if it had come from a terminal), receive the outgoing 3270 data stream and convert it to HTTP, and return the HTTP to the caller. The processes involved resemble the 3270 bridge facility and use some parts of the 3270 bridge architecture, but the support for 3270-to-HTTP connectivity is more extensive with CICS Web support than the support in the 3270 bridge.
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:
- Analyzer Program, which is called after the HTTP stream has been accepted from the Web
- Web Error Program, which is called when an abend or other error occurs
- Web Terminal Translation Application, which is called to convert outgoing 3270 data streams into HTML, using the 3270 bridge facility
- Password expiry management program, which is called to allow a user to define a new password if theirs has expired.
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.
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.