lange Felder im Command

[Fuerchau]

Ja jetzt nähert sich das so langsam. Die Ursache ist der SBMJOB !
Wenn du beim SBMJOB einen CALL mit Parametern übergibst, werden diese genauso gehandhabt wie ein Aufruf aus einer Kommandozeile.

Also SBMJOB ... CMD(CALL PGMX PARM(&V)) wird der Inhalt der Variablen ausgelesen und als Zeichenkette übergeben.
Nun schlägt die Defaultbehandlung des CMD-Prozessors für das CALL-CMD zu:
Numerische Werte in 15p5, Zeichenwerte in der Länge der Eingabe, mindestens jedoch 32 Stellen.
Einthält eine Zeichenkette keine Leer- und Sonderzeichen wird sie in Grossbuchstaben übersetzt ansonsten automatisch mit Hochkommata eingeschlossen.

Ein SBMJOB kann ja keinen Call-by-Reference auslösen wie ein CALL-CMD, der zur Compilezeit bereits in einen MI-CALLX aufgelöst wird !!!

Machst du nun einen SBMJOB ... CMD(MYCMD MYPARM(&V)) wird der Inhalt der Variable passend zum PARM konvertiert (numerisch, alpha ggf. in Hochkomma).
Der Befehlsprozessor stellt aber später sicher, dass das aufzurufende Programm garantiert die Puffer in der angegebenen Definition erhält.

Wenn du also einen CALL submitten willst, musst du die Parameter selber in einer Variablen zusammenbauen, ggf. Hochkommata einsetzen und das ganze als Variable übergeben SBMJOB ... RQSDTA(&V) anstelle von CMD(...).

Allerdings gibt es eine Längenbeschränkung von 3000 Zeichen !!!

[Fuerchau]

Ach ja:
Aus JAVA kann es keinen Call-by-Reference an RPG geben, so dass hier quasi per QCMDEXC ein Call aus den Inhalten gestrickt wird. Hier gilt wieder die automatische Parameteranpassung (s.o.).
Ausserdem arbeitet Java in UNICODE und muss daher die Parameter in SBCS konvertieren.

[KM]

Ja jetzt nähert sich das so langsam. Die Ursache ist der SBMJOB !

Das hatte ich aber weiter oben schon geschrieben, dass ich vorhabe die Mails per SBMJOB im Batch zu versenden.

Also SBMJOB ... CMD(CALL PGMX PARM(&V)) wird der Inhalt der Variablen ausgelesen und als Zeichenkette übergeben...

Aus diesen Gründen kann ich mit den CALL per SBMJOB abschminken.

Wenn du also einen CALL submitten willst, musst du die Parameter selber in einer Variablen zusammenbauen, ggf. Hochkommata einsetzen und das ganze als Variable übergeben SBMJOB ... RQSDTA(&V) anstelle von CMD(...)...

Den Aufruf mit RQSDTA hatte ich auch schon getestet. Nur durch die Längenbeschränkung von 3000 Zeichen konnte ich auch das nicht benutzen, da ja allein der eine Parameter schon 9999 Stellen hat.

Machst du nun einen SBMJOB ... CMD(MYCMD MYPARM(&V)) wird der Inhalt der Variable passend zum PARM konvertiert (numerisch, alpha ggf. in Hochkomma).

Genau da liegt ja das Problem. Ich dachte ja mit dem CMD hätte ich die Lösung zu meinem Problem gefunden. Nur entsprechen da die übergebenen 9999 Stellen nicht den empfangenen 9999 Stellen, zumindest wenn sie hinterher in einen Java-String konvertiert werden.

Aus JAVA kann es keinen Call-by-Reference an RPG geben, so dass hier quasi per QCMDEXC ein Call aus den Inhalten gestrickt wird.

Aus Java will ich ja auch gar kein RPG aufrufen.

Die Lösung mit dem Substring funktioniert ja. Und es scheint wohl auch die einzige Lösung für mein Problem zu sein. Damit kann ich leben.

Gruß,
KM

[Robi]

HI KM,
als wir das Problem hatten, haben wir eine Arbeitsdatei erfunden.
Wir schreiben die (bei uns mehrere) Parameter immer mit einem RPGPGM in die Datei. Das RPGPGM gibt uns eine SatzNr zurück. Diese ist dann Parameter und das gleiche PGM wird vom submittenten job gerufen, gibt die Parms zurück und löscht den Satz. Nicht sehr elegant aber es geht
Gruß
RJ

[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

[Fuerchau]

Wie sieht denn wiederum deine Zielvariable für den Trim aus ?
Ist diese denn mit varying definiert ?

Ich denke nicht, dass es ein CMD-Problem ist.

[KM]

Das Ergebnis wird direkt mit dem Constructor für Java.lang.String in einen Java-String konvertiert und wird nicht erst in eine Zwischenvariable gespeichert. Es funktioniert ja normalerweise auch immer. Nur eben nicht beim CMD.

Gruß,
KM

[Fuerchau]

Hm !
Wenn ich variable Längen benötige, kann ich das doch im PARM direkt definieren, dass mir die Länge der Eingabe als 2-Byte binär vorangestellt wird.
Das Parameterfeld im Programm definiere ich dann mit "varying" und es passt !

Kleiner Vorteil:
Bewusste Leerzeichen am Ende gehen nicht verloren.