lange Felder im Command

[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

[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