Test ob ein Programm auf dem System läuft

[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).