Frage zu BNDDIR

[mihael]

Unter dieser Prämisse:
- Erweitere nie ein Serviceprogramm da sich die Signatur (durch Sortierung nach Namen) ändert und alle anderen Programme dann auf die Nase fallen.
- schreibe dann lieber ein neues

Ich mach weiter mit meinen BNDDIR's.

Ich weiss ich bin etwas spät dran, aber ich dachte ich gebe auch noch was zum Besten, da ich in diesem Thema über ein paar Jahre mit meinen Open Source Serviceprogrammen (http://www.rpgnextgen.com) Erfahrung gesammelt habe.

Die Erweiterung von Serviceprogrammen ist grundsätzlich überhaupt kein Problem, wenn man die Signatur selbst setzt. Hier ein Beispiel für das Erweitern eines Serviceprogrammes mit Verwendung einer Binder Source: http://sourceforge.net/u/fist/src/HE.../json/json.bnd

Das Serviceprogramm enthält nicht nur eine Signatur, sondern mehrere. Somit müssen bestehende Programme nicht neu kompiliert werden, solange das Serviceprogramm kompatibel ist. Die erweiterten Prozeduren einfach immer hinten anhängen.

Ist ein Serviceprogramm aufgrund von Änderungen an der API (Prototypen) nicht mehr abwärtskompatibel, vergibt man einfach eine neue Signatur und löscht die alten Signaturen aus der Binder Source.

Letztendlich steht und fällt das Ganze mit der Sauberkeit der Programmierung bzw. der API.

Meine 2 Cent.

Mihael

[BenderD]

... auch da habe ich noch ein wenig Wechselgeld...
- jede Version braucht eine eigene Signatur (sonst merkt ein Programm nicht ob die installierte Version neu genug ist).
-- es muss mit jeder Erweiterung eine neue Signatur erzeugt werden
-- alte Komoponenten und Signaturen dürfen nicht entfernt werden.
-- alle Signaturen müssen unique sein

Die meisten können sich diesen Aufwand (und diese Fehlerquelle) ersparen. Wer sowohl das SRVPGM als auch die Verwender kontrolliert, kann sich das schenken und abhängige Komponenten neu binden, das ist einfacher und schneller erledigt.

D*B

Ich weiss ich bin etwas spät dran, aber ich dachte ich gebe auch noch was zum Besten, da ich in diesem Thema über ein paar Jahre mit meinen Open Source Serviceprogrammen (http://www.rpgnextgen.com) Erfahrung gesammelt habe.

Die Erweiterung von Serviceprogrammen ist grundsätzlich überhaupt kein Problem, wenn man die Signatur selbst setzt. Hier ein Beispiel für das Erweitern eines Serviceprogrammes mit Verwendung einer Binder Source: http://sourceforge.net/u/fist/src/HE.../json/json.bnd

Das Serviceprogramm enthält nicht nur eine Signatur, sondern mehrere. Somit müssen bestehende Programme nicht neu kompiliert werden, solange das Serviceprogramm kompatibel ist. Die erweiterten Prozeduren einfach immer hinten anhängen.

Ist ein Serviceprogramm aufgrund von Änderungen an der API (Prototypen) nicht mehr abwärtskompatibel, vergibt man einfach eine neue Signatur und löscht die alten Signaturen aus der Binder Source.

Letztendlich steht und fällt das Ganze mit der Sauberkeit der Programmierung bzw. der API.

Meine 2 Cent.

Mihael

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

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