Fehler ILERPG Runtime mit CONST-Parametern

[dschroeder]

Ich möchte mich auch mal kurz einmischen. Nach meinem Kenntnisstand ist const eine Übergabe per Referenz, also keine Kopie. Der Compiler verspricht nur, darauf aufzupassen, dass es keine Anweisungen gibt, die den Wert ändern.

Ich habe mich allerdings schon immer gefragt, wie bestimmte Konvertierungen funktionieren. Wenn ich einen Parameter als z.B. als varucs2 const deklariere, kann ich beim Aufruf problemlos einen normalen char-Wert übergeben. Irgendwie widerspricht das in meinen Augen dem Call by Reference. Der Wert, auf den der varucs2-Wert zeigt, ist ja nicht wirklich ein varucs2, sondern ein char. Aber es klappt.

Dass const grundsätzlich eine Übergabe per Referenz ist, habe ich aber bereits (leidvoll) erfahren müssen, als ich folgende seltsame Problematik in einem PGM gefunden habe:

1. Im PGM wurde eine Variable X global deklariert
2. X wurde an eine Procedure per Parameter übergeben und unter dem Namen Y const empfangen (Ich weiß, dass war unnötig, denn X war ja global)
3. Innerhalb der Procedure wurden keine Änderung an Y durchgeführt. Geht ja auch nicht, denn Y wurde ja const empfangen.
4. Im weiteren Verlauf wurde innerhalb der Procedure jedoch die globale Variable X verändert. Und damit war sofort auch Y verändert. Damit hatte man nicht gerechnet, da Y ja const war. Aber (ich denke wegen des call by reference) wurde sofort Y wertmäßig zu X

Aber vielleicht weiß ja jemand, wie die Konvertierung zwischen den Datentype klappt, auch wenn const ein "call by reference" ist.

Gruß,
Dieter

[B.Hauser]

Aber vielleicht weiß ja jemand, wie die Konvertierung zwischen den Datentype klappt, auch wenn const ein "call by reference" ist.

Gruß,
Dieter

Wenn ein Parameter mit CONST definiert wurde, wird die Adresse des Original-Feldes an die aufgerufene Prozedur übergeben, sofern Datentyp und Länge mit der Parameter-Definition übereinstimmen.

Bei abweichender Länge bzw. compatiblem Datentypen, wird ein Hilfs-Feld im erwarteten Format mit der entsprechenden Länge generiert und mit den Parameter-Daten aktualisiert. Anschließend wird dann die Adresse des Hilfsfeldes an die aufgerufene Prozedur übergeben.

Da nie sicher ist, ob es sich bei dem übergebenen Pointer um die Adresse des Original-Feldes oder des generierten Hilfsfeldes handelt, dürfen die übergebenen Daten in der aufgerufenen Prozedur nicht geändert werden.

In Baldurs Fall wird 2x die Adresse des Original-Feldes (einmal als Parameter und einmal als Datenstruktur-Unterfeld) übergeben. Da die Datenstruktur via Reference übergeben wurde, ist das Unterfeld nicht vor Überschreibung geschützt. Damit kann das Datenstruktur-Unterfeld geändert werden. Da jedoch bei dem Parameter, der mit CONST übergeben wurde die gleiche Adresse übergeben wurde, kann der Wert trotzt CONST geändert werden.
Bei VALUE hingegen wird immer ein Duplikat des Feldes erzeugt und dieses an die Prozedur übergeben.

M.E. ist das kein Bug, sondern eine bescheidene Programmierung.
Falls in einem solchen Fall in Zukunft ein Compile-Fehler auftreten sollte, würde ich empfehlen einen RFE (Recall for Enhancement) bei der IBM zu eröffnen.

Birgitta

[dschroeder]

Vielen Dank Birgitta und auch von mir noch herzlichen Glückwunsch zum IBM-Champion !

Das heißt, dass ein const nur bei komplett gleichem Datentyp ein "call by reference" ist und wenn es abweichend ist, dann ist es ein "call by value" ?

Dieter

[B.Hauser]

Nicht ganz:
Bei call by VALUE wird nicht die Adresse sondern das ganze Feld an die rufende Prozedur übergeben.
Bei constant Reference wird immer eine Adresse weitergegeben, je nachdem die Adresse des Original-Feldes oder des Hilfs-Feldes

Birgitta

[Fuerchau]

Nun habe ich (leider) erwartet, dass CONST eben grundsätzlich eine Kopie erstellt. Dann träte dieses Problem ja erst gar nicht auf.

[B.Hauser]

Nun habe ich (leider) erwartet, dass CONST eben grundsätzlich eine Kopie erstellt. Dann träte dieses Problem ja erst gar nicht auf.

Dann wär's nicht besser als VALUES, bei dem immer eine Kopie erstellt wird.

[dschroeder]

Nicht ganz:
Bei call by VALUE wird nicht die Adresse sondern das ganze Feld an die rufende Prozedur übergeben.
Bei constant Reference wird immer eine Adresse weitergegeben, je nachdem die Adresse des Original-Feldes oder des Hilfs-Feldes

Aber wenn die Adresse eines Hilfsfeldes übergeben wird, ist es doch ein call per Value, oder? Es muss doch erstmal eine Hilfskopie des Originalfeldes erstellt werden, denke ich.

Deshalb habe ich das jetzt alles so verstanden: bei VALUES wird immer eine Kopie erstellt, bei CONST nur manchmal.
Ist das korrekt?

[BenderD]

Aber wenn die Adresse eines Hilfsfeldes übergeben wird, ist es doch ein call per Value, oder? Es muss doch erstmal eine Hilfskopie des Originalfeldes erstellt werden, denke ich.

Deshalb habe ich das jetzt alles so verstanden: bei VALUES wird immer eine Kopie erstellt, bei CONST nur manchmal.
Ist das korrekt?

... der Unterschied liegt im Adressraum:
- const gehört zum Aufrufer (der Aufgerufene kann also immer noch im aufrufenden Programm rummmurgeln)
- value gehört zum Aufgerufenen (d.h. das geht nur, wenn beide das können, was bei externen stored Procdures nicht der Fall ist)

Was lernen wir daraus: eigentlich beides Murks (RPG halt).

D*B

[dschroeder]

Danke für alle Infos.

[Fuerchau]

Ist eine Variable mit CONST definiert, prüft nur der Compiler, ob eine Änderung versucht wird.
Das geht sogar, wen man versucht per %ADDR eine Variable per Pointer zu definieren.
Der Compiler lehnt dies bereits ab!

Da man Const aber auch beim Aufruf von z.B. CLP's oder COBOL verwenden kann, diese jedoch CONST gar nicht kennen, ist hierrüber trotzdem eine Änderung möglich.
Konzeptionell ist CONST also nicht sicher, da bei identischer Definition eben die Adresse direkt übergeben wird!