Umsetzung von Umlauten

[DEVJO]

Hallöchen kurze Frage,

ich importtiere Daten von einem fernen Server in ASCII auf unsere AS/400. Diese Daten werden dann in unsere Datenbank eingepflegt und sind hinterher für andere Kunden verfügbar. Mein Problem sind nun die Umlaute, da hier immer andere Zeichen genommen werden. Hat jemand eine Idee, wie ich das ohne Programmgesteuerte Umsetzung, sprich Programm interne Tabellen oder so bewerkstelligen kann? Ich habe einen Parameter beim umwandeln gefunden, LANGID diesen habe ich jetzt mal auf DEU gesetzt und bei der Datei, welche gefüllt wird habe ich den Parameter CCSID gefunden, ich habe noch irgendwie im Hinterkopf das man da eine 887 für die Schweizer Tabelle einsetzen kann und dann die Umlaute richtig kommen, stimmt das.
Ich kann leider nicht testen, da die nächsten Daten irgendwann heute Nacht kommen und ich nicht vor hatte dann in der Firma zu sein:-)

[Fuerchau]

Mit welchem Befehl werden die Daten importiert ?
Wenn die Daten vom PC kommen, gibt es 2 Varianten:
ASCII = Codpage 850
ANSI = Codepage 1252

Die Codepage kann direkt angegeben werden.

Das gleiche gilt für die Zieldatei. Hier sollte dann die CCSID 273 (Deutsch) verwendet werden.

[DEVJO]

Die Daten werden über einen bestimmten Port importiert mittels eines ILE RPG Programmes, also OPNSOCK, RECV usw.
dann von ASCII in EBCDIC mittels des API´s QDCXLATE übersetzt, dann werden sie in die Datei gespeichert.

[Fuerchau]

Dann ist nur die korrekte Umsetztabelle auszuwählen !
Über WRKTBL Q85* sollte die richtige zu finden sein.
Q850337273 stimmt für ASCII->EBCDIC

Besser sind da folgende API's:
http://publib.boulder.ibm.com/iserie.../apis/nls3.htm

Diese arbeiten nicht mehr mit TBL-Objekten sondern bieten die gleiche Funktion wie sie die DB auch nutzt.
Durch die direkte Angabe der gewünschten CCSID's (850->273, 1152->273) spart man sich das mühsame Suchen der passenden Tabelle.

Alternativ kann man auch eine neue Tabelle erstellen (CRTTBL).
http://publib.boulder.ibm.com/iserie.../cl/crttbl.htm

[DEVJO]

Also einfach da wo ich jetzt QASCII drin stehen habe Q850337273 eintragen?

[Fuerchau]

Wie Radio Eriwan: Im Prinzip ja !

Aber:

Mittels WRKTBL und Auswahl 5 kannst du dir die Tabelle anzeigen um die Unterschiede festzustellen.
Schau dir den generierten Hexcode in deiner Datei für irgendeinen Umlaut an.
Suche diesen in der Tabelle QASCII in der Spalte Hex-Ausgabe.
Der Wert in Spalte HEX-Eingabe ist der ASCII-Code, den du bekommen hast.
Zeige dir die Tabelle Q850337273 an und ermittle den neuen Ausgabecode an Hand des gerade ermittelten Eingabecodes.
Stimmt der nun mit deinem gewünschten Hex-Code für den Umlaut überein (ermittle den vorher z.B. mittels DSPPFM und F11) scheint das die richtige Tabelle zu sein.

Ist dies nicht der Fall, kommt wahrscheinlich nicht 850 an sondern 1252 (Windows-Ansi). IBM hat hier leider keine Standardtabelle (ich hab noch keine gefunden).
Dann hilft nur, neue Tabelle erstellen bzw. obige API's verwenden.

[angelone]

Aktion "Alter Thread nach oben 2005"

ich hab hier das selbe problem.
nur finde ich alles etwas merkwürdig.

und frag mich jetzt wer hier zu hohl is zeichen umzusetzen.
ibm oder ich

ich bekomme über meine socket verbindung vom windows server iso-8895-1
also codepage 819

und benutze jetzt zur umsetzung die tabelle Q819337273
ich teste hier die ganze zeit rum mit dem "è"
in iso-8895-1 ist das dezimal 233 / x'E8'

in dieser tabelle steht jetzt, dass x'E8' umgestetzt werden soll auf x'AE'
x'AE' ist aber jetzt ein "þ" (was immer das darstellen soll)

und definitiv kein "è" was ja im EBCDIC ein x'54' ist.

wo könnte jetzt das problem liegen?
kann nicht glauben, dass diese tabelle einfach falsch ist...

edit:
zieldatei hat ccsid 273
system hat ccsid 65535
job hat ccsid 65535

[Fuerchau]

ISO-8859-1 ist ANSI und entspricht der CP 1252 von Windows !
Dafür gibts leider kein TBL-Objekt.
Aber wenn du schon firm mit C-Api's bist, dann nutze doch die nachfolgenden API's:
http://publib.boulder.ibm.com/iserie...s/iconvopn.htm
http://publib.boulder.ibm.com/iserie...apis/iconv.htm
http://publib.boulder.ibm.com/iserie...s/iconvcls.htm

[angelone]

aha! da liegt der hund begraben
irgendwer meinte das iso-8859-1 sei cp819

was wäre denn dann 819? gibts da auch eine iso norm zu?
dann sag ich dem windowsprogger er soll mir 819 schicken
dann kann ich die tabelle ja benutzen

die apis hatte ich mir auch schon so angeguckt.
aber ich brauch da immer RPG beispiele.
rein aus der doku von ibm werd ich nie so schlau.

[Fuerchau]

CP819 galt früher mal als ANSI ist aber nicht ganz durchgängig.
Verwende einfach folgendes Beispiel:

d CDRCVRT pr extpgm('CDRCVRT')
d CCSID1 10I 0
d ST1 10I 0
d S1 32766 options(*varsize)
d L1 10I 0
d CCSID2 10I 0
d ST2 10I 0
d GCCASN 10I 0
d L2 10I 0
d S2 32766 options(*varsize)
d L3 10I 0
d L4 10I 0
d FB 12
d ConvParm ds
d CCSID1 10I 0 inz(1252)
d ST1 10I 0 inz(0)
d S1 100 inz
d L1 10I 0 inz(%size(S1))
d CCSID2 10I 0 inz(273)
d ST2 10I 0 inz(0)
d GCCASN 10I 0 inz(0)
d L2 10I 0 inz(%size(S2))
d S2 100 inz
d L3 10I 0 inz
d L4 10I 0 inz
d FB 12
d FBCodes 10I 0 overlay(FB) dim(3)

c/free
S1=x'E8';
CDRCVRT(
CCSID1
:ST1
:S1
:L1
:CCSID2
:ST2
:GCCASN
:L2
:S2
:L3
:L4
:FB
);

Quelle: http://publib.boulder.ibm.com/iserie...is/CDRCVRT.htm
Dies API ist einfacher zu programmieren.

[angelone]

sauber
vielen dank.

da kommen ja tatsächlich die richtigen zeichen raus.
hatte schon die hoffnung verloren

ich hab hier zwar probleme mit den varlengths aber das macht nix
wenn ich der funktion nen string übergebe der kürzer ist (mein "inputstring"), als das was da in der datenstruktur bei S1 angegeben ist, wird der rest mit "@" gefüllt.

hab dann in S2 sowas wie "hello@@@@@@@@@@"
kann man mit %len(%trim(inputstring)) machen. dann weiss man wie lang der string mit den vielen @ eigentlich sein sollte.
und dann n output=%subst(S2:1:%len(%trim(inputstring)))
aber schön is das nicht...

[Fuerchau]

In L1 wird die zu übersetzende Länge vorgegeben (Siehe Beschreibung).