-
Hallo,
wird CONST für einen Parameter angegeben, wird vom übergebenen Wert eine Kopie im Speicher gemacht. Diese Kopie wird als Referenz an das Programm übergeben. Es besteht demnach keine Referenz zur Variable des Aufrufers.
Dadurch kann als Parameter auch ein einfacher String statt einer Variable übergeben werden.
-
Bist du sicher, dass die Variable auch im aufrufenden Programm verändert wurde ?
Das wäre dann ein Bug (der allerdings bei RPGLE durchaus verständlich ist).
-
Wird CONST angegeben wird nur dann ein temporäres Feld gebildet, wenn die Definition des übergebenen Parameters nicht dem erwarteten Format entspricht oder wenn ein Ausdruck übergeben wurde. Stimmt die Parameter-Definition überein, wird die Adresse des Original-Feldes an das rufende Programm/Prozedur übergeben.
Da nie sicher ist, ob eine Referenz auf das Original-Feld oder ein temporäres Feld übergeben wird, dürfen Parameter-Felder, die mit CONST übergeben wurde im aufgerufenen Programm/Prozedur nicht geändert werden.
Wird ein solches Parameter-Feld (versehentlich) in dem aufgerufenen Programm/Prozedur geändert, tritt ein Compile-Fehler auf.
Auch wenn es möglich ist, die Entry-PList im Original-Programm zu belassen, sollte dennoch diese durch ein Procedure Interface ersetzt werden (und das Programm neu erstellt werden), um die Parameter-Prüfung, die das Prototyping ermöglicht zu integrieren.
Birgitta
-
Wobei das bei "alten" RPG oder gar CLP's wohl etwas schwierig wird.
Soviel dazu, dass CONST im rufenden Programm mal wieder nicht sicher ist.
Was nützt mir da die Compilerprüfung im gerufenen Programm.
Jetzt muss ich ja doch wieder Hilfsvariablen rummoven um mich vor Änderungen zu schützen.
Aus dem alten simplen
CALL 'MYPGM'
PARM SOURCE DEST
wird dann wieder
DEST = SOURCE;
MYPGM(DEST);
-
PHP-Code:
d NOP2 pr extpgm('NOP2')
d Kappes 10
*
d NOP2 pi
d Kappes 10
/free
Kappes = 'denkste';
return;
/end-free
*********************
PHP-Code:
d NOP2 pr extpgm('NOP2')
d Kappes 10 const
d noKappes s 10
d
*
/free
noKappes = 'kein Kappes';
NOP2(noKappes);
dsply noKappes;
return;
/end-free
******************
call tstnop2
=> 'denkste'
D*B
PS: RPG ist und bleibt ein Wackelhaufen, der Compiler glaubt schlicht was ein Programmierer im Prototyp behauptet und wenn man nix behauptet (*entry PLIST) glaubt er alles.
=> CONST im Prototyp beim aufrufenden Programm schützt davor, dass Änderungen zurück kommen und prüft sonst nix!
CONST im Prototyp des Procedure Interfaces des aufgerufenen Programmes prüft, dass man die Finger davon lässt!
-
Zitat von Fuerchau
Bist du sicher, dass die Variable auch im aufrufenden Programm verändert wurde ?
Das wäre dann ein Bug (der allerdings bei RPGLE durchaus verständlich ist).
Mit den beiden angehängten Programmen kann man es selbst testen. Selbst der Aufruf mit der Konstante führt zu keinem Fehler im aufrufenden Programm.
Ich stimme natürlich zu, dass ein Interface besser wäre. Bei neuen Programm handhaben wir das auch so. Das würde aber den Aufwand bei alten Programmen nicht rechtfertigen. Die Programme würden dann einfach weiterhin mit CALL aufgerufen werden.
Mal abgesehen von der Frage, ob die auf Interface umgestellten Programme dann aus den anderen alten Programmen mit CALL heraus noch korrekt aufgerufen werden können.
Generell sollte der Prototyp, zur Sicherheit, aber nur bei den Variablen CONST enthalten die im aufgerufenen Programm nicht verändert werden und auf gar keinen Fall bei Variablen die als Rückgabewert dienen sollen, damit diese Variablen nicht aus Versehen als Konstante übergeben werden können. Auch wenn es anders scheinbar auch funktioniert.
PHP-Code:
.
D VAR1 S 1
D VAR2 S 2
D VAR3 S 3
C *ENTRY Plist
C Parm VAR1
C Parm VAR2
C Parm VAR3
C Movel VAR1 VAR3
C Move VAR2 VAR3
C Eval *inlr = *on
PHP-Code:
.
H main(Main)
H DFTACTGRP(*NO)
H ACTGRP(*NEW)
DMain PR extpgm('TESTPGM')
DCALLPGM PR extpgm('TESTCALL')
D EXT_VAR1 1A const
D EXT_VAR2 2A const
D EXT_VAR3 3A const
PMain B
D PI
DVAR1 S 1A
DVAR2 S 2A
DVAR3 S 3A
/free
VAR1 = 'A';
VAR2 = 'BC';
VAR3 = 'XYZ';
CALLPGM(VAR1:VAR2:VAR3);
dsply (VAR1); //--> Ausgabe: A
dsply (VAR2); //--> Ausgabe: BC
dsply (VAR3); //--> Ausgabe: ABC
VAR1 = 'A';
VAR2 = 'BC';
VAR3 = 'XYZ';
CALLPGM(VAR1:VAR2:'XYZ');
dsply (VAR1); //--> Ausgabe: A
dsply (VAR2); //--> Ausgabe: BC
dsply (VAR3); //--> Ausgabe: XYZ
/end-free
P E
-
Zitat von Fuerchau
Wobei das bei "alten" RPG oder gar CLP's wohl etwas schwierig wird.
Soviel dazu, dass CONST im rufenden Programm mal wieder nicht sicher ist.
Was nützt mir da die Compilerprüfung im gerufenen Programm.
Jetzt muss ich ja doch wieder Hilfsvariablen rummoven um mich vor Änderungen zu schützen.
Aus dem alten simplen
CALL 'MYPGM'
PARM SOURCE DEST
wird dann wieder
DEST = SOURCE;
MYPGM(DEST);
Deshalb sollte man ja auch die Prototypen für alte Programme auch nicht mit irgendwas bestücken, das vorher auch nicht unterstützt war.
Die Rummoverrei musstest Du vorher auch machen!
Noch schlimmer wird's wenn in alten Programmen optionale Parameter verwendet wurden, die zudem nicht im aufgerufenen alten Programm abgeprüft wurden.
Birgitta
-
Ob dein Programm die Aufrufparameter über *ENTRY oder Interface definiert ist dem rufenden Programm letztlich egal da es sich hierbei ausschließlich um Compiler-Direktive handelt.
Wenn du dir per DSPPGM mal die Anzahl Parameter (Programmstatistik) ansiehst, so wirst du feststellen dass jedes Programm zwischen 0 und 255 Aufrufparameter hat selbst wenn du keine definiert hast.
Deshalb gibt es ja erst Laufzeitfehler nach dem Aufruf eines Programmes. Die Anzahl Parameter kannst du mit %parms() abfragen und ob ein Parameter besetzt ist mit %addr(Parm) = *NULL.
Beim CLP wird die Anzahl der Parameter festvorgegeben, weshalb es da ggf. beim Aufruf schon den Parameterfehler gibt.
Eine Mischung zwischen ILE- und OPM-Calls ist daher jederzeit möglich.
Similar Threads
-
By steven_r in forum NEWSboard Programmierung
Antworten: 7
Letzter Beitrag: 01-07-08, 15:33
-
By dino in forum IBM i Hauptforum
Antworten: 3
Letzter Beitrag: 17-01-07, 09:23
-
By hh-mi in forum IBM i Hauptforum
Antworten: 5
Letzter Beitrag: 15-11-06, 12:23
-
By edig in forum NEWSboard Programmierung
Antworten: 10
Letzter Beitrag: 14-07-06, 15:48
-
By jajonowak in forum NEWSboard Programmierung
Antworten: 2
Letzter Beitrag: 12-06-06, 13:55
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks