Problem mit Java-Methoden Aufruf aus ILE RPG?

[Stoeberl]

Hallo zusammen!

Ich habe ein Problem mit einem Java-Methoden Aufruf aus ILE RPG. Habe dazu auch schon ein Posting in der Newsgroup comp.sys.ibm.as400.misc verfasst (Problem with Java calls from ILE RPG?), aber leider noch ohne Lösung.

Ich habe ein Programm das verschiedene Java Methoden aus RPG aufruft. Um alle Zeichen verarbeiten zu können arbeite ich intern mit UCS2 und übergebe auch an Java UCS2 Felder (Konvertierung erfolgt von Job-CCSID nach UCS2). Das Programm funktioniert unter V5R3M0 und SBCS ohne Probleme für verschiedene Codepages. Mit V5R3M0 und DBCS stürzt das Programm unter bestimmten Konstellationen ab. Das RPG Programm wird von einem CL-Programm aufgerufen, das vorher noch ein paar Umgebungsvariablen für Java setzt. Unter Simplified Chinese (Codepage 935 od. 1388) kann ich das Absturz-Problem beheben wenn ich im CL einen DLYJOB DLY(5) absetze und dann das RPG-Programm nochmals aufrufe. Unter Japanisch (Codpage 930 bzw. 5026) hilft das allerdings nicht. Hier bekomme ich immer den Fehler:


MESSAGE ID . . . . . . : RNX0451
DATE SENT . . . . . . : 22/12/06 TIME SENT . . . . . . : 23:19:13

MESSAGE . . . . : CONVERSION BETWEEN CCSID(5026) AND CCSID(-11) IS NOT
SUPPORTED.

CAUSE . . . . . : IN RPG PROCEDURE TESTJAVA IN PROGRAM TEST/TESTJAVA, A
CONVERSION IS BEING DONE WHICH REQUIRES CONVERSION FROM CCSID(5026) TO
CCSID(-11), BUT THIS CONVERSION IS NOT SUPPORTED.
RECOVERY . . . : USE COMMAND DSPJOB TO FIND THE CCSID OF YOUR JOB, THEN
CONTACT THE PERSON RESPONSIBLE FOR PROGRAM MAINTENANCE TO DETERMINE THE
CAUSE OF THE PROBLEM.
TECHNICAL DESCRIPTION . . . . . . . . : FOR CONVERSION BETWEEN CHARACTER
VALUES AND GRAPHIC VALUES, THE CHARACTER VALUE IS ASSUMED TO BE IN THE
GRAPHIC CCSID RELATED TO THE JOB CCSID. FOR CONVERSION BETWEEN GRAPHIC
LITERALS AND GRAPHIC FIELDS, THE CCSID OF THE LITERAL IS ASSUMED TO BE THE
GRAPHIC CCSID RELATED TO THE JOB CCSID.

An dieser Stelle wird ein UCS2 Feld an den Konstruktor von java.lang.String übergeben. Nehme ich statt der Codepage 930 bzw. 5026 die Codepage 939 bzw. 5035 funktioniert das Programm (tritt der Fehler in der chinesischen Umgebung auf wird der gleiche Fehler angezeigt, aber mit CCSID(5035) und CCSID(-10)). Der wesentliche Unterschied bei diesen beiden Codepages ist, das bei 930 keine kleinen lateinischen Buchstaben unterstützt werden. Nach einem Update der Maschine auf V5R4M0 hat sich zumindest das Problem in der chinesischen Umgebung von alleine gelöst, das Problem in der japanischen Umgebung bleibt.
Aus der Newsgroup habe ich den Hinweis, das die negativen CCSID Werte zustande kommen da die CCSID als Unsigned Short Int gespeichert wird, ein Datentyp der von Java nicht unterstützt wird. Daher entspreche -11 = 65525 und -10 = 65526. Ein Anfrage bei der IBM zu diesem Thema blieb bis jetzt unbeantwortet.

Hat jemand schon ein ähnliches Problem gehabt bzw. ist jemanden bekannt das Java-Methoden Aufrufe aus ILE RPG in Zusammenspiel mit der CCSID 930 bzw. 5026 generell nicht funktionieren?

MfG
Martin Stöberl

[Fuerchau]

Ggf. kannst du das Problem behebn, indem du im ILERPG selber Variablen vom Typ G mit CCSID definierst, dann in eine Variable vom Typ C (UCS2) überträgst und diese dann an Java übergibst.

Die 2. Möglichkeit ist eine SQL-View (ggf. auch DDS-LF) in der du die Variablen der PF direkt in UCS2 castest "cast(mydbcs as graphic(nn) ccsid 13488)".

UCS2 müsste eigentlich alle anderen CCSID's unterstützen.

Wenn alles nichts hilft kannst du ggf. den Umweg über UTF8 (CCSID 1208) nehmen und dann nach UCS2 wandeln.

[Stoeberl]

An der Stelle wo der Fehler auftritt ist eigentlich die Umwandlung von Job-CCSID nach UCS2 schon gelaufen und das UCS2 Feld wird an den Kontruktor von java.lang.String übergeben. Hab mir auch im Debugger die erzeugten UCS2-Hex-Werte in den Feldern angeschaut, die sollten auch korrekt sein. Meine Vermutung wär ja, dass das Problem die Namen der Java-Klassen sind (wegen Groß- und Kleinschreibung). Unter V5R4M0 funktioniert es ja jetzt eigentlich überall außer mit Japanisch CCSID 930 (zur Erinnerung, hier werden keine kleinen lateinischen Buchstaben im SBCS Teil der Codepage unterstützt).

Die Daten die ich an das Java-Programm übergebe werden beim Aufruf des Programms als Parameter übergeben. Von dem her bringt mir die 2. von dir beschriebene Möglichkeit in diesem Fall nichts.

MfG
Martin Stöberl

[Fuerchau]

Da Java eigentlich mit UCS2 umgeht und du zwischen RPG/JAVA nur UCS2 austauschst hilft vielleicht eine temporäre Umschaltung des Job's auf CCSID 500 (international) und wieder zurück.

[Stoeberl]

Hmmm, wär noch ne Idee. Könnt erst mal alle Werte nach UCS2 konvertieren und in UCS2 Variablen speichern, die CCSID des Jobs auf 500 ändern und dann die Java Methoden aufrufen.

Werd ich mal probieren. Danke!

MfG
Martin Stöberl

[Stoeberl]

Ich glaub das wars! Anscheinend hat die IBM hier wirklich ein Problem wenn bei Codepage 930 in der Source kleine lateinische Buchstaben verwendet werden (auch im CL). Nachdem ich vor der Verwendung von kleinen lateinischen Zeichen die CCSID des Jobs auf 500 geändert habe funktioniert es. Nur zum Konvertieren der über Parameter übergebenen Werte setzt ich die CCSID wieder auf 930. Erste Tests schauen vielversprechend aus!

Danke für den Tip! Das Problem hat mich schon langsam zur Verzweiflung getrieben ...

MfG
Martin Stöberl

[Fuerchau]

Es könnte auch sein, da Java CaseSensitive ist, dass alleine die Variablennamen mit Kleinbuchstaben hier schon hinderlich sind, aber wer weiß....

Umgehungen sind auch manchmal die Lösung.

Warum reicht das Ändern der JobCCSID nicht direkt vor dem Java-Aufruf ?

[Stoeberl]

Im CL setze ich die Umgebungsvariablen wie CLASSPATH oder QIBM_RPG_JAVA_PROPERTIES. Hierbei wird auch Groß- / Kleinschreibung verwendet und zumindest bei der Umgebungsvariable QIBM_RPG_JAVA_PROPERTIES bin ich mir jetzt nicht sicher, ob Großschreibung funktioniert. Und solange ich die JobCCSID nicht ändere können die Umgebungsvariablen mit Kleinbuchstaben auch nicht verwendet werden.

Java ist definitiv Case Sensitive. Ich denke das Problem liegt hier beim Aufruf der Java Methode, die RPG Statements werden ja beim Kompilieren in Großbuchstaben umgesetzt. Aber der Methoden bzw. Klassenname wird ja in Hochkommas gesetzt, z.B.

     D CRTSTR          PR              O   EXTPROC(*JAVA:
     D                                      'java.lang.String':
     D                                      *CONSTRUCTOR)
     D                                      CLASS(*JAVA:'java.lang.String')
     D                            16383C    CONST VARYING

Ich weiß ja nicht genau wie IBM das intern händelt mit der Umsetzung wenn eine Programm, wo die Quelle unter CCSID 273 erstellt, gespeichert und kompiliert wurde in einer Umgebung mit CCSID 930 ausgeführt wird. Vielleicht wird hier versucht alles in die JobCCSID zu konvertieren und dann hätte er wohl ein Problem da einige Zeichen in der Ziel-Codepage nicht existieren.

Aber wie auch immer, im Moment bin ich damit zufrieden das es jetzt funktioniert

MfG
Martin Stöberl

[Fuerchau]

Programmkonstanten unterliegen nicht der Codewandlung zur Laufzeit sondern nur zur Compile-Zeit.
Da JavaCode aber im Wesentlichen ja Daten sind und kein Maschinencode kann dies hier zum Fehler führen.
Zum Auffinden der Methoden und Klassen bedarf es wohl einer gültigen Codepage die eben auch Kleinbuchstaben unterstützt.

Denn obwohl die Daten in Unicode verarbeitet werden ist wohl der Javecode selber eben kein Unicode.

Aber das ist alles stochern im Nebel, Dieter kann de ggf. mehr zu sagen.

Schön, dass mein Tipp funktioniert.