Test ob ein Programm auf dem System läuft

[Etherion]

Hallo zusammen,

ich möchte innerhalb eines Programms A feststellen, ob ein anderes Programm B auf der Maschine noch läuft. Des weiteren weiß ich, dass wenn B läuft es im Subsystem QBATCH läuft.

Gibt es einen CL Command oder zumindest eine API, die diese Information ermitteln kann? Wenn ja, wie?

Gruß

Etherion

[BenderD]

... freilich gibt es da APIs, die es ermöglichen, festzustellen ob ein bestimmter Job aktiv ist und/oder ein bestimmtes Programm da im Callstack ist, wenn es aber um wechselseitigen Ausschluss geht, den kann man damit nicht sicherstellen. Da macht man sich besser einen auf Sperren basierenden Mechanismus.

D*B

Hallo zusammen,

ich möchte innerhalb eines Programms A feststellen, ob ein anderes Programm B auf der Maschine noch läuft. Des weiteren weiß ich, dass wenn B läuft es im Subsystem QBATCH läuft.

Gibt es einen CL Command oder zumindest eine API, die diese Information ermitteln kann? Wenn ja, wie?

Gruß

Etherion

[Etherion]

Hi Bender,

das mit dem Sperrmachnismus habe ich implementiert. Aber da gibt es noch eine Lücke. Ich möchte deswegen zusätzlich noch das laufende Programm abprüfen. Hast Du da Beispielcode?

Gruß

Etherion

[cbe]

Hallo Etherion,

meinst Du sowas?
http://newsolutions.de/forum-systemi...ie-chkjob.html

Gruß, Christian

[BenderD]

... wo ist denn die Lücke?, vielleicht habe ich ja noch eine bessere Idee, als einen Wackelhaufen mit wühlen in Joblisten und Programm Stacks zu bauen!

D*B

Hi Bender,

das mit dem Sperrmachnismus habe ich implementiert. Aber da gibt es noch eine Lücke. Ich möchte deswegen zusätzlich noch das laufende Programm abprüfen. Hast Du da Beispielcode?

Gruß

Etherion

[Fuerchau]

Wenn eine explizite Sperre z.B. auf einen bestimmten Datensatz oder eine DTAARA gesetzt und gehalten wird, gibts keine Lücke.
Das Wühlen über Job's und Callstacks ist
a) sehr langsam
b) nicht sicher
Zu b)
Das Programm kann gerade nicht aktiv im Callstack aber in der Aktivierungsgruppe sein (*INLR = *OFF beim Return).
Dann findest du es nicht per Callstack, eine explizite Sperre bleibt aber bestehen (am Besten auf externe Objekte und nicht auf Datensätze).

[BenderD]

Baldur,
Du sprichst mir (wie so oft) aus der Seele, bis auf (wie so manchmal): Satzsperren sind schon optimal, wenn man das Ganze mit Commitment Controll implementiert. Ich mache bei sowas eine Procedure getMutex(Name), die legt pro Name automatisch einen Satz in einer journalisierten Datei (eigenes Journal vermeidet Randprobleme) an und liest diesen mit Commit Level repeatable read und bei Ende (und exit registriert über CEE4RAGE) sagt man commit, das wars - und damit kann man auch Gruppen sperren (alphabetisch, versteht sich, damit es keine Deadlocks gibt).
Für Batch Jobs macht man sowas per 2 Procedures (ala Unix) mit einer getProcess (returns JobId) und einer Join (JobId), die auf die Beendigung eines Tochterprozesses wartet (aufmerksame Leser haben dazu einen meiner Artikel gelesen, in einer hier nicht benennbaren Zeitschrift - vielleicht habe ich bei Common auch mal einen Vortrag hierzu gehalten...).

D*B

Wenn eine explizite Sperre z.B. auf einen bestimmten Datensatz oder eine DTAARA gesetzt und gehalten wird, gibts keine Lücke.
Das Wühlen über Job's und Callstacks ist
a) sehr langsam
b) nicht sicher
Zu b)
Das Programm kann gerade nicht aktiv im Callstack aber in der Aktivierungsgruppe sein (*INLR = *OFF beim Return).
Dann findest du es nicht per Callstack, eine explizite Sperre bleibt aber bestehen (am Besten auf externe Objekte und nicht auf Datensätze).