Frage zu BNDDIR

[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

[BenderD]

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

Hier ist zumindest der Mechanismus richtig beschrieben, es fehlen aber die Nebenwirkungen:
- macht man was verkehrt, geht es ohne Vorwarnung richtig in den Wald, da schützt einen keine Signatur mehr (ganz analog zu Dateiänderungen und CRTPF mit LVLCHK *NO - macht man hier alles richtig, erspart man sich auch compiles).
- Bei dieser Vorgehensweise kann man keine Exporte entfernen, was aber bei Änderungen an Schnittstellen gebraucht wird (zusätzliche erweiterte Schnittstelle zufügen, wenn alles nachgezogen ist alte entfernen)

Ich erspare mir halt die Mühe Binderquellen zu warten, muss dafür den Binder ein wenig mehr arbeiten lassen und gewinne Sicherheit, als fauler Mensch lasse ich die Maschine für mich arbeiten, statt umgekehrt und gewinne noch Sicherheit. Was will man mehr!!!

D*B

[B.Hauser]

Ich erspare mir halt die Mühe Binderquellen zu warten, muss dafür den Binder ein wenig mehr arbeiten lassen und gewinne Sicherheit, als fauler Mensch lasse ich die Maschine für mich arbeiten, statt umgekehrt und gewinne noch Sicherheit. Was will man mehr!!!

Bei mir werden die Binderquellen auch nicht manuell gewartet (zu fehleranfällig), sondern per Programm generiert, das zuvor die aktuellem Quellen scannt und die exportierten Prozeduren herauszieht. Die einzige zusätzliche Regel ist, dass neue (exportierte) Prozeduren immer am Ende des Source Codes angefügt werden müssen.

Einige meiner (Ex-)Kollegen wissen noch nicht einmal, dass sie mit Bindersprache arbeiten.

[BenderD]

Bei mir werden die Binderquellen auch nicht manuell gewartet (zu fehleranfällig), sondern per Programm generiert, das zuvor die aktuellem Quellen scannt und die exportierten Prozeduren herauszieht. Die einzige zusätzliche Regel ist, dass neue (exportierte) Prozeduren immer am Ende des Source Codes angefügt werden müssen.

... einer der seltenen Fälle, dass wir uns völlig einig sind: you must not do it by your own, wobei ich mich immer frage, warum ist IBM da nix besseres eingefallen, das können ander ohne handgestrickte Tools...

schönen Abend noch,

Dieter

[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