Frage zu BNDDIR

[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