Benötigte Ressourcen

Der Bereich Benötigte Ressourcen ist nur für Ablaufobjekte vom Typ JOB sichtbar und erlaubt die Definition von Ressourcen-Anforderungen. Diese ergänzen die implizit über das Environment und einen optionalen Footprint (Lastprofil) definierten Anforderungen.

Die Tabelle in diesem Bereich zeigt die für die Ausführung dieses Objektes notwendigen Ressourcen an. Es werden auch alle bereits durch das Environment oder einen angegebenen Footprint definierten Ressourcen mit angezeigt. Diese können hier nicht direkt verändert werden, sondern nur durch Änderung des entsprechenden Environments bzw. Footprints.

Die Spalten der Tabelle haben folgende Bedeutung:

Wählen

Um einzelne Ressourcen Anforderungen zu Kopieren, Ausschneiden oder zu Löschen, aktivieren Sie die Checkbox der jeweiligen Zeile und wählen dann die entsprechende Operation unterhalb der Liste aus.

Name

In dieser Spalte finden Sie den Namen der Named Resource, die für den Start des aktuellen Jobs benötigt wird. Wenn Sie den Mauszeiger über den Namen bewegen, wird der Pfad der Ressource angezeigt. Das vorangestellte Symbol gibt an, von welchem Typ (STATIC, SYSTEM oder SYNCHRONIZING) die Named Resource ist. Durch einen Klick auf das vorangestellte Symbol Wählen wird ein Popup geöffnet, welches die Auswahl einer anderen Named Resource ermöglicht.

Bedingung

Ressourcen-Anforderungen für STATIC Resources können zusätzlich mit einer Bedingung versehen werden, um festzustellen, ob die Ressource für einen Job zur Verfügung steht. Dies ermöglicht unter Anderem eine dynamische Auswahl des ausführenden Job Servers.

Anzahl

Dieses Feld wird nur angezeigt, falls die Ressource vom Typ ”SYSTEM” oder ”SYNCHRONIZING” ist. Diese Ressourcen stellen eine Definierte Menge von Einheiten zur Verfügung. Um solche Ressourcen allokieren zu können, muss diese Menge größer als die hier geforderte Anzahl sein. Während der Laufzeit des Jobs wird die verfügbare Menge der Ressource um die geforderte Anzahl reduziert.

Die angeforderte Anzahl darf die Anforderbare Menge der Ressource nicht überschreiten. Ist dies der Fall, kann die Ressource nicht allokiert werden, unabhängig von der verfügbaren Menge.

Beispiel

Ein Job Server stellt von der Resource A die Menge 5 zur Verfügung (zum Beispiel 5 CPU Einheiten auf diesem Server). Job A startet nun und benötigt eine Anzahl von 3. Der Job Server hat nun 3 CPU Einheiten belegt und 2 noch verfügbar.

Job B möchte starten, benötigt aber ebenfalls eine Anzahl von 3. Der Job kann nicht an den Job Server zum Starten übergeben werden, da dieser im Moment nur noch 2 CPU Einheiten zur Verfügung hat. Job B kann erst starten, wenn Job A beendet ist und mindestens drei CPU Einheiten zur Verfügung stehen.

Behalten

Mit dem Behalten Parameter wird bestimmt, wie lange die Belegung der Ressource durch den Job nach der Beendigung aufrecht erhalten wird. Es gibt folgende Auswahlmöglichkeiten:

• NO_KEEP
  Die Ressource wird nach Beendigung des Jobs freigegeben. Ob der Job erfolgreich beendet oder wegen eines Fehlers abgebrochen wurde, spielt für die Freigabe keine Rolle.

• KEEP
  Die Ressource wird erst freigegeben, wenn der Job einen finalen Status erreicht hat. Im Fehlerfall (kein finaler Status) wird die Ressource gehalten.

• KEEP_FINAL
  Die Ressource wird erst freigegeben, wenn der Job und alle seine Kinder einen finalen Status erreicht haben.

Sperrmodus

In dieser Spalte wird angegeben, in welchen Sperrmodus die Ressource vom Job belegt werden soll. Es gibt folgende Sperrmodi:

• EXCLUSIVE (X)
  Kein anderer Job (Ausnahme NOLOCK) hat Zugriff auf diese Ressource.
• SHARED EXCLUSIVE (SX)
  Diese Zugriffe sind untereinander verträglich, jedoch unverträglich mit SHARED- und EXCLUSIVE-Zugriffen.
• SHARED (S)
  Diese Zugriffe sind untereinander verträglich, jedoch unverträglich mit SHARED EXCLUSIVE- und EXCLUSIVE-Zugriffen.
• SHARED COMPATIBLE (SC)
  Diese Zugriffe sind sowohl untereinander als auch mit SHARED- und SHARED EXCLUSIVE-Zugriffen verträglich, jedoch nicht mit EXCLUSIVE-Zugriffen.
• NOLOCK (N)
  Der Sperrmodus NOLOCK gibt an, dass weder eine Sperrung der Ressource durchgeführt wird, noch beachtet werden soll. Ein Job, der eine Ressource mit NOLOCK sperrt, kann immer auf diese zugreifen.

Kompatibilitätsmatrix der Sperrmodi

• (+) bedeutet, die Sperrmodi sind kompatibel zueinander. Zwei Jobs, welche die beiden Sperrmodi anfordern, können zur selben Zeit laufen.
• (-) bedeutet, die Sperrmodi schließen sich aus. Ein Job wird blockiert, bis der an- dere Job die Ressource wieder freigibt.

	EXCLUSIVE (X)	SHARED (S)	SHARED EXCLUSIVE (SX)	SHARED COMPATIBLE (SC)	NOLOCK (N)
EXCLUSIVE	-	-	-	-	+
SHARED	-	+	-	+	+
SHARED EXCLUSIVE	-	-	+	+	+
SHARED COMPATIBLE	-	+	+	+	+
NOLOCK	+	+	+	+	+

Beispiel

Falls das Aktualisieren einer Datenbanktabelle nicht in einer einzigen Datenbank-Transaktion durchgeführt werden kann, wären für lesende Zugriffe anderer Prozesse, deren Ergebnisse nicht konsistent. Allokiert der aktualisierende Job die Ressource EXCLUSIVE und die Jobs, welche lesend auf diese Ressource zugreifen, im Sperrmodus SHARED, ist sichergestellt, dass zwar mehrere lesende Prozesse gleichzeitig aktiv sein können, aber nicht ausgeführt werden können, wenn der aktualisierende Job aktiv ist. Der aktualisierende Job kann nicht starten, solange noch lesende Zugriffe aktiv sind.

Status Abbildung

BICsuite und schedulix erlauben das automatisierte Setzen eines Ressourcen Status in Abhängigkeit des Exit Status eines Jobs. Dazu muss der Sperrmodus auf EXCLUSIVE gesetzt sein. Andernfalls ist dieses Feld nicht sichtbar. Hierfür kann ein optionales Resource State Mapping in diesem Feld ausgewählt werden.

Sticky

BICsuite und schedulix erlauben mittels dieser Option, kritische Bereiche zu definieren, die sich über mehrere Jobs erstrecken. Ist diese Checkbox gesetzt, so bleibt die Ressource für den Master Ablauf reserviert, bis der letzte Job in diesem Ablauf beendet wurde, der diese Ressource mit gesetzter Sticky Option benötigt. Für die Jobs des aktuellen Ablaufes hat diese Einstellung keine Auswirkung. Für Jobs anderer Master Abläufe gilt die Ressource nach wie vor als belegt.

Ein weiterer Effekt des Sticky Flags ist es, dass alle Jobs, welche die Ressource mit der Sticky-Option anfordern, sich zur Laufzeit auf ein und dieselbe Ressourcen-Instanz beziehen müssen. Damit laufen alle diese Jobs im gleichen Scope, bzw. Jobserver.

Beispiel 1

Master Batch M1 besteht aus den Jobs A, B, C und D, die nacheinander ausgeführt werden. Job A generiert eine Tabelle X, welche von Job D benötigt wird. Die Jobs B und C benötigen diese Tabelle X nicht. Andere Master Batches (M2) möchten auch auf die Tabelle zugreifen und diese verändern. Solange Job D aber noch nicht gelaufen ist, soll dies verhindert werden, da diese Aktionen das Ergebnis des Jobs A verfälschen und unbrauchbar machen würden. Die Tabelle X wird nun als Ressource vom Typ SYNCHRONIZING abgebildet und sowohl von Job A, als auch von Job D mit gesetzter Sticky-Option angefordert. Dies führt nun dazu, dass der Job J2 nach dem Start von Job A erst nach Abschluss von Job D starten kann.

Mit gesetztem Sticky Flag wird die Ressource nach der Beendigung des Jobs A nicht zurückgegeben, sondern im Master Batch als belegt gehalten. Andere Jobs können diese nun nicht allokieren. Erst nach der Beendigung des Jobs D wird die Resource freigegeben und andere Jobs können diese verwenden.

Beispiel 2

Es gibt in einer Systemumgebung 2 Unix-Rechner mit identischer Konfiguration und Umgebung, die zur Lastverteilung eingesetzt werden. Nun kann ein Master Batch entweder auf der einen oder auf der anderen Maschine laufen. Da aber Zwischenergebnisse als Files zwischen den einzelnen Jobs des Master Batch übertragen werden sollen, muss der gesamte Master Batch, nachdem die Maschine ausgewählt wurde, zwingend auf dieser laufen.

Um dies zu erreichen, wird eine Named Ressource (RessourceUnix) vom Typ SYNCHRONIZING angelegt und auf den beiden Job Servern instanziiert. Nun müssen alle Kinder des Master Batches, welche auf ein und demselben Job Server laufen sollen, diese Ressource mit gesetzter Sticky-Option anfordern.

Der erste Job (Job A) des Master Batch belegt nun eine der beiden verfügbaren Ressourcen (auf dem einen oder dem anderen Job Server). Alle nachfolgenden Jobs dieses Master-Batches mit gesetzter Sticky-Option müssen nun auf dem selben Job Server ausgeführt werden, auf dem Job A gelaufen ist. Da diese Sticky belegt wurde, wird sie nach Beendigung des ersten Jobs nicht mehr zurückgegeben. Alle weiteren Jobs des Master Batches sind über diese Sticky Resource auf den gewählten Job Server und damit auf diese Maschine festgelegt.

In der Grafik läuft nun ein Master Batch (Instanz 1) vollständig auf dem Job Server System A und ein zweiter Master Batch (Instanz 2) vollständig auf dem Job Server System B.

Name

Das der Sticky-Option folgende Feld Name erlaubt es, sticky Ressourcen-Anforderungen zu gruppieren. Das Feld wird nur sichtbar, wenn die Checkbox Sticky gesetzt ist. Sticky Anforderungen innerhalb eines Batches mit unterschiedlichen Sticky-Namen werden so behandelt, als kämen sie aus unterschiedlichen Master Abläufen. Damit können sich kritische Bereiche auch innerhalb eines Master Batches synchronisieren.

Elternelement

Ist das oben beschriebene Sticky Flag gesetzt, so wird auch das Feld Elternelement sichtbar. Ist das Elternelement gesetzt, wird die zwischenzeitliche Reservierung nicht an das Master Laufzeitobjekt des aktuellen Master Ablaufs gebunden, sondern an das Laufzeitobjekt, das als Elternelement spezifiziert wurde. Damit ist es möglich, einen Teilablauf so zu definieren, dass er innerhalb eines Masters mehrfach zur Ausführung kommen kann und die kritischen Bereiche dieser Ausführungen voreinander geschützt bleiben. Wird das Elternelement zur Laufzeit nicht gefunden, wird die Reservierung am Master des Ablaufs durchgeführt.

Zeitgrenze

Dieser Wert gibt die maximale Zeit an, die seit dem letzten Statuswechsel der Ressource vergangen sein darf, um die Ressource als belegbar zu betrachten. Ein negativer Wert hat zur Folge, dass eine Ressource mindestens so ”alt” wie angegeben sein muss. Damit lassen sich Aktualitäts- und Warte-Bedingungen definiert werden.

Einheit

Wird nur angezeigt, wenn im Feld Zeitgrenze ein Wert eingetragen wurde und enthält die Auswahlfelder, welche Zeiteinheit (MINUTE, HOUR, DAY, WEEK, MONTH, YEAR) das System mit dem Wert verknüpfen soll.

Gültige Status

Dieses Feld ist nur aktiv, wenn die Ressource vom Typ SYNCHRONIZING ist und ein Resource State Profile zugeordnet wurde. Hier können ein oder mehrere Ressourcen Status eingetragen werden, welche für eine Anforderung als gültig betrachtet werden sollen. Der Job kann nur starten, wenn die benötigte Ressource in einem dieser Status ist.

Bei Wiederholung ignorieren

Wird dieses Flag gesetzt, so wird die Ressource nicht mehr angefordert, wenn ein Job wiederholt ausgeführt wird. In diesem Fall stand die Ressource dem Job ja schon einmal für seinen ersten Start zur Verfügung. Die Ressource gilt damit für wiederholte Ausführungen als allokiert. So kann zum Beispiel die Zeitgrenze zum Zeitpunkt der Wiederholung des Jobs bereits wieder abgelaufen sein, der Job soll aber trotzdem wiederholt werden können.