Duplicate resource definition names

For all resource types except TDQUEUEs and FILEs, if two groups in a list contain resource definitions of the same name, and of the same resource type, CICS uses the definition in the group that is later in the list.

• For TDQUEUE definitions, the first definition in the list is used.
• For FILE resource definitions for local files, if the file is defined as ENABLED, the later installation of a duplicate fails. However, if the file is defined as DISABLED, the later installation of a duplicate succeeds. For FILE resource definitions for remote files, which are not defined as ENABLED or DISABLED, the installation of a duplicate always succeeds.

If you INSTALL a group while CICS® is active, the resource definitions in the group override any of the same type and name already installed. When an existing resource definition is replaced in this way, the statistics associated with the old resource definition are transferred to the new definition. If a PROGRAM definition is replaced, the program is relocated on the library and loaded when the new definition is referenced for the first time. In effect, the new definition implies a NEWCOPY operation. The same rules apply to map sets and partition sets.

It is probably unwise to have more than one resource definition of the same name on the CSD file, even for different resource types. You must keep PROGRAM, MAPSET, and PARTITIONSET names unique. If you have, for example a PROGRAM and a MAPSET with the same name, only one of them is available to CICS. As far as names are concerned, after installation these definitions are treated as if they were the same resource type. If you require alternative definitions of the same real resource, with different attributes, these resource definitions must be in different groups.

An RDO-defined definition overrides a macro-defined definition of the same name. For example, if you try to install a definition for an SNA LU that has the same name as a non-SNA LU, the SNA LU entry overwrites the non-SNA LU entry.

Installed resources that are defined in CICS bundles cannot be overwritten by resource definitions with duplicate names. When the bundle part containing a resource has been installed, if you try to install a duplicate resource using another CICS bundle, or using RDO, EXEC CICS CREATE commands or other methods, the request is rejected. You also cannot overwrite installed resources with a duplicate resource that is defined in a CICS bundle. When you attempt to install the CICS bundle, if a resource with the same name and resource type exists, the bundle part containing the resource is not installed, and the CICS bundle is placed in an unusable state. Resources that are defined in CICS bundles are therefore protected against accidental overwriting by duplicate resource names.

When you define a private resource in a CICS bundle that is packaged and installed as part of an application, the resource name does not have to be unique in your installation. You can use this facility to avoid resource name clashes between applications that were developed independently, but used the same resource names. The requirement for unique resource names for the supported CICS resources can be removed by managing the resources as part of applications deployed on a platform. You can use this process to assist with server consolidation.

For more information about private resources for applications, see Private resources for application versions.

Use the resource signature to identify the source of duplicate resource definitions that replaced existing installed resources. The resource signature shows when, how, and by whom each resource was defined, changed, and installed. The resource signature is displayed in the CICS Explorer® views, on CEDA and CEMT panels, in CICSPlex® SM BAS and Operations views, by EXEC CICS INQUIRE commands, and in DFHCSDUP reports.