Channels and containers IBM-CICS

Essentially the use of channels and containers provides a solution to the 32KB limit imposed on the traditional CICS COMMAREA in order to accommodate modern applications. There is now a need for considering how you currently handle data exchange and whether implementing this new function will benefit your application design needs.

Consider some of the COMMAREA issues you may face when handling large data objects:

  1. Applications must use a circumvention technique, such as using external VSAM files or splitting the data into separate parts. This method increases risk as well as programming time and effort.
  2. Passing XML documents by value throughout the request process path becomes inhibited because the size constraint applies to the following:
    • Calls between CICS programs both within the local system and between CICS system
    • Parameter data passed between CICS tasks
    • External client programming interfaces such as CICS interface (EXCI and the CICS client external call interface (ECI)
  3. Data structures used to define a COMMAREA payload can become overloaded. Redefining structures on the same area of memory increases the risk of program errors. Similarly, confusion about the validity of fields can result in application programming errors.
  4. An overloaded COMMAREA structure increases transmission time between CICS regions because the structure size must account for the maximum size of the data that could be returned from the called program—and this parameter size depends on the request logic invoked.
  5. CICS TS must always allocate memory to accommodate the return of the maximum COMMAREA structure size.

  6. A code-page conversion of COMMAREA structure is complex because binary and character data cannot be easily separated.

1. Advantages over COMMAREAs

The containers and channels approach has several advantages over COMMAREAs:

  • Containers can be any size and, as a result, can extend beyond the maximum 32KB size of a COMMAREA. There is no limit to the number of containers that can be added to a channel, and the size of the individual containers is limited only by the amount of storage available.
  • A channel consists of multiple containers, enabling it to be used to pass data in a more structured way. In contrast, a COMMAREA is a single block of data.
  • Unlike COMMAREAs, channels do not require the programs that use them to know the exact size of data returned, making programming easier.

2. Channels

A channel is a uniquely named reference to a collection of application parameter data held in containers. Its analogous to a COMMAREA but is not subject to the constraints of a COMMAREA.

You can choose a channel name that is a meaningful representation of the data structures that the channel is associated with. For example in a human resource application a channel name might be .

This collection of application parameter data serves as a standard mechanism to exchange data between CICS programs.

CICS TS provides an EXEC API that associates a named channel with a collection of one or more containers—offering an easy way to group parameter data structures to pass to a called application. CICS TS removes a channel when it can no longer be referenced—when it becomes out of scope.

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 the control to the called program via a LINK, XCTL, START, and pseudo-conversational RETURN with the channel parameter.

Although the program can create other channels, the current channel, for a particular invocation of a particular program, never changes. It is analogous to a parameter list.

If a channel is not explicitly specified, the current channel is used as the default value for the CHANNEL (channel-name) parameter on the EXEC CICS command. This is shown in the figure.

The-current-channel

The current channel

Typically, programs that exchange a channel are written to handle that channel. That is, both client and server programs know the name of the channel and the names and number 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 discover which of the possible channels it was passed.

A program can discover its current channel—that is, the channel with which it was invoked—by issuing an EXEC CICS ASSIGN CHANNEL

The program can also retrieve the names of the containers in its current channel by browsing, but typically, this is not necessary. A program written to handle several channels is often coded to be aware of the names and number of the containers in each possible channel.

Example: Browsing containers in a channel

Example: Browsing containers in a channel

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 that it was passed.

The scope of a channel

The scope of a channel is the code (for example, the program or programs) from which it can be accessed.

Figure shows the scope of channel EMPLOYEE-INFO, which consists of programs A (the program which created it), program B (for which it is the current channel), and program C (for which it is also the current channel). Additionally, we show the scope of channel MANAGER-INFO, which consists of programs D (which created it) and Program E (for which it is the current channel).

The scope of a channel

Example showing the scope of a channel

Lifetime of a channel

A channel is created when it is 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 creates the channel and also associates the container with it.

A channel is deleted when it goes out of scope to the programs in the linkage stack, meaning that no programs can access it. This will cause the channel to be deleted by CICS.

This shows the APIs used to create and manage a channel.

Lifetime of a channel

API to create and manage a channel

3. Containers

A container is a uniquely named block of data that can be passed to a subsequent program or transaction. It refers to a particular parameter data structure that exists within a collection of virtually any form of application parameter data.

You can choose a container name that is a meaningful representation of the data structure. For example, in a human resource application, the container name might be .

CICS TS provides EXEC API verbs to create, delete, reference, access, and manipulate a container as well as to associate it with a channel.

Containers

Container related API

A container can be any length, and a container size is constrained only by the available user storage in the CICS address space.

It can include data in any format required by an application. An application can create any number of containers and can use separate containers for different data types, such as binary and character data. This capability helps ensure that each container structure is based on a unique area of memory.

It also minimizes the potential for errors that commonly arise when parameter data for multiple applications is overloaded in a single memory area, by isolating different data structures, and making the association between data structure and purpose clear.

CICS read-only containers

CICS can create channels and containers for its own use and pass them to user programs. In some cases CICS marks these containers as read-only, so that the user program cannot modify data that CICS needs to return from the user program.

User programs cannot create read-only containers.

You cannot overwrite, move, or delete a read-only container. Thus, if you specify a read-only container on a PUT CONTAINER, MOVE CONTAINER, or DELETE CONTAINER command you will receive an INVREQ condition.

4. Data conversion

The data conversion model used by channel applications is much simpler than the data conversion model used by COMMAREA applications. This is because data conversion in COMMAREA applications is controlled by the system programmer, whereas in channel applications it is controlled by the application programmer using simple API commands.

Here are some cases where data conversion is necessary:

  • When character data is passed between platforms that use different encoding standards—for example, EBCDIC, and ASCII.
  • When you want to change the encoding of some character data from one Coded Character Set Identifier (CCSID) to another.

Applications that use Channels to exchange data use a simple data conversion model. Frequently, no conversion is required, but when conversion is required, a single programming instruction can be used to tell CICS to handle it automatically.

Using COMMAREAs

For applications that use the COMMAREAs to exchange data, the conversion is done under the control of the system programmer using the DFHCNV conversion table, the DFHCCNV conversion program, and optionally the DFHUCNV user-replaceable conversion program.

Using channels

The data conversion model used by channel applications is much simpler than that used by the COMMAREA applications. The data in channels and containers is converted under the control of the application programmer using API commands.

  • The application programmer is responsible only for the conversion of user data—that is, the data in containers created by the application programs. System data is converted automatically by CICS, where necessary.
  • The application programmer is concerned only with the conversion of character data. The conversion of binary data (between big-endian and little-endian) is not supported.
  • Applications can use the container API as a simple means of converting character data from one code page to another. Example converts data from codepage1 to codepage2:Using channels

Example API to convert codepage

5. Migrating COMMAREA to channels and containers

To migrate programs exchanging data via a COMMAREA on a LINK command, the format of the command must be changed and proper commands must be added to use channels and containers. Figure shows an example of this

Changes from commarea to channels using LINK

Changes from commarea to channels using LINK

The same applies to programs using the START command with the COMMAREA. Figure shows an example of this.

Changes from commarea to channels using START
Changes from commarea to channels using START

Migration consideration

Following is a list of items you may want to consider when migrating from a COMMAREA to channels and containers:

  • 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 SM, 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 is 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 is not good practice to do this.
  • Also, be aware that a channel may use more storage than a COMMAREA designed to pass the same data. Because you are taking the time to change your application programs to exploit this new function, you should implement the "best practices" for channels and containers.
  • Channels have several advantages over COMMAREAs, and it pays to design your channels to make the most of these improvements.
  • In previous releases, because the size of COMMAREAs is limited to 32K and channels were not available, some applications used temporary storage queues (TSQs) to pass more than 32K of data from one program to another. Typically, this involved multiple writes to and reads from a TSQ. If you migrate one of these applications to use channels, be aware of the following:
  1. If the TSQ used by your existing application is in main storage, the storage requirements of the new, migrated application are likely to be similar to those of the existing application.
  2. If the TSQ used by your existing application 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 rather than being written to disk.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

IBM-CICS Topics