Best Practices for Configuration

This article describes the best practices to configure
CA Endevor
for optimal performance in order to meet the specific needs of your software change management activities and for ease of use.
Implement a Proactive Preventive Maintenance Strategy
CA Technologies formerly delivered product maintenance using Service Packs. We have replaced this model with CA Recommended Service (CARS) for z/OS, which provides more flexibility and granular application intervals. CA RS is patterned after the IBM preventive maintenance model, Recommended Service Upgrade (RSU). With CA RS, you can install preventive maintenance for most CA Technologies z/OS-based products in a consistent way on a schedule that you select (for example, monthly, quarterly, annually).
CA Technologies periodically releases Service Updates. A Service Update is a product installation file and all PTFs preapplied up to the last CA RS level.
We recommend that you develop and implement a proactive preventive maintenance strategy whereby you regularly apply maintenance. You can follow the same schedule that you use to apply IBM maintenance, or you could implement a schedule for CA Technologies products only.
Business Value
Keep your products current with maintenance to help your team remain productive, minimize errors, and safely protect your systems. If you do not install preventive maintenance regularly, you might encounter known problems for which we have published and tested fixes.
Our mainframe maintenance philosophy grants you the flexibility to maintain your sites and systems consistent with industry best practices and site-specific requirements. Our philosophy focuses on two maintenance types. An understanding of each type can help you maintain your systems in the most efficient manner.
This philosophy applies to the CA Chorus Software Manager-enabled products. For legacy products, contact Broadcom Support for maintenance details.
  • Corrective Maintenance
    Helps you address a specific and immediate issue. This type of maintenance is necessary after you encounter a problem. We may provide a test APAR when a new problem is uncovered, and a confirmed PTF when the problem has been resolved. Your primary goal is to return your system to the same functional state that it was before you experienced the issue. This type of maintenance is applied on an as-needed basis.
  • Preventive Maintenance
    Lets you bring your system up to a more current level. Preventive Maintenance helps you avoid problems that others have reported. This maintenance may also contain compatibility fixes for hardware and software. You may have experienced the issues that each PTF addresses. CA RS provides a way to identify all published maintenance that has been successfully integration-tested. This maintenance has been tested with other CA Technologies products, current z/OS releases, and IBM subsystems, such as CICS and DB2. CA RS levels are published monthly that include PTFs, HIPERs and PRPs (PE-resolving PTFs). Before you download, apply, and test a new CA RS level, we recommend that you accept the previous CA RS level. You can initiate a maintenance installation activity at any time. You can then install the current CA RS level of maintenance (recommended) or an earlier level. Additionally, you can install maintenance to support a new hardware device, software upgrade, or function using the FIXCAT method.
For all maintenance,
before
you initiate any maintenance action, obtain the current SMP/E HOLDDATA.
More Information
To apply preventive maintenance, see the CA CSM online help, or the CA CSM website product page.
First Time Installation Using the BPI
For first-time installations, use the Best Practices Implementation (BPI) method to set up a complete implementation of the product. After you install, use the BPI method to set up an implementation, with minimum customization, to get you started with the application. The BPI is delivered as a set of input tables and jobs that you configure and run. After you complete the BPI, you will be ready to load your source code into the
CA Endevor
inventory structure that supports the software development lifecycle.
Business Value
The BPI method builds a best practices and customizable software development environment that is complete and includes a lifecycle and inventory structure.
More Information
For more information about the BPI process, see the Best Practices Implementation.
Logical Structure
The following best practices apply to the implementation of your logical structure, which includes your software change management lifecycle and software inventory classification scheme.
Avoid Confusing Environment and Stage Names
All environment names and stage names should be the same length and the names should be unique.
Business Value
When names are the same length, it is easier to use a name as part of a data set name. Unique names avoid confusion when you reference a particular stage.
Make System and Subsystem Names Easy to Identify
Each system name should identify the purpose of the application. Each subsystem name should identify the specific application within the system.
Business Value
Names that are easy to identify help avoid confusion.
Additional Considerations
If you perform concurrent development, you can use subsystems in the development environment to manage the concurrent development.
More Information
For more information about the use of subsystems for concurrent development, see Use Sandboxes for Concurrent Development.
Normalize Type Names
Type names should be normalized; that is, type names should correspond to the language, but not the version, of the source code (COBOL, JCL, CLIST, and so on). For example, there should be one type for COBOL, not separate types for COBOL/LE and COBOL II. Processor groups can be used to distinguish between language versions, such as COBOL LE and COBOL 2. We recommend the following Type names:
  • ASMMAC
  • ASMPGM
  • BIND
  • CHDR
  • CPGM
  • CICSMAP
  • COPYBOOK
  • COBOL
  • CLSTREXX
  • DCLGEN
  • DOC
  • EZTINCL
  • EZTRIEVE
  • FORM
  • FORTRAN
  • ISPM
  • INCLUDE
  • ISPP
  • ISPS
  • ISPT
  • JAR
  • JAVA
  • JCL
  • LINK
  • PARM
  • PL1
  • PROC
  • PROCESS
  • RULES
  • SANDBOX
  • SCL
  • TXT
  • XML
Business Value
Normalized type names make it much easier to upgrade the code from one version of the language to another.
Use Sandboxes for Concurrent Development
Use private work areas (sandboxes) for concurrent development.
Business Value
Sandboxes provide separate work areas for different development activities. This lets developers work on the same code simultaneously, without interfering with each other's work, which improves the efficiency of the development staff. Typically, you set up several sandboxes so that developers can work on the same code independently; then, the changes made in the sandboxes are combined in an integration subsystem, where the changes can be accepted or rejected
Additional Considerations
Methods of sandbox development include: 1) subsystem sandboxes; 2) environment sandboxes; and 3) private work area stages. Subsystem sandboxes are easiest to setup; however, if subsystems are required to subdivide systems (applications), it is necessary to set up environment sandboxes using the environment sandboxes method or the private work area stages method.
Details regarding sandbox development methods follow:
  • Subsystem sandboxes
    Use subsystem sandboxes, if you do not use subsystems for specific applications. This method is easier to set up and maintain than environment sandboxes. Adding a new environment requires the modification to and re-assembly of the C1DEFLTS table and the creation of all of the necessary environment-related data sets. Adding a new subsystem consists only of adding the subsystem to the system definition, adding a few required data sets, and sharing processors. In addition, it is easier to delete a subsystem than to delete an environment. For example, this diagram shows development of a code branch where coding changes for projects 1 through n are performed in subsystem sandboxes. Also, the maintenance team has their own subsystem sandbox. Then all development changes are integrated in the Integration stage.
    Image shows subsystem sandboxes example
  • Environment sandboxes
    Use separate environments for your sandbox development areas, if you are using subsystems for specific applications, for example, if you have a system for your Finance department's applications that contains subsystems for your Accounts Payable and Accounts Receivables applications. The advantage of environment sandboxes is that you can use the same system and subsystem names and relationships in each sandbox environment. The disadvantage is that this method requires additional administrative effort to set up each sandbox environment, which requires the modification to and re-assembly of the C1DEFLTS table and the creation of all of the necessary environment-related data sets. For example, this diagram shows that development activities can be performed in the Development Sandbox 1 environment and the Development Sandbox 2 environment. Then the changes can be integrated in the Integration stage.
    Image shows environment sandboxes example
  • Private Work Area Stages
    Use an extra stage with subsystem sandboxes, if you are using subsystems for specific applications. This method requires that you set up one additional environment and stage to hold your subsystem sandboxes, and you must add an integration subsystem to a subsequent stage. The advantage is that you only need to set up one additional environment and stage combination with as many sandbox subsystems as you need, instead of the multiple environments required for the environment sandboxes method. For example, this diagram shows a stage that is named Private Work Area that contains multiple subsystem sandboxes for development activity. The development changes are integrated in a subsystem in the Unit Test stage.
    Image shows private work area stages example
Use Subsystems to Support Multiple Releases
If you maintain multiple releases of the same application concurrently, use different systems (or subsystems, if available) to segregate the different versions of the code. Make sure that the system (or subsystem) name is incorporated into the related data set names to create unique libraries.
Some sites require maintaining multiple releases of the same program or element concurrently. For example, this requirement can occur when the site is a software vendor that needs to support program A shipped in release 1, release 2, and release 3, because not all of their clients have implemented the latest release.
Business Value
The subsystem definition provides the flexibility most sites are looking for in this situation. Using the application name as the system definition and the release number as the subsystem definition has the following advantages:
  • The
    CA Endevor
    administrator needs to only maintain one set of definitions within
    CA Endevor
    because the majority of administration is at the system level.
  • You are exploiting the ability of
    CA Endevor
    to logically categorize elements under its control.
  • You can extend the definition into the physical definition to create mutually exclusive physical inventories.
  • You can introduce new releases merely by adding new subsystems.
Physical Structure
The following best practices apply to implementing the physical data set structure that supports your site's logical structure.
Recommended Data Set Format
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.
Defining Base and Output Libraries
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.
Defining Delta Libraries
Define a minimum of one delta library for each stage. We recommend that you use PDSE-format libraries.
Business Value
Although delta libraries can be shared across stages in an environment, we recommend a minimum of one delta library per stage.
Binary Types
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.
Use Symbolic Variables in Data Set Names
The following best practices apply to using symbolic variables in data set names: Use symbolic variables to define base and delta libraries. For example, this library name refers to a library called SRCLIB for each subsystem and stage combination within a 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
replaces the symbolic with the proper information from the action request.
More Information
For more information, see Site Symbolics.
Use data set names that let you take advantage of the Processor Map Allocation feature. For this feature, certain symbolics can be used for the location specifications in the processor DD statement. Other symbolics are allowed, but will remain the same for all data sets in the concatenation.
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 Writing Processors.
Define Site Symbolics to Reference Libraries with Nonconforming Names
Use site symbolics to reference
CA Endevor
libraries in processors, where your libraries do not following the
CA Endevor
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 USS 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 Site Symbolics.
Processors
You can use the processors delivered with the Best Practices Implementation for reference.
The following best practices apply to processor JCL:
  • Use symbolics in your processors to reference data sets.
    Business Value
    With symbolics, one physical processor can support multiple processor groups. Symbolic overrides can be very valuable in providing flexibility to processors. They can support variations in compile and link parameters and in the inclusion or exclusion of steps such as adding or bypassing testing tools such as CA InterTest Batch.
    Additional Considerations
    Avoid having an excessive number of processor groups. When the number of processor groups becomes unwieldy an alternative approach to supporting some of the functions (such as compile and link parameter substitutions) should be used.
  • Use the LIBENV option on the C1DEFLTS table to enable -INC or ++INCLUDE syntax in processors for code that is used in multiple processor locations. The LIBENV parameter does not indicate that CA Librarian or CA Panvalet is used; it merely indicates which INCLUDE syntax style is used.
    CA Endevor
    determines which syntax to resolve, based on the definition of the field LIBENV in the C1DEFTLS table. This value can be set to either PV (for CA Panvalet syntax) or LB (for CA Librarian syntax). PV resolves ++INCLUDE statements and LB resolves - INC statements. You can set these values even if you do not have the CA Panvalet or CA Librarian
    CA Endevor
    interfaces, because the purpose of LIBENV is only to identify to
    CA Endevor
    how to resolve the syntax when it is encountered in element source.
    Business Value
    Using INCLUDE statements makes it easier and quicker to create processors as new languages and processing requirements arise at your site. You can exploit INCLUDE statements in
    CA Endevor
    processors to clean up the look of the processor and to share commonly used routines across various processors. INCLUDE statements read from a library and insert commonly used JCL into processors.
    Additional Considerations
    You can also imbed INCLUDE statements within other INCLUDE statements to expand the modularity of your routines.
  • Use consistent processor symbolic variable names across processors.
    Business Value
    Using consistent processor symbolic variable names make the maintenance of processors easier, because there is no need to constantly ask yourself what the variable is referring to. The consistent naming of variables in processors is as valuable to the maintenance function as is the consistent naming of variables in programs.
    Additional Considerations
    You can use an INCLUDE statement in your processor to insert a member that contains the symbolic variable names.
  • Use site symbolics as a method of reducing or eliminating processor group overrides.
    Business Value
    The Site Symbolics table provides the ability to override symbolics without having to modify a large number of processor groups.
  • Use
    CA Endevor
    utilities before using IBM utilities in executing processor steps.
    Business Value
    The
    CA Endevor
    utilities are specifically designed to work with
    CA Endevor
    within processors. These utilities support code (such as footprints) that may not be supported by other utilities and they capitalize on internal
    CA Endevor
    functionality that is foreign to other utilities.
    Additional Considerations
    IBM utilities can be used where
    CA Endevor
    utilities are not available to perform the required function. IBM utilities are generally more reliable and more consistently updated within the operating system than are those of third parties.
  • Other best practices for processors:
    • Balance the number of processors and the complexity level of the processors with the technical skills of the individuals who must support them. With an experienced staff, you can use one very complex COBOL generate processor that supports batch, CICS, DB2, and CA InterTest Batch. With a less experienced staff, you would need multiple processors that are less complicated, such as separate processors that support batch, CICS, DB2, and CA InterTest Batch. Multiple Processors support more limited functionality but are easier to understand and maintain.
    • Label or indent IF/ELSE/ENDIF statements to make them more readable and their ranges more identifiable.
    • Comment the steps in your processors to make it easy to understand the purpose of each step.
    • Each language level should have its own generate processor to reduce the complexity of each processor and to make it easier to retire obsolete levels. In addition, one move processor and one delete processor are recommended for each type.
    • If your types are defined as reverse delta and compress=N, then use the symbolic &C1BASELIB in processors to reference the type base library.
    • Use the processor parameter ALLOC=PMAP | LMAP for building concatenations using the Processor Map Allocation feature. For more information about Processor Map Allocation, see Use Symbolic Variables in Data Set Names.
Business Value
These best practices help to reduce administrative maintenance.
ESYMBOLS Table
Use symbols in the ESYMBOLS table to represent common values that are used in processors. The ESYMBOLS table can hold these types of symbols in addition to the C1
CA Endevor
symbols.
Business Value
Using symbols to define common values once for the site makes it easier when updates are required. Also, these symbols make it easier to write processors.
Packages
The following best practices apply to packages:
  • Set naming standards and use the target stage as the name prefix, if the package is not a promotion package.
    Business Value
    Lists of package names are automatically sorted by target stage, which makes it easier to find a specific package.
  • Use promotion packages for packages that contain Move actions only. The Promotion Package feature lets you use the same package for as many iterations and movements as needed, rather than requiring that you create new packages. If a package is not set up as a promotion package, every time it moves from one stage in the lifecycle to the next, an entirely new package must be created.
    Business Value
    If you use a package for move processing only and you need to promote the package all the way through to production, the Promotion Package feature simplifies this process. Promotion packages provide for greater project control and simplify the movement of packages through the lifecycle. This feature helps you meet regulatory requirements, because it makes it easy to track the transitions in the development of your applications. Promotion packages provide auditors with a complete trail of who did what, when, and where for each iteration of the package. In addition to facilitating project control, promotion packages also make it easier to comply with a standard package naming convention.
    Additional Considerations
    Promotion packages can contain Move actions only; no other
    CA Endevor
    actions are allowed. Promotion packages keep the same package ID for the entire migration cycle.
  • Enable the C1DEFLTS [email protected] feature for promotion packages that require package ship support at a stage prior to the last stage of your software life cycle.
    Business Value
    This best practice lets you use promotion packages, but enables you to stop them at one or more designated stages for shipment, prior to completing the promotion to the end of the lifecycle map.
  • Use external security groups (external security profiles) for approver groups.
    Business Value
    This best practice puts the responsibility for maintaining security in the security department, rather than with the change management administrators. This allows for more flexibility in maintaining approver groups by allowing more than 16 approver IDs and the addition or deletion of approvers as needed for a specific package.
  • Make packages sharable by default.
    Business Value
    A sharable package can be maintained by more than one person. If the creator of a package is unavailable when action needs to be taken with that package, having it sharable means that someone else can step in and maintain the package.
  • Clean up backout members at specific intervals using the COMMIT action.
    Business Value
    Backout enabled packages leave encrypted members in the output libraries. The COMMIT action removes those members, thus keeping the library clean and minimizing the space requirements.
  • Archive after n days.
    Business Value
    The Package Master file is a VSAM file which can grow quite large if not maintained. Archiving completed packages that have been committed helps to minimize that growth.
  • Delete after n days.
    Business Value
    The Package Master file is a VSAM file that can grow quite large if not maintained. Deleting unused packages (those that have not been accessed in a set number of days and which are still in the “Being Created” state) will help to minimize the growth of the VSAM file.
  • For more information about archiving completed packages and deleting unused packages, see the technical document TEC348243 on Broadcom Support.
Other Best Practices
The following best practices make
CA Endevor
easier to use and let you take advantage of advanced features:
Customize ISPF Session Parameters
Set session parameters to values that help your specific development process, instead of leaving the parameters set to the default values in the delivered software.
We recommend the following best practices:
  • Regularly review the ENDICNFG table, which contains the values that initiate the ISPF panels.
    Business Value
    Most of the common session parameters that can be set are in the ENDICNFG table. While these values can be set at installation time, they should be reviewed occasionally to ensure that they still reflect your site's needs. Each of these values results in a default value being displayed when the developer enters a panel that has a corresponding field. Whereas the developer can typically change the value as necessary, most developers will want the default value to correspond to the process that makes the most sense for their site.
    Additional Considerations
    We recommend setting the following ENDICNFG parameters: INTERCEPT_ISPF_RETURN Set this parameter to Y to ensure that the Return command (typically PF4) will not exit, but will return a user to the
    CA Endevor
    Primary Options panel, thus facilitating the user's ability to navigate within. SHARABLE_PACKAGE Set this parameter to Y so that all packages, by default, will be created sharable. This ensures that future maintenance against the packages can be conducted when it needs to be done. DELETE_AFTER_TRANSFER Set this parameter to N so that you have a backup in case there is an issue with the transfer process.
  • Set the SOFETCH parameter to Y in the C1DEFLTS table.
    Business Value
    This parameter indicates whether an element that you have caused to be fetched should be signed out to you, if not signed out to someone else.This parameter will come into play with Add (Fetch), Generate (Copyback), Move (Fetch), Transfer (Fetch), Search and Replace (Fetch), and QuickEdit.
  • Instruct your developers to modify their personal defaults settings on the User Defaults panel. Specifically, each developer should change the User Defaults panel field DISPLAY MSGS WHEN RC GE to a value greater than 4.
    Business Value
    The user defaults should reflect the needs of the individual user. As delivered, the DISPLAY MSGS WHEN RC GE value is set to 0, which causes
    CA Endevor
    to display messages for every action performed by the developer. Setting the value greater than 4 causes