Frage zu BNDDIR

[woodstock99]

Hallo ,

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

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)



was ist der vor und nachteil der jeweiligen technik ??

[Fuerchau]

Wenn du mit BNDDIR arbeitest, solltest du die 2. Methode wählen, da du dann eine eigene Signatur wählen kannst.
Da beim Binden die Signatur übernommen wird, stellt die Laufzeit sicher dass das passt.
Die Reihenfolge der exportierten Prozeduren wird nicht mehr geprüft und ist deshalb unbedingt einzuhalten.
Neue Exporte gehören immer ans Ende da der Funktionsaufruf immer über die relative Position erfolgt (dann braucht nicht gesucht zu werden).
Tauscht du Positionen aus, kommt es zu schweren Laufzeitfehlern da ja eine andere Prozedur aufgerufen wird.
Parametererweiterungen einer Prozedur sind möglich, wenn sie hinten angehängt werden und die Anzahl in der Funktion geprüft wird.
Ansonsten eine neue Funktion hinten anhängen und ggf. aus der alten Funktion die neue mit den erweiterten Parametern (Defaults!) aufrufen (Wrappen).
Man kann auch mehrere Serviceprogramme/Module in ein BNDDIR packen.

Im Forum gibt es 2 Meinungen:
Ohne BNDDIR und die Module im CRTPGM explizit aufführen, dazu gibt es ja auch Hilfsmittel.
Vorteil: Wenn sich ein Service-PGM ändert, dann müssen alle Programme neu kompiliert werden. Ansonsten gibt es Laufzeitfehler.
Nachteil: Genau dieses, was als Vorteil gesehen wird, wird schnell zum Nachteil.
Wenn die IBM für System-Runtime (RPG, LE, COBOL, ...) ohne BNDDIR arbeiten würde müssten mit jedem PTF alle Programme neu gebunden (nicht compiliert) werden.
Den Aufwand will wirklich keiner.

[BenderD]

... da schüttelt sich bei mir wieder mal alles, da geht wieder alles kreuz und quer.

BNDDIR haben mit Signaturen und Rebind nichts zu tun!!!

Wenn ein Programm oder Serviceprogramm Prozeduren aus anderen Modulen verwendet, dann muss man zur Bindezeit (beim CRTPGM bzw. CRTSRVPGM) Angaben machen woher diese Prozeduren kommen sollen. Dazu gibt es mehrere Varianten:
- Bind by copy: hier werden Module in das jeweilige Objekt zur Bindezeit reinkopiert.
- Bind by Reference: hier müssen die benötigten Module über ein SRVPGM erst bindbar gemacht werden
Nun kann man entweder im jeweiligen Parameter MODULE und BNDSRVPGM explizit angeben, was und wie gebunden weerden soll, das ist das stabilste und beste, erfordert aber ein Minimum an change Management (entweder schreibt man den command in die Quelle und benutzt einen Preprozessor, oder man verwendet ein Tool, das das aus bereits vorhandenen Objekten ausliest und wieder genauso macht.

Wer ein wenig Nervenkitzel braucht, der kann auch zu bindende Objekte in ein BNDDIR reinpacken (maximale Blutdruckerhöhung bekommt man mit einem einzigen Binderverzeichnis für alles und alle) und dann das System entscheiden lassen, was und wie gebunden wird - bei sorgfältiger Vorgehensweise kriegt man auch das, was man haben will.

Jetzt mit den Signaturen:
Hier kann man mit Binderquellen Signaturen selber vergeben und verwalten, das spart dann rebind Prozesse. Das empfehle ich allen, die Software Pakete verkaufen (oder als Open Source verteilen), vorher sollte man sich aber sehr solide damit beschäftigen, was da wie wirkt.

Allen anderen, insbesondere denen, die nicht genau wissen was sie da tun und auch denen, die da meinen Parameterschnittstellen ändern zu müssen und können, empfehle ich keine Binderlanguage zu verwenden und SRVPGMs mit export(*ALL) zu wandeln, dann zieht ein levelcheck Mechanismus vergleichbar mit dem bei Dateien, der davor schütz, dass Unfug aufgerufen wird - eh' was falsch aufgerufen wird, schmiert das Programm ab (wie bei Dateien auch) vermieden wird das, indem man alles betroffene neu bindet (wie die technische Umwandlung bei geänderten Dateien) und der Compiler alles prüft und wieder passend macht. Auch bei dem zweiten Verfahren ändert man selbstverständlich keine Schnittstellen, sondern fügt nur neues hinzu und nicht mehr verwendetes darf man dann rausnehmen.

D*B

[Fuerchau]

"Wer ein wenig Nervenkitzel braucht, der kann auch zu bindende Objekte in ein BNDDIR reinpacken (maximale Blutdruckerhöhung bekommt man mit einem einzigen Binderverzeichnis für alles und alle) und dann das System entscheiden lassen, was und wie gebunden wird - bei sorgfältiger Vorgehensweise kriegt man auch das, was man haben will."

Ich weiß nicht wieso das Nervenkitzel ist. Wie gesagt, ohne BNDDIR (und Bindary-Language) wird das mit größeren Projekten immer schwierig weil bei Erweiterung von Serviceprogrammen um neue Funktionen oder neue Serviceprogramme nur die betroffenen Programme gebunden/erstellt werden müssen.
Alle anderen Programme müssen nicht mehr gebunden werden.
Da herrscht auch kein Zufallsprinzip. Und ich muss nicht immer alles ausliefern.
Immerhin ist ja die Kompatibilität der Laufzeit seit Erfindung des ILE erhalten geblieben, dank der BNDDIR's des Systems. Warum soll ich diese Vorteile nicht nutzen und dies der IBM vorhalten?
Meine ILE's laufen seit V4 bis heute V7 problemlos.

[BenderD]

Wie gesagt, ohne BNDDIR (und Bindary-Language) wird das mit größeren Projekten immer schwierig weil bei Erweiterung von Serviceprogrammen um neue Funktionen oder neue Serviceprogramme nur die betroffenen Programme gebunden/erstellt werden müssen.
Alle anderen Programme müssen nicht mehr gebunden werden.
Da herrscht auch kein Zufallsprinzip. Und ich muss nicht immer alles ausliefern.
Immerhin ist ja die Kompatibilität der Laufzeit seit Erfindung des ILE erhalten geblieben, dank der BNDDIR's des Systems. Warum soll ich diese Vorteile nicht nutzen und dies der IBM vorhalten?
Meine ILE's laufen seit V4 bis heute V7 problemlos.

Lieber Baldur,

das mit dem BNDDIR hast Du ganz offenkundig nicht verstanden, das hat mit dem rebind nichts, aber auch garnichts zu tun!!
Auch das mit der Kompatibilität zur Laufzeit hat mit den Binding directories nichts, aber auch garnichts zu tun!!!
Und denke doch mal drüber nach, warum IBM zum Releasewechsel alles neu ausliefert!!!

Selbstverständlich vergibt IBM die Signaturen seiner SRVPGMs selber, aber wer schon das mit dem BNDDIR nicht geschnallt hat, sollte da die Finger von lassen.

Ein letztes Wort zu den BNDDIRs:
Wenn man versucht alles über ein zentrales BNDDIR zu binden, dann gibt es spätestens dann doppelte Einträge für Exporte, wenn man dasselbe Modul einmal by Copy und in anderen Modulen per Reference bindet (ja, das kann Sinn machen, wenn man z.B.: den Libl nicht kontrollieren kan, bei Triggern, Functions, Exits z.B. , dann muss man ohl oder Wübel mit Option(*DUBPROC) wandeln und dann entscheidet die Reihenfolge im BNDDIR darüber, wie man bindet, by copy oder by reference; hat man auch noch doppelte exportnamen für unterschiedliche Komponenten, dann entscheidet die Reihenfolge darüber aus welchem Modul der export aufgelöst wird - und in allen Fällen, wo sowas geknallt hat, hat der größte Chaot im Team die Hoheit über das BNDDIR gehabt, der hat nämlich einfach alles solange umgerührt bis sein raffiniertes Programm wandelbar war - und hat damit die Büchse der Pandorra geöffnet.

Ich bleibe dabei: an de gnebbsche schbiele solle nur ecksberrde

D*B

[ExAzubi]

Schade, ich dachte jetzt schnalle ich das mal mit dem BNDDIR aber auch jetzt herscht bei mir nur (noch mehr) Verwirrtheit.
Hat schon einen Grund warum ich keine SRVPGM mache....

[BenderD]

Schade, ich dachte jetzt schnalle ich das mal mit dem BNDDIR aber auch jetzt herscht bei mir nur (noch mehr) Verwirrtheit.
Hat schon einen Grund warum ich keine SRVPGM mache....

... das wird alles ganz einfach, wenn man sich an ganz wenige Grundregeln hält:
- eindeutige Exportnamen durch prefixen mit dem Namen des Moduls
- COPY Module mit gleichem Namen wie das Modul (anderes Sourcefile für die COPY Member) für die Prototypen der Exporte
- ein Modul gleich ein SRVPGM (gleicher Name)
- komplettes Erstellungsskript in die Quelle einbetten und mit Preprozessor wandeln
- keine Spielereine mit Signturen, keine Schnittstellenänderungen
Die Vorteile bestehen dann in stark erweiterten Modularisierungs Möglichkeiten.

D*B

[Fuerchau]

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.

[BenderD]

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.

- da fällt nix auf die Nase,ich muss nur abhängige Komponenten neu binden (dauert Sekundenbruchteile).
- mit Deinen BNDDIRs bewirkst Du da garnix, da muss Du zur Binder Language greifen.

D*B

[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

[B.Hauser]

Werden zu einem Service-Programm neue Prozeduren hinzugefügt, und lässt man die Signatur automatisch generieren, verändert sich diese.
Deshalb hat man mit der Bindersprache 2 Optionen.
Die Signatur generieren zu lassen, dann muss man den vorherigen Export-Block einfach als *PRV in der Binderquelle behalten.
Macht man dies sauber, braucht man noch nichteinmal die abhängigen Objekte neu zu binden, da sowohl die alte als auch die neue Signatur in dem Service-Programm gespeichert werden. Damit werden sowohl die (Service-)Programme in denen die alte Signatur hinterlegt ist, als auch die (Service-)Programme, die die neue Signatur verwenden, gefunden.
(Auch das läuft bei mir seit Jahren problemlos)

Die andere Option ist die Signatur bei der Bindersprache fix vorzugeben. Wenn man dies sauber macht, hat man ebenfalls keine Probleme mit irgendwelchen doppelten Signaturen.
In diesem Fall muss noch nichteinmal der vorherige Export-Block gesichert werden, da sich die Signatur beim Hinzufügen neuer Prozeduren nicht verändert.
Auch in diesem Fall muss man die abhängigen Objekte nicht erneut binden, da die Signatur unverändert ist.

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