Milestone 2: Prepare for Installation

Before you install ISPW, 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.

Task 2.1 Establish ISPW Dataset Naming Conventions

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

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

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

SAF Class Attributes

The following are some suggested attributes to be used for the SAF Class definition. The RACF definition for the static Class Descriptor Table (CDT) is shown as an example:

Post z/OS 1.5, it is possible to dynamically define the SAF Class. An example definition for RACF follows:

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. ISPW’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 ISPW works, and it is recommended that only your ISPW Technical Support person be able to update it.

Task 2.4 Create UserIDs for Started Tasks

Installation of the Base ISPW product will result in three permanent Started Tasks (CM, CI, and CT) plus one other Started Task (SX) that is started, when necessary, for ISPW  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 ISPW Deploy feature, a fifth started task (RX) will need to be defined. See the ISPW-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 ISPW 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 datasets 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 datasets 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 datasets specified in the PROC for the CT.
• ALTER access to the Warehouse Datasets from Establish ISPW 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.
• ISPW 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 ISPW-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 datasets specified in the PROC for the SX.
• UPDATE access to all Application datasets managed by ISPW.
• ALTER access to a specified HLQ for a “Set Log” (as specified for Set Log Datasets in Establish ISPW 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 ISPW will be used to deploy UNIX files.
• RACF authority to datasets 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 datasets specified in the PROC for the FX.
• UPDATE access to all Application datasets managed by ISPW.
• ALTER access to a specified HLQ for a “Set Log” (as specified for Set Log Datasets in Establish ISPW Dataset Naming Conventions).
• 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 datasets specified in the PROC for the EF.

Task 2.5 Plan System Libraries

During ISPW configuration, you will enter the library dataset 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 2.5.1 Determine ISPF Dataset Names

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

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

Compiler and Related Dataset Names

Task 2.6 Plan Started Task Parameters

ISPW relies on four Started Tasks (CM, CI, CT, and SX) to perform all its operations. Without these Started Tasks, ISPW 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 ISPW 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 CM Specific 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 2.6.5 Setting the Priority of ISPW Started Tasks

For proper performance, the started tasks used by ISPW 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 ISPW 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 ISPW/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 ISPW CT startup and handle parse operations for files saved by ISPW/Eclipse users. As such, they could be considered similar to batch, but should probably be given higher priority than batch.