CPYFRMIMPF (Tausenderpunkt)

[Fuerchau]

CPYFRMIMPF ... DECPNT(*PERIOD)
Wenn das mangels Dezimalpunkt auf einen Fehler läuft, kannst du dann alternativ einen 2. Aufruf mit
CPYFRMIMPF ... DECPNT(*COMMA)
durchführen.

[Robi]

Der tausender Punkt in dem 'Numerischen' Feld macht das Feld zu einem Alpa Feld.
Ich glaube nicht das du den so wegbekommst.
Also: Zieldatei mit Alpa-Feldern definieren und per Pgm nach der Übername in die eigendliche Zieldatei umschubsen. Wir haben nur in den seltensten Fällen CSV-Datei Lieferanten, bei dehnen ein Num Feld
immer als NUM-Feld kam !
Robi

[Fuerchau]

CPYFRMIMPF ... DECPNT(*PERIOD)
hat bei mir immer geholfen.

[Robi]

Ok, das wäre mir neu.
*period ist bei uns der voreingestellte Wert.
Bleibe aber bei der 'zuerst nach Alpa' Methode. In eine CSV Datei kann sooooo viel Mist stehen.
(Bsp: Datumsfeld: kommt 5 mal als ttmmJJJJ und dann als 'schnellstens'

Robi

[fpxx]

Konkret steht in einem Datenfeld z.B. der Inhalt

1.750,00

In der Zieldatei der AS400 ist das Datenfeld mit 9 Stelllen, davon 2 Dezimalstellen definiert

Bei CPYFRMIMPF DECPNT(*COMMA), was dem Kommazeichen entspricht, können alle Inhalte < 1000 übernommen werden, die höheren, wenn mit Tausenderpunkt, werden nicht übernommen.
Bei DECPNT(*PERIOD) werden keine Sätze übernommen.

Ich kann mir auch nicht vorstellen, dass ein Parameter, der das Dezimalzeichen steuert, auch den Tausender-Punkt regelt.

[KingofKning]

Tja die hilft Dir wohl nur der Import in Excel und dann wieder als CSV speichern. Vielleicht kannst Du ja auch mit einem Editor . suchen und durch nichts ersetzen.GG

[fpxx]

Das sollte ein automatisierter Ablauf sein.

Wenn ich CSV als Excel öffne, habe ich das nächste Problem, dass dann andere Felder mit sehr langen "rein numerischen Inhalten" (zB. Tel.Nr. mit Ländervorwahl + Ortsvorwahl usw.) dann automatisch mit "E-Inhalten" im Excel dargestellt werden und beim Speichern (als CSV-Datei) dann auch mit diesen (unbrauchbaren) Inhalten gespeichert werden.

Hat dieses Problem mit den Tausenderpunkten bisher noch niemand gehabt?

[Robi]

Doch, hab ich doch geschrieben.
Definiere ALLE Felder der Zieldatei als alpa.
Schreibe ein mini Pgm, das via input/output die Felder prüft, formatiert und so ausgibt, wie du es brauchst.
Läuft hier bestimmt mit 20 Schnittstellen so!
Robi

[KingofKning]

Und was hälst Du dann davon, die Datei in eine Zwischendatei zu importieren, das Feld per SQL zu ändern und entweder dann per SQL in die richtige Datei schreiben Alpha-Feld per Cast in numerisch wandeln oder zu exportieren und dann in die richtige Datei zu importieren.Dürfte nicht viel Zeit kosten das zu realisieren. Alternativ habt Ihr jemanden der Cobol oder RPG kann.GG

[Fuerchau]

1000er Trennzeichen werden tatsächlich von SQL nicht unterstützt.
CPYFRMIMPF verwendet intern nämlich SQL.
Um die Daten per SQL zu verarbeiten ist ein Replace der Punkte mit "Nichts" erforderlich um anschließend per CAST(TRIM(...)...) in Dezimal zu wandeln.
Also, wie der Vorredner schon sagt:
Importdatei mit Alphafeldern, SQL-View über die Alphafelder mit erforderlichen Casts.
Dann kann locker die View verwendet werden.

[fpxx]

Danke für Tipps; ich werde wohl die SQL-Variante verwenden.

Trotzdem schade, dass es keinen "eigenen" Parameter im CPYFRMIMPF gibt (ähnlich zu DECPNT oder RPLNULLVAL).
Da ist wohl IBM gefordert. ;-)

[AG1965_2]

Oder man lässt csv-Dateien von Programmierern erstellen, die wissen, was sie tun.
Nicht für jeden Schrott ist gleich IBM aufgerufen, was zu tun.