Tailor the Startup Procedures

Starting Your Product › How to Configure Without CA CSM › Tailor the Startup Procedures

Tailor the Startup Procedures

At startup, CA OPS/MVS invokes customizable procedures that control startup and set the CA OPS/MVS parameters.

To tailor the startup procedures

Tailor the OPSTART1 initialization CLIST.
The OPSTART1 initialization CLIST resides within the deployed runtime hlq.CCLXCLS0 data set that is allocated within the //SYSPROC concatenation of the OPSMAIN procedure. This CLIST executes within a TMP that is internally created during product start-up, and its primary purpose is to invoke the OPS/REXX program that sets up various CA OPS/MVS parameters. The OPSTART1 CLIST invokes this OPS/REXX program using the following statement:
```
OX 'SYS1.PARMLIB(&SUBSYSNAME.PA&MEMBER)'
```
If the residing location of SYS1.PARMLIB is not desired, then change this statement accordingly. Additionally, the SUBSYSNAME and MEMBER substitution variables are set within the OPSMAIN procedure or can optionally be overridden with the START command of OPSMAIN (S OPSMAIN, MEMBER=99).

Default SUBSYSNAME setting: OPSS

Default MEMBER setting: 00

Thus, the default start-up OPS/REXX program that is called by the OPSTART1 CLIST is named OPSSPA00. For new installations of CA OPS/MVS we recommended using the default SUBSYSNAME and MEMBER settings.
Copy and tailor the supplied start-up OPSSPA00 OPS/REXX program.
Copy member OPSSPA00 of the hlq.CCLXCNTL data set into the data set that was specified within the OPSTART1 CLIST (step 1).

This sample provides the logic to set various control parameters within CA OPS/MVS and also allocate the SYSCHK1 DIV data set and any OPSLOG DIV data sets that were created using the DEFDIV utility during installation step 1. Follow the detailed implementation steps located within the beginning comments of this member to successfully allocate these DIV data sets, and to override default values for these specific CA OPS/MVS parameters:

RULEPREFIX

Prefix name of the AOF rulesets

RULESUFFIX

Suffix name of the AOF rulesets

OSFCHAR

Override default command character of '!' for OPS/MVS servers

OSFSTC

Name of JCL procedure for OPS/MVS servers if not using the default of OPSOSF

For first-time users, the default settings for the remaining CA OPS/MVS control parameters let you quickly start and begin using the product. In the future, specific automation and environmental requirements may have you updating the default values of other CA OPS/MVS control parameters. Some of the most commonly updated parameters include the following:

GLOBAL* parms

Sets global variable parameter control.

OSF*

Controls all aspects of OPSOSF.

OCCONSOLENAME, EXTENDED*, EXTRA*

Controls the count and names of consoles used from within automation to issue commands to the system.

SSICMD, SSIMSG

Determines how command and WTO hooks are to be set.

STATEMAN, SSM*

Controls the System State Manager Component.

For specific details on these common parameters as well as all other CA OPS/MVS control parameters, see the Parameter and Reference. Additionally, this manual describes how to set these parameters outside of installation using the programmatic OPSPRM() OPS/REXX function, or manually using the OPSVIEW facility.
(Optional) Tailor the OPSTART2 OPS/REXX program
When the main CA OPS/MVS address space completes its internal initialization (this does not mean that the AOF is completely active) and before any OSF address spaces are started, CA OPS/MVS schedules the OPSTART2 OPS/REXX program for execution in the first OSF TSO server that is ready by sending the following command to the OSF TSO execute queue:
```
OI OPSTART2
```
The command OI OPSTART2 is the first OSF TSO server command that is executed. The distributed OPSTART2 program is designed to run only as an OPS/REXX program. If it is invoked as a TSO/E REXX program, it issues a highlighted warning message and terminates. The OPSTART2 OPS/REXX program must be in either the SYSEXEC (source) or OPSEXEC (compiled) concatenation of the OPSOSF procedure.

The OPSTART2 program can include any OPS/REXX functions, host commands, or TSO commands that you want to execute after CA OPS/MVS startup. OPSTART2 calls an external procedure, MSFINIT, which then calls the InitMSF internal procedure. The InitMSF procedure contains sample ADDRESS OPSCTL MSF control statements to start sessions between the current copy of CA OPS/MVS and two remote CA OPS/MVS copies.
Copy OPSTART2 from hlq.CCLXSAMPto your hlq.USER..REXX.
Note: You can define the MSF in the OPSTART2 program; however if you do, ensure that VTAM is running before you attempt to start it.

OI OPSTART2 is the default initial OSF server command. You may change it using the BEGINCMD parameter during product initialization (for details, see Tailor the OPSSPA00 REXX Program in this chapter). You may also set the BEGINCMD parameter to execute a different OPS/REXX program or even a CLIST or TSO/E REXX program.

For example:
```
T = OPSPRM(“SET”,"BEGINCMD","OI FIRSTPGM")
```
(Optional) Implement an AOF initialization OPS/REXX program.
Using the AOFINITREXX product parameter, you can specify the name of an OPS/REXX program to be executed during AOF initialization. This special OPS/REXX program executes before the product enables all auto-enabled rules, allowing you to logically control your AOF rules environment. You can use OPS/REXX language facilities to control your AOF environment based on SMF ID, time of day, or whatever criteria make sense for each system.

Almost all host command environments, like ADDRESS AOF, are available in this program. The only exception is ADDRESS TSO, where TSO commands are not allowed in the main product address space. ADDRESS TSO host commands will be treated like ADDRESS OSF host commands -they will be queued for execution in a server. At this point in CA OPS/MVS startup, the servers have not been started; the queued commands execute later when the servers are started. Access to existing global variables and relational tables is also available, which is useful for retaining information from a previous IPL or to pass information to automation routines that will execute later.

Notes:
- Any function call or host command that causes a WAIT will cause the AOF initialization of the product to be delayed. The OPSWAIT REXX function is an example.
- If the REXX program whose name you specify as the value of AOFINITREXX RETURNs or EXITs with a value of 8, the automatic enablement of all rules during AOF initialization is bypassed. All other return codes allow automatic enablement.
(Optional) Tailor OSFSTART OPS/REXX program.
The OPSOSF procedure, which creates a CA OPS/MVS server address space, always invokes the OSFSTART TSO/E REXX EXEC as its first command. You can customize this REXX EXEC, which is found in the hlq.CCLXCLS0 data set.

CA OPS/MVS can preallocate the data set used to capture the output of commands addressed to TSO in a server through the ADDRESS TSO host environment of OPS/REXX. To do this use the OPSTSO DD allocated in the OSFSTART REXX EXEC. After you specify this DD, the preallocation is used for all commands instead of allocating a data set for every REXX program. The ALOPSTSO subroutine in the OSFSTART REXX dynamically allocates a uniquely named OPSTSO data set for each server.

A typical use for the OSFSTART REXX EXEC is allocating ISPF data sets for use by the server. ISPF requires a unique profile data set name for each server, which you can revise the REXX EXEC to provide.

Note: We recommend that you use ALLOCSPF, located in the OPS.CCLXSAMP library, to allocate ISPF data sets for use by a server. This sample shows you two different ways of allocating a unique ISPF profile data set for each server. You should read the comments in this sample carefully before customizing and using it.

Your startup procedures are defined and you are ready to verify your installation.