Prüfen, ob PROGRAMM in Benutzung ist

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