Um zu verhindern, dass bestimmte Anwendungen versehentlich parallel gestartet werden, und um zu erreichen, dass bestimmte Anwendungen erst nach Abarbeitung von anderen gestartet werden, wurde eine Mutex-Verarbeitung implementiert.
Jobschritte können Mutex-Begriffe definieren. Andere Jobschritte können diese Begriffe prüfen.
Nur wenn kein Jobschritt aktiv ist, oder auf Abarbeitung wartet, der einen geprüften Mutex-Begriff definiert, kommt ein Jobschritt zur Ausführung.
Mutex-Begriffe können, durch Komma getrennt, bei der Erzeugung von Jobschritten angegeben werden, oder sie können aus einer zentralen Konfiguration stammen, die von der SOG ERP (VACOS)-Entwicklung gepflegt wird. Der Name dieser Konfiguration lautet "VacosMutex_cfg.xml", und wird über die Variable "FRMCFGPATH" gesucht und aufgelöst.
Normalerweise werden Mutex-Begriffe, die in der Joberstellung angegeben werden zusätzlich zu den in der Konfiguration hinterlegten Begriffen definiert. Dies Verhalten kann durch Voranstellen eines "#"-Zeichens bei Definition der Job-Mutex-Eigenschaften verändert werden. Wird ein "#" als erstes Zeichen der Mutex-Definition verwendet, werden keine Mutex-Definitionen aus der Konfiguration hinzugefügt.
Beginnt der Mutex-Begriff nicht mit einem "-" Zeichen, ist dieser Firmenabhängig. Das heißt: Normalerweise haben alle Mutex-Begriffe einen Firmenbezug!
Durch die Definition von Mutex-Begriffen können Blockierungssituationen geschaffen werden, die dafür sorgen, dass kein Jobschritt zur Ausführung gelangt.
Beispiel:
Job1 definiert einen Jobschritt "p1" der eine Mutex "p1" definiert, und eine Mutex "p2" prüft.
Job2 definiert einen Jobschritt "p2" der eine Mutex "p2" definiert, und eine Mutex "p1" prüft.
Werden beide Jobs gleichzeitig aktiviert, wird keiner der Jobschritte zur Verarbeitung gelangen, da die Mutex-Definitionen eine Verarbeitung gegenseitig ausschließen. Dieses Problem kann nur organisatorisch bewältigt werden.