Wieder mal CCSID und IFS

[Fuerchau]

Nun ja, Grundsatzfehler gehören bestraft;-).
Wenn die Systeme eine gültige CCSID hätten (also QCCSID <> *HEX) hättet ihr wahrscheinlich nichts bemerkt.

Mit welchem SFTP transportiert ihr die Daten?
Falls mit dem aktuellen FTP-Kommando, so hat dies einen CCSID-Parameter, der wahrscheinlich auf *DFT steht. Der Default hat sich wahrscheinlich geändert, von 819 auf 1208 (UTF8).

Wenn aber euer Job keine gültige CCSID hat, kann UTF8 nicht verarbeitet werden, da das System nicht weiß in welchen Code die Daten umgesetzt werden.

Mit welcher Methode lest ihr die Daten ins RPG? Irgendwo muss ja eine Umsetzung von 819 in 273/1141 erfolgen.

Aber auch 819 ist eine schlechte Wahl, da von Windows aus 1252 besser wäre und dies seit V5R3 oder sogar früher unterstützt wird.

Fazit:
Prüfe die CCSID-Werte des FTP-Kommandos.
Setze die QCCSID passend zu euren Dateien. DDS/SQL-Tables haben immer eine CCSID.
Dann klappts sogar bei ODBC besser.

[wolfgang.w]

Hallo Fuerchau

Der mit dem Grundsatzfehler erschliesst sich mir jetzt nicht wirklich. Auf dem alten System läuft ja alles bestens...

Der Transportkanal ist das 'normale' SFTP des Systems (QP2SHELL) mit dem public und private key und wird mit 'sftp RMTUSER@commpartner.com' gestartet. Im Gegensatz zum normalen FTP habe ich bei SFTP keinen Parameter für die CCSID gefunden.

Nach der gesicherten Anmeldung erstellt ein Befehl (ls -1) ein Inhaltsverzeichnis des Servers als IFS-Logfile. Dieses Logfile hat bereits 1208 welches auf der alten Maschine 819 hatte. Bis zu diesem Punkt hatte ich keine Möglichkeit irgendwo eine CCSID zu bestimmen bzw. ich habe keine solche Möglichkeit gefunden.

Das Logfile wird dann mittels einem RPG Programm mit fopen und readonly geöffnet und durchgelesen. Der fopen geht schief wenn das Logfile 1208 hat. Mit 819 klappt es.

Es ist mir klar, dass man die Datei mit einer Angabe von CCSID öffnen könnte oder zuvor wie bereits erwähnt einen CHGATR machen. Aber es sind eben viele Jobs und noch mehr Dateien.

Ich kapiere einfach nicht warum die Umsetzung auf dem neuen System nicht gleich funktioniert wie auf dem alten.

Zu Deinen Empfehlungen:
- es handelt sich nicht FTP sondern wie oben beschrieben um SFTP via QP2SHELL
- es handelt sich nicht um DDS oder SQL Dateien sondern um reine IFS Files

[Fuerchau]

Ein CHGATR führt dann zum Fehler wenn tatsächlich UTF8-Daten enthalten sind.
Da reicht ein Umlaut.

Klar funktioniert alles mit CHRID 65535, aber nur innerhalb des Systems.
Bei allen Aussenverbindungen benötigt man zusätzliche Klimmzüge die mit einer CCSID nicht erforderlich sind.
Aber da rede ich schon seit 25 Jahren gegen an und es wird immer noch grundsätzlich erst mal 65535 installiert und dann nie geändert. Dabei haben alle Systemtabellen schon immer eine CCSID gehabt.
Wenn dann Internationalität benötigt wird greift man zu komplexen Szenarien mit gretrennten Libs u.ä. Alles vollkommen unnötig, zumindest seit V5R4.

Die Ursache siehst du im Übrigen hier:
https://www.ibm.com/support/knowledg...sPASEccsid.htm

"Setting the environment variable PASE_DEFAULT_UTF8 to "N" in the current job will allow the prior behavior to be used".
Dies kannst du auch als Systemvariable setzen.

[wolfgang.w]

Vielen Dank für den Tip mit der environment variable PASE_DEFAULT_UTF8. Genau das war das Problem. Meine bereits 32 jährige Erfahrungen mit den Midrange-Systemen hat eine solche (doch essentielle) Änderung zwischen den Releases jetzt nicht erwartet. Wenn es sich um ein Microsoft Produkt handelt ist man sich einen 'Umkehrparameter' zwischen den Versionen ja schon fast gewohnt. Dass IBM jetzt auch damit anfängt ist schade und vereinfacht die Arbeit nicht wirklich.

Nochmals herzlichen Dank!
Wolfgang

[Fuerchau]

Ich denke mit dieser 32-jährigen Erfahrung wärst du auch darauf gestoßen.

[MoellerH]

Hallo Herr Fuerchau, ich lese aus dem IFS: OpenFile(%addr(PathFile):%addr(OpenMode)),
If (ReadFile(%addr(RtvData):32767:FilePtr)) = *null;
weil ich immer ganze Sätze (CSV-Datei) haben möchte. Dies funktioniert auch wunderbar. Nun habe ich wegen der falschen Darstellung der Umlaute in der PF die CSV auf CCSID
1208 umgestellt.
Beim OpenFile krachts, aber ohne Fehlermeldung.
Was könnte ich tun ?
Vielen Dank für Ihre Unterstützung.
Gruss
Heinrich Möller

[Fuerchau]

Da gibts mit Sicherheit eine Fehlermeldung.
a) bist du sicher, dass es UTF8 ist?
b) steht deine Job-CCSID vielleicht wieder auf 65535?
Aber warum immmer wieder die C-Funktionen?
Diese können nur in die Job-CCSID umwandeln und nicht z.B. in Unicode (nvarchar oder RPG-Typ C).

Im Forum immer wieder diskutiert funktioniert hier SQL besser.
Suche mal nach SQLTYPE(CLOB_FILE).
Seit V7R3 gibts nun auch SQL-Funktionen IFS_READ/IFS_WRITE.

Und ansonsten duzen wir uns im Forum;-).

[MoellerH]

Ok, vielen Dank. Hört sich plausibel an, ich verabschiede mich mal von den C-Funktionen.
Weißt du wo ich unter RDI die erforderliche Lib. QSYSINC eintragen muss ?

[Fuerchau]

DIE brauchst du dafür überhaupt nicht. Da sind nur API Strukturen und Prototypes drin.
Google mal hier im Forum nach SQLTYPE und CLOB_FILE.

[B.Hauser]

Die Funktionen IFS_READ / IFS_READ_BINARY / IFS_READ_UTF8 befinden sich ebenso wie die Stored Procedures IFS_WRITE / IFS_WRITE_BINARY / IFS_WRITE_UTF8 in der Bibliothek QSYS2 (die im Systemteil der Bibliotheksliste hinterlegt ist).

Die Arbeit mit Large Object (LOB) File Reference Variables ist von daher etwas tricky, dass Du ein Standalone Field mit SQLTYPE definierst, und der SQL PreCompiler daraus eine Datenstruktur macht. Mit RPG sprichst Du die Datenstruktur-Unterfelder an, mit SQL die Variable (bzw. Datenstruktur). Mit SQL-Befehlen und Funktionen (z.B. SELECT ... INTO / SUBSTR ...) kann die IFS-Datei dann behandelt werden als wäre sie ein ganz gewöhnliches alphanumerisches Feld.
LOB file reference variables in ILE RPG applications that use SQL

Birgitta