Job Log Monitoring is designed to monitor JES spool files only.

The JCL JES spool output file can be a classical definition like this one:
It can contain the definition of a temporary data set:
Or it can contain the definition of a temporary data set with additional parameters:

The current implementation supports any JES spool output file regardless of whether the job is executing or the job has finished. However, in the latter case the output must still be available on the JES output queue and the user has to ensure that the output is processed only once.

To use joblog monitoring, NetView must have a JES job ID. If the user enables the DSIRQJOB task, the JES job ID can be obtained by starting the DSIRQJOB. If the user disables the DSIRQJOB task, the INGTJLM task will automatically acquire a JES job ID as needed when joblog monitoring is started. Before any attempted shutdowns of JES in both cases, the user must ensure that the job ID is released by stopping either the DSIRQJOB or INGTJLM task, whichever they have employed (refer to the best practice policies for SA's recommended approach). Alternatively, refer to Starting the NetView Program Before Starting JES topic in the NetView Installation: Getting Started manual. This topic explains how to use the NetView MVS Command Revision function to stop the DSIRQJOB job when JES ends abnormally or is stopped by a user from the command line.

The monitoring function is controlled by SA z/OS based on the definitions of the customization dialog. Monitoring is automatically started when the job reaches a status of UP, ACTIVE, or RUNNING. If your job was already active at the time you specified the Job Log Monitoring definitions in the customization dialogs, then this job must be restarted in order to start Job Log Monitoring for it. However, you can monitor jobs that are not controlled by SA z/OS with the following restrictions:

  1. You cannot specify any filter criteria to limit the data that is passed to automation. This means any line of data except an empty line that is generally excluded is forwarded to the message automation.
  2. The message that is forwarded to message automation is always queued to the autotask LOGOPER. For SA z/OS controlled jobs those messages are queued to the autotask that is responsible for the job in view of SA z/OS.
  3. You need to start the monitoring manually by using the command INGJLM START. Required parameters are the job name and the monitoring interval. In case you want to monitor a data set other than the default data set JESMSGLG you also need to specify the appropriate ddname. The specifications of the owner or the job ID are necessary only when multiple jobs with the same job name exist. This could be the case when the job already ended and the output is held on the output queue. In this case, it is your responsibility that the job is monitored only once.
  4. You need to qualify the ddname by the step name if you do not want to monitor a spool file of the last step in a multi-step job when the ddname is specified multiple times. In case the step name is not unique in an in-stream procedure you need to qualify the ddname by the procedure step name as well.

You can stop the monitoring function for a particular job at any time using the command INGJLM STOP even for SA z/OS controlled jobs. Normally, the monitoring is automatically stopped when the job has ended. For SA z/OS controlled jobs this is done when the job reaches a termination status like AUTOTERM, ENDING, and so on. For non-SA z/OS controlled jobs the monitoring is automatically stopped when the job has ended and the monitoring interval has expired twice.

The monitoring task can be suspended for an indefinite time frame using the command INGJLM SUSPEND. The accumulated output of all monitored jobs is processed not before the task has been restarted. The output of jobs that have finished in the meantime is lost unless the output is still held on the JES output queue. Jobs that have been started after the task was suspended will not be monitored after the task has been restarted. To restart the task, use the NetView command START TASK=INGTJLM.

The monitoring task can be instructed to continue its monitoring after NetView has been recycled. To do so, issue the command INGJLM RECYCLE RESUME at any time when the task is active. Note that you need to do this only once for all future NetView recycles until the next IPL. The behavior is similar to when you would suspend and restart the task except that the task is not suspended and a NetView recycle takes place between task termination and restart. You can reset the condition by issuing the command INGJLM RECYCLE RESET. This will clear the internal structures after NetView has been restarted and is the default. The internal structure is held in a data space that is anchored to the master address space. Its initial size depends on the number of jobs that have been defined in the PDB for monitoring. It will be at least 16K. Each time the current allocation needs more space for monitoring the data space is extended by 1 block up to the installation limit. However, the space required for monitoring a ddname is reused after the job of the monitored ddname has terminated.

The name of the data space is given by the constant INGJLM suffixed by the value of the GRPID parameter as defined in the DSIPARM member INGXINIT. Changing this value results in the creation of a new data space when System Automation initializes the next time.

You may use the advanced automation option to set the behavior automatically. Every time when System Automation (re-)initializes it checks the status of the Job Log Monitoring task. When the task is active or needs to be started, it also evaluates the common global AOF_AAO_JLM_RECYCLE and issues the command INGJLM RECYCLE according to the value of the global (Refer to Read/Write Variables for details.

In case of an abend condition the monitoring task performs an internal suspend command with the following exception. The job that caused the error condition is marked "in error" and will be excluded from monitoring when the task is restarted.

Note: The monitoring task must be terminated before JES is shut down. For this reason the default policy has been updated and the following STOP command has been added to the SHUTINIT phase of JES:
     | NETV


  1. Executing SA z/OS controlled jobs that are running less than two seconds are probably not monitored. One reason is that the automation does not find the job active any longer. Or, JES has deallocated the resource before the monitoring task could allocate it. The latter case is also true for non-SA z/OS controlled jobs when the output is not held on the JES output queue after the job ended. In any case, specify a message class when starting the job that leaves the output on the JES output queue and trigger the monitoring manually.
  2. The monitoring function is limited to the primary subsystems JES2 and JES3.
  3. Dynamically allocated spool output data sets are not supported.
  4. The processing of normal data sets as well as temporary data sets outside a spool output definition are not supported.
    For example:
    //         DCB=(DSORG=PS,RECFM=V,BLKSIZE=123)
    //         DCB=(DSORG=PS,RECFM=V,BLKSIZE=123)
  5. Job Log Monitoring does not support a spool data set where the temporary data set name is blank or starts with a blank.
    For example:
    //         DCB=(DSORG=PS,RECFM=V,BLKSIZE=123)
  6. When the NetView task DSIRQJOB is defined, Job Log Monitoring waits for receiving the JES job ID by DSIRQJOB. Without the job ID, a spool data set cannot be accessed. If DSIRQJOB is not defined, the job ID is obtained by Job Log Monitoring and returned to JES when the monitoring task terminates.

    If DSIRQJOB is terminated in a JES2 environment, the monitoring task is automatically suspended because the job ID is returned to JES2. And the monitoring task is automatically restarted after DSIRQJOB is restarted.

    In a JES3 environment, DSIRQJOB does not return the job ID on termination. For this reason, the monitoring task is not terminated. However, if for whatever reason the job ID is returned to JES3, the monitoring task is automatically suspended but needs to be restarted manually when a new job ID is received.