Milestone 2: Prepare for Installation

Before you install Code Pipeline, there are certain decisions that must be made and pieces of information that must be gathered. The tables in this milestone can be printed and used to record the values to be specified later in the installation process.

Step 1 Establish Code Pipeline data set naming conventions

Various types of data sets are required for the installation of Code Pipeline and should be planned to ensure a smooth installation. The following table describes the various types of data sets required and provides naming examples. The naming convention established in this task will be used in Determine High-Level Qualifiers and Warehouse ID.

Step 2 Determine High-Level Qualifiers and Warehouse ID

The following table can be used to record the values you will enter during Specify Environment Values.

Step 3 Set Up an SAF Class

Code Pipeline makes security checks to SAF which require a Class Name (Generic). It is recommended that a separate SAF Class be defined specifically for Code Pipeline, because the Code Pipeline CM started task issues (RACROUTE REQUEST=LIST) against the class at startup to pre-load all the profiles. Keeping the Code Pipeline profiles separate provides the maximum level of optimization under SAF.

An example definition for RACF follows:

This can be refreshed using the RACF command:

Specifying the Class during the installation

There is an installation substitution variable in the dialog called SECCLASS. A non-existent class can be specified here if it is to be defined later. Code Pipeline’s CM will still work, except that no internal security will be available.

Early in the installation process, it will become necessary to turn on some internal security. All of the Reference Data should be protected from users so that it is not accidentally changed. The Reference Data governs the way Code Pipeline works, and it is recommended that only your Code Pipeline Technical Support person updates it.

Step 4 Create UserIDs for Started Tasks

Installation of the Base Code Pipeline product will result in three permanent Started Tasks (CM, CI, and CT) plus one other Started Task (SX) that is started, when necessary, for Code Pipeline  to perform work in a Set. Information as to their required permissions is listed in the subsequent paragraphs, however some of the values (such as the names of the Warehouse Datasets) will not be known until later in the installation process.

If your site intends to use the Code Pipeline Deploy feature, a fifth started task (RX) will need to be defined. See the Code-Pipeline-Deploy-Reference for more information about the RX task.

Additionally, if your site intends to use the Custom Exit Processor a sixth started task (FX) needs to be defined. Its permissions are similar to the SX task mentioned above.

If your site intends to use the Code Pipeline External Function Processor Enhancement, a seventh started task (EF) will need to be defined.

CM Authority

The CM Task needs to be associated with a UserID with the following authority:

• READ access to data sets specified in the PROC for the CM.
• EXECUTE privilege on the Db2 Plan as specified in the input parameters. This should be done as part of the Db2 Repository Install.
• The UserID should be set up with no password (using the NOPASS attribute).
• For TCP/IP communications, the CM Task will require an OMVS segment.
• Authority to issue the z/OS START command (to start the SX task).

CI Authority

The CI Task needs to be associated with a UserID with the following authority:

• READ access to data sets specified in the PROC for the CI.
• The UserID should be set up with no password (using the NOPASS attribute).
• STEPLIB must be z/OS APF-authorized.
• For TCP/IP communications, the CI Task will require an OMVS segment.

CT Authority

The CT Task needs to be associated with a UserID with the following authority:

• READ access to data sets specified in the PROC for the CT.
• ALTER access to the Warehouse Datasets from Establish Code Pipeline Dataset Naming Conventions.
• The UserID should be set up with no password (using the NOPASS attribute).
• Authority to issue the z/OS START command (to start the SX Task).
• For TCP/IP communications, the CT Task will require an OMVS segment.
• Code Pipeline authority REFDATA, TECH to keep the repository updated with warehouse details. See the “REFDATA” section in the chapter entitled “Security-Objects-and-Methods” in the Code-Pipeline-Technical-Reference-Guide for more information.

SX Authority

The SX Task needs to be associated with a UserID with the following authority:

• READ access to data sets specified in the PROC for the SX.
• UPDATE access to all Application data sets managed by Code Pipeline.
• ALTER access to a specified HLQ for a “Set Log” (as specified for Set Log Datasets in Establish Code Pipeline Dataset Naming Conventions).
• The UserID should be a maximum of 7 characters because SX runs batch TSO and ISPF.
• Because SX submits controlled compile jobs under its authority, it requires TSOSUBMIT authority. For the same reason, SX requires JCL authority under the TSOAUTH resource class.

• Authority to perform operations the SX task will do directly (for example, BINDs and CICS Newcopy).

RX Authority

• TSO UserID (7 characters or less).
• The UserID should be set up with no password (using the NOPASS attribute).
• An OMVS segment is needed if Code Pipeline will be used to deploy UNIX files.
• RACF authority to data sets the RX task will access (such as Lifecycle and Target Deploy Datasets).
• Authority to perform operations the RX task will do directly (for example, BINDs and CICS Newcopy).

FX Authority

The FX Task needs to be associated with a UserID with the following authority:

• READ access to data sets specified in the PROC for the FX.
• UPDATE access to all Application data sets managed by Code Pipeline.
• ALTER access to a specified HLQ for an “FX Log” (as specified in M.ER variable FXLOGPFX).
• The UserID should be set up with no password (using the NOPASS attribute).
• The FX Task requires JCL authority under the TSOAUTH resource class. It will require the same authority as the SX Processor.

EF Authority

The EF Task needs to be associated with a UserID with the following authority:

• READ access to data sets specified in the PROC for the EF.

Step 5 Plan System Libraries

During Code Pipeline configuration, you will enter the library data set names to be used in tailoring the Site skeletons. ISPF Dataset Names and Compiler and Related Dataset Names can be used to record the values you will enter in Define/Provide System Libraries.

Task 5.2 Determine compiler and related data set names

The following table can be used to record the values you will enter during Provide Compiler and Related Dataset Names.

Compiler and related data set names

Step 6 Plan Started Task parameters

Code Pipeline relies on four Started Tasks (CM, CI, CT and SX) to perform all its basic functions. Without these Started Tasks, Code Pipeline will not function. Follow the instructions in this Milestone to plan the necessary Started Task parameters you will enter during Milestone-8-Define-Started-Tasks.

Certain parameters are used by all of the Code Pipeline Started Tasks. The following table can be used to record the values you will enter during Define Common Parameters.

The following table can be used to record the values you will enter during Define CI Specific Parameters.

The following table can be used to record the values you will enter during Define CT Specific Parameters.

Additional CT Started Task audit log parameters

Task 6.5 Setting the priority of Code Pipeline Started Tasks

For proper performance, the started tasks used by Code Pipeline need to have the proper priority. The following tasks should be given a relatively high priority:

• CM is a transaction processing environment that only performs business logic with Db2 activity, such as CICS and IMS.
• CI is primarily a communications gateway.
• CT handles deployments, moves components, and manages Code Pipeline warehouses.

Other tasks

• SX tasks are started as required and can have many running concurrently up to user-configured maximums. These tasks primarily handle all the background life-cycle operations run in Sets, but are also used for some other background functions. As such, they could be considered similar to batch, but should probably be given higher priority than batch.
• RX tasks are also started as required to handle deployments where any additional processes are required (CICS NEWCOPY, Db2 binds, LLA refresh, etc.), and should therefore be given consideration similar to that given to SX tasks.
• FX tasks are started as required and handle custom exit processing for Code Pipeline for Eclipse users. There can be many FX tasks running concurrently (although this is unlikely). As such, they could be considered similar to batch, but should probably be given higher priority than batch.
• EF tasks are started at Code Pipeline CT startup and handle parse operations for files saved by Code Pipeline for Eclipse users. As such, they could be considered similar to batch, but should probably be given higher priority than batch.