Code-Umsetzung EBCDIC -> UTF-8
- Dieses Thema hat 5 Antworten und 1 Teilnehmer, und wurde zuletzt aktualisiert vor 13 Jahre, 3 Monaten von
Anonym.
-
AuthorPosts
-
24. Mai 2010 um 10:04 Uhr #4085
AnonymInaktivHi,
Ich habe folgendes Problem:
Von DB2 V9.7 mit UTF-8 unter z/Linux wird via federated databases auf Tabellen unter DB2 z/OS (EBCDIC) zugegriffen. Diese Tabellen enthalten in CHAR-Spalten auch Sonderzeichen, die in UTF-8 mit 2 Bytes dargestellt werden. Diese Sonderzeichen werden bei Abfragen dann nicht korrekt angezeigt, wenn die Spalten voll ausgefüllt sind (z.B. 5 Zeichen in CHAR(5)-Spalte). Kennt jemand eine Lösung für das Problem?
Ich bin der Meinung, wenn ich eine Abfrage gegen die Tabelle starte, müßte die Code-Umsetzung für das auszugebende Ergebnis auf jeden Fall korrekt funktionieren. Ich kann ja nicht die Tabellendefinition unter z/OS ändern (CHAR-Spalten vergrößern), nur damit eine Abfrage auf dem z/Linux-Server das richtige Ergebnis liefert.
MfG
AxelP
28. Mai 2010 um 19:55 Uhr #4240
AnonymInaktivHallo,
warum denn DB2 z/OS als Federated Database? Warum keine DB2 Connect Verbindung (garantiert inklusive der notwendigen Codepage Conversion Aktivitäten)?
Alternativ JDBC Type 2 oder Type 4 Verbindung?!
Schon mal einen CAST als VARCHAR probiert?
Wie sind die Columns codiert: (FOR BIT DATA hätten CODEPAGE=0)
[tt]select colname, typename, codepage
from syscat.columns
where tabname = ‚yourtable‘
[/tt]
>>Diese Sonderzeichen werden bei Abfragen dann nicht korrekt angezeigt, …
Mit welchem Medium werden denn die Abfrageergebnisse angezeigt?Gruß
GernotWhen codepage conversion occurs: http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.nls.doc/doc/c0006849.html
30. Mai 2010 um 15:54 Uhr #4355
AnonymInaktiv4B4E4743442A0 wrote: Hallo,
warum denn DB2 z/OS als Federated Database? Warum keine DB2 Connect Verbindung (garantiert inklusive der notwendigen Codepage Conversion Aktivitäten)?
Weil derzeit ein Mix von Linux-Tabellen und z/OS-Tabellen in einer z/Linux-Datenbank genutzt werden soll
Alternativ JDBC Type 2 oder Type 4 Verbindung?!
Java-Abfragen gegen z/OS-DB2 sind korrekt.
Schon mal einen CAST als VARCHAR probiert?Wie sind die Columns codiert: (FOR BIT DATA hätten CODEPAGE=0) Single Byte Character unter z/OS
[tt]select colname, typename, codepage
from syscat.columns
where tabname = ‚yourtable‘
[/tt]
>>Diese Sonderzeichen werden bei Abfragen dann nicht korrekt angezeigt, …
Mit welchem Medium werden denn die Abfrageergebnisse angezeigt?
Bildschirm
Gruß
GernotWhen codepage conversion occurs: http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/topic/com.ibm.db2.luw.admin.nls.doc/doc/c0006849.html
Hi,
oben meine Antworten zu den Fragen.
Das Problem besteht nicht nur bei Abfragen gegen die föderierten Tabellen, sondern auch bei Exports. Es sieht für mich so aus, als ob irgendein Stück Software das Ergebnis konvertiert, dann nochmal die Spaltendefinitionen vom z/OS darauf anwendet und dabei die zu langen Zeichenketten abschneidet.Grüße
AxelP
1. Juni 2010 um 20:14 Uhr #4438
AnonymInaktivHallo,
ein paar Fragen, die einem erfahrenen Federated Database Anwender vielleicht trivial erscheinen mögen:
- DRDA-Wrapper verwendet?
[tt]CREATE WRAPPER drda LIBRARY ‚libdb2drda.a‘CREATE SERVER server_name
 TYPE DB2/ZOS
 VERSION 8.1
 WRAPPER DRDA
 AUTHORIZATION "userid" PASSWORD "password"
 OPTIONS (DBNAME ‚database_name‘)
[/tt] - Irgendwelche Options angeben?[BR]Vielleicht lohnt es sich die Option VARCHAR2_COMPAT mal explizit auf NO zu setzen?!
Options siehe http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/com.ibm.swg.im.iis.db.found.conn.fw.opt.doc/topics/iiyfarefdb2opts.html - Was sagt denn der DB2 Server (z/OS) zur folgenden Abfrage:
[tt]SELECT GETVARIABLE(‚SYSIBM.SYSTEM_ASCII_CCSID‘), Â
    GETVARIABLE(‚SYSIBM.SYSTEM_EBCDIC_CCSID‘), Â
    GETVARIABLE(‚SYSIBM.SYSTEM_UNICODE_CCSID‘), Â
    GETVARIABLE(‚SYSIBM.VERSION‘)
FROMÂ Â SYSIBM.SYSDUMMY1;
[/tt] - Eventuell bekommt man mit "db2 -a connect to feddb" noch ein paar Anhaltspunkte?!
Viele Grüße
Gernot
14. Juni 2010 um 11:18 Uhr #4486
AnonymInaktivHi Gernot,
es hat etwas länger gedauert, bis ich wieder auf dieser Baustelle aufgelaufen bin.
MfG
AxelP
3F3A3337305E0 wrote: Hallo,
ein paar Fragen, die einem erfahrenen Federated Database Anwender vielleicht trivial erscheinen mögen:
- DRDA-Wrapper verwendet?
[tt]CREATE WRAPPER drda LIBRARY ‚libdb2drda.a‘
ja
CREATE SERVER server_name
 TYPE DB2/ZOS
 VERSION 8.1
 WRAPPER DRDA
 AUTHORIZATION "userid" PASSWORD "password"
 OPTIONS (DBNAME ‚database_name‘)
ja, aber V9
[/tt] - Irgendwelche Options angeben?[BR]Vielleicht lohnt es sich die Option VARCHAR2_COMPAT mal explizit auf NO zu setzen?!
Options siehe http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/com.ibm.swg.im.iis.db.found.conn.fw.opt.doc/topics/iiyfarefdb2opts.html - Was sagt denn der DB2 Server (z/OS) zur folgenden Abfrage:
[tt]SELECT GETVARIABLE(‚SYSIBM.SYSTEM_ASCII_CCSID‘),Â
819,65534,65534Â
    GETVARIABLE(‚SYSIBM.SYSTEM_EBCDIC_CCSID‘),Â
273,65534,65534 Â
    GETVARIABLE(‚SYSIBM.SYSTEM_UNICODE_CCSID‘),Â
367,1208,1200 Â
    GETVARIABLE(‚SYSIBM.VERSION‘)
DSN09010
FROMÂ Â SYSIBM.SYSDUMMY1;
[/tt] - Eventuell bekommt man mit "db2 -a connect to feddb" noch ein paar Anhaltspunkte?!
Viele Grüße
Gernot21. Juni 2010 um 13:06 Uhr #4513
AnonymInaktivHi,
🙂 Problem gelöst: per ALTER NICKNAME ALTER COLUMN … LOCAL TYPE … betroffene Spalten vergrößern, dann klappt die Konvertierung auch!
Merkwürdigerweise ist die Angabe von lokalen Redefinitionen gleich beim CREATE NICKNAME für relationale Quellen nicht erlaubt.  😕
MfG
AxelP
- DRDA-Wrapper verwendet?
-
AuthorPosts
You must be logged in to reply to this topic.