WRKCMTDFN als API

[harkne]

Hallo zusammen,

ich soll programmtechnisch feststellen ob es offene Commits auf dem System gibt. Als Befehl habe ich WRKCMTDFN JOB(*ALL) STATUS(*PENDING) gefunden. Allerdings kann ich darüber nur anzeigen oder drucken lassen. *OUTFILE gibt es leider nicht. Kann mir jemand sagen ob es dafür ein API gibt ?

Vielen Dank

Viele Grüße Harald

[BenderD]

... m.W. geht das nur über die Jobs (QGYOLJOB), falls QWCRTVCA da was hat, wobei ich mich frage, wofür das gut sein soll.

D*B

[harkne]

Es geht letztendlich darum, dass ein Job, der eigentlich gar nicht laufen dürfte, aber auch nicht von uns ist, auf dem System läuft und per update, bei dem der COMMIT noch fehlt, eine Datei sperrt, die wir in unserem Job sichern wollen. Der Job soll dann von unserem Job programmgesteuert beendet werden. Es geht aber nicht nur um diesen Job, sondern um alle. Wir sichern bereits im aktiven Zustand, nur bei offenem COMMIT funktioniert dies halt nicht. Ich muss aber auch ganz ehrlich sagen, dass dies nicht meine Baustelle ist. Gewünscht wird von mir dass ich offene Commits finde und die Jobs, die diese verursachen beende.
Ein Kollege hatte im Juli bereits mal eine Anfrage. Nachdem er WRKCMTDFN als Antwort bekam, reichte ihm das aus. Da jetzt das Problem aber programmtechnisch entfernt werden soll bräuchte ich die Daten halt in einer Datei oder als Result aus einem API denn die Spooldatei auslesen wollte ich nicht unbedingt, wenn es nicht sein muss.

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