PDA

View Full Version : RPGLE --> CLLE String wird mit x'00 statt x'40' gefüllt



Seiten : [1] 2

ILEMax
12-04-24, 08:24
Moin
wir haben hier ein ILERPG Pgm, das ein CLLE ruft.

Es werden 9 Parameter, alle *CHAR übergeben.
Parameter 1 - 8 kommt 'richtig', wenn leer dann mit x'40' gefüllt.
Diese sind < 32 Byte.
Der 9. Parameter ist 275 Byte groß, wird im RPG mit *blank initialisiert.
Danach wird er aus einer Datei gefüllt. I.d.R. weniger als 275 Stellen.

Die Füllung erfolgt in einer Schleife, ab dem 2. lesen so:
eval Text = %substr(text:1:i*30) + NUTEXT

Im CLLE kommt der String mit 'seinen' Daten + x'00' an.
Auch ein XLATE x'00' auf x'40' im RPGLE hilft nicht.

Das war früher nicht so oder? (Jetzt V7R5)
Kann ich das beeinflusen?

Danke.
der ILEMax

dschroeder
12-04-24, 08:38
Moin,
sind die Parameter im RPGLE eventuell nicht char definiert sondern varchar?

Oder wird das CL nicht einfach mit CALL aufgerufen, sondern per SBMJOB?

ILEMax
12-04-24, 08:42
Nachtrag:
Das ist nur im Batch so.
Das clle prüft ob es interaktiv oder im Batch läuft.
Läuft es interaktiv und wir haben keinen Debug an, submittet es sich selbst.

ILEMax
12-04-24, 08:57
Noch ein Nachtrag..
Habe im Submit(call Pgm Parm(
nun beim letzten Parameter *char 275 mit angegeben.
Jetzt geht es wieder.
Der ILEMax

Fuerchau
12-04-24, 09:10
Das ist dann der Fall, wenn du den Umweg über QCMDEXC, also z.B. für SBMJOB machst.
Es galt schon immer beim CMD-Call:

Wenn Zeichen kürzer als 32 angegeben werden, werden sie mit Leerzeichen aufgefüllt, bei längeren Zeichenfolge nur in der angegebenen Länge.
Für die korrekte Länge muss die ganze Zeichenkette komplett mit Leerzeichen aufgefüllt in Hochkommas übergeben werden, incl. ggf. zu verdoppelnder eingebetteter Hochkommas.

Man kann natürlich auch einfach 1 Zeichen mehr übergeben, als das Ziel erwartet. Im Ziel ist das dann nicht zu sehen.
Also beim ILERPG:
dcl-s feld char(275);

call qcmdexc 'SBMJOB .... CALL PGMX PARM(''' + feld + 'x' + ''')

im CLLE/CLP:

dcl &feld char(275)
var &parm char(276)
chgvar &parm (&feld *cat 'x')

ILEMax
12-04-24, 10:07
Also in der Form war das früher nicht!
Das 32 Bit Thema ist bekannt.
Der String wird in 2 ' übergeben (vorne und hinten je 2!)

Das Pgm läuft selten aber schon seit mehreren Jahren.
irgendwas ist anders
Aber egal, mit dem *CHAR 275) geht es wieder

Der ILEMax

Fuerchau
12-04-24, 10:37
%substr(text:1:i*30) + NUTEXT

Wenn das Ergebnis des Substr kürzer als 275 ist, steht dein NUTEXT nun mal direkt dahinter.
Ich wüsste nun nicht, was sich da dann geändert haben sollte.

ILEMax
12-04-24, 11:02
???
Nutext ist 30 stellig

1. lesen: i = 0, eval text = nutext
2. lesen bis eof: i = i + 1, eval text = substr(text:1:i*30) + Nutext

so bilden sich Inhalte die zwischen 1 und 275 Byte lang sind
Ja, 275 ist nicht durch 30 Teilbar, macht aber nix!

Diese werden immer in '' in dem 275 er Text String weggegeben
Im CLLE kommt das auch an
beim Submit des CLLE von sich selber wird aus
ABCX'40'x'40'x'40'...
ABCX'00'x'00'x'00'...
Das war nicht so, das Pgm läuft seit Jahren. Selten aber 1-4 mal / Jahr.
Gestern hat es geknallt.

Fuerchau
12-04-24, 11:45
Aber wie sieht denn der SBMJOB denn tatsächlich aus. Irgendwo müssen die Hochkomma dann wieder weg interpretiert werden, was zum Abschneiden auf die Länge der Konstanten führt.

ILEMax
12-04-24, 12:12
sbmjob(call pgm(Pgmx) parm('123') ('234') ('9') ('240412') (''ABC '') (''D e f'') ('123457') ('7') (''test text test text test3 text ... mit leerzeichen am ende''))) Job(xyzjob) Jobd(meinejobd)