lange Felder im Command

[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