Limited supportBMC provides limited support for this version of the product. As a result, BMC no longer accepts comments in this space. If you encounter problems with the product version or the space, contact BMC Support. BMC recommends upgrading to the latest version of the product.

Setting up CZAJOBLG


CZAJOBLG's initial source of parameters is the PARMS= parameter specified or defaulted in the START command (see START-CZAJOBLG-command). BMC AMI Datastream supplies a sample CZAJOBLG parameter file as member CZJPARMS of the installation data set amihlq.CZAGENT.CNTL. You must edit CZJPARMS to suit your situation. See CZAJOBLG-parameters.

For more informatoin about general parameter file syntax considerations, see Format-of-parameter-and-field-definition-files.

In the following examples, you must change the values in angle brackets (<>) for your situation, and remove the angle brackets.

BMC AMI Datastream as instance 0. If you run BMC AMI Datastream as instance 0 and monitor the output of one or more running jobs or started tasks that produce a single user SYSOUT data set. 

Important

  • 0 is the default BMC AMI Datastream instance number. To determine the instance number of a started task, enter the console command:
    F taskname,D(INSTANCE).
    The instance number of that started task is shown on the row labeled this instance.
  • To determine the user SYSOUT data sets produced by a running job, go to the DA panel in SDSF. Type a ( ? ) next to the job in question and press Enter. User SYSOUT data sets are listed with an actual StepName rather than JESn.

You need a CZAJOBLG parameter file such as the following:

JOBLOG JOBNAME(<myJob>)
JOBLOG JOBNAME(<someJob>)

If one or more of the jobs is producing more than one user SYSOUT data set, then add the DD name of the desired data set to the JOBLOG statement. You can code more JOBLOG statements for additional DD names if you want.

JOBLOG JOBNAME(<myJob>) DD(<sysprint>) 

or

 JOBLOG JOBNAME(<someJob>) DD(<step2.errLog>) 

BMC AMI Datastream not as instance 0. If you run BMC AMI Datastream as an instance other than 0, add a DEFAULT statement specifying a default instance number or name:

DEFAULT INSTANCE(<2>) 

or

DEFAULT INSTANCE(<CorreLog.test>) 

To see if CZAJOBLG is working, enter the following command at the console:

MODIFY <taskName>,D(JOBLOG)) 

You should see a display like the following:

CZA0711I JOBLOG Definition    Job ID   Last Data Time     Read     Sent
CZA0712I -------------------- -------- -------------- -------- --------
CZA0713I MYJOB                STC02429 20180629T13:27    47915    47914
CZA0713I OTHERJOB             STC00544                       0        0
CZA0713I SOMEJOB               

If you see non-zero Read and Send counts (as for MYJOB as discussed), CZAJOBLG is forwarding SYSOUT data to your SIEM. If the line is largely blank like SOMEJOB as previously discussed, then CZAJOBLG is unable to find the job or the BMC AMI Datastream instance or event. Check the CZAJOBLG listing for warnings and errors. If the line is partially populated, but the counts are zero like OTHERJOB, as previously discussed, then the job was located but the specified or default DD name does not exist. If you cant get beyond the problem, contact BMC Support.

After you have basic job log monitoring working, you might want to make changes to improve the readability or recognizability of the results in your SIEM:

JOBLOG NAME(<widget_status>) JOBNAME(<myJob>)
DD(<sysprint>) 

or

JOBLOG JOBNAME(<someJob>) DD(<step2.errLog>) SEV(ERROR) 

You might also want to use FILTER or MATCH to limit the data sent to your SIEM to specific records of the data sets.

If you want a running CZAJOBLG to forward additional spooled data sets to your SIEM, there is no need to stop and restart CZAJOBLG. Simply enter the following command at the console:

MODIFY <taskName>,JOBLOG(JOBN(<otherJob>)) 

The amount of CPU time used by CZAJOBLG when idle is inversely proportional to the value of DATADelay (default 15 seconds). You could cut the idle CPU time in half by specifying:

DEFAULT INSTANCE(<2>) DATAD(30) ; Affects subsequent JOBLOGs 

On the other hand, you could improve the timeliness of the monitoring of one particular JOBLOG by specifying a shorter DATADelay for that JOBLOG:

JOBLOG JOBNAME(<someJob >) DD(step2.errLog) DATAD(5) 

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*