Ever since command-level programming was introduced in CICS in 1975, an in-memory process called the communications area (COMMAREA) has been used to pass data from one application to another. From its inception, the size of the COMMAREA was held in a half-word data field— the EIBCALEN—which limited the size of the COMMAREA to 32KB. Although this was a problem, since most application data was 3270-based and not, therefore, particularly resource hungry, the 32KB limit was sufficient to manage data propagation between applications. However, with the advent of Web-based applications, today’s CICS applications are required to process larger quantities of structured parameter data in both XML and non-XML formats, meaning the constraints imposed on the COMMAREA size by the 32KB limit are too restrictive. Furthermore, if an XML document has to be exchanged, the parameter data contained in it is quite different from the data format historically known to CICS programmers.
While the COMMAREA remains the basic way to pass data between traditional CICS application programs, a new way to exchange data is needed, in parallel with the COMMAREA solution, to satisfy the requirements introduced with use of new application programming styles.
CICS Transaction Server V3.1 introduces a new approach that provides an easy, more flexible mechanism for exchanging large volumes of structured parameter data between CICS applications. This new approach is known as the channels and containers model. As well as being available from the EXEC CICS Application Program Interface (API), it’s also used extensively in the internals of CICS Web services support.
Channels and Containers Concepts
A container is a named reference to a CICS-managed storage area that can hold any form of application data. A container can be any size and can hold data in any format required by the application. An application can reference any number of containers. CICS provides EXEC CICS API verbs to create, delete, reference, access and manipulate a container and associate it with a channel.
A channel is a uniquely named reference to a collection of application data held in containers. A channel is analogous to a COMMAREA, but it lacks the constraints of a COMMAREA. CICS provides EXEC CICS API verbs that associate a named channel with a collection of one or more containers, making it an easy way of grouping data structures to pass to a called application. CICS will automatically destroy a channel when it can no longer be referenced— a point at which the channel is considered “out of scope.”
Using channels and containers provides you with a simpler, application-based method of performing data conversion.
The Current Channel
A program’s current channel is the channel (if any) with which it was invoked. The current channel is set by the calling program or transaction by transferring control to the called program via an EXEC CICS LINK, EXEC CICS XCTL, EXEC CICS START or pseudo-conversational EXEC CICS RETURN command with the CHANNEL parameter specified.
Although the program can create other channels, the current channel for a particular invocation of a specific program never changes. It’s analogous to a parameter list. Clearly, therefore, the first program in a particular application, although it may well create a channel with which it will invoke another program, doesn’t itself have a current channel. A program can only have a current channel if it was invoked with a channel. If a channel isn’t explicitly specified, the current channel is used as the default value for the CHANNEL parameter on the EXEC CICS command used to start the program or task.