Frage zu BNDDIR

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

[B.Hauser]

So, Dieter
Wenn man sich also an die von Dir genannten Grundregeln hält, warum wehrst Du Dich gegen ein Binderverzeichnis in dem alle Service-Programm eingetragen sind.

Eindeutige Prozedur-Namen, eindeutige Service-Programm-Namen, nur die Service-Programme im Binderverzeichnis, also keine Gefahr das Duplikate auftreten könnten.
Wenn dann alle Service-Programme in ein Binderverzeichnis gepackt werden, das beim Binden mitgegeben wird, werden die richtigen Prozeduren auch problemlos gefunden.

Ich fahre seit Jahren mit diesem Prinzip und habe bislang bei "hunderten" von Service-Programmen mit "tausenen" von Prozeduren bislang keinerlei Probleme damit gehabt.

Voraussetzung ist natürlich die Eindeutigkeit der Prozedur-Namen (mit Service-Programm-Name "qualifizieren") und die Regeln 1 Modul = 1 Programm oder 1 Modul = 1 Service Programm.

Probleme sind nur dann aufgetreten, wenn sich irgendjemand nicht an die Regeln gehalten hat. Aber dies Probleme treten dann auch ohne Binderverzeichnis auf.

Birgitta

[BenderD]

Eindeutige Prozedur-Namen, eindeutige Service-Programm-Namen, nur die Service-Programme im Binderverzeichnis, also keine Gefahr das Duplikate auftreten könnten.

Probleme sind nur dann aufgetreten, wenn sich irgendjemand nicht an die Regeln gehalten hat. Aber dies Probleme treten dann auch ohne Binderverzeichnis auf.

Birgitta

- Duplikate treten dann auf, wenn ich dasselbe Modul in einigen Programmen per COPY binde (damit ich vom LIBL unabhängig bin - Beispiel Trigger, Exitprogramme (ARDPGM mit mehrfacher Installierbarkeit) und in anderen Modulen per Reference binde (weil das im Regelfall besser ist).
- Das mit den Problemen stimmt natürlich, aber der Unterschied ist hierbei wer die Probleme bekommt und wann sie auftreten. Bei Krummheiten im Binderverzeichnis treten diie Probleme irgendwann später in ganz anderen Programmen/Serviceprogrammen auf, wenn niemand mehr so richtig weiß was da jetzt krumm ist und wie es gerade war. Biegt man es jetzt für das betreffende Objekt gerade, knallt es wieder einiges später bei einem anderen Objekt.
- Ich bin ein großer Anhänger davon, dass jede Quelle vollständig enthält, wie das entsprechende Objekt erstellt werden muss und dass jedes Objekt genau eine Quelle hat.

Dieter Bender

[Fuerchau]

Dann muss man halt nur auf Serviceprogramme verzichten, da diese ja das Problem der Signaturen haben.
Wenn ich meine Programme immer mit allen Modulen zu einem Objekt binde habe ich natürlich diesbezüglich keine Probleme.
Aber warum mache ich Service-Programme?
Um Redundanzen zu verhindern und die Wartbarkeit zu vereinfachen.
Das habe ich bei OPM ja auch nicht anders gemacht:
Viele Funktionen in vielen Modulen die dann per Schnittstelle aus diversen Ecken aufgerufen wurden.
Natürlich kann ich dieses OPM-Prinzip weiter behalten und somit auf Service-Programme verzichten.
Mache ich aber Serviceprogramme vereinfache ich das durch BindaryLanguage und BNDDIR's.

Und die Probleme von LIBL usw. haben damit nichts zu tun, die habe ich schon immer gehabt.

[BenderD]

Dann muss man halt nur auf Serviceprogramme verzichten, da diese ja das Problem der Signaturen haben.
Wenn ich meine Programme immer mit allen Modulen zu einem Objekt binde habe ich natürlich diesbezüglich keine Probleme.
Aber warum mache ich Service-Programme?
Um Redundanzen zu verhindern und die Wartbarkeit zu vereinfachen.
Das habe ich bei OPM ja auch nicht anders gemacht:
Viele Funktionen in vielen Modulen die dann per Schnittstelle aus diversen Ecken aufgerufen wurden.
Natürlich kann ich dieses OPM-Prinzip weiter behalten und somit auf Service-Programme verzichten.
Mache ich aber Serviceprogramme vereinfache ich das durch BindaryLanguage und BNDDIR's.

Und die Probleme von LIBL usw. haben damit nichts zu tun, die habe ich schon immer gehabt.

Das Problem mit der Signatur haben nur diejenigen, die da händisch rumfummeln - ansonsten macht das die Maschine für mich, da lässt man ein Programm rattern und das wars.

Nochmal zum LIBL, am Beispiel:
- Ich habe einen Trigger, der ein SRVPGM benutzt.
- Die Datei wird aus allen möglichen Umgebungen benutzt, lokal, remote und alles mögliche.
- Der Trigger wird beim ADDPFTRG qualified angehängt - das geht garnicht anders!
- Das SRVPGM existiert in mehr als einer Umgebung, in einer oder mehreren Versionen.

Was ich dann mache:
- ich binde POCP4NAME (SRVPGM zum dynamischen binden by Copy
- die benötigten SRVPGMs binde ich dann dynamisch und kann jetzt genau kontrollieren was gebunden wird (zumeist ist es dann das SRVPGM aus derselben LIB wie das Triggerprogramm).
Da ich jetzt natürlich PROCP4NAME nicht generell per COPY binden will, gibt es jetzt beide Varianten.

D*B