Kommandozeilenoptionen

Zeigt die Kommandozeilenoptionen.

Lässt den Job Scheduler beim Start Versionsnummer und Versionsdatum ausgeben.

Startzeitpunkt in der Form "yyyy-mm-dd HH:MM[:SS]". Siehe <at at="…">.

Der Job wird nicht gestartet, wenn der Startzeitpunkt in der Vergangenheit liegt.

Maßgeblich ist die Uhr des Rechners, auf dem der Job Scheduler läuft.

-at=now ist voreingestellt und lässt den Job sofort starten.

Nur mit -exclusive möglich.

Ein Backup Job Scheduler übernimmt den Betrieb nur, beginnt aber keinen neuen Betrieb. D.h. nach <terminate continue_exclusive_operation="no"> läuft er nicht an, sondern wartet auf einen anderen Job Scheduler, der den Betrieb startet.

Zusammem mit -install-service und -remove-service führt -backup zu einem eigenen Dienstenamen, so dass der Backup Job Scheduler als eigener Dienst auf demselben Rechner installiert werden kann.

Der Dateiname des Hauptprotokolls erhält den Zusatz "_backup".

Nur mit -exclusive möglich.

Wenn mehrere inaktive Backup Job Scheduler einen ausgefallenen Job Scheduler ersetzen können, übernimmt der mit dem kleinsten Wert von -backup-precedence.

Wenn die Uhren nicht gleichlaufen, kann ein anderer Job Scheduler als der mit dem vorderen Rang den Betrieb übernehmen.

Mit der Option -backup ist die Voreinstellung 1, sonst 0.

Ändert das Arbeitsverzeichnis.

Der Job Scheduler führt beim Start das XML-Kommando aus. Das kann z.B. ein <start_job> sein.

Gibt die Konfigurationsdatei an.

"-config=" vor dem Dateinamen kann weggelassen werden.

Die Option gibt die Konfigurationsdatei oder das Konfigurationsverzeichnis an. Im letzteren Fall erwartet der Scheduler die Konfigurationsdatei im Konfigurationsverzeichnis unter dem Namen scheduler.xml.

Voreingestellt ist das Verzeichnis live im Verzeichnis der Konfigurationsdatei (-config).

Diesem Verzeichnis entnimmt der Job Scheduler Jobs, Job-Ketten, Daueraufträge, Prozessklassen und Sperren.

Voraussetzung ist Datenbankbetrieb (). Mehrere Job Scheduler mit derselben Scheduler-Id (-id), derselben Datenbank und derselben Konfiguration können gestartet werden, die sich die Ausführung der Aufträge teilen.

Mit <job_chain distributed="yes"> lassen sie eine Job-Kette für den verteilten Betrieb zu.

Meldungen

-env=NAME=VALUE setzt die Umgebungsvariable NAME.

Meldungen

Die Option kann mehrfach angegeben werden.

Voraussetzung ist Datenbankbetrieb, siehe factory.ini (Abschnitt [spooler], Eintrag db=…).

Mehrere Job Scheduler mit derselben Scheduler-Id (-id) und derselben Datenbank können mit -exclusive gestartet werden, wobei nur einer aktiv wird. Erst wenn der aktive Job Scheduler ausfällt oder einzeln beendet wird (<terminate continue_exclusive_operation="yes">), wird ein anderer Job Scheduler aktiv. Die Übernahme kann einige Minuten dauern.

Vorsicht: Alle beteiligten Job Scheduler müssen mit -exclusive oder -distributed-orders gestartet werden. Wenn ein Job Scheduler mit und einer ohne die Einstellung gestartet wird, laufen zwei Job Scheduler gleichzeitig, was zu unerwarteten Ergebnissen führen kann.

Siehe auch -backup.

Meldungen

Expandiert den als Parameter angegebenen Java-Classpath, d.h. die Joker werden verarbeitet wie sos.ini (Abschnitt [java], Eintrag class_path=…).

Das Ergebnis schreibt der Job Scheduler nach stdout. Wenn keine weiteren Optionen es verlangen, beendet sich der Job Scheduler ohne weitere Ausgaben.

Beispiel  

export CLASSPATH="`scheduler -expand-classpath='/opt/java/lib/*.jar'`"

Zeigt die Kommandozeilenoptionen.

Der Job Scheduler wählt nur die Elemente der XML-Konfiguration aus, deren Attribut spooler_id leer ist oder denselben Wert wie in dieser Einstellung enthält.

Wenn die Scheduler-ID nicht angegeben ist, beachtet der Job Scheduler das XML-Attribut spooler_id= nicht und wählt alle Elemente der XML-Konfiguration aus.

Siehe z.B. <config>.

Verzeichnis der Dateien, die mit <include> eingezogen werden.

Umgebungsvariablen (z.B. $HOME) werden ersetzt (siehe hier).

Wählt eine andere Datei für die Datei factory.ini aus.

In dieser Dokumentation ist dann mit der Datei factory.ini die hier eingestellte gemeint.

Siehe auch Spooler.ini_path

Die Option startet nicht den Job Scheduler, sondern installiert ihn als Windows-Dienst. Dabei werden folgende Optionen aus der Kommandozeile übernommen:

-cd
-config
-id
-ini
-log
-pid-file
-sos.ini
-env

-install-service=name ist dasselbe wie -install-service -service-name=name.

Die IP-Adresse, an die TCP- und UDP-Port gebunden werden. Der Job Scheduler ist dann nur über diese IP-Adresse erreichbar.

Ein Hostname kann angegeben werden.

Default ist 0.0.0.0, was für alle IP-Adressen steht.

Wenn eine andere IP-Adresse als 127.0.0.1 oder localhost angegeben ist, kann der Job Scheduler nicht über localhost erreicht werden.

Name der Job-Kette für den Auftrag, siehe <add_order job_chain="…">.

Bricht den Job Scheduler mit kill -SIGKILL ab, dessen Prozess-Id in der mit -pid-file angegebenen Datei steht.

Bricht den Prozess mit der PID mit kill -SIGKILL ab.

Skriptsprache, siehe <script language="…">.

Wenn diese Einstellung gesetzt ist, schreibt der Job Scheduler ein detailliertes Protokoll zur Fehlerdiagnose in die Datei. Geben Sie den Dateinamen absolut an (als vollständigen Pfad).

Ein Plus (+) direkt vor dem Dateinamen lässt ein vorhandenenes Protokoll fortsetzen. Sonst wird es überschrieben.

Kategorien

Sie können das Protokoll mit Kategorien erweitern oder einschränken. Schreiben Sie die Namen der Kategorien mit Zwischenräumen getrennt vor den Dateinamen, den Sie mit einem Größerzeichen (>) einleiten.

Hier ist die Liste der Kategorien.

Beispiel  

log = c:/tmp/scheduler.log
log = scheduler.wait >scheduler.log
log = scheduler.wait com_server.* >scheduler.log

In dieses Verzeichnis schreibt der Job Scheduler seine Protokolle.

log_dir=*stderr lässt den Job Scheduler die Protokollausgabe nach stderr (auf den Bildschirm) schreiben.

Umgebungsvariablen (z.B. $HOME) werden ersetzt (siehe hier).

Legt fest, ab welcher Stufe der Job Scheduler Protokollzeilen ausgibt. Jede Protokollzeile ist auf einer der folgenden Stufen: error, warn, info, debug1 bis debug9 (debug1 ist dasselbe wie debug).

In Verbindung mit -install-service können Sie hier einen anderen Dienst angegeben, der laufen soll, bevor Windows den Job Scheduler Dienst startet. Das kann z.B. ein Datenbank-Server sein.

Diese Option kann wiederholt angegeben werden, wenn der Job Scheduler mehrere Dienste voraussetzt.

Kennung des Auftrags, siehe <add_order id="…">.

Zur freien Verwendung. Der Parameter ist in den Skripten über spooler.param lesbar.

Für Unix: In diese Datei schreibt der Job Scheduler seine PID. Beim Beenden löscht der Job Scheduler die Datei.

Fasst die Einstellungen tcp_port und udp_port zusammen.

Siehe auch -tcp-port und -udp-port.

Wenn der Port blockiert ist, versucht der Job Scheduler zwei Minuten lang, ihn zu belegen, bevor er aufgibt.

Name der Prozessklasse für den temporären Job, siehe <job process_class="…">.

Beim Aufruf des Job Schedulers aus einer Java-Klasse heraus (zum Debuggen) geben Sie hier den Programmdateinamen an, wenn der Job Scheduler Jobs in eigenen Prozessen starten können soll.

Entfernt einen zuvor mit -install-service installierten Dienst.

-remove-service=name ist dasselbe wie -remove-service -service-name=name.

Die Option soll nur in Ausnahmefällen benutzt werden, sie schaltet die Prüfung ab, ob ein Port vom Betriebssystem freigegeben ist.

Ruft setsockopt(socket,SOL_SOCKET,SO_REUSEADDR,true).

Die Option sollte nur im Notfall benutzt werden, falls das Betriebssystem den Port dauerhaft sperrt, obwohl keine Anwendung ihn mehr belegt. Das kann unter Windows XP passieren, wenn die Anwendung mit einem Debugger abgebrochen wird. Unix kann ggf. fast eine Minute benötigen, um einen Port freizugeben.

U.U. ist der Job Scheduler mit -reuse-port über TCP oder UDP nicht erreichbar, wenn statt dessen der Port einer anderen Anwendung angesprochen wird.

Rechnername (oder IP-Nummer) und Portnummer des anzusprechenden Job Schedulers.

Mit dieser Option startet der Job Scheduler nicht, sondern schickt einem anderen Job Scheduler mit gleicher Option -tcp-port= auf demselben Rechner das XML-Kommando. Das kann z.B. ein <terminate> sein: -send-cmd="<terminate/>"

Das Kommando wird an die mit <config ip_address="…"> eingestellte IP-Adresse geschickt, oder, wenn diese fehlt, an 127.0.0.1.

Unter Unix versetzt sich der Job Scheduler in den Hintergrund und trennt sich vom Terminal. stdout und stderr sollten in eine Datei umgeleitet werden, damit Ausgaben nicht verloren gehen.

Nur in Verbindung mit -install-service.

Nur in Verbindung mit -install-service. Die Dienstesteuerung von Windows zeigt diesen Namen. Er darf Leerzeichen enthalten. Wenn die Option fehlt, erzeugt der Scheduler einen aus dem Dienstnamen (s. -service-name=).

Nur in Verbindung mit -install-service oder -remove-service. Wenn diese Option fehlt und -id= angegeben ist, verwendet der Job Scheduler den Namen sos_scheduler_scheduler_id. Bei -backup fügt er _backup hinzu.

Der Job Scheduler verfügt über ein eingebautes XML-Schema, dem die XML-Kommandos und die XML-Konfiguration entsprechen müssen.

Siehe XML-Schema des Job Schedulers.

Wählt eine andere Datei für globale Konfigurationen sos.ini aus. Diese Datei enthält u.a. den Lizenzschlüssel.

Der Job Scheduler kann auf einem TCP-Port während des Betriebs Kommandos entgegennehmen. Hier kann eine Portnummer eingestellt werden. Die Portnummer ist eine Zahl zwischen 2048 (betriebssystemabhängig) und 65535. Die Voreinstellung lautet 4444.

Über denselben Port betreibt der Job Scheduler einen HTTP/HTML-Server, so dass er über einen Browser ansprechbar ist, z.B. http://localhost:4444.

Bei tcp_port=0 (voreingestellt) ist der Job Scheduler nicht über TCP oder HTTP ansprechbar. Damit kann die Steuerung des Job Schedulers per TCP-Kommando, z.B. über eine Web-Seite, unterbunden werden.

Siehe auch -port.

Dem Auftrag kann ein Titel gegeben werden. Siehe <add_order title="…">.

Auch über UDP kann der Job Scheduler Kommandos entgegennehmen. Hier wird die Portnummer angegeben. Ein Kommando muss in eine Nachricht passen. Der Job Scheduler schickt keine Antwort.

Bei udp_port=0 (voreingestellt) öffnet der Job Scheduler keinen UDP-Port.

Siehe auch -port.

-validate-xml- schaltet die Validierung ab (für den Fall, dass das Schema fehlerhaft ist).

Siehe -show-xml-schema.