The following best practices apply to implementing the physical data set structure that supports your site's logical structure.
Use PDSE data sets.
Business Value:
A PDSE is similar to a PDS, however the PDSE architecture includes dynamic expansion of the data set, and space from deleted or moved members is automatically reused for new members. This architecture minimizes the chances of an ABEND occurring because of lack of library space; therefore, it is far more efficient to use PDSE data sets than traditional PDS data sets.
Do not share base libraries across environments, stages, systems, and types. Do not share libraries across subsystems when subsystems are used as sandbox names. These recommendations also apply to processor output libraries, such as object, load and listing libraries.
Business Value:
Having separate base and output libraries for each type avoids name conflicts, which otherwise could occur if you had two members with the same name that were different types.
Define a minimum of one delta library for each stage. Use CA Endevor SCM BDAM ELIBs for the delta libraries.
Business Value:
Although delta libraries can be shared across stages in an environment, we recommend a minimum of one delta library per stage.
Use full-image deltas as the delta format for binary type elements.
Business Value:
Source compare is impossible or unnecessary for binary files and is not performed with the full image delta format.
The following best practices apply to using symbolic variables in data set names:
For example, the following library name refers to a library called SRCLIB for each subsystem and stage combination within a given system.
&C1SYSTEM..&C1SUBSYS..&C1STGID..SRCLIB
Business Value:
Using symbolic variables allows the same type definition to point to different libraries based on the inventory classification of the element. You can use the symbolics when specifying base and delta libraries on type definition panels. During processing, CA Endevor SCM replaces the symbolic with the proper information from the action request.
More Information:
For more information, see Using Symbolics to Define CA Endevor SCM Libraries in the Installation Guide.
Business Value:
The Processor Map Allocation feature provides the ability to code a varying concatenation of data sets to a single DD statement based on the map, using location (environment, stage, system, subsystem) information provided by symbolics within the data set name, eliminating the need to use if-then-else logic. This feature facilitates the implementation of subsystem sandboxes (private work areas) by eliminating the need for alias data set names when system or subsystem names change across environments. This feature works for data sets whose names follow the mapping structure of the location from which the processor is executing; therefore, processors do not have to be regenerated after a change to the mapping structure.
Additional Considerations:
For purposes of the Processor Map Allocation feature, the following symbolics can be used for the location specifications in the DD statement. Other symbolics are allowed, but will remain the same for all data sets in the concatenation.
|
Identify libraries by |
Using this symbolic |
Or this alias |
|
environment |
&C1ENVMNT |
&C1EN |
|
stage |
&C1STAGE |
&C1ST |
|
stage ID |
&C1STGID |
&C1SI |
|
stage number |
&C1STGNUM |
&C1S# |
|
system |
&C1SYSTEM |
&C1SY |
|
subsystem |
&C1SUBSYS |
&C1SU |
More Information:
For more information, see Implement Processor Map Allocation in the Extended Processors Guide.
Use site symbolics to reference CA Endevor SCM libraries in processors, where your libraries do not following the CA Endevor SCM naming convention, for example, CICS libraries, DB2 libraries, processor step libraries, system libraries, and so on. Site symbolics are required if you are using USS HFS pathname specifications for element type base or source output file definitions. Otherwise, site symbolics are optional.
Business Value:
The Site Symbolics facility lets you define global symbols that can be used in type and processor definitions to reference data set name specifications for base, delta, source output, include libraries, and processors. Thus, commonly referenced data sets can be defined in a single location (the Site Symbolics table) significantly easing maintenance. At execution time, all site symbolics referenced by a processor are stored with the processor symbolics in the component data. If changes are needed, the Site Symbolics table can be updated, but the processors do not need to be regenerated.
More Information:
For more information, see the chapter "Site Symbolics" in the Administration Guide.
|
Copyright © 2014 CA.
All rights reserved.
|
|