Jobvariablen, die als überwachende Jobvariable verwendet werden, können ebenso gegen Zugriffe geschützt werden wie andere Jobvariablen. Insbesondere kann der Benutzer Kennwörter für den erweiterten Lese- und/oder Schreibschutz vergeben.
Das System umgeht diese Schutzmechanismen nicht, wenn es versucht, den überwachenden Jobvariablen Werte zuzuweisen. Daraus folgt, dass ein Benutzer selbst dafür Sorge zu tragen hat, dass seine Jobvariablen zugreifbar sind. Kennwörter müssen dem System beim ersten Zugriff bekannt sein (z.B. Kommando ADD-PASSWORD).
Kann die überwachende Jobvariable nicht zugeordnet werden, wird der Auftrag bzw. das Programm nicht gestartet.
Die Überwachung eines Auftrags oder Programms erfordert Schreibzugriffe auf die überwachende Jobvariable, um die entsprechenden Werte zu setzen. Wenn beim ersten Zugriff auf eine überwachende Jobvariable das Zugriffsrecht gegeben ist, dann bleibt dem System dieses Zugriffsrecht solange erhalten, wie die Jobvariable zur Überwachung benutzt wird.
Diese Vererbung der Zugriffsberechtigung beschränkt sich auf den Kennwortschutz (READ-PASSWORD/WRITE-PASSWORD).
Die Änderung der Schutzmerkmale (z.B. Mehrbenutzbarkeit oder BASIC-ACL) bei auftragsüberwachenden Jobvariablen ist nur möglich bei Aufhebung des MONJV-Schutzes.
Das System schützt die ersten 128 Bytes (Systembereich) einer auftragsüberwachenden Jobvariablen vor Schreibzugriffen. Bestimmte Felder des Systemteils (siehe Tabelle 14) können jedoch über das Kommando MODIFY-MONJV bzw. den Makroaufruf TIMJV geändert werden.
Der Systembereich einer programmüberwachenden Jobvariablen ist zwar nicht geschützt, sollte aber trotzdem nicht genutzt werden, da dabei die vom System hinterlegten Informationen überschrieben werden bzw. das System bei jeder Zustandsänderung diese 128 Bytes selbst neu überschreibt.
Zusätzlich ist der JV-Eintrag einer auftragsüberwachenden Jobvariablen selbst gegen Änderung geschützt. Dieser Schutz beginnt mit ENTER-JOB, LOGON bzw. SET-LOGON-PARAMETERS und wird wieder aufgehoben:
bei Beendigung des überwachten Auftrags
wenn TSOS die Überwachung eines Auftrags mit dem Kommando MODIFY-JOB-OPTIONS vorzeitig beendet
bei expliziter Freigabe durch den Benutzer:
/MOD-JV-ATTR JV-NAME=jvname,PROTECTION=*PAR(MONJV-PROTECTION=*NO)
Während der Schutzdauer kann die Jobvariable keinem anderen Auftrag oder Programm als überwachende Jobvariable zugewiesen werden.
Bei der Systemeinleitung sind in folgenden Fällen Zugriffe auf überwachende Jobvariablen notwendig:
Ein überwachter Auftrag wird aus der Auftragswarteschlange entfernt. Die überwachende Jobvariable wird auf $A gesetzt, der Schreibschutz wird aufgehoben.
Ein Auftrag wurde mit RERUN-AFTER-CRASH=*YES oder FLUSH-AFTER-SHUTDOWN=*NO gestartet und befindet sich noch in der Auftragswarteschlange. Die überwachende Jobvariable bleibt geschützt und wird ggf. auf $S gestellt.
Zur Absicherung korrekter Werte in überwachenden Jobvariablen ist demnach notwendig, dass sie während der Systemeinleitung zugreifbar sind. Da mehrere Pubsets gleichzeitig betrieben werden können (siehe Handbuch „Einführung in die Systembetreuung“ [3]), ist Folgendes zu beachten:
Eine überwachende Jobvariable sollte auf dem Home-Pubset des Rechners liegen, auf dem der Auftrag ausgeführt wird. Andere Pubsets sind zum Zeitpunkt der Systemeinleitung nicht zugreifbar.
Im Fall fehlerhafter Beendigung einer BS2000-Session zeigen überwachende Jobvariablen unverändert den Zustand des überwachten Auftrags oder Programms entsprechend der letzten ausgeführten Eintragung an.
Besonderheiten bei Repeatjobs
Die MONJV enthält die TSN und den Auftragszustand des ersten Auftrags. Die TSN und der Auftragszustand einer nachfolgenden Wiederholung wird erst zum Startzeitpunkt des Folgeauftrages, d.h. zum LOGON-Zeitpunkt, aktualisiert. Eine Abfrage nach dem Zustand „$S“ ist für Folgeaufträge nicht möglich.
Dies ist auch bei Verwendung der MONJV zur Identifizierung von Aufträgen zu beachten (z.B. CANCEL-JOB). Dabei ist zu überlegen, ob der gerade laufende bzw. bereits beendete Auftrag oder der bereits in Type 1 befindliche Folgeauftrag angesprochen werden soll. Dieser Folgeauftrag kann erst über die MONJV angesprochen werden, wenn er gestartet ist.
Außerdem ist die MONJV von LOGOFF bis zum Start des Folgeauftrages nicht geschützt. Die Gefahr des Zugriffsverlustes bei langen Wartezeiträumen zwischen zwei Wiederholungen ist entsprechend groß.
Besonderheiten bei Kalenderjobs
Die MONJV ist während der gesamten Laufzeit geschützt, also auch für sich in Type 1 befindliche Folgeaufträge.
Die TSN bleibt während der gesamten Laufzeit gleich. Die MONJV enthält ab der Beendigung einer Jobausprägung bis zum Start der Nächsten den Terminierungszustand $T oder $A des Vorgängers. Eine Abfrage nach dem Zustand „$S" ist für Folgeaufträge nicht möglich.