Requirements

Running Adabas Audit Data Retrieval in a multi-CPU environment requires Open Communications Facility (OCF). You can use Adabas Audit Data Retrieval or any other Beta Systems product as OCF node.

For information on defining the required OCF and VTAM definitions, see "Multi-CPU with the Open Communication Facility (OCF)" in BSA Installation and System Guide.

Setting up Adabas Audit Data Retrieval master and slave subsystem

When two Adabas Audit Data Retrieval subsystems share a single database, the Adabas Audit Data Retrieval subsystem that controls the database is the master subsystem, the other Adabas Audit Data Retrieval subsystem is the slave subsystem. You must use different subsystem IDs for each subsystem.

Proceed as follows to set up a second Adabas Audit Data Retrieval subsystem (slave):

1. Copy the BETA.PARMLIB member B97LSTxx used by the master Adabas Audit Data Retrieval subsystem to a different member name. Change the following parameters for the slave subsystem:
   • B97_SSID

   Do not modify parameter BQL_MASTER_SSID. This parameter must be identical in both LST members. It defines the subsystem ID of the Adabas Audit Data Retrieval master subsystem.

   In both LST members, enter the required OCF (Open Communication Facility) statements for a VTAM connection between both CPUs. For more information, see BSA Installation and System Guide.

2. Copy the LST member B97LSTxx used by the slave Adabas Audit Data Retrieval subsystem to the parameter library on the other system.
3. Enter the new subsystem ID in member IEFSSNxx of your SYS1.PARMLIB dataset or another dataset concatenated in the MSTJCLnn dataset or in the LOADnn member. Initialize the new subsystem as described in installation step 3 in this manual.
4. Copy the started task procedure to the PROCLIB on the other system.
5. In the new started task procedure, change the EXEC parameter to point to the new B97LSTxx parmlib member.
6. In the Adabas Audit Data Retrieval master subsystem, define a new System Option Record (SYS) for the new system under option S.2. Under this option, enter the subsystem ID and VTAM Net ID of the slave subsystem.
7. Start the new started task.
8. To access the new subsystem, the appropriate subsystem ID must be entered in the user profile (option P.2). You can now change all parameters of the new subsystem online.

Notes on security

You must perform the same subsystem definition steps, described above, on the local z/OS system, with the same subsystem ID and security exits, as are performed on the remote CPU. This is in order to provide the same level of security checking on the local z/OS system that would be required on the remote z/OS system to access the resources in the started task.

To do this, you must perform the same Adabas Audit Data Retrieval subsystem initialization (via program BST01ARI, during IPL or in batch) on the local CPU as was performed for the remote CPU where the Adabas Audit Data Retrieval subsystem actually resides.

For example, if your local OCF node subsystem ID is B97X, and the remote Adabas Audit Data Retrieval subsystem ID your local online users require access to is B97P, then the following IEFSSNxx definitions must be accessible to the local z/OS system:

+-----------------------------------------------------------------------+
|B97X,BST01ARI,'BETA.PARMLIB(B97SSI00)' |
|B97P,BST01ARI,'BETA.PARMLIB(B97SSI01)' |
+-----------------------------------------------------------------------+

You can also define and initialize the subsystems dynamically. For each subsystem, enter the command SETSSI ADD,SUB=ssid and then run B97INIT on the local CPU.

In addition, the SVC number specified in B97SSI00 (via the SVC= parameter) must also be initialized on the local z/OS system (as described in the BSA Installation and System Guide).

If the Beta SVC number in use on the remote system is different from the one in use on the local system, you must change B97SSI00 by copying it to a new member such as B97SSI08 (this should contain the Beta SVC number in use on the local system), and use the following IEFSSNxx entries instead:

+-----------------------------------------------------------------------+
|B97X,BST01ARI,'BETA.PARMLIB(B97SSI00)' |
|B97P,BST01ARI,'BETA.PARMLIB(B97SSI08)' |
+-----------------------------------------------------------------------+

Finally, the security exits and security environment used for online users running on the remote CPU must also be available on the local CPU. This is done because security checking (logon and access validation) is always performed on the local CPU, even if the access is to a remote Adabas Audit Data Retrieval subsystem.

Note on copying load libraries

We recommend using IEBCOPY with COPYMOD for copying load libraries.

Copying load libraries with ISPF may lead to problems under certain conditions.