lange Felder im Command

[KM]

Ich habe ein sehr seltsames Phänomen. Ich habe einen Command zum Versenden von eMails erstellt mit mehreren Parametern vom Typ Character. Ein Parameter davon ist 9999 Stellen lang, die anderen deutlich kleiner. Das Feld mit den 9999 Stellen stellt den eMail-Body dar. Hinter diesem Command steckt ein CLLE-Programm, das die Parameter empfängt und weiterverarbeitet. So weit so gut.
Wenn ich nun einen normalen Text (z.B. ein paar Wörter) per eMail versenden will, erstellt mir das Programm eine Mail von 22 KB (!). Ich habe auch gesehen, dass das lange Textfeld wohl in Blöcke zu jeweils 75 Stellen aufgesplittet wird mit lauter Leerzeichen, obwohl vorher auf dieses lange Textfeld ein %trim() gemacht wird.

Kann es also sein, dass es Probleme gibt, wenn man lange Textfelder bei einem Command an ein Programm übergibt ? Irgendwas scheint hier faul zu sein, denn im Debug sieht alles noch ganz normal aus.

Gruß,
KM

[Fuerchau]

Ich denke, dass in dem Feld für das Kommando noch am Ende irgendein Hexwert <> Blank steht.
Zeige das Feld im Debugger mal Hex an.

[KM]

Also das sieht mir sehr nach einem Bug aus (vielleicht ist's ja auch ein Feature - haha).

Ich habe jetzt das Programm zum Mail-Versand einmal direkt mit CALL aufgerufen und einmal über den CMD. Die Parameter sind alle vom gleichen Typ und gleicher Länge. Beim CALL funktioniert alles so wie es sein soll. Beim CMD gibt es diese Probleme mit dem langen Textfeld. Im Debug sieht dieses Textfeld bei beiden Varianten absolut gleich auch (auch in Hex-Ansicht). Offenbar wird das Feld dann intern anders behandelt, wenn es von einem CMD übergeben wird, als von einem CALL.

Da ich die Mail im Batch versenden will (per SBMJOB) nützt mir der reine CALL leider nicht viel, weil bei dieser Konstellation (SBMJOB -> CALL) die Parameter dann nochmal anders übergeben werden und trotz gleicher Parameterlängen im gerufenen Programm die Parameterwerte auf einmal völlig verschoben sind. Da werden offenbar die Pointer falsch gesetzt. Deshalb wollte ich das über den CMD lösen.

Jetzt konnte ich das Problem doch ganz gut umgehen. Ich habe einfach als weiteren Parameter noch die Länge des Inhalts dieses langen Textfeldes eingebaut und mache im gerufenen Programm als erstes einen Substring auf dieses Feld mit dieser Länge. Und jetzt funktioniert's richtig.

Ist schon komisch das Ganze...

Gruß,
KM

[TARASIK]

Hallo KM,
das hahaha war doch angebracht. Ich denke Du hast R530,
dann ist es doch ein Bug.

http://www-912.ibm.com/n_dir/nas4apa...nd,length,r530

[KM]

Hallo Tarasik,

wenn ich das PTF richtig verstehe, ist es dafür gedacht, wenn der %SST falsche Ergebnisse produziert. Das ist aber nicht mein Problem. Im Gegenteil der %SST hilft mir ja jetzt die übergebenen Parameter korrekt zu verarbeiten.

Trotzdem Danke! Ich werde mir das PTF dennoch holen. Wir haben es nämlich noch nicht auf unserem System.

Gruß,
KM

[Fuerchau]

Natürlich ist die Parameterübergabe bei einem CMD anders zwischen Konstante und Variable !
Wenn du ein CMD selber entwickelst, kannst du einen PARM-Wert mit Längeninformation erstellen (meist 2-Byte-Bin).

Wenn du nun ein CMD per Kommandozeile mit Text aufrufst, wird die Länge des Textes vom Befehlsprozessor berechnet, ein Speicherbereich angelegt und die Information an das ausführende Programm übergeben.

Wenn du nun das selbe CMD in einem CLP mit Variable aufrufst, erstellt der Compiler bereits einen vorcompilierten CMD-Aufruf in dem nun die Länge der Felder und nicht die Länge des Feldinhaltes verwendet wird !!!

Deine Lösung mit Übergabe als %SST(...) ist da nur die konsequente Folge

[KM]

Natürlich ist die Parameterübergabe bei einem CMD anders zwischen Konstante und Variable !

Das war auch nicht das Thema. Ich hatte den CMD ja auch nie mit Textkonstanten aufgerufen, sondern immer aus einem CL-Programm mit den entsprechenden Variablen. Wie ich bereits geschrieben hatte, habe ich sowohl beim CMD als auch beim CALL dieselben Parameter übergeben mit unterschiedlichen Ergebnissen im gerufenen Programm. Deshalb muß hier ein Bug vorliegen.

Gruß,
KM

[Fuerchau]

Ich verstehe das nun nicht so ganz:
Welches Programm wird mit CMD und welches per CALL aufgerufen ?
Sind die Übergabeparameter denn tatsächlich identisch ?
Wenn ein Programm über CMD aufrufbar ist, sollte es immer über das CMD aufgerufen werden. Nur dann kann das CMD jederzeit erweitert oder geändert werden.

[KM]

PROG_A (CLLE) enthält den CMD, der PROG_C aufruft.

PROG_B (CLLE) enthält den CALL, der PROG_C aufruft.

Die Parameter, mit denen PROG_C aufgerufen wird, sind in beiden Fällen absolut identisch. Es handelt sich bei allen Parametern um CL-Variablen. Das Ergebnis in PROG_C ist in beiden Fällen unterschiedlich.

Gruß,
KM

[Rincewind]

Hi,

schonmal geguckt was passiert wenn du den langen Text als VARCHAR übergibst ? ob sich dass dann bessert ?

Liegt ein Unterschied vor wenn du die einzelnen Programme den CMD/bzw den Call submitten lässt ?

Gruß
Rince

[Fuerchau]

Also muss die CMD-Definition zu den Parametern des gerufenen Programmes PROG_C oder des rufenden Programmes PROG_B nicht ganz passen !!!
Eine andere Erklärung kann es nicht geben, sonst würde ich an der AS/400 doch Zweifel aufkommen lassen

Ansonsten frage ich mich, warum du ein Programm mal als CMD mal per CALL aufrufst.

[KM]

@Rincewind

Das gerufene Programm erwarte eine feste Feldlänge von 9999 Stellen für dieses Feld. Wenn ich da kürzere Werte übergebe oder VARCHAR, dann wird der Rest des Feldes bereits mit dem Wert des nächsten Parameters aufgefüllt.
Wenn ich das Programm mit dem CALL per SBMJOB aufrufe, dann stehen am Ende des Feldes bereits Teile des Wertes des nächsten Parameters, obwohl die Feldlängen passen. So wollte ich es ja ursprünglich machen. Ich konnte leider nicht feststellen wie da die Feldlänge beim SBMJOB ermittelt wird. Das war der Grund warum ich jetzt den CMD aufrufe.

@Fuerchau

Wie ich bereits mehrfach erwähnt habe, stimmen die Parameterdefinitionen des CMD mit dem rufenden und dem gerufenen Programm absolut überein.
Den Aufruf einmal per CMD und einmal per CALL habe ich nur zu Testzwecken gemacht, um eben genau diesen Unterschied feststellen zu können. Im aufgerufenen RPG-Programm sehen die Inhalte der Felder ja auch identisch aus. Nur wenn diese Felder konvertiere in Objekte vom Typ Java.String, dann erhalte ich unterschiedliche Ergebnisse. Und somit müssen beide Felder an sich schon vor der Konvertierung unterschiedlich sein. Das ist mir bis jetzt allerdings nur bei diesem langen Feld aufgefallen.

Gruß,
KM