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

[BenderD]

Hallo,

zurück zum Anfang: hast du nun einen eigenen Command erstellt, oder nicht.
SBMJOB CMD(MyCommand PARM(....)) geht mit allen Parametern, solange sie sein dürfen ohne Probleme.
Was nicht geht ist:
SBMJOB CMD(CALL ....), was am Command Call liegt, wie ein Blick in die Bedienerhilfe des Commands Call näher erläutert...

mfg

Dieter Bender

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

[KM]

Ja, das hatte ich ja schon mehrfach geschrieben, dass ich einen eigenen CMD dafür erstellt habe.

SBMJOB CMD(MyCommand PARM(....)) geht mit allen Parametern, solange sie sein dürfen ohne Probleme.

Das geht eben nicht!!! Das ist ja das Problem. Ich dachte ja auch, dass das funktioniert. Aber wenn ich im gerufenen Programm einen TRIM auf das lange Feld mache, in dem nur ein kurzer Text steht, und das Ergebnis dieses TRIMs in einen Java-String konvertiere, dann sollte doch eigentlich in diesem String nur noch dieser kurze Text vorhanden sein. Und das ist nicht so. Ich erhalte ein langes String-Objekt, das offenbar in mehrere Blöcke aufgeteilt ist und viele Leezeichen enthält.

Gruß,
KM