Step 1: Define Application Data

Objective

The objective of this step is to have the new Application fully defined in Code Pipeline.

What to Define

The information listed in the following table needs to be defined, as a minimum.

Define Application Data

Definition Data	Option	Description
Application and SubApplication	M.AP	The new Code Pipeline Application or SubApplication is required to be added to the list of Code Pipeline Applications and SubApplications.
Application and SubApplication/Stream	M.AD	The Application and SubApplication Definitions are defined to a Stream.
Application/SubApplication Component Types	M.AD(T)	Add the Component Types to the Application/SubApplication Definition. The Types must have already been defined to M.CT. Important: See the Warning in the subsequent section about Component Type Domain.
Application/SubApplication Dataset Names	M.AD(N)	For each Application/SubApplication Level and Type, the Dataset Names are specified.
Application Component Type Associations	M.AD(A)	For each “Generatable” Component Type, the associations must be defined (for example, DBRM, LOAD, etc.).
Assignment Prefix	M.P	An Assignment will need to be created before the Application Load process can be performed. An Assignment Prefix is required for this.

It is essential that this data be accurately defined for the Application Load to work correctly.

Component Type Domain

Warning

In defining the Application/SubApplication Types in M.AD(T), there is a field for the Component Domain. It is essential that this be correctly defined if there are any Component naming constraints for this and other applications. The rest of this section is a discussion of this feature.

Setting up a Component Domain

A Component Domain enforces uniqueness of a component name for all component types that have been made a part of the domain. This is useful when shared libraries are being used for more than one component type.

Example

In application/subapplication XYZ/XYZ, the component types COB and COPY are both stored in one set of libraries (as defined in option AD(N)). This means that a Component Domain must be set up to ensure that components of these two types are not created with the same component name. (Each member must be unique in a dataset.) For example, if a component of type COB has been created with a name of TESTPGM1, the Component Domain will prevent a component of type COPY from being created with a name of TESTPGM1.

The procedure in the following table describes how to set up a Component Domain using the example above.

Setting Up a Component Domain

Step	Action
1	Identify which application/subapplication component types are going to be part of the Domain. Example: COB and COPY component types in application/subapplication XYZ/XYZ.
2	Think of a name that suitably describes the Component Domain. A Domain name can be up to 8 characters long. Example: COBCOPY
3	Change the Component Domain field to the Domain name identified in step 2 in M.AD, Types. Do this for each application/subapplication component type identified in step 1. Example: Update the Component Domain field to COBCOPY for Types COB and COPY in application/subapplication XYZ/XYZ.
4	Save the changes and refresh the server cache.

Important

This is just one example of when a Domain is useful. If Applications share libraries (including Load Libraries), a Domain will need to be defined for all those types across all the applications/subapplications that share those libraries.