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:
CICS TS must always allocate memory to accommodate the return of the maximum COMMAREA structure size.
1. Advantages over COMMAREAs
The containers and channels approach has several advantages over COMMAREAs:
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
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
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).
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.
API to create and manage a channel
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.
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:
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.
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.
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.
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
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
Following is a list of items you may want to consider when migrating from a COMMAREA to channels and containers:
IBM-CICS Related Interview Questions
|VSAM Interview Questions||IBM - VSAM Interview Questions|
|IBM-REXX Interview Questions||JCL Interview Questions|
|IBM DB2 Interview Questions||COBOL Interview Questions|
|IBM-JCL Interview Questions||DB2 Using SQL Interview Questions|
|IBM-JCL&VSAM Interview Questions||IBM Mainframe Interview Questions|
|Mainframe DB2 Interview Questions|
Service-oriented Architecture And Cics
Cics As A Service Provider And Requester
Modern Web Services Development Tools
Development Of The Change Of Address Cics Application
Exposing Our Application As A Web Service
Developing Web Service Clients
Tracing The Change Of Address Scenario
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.