WRKCMTDFN als API

[BenderD]

... das gibt wieder mal einen Wackelhaufen. Das ist doch nur eine Momentaufnahme und im richtigen Leben lässt sich das aus einem Programm nicht wirklich entscheiden. Das muss man über Jobsynchhronisation (die Sicherung blockt konkurrierende Jobs und wartet bis nix mehr stört), oder über Work Management (ENDSBS) lösen.

D*B

[harkne]

Der Job hängt und blockiert die Sicherung so lange bis sie abbricht. Dann schauen wir über WRKCMTDFN nach welche offenen Commits da sind und beenden diese dann manuell. Dies machen wir nachts um 4 Uhr weil wir da dann angerufen werden, dass die Sicherung noch nicht durch ist. Deshalb brauche ich eine Lösung die mir die offenen Commits mit dem Job der sie verursacht zurück gibt damit ich per CL einen ENDJOB machen kann. Das dies eine Momentaufnahme ist ist gut so, denn es sollen ja nur die beendet werden die im "Moment" den Commit offen haben ;-) Da es das System nur so hinbekommt, dass es die Sicherung beendet und dies nicht akzeptabel ist, muss der Job weg der die Sicherung und unsere Nachtruhe blockiert.

Ich sage ja, es ist nicht meine Baustelle. Ich weiss dass wir alle relevanten Subsystem runter fahren und erst wieder nach der Sicherung wieder hoch fahren. Aber bestimmte Dinge liegen nicht in unserer Hand. Also kann es durchaus sein dass die andere Software ein Subsystem verwendet welches wir nicht runterfahren dürfen. Dort kommt irgendwann der Job rein und hängt sich irgendwie mit offenem Commit auf eine unserer Dateien die wir sichern wollen auf.

[Fuerchau]

Da der blockierende Job doch bekannt ist, sollte doch dieser Job gar nicht erst gestartet werden.
Wie du schon sagtest, Sicherung in aktivem Zustand klappt ja nicht bei Commit.
Also, wie Dieter schon sagt, vorab dafür sorgen, das die blockierenden Job's erst gar nicht starten.

Ein öffentliches API scheint es aber tatsächlich nicht zugeben.
Bleibt dir wohl nichts anderes übrig als den Spool auszuwerten.

Wenn du aber eine zentrale Datei (PF) hast, dann sperre doch diese exclusiv oder, hier gibt es ein API, prüfe wer die Datei gesperrt hat.

[harkne]

Das ist uns alles schon bekannt. Leider haben wir darauf keinen Einfluss. Wir kennen den Jobnamen und auch den der es verursacht. Die Rüge ist schon raus, ändert aber nix daran wenn es nicht geändert wird. Ich hab dann vorgeschlagen, da uns der Jobname bekannt ist, lediglich diesen zu verwenden und darüber raus zu finden ob ein Commit offen ist. Aber wenn ich ein solches Programm machen will dann generell für alle offene COMMITS. Das ist Stand der Dinge und bevor ich aber damit leben muss nachts raus zu müssen und was zu machen was auch ein Programm machen kann, dann soll es halt das Programm machen. Wenn es nichts gibt, werde ich wohl in den sauren Apfel beißen müssen und die Spool-Datei auslesen.

[BenderD]

... nochmal: das gibt eine Wackelhaufen. z.B.: folgendes Szenario:
- Du guckst ob da was is, und da is nix
- die Sicherung läuft los und bis sie an die ominöse Datei kommt, ist da doch was und es knallt!!!
Ich habe das Gedöns mit dem BrummsGelumms und dem SAVACT, der nur zuverlässig geht, wenn nix aktiv ist, lange genug mitgemacht.