Code Pipeline Troubleshooting

This section describes potential problems that can be avoided, as well as ongoing support issues. According to past experiences with various sites running Code Pipeline, a number of situations have been found. They should be either avoided or monitored to reduce the potential number of support problems. The following situations are described in this section.

• • Code Pipeline Support Versus ISPF Support
  • Code Pipeline Support Versus Other Program Products
  • Upgrades to Compile Procs
  • Code Pipeline and Migrated Datasets
  • Multiple Component Types Using the Same Libraries
  • Maintenance Guidelines
  • Abends in ISPF Client
  • Searching tasks by WORK REQ No.

Code Pipeline Support Versus ISPF Support

Because Code Pipeline is closely linked with ISPF, any changes to ISPF could affect Code Pipeline. If the same person or group is not supporting both products, there are potential problems if ISPF is upgraded without the corresponding changes to Code Pipeline.

Things to Watch Out For

Changes to the ISPF primary option menu or the Printoff or Script invocations. You may need to change:

• The Code Pipeline primary menu to pick up the new ISPF invocations.
• M.ER options for the Printoff (3.6) calls.
• The Z functions list on the main menu, if you are using that option, via M.CZ or M.CO.

Recommendation

Code Pipeline should either be supported by the systems programming group, or the Code Pipeline support staff should be party to regular change control meetings to anticipate any impacts.

Code Pipeline Support Versus Other Program Products

Further to the point above, Code Pipeline interfaces to many technologies at any site, which undergo regular upgrades.

Things to Watch Out For

Changes to any of these products that are under the Code Pipeline umbrella. Most of the time, these changes are transparent to Code Pipeline, but you should check with us if unsure of the impacts. See the Code Pipeline Interfaces Guide chapter on new versions and their implications.

Recommendation

Code Pipeline should either be supported by the systems programming group, or the Code Pipeline support staff should be party to regular change control meetings to anticipate any impacts.

Upgrades to Compile Procs

In the planning phase, we discussed how the compiles are going to be installed and supported, and the “Skels only” approach versus the “Procs and Skels” approach.

If you have chosen to keep the Compile Procs separate from the Skels, there are potential synchronization problems.

Things to Watch Out For

Watch out for changes to the Compile Procs that may affect the Code Pipeline Skeletons. It is possible that the skeleton itself will need to be changed.

Recommendation

Code Pipeline should either be supported by the group responsible for the compiler interfaces, or the Code Pipeline support staff should be party to regular change control meetings to anticipate any impacts.

Code Pipeline and Migrated Datasets

Data sets used by Code Pipeline may be migrated based on a site’s storage management policies. Code Pipeline is unaware of the status of these data sets. Code Pipeline uses a variety of functions that may cause a migrated data set to be recalled. The expectation is that this occurs synchronously in the background.

Things to Watch Out For

There are several products that perform storage management. These products can be configured in various ways. This may include manual intervention for recalled data sets. 

BMC AMI Storage FDR

FDR

Recommendation

You will need to add the following DD statement to the SX, RX, and FX procedures. Refer to the

BMC AMI Storage FDR

Multiple Component Types Using the Same Libraries

Generally, one set of libraries can be used for many Component Types if they all have the same dataset format (for example, 80 bytes, fixed). This works well for such types as COB, JOB, COPY, etc. If this is the case, Component Domains should be set up to prevent these different component types from using the same name. A component name has to be unique across component types because they are sharing the same libraries. See Maintenance-Functions for more information on setting up Component Domains.

Code Pipeline base software is delivered and maintained using standard z/OS product installation processes (SMP/E).

Upgrading a Code Pipeline environment involves additional considerations compared to typical z/OS products. To meet the specific requirements of each customer, Code Pipeline supports extensive configuration and customization. There will also be multiple Code Pipeline environments: at a minimum, one “test” and one “production” environment.

The SITE application is provided as the default mechanism for maintaining local customizations. New major versions of Code Pipeline, as well as any single PTF, may contain changes to components that have been placed and/or updated in the SITE application.

As part of any Code Pipeline implementation, the process by which product changes are applied to each Code Pipeline environment should be established. The Code Pipeline Administrator plays an important role in this process. They will need to verify whether any PTF or new version of the base software requires updates to the SITE application. The Code Pipeline Administrator and the z/OS product installer will need to coordinate their respective tasks in order to make those product changes active in each Code Pipeline environment.

A major upgrade may require going through the product installation process. The process to check for changes required to the SITE application is similar, whether it’s a completely new set of base software or a single PTF.

General Guidelines for Applying Product Updates

Local procedures for managing Code Pipeline updates should have been established as part of the initial Code Pipeline implementation. The training given to new Code Pipeline Administrators should cover their role and required activities when implementing Code Pipeline product updates. This will vary according to the established local procedures. The information in this section is intended only as a general guide. It is important that any Code Pipeline maintenance activity adhere to locally-established procedures.

The group or service provider responsible for the Code Pipeline z/OS product installation will receive and apply the base software updates. Typically, the base software datasets managed by SMP/E will not be used directly by your Code Pipeline environments. This will depend on the process adopted for managing Code Pipeline base software updates.

For each new version or PTF, the Code Pipeline Administrator will need to follow a process that includes:

• Checking for the existence of any SITE versions
• Resolving change impacts for SITE versions
• Implementing the new SITE versions
• Keeping code in sync.

Check for Existence of Any SITE Versions

For smaller upgrades, this can be accomplished by comparing the list of components delivered to the list of components in the SITE application. For larger upgrades or new releases, it may be necessary to compare the new base datasets with the previous version, along with the SITE application datasets. Identify where any base components have changed that also exist in the SITE application.

Note that there are different ways that customization may have been done:

• Components customized from the 

  Code Pipeline

   base software datasets (REXX/CLIST, ISPF panels/skeletons/messages). Some components in these base datasets are expected to have local customization. They are copied to the SITE application for the customization to be made, then implemented using the SITE application lifecycle. If such components are in the SITE application, they will contain some local change—otherwise they would not be required in the SITE datasets.

• Components implemented/customized from samples in the 

  Code Pipeline

   base SAMPLIB dataset. Many product features are provided with samples (REXX, ISPF panels/skeletons/messages, and JCL). Those samples would be imported to the SITE application and, in some cases, may not require any local changes. They would just need to be in the SITE datasets to be available to the Code Pipeline runtime environment. Depending on the Code Pipeline implementation at your site, the names used in the SITE application may also be different from the supplied samples.

Resolve Change Impacts for SITE Versions

If your SITE application has a version of a base component or sample received in an update, the update changes will need to be reviewed and incorporated into the SITE application version as part of the maintenance process. This could be done by a three-way compare of the previous base version, the new base version, and the current SITE version. It could also be done by comparing the SITE version to the current base, in conjunction with comparing the current and previous base versions.

If a new sample is simply copied to the SITE datasets without any changes (to quickly make it available, for instance), the new version can just be imported into the SITE application. If the SITE version contained changes, it might be easier—depending on the scale of the differences—to import the new version and reapply the local changes, or to check out the version in the SITE application and apply the new base version changes.

Workbench for Eclipse

Implementing the New SITE Versions

After any impacts in the SITE application have been identified (and if necessary resolved by adding new SITE versions), the SITE application lifecycle can be used to promote those SITE changes to production. How the SITE application is used and made available in any given Code Pipeline environment will depend on the local procedures established as part of the Code Pipeline implementation. It is very important that any base software changes being made active for a given Code Pipeline environment occur in careful coordination with any required SITE changes.

Keeping Code in Sync

Not every PTF will be essential for every installation. Applying those PTFs might still be necessary, however, because they can include updates to components that are generally used. If such a PTF isn’t applied, and a later PTF also updates the same component, SMP/E will prompt you to apply the previous PTF. Also, the PTF may update (for example) a REXX program. If that program is in the SITE application and the updates aren’t applied, subsequent updates to that program will be more difficult to apply. There will be more source code differences because the latest maintenance will include all the updated code, and the local version may be missing updates.