Configuring CIA Real-Time Processing for CA Chorus › Implement the CIA Real-Time Feature › Begin CIA Real-Time Recording

Begin CIA Real-Time Recording

Perform these steps on every z/OS image whose security information is represented in the CA Chorus CIA repository.

If a security product database is shared across multiple z/OS images, perform these tasks on each of the z/OS images. Administrative commands, SAF calls, and user signon and signoff processes on any of the z/OS images can change information in the security database that is replicated in the CIA repository. The CIA real-time process must communicate all of these changes to the CIA repository.

The following steps cause the security product to begin recording changes made to security product information that is replicated in the CIA repository.

1. Define the CIA real-time feature logstream.

   The CIA real-time feature uses a dedicated z/OS system logger logstream to record update requests made to any security product information that is replicated in the CIA repository. The CIA real-time component reads this logstream and communicates the update requests to the CIA repository.

   Modify and run the CIALOGST sample job to define the CIA real-time feature logstream.

   Note: A separate and unique logstream is required for each z/OS image.

   The CIALOGST job defines the logstream as DASDONLY(YES), AUTODELETE(NO), and RETPD(0). This is intended to keep the offloaded data maintained by z/OS System Logger to a minimum. The z/OS system Logger is prevented from deleting any event records that it has offloaded which the CIA real-time component has not marked as deleted. These values can be changed per your installations requirements.

   The size required for the logstream depends on a number of factors. Under normal processing, the life of any given record in the logstream is measured in seconds or less. The record is marked deleted as soon as the CIA database update has been completed. A minimal number of active records is present in the logstream, and any offloaded data is marked deleted by the CIA real-time process. However, two situations where this will not occur.

   • During the initial implementation, the time that elapses between when the security product begins recording update requests into the logstream and when the CIA real-time component is started. For that duration, update requests are carried in the logstream without being processed and deleted.
   • When any of the components in the CIA real-time process communication path are unavailable, the update requests remain in the logstream until the process path is restored. The components in the communication path are:
     • CIA real-time component
     • TCP/IP
     • CA DSI Server
     • CIA subsystem with the CIA repository

   We recommend that you make an evaluation of your network and system stability and the effort involved in reloading the CIA repository information. If the time involved in either of the situations described is greater than the size of the logstream allows, the logstream fills up and update requests will be lost. In this case, the security information in the CIA repository for this system must be deleted and repopulated. If this occurrence is likely and the effort involved is great, increase the size of the logstream accordingly.

   Each block on the logstream contains a single event record and is 4096 bytes long. The number of records which the logstream can hold has an initial value of 1000 (‘(STG_SIZE(1000)’). Increasing this number increases DASD space requirements and reduces the number of offloads performed by the z/OS system logger. Decreasing the number has the opposite effect. Since each system is different, it is important to monitor the number and frequency of offloads and balance it with the performance impact an offload can cause.

   The definition of the parameters discussed and the various options and considerations for allocating and managing z/OS system logger logstreams can be found in the IBM Redbook System Programmer’s Guide to: z/OS System Logger (SG24-6898-01).

2. Modify the CA Top Secret control options to enable recording of update requests to the CIA logstream.

   When specified, the following fields in the CA Top Secret control options enable the recording of update requests to the CIA logstream. For more information about the CA Top Secret control options, see the CA Top Secret Control Options Guide.

   CIART(ACTIVE)

   Specifies that CA Top Secret is to begin recording to the CIA logstream.

   CIALOGNAME

   Specifies the name of the logstream used by the CIA real-time process. This name must match the logstream name chosen in the CIALOGST job that created the logstream.

   CIAMAXSTOR(25|nnn)

   Specifies the maximum amount of above the bar (64 bit) storage in the CA Top Secret address space that is used to temporarily hold the queue of update requests that are waiting to be written out ot the CIA logstream.

Note: In order to specify the CA Top Secret control options, you must also provide the CIAHOST and CIAPORT values. For more information about these options, see CIA Real-Time Control Options.