Designing a channel: Best practices

Containers are used to pass information between programs. These containers are grouped together in sets called channels. It is advisable to design your channels to follow a set of best practices.

About this task

At the end of a DPL call, input containers that the server program has not changed are not returned to the client. Input containers whose contents have been changed by the server program, and containers that the server program has created, are returned. Therefore, for optimal DPL performance, use the following best practices:
  • Use separate containers for input and output data.
  • Ensure that the server program, not the client, creates 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.

If you are using STARTBROWSE or GETNEXT commands, be aware that the order in which containers are returned is undefined and might change. Applications should not rely on the order of returned containers. If you have existing applications that are written as such, see Upgrading applications for advice.

The following general tips on designing a channel include, and expand on, the recommendations to achieve optimal DPL performance:
  • Use separate containers for input and output data. This provides the following benefits:
    • 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.
  • Ensure that the server program, not the client, creates the output containers. If the client creates them, empty containers are sent to the server region.
  • Use separate containers for read-only and read-write data. This provides the following benefits:
    • 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 provides the following benefits:
    • Better encapsulation of the data, making your programs easier to understand and maintain.
    • Greater ease in changing one of the structures, because you do not need to recompile the entire component.
    • The ability to pass a subset of the channel to subcomponents, 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 provides the following benefits:
    • Easier identification of error information.
    • Greater efficiency, for the following reasons:
      • 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 ) or GET64 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 code page1 and character data in code page2 , 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 might affect performance. This is particularly true if the local and remote regions are connected by an ISC, rather than MRO, connection.

    Attention: Take care not to create so many large containers that you limit the amount of storage available to other applications.
  • Channels and containers use storage below 2 GB (below the bar) and 64-bit storage (above-the-bar). For information on how storage is used and freed, see Deleting channels and containers and freeing their storage . The use of 64-bit storage for channels and containers influences the value that you choose for the z/OS® MEMLIMIT parameter that applies to the CICS region. You must also allow for other CICS facilities that use 64-bit storage. For more information, see Estimating, checking, and setting MEMLIMIT.