PDA

View Full Version : CPYTOIMPF und CCSID - Codepage - FROMCCSID



Erol
23-11-20, 10:03
Liebe Forum-Gemeinde,
noch einmal eine Frage zu CPYTOIMPF: Bei der Übertragung einer vorhandenen Datei in das IFS bekomme ich die korrekte Darstellung nicht hin.

Meine Datei hat überwiegend Felder, die mit dem Zeichensatz 273 definiert sind, allerdings einige auch mit dem Zeichensatz 65535.

Ich habe die Übertragung schon mit
FROMCCSID = *FILE und mit FROMCCSID = 273 probiert.

Beispiele:
CPYTOIMPF FROMFILE(XER/DTFBSP) TOSTMF('/home/Test/b_file.txt') MBROPT(*REPLACE) FROMCCSID(*FILE) STMFCCSID(1252) RCDDLM(*CRLF) DTAFMT(*FIXED) STRDLM(*NONE) DECPNT(*COMMA)

CPYTOIMPF FROMFILE(XER/DTFBSP) TOSTMF('/home/Test/b273.txt') MBROPT(*REPLACE) FROMCCSID(273) STMFCCSID(1252) RCDDLM(*CRLF) DTAFMT(*FIXED) STRDLM(*NONE) DECPNT(*COMMA)


Bei allen bekomme ich an der einen oder anderen Stelle fehlerhafte Daten in der PC-Datei.

Wenn ich dieselbe Datei mit der Datenübertragungsfunktion *.dtfx in das IFS kopiere werden alle Felder richtig dargestellt.

Hier ein Ausschnitt der Datenübertragungsfunktion:

[DataTransferFrom]
DataTransferVersion=1.0
[HostInfo]
Database=*SYSBAS
HostFile=xer/dtfbsp
HostName=AS400
[ClientInfo]
OutputDevice=2
FileEncoding=UTF-8
ClientFile=\\as400/root/home/Test/b_dtfx.txt
ClientFileType=1
SheetNumber=2
SaveFDF=0
FDFFile=\\as400\home\Test\bsp7.fdfx
CrtOpt=1
TruncateTrailingSpaces=1
TextHeadingsOn=0
TextHeadingsAreColumnNames=0
LineEnding=1
LFInLineEnding=0
CRInLineEnding=0
PadNumericFields=1
PadNumericFieldsWithLeadingSpaces=1
[SQL]
Select=*
[Properties]
Convert65535=1
StoreDecFAsChar=1
SQLStmt=0
UserOption=0
UseSSL=2
[Options]
DecimalSep=,
IgnoreDecErr=1

Hat jemand eine Idee, wie ich die Daten auch mit CPYTOIMPF sauber in das IFS bekomme?
Im Voraus vielen Dank für eure Rückmeldung.

Fuerchau
23-11-20, 13:29
CPYTOIMPF nutzt intern nur SQL, somit sind Binärfelder (CCSID 65535) eben Binärfelder.
Bei der Übertragung per ODBC gibts aber schon länger die Einstellung:
Convert65535=1
Damit werden Binärfelder wie Textfelder in ANSI übertragen. Allerdings ist dies nicht Sache von SQL sondern des ODBC/OLEDB-Treibers.

Die Frage ist, warum in deiner Datei gemischte Textfelder mit CCSID x und 65535 überhaupt vorhanden sind.
Mach doch einen entsprechenden Alter Table und setze die CCSID korrekt.

Erol
23-11-20, 14:06
Hallo Baldur,
vielen Dank für die rasche Rückmeldung.
Die CCSID 65535 entstehen durch mit SQL erstellte Felder wie

trim(char(fld1)) concat trim(char(fld2)) as FLD3 oder
ifnull(FLD4, ' ') as FLD4.

Die zu verarbeitenden Dateien kommen allerdings aus verschiedenen Quellen, die ich nicht immer ändern kann.

Ist es möglich den Default für die Erzeugung von Feldern mit SQL auf eine andere CCSID als 65535 zu hinterlegen? Z. B. CCSID 273?

Oder kann mit einem Alter Table Befehl gleichzeitig für alle Spalten einer temporären Datei die CCSID gesetzt werden?

BenderD
23-11-20, 14:11
... in einer SQL View kann man (fast) alles nach (fast) jedem casten und die View dann im CPYTOIMPF verwenden.

D*B

Fuerchau
23-11-20, 14:25
Der Default bei SQL für CHAR oder VARCHAR ist eine gültige CCSID. Hat der Job oder das System 65535, wird die CCSID aus der aktuellen Sprache entwickelt.
Dies betrifft aber ausschließlich den CREATE TABLE.

Felder ohne CCSID müssen explizit als BINARY definiert werden.
DDS-Tabelle, CRTPF, können aber tatsächlich auch eine CCSID 65535 auf Datei oder Feldebene aufweisen.

Baut man allerdings eine View auf eine DDS-Tabelle, wo hier die Datei/Felder eine CCSID 65535 enthalten, bekommt eine Funktion CHAR(binary) wiederum CCSID 65535.

Ansonsten kannst du statt "char" auch die Castfunktion:
cast(fld1 as char(nn) ccsid 1141)
verwenden, wie Dieter ja schon schrieb.

Erol
23-11-20, 14:51
Vielen Dank für eure Antworten.
Schade, dass es bei CPYTOIMPF nicht auch eine Option wie bei ODBC mit Convert65535=1 gibt.

Ich werde versuchen alle Quellen nach "create table" zu durchforsten, um überall, wo neue Spalten erzeugt werden, den CAST mit Angabe der ccsid 273 einzufügen oder reicht etwa nur der CAST-Befehl ohne Angabe der ccsid?

BenderD
23-11-20, 15:34
... die PFs würde ich ohne genaueste Prüfung nicht anfassen. Solche Wackelhaufen funktionieren meist nur zufällig. Für die Exporte Views anzulegen reicht aus.

D*B

Fuerchau
23-11-20, 15:40
Du musst nicht Create Table durchsuchen, sondern Create View.
Schau dir mal per DSPFD die jeweilige Tabelle(PF)/View(LF) an.
Ist es eine TABLE/VIEW, steht der Create drin.
Ist es eine PF kannst du per DSPOBJD => Auswahl 8 die Quellinformation ansehen.
Schau dir per DSPFFD die Feldinformationen auch bzgl. CCSID an
Bei PF's steht ggf. die CCSID bereits auf Dateiebene (DSPFD).

Du kannst dir auch eine View von einer View basteln, wenn berechnete Felder vorkommen.

Erol
24-11-20, 11:09
Vielen Dank für eure Tipps.
Es geht hier ausschließlich um temporär erzeugte Arbeitsdateien, sie werden in der Regel dynamisch mit embedded SQL auf Basis von Tabelleneinträgen erzeugt. Diese Tabelleneinträge werde ich auf die entsprechenden Stichwörter hin untersuchen.