Frage zu BNDDIR

[iseries_user]

Das heißt, wenn ich ein RMVBNDDIRE mache, müsste ich alle Programme, die das BNDDIR nutzen neu wandeln?

Angenommen ich würde ein SRVPGM um eine Prozedur erweitern bzw. eine Prozedur anpassen (Parameter geändert oder Logik geändert). Dann habe ich mit dem BNDDIR keine Probleme oder?
Beim ändern der Parameter muss ich dann im BND eine neue Signatur erstellen und die aktuelle als *PRV im BND behalten.

[Fuerchau]

Vorsicht:
Das Ändern von Parametern bei Verwendung von BinderSource ist strikt verboten!
Du kannst nur eine neue Prozedur mit den geänderten Parametern schreiben und im Verzeichnis hinten anhängen. Eine neue Signatur und/oder *PRV ist nach meiner persönlichen Erfahrung gar nicht nötig.
Die alte Prozedur musst du ggf. als Wrapper umschreiben in dem diese mit den neuen Parametern und ggf. Defaults die neue Prozedur aufruft.
Damit können alte Programme noch die alte Prozedur aufrufen.
Solltest du dies auch nicht wünschen, musst du ggf. in der alten Prozedur eine ESC-Message senden so dass nicht umgestellte Programme auf die Nase fallen.
Bei korrekter Softwareverwaltung weiß man ja, welche Programme auf die neue Prozedur umgebogen werden müssen.

Solltest du das so nicht wollen, dann verabschiede dich besser von BNDDIR's und binde alle Programme neu die das Service-PGM verwenden.
Auch dafür gibt's ja Tools.

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

[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

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

[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

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