It's possible to use containers to pass data in the same way
as communication areas (COMMAREAs) have traditionally been used. However,
channels have several advantages over COMMAREAs (see Benefits of channels)
and it pays to design your channels to make the most of these improvements.
At
the end of a DPL call, input containers that have not been changed by the
server program are not returned to the client. Input containers whose
contents have been changed by the server program, and containers created by
the server program, are returned. Therefore, for optimal DPL performance:
- Use separate containers for input and output data.
- The server program, not the client, should create the output containers.
- Use separate containers for read-only and read-write data.
- If a structure is optional, make it a separate container.
- Use dedicated containers for error information.
Here are some general tips on designing a channel. They include
and expand on the recommendations for achieving optimal DPL performance.
- Use separate containers for input and output data. This leads to:
- Better encapsulation of the data, making your programs easier to maintain.
- Greater efficiency when a channel is passed on a DPL call, because smaller
containers flow in each direction.
- The server program, not the client, should create the output containers.
If the client creates them, empty containers will be sent to the server region.
- Use separate containers for read-only and read-write data. This leads
to:
- A simplification of your copybook structure, making your programs easier
to understand.
- Avoidance of the problems with REORDER overlays.
- Greater transmission efficiency between CICS® regions, because read-only containers
sent to a server region will not be
returned.
- Use separate containers for each structure. This leads to:
- Better encapsulation of the data, making your programs easier to understand
and maintain.
- Greater ease in changing one of the structures, because you don't need
to recompile the entire component.
- The ability to pass a subset of the channel to sub-components, by using
the MOVE CONTAINER command to move containers between channels.
- If a structure is optional, make it a separate container. This leads to
greater efficiency, because the structure is passed only if the container
is present.
- Use dedicated containers for error information. This leads to:
- Better documentation of what is error information.
- Greater efficiency, because:
- The structure containing the error information is passed back only if
an error occurs.
- It is more efficient to check for the presence of an error container by
issuing a GET CONTAINER(known-error-container-name) command (and possibly
receiving a NOTFOUND condition) than it is to initiate a browse of the containers
in the channel.
- When you need to pass data of different types—for example,
character
data in codepage1 and character data in codepage2
—use
separate containers for each type, rather than one container with a complicated
structure. This improves your ability to move between different code pages.
- When you need to pass a large amount of data, split it between multiple
containers, rather than put it all into one container.
When a channel is
passed to a remote program or transaction, passing a large amount of data
may affect performance. This is particularly true if the local and remote
regions are connected by an ISC, rather than MRO, connection.
CAUTION:

Take care not to create so many large containers that you limit
the amount of storage available to other applications.

For information about migrating programs that use COMMAREAs to
use channels instead, see Migrating from COMMAREAs to channels.