Anmelden

View Full Version : Lib eines Programms ermitteln



Seiten : [1] 2

dschroeder
12-06-13, 15:33
Hallo,

ich weiß, es klingt etwas seltsam, aber ich muss ein Programm aufrufen, von dem ich nicht weiß, in welcher Bibliothek es sich befindet. Die Bibliothek, in der sich das Programm befindet, ist zu diesem Zeitpunkt auch nicht in der *LIBL.

Deshalb möchte ich (wie ich das z.B. mit WRKOBJ machen würde) alle Bibliotheken ermitteln, in denen sich ein PGM mit dem spezifischen Namen befindet.

Kennt jemand dazu eine einfache Möglichkeit?


Danke im Voraus,
Dieter

Pikachu
12-06-13, 15:48
Wir wärs mit einem DSPOBJD nach *OUTFILE und anschließenden RCVFs über die Ausgabedatei in Schleife?

Fuerchau
12-06-13, 15:50
Das gehört eigentlich verboten!

Außerdem kann es da verschiedene Versionen des selben Programmes in verschiedenen Lib's geben.
Zusätzlich kann dieses Programm dann Ressourcen benötigen, die dann auch nicht in der LIBL verfügbar sind (z.B. andere Programme oder Dateien).

Sicherstellen kannst du das wirklich nur, wenn deine LIBL stimmt.

Ansonsten gibt es leider keine "einfache" Möglichkeit, hierfür musst du die Objekt- und USRSPC-API's bemühen.

Mittels Objekt-API das/die Objekt(e) ermitteln. Dieses API stellt dir einen USRSPC mit einer Liste zur Verfügung die du mit den entsprechenden API's dann auslesen kannst.

Ob das dann so funktioniert wie von dir gewünscht bleibt dann abzuwarten.
Das Risiko dabei ist sehr hoch.

Fuerchau
12-06-13, 15:52
DSPOBJD geht zwar auch, aber man muss dabei aufpassen, dass man hier eindeutige Dateinamen (QTEMP) verwendet. Immerhin können das ja mehrere Jobs gleichzeitig machen.

BenderD
12-06-13, 16:13
Das gehört eigentlich verboten!

Ob das dann so funktioniert wie von dir gewünscht bleibt dann abzuwarten.
Das Risiko dabei ist sehr hoch.
... wer wird denn da so streng sein, immerhin ist das schon besser als die LIB zu kennnen und dann das Programm auszuwürfeln - und außerdem gilt: no risc no fun...

D*B

B.Hauser
12-06-13, 16:13
DSPOBJD geht zwar auch, aber man muss dabei aufpassen, dass man hier eindeutige Dateinamen (QTEMP) verwendet. Immerhin können das ja mehrere Jobs gleichzeitig machen.

Das Problem hast Du aber auch bei den List APIs wenn Du den gleichen User Space Namen verwendest und nicht in die QTEMP kopierst.

Das API für Objekte is QUSLOBJ (List Objects) und Format OBJL0100 sollte reichen.

Birgitta

Fuerchau
12-06-13, 16:32
Als USRSPC gebe ich ja gezielt QTEMP an, bei DSPOBJD in QTEMP brauche ich aber noch einen OVRDBF, da ja zum Compilezeitpunkt ggf. die Datei nicht da ist.
Ich könnte da natürlich auch anschließend SQL nehmen.

Wie immer, es gibt viele Möglichkeiten (auch ein Programm zum Absturz zu bringen).

dschroeder
12-06-13, 16:33
Vielen Dank für die schnellen und zahlreichen Antworten.

Das API ist wahrscheinlich die eleganteste Lösung. Nur sind API-Aufrufe (für mich) meistens mit zeitintensiver Tüftelei verbunden.
Deshalb werde ich wohl erstmal die DPSOBJD-Lösung favorisieren.

Zur Erklärung, was das ganze soll: Wir setzen ja Profound ein und möchten Profound-Releasewechsel ohne Nachtarbeit erledigen. Deshalb wollen wir die User mit einer vorgeschalteten Apache-Instanz auf die von uns (der Programmierung) gerade gewünschten Profound-Instanz leiten, wenn die User eine neue iSeries-Sitzung (im Browser) öffnen. Dazu müssen wir im Startprogramm des Users aber die richtige Profound-Bibliothek (passend zur Apache-Instanz) setzen. Um die richtige Bibliothek herauszufinden, müssen wir ein bestimmtes Profound-Tool aufrufen, dass uns die gewünschte Information liefert. Das Aufrufen des Tools ist allerdings schwierig, solange sich noch keine Profound-Lib in der *LIBL befindet.

Während ich das ganze hier schreibe, merke ich gerade, dass ich den Wald vor lauter Bäumen nicht sehe: Ich kann ja das Profound-Tool einfach in eine feste, beim Releasewechsel nicht veränderbare eigene Lib kopieren und damit immer ohne Suchen finden!

Tja, sorry für die Mühe.
Und danke, das wir darüber gesprochen haben :-).

Viele Grüße,
Dieter

Fuerchau
12-06-13, 17:16
Wenn du verschieden Versionen hast würde ich diese Info doch in einer bekannten Lib in einer Datei vorhalten.
Somit reicht SQL um die korrekte Lib zur Version herauszufinden und die LIBL anzupassen.

Pikachu
12-06-13, 17:53
Wenn du stattdessen einen eigenen Befehl schreibst, der das gewünschte Programm aufruft, und diesen in die feste Bibliothek legst, dann brauchst du diesem nur die entsprechenden Produktbibliothek (Parameter PRDLIB) einmalig einzutragen.