Frage zu BNDDIR

[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]

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

[BenderD]

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.

Das Problem mit der Signatur haben nur diejenigen, die da händisch rumfummeln - ansonsten macht das die Maschine für mich, da lässt man ein Programm rattern und das wars.

Nochmal zum LIBL, am Beispiel:
- Ich habe einen Trigger, der ein SRVPGM benutzt.
- Die Datei wird aus allen möglichen Umgebungen benutzt, lokal, remote und alles mögliche.
- Der Trigger wird beim ADDPFTRG qualified angehängt - das geht garnicht anders!
- Das SRVPGM existiert in mehr als einer Umgebung, in einer oder mehreren Versionen.

Was ich dann mache:
- ich binde POCP4NAME (SRVPGM zum dynamischen binden by Copy
- die benötigten SRVPGMs binde ich dann dynamisch und kann jetzt genau kontrollieren was gebunden wird (zumeist ist es dann das SRVPGM aus derselben LIB wie das Triggerprogramm).
Da ich jetzt natürlich PROCP4NAME nicht generell per COPY binden will, gibt es jetzt beide Varianten.

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

[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

[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.

[iseries_user]

Ok vielen Dank.


Wenn ich ein SRVPGM ändere, muss ich es aber nicht aus dem BNDDIR raus nehmen und wieder reinschreiben oder?

Danke & Gruß

[Fuerchau]

Aus dem BNDDIR darfst du keine Programme mehr rausnehmen, da sich sonst Bezüge verschieben.
Altlasten schleppt man so halt mit.

Die Fraktion die gegen BNDDIR's ist hat diese Probleme dann nicht.