Installing

This section provides information about the following topics:

Product architecture

Code Pipeline is made up of four main started tasks components—CI, CM, CT, and SX—along with a TSO/ISPF client. It can also include a remote server and a

BMC AMI Common Enterprise Services

(

CES

) Web server. See the Code Pipeline Structure diagram. A fifth started task, RX, is only used with Code Pipeline Deploy. A sixth started task, FX, is only used with Code Pipeline Custom Exit processing. A seventh optional started task, EF, is used to handle parsing of source. For more information, see Started Task Details.

Code Pipeline installation

A Code Pipeline installation consists of the following:

SAF Class
Db2 Tables and Indexes
Started Tasks
TCP/IP Definitions
Authorized Load Library
ISPF Dialog

Upgrading from Code Pipeline 18.02 to 22.01

For instructions to upgrade from Code Pipeline 18.02 to 22.01, refer to the Upgrading.

Installation preparation

Review Planning in this manual before starting. That section prompts thought on many issues that may occur during the installation. In addition, the following points need to be considered prior to installing:

Defining an SAF Class sometimes requires an IPL (depending upon your security product). It is advisable to have this defined in time for the installation, although it is not strictly necessary. See the chapter entitled “Security-of-Code-Pipeline” in the Code-Pipeline-Technical-Reference-Guide.
Installing the Db2 objects will require input from your DBAs and may require some planning before the installation, especially related to naming standards.
Authorizing load libraries may require some planning prior to the installation.

Code Pipeline structure

Code Pipeline software delivery

Code Pipeline is delivered as a single z/OS job that downloads all the applicable data sets to the z/OS system required to install the SMP/E-maintained portions of Code Pipeline software using the BMC Installer.

Installation delivery options

BMC has made the following product delivery options available:

Receive From Network (RFN)
Extended Play (EP) media on DVD or electronic FTP download

Started Tasks information

This section provides an overview of what each of the Started Tasks do and how they communicate with each other. It is important to understand this before proceeding with the installation.

There can be up to six Code Pipeline Started Tasks in a standard Code Pipeline Implementation:

CM Task: This is the Code Pipeline Server, which processes all requests with respect to Code Pipeline Operations.
CI Task: This is the Communications Interface task, which is responsible for passing on requests from Code Pipeline clients (TSO users, Set Processor, External Call Interface, etc.) to the CM Task.
CT Task: This is the Component Transport task and is used to manage the movement of Code Pipeline managed components between the Component Warehouse and working data sets. Code Pipeline Deploy also uses this to move components between disparate z/OS LPARs and other distributed platforms.
SX Task: This is the Set Execution Processor task and is non-permanent. It is started only when there is work for it to do.
FX Task: This is the Custom Exit Processor and is non-permanent. It is started only when there is work for it to do.
EF Task: This is the Code Pipeline External Function Processor and is optional. It is started by CT at CT initialization if EF is configured.

Deployment Started Task

If the Deploy function of Code Pipeline is implemented, a seventh STC called RX is required, which is similar in definition to the SX Task. This is further described in the Code Pipeline Deploy Reference Guide.

CM/CI/CT restarts

You do not need to recycle the CM, CI, or CT Started Tasks if one of them is being restarted.

Started Task details

For each Code Pipeline system (that is, separate Db2 Repository), a single CM task is required.
The CM task controls Code Pipeline security and interfaces to the site SAF product (for example, RACF, ACF2, Top Secret, etc.). The started task is a multi-user address space. With Top Secret, multi-user address spaces should be assigned to a FACILITY. Define a FACILITY for Code Pipeline.
The CM task is the only task that communicates directly with the Db2-based repository.
CM will issue z/OS START commands to initiate SX Tasks as work is required to be performed.
The STEPLIB library must be z/OS APF-authorized.
CM uses Language Environment time functions, therefore when there is a time change for Daylight Saving or other reasons, the CM must be restarted.

The CI task acts as an intermediary between Code Pipeline Clients (for example, TSO users, SX, etc.) and the CM task. Multiple CI tasks can be configured to communicate to a single CM.
The CI task requires no allocations or access to any data sets other than its runtime library.
CI tasks must define a z/OS subsystem ID for its use of cross-memory services. The default value for the name of this subsystem is “Code Pipeline”, but a different value may be used in the event of conflict with the name of an existing started task or subsystem. Contact BMC Support if required.
One CI task is required for each z/OS system image on which there are Code Pipeline TSO users (or SX Tasks). Code Pipeline can be implemented with users across different z/OS LPARs.
The CI task must run from a z/OS APF-authorized library. (Authorization is required to use the z/OS cross-memory services, which are used for communication with the Code Pipeline clients.)

There will typically be one Component Transport task running on the same system as CM. It will run continuously and communicate to CM via a TCP/IP connection. It may be started before or after the CM task.
If Code Pipeline Deploy is used for deployment of z/OS objects, other CT Tasks may be defined on other z/OS LPARs.
The CT task will manage access to the Component Warehouse. It can copy components into and out of the warehouse data sets. It will dynamically create additional warehouse data sets as needed.
There can be multiple warehouses in a CT task, and there can be multiple CT tasks.
The CT task must run from a z/OS APF-authorized library. (Authorization is required to use the SAF interface. It also will require authorization if the DFHSM interface is enabled).

The SX Task is the Set Execution Processor and is started by the CM task for Set Processing.
Once started, SX operates as a TSO Code Pipeline client, communicating with CM through CI.
SX uses the RTCONF parameter on the START command to select the Runtime Configuration that allocates the appropriate data sets and also specifies the appropriate Cross Memory ID to use to communicate with CI.
The SX ProcName is specified to CM using a PARMLIB input statement.
SX moves components between Application libraries and needs appropriate authority to do this within your security product.
Because SX submits controlled compile jobs under its authority, it requires TSO SUBMIT authority. For the same reason, SX requires JCL authority under the TSOAUTH resource class.

The FX Task is the Custom Exit Processor and is started by the CM task for Custom Exit processing.
Once started, FX operates as a TSO Code Pipeline client, communicating with CM through CI.
The FX procedure name is specified to CM using a PARMLIB input statement..
FX moves components between Application libraries and needs appropriate authority to do this within your security product.
The FX requires JCL authority under the TSOAUTH resource class. It will require the same authority as the SX Processor.

The EF Task is the Code Pipeline External Function Processor and is started by the CT task to handle parsing of source (Parse on Save Feature). Additional functionality will be added in the future.
EF communicates with CT to receive the source to parse, and with CM through CI to store the parse results. EF cannot be used to parse source if the Code Pipeline DNA Facility is in use.
The EF procedure name is specified to CT using a PARMLIB input statement.

Basic setup

The installation process is focused on setting up a Code Pipeline environment that looks like the following figure.

Simple Code Pipeline communications setup (Started Tasks)

Task communication

Communication between these tasks is based on a product called MSP (Multi System Platform), which provides the functions that allow these tasks to communicate with each other via TCP/IP and cross-memory services. The CI, CT, and CM tasks communicate with each other via TCP/IP. z/OS-based Code Pipeline tasks (including EF, FX, SX, and TSO Users and batch jobs) communicate with CI via cross-memory services. EF also communicates with CT via cross-memory services. Code Pipeline includes a run-time version of MSP, and the license for Code Pipeline includes a license to use this run-time version for Code Pipeline purposes only.

More complicated communication

More complicated Code Pipeline Environments can be defined and could include Code Pipeline Deploy to transport components to disparate z/OS LPARs.
These types of communications setups are outside the scope of this Installation and Configuration Guide. See the Code Pipeline Remote Server Guide for further details on setting up Servers.

TCP/IP communications

One TCP/IP Port number is assigned to the CM Task to listen on, as shown in the Product Architecture diagram at the beginning of this Overview, to support communication with CI and CT tasks. The CI and CT tasks have the IP Address and Port Number of the CM Task in their configuration files, and they initiate communication with CM on startup. If the Code Pipeline for Eclipse interface of

Workbench for Eclipse

CES

REST APIs or

CES

Browser apps are being used, then a second TCP/IP Port number is required to allow them to communicate with CM via HCI.

Overview

The setup of Code Pipeline with

BMC AMI Host Communications Interface (HCI)

and

Workbench for Eclipse

18.2 and above requires defining six ports as follows:

In the Code Pipeline Guided Configuration dialog for the CM:
- WZCMPORT - port for CM to listen on (for communications from CI and CT)
- WZCMXPRT - port for CM to listen on (for HCI/
  Workbench for Eclipse
  ,
  BMC AMI Common Enterprise Services
  ,
  CES
  REST API 18.02.02 and above, and
  CES
  Browser Apps 18.02.02 and above).
In the Code Pipeline Guided Configuration dialog for the CI:
- WZCIPORT – no longer required. Set to 0 (zero).
- WZCIXPRT – no longer required. Set to 0 (zero).

When the Code Pipeline installation is finished, you will be instructed to update ports and specify encryption on the Maintenance Dialog for the Servers (M.SV) as follows:

A new entry for the default CT server will need two ports:
- Socket - Port for file transfers from other CT/Remote Server/
  Workbench for Eclipse
  17.2
- CSS Socket - Port for
  Workbench for Eclipse
  18.2 and above,
  BMC AMI Common Enterprise Services
  /REST APIs.
The Encryption field on M.SV is used to select the type of encryption, if any, to be used when the CT server communicates with
Workbench for Eclipse
.
The Cross-memory ID field on M.SV is used to define the 4-character cross-memory ID to be used by this CT. This value must be unique across all Code Pipeline CTs running in a z/OS Sysplex, even if they are part of different Code Pipeline systems. Only specify a value if you will be using the Code Pipeline External Function Processor Enhancement.

The following figure provides a general overview of the TCP/IP configuration.

TCP/IP configuration overview

For further network connection information, see Network-Connections.

PARMLIB Information

With Release 22.01, Code Pipeline parameters are managed by the

BMC Common Mainframe Services Controller (CMSC)

. The CMSC component is installed with

BMC AMI Enterprise Common Components

(

ECC

). This address space is a centralized facility that provides common parameter library services for BMC AMI products. It functions in a similar manner to the IBM z/OS PARMLIB. Refer to the Enterprise Common Components Installation and Configuration Guide for complete details on installing and setting up the CMSC.

You may run multiple instances of Code Pipeline on a single LPAR. Each instance will have its own PARMLIB members. For more information, see Multiple-Code-Pipeline-Instances-on-an-LPAR.

Multiple CIs and CTs

You can have a Code Pipeline configuration with a single CM and multiple CIs and CTs. Each CI and CT have their own PARMLIB member, and will require unique names. You should work with the team that supports the CMSC to create meaningful PARMLIB member names for these extra CIs and CTs.

You would also add an appropriate DD statement to each CI and CT. The DD statement takes the form of //PMIIsufx DD DUMMY for a CI and //PMITsufx DD DUMMY for a CT. The value sufx is the PARMLIB member suffix. The following table lists some samples for the names and DD statement for a CT.

Samples of CT Suffix and DD Statement

Suffix	PARMLIB Member Name	DD Statement
TEST	IWCTTEST	//PMITTEST DD DUMMY
TST	IWCTTST	//PMITTST DD DUMMY
T1	IWCTT1	//PMITT1 DD DUMMY

Multiple Code Pipeline Instances

There may be situations where you run more than one CM and its family of CTs and CIs on a single LPAR; for example Deploys will make use of additional CIs and CTs. In this case the Code Pipeline Configuration Dialog will be used to create separate additional PARMLIB members for each of the Code Pipeline instances. The default member, which is specified in the Configuration Dialog, will have a suffix of 00. Additional members will have a suffix of the SERVERID. To make use of these members, the Dialog will add a DD statement to the JCL streams for the different address spaces at the time the Configuration Dialog is run. For more information, see Multiple-Code-Pipeline-Instances-on-an-LPAR.

Important

Each instance of Code Pipeline requires its own unique Warehouse ID.