This section describes how you can migrate several types of existing application to use channels and containers rather than communication areas (COMMAREAs).
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’s 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. (See Benefits of channels.)
Because you’re taking the time to change your application programs to exploit this new function, you should implement the "best practices" for channels and containers--see Designing a channel: best practices. Channels have several advantages over COMMAREAs (see Benefits of channels) and it pays to design your channels to make the most of these improvements.
To migrate two programs which use a COMMAREA on a LINK command to exchange a structure, change the instructions shown in Table 13.
Program | Before | After |
---|---|---|
PROG1 |
|
|
PROG2 |
|
|
To migrate two programs which use a COMMAREA on an XCTL command to pass a structure, change the instructions shown in Table 14.
Program | Before | After |
---|---|---|
PROG1 |
|
|
PROG2 |
|
|
To migrate two programs which use COMMAREAs to exchange a structure as part of a pseudoconversation, change the instructions shown in Table 15.
Program | Before | After |
---|---|---|
PROG1 |
|
|
PROG2 |
|
|
To migrate two programs which use START data to exchange a structure, change the instructions shown in Table 16.
Program | Before | After |
---|---|---|
PROG1 |
|
|
PROG2 |
|
|
Note that the new version of PROG2 is the same as that in the pseudoconversational example.
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 that:
EXEC CICS LINK and EXEC CICS START commands, which can pass either COMMAREAs or channels, can be dynamically routed.
When a LINK or START command passes a COMMAREA rather than a channel, the routing program can, depending on the type of request, inspect or change the COMMAREA’s contents. For LINK requests and transactions started by terminal-related START requests (which are handled by the dynamic routing program) but not for non-terminal-related START requests (which are handled by the distributed routing program) the routing program is given, in the DYRACMAA field of its communication area, the address of the application’s COMMAREA, and can inspect and change its contents.
If you migrate a dynamically-routed EXEC CICS LINK or START command to use a channel rather than a COMMAREA, the routing program is passed, in the DYRCHANL field of DFHDYPDS, the name of the channel. Note that the routing program is given the name of the channel, not its address, and so is unable to use the DYRCHANL field to inspect or change the contents of the channel’s containers.
To give the routing program the same kind of functionality with channels, an application that uses a channel can create, within the channel, a special container named DFHROUTE. If the application issues a LINK or terminal-related START request (but not a non-terminal-related START request) that is to be dynamically routed, the dynamic routing program is given, in the DYRACMAA field of DFHDYPDS, the address of the DFHROUTE container, and can inspect and change its contents.
If you are migrating a program to pass a channel rather than a COMMAREA, you could use its existing COMMAREA structure to map DFHROUTE.