Jun 8 ’10
An Overview of CICS Channels and Containers
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.
Figure 1 shows the current channel for a series of programs involved in a sample application.
Typically, programs that exchange a channel are written to handle that channel (i.e., both client and server programs know the name of the channel and names and numbers of the containers in that channel). However, if, for example, a server program or component is written to handle more than one channel, on invocation it must ascertain which of the possible channels it has been passed.
A program can discover its current channel by issuing the EXEC CICS ASSIGN CHANNEL command. If there’s no current channel, this command returns blanks. The program also can retrieve the names of containers in its current channel by browsing, but typically, this isn’t necessary. A program written to handle several channels is often coded to be aware of the names and numbers of the containers in each possible channel. To get the names of the containers in the current channel, use these BROWSE commands:
EXEC CICS STARTBROWSE CONTAINER
EXEC CICS GETNEXT CONTAINER(data-area)
EXEC CICS ENDBROWSE CONTAINER
Having retrieved the name of its current channel and, if necessary, the names of the containers in the channel, a server program can adjust its processing to suit the kind of data it has been passed. For a program creating a channel, the EXEC CICS ASSIGN CHANNEL command will return blanks unless the program issuing the command was invoked via an EXEC CICS START, EXEC CICS LINK or EXEC CICS XCTL command specifying a channel name.
Scope of a Channel
The scope of a channel is the code (i.e., the program or programs) from which it can be accessed. Figure 2 shows the scope of channel CHANNEL1, which consists of program A (the channel that created it), program B (for which it’s the current channel), and program C (for which it’s also the current channel). Additionally, we show the scope of channel CHANNEL2, which consists of program D (which created it) and program E (for which it’s the current channel).
Lifetime of a Channel
A channel is created when it’s named on an EXEC CICS command. The usual command to create a channel is the EXEC CICS PUT CONTAINER command, in which specifying the CHANNEL parameter will create the channel and also associate the container with it.
A channel will be deleted when it goes out of scope to the programs in the linkage stack of application programs CICS currently is using, meaning that no programs will be able to access it. This will cause CICS to delete the channel.
The data conversion model channel applications use is much simpler than the model COMMAREA applications use, as the CICS systems programmer controls data conversion in COMMAREA applications, whereas in channel applications, it’s used by the CICS application programmer, using simple EXEC CICS API commands.
Here are some cases where data conversion is necessary:
- When character data is passed between platforms that use different encoding standards (e.g., EDCDIC and ASCII)
- When you want to change the encoding of some character data from one Coded Character Set Identifier (CCSID) to another.
For applications that use a COMMAREA to exchange data, the conversion occurs under the control of the CICS systems programmer, who uses the DFHCNV conversion table, DFHCCNV conversion program and, optionally, DFHUCNV user-replaceable conversion program. By contrast, the data conversion model channel applications use is much simpler than what COMMAREA-based applications use. The data in a channel and container application is converted under the control of the CICS application programmer, who issues EXEC CICS API commands.
The CICS application programmer is responsible only for conversion of user data (i.e., data in containers created by the application programs). CICS automatically converts system data, where necessary. Additionally, the CICS application programmer is concerned only with conversion of character data. The conversion of binary data isn’t supported.
Applications can use the EXEC CICS CONTAINER API as a simple means of converting character data from one code page to another. Figure 3 converts data from codepage1 to codepage2. When you use the combination of EXEC CICS commands shown in Figure 3 for data conversion, remember to add a temporary channel as shown in the CHANNEL(temp) parameter. Otherwise, you’re relying solely on the program having a current channel, and this may not always be the case. Also, if the data is large, you should perform an EXEC CICS DELETE CONTAINER immediately after the EXEC CICS GET CONTAINER statement.
Migrating to Channels and Containers
To migrate programs exchanging data via a COMMAREA on an EXEC CICS LINK command, the format of the command must be changed and EXEC CICS CONTAINER API commands must be added to use channels and containers instead.
Figure 4 shows that Program B doesn’t specify a channel operand on its EXEC CICS CONTAINER commands, thus defaulting to its current channel. The same applies to programs using an EXEC CICS START command, as shown in Figure 5.
When migrating from COMMAREAS to channels and containers, keep these considerations in mind:
- CICS application programs that use traditional COMMAREAs to exchange data will continue to work as before.
- EXEC CICS LINK and EXEC CICS START commands, which can pass either COMMAREAs or channels, can be dynamically routed.
- If you employ a user-written dynamic or distributed routing program for workload management, rather than CICSPlex, you must modify your program to handle the new values that it may be passed in the DYRLEVEL, DYRTYPE and DYRVER fields of the DFHDYPDS communications area.
- It’s possible to replace a COMMAREA by a channel with a single container. While this may seem the simplest way to move from COMMAREAs to channels and containers, it isn’t good practice to do this. You should, instead, consider using separate containers for each logically separate data structure in your COMMAREA. This is beneficial for several reasons such as separating input and output data fields, or fields containing different data types. In addition, the use of multiple containers to separate the data structures of the COMMAREA serves to make the data layout more readable and much easier to understand.
- In previous releases of CICS, because the size of the COMMAREA was limited to 32KB and channels weren’t available, some applications used Temporary Storage Queues (TSQs) to pass more than 32KB of data from one program to another. Typically, this would involve multiple readqs and writeqs to a TSQ. If you migrate such applications to use channels, be aware that:
◆ If the TSQ your existing application uses is in main storage, the storage requirements of the new, migrated application are likely to be similar to those of the existing application. Both TSQ data and container data reside in the CICS address space.
◆ If the TSQ your existing application uses is in auxiliary storage, the storage requirements of the migrated application are likely to be greater than those of the existing application. This is because container data is held in storage (above the line, but below the bar) rather than written to disk.
Since the lifecycle and scope of channels and containers are completely under the control of the CICS system, data integrity and storage resource management can be ensured. Additionally, the use of channels and containers also offers an unconstrained, CICS-supported method of passing data alongside a CICS standard API for optimized exchange of data between CICS programs implemented in CICS-supported languages. A simple, explicit code page conversion technique also is available, as is the freedom to dynamically determine the nature of the passed data and thereby select the appropriate processing required. Z
• IBM Redbook: CICS Transaction Server V3.1 Channels and Containers Revealed (SG24-7227-00)
• CICS Transaction Server for z/OS Version 3.1 Application Programming Guide (SC34-6433-02).