CICSadvanced

Channels and Containers

Understand how channels and containers provide a more flexible, size-unrestricted alternative to COMMAREA for modern CICS program communication.

A COMMAREA is one block with one layout that every program in the chain must agree on. Channels and containers replace it with named pieces.

COMMAREA is one shared suitcase everyone in a travel group must pack according to the exact same agreed layout; channels and containers are separate labeled boxes each person can pack and retrieve independently, so repacking your own box never risks disturbing anyone else's.

Key Concepts

1
The problem being solved. Suppose three programs share a COMMAREA and you add a field in the middle.
2
Every program that copies that layout must be recompiled. Miss one and it reads at the old offsets — no error, just wrong values from that point in the record onwards.
3
That coupling gets worse with every program added, and it is the reason large CICS applications accumulated enormous, carefully versioned COMMAREA copybooks.
4
A channel is a named set of named containers.
    EXEC CICS PUT CONTAINER('CUSTOMER')
         CHANNEL('ORDER-CH')
         FROM(WS-CUSTOMER)
         FLENGTH(LENGTH OF WS-CUSTOMER)
    END-EXEC.
5
    EXEC CICS PUT CONTAINER('ORDER-LINES')
         CHANNEL('ORDER-CH')
         FROM(WS-LINES)
         FLENGTH(WS-LINES-LEN)
    END-EXEC.
6
    EXEC CICS LINK PROGRAM('PGMB') CHANNEL('ORDER-CH') END-EXEC.
7
The called program takes only what it needs, by name:
8
    EXEC CICS GET CONTAINER('CUSTOMER')
         CHANNEL('ORDER-CH')
         INTO(WS-CUSTOMER)
    END-EXEC.
9
Why that decouples things. A program interested only in the customer container is unaffected by changes to the order-lines container. Add a fourth container and nothing that ignores it needs recompiling.
10
Data is addressed by name rather than by byte offset, so a layout change stops propagating through everything that shares the block.
11
No 32K limit. Containers are not capped the way a COMMAREA was, which on its own removed a genuine constraint — applications used to split data across several links purely to stay under it.
12
Other practical gains. A called program can return containers to the caller on the same channel, so results come back the same way. And a container's presence or absence carries meaning — an error container that exists only when something went wrong is cleaner than a status field somebody must remember to clear.
13
The honest position. Channels are the better design and the API is more verbose: several PUT and GET calls instead of one COMMAREA clause.
PUTGETCOMMAREA
14
Plenty of shops still run entirely on COMMAREA and have not migrated. Knowing both, and being able to say why an application would move, is what the question is checking.
15
What the interviewer is probing.1. "What do channels solve that COMMAREA does not?" Probing: the motivation. Stalls: "Nothing." Moves up: the 32KB limit and the single-structure constraint — a channel carries many named containers of any size.
16
2. "How does a program read one?" Probing: the mechanics. Stalls: "Like a COMMAREA." *Moves up:* GET CONTAINER by name from the current channel, so the contract is by name rather than by offset.
17
3. "Why is that better for maintenance?" Probing: the argument. Stalls: "It is not." *Moves up:* adding a container does not shift anything, so programs that do not use it need no change — unlike a COMMAREA layout.
18
4. "What is the migration consideration?" Probing: the practical angle. Stalls: "None." Moves up: both sides must support channels, so conversion is done at boundaries rather than all at once.