Prüfen, ob PROGRAMM in Benutzung ist

[JIM]

Hallo zusammen,

hier ist mal wieder der "Dino", mit 'ner (merkwürdigen???) Frage.

Wenn ein bestimmtes Programm in Benutzung ist, darf ein konkreter Job nicht gestartet werden.

Leider kann ich das nicht über Objektsperren lösen, da es nicht um eine Datei geht, sondern um ein Programm, welches nur im Bedarfsfall eine Datei für Update/Write öffnet.
Hier im Forum habe ich auch schon gesucht und auch unter der Liste der APIs hat mich nichts auf eine Idee gebracht.

Von einer Lösung, die bei Aufruf des fraglichen Programms irgendeine "ich-bin-jetzt-aktiv"-Meldung in beispielsweise eine DTAARA schreibt, möchte ich gerne absehen, da ein ähnliches Problem mal so gelöst wurde und scheinbar nicht wasserdicht ist... macht manchmal Ärger, vielleicht weil manche User einfach oben rechts die Session schließen...???

Wäre schön, wenn ihr einen Tipp für mich hättet oder - vielleicht sogar noch schöner - wenn ihr mir klipp und klar sagt: DAS GEHT NICHT. ;-)))


Danke, JIM

[Pikachu]

Also wenn jemand auf dem System das Programm nochmals aus dem Quelltext erstellt, dann wird das vorhandenen Programm umbenannt und in die Bibliothek QRPLOBJ verschoben. Dann kann es zwar weiterhin aktiv sein, heißt aber anders. Das heißt am Namen kann man es dann nicht mehr erkennen.

Am besten ist es wenn das Programm selbst ein Objekt sperrt (zum Beispiel exklusiv mit Leseerlaubnis) und später wieder freigibt. Diese Sperre kannst du dann prüfen. Falls der Job mit dem Programm beendet wird (normal oder abnormal), wird die Sperre vom System gelöst.

[KingofKning]

Alternativ kannst Du ja ein wrkactjob in eine Datei machen evtl über sbs eingrenzen und dann auslesen. Dann weißt Du ob in diesem Moment der Job aktiv ist.

Sagt natürlich nichts über 3 Sekunden später aus....

GG

[JIM]

@Pikachu
Also, Programme erstellen hier nur zweieinhalb Leute und die habe ich im Griff ;-) Ansonsten ist Deine Pseudo-Sperre wohl zumindest eine Möglichkeit.

@KingofKning
Es geht nicht um einen bestimmten Job, sondern um ein Programm, das von nahezu jedem interaktiven Job gestartet worden sein könnte. Und da diese alle aus einem Hauptmenü unserer (mehr-oder-weniger)Standardsoftware heraus agieren, kann ich selbst bei der vorgeschlagenen Auswertung WRKACTJOB nicht sehen, ob das fragliche Programm aktiv ist.


Weiß niemand eine elegantere Lösung???
JIM

[mino]

Hallo Jim,

wenn Du in dem zu prüfenden Programm ändern kannst, könntest Du hier ja eine Datei einbauen.

Im Job kannst Du dann auf diese Datei ein ALCOBJ mit *EXCL machen.
Evtl. mit Angabe einer Wartezeit und in einem Loop, um zu warten, bis der Job loslaufen kann.
Am Ende dann wieder DLCOBJ.

Viele Grüße
Michael

[Fuerchau]

Eine Objektsperre (Satzsperre) ist die einzige und sicherste Variante, alles andere dauert zu lange und ist sehr unsicher.
Einen ALCOBJ (s.o.) auf ein Objekt (Datei/DTAARA) wird bei Jobende auch automatisch aufgehoben.

Ansonsten siehe auch hier:
http://newsolutions.de/forum-systemi...em-laeuft.html

[JIM]

Guten Morgen,

Danke, dann wird es jetzt wohl doch auf so eine Lösung hinauslaufen.
Das mit der Objektsperre ist gut.
Wir haben, wie bereits erwähnt, manchmal in eine DTAARA geschrieben, welcher User wann das Programm aufgerufen hat. Das diente dann zur Prüfung, ob andere User das Programm nun aufrufen dürften. Wenn die Jobs (ominöser Weise) nicht korrekt beendet wurden, blieb der Eintrag natürlich hängen... Aber auf die Idee, die Sperre eigentlich mit einer Objektsperre zu realisieren, kam ich nicht.

Danke Euch und frohes Schaffen!
JIM

[B.Hauser]

Wir haben, wie bereits erwähnt, manchmal in eine DTAARA geschrieben, welcher User wann das Programm aufgerufen hat. Das diente dann zur Prüfung, ob andere User das Programm nun aufrufen dürften. Wenn die Jobs (ominöser Weise) nicht korrekt beendet wurden, blieb der Eintrag natürlich hängen...

Auch dem kann man entgegen wirken, in dem man über QMHSNDSM (Send Scope Message) ein Programm oder über CEE4RAGE (Register Activation Group Exit Procedure) eine Prozedur registriert, die ausgeführt werden, wenn der Job oder das Programm oder der Callstack oder die Aktivierungsgruppe beendet wird und zwar unabhängig davon, ob das Ende normal oder abnormal erfolgt. In einem solchen registrierten Programm/Prozedur wird dann der Inhalt der Data-Area zurückgesetzt.

Birgitta

[BenderD]

... depends on design und da würde ich mir bei der beschriebenen Lage keine Hoffnung machen. Ein Programm kann durchaus runterbröseln ohne dass die Activation Group vor Feierabend beim Ende des Jobs wegfliegt...
Meines Erachtens ist das Design von Beginn an krumm - und da sollte man ansetzen.

D*B

Auch dem kann man entgegen wirken, in dem man über QMHSNDSM (Send Scope Message) ein Programm oder über CEE4RAGE (Register Activation Group Exit Procedure) eine Prozedur registriert, die ausgeführt werden, wenn der Job oder das Programm oder der Callstack oder die Aktivierungsgruppe beendet wird und zwar unabhängig davon, ob das Ende normal oder abnormal erfolgt. In einem solchen registrierten Programm/Prozedur wird dann der Inhalt der Data-Area zurückgesetzt.

Birgitta

[B.Hauser]

Ein Programm kann durchaus runterbröseln ohne dass die Activation Group vor Feierabend beim Ende des Jobs wegfliegt...

Deshalb verwende ich auch nicht CEE4RANGE sondern QMHSNDSM, bei dem ich u.U. sogar bei Call-Stack-Ende (also schon wenn die Prozedur endet) ein Programm aktivieren kann. Wenn also meine Prozedur abbröckelt, wird die DataArea richtig gesetzt (die Aktivierungsgruppe kann deshalb noch lange aktiv sein, besonders wenn Spezialisten ihre Programme in der Default-Aktivierungsgruppe laufen lassen).

I.d.R. verwende ich QMHSNDPM auf Programm-Ebene! Da ich nur wenige Programme und viele/viele Prozeduren in Service-Programmen habe und im Extremfall Fehler zwar protokolliere, aber bis auf Programm-Ebene durchbrechenlasse, hatte ich bislang noch keine Probleme damit.

... allerdings verwende ich das Ganze in einem anderen Zusammenhang. (z.B. ein Tool benötigt eine eigene Umgebung/Bibliotheksliste und muss am Ende die ursprüngliche Umgebung wieder herstellen)

Birgitta

[Fuerchau]

Da aber immer noch mindestens 90% aller Anwendungs-Programme OPM-Programme sind, erübrigt sich das.
Für OPM ist ALCOBJ/DLCOBJ immer noch die beste Alternative.

Wenn ich eine Anwendung auf der grünen Wiese mit ILE und SQL entwickeln kann, benötige ich ja solche Dinge gar nicht mehr .