IBM Workload Scheduler for z/OS, Version 9.3 SPE

AUDIT

Purpose

The AUDIT statement defines how changes to IBM Workload Scheduler for z/OS data is logged. You can specify this statement for a controller or standby controller. You can also use more than one AUDIT statement to define IBM Workload Scheduler for z/OS auditing actions.

Start of change When an access is logged, a record containing auditing information is written to the current log data set, which depends on the value you set for the AMOUNT parameter. The mapping of the records on the log data set is described in Diagnosis Guide and Reference. End of change

When you request logging of accesses to JCL data, logging is performed if the JCL is present in, or is inserted into, the JCL repository.

Note:

Changes to current plan, current-plan-extension, and event-triggering records are always logged for IBM Workload Scheduler for z/OS restart purposes. Read accesses to these resources are not logged, and you cannot prevent the logging of update accesses.
If you set AMOUNT(DATA) or AMOUNT(KEY), auditing records are written to the job-tracking-log data set and this affects how often IBM Workload Scheduler for z/OS performs a current-plan-backup process. Keep this in mind when specifying a value for the BACKUP keyword of JTOPTS. Also consider auditing records when allocating the job-tracking-log data sets, especially if you specify AMOUNT(DATA).
The AUDIT records contain a field to indicate whether or not they are related to a real data change. Based on that field, EQQAUDIT program reports only those records that actually changed from an external point of view. For example, when a dialog user selects a data item in a list through the M (Modify) row command and exits using the PF3 key, without changing the data item, the process rewrites related data records to keep any change that the scheduler performed for internal purposes. In this case, the scheduler creates an AUDIT record for a data item that the external user did not really change, however EQQAUDIT does not report that record. In particular, using the J row command always causes the JCL to be written to the JS file, even if the dialog user did not change the JCL.

Start of change The IBM Workload Scheduler for z/OS sample library contains a program that can format reports of job-tracking, track-log, and extended-auditing records. See IBM Workload Scheduler for z/OS auditing package for more information. End of change

AUDIT is defined in the member of the EQQPARM library as specified by the PARM parameter on the JCL EXEC statement.

Format


>>-AUDIT--+--------------------------+-------------------------->
          |            .-UPDATE-.    |   
          '-ACCESS--(--+-READ---+--)-'   

>--+----------------------------+--FILE--(--+-ALL------+--)----><
   |            .-KEY------.    |           '-+-AD---+-'      
   '-AMOUNT--(--+-DATA-----+--)-'             +-CAL--+        
                '-EXTENDED-'                  +-JLIB-+        
                                              +-JS---+        
                                              +-JV---+        
                                              +-LT---+        
                                              +-OI---+        
                                              +-PER--+        
                                              +-RD---+        
                                              +-RG---+        
                                              +-VAR--+        
                                              +-WS---+        
                                              '-WSCL-'

Parameters

ACCESS(READ|UPDATE)

Defines when IBM Workload Scheduler for z/OS tracks accesses to the file. Specify UPDATE to track all changes to the file. Specify READ to track all accesses.

AMOUNT(DATA|EXTENDED|KEY)

Defines how much data is to be logged by IBM Workload Scheduler for z/OS for accesses to the file.

Specify KEY to log only the VSAM key (this is enough to identify the resource). Specify DATA to log the VSAM key and record.

Specify EXTENDED to use the extended auditing feature. In this case, all data about the database changes is logged in the EQQDBnn data sets (instead of EQQJTnn). The EQQDBnn data sets are created by the EQQPCS14 sample and provide the input for the extended auditing feature. The EXTENDED argument applies only to the following files:

FILE(name of IBM Workload Scheduler for z/OS file)

Defines the name of the file for which auditing is being defined. A separate AUDIT statement is required to identify each file for which you want auditing information recorded. Specify one of these files:

AD: Application description
CAL: Calendar definition
JLIB: JCL in a job library
JS: JCL in the JS VSAM file
JV: JCL variable table
LT: Long-term-plan occurrence
OI: Operator instruction
PER: Period definition
RD: Special resource descriptions
RG: Run cycle group definition
VAR: JCL variable setting
WS: Workstation description
WSCL: All-workstations-closed definition
ALL: All files

Examples

 AUDIT FILE(ALL) ACCESS(UPDATE) AMOUNT(KEY)   1 
 AUDIT FILE(JS) ACCESS(UPDATE) AMOUNT(DATA)   2

In this example of AUDIT statements:

1: IBM Workload Scheduler for z/OS tracks all changes to all files by logging the VSAM key.
2: IBM Workload Scheduler for z/OS tracks all changes to JCL for jobs and started tasks by logging the VSAM key and record.