Parallel Job Manager (PJM)

Parallel Job Manager (PJM) ist eine Funktion und ein Framework für die Übergabe und Verwaltung transaktionsorientierter Stapeljobs, die als koordinierte Sammlung unabhängiger paralleler untergeordneter Jobs ausgeführt werden.

PJM-Grundlagen

  • Parallel Job Manager befindet sich im Stapelcontainer und nicht in einer separaten Systemanwendung.
  • Es ist nur eine einzige xJCL-Datei erforderlich. Die xJCL kombiniert den Inhalt der übergeordneten Job-xJCL mit dem Inhalt der untergeordneten Job-xJCLs.
  • Sie müssen keine separate Datenbank erstellen.
  • Da PJM zum Stapelcontainer gehört, müssen Sie PJM nicht installieren und konfigurieren.
  • Sie packen die PJM-APIs in der Stapelanwendung als Dienstprogramm-JAR (Java-Archiv). Es ist keine gemeinsam genutzte Bibliothek erforderlich.
  • Der Inhalt der Datei xd.spi.properties ist Teil der xJCL. Es ist keine Datei xd.spi.properties erforderlich.

PJM-Betrieb und Aufruf der APIs

Die folgenden beiden Abbildungen veranschaulichen die PJM-Architektur und den Ablauf eines parallelen Jobs. Zuerst wird die xJCL an den Job-Scheduler übergeben. Der Job-Scheduler teilt die xJCL einem Endpunkt zu, der die Anwendung ausführt, auf die die xJCL verweist. Der Stapelcontainer stellt durch Überprüfung der Ausführungseigenschaft des Jobs in der xJCL fest, dass der Job parallel auszuführende untergeordnete Jobs haben soll. Der Stapelcontainer delegiert die Ausführung an die Unterkomponente PJM. PJM ruft die API "Parameterizer" auf und verwendet die Informationen in der xJCL, um den Job in untergeordnete Jobs zu unterteilen. Anschließend ruft PJM die Synchronisations-API "LogicalTX" auf, um den Anfang der logischen Transaktion anzuzeigen. PJM generiert die xJCLs der untergeordneten Jobs und übergibt die untergeordneten Jobs an den Job-Scheduler. Der Job-Scheduler teilt die untergeordneten Jobs zur Ausführung den Endpunkten des Stapelcontainers zu. Der Stapelcontainer führt den untergeordneten Job aus. Bei einem Prüfpunkt wird die Collector-API des untergeordneten Jobs aufgerufen. Diese API erfasst relevante Statusinformationen über den untergeordneten Job. Diese Daten werden zur Interpretation an die Analyzer-API des untergeordneten Jobs gesendet. Nachdem alle untergeordneten Jobs einen Endstatus erreicht haben werden die Synchronisations-APIs "beforeCompletion" und "afterCompletion" aufgerufen. Außerdem wird die Analyzer-API aufgerufen, um den Rückkehrcode des Jobs zu berechnen.

Eine logische Transaktion ist eine UOW-Demarkation (Unit of Work, Arbeitseinheit), die die Ausführung eines parallelen Jobs umspannt. Ihr Lebenszyklus entspricht den kombinierten Lebenszyklen der untergeordneten Jobs des parallelen Jobs. Mithilfe eines Erweiterungsmechanismus können Sie anwendungsverwaltete Ressourcen so anpassen, dass sie in diesem UOW-Bereich für Commit- und Rollback-Zwecke gesteuert werden können.

PJM-Architektur und -Programmiermodell

In der folgenden Abbildung sehen Sie eine Zusammenfassung der PJM-Architektur, anhand derer erkennbar ist, wo die APIs aufgerufen werden:

PJM-Architektur

Ablauf eines parallelen Jobs

In der folgenden Abbildung sehen Sie die Reihenfolge der Ereignisse in einem parallelen Job:

Ablauf eines parallelen Jobs

PJM-Jobverwaltung

Der übergeordnete Job übergibt die untergeordneten Jobs und überwacht deren Ausführung. Der Endstatus des übergeordneten Jobs wird wie folgt durch das Ergebnis der untergeordneten Jobs beeinflusst:
  1. Nachdem alle untergeordneten Jobs den Endestatus erreicht haben (d. h. nach einem erfolgreichen Abschluss), wird der übergeordnete Job in den Endestatus versetzt.
  2. Wenn ein untergeordneter Job mit einem wieder anlauffähigen Status beendet wird und kein untergeordneter Job einen Fehlerendestatus hat, wird der übergeordnete Job in den wieder anlauffähigen Status versetzt.
  3. Wenn ein untergeordneter Job mit einem Fehlerstatus beendet wird, wird der übergeordnete Job in den Fehlerstatus versetzt.
  4. Wenn der übergeordnete Job und die untergeordneten Jobs den wieder anlauffähigen Status haben, wird nur der übergeordnete Job erneut gestartet. Wenn untergeordnete Jobs manuell neu gestartet werden, verarbeitet der übergeordnete Job die logische Transaktion nicht ordnungsgemäß.

Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cgrid_cgparallel
Dateiname:cgrid_cgparallel.html