White Paper

Property overview: IBM UrbanCode Deploy and z/OS


Cover page of the document Property overview: IBM UrbanCode Deploy and z/OS

The following diagram shows a few primary ways to use properties to parameterize and re-use mainframe code in IBM UrbanCode Deploy applications. In each case, the server imports built JCL and compiled Cobol load modules as component versions. The left side of the diagram shows the major types of properties that are defined or set on the components themselves, prior to deployment.

The gray boxes with solid borders represent properties that are defined and specified in the same place. For example, component properties are defined on a component, and component properties are also given a value on that component. The yellow boxes represent properties that are defined but not given a value. For example, component version properties are defined on the component, but the property has no value until the server imports a component version and the property value is assigned for that version. The diagram shows other properties in gray boxes with dashed borders; the values of these properties are specified in other areas of the IBM UrbanCode Deploy system. For example, agents are not shown on this diagram, but the agent properties are available in the context of the resources.

When built mainframe components are imported, the JCL is parameterized to allow property values to be filled in later. Similarly, the load modules are accompanied by properties that store information about them and can change how they are used.

The right side of the diagram shows a deployed application and the properties that are available in that context. The deployed components have access to the component properties plus all of the properties of the environment, resource, and application.

Diagram of UCD properties in z/OS builds

These properties can come from a variety of sources:

Component properties are defined and set directly on the component. They stay the same for all versions of the component. In processes, reference component properties like this: ${p:component/componentPropertyName}

Component version properties are defined on a component, but the values are specified on component versions. This type of property stores information that changes with each version of the component, such as a version number. Each component version can have a different value for its component version property. Reference component version properties like this: ${p:version/componentVersionPropertyName}

Component environment properties are defined on a component, but the values are not specified until the component is deployed to an environment. Reference component environment properties just like any other environment property: ${p:environment/componentEnvironmentPropertyName}

Environment properties store information about an application environment, such as the location of environment-specific files or servers that are on that environment. Environment properties are not related to any component, but component processes can refer to environment properties to get information about the environment. Reference environment properties like this: ${p:environment/propertyName}

Resource properties are similar to environment properties in that they are both associated with infrastructure rather than components. Refer to a resource property like this: ${p:resource/resourcePropertyName}

Agent properties are also available on resources. Refer to an agent property like this: ${p:agent/agentPropertyName}

Application properties are set on applications and are referenced like this: ${p:application/applicationPropertyName}

Each type of process can have process properties. Refer to process properties like this: ${p:propertyName}

System properties are available in all contexts. Refer to system properties like this: ${p:system/systemPropertyName}

These are the most commonly used properties; other properties are available. For more information, see IBM Knowledge Center: Properties.

Properties have an order of precedence, which allows you to override properties in specific contexts. If you refer to a property without a specific scope, such as ${p:propertyName} , (instead of specifying the scope, as in ${environment/propertyName} or ${resource/propertyName}), the property with the highest order of precedence is used. The order of precedence of properties is as follows, from highest precedence to lowest:

  1. Process
  2. Component version
  3. Resource
  4. Agent
  5. Environment
  6. Component
  7. Application
  8. System

In this way, you can override properties to change the application behavior without changing the code. For example, an application might have a database for testing and a separate database for production use. In this case, you might create an application property named databaseLocation to store the testing database location. The application and component processes can refer to the property without specifying the application scope, like this: ${p:databaseLocation}. Then, in the production environment, you can override the application property with an environment property that specifies the production database location. The processes still refer to ${p:databaseLocation}, but in the context of the production environment, the environment property takes precedence, so the application uses the production database.