Implementing Multiple CA 11's On A Single System
search cancel

Implementing Multiple CA 11's On A Single System

book

Article ID: 55278

calendar_today

Updated On:

Products

CA-11 Datacom DATACOM - AD

Issue/Introduction

Multiple CA 11's need to run concurrently on a single LPAR.   To implement this the Multiple Subsystem Facility (MSSF) needs to be used--how is this process implemented?

 

 

Environment

Release:
Component: 11

Resolution

The process of running multiple CA 11's concurrently on a single LPAR is known in CA 11 as Multiple Subsystem Facility (MSSF). With this setup the SVC and load modules between CA 11's can be shared, as well as the Datacom MUF (or each CA 11 can use its own). Installation considerations for MSSF would be determined by the relationship between the multiple CA 11's. Just as important is how the data for each CA 11 will be separated. Three options for this exist:

The first option is to allow multiple CA 11's to use the same Datacom/MUF, accessing data unique to each CA 11 by Subsystem Name.

Another option is to have a different DBID for each CA 11 that utilizes the same Datacom/MUF.

A third option is to run a Datacom/MUF for each CA 11. When choosing the option of creating a separate DBID for implementing MSSF, several steps from the installation need to be repeated. 

   STEP                                                   SAMPJCL LIBRARY MEMBER     
   ----                                                   ----------------------     
        
  --RESOLVE DATABASE ID AND URT NAME                      AL7DBID (L730DBID in r3.0)      
  --START CA DATACOM     
  --ALLOCATE CA 11 PURGE FILE                             AL7ALOP (L730ALOP in r3.0)      
  --DEFINE AND CATALOGE CA 11 CA DATACOM TABLES           AL7AD1 (L730AD1 in r3.0)     
  --ALLOCATE CA 11 DATA AREA AND INDEX                    AL7AD2 (L730AD2 in r3.0) 

CAIRIM
-----------

CAS9 must be run to initialize each CA 11. It is important to keep in mind that the VERS and the SSN value within the PARM must be unique. The first subsystem initialized must use VERS of L7B0. Subsequent subsystems need to use a unique VERS. The SSN value used must be the same as the one specified in the CONFIG file for each CA 11. The default SSN is CAL7.

Below is an example of the CAIRIM statement to initialize multiple CA 11's on the same system.

  
  PRODUCT(CA-11 GENLEVEL 0108) INIT(L7B0INIT)    -      
  VERSION(L7B0) PARM(SSN=CAL7,SVC=169,REINIT)     
  PRODUCT(CA-11 GENLEVEL 0108) INIT(L7B0INIT)    -      
  VERSION(L7BT) PARM(SSN=CALT,SVC=169,REINIT) 

The same example can be used to initialize multiple CA 11's on the same system with a r11 and 3.0 version running at the same time.

          
  PRODUCT(CA-11 GENLEVEL 0108) INIT(L7B0INIT)     - /* r11 Subsystem */     
  VERSION(L7B0) PARM(SSN=CALT,SVC=169,REINIT)      
  PRODUCT(CA-11 GENLEVEL 0108) INIT(L7B0INIT)     - /* r3.0 Subsystem */     
  VERSION(L7BA) PARM(SSN=CAL7,SVC=169,REINIT) 

NOTE: In a MSSF setup with both 3.0 and r11 subsystems, the r11 version of the SVC must be used for both. The r11 SVC is downwardly compatible with the 3.0 release. The 3.0 release should not be run once r11 has been initialized by CAIRIM. If there is a need to go back to 3.0, you should stop the r11 CA 11 and restart the 3.0 CA 11 with RECOVCSA=NO specified in the CONFIG file.

U11SSSEX will have to be coded to indicate which jobs would run under any subsystem other than CAL7. The U11SSSEX exit is the recommended way to control the selection of a subsystem. While the //@SSNxxx DD override statement can be used, it does not invoke the CA 11 Tracking system (in the MSSF environment).

Also keep in mind that CA 11 utilities and the Online system can only access one CA 11 per execution. The override DD can be used to force the selection of a particular CA 11 database.