CEEDOD im Hauptprogramm

[XMan]

@BenderD

das ist mir bewusst das dieser "Müll" benötigt wird!
Siehe 2. Posting von mir "...der Rest des Parameters nur "Müll" enthält (wobei der Müll ja vom System benötigt wird)..."

Ich bezeichne in deshalb als "Müll" (auch bewusst unter Anführungszeichen geschrieben) weil ich im Pgm damit nichts anfangen kann wenn das im Parameter steht!


LG

[Fuerchau]

Dies deutet wie immer darauf hin, dass Aufrufkonventionen nicht eingehalten wurden.
Dies wird ja auch (in vereinfachter Form) durch die Prototyp- und Interfacedefinitionen (leider nur zur Compile-Zeit) einigermaßen geprüft.

[Anton Gombkötö]

XMan will hier den ersten Parameter übergeben, wie er möchte (was kein Problem ist) UND er möchte herausfinden, wie groß die Variable im aufrufenden Programm ist (das ist das Problem). Wozu auch immer er das brauchen mag, das wissen wir leider nicht.

Und er hat das Problem auf genau die gleiche Weise wie die IBM selber bei z.B. QCMDEXC gelöst.

"Schöner" wäre natürlich irgendeine einfache Funktion in RPG selber, die einem die Infos liefert. Aber die gibt's halt leider (noch) nicht.

[Fuerchau]

Jede offen definierte Schnittstelle ist immer mit einer "Aufrufkonvention" festgelegt sonst funktioniert diese eben nicht.
Diese Diskussion haben wir hier schon des öfteren geführt.
Hält man die Schnittstelle nicht ein, gibts halt Fehler um die Ohren (MCH-, CPF-).

Dies gilt auch für objektorientierte Sprachen wie Java/.NET und etwas eingeschränkt auch für C++.
Während in Java und .Net die Schnittstellendefinition im Objekt mit abgelegt wird und somit zur Laufzeit die Prüfung erfolgt (und mittels "Reflection" auch dynamisch verwendet werden kann).

In den HLL-Sprachen RPG/COBOL werden per Definition Pointer übergeben.
Die PR/PI-Definitionen helfen da leider nur zur Compilezeit, zur Laufzeit erfolgt keine Prüfung mehr.
Dies geht sogar soweit, dass gebundene Serviceprogramme nicht mehr über den Namen der Procedur aufgerufen werden sondern über die laufende Nummer der exportierten Funktion.
Verwendet man keine BindaryLanguage, wo man das Verhalten besser beeinflussen kann, sortiert der Compiler die Exporte alphabetisch und generiert eine Hash-Signatur für das gesamte Objekt, diese Signatur wird beim Binden übernommen.
So wird zur Laufzeit der Aufruf des Serviceprogrammes verhindert, wenn die Signatur nicht passt.
Mit BindaryLanguage vergibt man ein eigene Signatur und legt die Reihenfolge der Exporte selber fest.
Neue Funktionen werden dann immer am Ende (in der BindaryLanguage, im Modul ist das egal) hinzugefügt, so dass bestehende Programme über den Index des Exportes die korrekte Prozedur aufrufen.
Fügt man eine neue Funktion irgendwo mitten drin hinzu ohne die Signatur zu ändern, werden von den Programmen sogar die falschen Funktionen aufgerufen.
Eine Laufzeitprüfung erfolgt nicht!

Also wann immer man Parameter für eine Schnittstelle festlegt, sollte man diese "Aufrufkonvention" als Copy zur Compilezeit zur Verfügung stellen und in ILE reduziert man somit die Probleme.

Es regt sich ja auch keiner darüber auf, dass die tausenden von API's über feste Parameter verfügen und bei Nichteinhaltung das API eben nicht funktioniert.

[Anton Gombkötö]

... des Ist-Zustandes.

Es wäre aber für die IBM kein Problem, Meta-Informationen über jeden Parameter vor dem Call irgendwo zu merken und bei Bedarf (eben über eine neue Funktion) dem aufgerufenen Programm zur Verfügung zu stellen.

Ebenso sollten vor dem Call die Parameterdefinitionen eingesehen werden, um z.B. ein anderes "Mirakel" zu lösen, z.B. ein Call von der Commandline mit einem String, der kürzer als 32 Bytes ist an eine Variable, die länger als 32 Bytes ist. Oder korrekte numerische Übergabe und nicht stur gepackt 15/5.

Default sollte das Einhalten der Konventionen sein mit Fehlermeldung wenn die Parameter nicht passen, aber wenn ich weiß, was ich tue, wie in diesem Beispiel XMan, sollte ich mit Variablen jeder Länge (und vielleicht sogar Art) umgehen können. (Aber erfahren können, was und wie groß es ist.)
Sicher kann man das mit Pointern und einer Hilfsvariablen lösen, aber wie gesagt, es ginge "schöner".

[Fuerchau]

Dann sollte man die Sprache wechseln .
Immerhin muss man ja auch an den großen "Altbestand" denken.

Mit den OPDESC hast du doch alles in der Hand.
Allerdings nur zwischen Prozeduren.
Wenn man denn alles "schön" machen will, kannst du Schnittstellen nur als Serviceprozeduren mit OPDESC erstellen, das verhindert eben den Aufruf aus der Kommandozeile .

[Anton Gombkötö]

Du hast natürlich völlig recht, aber ich träume ja von einer ins ganze System integrierten Lösung. :-)
Ich bin der, der an jedem kleinen Finger zerrt... ;-)

[BenderD]

Dann sollte man die Sprache wechseln .
Immerhin muss man ja auch an den großen "Altbestand" denken.

Mit den OPDESC hast du doch alles in der Hand.
Allerdings nur zwischen Prozeduren.
Wenn man denn alles "schön" machen will, kannst du Schnittstellen nur als Serviceprozeduren mit OPDESC erstellen, das verhindert eben den Aufruf aus der Kommandozeile .

... das verhindert nicht nur Aufrufe aus der Kommandozeile, sondern auch Aufrufe aus SQL.

... wenn ich denn mal gerade am aufräumen von Mythen bin:
- SQL macht schon schlapp bei Übergabe als VALUE
- das bei manchen so beliebte CONST ist nur ein halbherziger Versuch, der bei der Weitergabe von CONST Parametern per Reference weinend zusammenbricht
- Java lässt sich da nicht austricksen, da weiß jeder Pointer auf was er zeigt (das wäre auch die elegantere Lösung für den OS/400 rwrite bei CISC->RISC gewesen, aber da waren RPG Huddeler am Werk)

D*B

PS: bei korrekter Verwemdung von VARCHAR braucht man keinen extra Parameter, eine VARCHAR weiß selber wie lange sie ist; ansonsten hätte man auch Null terminated Strings nehmen können, die man aus der main in eine echte procedure per Reference weitergibt (müsste eigentlich auch bei OPDESC gehen?!)