PDA

View Full Version : Konvertierung nach Graphic --> CCSID Problem



Seiten : [1] 2 3 4

codierknecht
21-08-06, 09:10
Hallo Forum,

ich möchte unsere SAP Datenbank auf der AS400 mit Daten aus einer physischen Datei auf einer anderen AS400 füttern.

Ich habe dazu mittels SQL auf der Nicht SAP Maschine eine Datei erzeugt, welche den Datentyp GRAPHIC verwendet, da SAP diesen Datentyp fast ausschließlich nutzt (auf OS Ebene).

Sah in etwa so aus:
CREATE TABLE TEST01 (WERK GRAPHIC (4 ) ccsid 13488 NOT NULL
, LAGER GRAPHIC (4 ) ccsid 13488 NOT NULL , BLOCK GRAPHIC (4 )
ccsid 13488 NOT NULL , MATNR GRAPHIC (18 ) ccsid 13488 NOT NULL ,
CHARGE GRAPHIC (10 ) ccsid 13488 NOT NULL , MENGE decimal (13, 3 )
, EINHEIT GRAPHIC (3 ) ccsid 13488 NOT NULL
, BENUTZER GRAPHIC (10 ) ccsid 13488 NOT NULL , ZEIT
GRAPHIC (26 ) ccsid 13488 NOT NULL )


Beim füllen der Datei aus einer anderen erhalte ich die Fehlermeldung:
Zeichenumsetzung zwischen CCSID 65535 und CCSID 13488 ungültig.

SQL sieht wie folgt aus:
insert into test01
(select graphic(werk, 4, 13488) as werk,
graphic(lager, 4, 13488) as lager, graphic(block, 4, 13488) as block
, graphic(matnr, 8, 13488) as matnr, graphic(charge, 10, 13488) as
charge, menge, graphic (einheit, 3, 13488) as einheit,
graphic(benutzer, 10, 13488) as benutzer, graphic(
char(zeit), 26, 13488) as
zeit from sapin01p)

Wie erreiche ich eine korrekte Konvertierung?

codierknecht
21-08-06, 09:52
Ich glaube, ich bin einen Schritt weiter.
Ich habe mal die CCSID meines Jobs von 65535 auf 273 geändert. Ich weiß zwar nicht, was die CCSID 273 repräsentiert, aber die Daten wurden in die Tabelle geschrieben

KM
21-08-06, 13:52
Sobald die CCSID 65535 angegeben ist, erfolgt keine Code-Konvertierung. Die Angabe von 273 war schon richtig. Das ist die EBCDIC-Codepage für deutsch (ohne Euro-Symbol). Damit wird korrekt konvertiert.

Gruß,
KM

Fuerchau
21-08-06, 14:40
CCSID 13488 steht für Unicode/UCS2.
CCSID 65535 steht für *HEX.

Um also in UCS2 zu konvertieren, muss ein CCSID ungleich 65535 verwendet werden.

Beim "Insert ... Select" sollte die Job-CCSID eigentlich keine Rolle spielen !

Da ein Job nicht in UCS2 arbeiten kann, liest dein Select die Daten und konvertiert diese in die JOB-CCSID (dein CAST in 13488 wird also wieder rückgängig gemacht) um ihn anschließend in die Zieltabelle wieder umzuwandeln.

Was anderes besagt die CPF-Nachricht nämlich nicht, als das die Codewandlung von/nach 65535 nicht funktioniert.

codierknecht
23-08-06, 10:11
Hallo Fuerchau


Beim "Insert ... Select" sollte die Job-CCSID eigentlich keine Rolle spielen !

das mag durchaus sein. Dennoch gelingt mir der Insert nur, wenn ich die Job CCSID entsprechend ändere. Andernfalls erhalte ich wieder die Fehlermeldung.

Wenn ich die Daten mittels CPYF in die Zieldatei kopiere und die CCSID NICHT umstelle, so ist die Datei in SAP hinterher mit Sonderzeichen und sonstigem Zeug gefüllt. Mit einer anderen CCSID gelingt es jedoch hervorragend.

sflo
28-03-17, 13:58
Hallo Fuerchau,
hallo zusammen,

hierzu habe ich auch eine Frage: ich bin auf der Suche nach einer richtigen Kodierung zu base64 mittels RPGLE. Das Problem ist, dass die vorhandene Funktion SYSTOOLS.BASE64ENCODE eine VARCHAR mit der max. Länge von VARCHAR(2732) annehmen kann. Ich benötige aber die Konvertierung einer größeren Zeichenkette. Hat jemand Tipps dazu?

Vielen Dank und viele Grüße,
Claudia

Fuerchau
28-03-17, 14:20
Da hilft nur, selber machen: https://www.scottklement.com/base64/

KM
28-03-17, 15:04
Hallo Claudia,

wenn Dein String größer als 2732 Zeichen ist, dann versuche ihn doch mal zu splitten. Die ersten Blöcke müssen Vielfache von 3-Bytes Länge sein. Der letzte Block ist dann egal. Die Ergebnisse kannst Du dann wieder zusammenfügen. Dann sollte das richtige Ergebnis dabei rauskommen.

Viele Grüße,
KM

Fuerchau
28-03-17, 15:08
Ja und nein.
Das Problem ist, dass dann jeder Block auch weider einzeln dekodiert werden muss.
Am Ende eines MIME64 wird mit 1 oder 2 "=" aufgefüllt damit die Anzahl Zeichen wieder durch 4 teilbar ist. Ich kann das schon verstehen, wenn die Daten als Block an eine andere Anwendung weiter gereicht werden muss, sollte die Kodierung auch vollständig in einem Block erfolgen.
Also muss man es selber machen und halt Scott's Routinen ggf. auch aufbohren.

Nachtrag:
"Die ersten Blöcke müssen Vielfache von 3-Bytes Länge sein" habe ich übersehen, das passt dann ja.

KM
28-03-17, 15:31
hier ein Beispiel...

Encode:
values(systools.base64encode('DasisteinTes') concat systools.base64encode('tmitBase64Encode'))

Decode:
values((systools.base64decode('xIGiiaKjhYmV44Wi')) concat systools.base64decode('o5SJo8KBooX29MWVg5aEhQ=='))

Beim Decode müssen es natürlich Blöcke mit einer Länge von Vielfachen von 4 Zeichen sein.

Funktioniert also problemlos.

Gruß,
KM