Zitat Zitat von B.Hauser Beitrag anzeigen
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