SRVPGM

[philsturm]

Hallo zusammen,

ich habe folgendes Problem:
Ich habe ein Serviceprogramm mit diversen Prozeduren erstellt. Dieses habe ich über ein Binderverzeichnis in mehrere Programm "eingebaut". Soweit, so gut.
Damit ich beim Hinzufügen neuer Prozeduren keinen LevelCheck-Fehler bekomme, habe ich eine Binder-Language-Datei mit fester Signatur aufgebaut.
Bis hierhin funktioniert alles.

Wenn ich jetzt aber eine Prozedur aus dem Serviceprogramm lösche (und auch aus dem Binder-Language-Programm) und aus meinem aufrufenden Programm andere, noch existierende, Prozeduren aus dem SRVPGM ansprechen möchte, werden falsche Prozeduren aufgerufen.

Ich werde das Gefühl nicht los, dass das mit der Signatur zusammenhängt. Bin aber auch nicht soooo firm in der Signaturgeschichte.

Vllt. kann mich da jemand aufklären. Schon jetzt: DANKE!

[Fuerchau]

Fatal, Fatal!
Wenn du mit einem Binder-Verzeichnis arbeitest und eine eigene Signatur verwendest darfst du folgendes nicht mehr tun:
- Exporte entfernen
- Parameter eines Aufrufes vom Typ und Folge verändern
- Exporte einsortieren

Der Hintergrund ist ganz einfach:
Durch das Binderverzeichnis legst du die Reihenfolge der Aufrufe genau fest.
Diese werden dann von 1 bis N durchnummeriert.

Erstellst du nun ein Programm mit dem Aufruf des Service-Programmes, wird die Positionsnummer der Funktion im Programm vermerkt und später genau mit dieser aufgerufen.
Entfernst du nun eine Funktion wird über den gemerkten Einstiegspunkt die falsche Funktion aufgerufen.

Wenn du sowas machst, erzwingt dies ebenso eine Neuerstellung aller Programme wie bei Nichtverwendung eines Binderverzeichisses.

Bei dir ist genau das eingetreten, vor dem D*B immer gewarnt hat.
Wenn man mit der Konzeption einer Binderlanguage absolut nicht vertraut ist, handelt man sich eben massive Probleme ein.

[mihael]

Fatal, Fatal!
Wenn du mit einem Binder-Verzeichnis arbeitest und eine eigene Signatur verwendest darfst du folgendes nicht mehr tun:
- Exporte entfernen
- Parameter eines Aufrufes vom Typ und Folge verändern
- Exporte einsortieren

Das ist so nicht ganz richtig. Richtig wäre das Zitat bei einer eigenen fixen Signatur. Denn dann hat man nicht mehr die Möglichkeit zu sagen: Diese neue Version des Serviceprogramms ist nicht kompatibel mit der alten. Wenn man selber Signaturen (nicht fixe) pflegt ist dieses nämlich durchaus möglich.

Man pflegt für jede Version eine neue Signatur hinzu. Das heisst, man hat irgendwann auch mehrere Signaturen für ein Serviceprogramm. Das heisst, dass ein Programm mit einem Serviceprogramm gebunden werden muss, welches einer der Signaturen hat (egal welche).

Wenn man nun eines der "verbotenen" Dinge tut (wie Exporte umsortieren oder herauslöschen), dann erklärt man einfach alle alten und inkompatiblen Signaturen für ungültig indem man sie aus der Binder Source entfernt und fügt eine neue Signatur ein. Nun wird beim Starten des Programms schon darauf hingewiesen, dass die Signatur nicht passt und es passiert auch nix unvorhergesehenes (wie der Aufruf der verkehrten Prozedur aufgrund der geänderten Reihenfolge).

Das verwenden von Binder Source und eigenen Signaturen erschliessen einem viele Möglichkeiten. Allerdings erfordert es auch viel Aufmerksamkeit und Fingerspitzengefühl.

Gruss

Mihael

[Fuerchau]

Lies oben noch mal nach:

Damit ich beim Hinzufügen neuer Prozeduren keinen LevelCheck-Fehler bekomme, habe ich eine Binder-Language-Datei mit fester Signatur aufgebaut.

Eigentlich will ich mir ja das Recompile der vielen Programme mit BNDDIR schenken.
Dann darf sich schon die Idee des Entfernens einer Funktion nicht einschleichen sonst handelt man sich eben die Risiken ein.
Besser wäre es, die "veraltete" Funktion mit einer ESC-Message abzubrechen oder die neue Funktion aufzurufen. Dann funktioniert die Alte eben als Wrapper.

Allein der Aufwand mit mehreren Signaturen wäre mir schon zu hoch.
D*B's Lösungsansatz die Umwandlungsoptionen in die Quelle einzubetten und auszulesen ist die sicherste überhaupt.
Allerdings erfordert das bei geänderten Signaturen ein Recompile aller betroffener Programme. Als Softwarehersteller bekomme ich ggf. beim Verteilen von Patches ein Problem, aber heutzutage wird ja doch meistens komplett upgedated.

Und ob verschiedene Signaturen für ein Serviceprogramm mit geänderter Exportfolge funktioniert sollte man besser überprüfen. So richtig glauben kann ich das nicht, dass im Programmobjekt selber je Signatur eine eigene Verweistabelle gepflegt wird.

[mihael]

Eigentlich will ich mir ja das Recompile der vielen Programme mit BNDDIR schenken.

Was hat ein Bindeverzeichnis damit zu tun, ob ich ein Programm rekompilieren muss oder nicht?! Ein Bindeverzeichnis hilft ausschliesslich dabei Exporte aufzulösen.

...
D*B's Lösungsansatz die Umwandlungsoptionen in die Quelle einzubetten und auszulesen ist die sicherste überhaupt.
...
Meiner Meinung nach ist das mit der schlechteste Ansatz, da sich die Umwandlungsoptionen von Umgebung zu Umgebung (Maschine zu Maschine) ändern können. Umwandlungsoptionen sollten immer extern sein.

...
Und ob verschiedene Signaturen für ein Serviceprogramm mit geänderter Exportfolge funktioniert sollte man besser überprüfen. So richtig glauben kann ich das nicht, dass im Programmobjekt selber je Signatur eine eigene Verweistabelle gepflegt wird.
...
Nein, ich auch nicht. Und das habe ich auch nicht behauptet.

Wenn eine Prozedur/Export entfernt wird, muss man davon ausgehen, dass alle Programme, die das Serviceprogramm benutzen, neu gebunden werden müssen, damit nicht eine andere Prozedur (aufgrund der Exportreihenfolge) aufgerufen wird. Es werden alle anderen Signaturen aus der Binder Source entfernt und eine neue eingefügt.

SRVPGM 1.2.0 löschen
SRVPGM 1.1.2 löschen
SRVPGM 1.1.1 löschen
SRVPGM 1.1.0 löschen
...
SRVPGM 2.0.0 neu

Also bleibt eine Signatur übrig und alle bisher gebundenen Programme fliegen frühzeitig auf die Nase.

Die Vorgehensweise mit einer fixen Prozedur mag funktionieren, wenn man die Umgebung/Kunden kennt, ist aber äusserst unpraktikabel, wenn man die Umgebung nicht kennt, z. B. in der Open Source Welt.

Meine 2 Cent.

Mihael

[Fuerchau]

D*B's Lösungsansatz die Umwandlungsoptionen in die Quelle einzubetten und auszulesen ist die sicherste überhaupt.
...
Meiner Meinung nach ist das mit der schlechteste Ansatz, da sich die Umwandlungsoptionen von Umgebung zu Umgebung (Maschine zu Maschine) ändern können. Umwandlungsoptionen sollten immer extern sein.

D*B's Software, die dafür nötig ist, kann ich auf jedem System installieren wo ich es brauche, das wäre nicht so der Akt.

Pflege ich die benötigten Serviceprogramme in der Quelle hat das den Vorteil gleichzeitig eine Dokumentation zu haben und die Sicherheit, dass beim Erstellen nichts fehlt.
Zusätzlich kann ich Automatismen wählen (Suchen+Ausführen) wenn sich ein Serviceprogramm tatsächlich mal ändert.
Die meisten Prototypen definiere ich ja normalerweise in Copy/Includes, so dass mir Suchen+Ausführen bei deiner Methode überhaupt nicht hilft, da ggf. auch die Aufrufe in Copy/Includes eingebettet sein können.

Aber was solls, vernünftige Tools, die Verwendungen u.ä. verwalten und automatisierte Massenumwandlungen vornehmen können, sollte ich ja sowieso einsetzen.
Und ggf. auch meine Kunden, falls ich Quellen mit ausliefere, zu diesem System zwingen.

[BenderD]

Ich werde das Gefühl nicht los, dass das mit der Signatur zusammenhängt. Bin aber auch nicht soooo firm in der Signaturgeschichte.

... und warum spielst Du dann mit Signaturen rum? Mögen sich alle diejenigen, die diese Spielereien empfehlen, an die Nase fassen und sich Asche aufs Haupt streuen...

D*B
PS: auch in diesem Thread wird schon wieder mal aller mögliche Unfug von ratgebemdem Experten erzälhlt, über Binding directories... und dass man auf unetrschiedlichen Systemen verschieden umwandeln soll... - ich habe keinen Bock mehr darauf zu antworten...

[B.Hauser]

Das Service-Programm wird über den fixen Signatur-Namen gefunden.
Die Prozeduren werden in der Reihenfolge, in der sie in der Bindersprache eingetragen sind zugewiesen, d.h. 1. Prozedur = 1, 2. = 2 etc.
Wenn Du eine Prozedur löscht, oder die Reihenfolge der Prozeduren in der Binder-Sprache ändererst, bekommst Du genau Dein Problem, d.h. anstatt der richtigen Prozedur, die zuvor an Position 3 gestanden ist, wird jetzt eine andere Prozedur, die jetzt an Position 3 steht aufgerufen.
Das hat an dieser Stelle weder etwas mit dem Binder-Verzeichnis noch der Signatur zu tun, sondern einzig und allein mit der Reihenfolge der Prozeduren in der Binder-Sprache.

... übringens haben hier einige nicht verstandan wofür Binder-Verzeichnisse gut sind.
Binder-Verzeichnisse werden zur Compile-Zeit (bzw. im Binder-Schritt) verwendet um die Service-Programme (oder Module) zu lokalisieren, in denen sich die aufgerufenen Prozeduren befineden. Sofern die Service-Programme bzw. Module gefunden wurden, werden entweder die Signatur (Service-Programm) bzw. das Modul selber in das Programm oder Service-Programm eingebunden.

Man kann natürlich auch alles immer schön zu Fuß auflisten, was bei vielen Prozeduren in vielen Service-Programmen ganz schön aufwändig wird.

Birgitta

[Fuerchau]

... übringens haben hier einige nicht verstandan wofür Binder-Verzeichnisse gut sind.

Damit kannst du sicherlich nicht D*B oder mich gemeint haben...

Nun, Dieters Lösung finde ich auch nicht aufwändiger als die anderen, denn ich brauche ja nur die neuen benötigten Serviceprogramme ergänzen. Das halte ich für einen geringen Aufwand.
Außerdem gehört bei einer vernünftigen Dokumentation dazu, den betroffenen Programmnamen in die Includes/Copies zu schreiben so dass ich bei der erstmaligen Verwendung eines SRVPGM's dieses nur aufnehmen muss.
Wo ist da der Aufwand?

Man kann Binderverzeichnisse komplex oder simpel halten.
Am simpelsten sind doch z.B. QC2LE, QILE, QRNXLE...
Diese funktionieren seit Anbeginn der Erfindung von ILE ohne jemalige Neukompilierung der betroffenen Programme.
Die Signatur ändert sich nie, die Reihenfolge der Exporte bleibt gleich.
Neue Funktionen werden am Ende angehängt und alte Funktionen werden als "veraltet" ausgewiesen, so einfach kann es gehen.