CPYFRMSTMF

[Rainer Ross]

Hallo Forum,

herzlichen Dank für den Tipp mit FTP und CCSID 1208 aus dem Jahr 2004. Genau bei diesem Thema hatte ich diese Woche ein Problem, das ich damit lösen konnte.

Für eine Anwendung nutze ich Open Source Geodaten von www.geonames.org In der Rubrik „Free Postal Code Data“ kann man für beliebige oder für alle Länder Daten über Land, Postleitzahl, Stadt, Admin-Namen und Koordinaten downloaden.

z.B. für Deutschland http://download.geonames.org/export/zip/DE.zip

Diese Daten liegen im UTF-8 Format = CCSID 1208 vor und müssen in die Datenbank eingelesen werden, deren Felder in CCSID 13488 definiert sind. Mit CPYFRMIMPF oder CPYFRMSTMF geht es leider nicht, darüber wurde hier schon geschrieben. Aber mit FTP funktioniert das sehr gut.

Ich habe diesen Einleseprozess automatisiert und stelle die notwendigen Schritte dar. Für das automatische unzip habe ich ein RPG Programm beigefügt, das auf die Arbeit von Simon Hutchinson aufbaut: http://www.rpgpgm.com/2014/05/2-apis...unzipping.html

• Download der Datei in das IFS mit dem Tool von Scott Klement HTTPAPI, ab V7R1 geht auch HTTPGETCLOB oder HTTPGETBLOB https://www.ibm.com/developerworks/c...0to%20SYSTOOLS

• Unzip der DE.zip mit dem beigefügten RPG Programm unzip oder mit einem CL-Programm, das die unzip-Funktion in der PASE-Umgebung benutzt

• Erzeugen einer temporären Datei mit RUNSQL. CL-Programm CRTFILE ist beigefügt

• Senden der entpackten Datei aus dem IFS in die physische Datei mit FTP und der Option „type c 1208“. Jetzt liegen die Daten in der PF in UNICODE vor und können per Programm in einzelne Felder aufgeteilt werden. Der Delimiter ist hier ein „Tab“ = Hex x‘0009‘. Tabelle für UTF-8: http://www.utf8-chartable.de/unicode...pl?number=1024

Herzliche Grüße
Rainer Ross
www.myhofi.com
schnelle und komfortable Hotelsuchmaschine mit Volltextsuche – powered by IBM i

[Fuerchau]

Wenn du schon für die Allgemeinheit so schön dokumentierst und Beispiele bzw. fertige Lösungen postest dann sprich das nächste mal bitte auch alle an.
Ich bin hier nicht der König und möchte auch nicht so persönlich und offensichtlich bevorzugt werden.
Hier im Forum sind alle gleich, deshalb auch das globale DU, selbst wenn man sich irgendwo mal trifft und ggf. auf SIE ist.

Ich bin schon zufrieden, wenn mir mal einer ein Bier mailt oder einen 50er faxt.
Schließlich gibt es hier eine Menge Leute die auch sehr gute oder bessere Lösungen offerieren.

[Rainer Ross]

Hallo Baldur,

habs geändert und die Idee mit der Bier-Mail ist wirklich nicht schlecht - natürlich frisch vom Oktoberfest

Viele Grüße

Rainer

[Sven Schneider]

Also ich habe es auch noch mal mit IBM i 7.1 probiert.
Folgendes funktioniert :

• mit Windows-Notepad eine Datei im UTF8-Format im IFS angelegt, z.B. '/app/utf8.txt'

je nach Einstellung des Netservers ggf.

• CHGATR OBJ('/app/utf8.txt') ATR(*CCSID) VALUE(1208)

• CL: CRTPF FILE(QTEMP/IMPF) RCDLEN(132) FILETYPE(*SRC) CCSID(1208)

oder

• SQL: CREATE TABLE QTEMP.IMPF (IMPORT GRAPHIC (120) CCSID 13488)

oder

• SQL: CREATE TABLE QTEMP.IMPF (IMPORT VARCHAR (120) CCSID 1208)

• CPYFRMIMPF FROMSTMF('/app/utf8.txt') TOFILE(QTEMP/IMPF) MBROPT(*REPLACE) RCDDLM(*CRLF)

CPYFRMSTMF geht auch über den Umweg SRC-File :

• CL: CRTPF FILE(QTEMP/IMPF) RCDLEN(132) FILETYPE(*SRC) CCSID(1208)

• SQL: CREATE TABLE QTEMP.IMPF1 (IMPORT GRAPHIC (120) CCSID 13488)

• CPYFRMSTMF FROMSTMF('/app/utf8.txt') TOMBR('/qsys.lib/qtemp.lib/impf.file/impf.mbr') MBROPT(*REPLACE) ENDLINFMT(*CRLF)

• CPYF FROMFILE(QTEMP/IMPF) TOFILE(QTEMP/IMPF1) MBROPT(*REPLACE) FMTOPT(*CVTSRC)

@Rainer Ross
Für deine http://download.geonames.org/export/zip/DE.zip nimmst du *LF als Format für das Zeilenende.

[Fuerchau]

Immer wieder schön wenn andere auch mal was ausprobieren.
Mir steht erst jetzt V7R1 (also noch nicht V7R2) zur Verfügung um nun Diverses auszuprobieren.
Ich kann mir auch nicht vorstellen, dass es seit 2004 keine Verbesserungen bzgl. Unicodeunterstützung geben sollte.
Mit V7 steht in SQL nun auch der Typ NCHAR/NVARCHAR zur Verfügung.
Dies ist nun endlich eine Vereinfachung da mit CCSID 1200 nun UTF-16 verwendet wird.
Dies ist ein 2/4-Byte-Code und ist mit CCSID 13488 kompatibel.
Der ILERPG-Compiler definiert das Feld auch mit Typ "C" und CCSID 1200.

[Sven Schneider]

......Mit V7 steht in SQL nun auch der Typ NCHAR/NVARCHAR zur Verfügung.
Dies ist nun endlich eine Vereinfachung da mit CCSID 1200 nun UTF-16 verwendet wird.
Dies ist ein 2/4-Byte-Code und ist mit CCSID 13488 kompatibel.
Der ILERPG-Compiler definiert das Feld auch mit Typ "C" und CCSID 1200.

NCHAR/NVARCHAR gibt es seit V6R1.
Davor konnte man aber schon Datentyp GRAPHIC/VARGRAPHIC mit CCSID 1200 verwenden, was zum gleichen Ergebnis führt.

[Sven Schneider]

Immer wieder schön wenn andere auch mal was ausprobieren....

Meine Vermutung ist, das Unicode-Support für CPYFRMIMPF/CPYFRMSTMF auch für V6R1 schon funktioniert hat, ggf. sogar mit V5R4.
Leider kann ich das nicht mehr ausprobieren.

...Mit V7 steht in SQL nun auch der Typ NCHAR/NVARCHAR zur Verfügung.
Dies ist nun endlich eine Vereinfachung da mit CCSID 1200 nun UTF-16 verwendet wird.
Dies ist ein 2/4-Byte-Code und ist mit CCSID 13488 kompatibel.
Der ILERPG-Compiler definiert das Feld auch mit Typ "C" und CCSID 1200.

NCHAR/NVARCHAR gibt es seit V6R1.
Davor konnte man aber schon Datentyp GRAPHIC/VARGRAPHIC mit CCSID 1200 verwenden.

[Fuerchau]

Dass man CCSID 1200 schon vorher verwenden konnte war mir schon klar.
Es tauchte aber leider immer mal wieder die Frage auf, was 1200/13488 denn mit "Graphic" zu tun hat.
Da ist die Angabe NCHAR doch schon sprechender, da diese auch in anderen Dialekten verwendet wird und eine CCSID-Angabe nicht mehr erforderlich ist.