Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Protecting monitoring job variables

&pagelevel(4)&pagelevel

Job variables which are used as monitoring job variables can also be protected against access like other job variables. In particular, the user can freely allocate passwords for extended read and write protection.
The system cannot bypass these protection mechanisms when values are to be assigned to the monitoring job variables. This means that each user is responsible for ensuring that his or her job variables are accessible. Passwords must therefore be known to the system when the first access operation is performed (e.g. ADD-PASSWORD command).
If the monitoring job variable cannot be assigned, the job or program is not started.

When monitoring a job or a program, write accesses to monitoring job variables are necessary in order to set the appropriate values. If access authorization is granted when a monitoring JV is first accessed, this access right remains assigned to the system for as long as the job variable is used for monitoring.

This inherited access authorization is restricted to password protection
(READ-PASSWORD/WRITE-PASSWORD).
Changing the protection attributes (e.g. shareability or BASIC-ACL) of job monitoring job variables is only possible when MONJV protection is deactivated.

The system protects the first 128 bytes (system area) of a job-monitoring job variable against write access. Certain fields in the system section (see table 14) can still be changed with the command MODIFY-MONJV or the macro call TIMJV.
The JV entry is also protected against modification. This protection begins with ENTER-JOB, LOGON or SET-LOGON-PARAMETERS and is canceled at the end of the monitored job. If this cancellation is not possible, the JV remains locked until the next system initialization or until explicitly released by the user:

/MOD-JV-ATTR JV-NAME=jvname,PROTECTION=*PAR(MONJV-PROTECTION=*NO)

For the duration of this retention period, the JV cannot be assigned as a monitoring JV to any other job or program.
During system initialization, access to monitoring job variables is required in the following instances:

  • A monitored job is removed from the job queue. The monitoring job variable is set to $A, write protection is canceled.

  • A job was started by means of RERUN-AFTER-CRASH=YES or FLUSH-AFTER-SHUTDOWN=YES and is still in the job queue. The monitoring job variable remains protected.

To ensure that the values in monitoring job variables are correct, the variables must be accessible when the system is initialized. Since more than one pubset can be operated simultaneously (for details see the manual “Introductory Guide to Systems Support” [3]), the following should be noted:

A monitoring job variable should reside on the home pubset of the computer on which the job is executed. Other pubsets cannot be accessed at system initialization time.

If a BS2000 session is terminated abnormally, monitoring job variables indicate the status of the monitored job or program at the time the last entry was made.

Notes

  • Note the following when monitoring repeat jobs:

    The MONJV contains the TSN and the job status of the first job. The TSN and the job status of a subsequent repeat are not updated until the point in time at which the repeat job is started, i.e. at LOGON time. It is not possible to interrogate the status “$S” for repeat jobs.
    This should also be noted when using the MONJV for the identification of jobs (e.g. CANCEL-JOB). It is necessary to consider whether the job currently running or already terminated or the repeat job already in type 1 is to be referenced. This repeat job can, however, only be referenced through the MONJV if it has been started.
    In addition, the MONJV is not protected from LOGOFF to the start of the repeat job. The danger of loss of access in the event of long delays between two repeats is correspondingly high.

  • By contrast, the following applies to calendar jobs:

    The MONJV is protected for the entire runtime, i.e. also for follow-up jobs of type 1. The TSN does not change throughout the runtime. From termination of one job to the start of the next, the MONJV contains the termination status $T or $A of the predecessor.