CALL-Programme als CALLP

[Ottersberg]

Ah okay.

Sprich Interface und Prototyp erstellen, damit diese aus den Free-Programmen verwendet werden können.
Das Interface wiederum ruft dann das alte Programm auf.

Korrekt?

[mk]

Hallo,
hier ein kleines Beispiel:

DPGMR2          PR                  EXTPGM('XXXXXR2')   
D Mode                                CONST LIKE(ParmSel) 
D Season                              CONST LIKE(SLSSEA) 

Callp Aufruf

CALLP     PGMR2(02   :aSaison) 

Gruß
Michael

[Fuerchau]

Ein Prototyp wird im rufenden Programm definiert, das Interface im gerufenen Programm (ersetzt den *ENTRY).

[Ottersberg]

Moin,

DPGMR2          PR                  EXTPGM('XXXXXR2')   
D Mode                                CONST LIKE(ParmSel) 
D Season                              CONST LIKE(SLSSEA) 

Callp Aufruf

CALLP     PGMR2(02   :aSaison) 

da haben wir wieder einen typischen Fall von zu kompliziert gedacht. So einfach ist das also.

Ein Prototyp wird im rufenden Programm definiert, das Interface im gerufenen Programm (ersetzt den *ENTRY).

Aber das gerufene Programm muss kein Interface haben oder? So wie das Beispiel von mk.
Habe ich selbst gerade ausprobiert und es ging ohne. Es gab sogar die Rückgabe.

Gruß

[Fuerchau]

Ein Interface ersetzt den *ENTRY!

Achtung bei der Parameterdefinition.
CONST bedeutet, dass der Compiler zusätzlichen Code generiert um die Übergabe zuerst in interne Variablen zu kopieren und dann zu übergeben.
Solltest du Antwort in einem Parameter erwarten, darfst du CONST nicht verwenden, da du ja an die interne Kopie nicht drankommst.

CONST ist dann sinnvoll, wenn man als Parameter eine feste Definition hat aber mit variablen Parametern ohne vorherigen Move/Eval arbeiten möchte oder verhindern möchte, dass das gerufene Programm meine Parameter verändert.

[Ottersberg]

Ein Interface ersetzt den *ENTRY!

Ja das habe ich verstanden. Die Frage ist: Muss ich den *ENTRY ersetzen oder kann ich es?
Bei dem Test den ich gemacht habe, wird ein altes Programm, welche *ENTRY beinhaltet, aufgerufen und es hat funktioniert. Daher würde ich sagen, ich muss *ENTRY nicht durch ein Interface ersetzen.

Achtung bei der Parameterdefinition.
CONST bedeutet, dass der Compiler zusätzlichen Code generiert um die Übergabe zuerst in interne Variablen zu kopieren und dann zu übergeben.
Solltest du Antwort in einem Parameter erwarten, darfst du CONST nicht verwenden, da du ja an die interne Kopie nicht drankommst.

CONST ist dann sinnvoll, wenn man als Parameter eine feste Definition hat aber mit variablen Parametern ohne vorherigen Move/Eval arbeiten möchte oder verhindern möchte, dass das gerufene Programm meine Parameter verändert.

Das hatte ich auch so gedacht. So kannte ich CONST bislang.
Testweise habe ich versucht das alte Programm mit einer Prozedur ohne CONST und einer Prozedur mit CONST aufzurufen. Es kommt in beiden Fällen allerdings dasselbe dabei heraus.

Kann es sein, dass CONST nur das ändern der Parameter verhindert, wenn es im Interface verwendet wird?
Und wird es im Prototypen verwendet bedeutet es lediglich, dass Parameter durch Referenz übergeben werden dürfen? (Siehe Beispiel mk)

[Fuerchau]

Parameter an externe Programme können immer nur als Referenz übergeben werden, Value funktioniert nur bei Prozeduren und Funktionen.

Const verhindert nicht das verändern der Parameter im gerufenen Programm sondern gibt die Veränderung nicht zurück.

Interface und *ENTRY sind nur unterschiedliche Compiler-Directiven, zur Laufzeit gibts da keinen Unterschied.

[Ottersberg]

Okay. Das hab ich soweit. Danke erstmal dafür.

Const verhindert nicht das verändern der Parameter im gerufenen Programm sondern gibt die Veränderung nicht zurück.

Dazu aber noch eine Frage.

Folgendes Beispiel:

     DPGM1             PR                  extpgm('PGM1')
     D EXT_VAR1                       1A   const
     D EXT_VAR2                       2A   const
     D EXT_VAR3                       3A   const

     D  VAR1           S              1A
     D  VAR2           S              2A
     D  VAR3           S              3A

       VAR3 = 'XYZ';
       PGM1(VAR1:VAR2:VAR3); 

PGM1 kann VAR3 jetzt zwar auf 'ABC' ändern, es kommt aber nicht zurück, sondern es steht weiterhin 'XYZ' drin?

Ich habe das mit einem Programm mit *ENTRY getestet und der Wert wird verändert, obwohl die Variable im Prototyp auf CONST steht.

Es macht natürlich keinen Sinn den Wert der sich verändern soll als Konstante (im Beispiel: PGM1(VAR1:VAR2:'XYZ')) zu übergeben. Dann kann die Veränderung ja in keine Variable geschrieben werden.

[andreaspr@aon.at]

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.

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

[Ottersberg]

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.

.
     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 

.
     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 

[B.Hauser]

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