Keine Probleme mit Parametern

[harkne]

Der Titel hört sich erst mal komisch an aber ich habe hier was, was ich nicht verstehe.

Ich habe ein CL-Programm welches ich von der Befehlszeile aus aufrufe und dieses wiederum ruft ein RPG auf.
Das CL-Programm sollte eigentlich 2 Parameter empfangen die jeweils 2 Stellen *CHAR sind. Diese zwei Parameter übergibt das CL-Programm weiter an das RPG.
Jetzt ist der erste Parameter des CL-Programms fälschlicherweise nicht mit 2 sondern nur mit 1 Stelle *CHAR definiert worden. Jetzt habe ich mir die ganze Zeit überlegt warum das noch niemand gemerkt hat. Das RPG zeigt in einer Maske beide Parameter an. Ich rufe das CL auf mit CALL PGM(XXX) PARM('01' '01') und siehe da auf der Maske erscheinen auch genau diese beiden Werte. Ich denke mir das kann noch nicht sein und debugge das CL-Programm. Das CL-Programm empfängt so wie ich es mir gedacht habe den ersten Parameter einstellig und gibt diesen dann wieder an das RPG weiter. Ich nun also das RPG gedebuggt und dort kommt er Wunder über Wunder wieder korrekt zweistellig an. Also aus dem Wert 1 wird auf einmal wieder 01. Also ich kann mir das bis jetzt nur so erklären daß dadurch das im CL der empfangene Parameter und der übergebenen Parameter an das RPG die gleiche Variable ist und dort dann eine übergabe nicht by Value sondern by Reference erfolgt. Aber das sind natürlich nur Vermutungen. Kann mir das jemand hier erklären warum das so ist ?

[Fuerchau]

Mit der Übergabe per Reference hast du vollkommen Recht.
Wie Parameter des CALL-CMD's übergeben werden, habe ich schon des öfteren erklärt.
Da die Deklaration über den Zugriff auf Speicher bestimmt, kann es natürlich zwischen den Aufrufen zu Problemen kommen.

Parameter mittels CMD-CALL aus der Kommandozeile:
Zeichen mit der übergebenen Länge, mindestens jedoch 32 Stellen ! (Dadurch erklärt sich eben die korrekte Übergabe.)
Zahlen immer im Format DEC(15, 5), also gepackt.

Wird das CMD aus CLP verwendet, wird bereits zur Compile-Zeit definiert und somit Adressen bereits vergeben.

Bei inkorrekter Deklaration kann man halt auch auf dahinterliegende Bereiche zugreifen, mit allen Konsequenzen.

Bei der Entwicklung von CMD's mit Parameterlisten behelfe ich mir auch häufig mit diesem Trick.
Im CLP definere ich den Parameter immer mit CHAR(1), im RPG dann in der benötigten Ausprägung.

[mk]

Hallo Baldur,

da muß ich doch glatt nochmal Fragen...............

Ich verarbeite die Parameter des Befehls mit einem CL Programm.

Dabei bin ich jetzt unter V5R1 an die Grenze von 40
Entry Parametern gekommen.

Ich würde aber gerne den Befehl um weitere Funktionen erweitern.

Bedeutet es jetzt das ich einfach ein langes Feld als letzten
Parameter im CL angeben kann und auch die richtigen Inhalte
der Befehlsvariablen darin stehen ?????????????

Gruss
Michael
PS: Das mit dem Kaffee wird noch nachgeholt.

[Fuerchau]

1. Mach es einfach als ILECLP, da ist, meine ich, die Grenze nun bei 255.

2. eindeutig nein.
Der Kommando-Interpreter legt die Parameter nicht in gesicherter Folge ab (meisten rückwärts).

Du solltest dann das Programm/CMD mal auf Verständnis prüfen.
Wenn mehr als 32 Parameter in einem CMD benötigt werden:
a) durch QUAL Paramter zusammenfassen
b) durch ELEM Parameter strukturieren

[kuempi von stein]

Die Einschränkung auf 40 Parameter unter 5.1. betrifft ja wohl nur CALL PGM PARM1-40
Ein CMD kann unter 5.1. glaube ich 75 Parameter schlucken.

Du könntest auch mal versuchen anstellen von CALL ein CMD zum durchschleifen von mehr als 40 Parameter zu missbrauchen, das ruft dann eben das entrprechende PGM auf.

Ist vermutlich schneller zu kodieren als dran rumzudoktern.

Nur so ne Idee...

k.

[mk]

Hallo,

das CL ist ein CLLE und bei V5R1 sagt er das bei 40 Entry Parametern schluß ist.

Das zusammenführen mehrerer Parameter werde ich mir bei
Gelegenheit nochmal ansehen.

Trotzdem Vilen Dank
Michael