Frage zu BNDDIR

[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

[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

[iseries_user]

Hallo zusammen,

ich habe eine frage zu den BNDDIR.

Ist es Sinnvoll alle SRVPGM in ein einziges BNDDIR zu packen oder sollte man mehrere kleine BNDDIR erstellen?

Habe ich Probleme mit der Performance, wenn ich ein großes BNDDIR erstelle?
Duplikate der einzelnen Prozeduren vermeide ich durch einfügen des Modulnamens in der Prozedur.

Danke & gruß
iseries_user

[Fuerchau]

Das ist dem Compiler letztlich egal. Man kann allerdings nur 300 BNDDIR's angeben.
Performance spielt hier überhaupt keine Rolle, da die Programme ja nicht dauernd und zur Laufzeit neu erstellt werden.
Ob der Binder da nun 1 oder 2 Sekunden benötigt ist doch unerheblich.

Wichtig ist halt nur den Überblick nicht zu verlieren.