[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    Feb 2006
    Beiträge
    78

    Parameterprüfung CL-Pgm

    Hallo Forum,

    bin im CL nicht so bewandert.

    Gibt es eine einfache Möglichkeit im CL Programm zu prüfen ob ein Parameter an das Programm übergeben wurde oder nicht?
    Also ich möchte prüfen ob mir der Parameter übergeben wurde, wenn dieser nicht übergeben wurde dann mach ich im CL Programm einen anderen Ablauf.
    Hier geht es darum ob z.B. Parameter 11 übergeben wurde oder nicht (ist der letzte Parameter für das CL)

    Vielen Dank!

  2. #2
    Registriert seit
    Nov 2003
    Beiträge
    2.307
    Das Zauberwort heißt MCH3601 - beim Zugriff auf einen Parameter, der nicht übergeben wurde. Außerdem muß es ein ILE-CL-Programm sein, damit ein fehlender Parameter nicht bereits beim Aufruf einen Fehler verursacht.

    Nachtrag: Hoppla, alles wohl doch nicht ganz so einfach.

  3. #3
    Registriert seit
    Feb 2006
    Beiträge
    78
    Danke für die Antwort.

    Habe mich nun ein wenig damit "gespielt" und folgendes probiert:
    Das scheint zu funktionieren:

    DCL VAR(&In_Parm) TYPE(*CHAR) LEN(10)
    DCL VAR(&Work_Parm) TYPE(*CHAR) LEN(10)
    DCL VAR(&nullptr) TYPE(*PTR)

    IF COND(%ADDR(&In_Parm) *NE &NULLPTR) THEN(DO)
    chgvar var(&Work_Parm) value(&In_Parm)
    enddo


    CALL PGM(PGM01) PARM(&Work_Parm)

    Ich prüfe da einfach mit hilfe von %ADDR ab ob der Input-Parm eine Adresse enthält.
    Ist das ein gangbarer Weg?

    LG

  4. #4
    Registriert seit
    Feb 2001
    Beiträge
    20.241
    Wenn du dem "Hoppla"-link folgst, siehst du dass das auch nicht funktioniert.
    Es können wohl noch Reste im Stack rumliegen.
    Solange es in CLP keine Möglichkeit gibt, die Anzahl der Parameter abzufragen solltest du die vorgeschlagene Wrapperfunktion in ILERPG verwenden.

    Man kann auch ein CLP mit den Parametern machen, dann gibts schon beim Aufruf einen Parameterfehler und dann per TFRCTL das eigentliche CLLE-Programm starten.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  5. #5
    Registriert seit
    Feb 2006
    Beiträge
    78
    Hallo Fuerchau,

    den Link habe ich mir schon angesehen.
    Allerdings ist, soweit ich das sehen konnte, diese Info vom Jahr 2004.

    Ich rufe mein CL Programm nicht mit einem RPGLE auf sondern auch mit einem CL Programm.
    Sprich CL1 ruft CL2 auf und im CL2 wird diese Prüfung gemacht.
    Ich habe mir das mit den Parametern angesehen und es auch getestet.

    Rufe im CL1 das CL2 im 1. Lauf mit 10 Parametern auf, gleich darauf mit 11 Parms, danach gleich wieder mit 10 Parms. Also CL1 wird zwischendurch nicht geschlossen.
    Es äußert sich so als ob beim 3. Aufruf der 11 Parm gar nicht vorhanden wäre und somit meine Prüfung korrekt abgehandelt wird.
    Ich konnte hier keine falschen Werte bzw. noch gefüllte Parameter feststellen.

    Bekomme beim 3. Lauf dann wiederrum (im Debug) die Fehlermeldung "Domänenverletzung" wenn ich den Feldinhalt ansehen will.

    Ob dies mit dem RPGLE auch so funzt weiß ich noch nicht. Werde ich ggf. mal testen.
    Hier dürfte die V7 dies dann doch schon besser händeln.

    Greats

  6. #6
    Registriert seit
    Feb 2001
    Beiträge
    20.241
    Domänenverletzung deutet ja auf einen stehen gebliebenen Pointer hin, der halt (meistens) der Systemdomäne gehört an die ein User-Programm (der Normalfall) eben nicht dran darf.
    Ansonsten käme ein InvalidPointer.

    Das ist ja genau das Problem mit variablen Aufruflisten wenn man die Anzahl der Parameter nicht abfragt bzw. halt nicht abfragen kann.
    In ILERPG kann ich das num mal mit %parms() sicherstellen.
    Parameter, die zwischendrin fehlen dürfen, benötigen dann einen NULL-Pointer.

    In CLLE würde ich mich auf solche Spielchen nicht einlassen.
    Wenn du unbedingt variable Aufrufparameter haben musst, ggf. auch als Returnwert, dann empfehle ich die Entwicklung eines CMD's.
    Optionale Parameter bekommen einen Default, nicht angegebene optionale Returnwerte bekommen einen NULL-Pointer.
    Die Anzahl der Parameter ist immer identisch und man kann sich darauf verlassen.
    Man kann jederzeit das Kommando und das CLLE anpassen ohne dass andere Programme ggf. von zusätzlich Parametern etwas merken.

    Deine Methodik mit MONMSG/%ADDR ist dafür prädestiniert, Fehler zu generieren die dann kein Mensch mehr findet.
    Außerdem handelst du dir ja auch noch Typfehler ein, da ein CLP/CLLE immer mit Call-By-Reference aufgerufen wird. Call-By-Value (ILERPG/COBOL/C) gibt es dafür nicht.
    Die Probleme mit den falschen Längen bei den Aufrufen sind ja nun mal hinreichend bekannt.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  7. #7
    Registriert seit
    Feb 2006
    Beiträge
    78
    Guten Morgen Fuerchau,

    Danke für die Aufklärung!
    Nun ist mir einiges klarer.

    Thx

  8. #8
    Registriert seit
    Mar 2002
    Beiträge
    5.287
    ... was ich da lese, wenn ich dem link folge, da schüttelts mich (give me a bucket). Da gibt es doch nur eine Konsequenz: ändere in CL/RPG niemals (in Worten: niemals!) eine Parameterschnittstelle. Verwende immer einen neuen Namen für die neue Schnittstelle!!!

    @OP: 11 Parameter, das ist auch jetzt schon jenseits von Gut und Böse, da blickt doch schon keiner mehr durch, was da was ist, ohne sich die aufgerufene Funktion genau anzusehen.
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  9. #9
    Registriert seit
    Feb 2006
    Beiträge
    78
    Zitat Zitat von BenderD Beitrag anzeigen

    @OP: 11 Parameter, das ist auch jetzt schon jenseits von Gut und Böse, da blickt doch schon keiner mehr durch, was da was ist, ohne sich die aufgerufene Funktion genau anzusehen.
    Wenn es vernünftig dokumentiert ist sind auch noch mehr Parameter kein Problem ;-)

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •