Creating a resource model

A resource model is a mandatory CICS® TS resource builder component. It defines the standards that must be used for resource definitions.

System programmers create the resource model and define:

  • The set of resources and attributes that a developer is allowed to define. These are model-defined resource types. See Model-defined resource types for details.
  • Naming constraints on resource attribute values, to apply to all attributes or per application. See Constraints.
  • Which attributes cannot be modified by a developer. These are private attributes. Public attributes can be modified by a resource definitions YAML file. See Public and private attributes.

The resource model uses opt-in control. Unless a CICS resource type is explicitly added to the resource model, it cannot be used in the application developer's resource definitions YAML file. Unless a resource attribute is explicitly defined as public in the resource model, it cannot be used in the application developer's resource definitions YAML file.

The system programmer creates YAML to represent the resource model. A resourceModel block is always required; an application block provides application-level control. These YAML blocks go into a resource model YAML file and an application constraints YAML file, respectively (see Resource model files). A resource model schema is supplied with CICS TS resource builder to help in constructing the resource model YAML file.

You can create a resource model from existing CSD resource definitions by using the CICS TS resource builder import capability. For details, see Importing existing CSD resource definitions.

Tip icon Tip: See Tutorial: creating a resource model YAML file to see examples of how to use model-defined types, public and private attributes, and application constraint identifiers, including how to use an IDE to create and validate the resource model YAML.

Role icon Application developer

The application developer creates a resource definitions YAML file of the resource definitions for the application by selecting a model-defined resource type and working with any public attributes. Only resource definitions that match a model-defined resource type in the resource model are considered valid resource definitions by the CICS TS resource builder when the resource definitions YAML file is processed and a DFHCSDUP commands file is built.

The zrb generate command can be used to generate a resource definitions schema from the resource model YAML. The generated resource definitions schema contains information about the model-defined resource types created in the resource model YAML. If application developers use this schema in their IDEs, it validates that the contents of the resource definitions YAML file satisfy both the requirements of YAML syntax and of the resource model.

Model-defined resource types

Model-defined resource types, specified in the resource model, map (and constrain) the type and attributes of CICS resource definitions to your system environment. When CICS TS resource builder runs, resource definitions can be created or modified only by using your model-defined resource types. Model-defined resource types are distinct from types of CICS resource to give you flexibility in matching the needs of your environment. For example, you can have extra granularity in your resource model by defining multiple model-defined resource types that correspond to a single type of CICS resource. A type of CICS resource is URIMAP. You might decide to have a model-defined resource type of URIMAP resources with USAGE(CLIENT) and another model-defined resource type of URIMAP resources with USAGE(SERVER).

Constraints

Constraints are naming restrictions that can be applied to the value of any resource attribute that takes a string value.

Naming constraints can be used to:

  • Enforce the use of a prefix
  • Comply to a regex (regular expression) pattern
  • Set the name to a fixed value.

For example, you can use a prefix constraint to define that the group of a TRANSACTION resource must begin with the characters APP1.

Constraints can apply to all applications when they are defined in the resourceModel YAML or to specific applications when they are defined in the application YAML.

Public and private attributes

Attributes of resources are specified as either public or private. Public attributes can be defined by the application developer's resource definitions YAML file. Private attributes are defined only in the resource model and cannot be defined by the application developer's resource definitions YAML file.

Resource model files

The resource model YAML blocks go into the following files:

If you are creating a very simple model that does not differentiate between applications (for example, for getting started), you can include the application YAML block in the resource model file (see Getting started with a simple model for an example of a combined resourceModel and application resource model file.) Typically, the application YAML block is in a separate application constraints file.

You can store the individual application constraints YAML files along with a single resource model file in a source control management system within a DevOps pipeline. To generate or build the application-specific outputs, the pipeline pulls in the same resource model YAML file but pulls in the application constraints YAML file that is specific to the required application resource definitions.

The resource model files are mandatory input to the following CICS TS resource builder commands, as illustrated in Architecture:

  • The zrb build command, which uses the resource model to validate that the resource definitions YAML file, which is used by the resource builder to build the DFHCSDUP commands file, aligns with the resource model.
  • The zrb generate command, which generates a resource definitions schema that can be used in an application developer's IDE to create a valid resource definitions YAML file.

Find out more