SRVPGM

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