Installation and Configuration

This section provides information about the following topics:

• Product Architecture
• Installation Preparation
• ISPW Software Delivery
• TCP/IP Communications
• Compuware PARMLIB Information

Product Architecture

ISPW 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 Compuware Enterprise Services (CES) Web server. See the ISPW Structure diagram. A fifth started task, RX, is only used with ISPW Deploy. A sixth started task, FX, is only used with ISPW Custom Exit processing. A seventh optional started task, EF, is used to handle parsing of source. For more information, see Started Task Details.

ISPW Installation

An ISPW installation consists of the following:

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

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-ISPW” in the ISPW-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.

ISPW Structure

ISPW Software Delivery

ISPW 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 ISPW software using the BMC Compuware 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 ISPW Started Tasks in a standard ISPW Implementation:

• CM Task: This is the ISPW Server, which processes all requests with respect to ISPW Operations.
• CI Task: This is the Communications Interface task, which is responsible for passing on requests from ISPW 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 ISPW managed components between the Component Warehouse and working data sets. ISPW 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 ISPW 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 ISPW is implemented, a sixth STC called RX is required, which is similar in definition to the SX Task. This is further described in the ISPW-Deploy-Reference.

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

CM

• For each ISPW system (that is, separate Db2 Repository), a single CM task is required.
• The CM task controls ISPW 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 ISPW.
• 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.

CI

• The CI task acts as an intermediary between ISPW 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 “ISPW”, but a different value may be used in the event of conflict with the name of an existing started task or subsystem. Contact BMC Software if required.
• One CI task is required for each z/OS system image on which there are ISPW TSO users (or SX Tasks). ISPW 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 ISPW clients.)

CT

• 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 ISPW 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).

SX

• 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 ISPW 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 on an input card to CM.
• 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.

FX

• 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 ISPW 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.

EF

• The EF Task is the ISPW 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 ISPW 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 an ISPW environment that looks like the following figure.

Simple ISPW 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 ISPW 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. ISPW includes a run-time version of MSP, and the license for ISPW includes a license to use this run-time version for ISPW purposes only.

More Complicated Communication

More complicated ISPW Environments can be defined and could include ISPW 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 ISPW Remote Server Guide for further details on setting up Servers.

TCP/IP Communications

A single 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. 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.

Overview

The setup of ISPW with BMC Compuware’s Host Communications Interface (HCI) and Topaz Workbench 18.2 and above requires defining six ports as follows:

• In the ISPW 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/Topaz Workbench, BMC Compuware Enterprise Services CES REST API 18.02.02 and above, and CES Browser Apps 18.02.02 and above).
• In the ISPW Guided Configuration dialog for the CI:
  • WZCIPORT - port for CI to listen on (for ISPW Remote Servers and Topaz Workbench 18.02.00 and below)
  • WZCIXPRT - port for CI to listen on (for BMC Compuware Enterprise Services CES REST API 18.02.01 and below, and CES Browser Apps 18.02.01 and below).

When the ISPW 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/Topaz Workbench 17.2
  • CSS Socket - Port for Topaz Workbench 18.2 and above, BMC Compuware 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 HCI/Topaz Workbench.
• 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 ISPW CTs running in a z/OS Sysplex, even if they are part of different ISPW systems. Only specify a value if you will be using the ISPW External Function Processor Enhancement.
• HCI will need a port for Topaz Workbench to communicate to HCI, and the HCI configuration will use the WZCMXPRT (for Topaz Workbench 18.02.01 and above).

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

TCP/IP Configuration Overview

For further network connection information see Network Connections.

Compuware PARMLIB Information

With Release 18.02, ISPW parameters are now managed by the BMC Compuware Mainframe Services Controller (CMSC) and no longer reside in ISPW parameter data sets. The CMSC component is installed with Enterprise Common Components (ECC). This address space is a centralized facility that provides common parameter library services for BMC Compuware 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 ISPW on a single LPAR. Each instance will have its own PARMLIB members. For more information, see Multiple ISPW Instances on an LPAR.

Multiple CIs and CTs

You can have an ISPW 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

Multiple ISPW 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 ISPW Configuration Dialog will be used to create separate additional PARMLIB members for each of the ISPW 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 ISPW Instances on an LPAR.