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. To see documentation for that version, see BMC AMI Datastream for z/OS 7.1.

CZAJOBLG parameters


CZAJOBLG is a program that streams the JES-spooled output of one or more running z/OS jobs or started tasks to any SIEM in real-time.

CZAJOBLG’s initial source of parameters is the PARMS= parameter specified or defaulted in the Start command. BMC supplies a sample CZAJOBLG parameter file as member CZJPARMS of the installation data set amihlq.CZAGENT.CNTL. You have to edit CZJPARMS to suit your particular situation.


JOBLOG names

Each specification of a JES-spooled SYSOUT data set that gets forwarded to a SIEM is called a JOBLOG definition. Each JOBLOG definition has a name, either explicit or implicit. If you code the NAME parameter then you might give the definition an explicit name of your choice. If you do not code NAME and code DDName (either on JOBLOG or DEFAULT), the implicit name of the JOBLOG definition is the specified JOBID or JOBName followed by a period and the DDname (without procname or stepname). 

Example

MYJOB.SYSPRINT or STC03862.SYSUT2; if DDName gets omitted from both DEFAULT and JOBLOG then the default for NAME is the JOBID or JOBName.

JOBLOG names are limited to 20 characters and might not contain embedded blanks or parentheses.

The name of the associated JOBLOG definition gets sent to the SIEM with each SYSOUT record as field JOBLOG_Name.

You might have only one effective JOBLOG definition with a given name, whether specified with NAME or allowed to default. Multiple JOBLOG definitions in the parameter file with the same name are prohibited. See the next section, Changing Previously-Defined JOBLOGs.

Changing previously defined JOBLOGs

In the following rules, NAME applies equally whether the name is coded explicitly in NAME or constructed implicitly from any DDname and JOBID or JOBName.

  • Each JOBLOG definition gets internally tagged with its origin, either a statement in a parameter file or a MODIFY JOBLOG command.
  • If a JOBLOG statement in a parameter file attempts to define a JOBLOG with the same name as that of a previous JOBLOG statement in the file, then the attempt is rejected with an error message.
  • A MODIFY JOBLOG command that defines a JOBLOG that is identical to an existing JOBLOG definition causes the origin to be set to MODIFY, but otherwise has no effect.
  • A MODIFY JOBLOG command that defines a JOBLOG with the same name as a pre-existing JOBLOG definition and different options modifies the pre-existing JOBLOG definition and sets its origin to MODIFY.
  • A MODIFY DELETE command might be used to close and remove from processing any JOBLOG definition, whether the origin is parameter file or MODIFY.
  • On a parameter file refresh (MODIFY PARMS) the following rules apply:
    • If the new parameter file contains a JOBLOG statement that defines a JOBLOG that is identical to a pre-existing JOBLOG, then the origin of the pre-existing JOBLOG is set to parameter file, but otherwise, the statement does not affect.
    • If the new parameter file contains a JOBLOG statement with the same name as a pre-existing JOBLOG definition and different options, the pre-existing JOBLOG definition gets modified, and the origin gets set to the parameter file.
    • If the new parameter file omits the definition of a pre-existing JOBLOG with an origin of the parameter file, then the pre-existing JOBLOG is closed and removed from processing. (The pre-existing JOBLOG is not closed and removed if it has an origin of MODIFY.)
  • If an existing JOBLOG definition is modified and if the changed options include CLASSes, DDname, JESName, JOBID, JOBName or SYSName and the JOBLOG is already allocated successfully, the pre-existing definition is closed and re-started (in other words, an SYSOUT data set, possibly the same data set or a different qualifying data set is re-sent from the beginning). Otherwise, processing continues from the next SYSOUT record with the changed options. 

    Example

    You might change SEVerity; if so, processing of the SYSOUT file simply continues, and the next record gets sent with the new severity.

See the following topics in this section for more information:

 

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