At startup, CA OPS/MVS invokes customizable procedures that control startup and set the CA OPS/MVS parameters.
To tailor the startup procedures
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 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:
Prefix name of the AOF rulesets
Suffix name of the AOF rulesets
Override default command character of '!' for OPS/MVS servers
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:
Sets global variable parameter control.
Controls all aspects of OPSOSF.
Controls the count and names of consoles used from within automation to issue commands to the system.
Determines how command and WTO hooks are to be set.
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.
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.
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")
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:
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.
Copyright © 2014 CA Technologies.
All rights reserved.
|
|