A data-container is a named area of storage, maintained by BTS.
Each data-container is associated with an activity or process. It is identified by its name and by the activity for which it is a container. An activity can have any number of containers, as long as they all have different names within the scope of the activity. For example, several activities can each have containers named "Input", "Output", and "State".
An activity’s data-containers serve as its working storage. They can be read and updated by the activity itself, by the activity’s parent, or by a program that has "acquired" the activity (see Acquiring processes and activities). Because they are preserved across multiple activations of the activity, they can be used to hold state data, or inputs and outputs for the activity. They are recoverable resources, being written to disk as necessary, and restored at system restart.
Just like an activity, a process may have a set of data-containers associated with it. These are called process containers: every activity in the process can access them, but only the root activity3 can update them.
Before running a process, the program that creates it can:
Alternatively, the root activity can create and set the process containers.
An activity’s data-containers have the same lifetime as the activity itself. They are only destroyed when the activity itself is destroyed. While a child activity exists, its data-containers are always accessible to its parent, whatever processing mode the child is in (including complete).
If you issue a DELETE ACTIVITY command against an activity, bear in mind that you will destroy the activity’s containers. It’s usually best to allow activities to be deleted automatically by CICS®. For child activities, this happens when the activity’s parent completes. At this stage, the parent no longer needs access to its children’s containers. If the parent is reset and re-run, it will recreate its child activities.