How it works: CICS resources
For CICS to support such a great range of businesses and types of applications, it must be flexible. A key part of CICS flexibility is the way that it defines and processes the resources that it needs and how resources are defined and managed separately from the applications that use them.
What is a CICS resource?
CICS identifies a set of elements that are used by itself or by applications as resources. For example, some resources are used by applications, such as files, data queues, and web services. Some resources define communication, such as connections, sessions, and URI maps. Other resources define system resources, such as journaling and the JVM server environment. CICS supplies a set of resources that must be installed on your CICS region and definitions of the resources that are used by the sample application programs (see Supplied resource definitions, groups, and lists). Other resource definitions are up to you. You can see a complete list of resources in here.
Each instance of a resource needs to be defined to CICS in a resource definition. CICS provides a number of ways for you to create and modify resource definitions. These methods are described in How you can define CICS resources. After a resource definition is created, it must be installed for CICS to be able to use it.
In this documentation, CICS resource definitions are normally shown in uppercase: for example, WEBSERVICE.
You define and modify resources with a set of attributes. The attributes are the properties of the resource, telling CICS, for example, whether a file can be updated, what security level should be given to a transaction, or the remote systems with which CICS can communicate.
How CICS uses resources
You define the resource using one of a number of available methods. These methods, and the interfaces that control them, are described in How you can define CICS resources.
The resource definition is stored in a repository, according to the method of resource definition that you used. See Where resource definitions are held.
You install (or deploy, for CICS bundles) the resource definition to make it available for CICS to use. When a resource definition is installed or deployed, information about the resource is used to construct the data structures that represent the resource in the CICS address space. Find out more about installing resources in Resource definition installation.
You can modify installed resource definitions, again using one of a number of available methods. Find out more about this in How it works: Resource definition overrides.
Where resource definitions are held
The repository for the resource definition depends on how it is defined.
- CICS system definition file
- The CICS system definition data set (CSD) is a VSAM data set that contains a resource definition
record for every resource that is defined to CICS through
CEDA, CICS Explorer, the CSD update batch utility program DFHCSDUP,
or EXEC CICS CSD commands. The CSD is defined to CICS as a VSAM file called
DFHCSD, so in CICS documentation, the terms CICS system definition data set (CSD),
CICS system definition file (CSD), CSD file, DFHCSD file and
CSD mean the same and are used interchangeably.
Resources in the CSD can be organized into groups and lists.
You can change the contents of the CSD without interfering with a running CICS region that uses the CSD. When you install the definitions in the CICS region, CICS copies the information from the CSD and keeps it in its own storage. You can also change the definitions in the running region by reinstalling them, or add more definitions by installing new resources. You can define the CSD file as recoverable, so that changes that are incomplete when an abend occurs are backed out. You can also share a CSD file and its resource definitions with different CICS regions, including regions at different releases.
Following initialization, the CSD file contains two categories of resource definition groups:- Groups named in DFHLIST: these are essential for using Resource Definition Online (RDO) and other CICS transactions.
- Groups of definitions for the sample application programs. For details, see Sample application program groups.
For information, see Setting up the CICS system definition data set.
- CICSPlex® SM data repository
- The data repository is a VSAM key-sequenced data set (KSDS) that is created for each CMAS, using
a CICSPlex SM post-installation job. Resource definitions that are created through CICSPlex SM
Business Application Services (BAS) are stored here.
For information, see Creating and populating the CICSPlex SM data repository.
- The global catalog
- The global catalog is a VSAM key-sequenced data set (KSDS) that CICS uses to save all resource
definitions that were installed when CICS shut down. Resource definitions that are created with EXEC
CICS CREATE commands and resource definitions that are amended with resource definition overrides
are recorded in the CICS global catalog.
For information, see Defining the global catalog.
- z/FS
- z/OS File System (zFS) is the primary type of z/OS UNIX file system and is widely used with CICS. zFS is part of the Distributed File Service base element of z/OS. CICS support for Java™, Node.js, Web services, and feature toggles all store some of their configuration files in zFS. Bundles and some other artifacts in application deployment are used from zFS and some applications, such as Java and Node.js, store logs there.
- Resource control tables
- For CICS system initialization, you configure a system initialization table (SIT) and, through the SIT, CICS selects other control tables. Each control table is created separately and can be re-created at any time before system initialization. You prepare the required control tables by coding the appropriate macros. Resources that cannot be defined in the CSD are held in CICS control tables.
Organizing resources: bundles, groups and lists
- CICS bundle
- A CICS bundle is a directory that contains artifacts and a manifest that describes the bundle and its dependencies. CICS bundles provide a way of grouping and managing related resources. CICS bundles also provide versioning for the management of resource updates, and can declare dependencies on other resources outside the bundle. Some characteristics of CICS resources change when they are defined in a CICS bundle and dynamically created as part of a bundle deployment. The life cycles of CICS resources that are created in this way cannot be managed independently of the BUNDLE resource; they must be managed through the CICS bundle as a unit.
- Group (CSD resources only)
- A group is a collection of related resources on the CSD. Each resource that you define must belong to a group; you cannot define a resource without naming the group. You can choose how to define the group, but typically you might associate the resources for one application into a group. You might group communication resources by location or by application. There can be only one resource of a particular type and name in a group. For example, you cannot have two transactions named AP01 in the same group.
- List (CSD resources only)
- A list contains the names of CSD resource groups that CICS installs at an initial or cold start. Groups are associated with a list to provide a collection of the CSD resources that are needed for one CICS region or execution. When the region starts, it can install resources from up to four lists that you specify in the startup parameters. You can add groups to lists if you want them installed at an initial or cold start, or if it helps you to manage your groups better. Groups do not have to belong to lists, and can be defined independently. The same group can be placed in several lists.