Frage zu BNDDIR

[iseries_user]

Hallo zusammen,

ich habe eine frage zu den BNDDIR.

Ist es Sinnvoll alle SRVPGM in ein einziges BNDDIR zu packen oder sollte man mehrere kleine BNDDIR erstellen?

Habe ich Probleme mit der Performance, wenn ich ein großes BNDDIR erstelle?
Duplikate der einzelnen Prozeduren vermeide ich durch einfügen des Modulnamens in der Prozedur.

Danke & gruß
iseries_user

[Fuerchau]

Das ist dem Compiler letztlich egal. Man kann allerdings nur 300 BNDDIR's angeben.
Performance spielt hier überhaupt keine Rolle, da die Programme ja nicht dauernd und zur Laufzeit neu erstellt werden.
Ob der Binder da nun 1 oder 2 Sekunden benötigt ist doch unerheblich.

Wichtig ist halt nur den Überblick nicht zu verlieren.

[iseries_user]

Ok vielen Dank.


Wenn ich ein SRVPGM ändere, muss ich es aber nicht aus dem BNDDIR raus nehmen und wieder reinschreiben oder?

Danke & Gruß

[Fuerchau]

Aus dem BNDDIR darfst du keine Programme mehr rausnehmen, da sich sonst Bezüge verschieben.
Altlasten schleppt man so halt mit.

Die Fraktion die gegen BNDDIR's ist hat diese Probleme dann nicht.

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

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

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