Mittels Java-Toolbox auf MessageFiles zugreifen

[opeker]

Hallo,

ich gehe davon aus, dass ein Message File eine CCSID hat, die Connection (sprich: das AS400 Objekt) hat ebenfalls eine und beim holen findet dann eine (gegebenen Falls doppelte) Umsetzung statt. Von der CCSID der Message File über die CCSID des AS400 Objektes zu Unicode und wenn du hier alles richtig einstellst sollte das Ergebnis stimmen, oder die Toolbox hat einen Bug, oder in deinem Message File steht Schrott.
Was das Byte Array angeht: diese Frage kann doch nicht ernst gemeint sein???. die getText() des MessageFiles liefert dir einen String zurück und selbiger hat wie jeder String eine Methode getBytes() die dir ein Byte Array zurück liefert. Allerdings käme kein Java Programmierer auf die RPG Idee irgendwelche Bit Frickeleien in einem Byte Array vorzunehmen, um einen Work around für einen Bug oder Schrottdaten zu drechseln.

mfg


Dieter Bender

Ich habe wie oben schon beschrieben das Problem das der MSGF mit CCSID 65535 und die Texte darin in den Spracheigenen CCSID's gespeichert sind. Also z.Bsp. 37, 870 oder 1025. Das ist leider auf die Schnelle nicht zu ändern da auf der iSeries sämtliche Ausgaben korrekt dargestellt werden und diese Lösung international auf meherern System zur Anwendung kommt. Ich brauche nun in der Java-Welt die gleichen Texte, habe dabei das Problem das 1025-Texte nur als Sonderzeichen in Java ankommen.

Klar kann ich aus einem String ein Byte-Array machen, doch da ist die falsche Umsetzung bereits passiert und es hilft mir nichts mehr. Ich bräuchte einen Einstieg eine Ebene tiefer.

mfg

[Fuerchau]

Schau dir mal den Befehl RTVMSG, F10 zusätzliche Parameter an.
Im Default für CCSID steht *JOB, das heißt, dass die Nachricht eben in die Jobccsid geändert wird. Das glieche gilt auch für das API.

[opeker]

Schau dir mal den Befehl RTVMSG, F10 zusätzliche Parameter an.
Im Default für CCSID steht *JOB, das heißt, dass die Nachricht eben in die Jobccsid geändert wird. Das glieche gilt auch für das API.

Vielen Dank für den Tipp. Werde weiter nach einer Lösung suchen und ggf. dann hier posten. Das mit der Job-CCSID habe ich schon mit wenig Erfolg probiert. Ich habe dazu mit CommandCall die richtige CCSID eingestellt. War aber eher nur ein Versuch, da ein Serverjob ja auch für eine andere Anwendung herangezogen werdan kann und dann zu nicht gewünschten Effekten führen kann.

lg,

[Fuerchau]

Du must wohl dann doch auf die Nachricht "native" zugreifen um den Job eben kurzfristig umzustellen, nämlich nur für den Zugriff auf die Nachricht.
Inwieweit sich allerdings Java die aktuelle Umgebung beim Start "merkt" und ggf. auf die Umstellung des Jobs gar nicht reagiert, bleibt auszuprobieren.

Die andere Alternative ist halt:
Die Nachrichten in eine Datei mit CCSID 13488 (Unicode) auszulagern und dann por SQL auslesen (die Toolbox entfällt dann nämlich).

[BenderD]

Hallo,

wobei es ja immer noch die stored Procedure Variante gibt, die ich eh' vorziehen würde, weil man da den ganzen Toolbox Huddel mit seinen Bugs vermeidet. Warum packst du nicht einfach eure funktionierende AS400 Logik in ein RPG/COBOL/odersowas Programm und registrierst selbiges als stored Procedure?

mfg

Dieter Bender

Vielen Dank für den Tipp. Werde weiter nach einer Lösung suchen und ggf. dann hier posten. Das mit der Job-CCSID habe ich schon mit wenig Erfolg probiert. Ich habe dazu mit CommandCall die richtige CCSID eingestellt. War aber eher nur ein Versuch, da ein Serverjob ja auch für eine andere Anwendung herangezogen werdan kann und dann zu nicht gewünschten Effekten führen kann.

lg,

[opeker]

Vielen Dank für eure Vorschläge. Bin mir sicher das da etwas dabei ist, das ich realisieren kann. Auf diese Ideen bin ich noch gar nicht gekommen. Aber wie so oft - warum einfach, wenns kompliziert auch geht.

Ich kann nur leider in den nächsten Tagen kein Feedback darauf geben, da ich leider ein anderes Projekt vorziehen muss und daher eure Vorschläge nicht gleich testen kann.

Also nochmals Danke und ein schönes Wochenende

lg,

[Fuerchau]

Was die StoredProcedure angeht, hat sich ja das gleiche Problem wie Java.
Ich kann zwar dann per RTVMSG die Nachricht auslesen, ggf. auch die Umsetzung verhindern "RTVMSG ... CCSID(*HEX)", aber ich habe dann noch keine Möglichkeit die Daten in Unicode zu übersetzen (CCSID 13488 ist leider nicht erlaubt).
Ggf. hilft da noch RPGLE, da ich auf Feldebene eine CCSID definieren kann und dann per Move/Eval eine Konvertierung erreiche.

Aber einfacher gehts tatsächlich über eine Datei, die kann nämlich Unicode.

[BenderD]

Hallo,

die kann aber notfalls ein Byte Array zurück geben, das mit dem DollbSchachtel Krimskrams konvertiert werden kann. Oder man könnte nochmal bei SQL Functions; Procedures etc stöbern.
Was mir an der Datei nicht gefällt ist, dass ich den ganzen Krumschel dahin replizieren muss und eh' ich das mache, würde ich mir Java ResourceBundles generieren und die Java Applikation nicht an Altlasten binden.

mfg

Dieter Bender

Was die StoredProcedure angeht, hat sich ja das gleiche Problem wie Java.
Ich kann zwar dann per RTVMSG die Nachricht auslesen, ggf. auch die Umsetzung verhindern "RTVMSG ... CCSID(*HEX)", aber ich habe dann noch keine Möglichkeit die Daten in Unicode zu übersetzen (CCSID 13488 ist leider nicht erlaubt).
Ggf. hilft da noch RPGLE, da ich auf Feldebene eine CCSID definieren kann und dann per Move/Eval eine Konvertierung erreiche.

Aber einfacher gehts tatsächlich über eine Datei, die kann nämlich Unicode.