Frage zu BNDDIR

[dschroeder]

Von mir auch noch ein Hinweis: Wir nutzen nur wenige, aber dafür sehr große BNDDIRs. Bei jeder (erfolgreichen) Compilation eines Serviceprogramms nimmt unser Compile-Script das alte Programm per RMVBNDDIRE aus dem BNDDIR heraus und fügt es dann mit ADDBNDDIRE wieder hinzu. Das klappt bei uns anstandslos. Allerdings exportieren wir immer nur genau eine Procedure pro Serviceprogramm.

Eine Sache ist uns noch aufgefallen: Beim Durchwandeln von tausenden Programmen würden wir gerne Parallelverarbeitung einsetzen. Das klappt jedoch nicht. Es kommt dann immer wieder dazu, dass beim parallelen Massenkompilieren einige Programme nicht gewandelt werden können. Ich glaube, das liegt an Sperrungen auf dem BNDDIR. Bei Kompilierungen in einer Jobq, die jeweils nur einen Job verarbeitet, gibt es diese Probleme nicht.

Dieter

[Fuerchau]

Ich denke nicht, dass es um Sperren geht.
Aber wenn du ein Programm entfernst, dessen Referenz gerade benötigt wird, stirbt halt der CRTxxxPGM da er das zu bindende Objekt nicht findet.
Dies kannst du ggf. umgehen, in dem du einen ALCOBJ auf das BNDDIR mit *EXCL machst und nach dem Remove/Add wieder freigibst.
Der Remove/Add macht das ggf. ja selber aber zwischen Remove und Add vergeht nun mal etwas Zeit.

[dschroeder]

Das mit dem ALCOBJ haben wir früher schon mal probiert. Das hat setlsamerweise nichts gebracht. Wenn wir viele Programme parallel gewandelt haben, konnte man im WRKACTJOB haufenweise Wandlungsjobs sehen, die auf LCKW standen. Ich meine das schon mal näher untersucht zu haben und damals zu der Erkenntnis gelangt zu sein, dass die Programme auf das Eintragen ins Binderverzeichnis warten. Wir haben im Wandlungsprogramm bereits eine Schleife eingebaut, die alle 500ms versucht, den Eintrag vorzunehmen. Das hat das Problem aber nur etwas entschärft, nicht gelöst.

Im Moment wandeln wir immer nicht-parallel. Deshalb haben wir das Problem schon lange nicht mehr gehabt.

Dieter.

[Fuerchau]

Nun, das Wandeln dauert meist länger als das Eintragen im BNDDIR.
Andererseits kann es auch sein, dass der Compiler auf das BNDDIR schon vorab zugreifen will und deshalb nicht startet.

[dschroeder]

Tja, ich muss es demnächst nochmal ausprobieren. Wenn ich etwas rausfinde, werde ich es berichten.

[Fuerchau]

Aber wie Dieter schon sagt, einen Remove brauchst du ja nicht.
Mach einfach einen Add mit MONMSG und alles ist OK.
Dann sollte Parallel-Wandeln funktionieren.

[dschroeder]

Aber wie Dieter schon sagt, einen Remove brauchst du ja nicht.
Mach einfach einen Add mit MONMSG und alles ist OK.
Dann sollte Parallel-Wandeln funktionieren.

Sorry! Ich wollte gerade das RMVBNDDIRE aus dem Wandlungsprogramm entfernen. Das ist aber wohl schon länger nicht mehr drin. Wir machen einfach nur ein ADDBNDDIRE. Sperre kommt trotzdem. Das Problem scheint sogar zu sein, dass es zu dead locks oder etwas ähnlichem kommt. Wenn eine Wandlung erstmal auf einen Lock läuft, scheinen die nächsten das gleiche Problem zu haben. Es ist also anscheinende nicht so, dass die Locks das ganze nur verzögern.

Vielen Dank für eure Mühe.

Ich muss jetzt leider weg. Werde mich aber später nochmal des Problems annehmen.

Dieter

[dschroeder]

Nun, das Wandeln dauert meist länger als das Eintragen im BNDDIR.
Andererseits kann es auch sein, dass der Compiler auf das BNDDIR schon vorab zugreifen will und deshalb nicht startet.

Ich habe es doch gerade nochmal ausprobiert: 50 Serviceprogramm parallel gewandelt. Es ist sind nur ein oder 2 Programme wirklich erstellt worden. Die anderen Wandlungen sind fehlgeschlagen. Im WRKACTJOB standen fast alle auf LCKW. Der Lock geschah aber nicht beim ADDBNDDIR, sondern beim CRTSRVPGM MODULE(*SRVPGM) EXPORT(*ALL) OPTION(*DUPPROC) USRPRF(*OWNER) TGTRLS(*CURRENT) ...

Die Spoolfiles geben an, dass alle Module erstellt wurden. Nur die Programme eben nicht. Ich finde seltsamerweise auch kein Fehlerlog in meinem Spool. Ich muss dass mal genauer prüfen. Vielleicht werden irgendwelche Fehlercodes im Wandlungsprogramm abgefangen.

[BenderD]

... das Binding directory wird nur zur Bindezeit verwendet!!! Beim binden werden alle Importe gegen Exporte aufgelöst und in dem PGM/SRVPGM fest vernagelt. Änderungen nach diesem Zeitpunkt haben auf bereits erstellte PGM/SRVPGM keinerlei Auswirkung. Wenn man allerdings keine eindeutigen Exportnamen hat, können zwischenzeitliche Änderungen des Binding Directories bei der nächsten Erstellung des Programms zu unerwünschten Effekten führen.
Einfacher und stabiler ist es, alle benötigten Module und SRVPGMs im CRTPGM/CRTSRVPGM anzugeben, den Erstellungsbefehl in der Quelle einzubetten und durch einen Precompiler auszuführen - dann sieht man sofort, was da gebunden werden soll und auch andere Erstellungsparameter können reproduzierbar verwendet werden.
Für beide Varianten gilt, dass nur das gebunden wird, was tatsächlich für unresolved references benötigt wird. Angabe von nicht benötigten MODULE oder SRVPGM im Command, oder im binding directory haben auf die erstellten Objekte keinerlei Auswirkung.
Serviceprogramme nach Änderung aus dem BNDDIRrauszunehmen und dann wieder reinzusetzen macht keinerlei Sinn und sollte unterbleiben - dann hat man damit auch kein Problem.

D*B

der sich immer wieder wundert, was da für ein Durcheinander in den Köpfen vorzuherrschen scheint!!!!!!!!!

[Fuerchau]

Nun ja, es gibt ja auch ziemlich unterschiedliche Meinungen zu diesem Thema.
Und somit macht sowieso jeder was er will und für ihn persönlich das beste ist.
Solange es funktioniert...

[BenderD]

... da empfiehlt sich mal ein Blick in ILE concepts
https://www.google.de/url?sa=t&rct=j...f-SPn7eHsmtmEg

[BenderD]

Bei jeder (erfolgreichen) Compilation eines Serviceprogramms nimmt unser Compile-Script das alte Programm per RMVBNDDIRE aus dem BNDDIR heraus und fügt es dann mit ADDBNDDIRE wieder hinzu.Dieter

... wofür soll das gut sein? Ein BNDDIR ist ähnlich wie ein LIBL lediglich eine Suchliste und akzeptiert sogar Einträge, die es garnicht gibt. Im übrigen stehen da nur Module und SRVPGMs drin und die darüber erreichbaren Exporte werden dynamisch gezogen. Lasst das ganze Gedöns weg - und gut ist!!!

D*B