Scoping of bundles

The BUNDLE resource definition provides the BASESCOPE attribute as a way of applying a scope to related BUNDLE resources. You can use this attribute for bundles that are deployed on a platform, or to set a Service Component Architecture (SCA) domain for a bundle that contains SCA composite applications.

BASESCOPE is an optional attribute on the BUNDLE resource definition that you can use in different ways. You can use the IBM® CICS Explorer® to view all of the BUNDLE resources that are defined in a CICS® region and order them by the value of the BASESCOPE attribute.

Scoping of bundles for a platform

CICS bundles that are deployed on a platform automatically have a BASESCOPE applied when the BUNDLE resource is created during an application deployment. A BUNDLE resource that is deployed on a platform as part of an application bundle or an application binding bundle has a URI in the BASESCOPE attribute with the following format:

cicsapplication://Platform/ApplicationID/MajorVersion/MinorVersion/MicroVersion

Platform is the name of the platform, ApplicationID is the ID of the application bundle, followed by the major, minor, and micro version of the application.

CICS uses the BASESCOPE attribute to identify the relevant application and version, so that multiple versions of the same application can be installed on a platform. The BASESCOPE attribute can be used to restrict resources to the appropriate version of the application. For example, certain supported resource types that are defined in a CICS bundle, then packaged and installed as part of an application bundle or application binding bundle, are private to that version of that application. For more information about private resources for applications, see Private resources for application versions.

The same cicsapplication format basescope can be added to CICS bundles that are outside of a platform environment. This is useful in a single CICS region (SMSS) where you do not have a platform and applications. In the SMSS case, it is the responsibility of the user to ensure that the basescope is properly specified, whereas in a platform CICS automatically generates the correct basescope attribute.

Scoping of bundles for a policy

Policies are defined in CICS bundles. In a platform, policies are deployed to a specific scope. The scope can be an application scope, an operation (within an application) scope, or a platform scope. For more information, see Policy scopes.

Scoping of bundles into SCA domains

The BASESCOPE attribute has a specific use for bundles that contain SCA composite applications. A composite application is deployed on an SCA domain. An SCA domain typically represents a set of services that provide an area of business function that is controlled by a single organization; for example, the SCA domain for an accounts department in a business might cover all financial related functions and contain a series of composite applications that deal with specific areas of accounting.

In a CICS region, by default there is one SCA domain. Every bundle that is deployed on the CICS region has the same default SCA domain, although the value is empty. You can use the BASESCOPE attribute on the BUNDLE resource definition to set a value for the SCA domain.

You can also deploy the same bundle multiple times into the CICS region by specifying different SCA domains for the BASESCOPE attribute. CICS uses the SCA domain and the composite together to identify the service during runtime processing. The scope of the service is available to the task that is processing the request.

Use a unique URI for the BASESCOPE attribute value; for example, http://mycompany/HR or http://mycompany/warehouse. CICS creates the names of services, composites, and references by extending the value of the BASESCOPE attribute; for example, installing a service with a local name of location/taxService into the HR SCA domain would create a scoped name of http://mycompany/HR/location/taxService.

Do not extend the same URI to create a new SCA domain. If you extend the same URI, you might get unexpected service or reference name clashes; for example, if you used http://mycompany/HR and http://mycompany/HR/location as different SCA domains and had a service with a local name of location/taxService and another service called taxService, installing these services into both the http://mycompany/HR and http://mycompany/HR/location SCA domains create clashes with the service names. Although you can install and enable BUNDLE resources successfully with these values, you might get unexpected results and errors when the services are called by other applications.