CCSID eines PF aus java herausfinden

[rod]

Hallo,

ich suche eine Möglichkeit aus einem Java-Programm heraus die CCSID einer physischen Datei herauszufinden (um diese dann mit der korrekten Codepage zu öffnen). Ich habe hier nichts gefunden in jt400 . Ich bräuchte praktisch einen DSPFD als JavaMethode.

Vielleicht hat jemand einen Rat für mich?

Schönen Gruß und Danke!
Roderich Hellwig

[Fuerchau]

Soweit ich weiß, wird eine Datei MIT CCSID automatisch in Java korrekt geöffnet.
Voraussetzung ist, dass das USRPRF unter dem JAVA läuft eine CCSID ungleich 65535 hat, oder wenn dort *SYSVAL steht, eben QCCSID eine korrekte CCSID hat.

Nur wenn die PF eine CCSID 65535 hat, sollte man beim Open eine CCSID vorgeben.

[BenderD]

Hallo Roderich,

mit JDBC sollte das der Treiber übernehmen - kannst Du Dein Problem etwas genauer darstellen?

mfg

Dieter Bender

Hallo,

ich suche eine Möglichkeit aus einem Java-Programm heraus die CCSID einer physischen Datei herauszufinden (um diese dann mit der korrekten Codepage zu öffnen). Ich habe hier nichts gefunden in jt400 . Ich bräuchte praktisch einen DSPFD als JavaMethode.

Vielleicht hat jemand einen Rat für mich?

Schönen Gruß und Danke!
Roderich Hellwig

[rod]

Hallo,

danke für die Antworten.

Der Job läuft unter Codepage 273, die (Test-)Datei hat auch 273. Das Programm muss aber auch mit Dateien mit anderen CCSIDs zurechtkommen (allen normalen CCSIDs, nicht 65535) . Das lesen aus der Datei erfolgt nicht mit JDBC sondern per:

new BufferedReader(new InputStreamReader(
new FileInputStream(file), "???Codepage???"));

Ich bin allerdings nicht auf die Idee gekommen keine Codepage anzugeben.
Das werde ich jetzt als erstes probieren.

Danke!

Roderich Hellwig

[BenderD]

Hallo Roderich,

falls Du mit Datei ein Streamfile im IFS meinst, da hängt es von den verwendeten lese/schreib Methoden ab, ob konvertiert oder transparent verarbeitet wird. Beim lesen brauchst Du da eigentlich nix anzuugeben, beim erzeugen nur dann, wenn Du eine andere haben willst, wie Dein Job hat.

mfg

Dieter Bender

Hallo,

danke für die Antworten.

Der Job läuft unter Codepage 273, die (Test-)Datei hat auch 273. Das Programm muss aber auch mit Dateien mit anderen CCSIDs zurechtkommen (allen normalen CCSIDs, nicht 65535) . Das lesen aus der Datei erfolgt nicht mit JDBC sondern per:

new BufferedReader(new InputStreamReader(
new FileInputStream(file), "???Codepage???"));

Ich bin allerdings nicht auf die Idee gekommen keine Codepage anzugeben.
Das werde ich jetzt als erstes probieren.

Danke!

Roderich Hellwig

[rod]

Hallo,

ohne Angabe einer Codepage wird leider die Datei in (wahrscheinlich) ISO_8859-1 aufgemacht.
Was ich machen will ist, z.B.:
new BufferedReader(new InputStreamReader(
new FileInputStream(new File("/QSYS.LIB/TESTLIB.LIB/TESTF.FILE/MEMBER.MBR"), "???Codepage???"));

Dass funktioniert bei mir nur dann korrekt, wenn ich die richtige Codepage angebe.

z.B.:
new BufferedReader(new InputStreamReader(
new FileInputStream(new File("/QSYS.LIB/TESTLIB.LIB/TESTF.FILE/MEMBER.MBR"), "Cp273"));

angebe.

Damit ich hier die Dateien (Physical Files) korrekt aufmachen kann, muss ich irgendwie herausfinden, welche Codepage diese haben.

Und wie das funktioniert weiss ich nicht.

Schönen Gruß
Roderich

[Fuerchau]

Auch das ist normalerweise unerheblich. Durch Angabe der CP wird beim Lesen halt in diese CP umgesetzt.
Wenn die PF z.B. CP500 hat, kannst du diese trotzdem mit CP273 lesen.

Übrigens:
Das ganze geht nur mit PF's, die KEINE gepackten oder sonstige Nicht-Zeichen-Felder enthalten !!!
Du öffnest einen Zeichen-Stream, so dass keine Feldumsetzung stattfindet.
Der bessere und sicherere Weg ist (wie Dieter schon sagt) SQL !!!

[BenderD]

Hallo,

new BufferedReader(new InputStreamReader(
new FileInputStream(new File("/QSYS.LIB/TESTLIB.LIB/TESTF.FILE/MEMBER.MBR"), "Cp273"));

Roderich

hier sehe ich erst mal zwei Sachen:*
1. der Konstruktor von File wird verbogen bedient, es gibt nur einen Konstruktor von File(String parent, String child) bei dem child mit der CCSID nix zu tun hat.

2. Du öffnest hier ein Objekt aus dem QSYS.LIB als File, das ist aber Datenbank und sollte mit JDBC angepackt werden, dann funzt das auch.

mfg

Dieter Bender

[rod]

Hallo Dieter,

zu 1: das "Cp273" gehört zum Constructor des FileInputStream (funktioniert ja auch mit Cp273)

InputStreamReader(
new FileInputStream(file, "Cp273"));

zu 2:

Das ist ja gerade mein Problem, das dieses Lesen aus eine AS400 DB-Datei (physische Datei) NICHT per JDBC erfolgen kann, sondern ich einen BufferedReader benötige.
Hintergrund ist der, das wir hier eine plattformunabhängige Java-Applikation haben, in welcher ich es nicht ändern kann, das ich einen BufferedReader benötige UND die Daten in physischen Dateien vorliegen. Ein umkopieren in STMFiles ist wegend der großen Datenmengen leider keine wirkliche Alternative.

Danke für die Antworten.

Roderich

[Fuerchau]

Gerade das ist doch der Vorteil von JAVA, dass du je nach Datenbank nur einen anderen JDBC-Treiber benötigst (über z.B. ein Property-Datei einstellbar incl. Verbindungsfolge), aber alle SQL-Zugriffe (bis auf wenige Ausnahmen) immer identisch sind.
Wenn du erst mühsam eine PF in eine STMF umkopieren musst, ist ja der ganze Vorteil der DB hinüber.
Was machst du denn, wenn es mal eine andere DB ist (ORACLE, MySAP, usw.) ?
Was ist mit Einzelsatz-Zugriffen ? Musst du dann immer alle Sätze der STMF durchackern ?

Ich würde das Konzept da nochmal überprüfen !!

[Fuerchau]

PS:
Mit CP273 erhältst du die Daten in EBCDIC und mnusst sie auch noch selber wandeln.
JAVA arbeitet z.B. in ISO8859-1 oder sogar UNICODE.
Wo ist da der Vorteil, alles selber machen zu müssen ?

[rod]

Es geht hier um die Umsetzung einer DB die auf allen Plattformen erst in Textdateien ausgelesen werden , das wollte ich mir auf der AS/400 schenken. Und anschliessend in einem neuen Format per jdbc in die DB geschrieben wird.
Diese Funktionalität ist so gewählt, da es einfacher ist, die DB auszulesen, wegzuschmeissen, neu aufzubauen und zu befüllen, als zwei parallele DBs zu haben, das hiesse erst eine komplett neue DB anzulegen, und dann zwischen diesen hinundherzuschaufeln. Auf der AS/400 ist das recht einfach, aber mit MSSQL, Oracle usw ist das nicht so einfach....

Schönen Gruß

Roderich