Previous Topic: Define a DASD-Only LogstreamNext Topic: Start the CA Compliance Manager Components (Manually)

Implementing CA Compliance Manager for CA Chorus for Security and Compliance Management › Determine Which Type of z/OS System Logstream to Define › Define a CF-Based Logstream

Define a CF-Based Logstream

The CMGRLDEF job defines a Coupling Facility (CF)-based system logstream using the IBM Utility, IXCMIAPU.

Follow these steps:

  1. Edit the CMGRLDEF job in CAI.CEIQJCL0.
  2. Delete STEP1.

    Note: STEP1 is used only for defining a DASD-only logstream.

  3. Edit STEP2

    Modify the job statements to conform to your installation standards.

  4. Edit STEP3

    Modify the job statements to conform to your installation standards.

    Note: This STEP merges the CFRM structure definition into the current active CFRM policy (in STEP2).

  5. Submit the job.
  6. Review the output of the CMGRLDEF job.

    Verify that the job completed successfully, and that the CF-based logstream was defined.

Enable SSL for CA Compliance Manager Chorus Alerts

This procedure enables the CA Compliance Manager Alert and Monitor components to send CA Chorus Alerts using SSL.

Note: Do this procedure for both the Alert and Monitor started tasks.

Follow these steps:

  1. Review the Monitor and Alert started tasks procedures for a CEEOPTS DD. If a CEEOPTS DD already exists, skip this step and proceed to step 2.

    If a CEEOPTS DD does not exist, add one.

    Example:

    //CEEOPTS DD DISP=SHR,DSN=your.proclib(CMGROPTS)

    Note: 'CMGROPTS' is an example of a PDS member name. Use any member name as long as it meets the standard PDS naming conventions.

  2. Edit the 'CMGROPTS' PDS member referenced by the CEEOPTS DD so that it has the following configuration parameters: 
    TRAP(OFF),POSIX(ON) 
ENVAR("_CEE_ENVFILE_S=DD:STDENV")
  3. In the Monitor and Alert started task procedures, add a STDENV DD.

    Example:

    //STDENV DD DISP=SHR,DSN=your.proclib(ALERTS)

    Note: 'ALERTS' is an example of a PDS member name. Use any member name as long as it meets the standard PDS naming conventions.

  4. If you are using a key database, skip this step and proceed to step 5.

    If you are using a keyring, create the 'ALERTS' PDS member referenced by the STDENV DD so that it has the following configuration parameters:

    AXIS2C_CERT_KEYFILE=userid/ringname

    Replace the ‘userid/ringname’ text with the name of the key ring.

    Important! The user ID of the started task must be permitted access to the IRR.DIGTCERT.LISTRING resource in the FACILITIES task. If the user ID specified in the environment file above is the same as the user ID of the started task, then you must permit READ access; otherwise, if the user IDs are not the same, you must grant UPDATE access.

    Important! The key ring name is case sensitive. Enter the exact name of the key ring.

    The name of the key ring can be obtained through the security package as follows:

    After making these changes, but before starting the alert component, create the key ring and connect the appropriate certificate to it. The appropriate certificate is the root CA certificate that signed the certificate that the JBOSS server uses. You can use the Java keytool utility to export this certificate from the key store of the JBOSS server. Import the certificate into the security manager on the system that will run the alert component and connect it to the alert component’s key ring. The certificate should be associated with either the user ID of the alert component or to the CERTAUTH ID. If you do not associate the certificate with the CERTAUTH ID, you must specify “USAGE(CERTAUTH)” when connecting the certificate to the key ring.

  5. If you are using a key database, create the 'ALERTS' PDS member referenced by the STDENV DD so that it has the following configuration parameters: 
    AXIS2C_CERT_KEYFILE=/dir/dbname
AXIS2C_CERT_LABEL=label
AXIS2C_CERT_PASSWRD=passwrd