CPYFRMIMPF (Tausenderpunkt)

[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.

[Robi]

Stimmt!
Häufig sind CSV Dateien Excel 'Masken', erstellt vom Neffen vom Chef, in denen der Anwender ALLES machen kann.
Bsp.:
Datum der Abgabe: 08.04.2014, 14/04/08, 20140408 ,"Schnellstens"
Monat der Fertigstellung: Januar, Jan, 01, 01/2014, "bald"
Wert: 15,00 oder 1.500,99 oder "steht noch nicht fest"

fröhliches Schnitstellen gestalten mit SQL

[BenderD]

... CPYFRMIMPF ist lediglich ein dümmlicher Name. Andere Datenbanken nennen solche Routinen load und unload. Sprich: die CSV Files kommen aus einer Datenbank, werden transportiert und dann landen sie wieder in einer anderen Datenbank - und wenn die Tabellen zueinander passen, dann geht das alles.
Für "echten" Schrott (Datum schnellstens etc.) hat CPYFRMIMPF die beiden Parameter ERRLVL, ERRRCDFILE und ERRRCDOPT (F1 und lesen macht schlauer). Mit den Tausenderpunkten ist das so eine Sache, das könnte CPYFRMIMPF händeln und sollte es wohl auch tun. EIn search/replace ist wohl zu wenig, der würde auch "." in Strings entfernen, sich dafür einen Filter zu schreiben, sollte wohl jeder Programmeur-AZUBI hinbekommen...

D*B

[E305GL]

bin zufällig auf diesen beitrag gestossen; wie wurde das problem tatsächlich gelöst ?