Best Practices for Configuration
This article describes the best practices to configure
CA Endevorfor 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.
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 MaintenanceHelps 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 MaintenanceLets 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,
beforeyou initiate any maintenance action, obtain the current SMP/E HOLDDATA.
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 Endevorinventory structure that supports the software development lifecycle.
The BPI method builds a best practices and customizable software development environment that is complete and includes a lifecycle and inventory structure.
For more information about the BPI process, see the Best Practices Implementation.
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.
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.
Names that are easy to identify help avoid confusion.
If you perform concurrent development, you can use subsystems in the development environment to manage the concurrent development.
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:
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.
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
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 sandboxesUse 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.
- Environment sandboxesUse 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.
- Private Work Area StagesUse 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.
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.
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:
- TheCA Endevoradministrator needs to only maintain one set of definitions withinCA Endevorbecause the majority of administration is at the system level.
- You are exploiting the ability ofCA Endevorto 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.
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.
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.
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.
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.
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.
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 Endevorreplaces the symbolic with the proper information from the action request.
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.
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.
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
For more information, see Writing Processors.
Define Site Symbolics to Reference Libraries with Nonconforming Names
Use site symbolics to reference
CA Endevorlibraries in processors, where your libraries do not following the
CA Endevornaming 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.
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
For more information, see Site Symbolics.
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 ValueWith 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 ConsiderationsAvoid 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 Endevordetermines 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 LibrarianCA Endevorinterfaces, because the purpose of LIBENV is only to identify toCA Endevorhow to resolve the syntax when it is encountered in element source.Business ValueUsing 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 inCA Endevorprocessors 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 ConsiderationsYou 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 ValueUsing 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 ConsiderationsYou 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 ValueThe Site Symbolics table provides the ability to override symbolics without having to modify a large number of processor groups.
- UseCA Endevorutilities before using IBM utilities in executing processor steps.Business ValueTheCA Endevorutilities are specifically designed to work withCA Endevorwithin processors. These utilities support code (such as footprints) that may not be supported by other utilities and they capitalize on internalCA Endevorfunctionality that is foreign to other utilities.Additional ConsiderationsIBM utilities can be used whereCA Endevorutilities 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.
These best practices help to reduce administrative maintenance.
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
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.
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 ValueLists 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 ValueIf 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 ConsiderationsPromotion packages can contain Move actions only; no otherCA Endevoractions 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 ValueThis 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 ValueThis 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 ValueA 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 ValueBackout 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 ValueThe 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 ValueThe 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 Endevoreasier 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 ValueMost 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 ConsiderationsWe 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 theCA EndevorPrimary 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 ValueThis 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 ValueThe user defaults should reflect the needs of the individual user. As delivered, the DISPLAY MSGS WHEN RC GE value is set to 0, which causesCA Endevorto display messages for every action performed by the developer. Setting the value greater than 4 causes