CICS / WebSphere

Since it was introduced in 1993 under the MQSeries name, IBM’s WebSphere MQ messaging integration middleware product has allowed systems and applications to be connected, regardless of the platform or environment. WebSphere MQ can, for example, allow a desktop application to communicate seamlessly with an IBM CICS transaction that’s running on the IBM z/OS operating system.

Here we explore the way in which the relationship between WebSphere MQ and CICS has developed and been enhanced over recent versions of CICS.

The Open Transaction Environment History
Within CICS The CICS Open Transaction Environment (OTE) has been implemented and enhanced across many releases of CICS; its functionality and range of features have grown from release to release.

CICS TS 1.3 was the first release to support OTE. It introduced J8 Task Control Blocks (TCBs) to allow Java Virtual Machines (JVMs) to execute inside CICS and run user Java applications (Java class files). After this support was provided in the base version of the release, support for compiled Java (“hotpooled” Java programs) was added via PTF; this exploited H8 OTE TCBs.

Note: Hotpooling was a temporary solution to Java programming within CICS; the JVM is the strategic platform for running Java programs inside CICS and hotpooling support has since been removed from later releases.

CICS TS 2.2 provided a new open TCB mode (the L8 mode) to allow OPENAPI Task-Related User Exit (TRUE) programs. CICS TS 2.2 allowed DB2 to exploit OTE and use L8 open TCBs to process DB2 requests from CICS via the RMI interface for TRUEs.

Defining CICS applications with a CONCURRENCY program attribute of THREADSAFE instead of the default value of QUASIRENT meant control could return to the user program on the L8 TCB that had been used for the DB2 request, rather than having to switch back to the quasi-reentrant (QR) TCB. Threadsafe programs could therefore execute on an L8 TCB and run in parallel with other non-threadsafe applications executing on the QR TCB. This let CICS better exploit multiprocessor environments. In addition, CICS made parts of the EXEC CICS API threadsafe in order to avoid the need for such threadsafe applications to have to switch back to the QR TCB to execute subsequent EXEC CICS commands.

CICS TS 3.1 supported additional open TCB modes, including J8 and J9 TCBs (for CICSkey and user-key Java applications), L9 TCBs (along with L8s, for CICS-key and user-key programs respectively), and X8 and X9 open TCBs for XPLINK operations in CICS. The CICS Security domain utilized the SO, SL, SP and S8 TCBs. In addition, the OPENAPI attribute was enhanced to allow applications to execute under open TCBs, much as TRUEs could do in earlier releases. CICS also exploited OTE internally; for example, when accessing doctemplates and HTTP static responses stored on zFS, when processing parts of Web service requests and when handling Extensible Markup Language (XML).

CICS TS 3.2 extended the threadsafe TRUE environment to allow the CICS-WebSphere MQ interface to exploit open TCBs, just as DB2 had done before. CICS TS 4.1 introduced T8 TCBs for the JVM server environment, and CICS TS 4.2 extended the threadsafe environment to position the CICS DBCTL interface to also exploit open TCBs.

CICS TS 4.2 introduced the CONCURRENCY(REQUIRED) option for applications. Such programs must be written to threadsafe standards. CICS will start them running on an open TCB and ensure the program always runs on an open TCB. For CICSAPI programs, if a CICS application program is defined with an attribute of CONCURRENCY(QUASIRENT), it will always execute on the QR TCB. If defined as CONCURRENCY(THREADSAFE), it will execute on the TCB in use by CICS at the time, and if defined with CONCURRENCY(REQUIRED), the program will always run on an open TCB (although the QR TCB is still used to actually initialize the transaction before handing control to the program on the open TCB).

2 Pages