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]

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

[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