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]

.. die eigentliche Frage des OP ist ein wenig in den Hintergrund gedrängt worden, da gibt es noch einige offene Punkte:

ich habe z.b. 3 Module mit X prozeduren ..

ich kann ja jetzt die module so binden ..

CRTBNDDIR BNDDIR(&LIB/BNDDIR1) TEXT('XYZ')

ADDBNDDIRE BNDDIR(BNDDIR1) OBJ((module1 *MODULE))
ADDBNDDIRE BNDDIR(BNDDIR1) OBJ((module2 *MODULE))
ADDBNDDIRE BNDDIR(BNDDIR1) OBJ((module3 *MODULE))

und es im PGM in den H Bestimmungen so einbinden BNDDIR(BNDDIR1) und auf die prozeduren zugreifen

Gedanklich befinden wir uns wohl in einem 4. Modul mit einem main. Du verwendest hier ein Binding directory, damit Du das ganze aus PDM bequem wandeln kannst und Du mit H oprtions nicht an alle Compile Parameter drankommst. Das ist dann stabil, wenn Du pro Programm eine eigenes Binding Directory verwendest (am besten: Name des BNDDIR = Module name des Moduls, wo die H-Option drauf verweist.

Auf diese Art und Weise bindest Du die 3 Module per Copy ein, mit der Folge, dass nach Änderung eines der gebundenen Module noch die alte Version gebunden ist und die neue Version erst nach erneutem binden (bei PDM wandeln) verfügbar ist. Werden Funktionen aus den gebundenen Modulen woanders auch noch gebraucht, werden die Module redundant in die Programme beim binden reinkopiert.

Vorteil kann hierbei sein, dass bei unterschiedlichen Versionen mit dem Programm immer die passenden Module gefunden werden, ohne Einfluss des LIBL zur Laufzeit.

oder ich mache

ein ServicePGM (BNDDIR2) daraus z.b. ..
STRPGMEXP SIGNATURE('XYZ_01')
EXPORT SYMBOL("proz1")
EXPORT SYMBOL("proz1")
EXPORT SYMBOL("proz1")
EXPORT SYMBOL("proz1")
EXPORT SYMBOL("proz1")
ENDPGMEXP

CRTBNDDIR BNDDIR(&LIB/BNDDIR2) TEXT('xyz')
ADDBNDDIRE BNDDIR(BNDDIR2) OBJ((BNDDIR2 *SRVPGM))

und binde es im PGM in den H Bestimmungen sin ein BNDDIR(BNDDIR2)

Jetzt erstellst Du im ersten Schrit ein SRVPGM aus den 3 Modulen und machst sie dadurch per reference bindbar, in der Exportliste müssen die Namen natürlich alle unterschiedlich sein und mit den EXTPRC Einträgen des Prototyps der exporte übereinstimmen.

Das zu bindende SRVPGM hast Du wieder in einem BNDDIR (hier gilt wieder meine obige Empfehlung!!!) In diesem Fall wird nur die Exportliste des SRVPGM in das Programm gebunden, zur Laufzeit wird dann das SRVPGM über den LIBL gesucht (und hoffentlich gefunden) und die Exporte an die Exportliste nach Position gebunden, das nennt man bind by reference. Nach Änderung im SRVPGM braucht man nicht neu zu binden, solange die Exportliste für die verwendeten Einträge noch "passt", sitzt an einer der verwendeten Exporte jetzt was anderes, geht es lustig in den tiefen Wald!!!

was ist der vor und nachteil der jeweiligen technik ??

Im Regelfall ist die zweite Variante eindeutig vorzuziehen, es gibt aber durchaus Ausnahmen, wo Variante 1 vorteilhaft ist, bei den an anderer Stelle genannten Triggerprogrammen zum Beispiel.
An Deinem Beispiel sieht man auch sehr schön die Rolle des Binderverzeichnisses. Ob Variante 1 entsteht, oder Variante 2 geht nur aus dem Binderverzeichnis hervor. Bei einem zentralen Verzeichnis würden also nach Änderung im Binderverzeichnis, andere Objekte bei der nächsten Wandlung anders erstellt werden als zuvor, was bei Änderungen in den Modulen später zu Seiteneffekten führt.

D*B