PDA

View Full Version : CCSID eines PF aus java herausfinden



Seiten : [1] 2

rod
30-08-04, 10:46
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
30-08-04, 11:17
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
30-08-04, 11:22
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
30-08-04, 11:53
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
30-08-04, 12:37
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
30-08-04, 16:41
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
30-08-04, 16:49
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
30-08-04, 17:07
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
30-08-04, 17:25
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
30-08-04, 17:32
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 !!