CPYTOIMPF mit Ergebnisfeldern aus QUERY

[spiceisnice]

Bei V5R3 sind jede Menge PTF'S Voraussetzung um den glichen Stand/ergbensi wie V5R2 zu erreichen - suche nach CPYTOIMPF im iSeries Forum, da gabs erst vor Kurzem was dazu.

[Jenne]

Habe mein USRPRF auf die richtige CSSID gesetzt und jetzt klappt es.

Danke für die Hilfe
Jenne

[Proggi]

Hallo Jenne,

es wäre schön, wenn Du hier kurz schreiben würdest, welche CSSID Du genommen hast, damit andere Personen mit dem gleichen Problem hier direkt die Antwort lesen können.

Danke.

[Jenne]

Sorry,
habe die CSSID = 1141 genommen.

Gruß
Jenne

[Klaus Söllner]

Nach der Umstellung auf V5R3 sind auch wir nun in den "Genuss" dieser vielfältigen Probleme mit CPYTOIMPF und CPYFRMIMPF gekommen. Sämtliche PTFs zu dem Thema sind installiert, helfen aber allesamt nichts! Ein ziemlich dicker Hund von IBM, zumal man sich nicht wirklich auf die Lösung der nach dem Update akut anstehenden Probleme vorbereiten kann (außer vorab Freiraum für Überstunden einzuplanen).

Konkret zu dem Problem von Jenne: Auch wir haben einige Query-Outputs, die wir als Datenschnittstelle per CPYTOIMPF ins IFS kopieren. Generische Felder (z.B. Substr oder im Query definierte Zeichenkonstanten) hatten in der physischen Ausgabedatei CCSID 65535, was unter V5R1 nicht gestört hat. Nun werden diese Felder aber auf einmal falsch transferiert - danke, IBM!

Zunächst habe ich nach Möglichkeiten gesucht, die CCSID im Query festzulegen, habe aber nur die Funktion VARCHAR gefunden, die dafür Probleme mit der festen Feldbreite mit sich bringt.

Der Tip mit der CCSID im Benutzerprofil war Gold wert! Ich habe gleich den globalen Systemwert QCCSID auf 273 gesetzt und alle betroffenen Queries neu gespeichert. Problem gelöst, aber mein Unmut gegenüber IBM wird sich wohl noch lange Zeit nicht legen.

[Fuerchau]

Das ist das allgemeine Problem, dass sehr häufig mit CCSID 65535 gearbeitet wird.
Der Systemwert sollte eine gültige CCSID haben, DDS-Dateien ebenso.

Wenn man dieses immer berücksichtigt, gibt es eher selten Probleme (auch anderswo).

Ich hatte auch mit V5R3 KEINE Probleme mit CPYFRM/TOIMPF, da ich schon seit V2R2 mit einer korrekten CCSID arbeite

[Klaus Söllner]

Wenn man dieses immer berücksichtigt, gibt es eher selten Probleme (auch anderswo).

Ich hatte auch mit V5R3 KEINE Probleme mit CPYFRM/TOIMPF, da ich schon seit V2R2 mit einer korrekten CCSID arbeite

Naja, gut und schön, aber ganz so pauschal kann man die Sache dann auch nicht abhaken. Das oben geschilderte Problem ist ja nur eines von vielen.

Dass z.B. FTP Dateien standardmäßig mit CCSID 819 im System landen, was bis V5R2 kein Problem mit CPYFRMIMPF darstellte...

Dass nun auf einmal Leerzeichen in der Ausgabe von CPYTOIMPF erscheinen, die vorher nicht da waren...

Dass die Breite gepackter Felder in der Ausgabe von der Vorversion abweicht...

...alles Sand im Getriebe, der in meinen Augen völlig unnötige Schikane darstellt. Oder kann mir irgendjemand einen konkreten Vorteil dieser Modifikationen nennen?

[Klaus Söllner]

Es nimmt einfach kein Ende: gerade ist eine weitere Fallgrube mit diesen unsäglichen Programmen aufgetreten!

Früher wurde von CPYFRMIMPF die Escape-Nachricht CPF2817 abgesetzt, falls einzelne Sätze aufgrund von Datenfehlern (z.B. ungültige Dezimaldaten) nicht kopiert werden konnten. Nun landen diese Sätze zwar immer noch in der Fehlerdatei (Parameter ERRRCDFILE), aber das Programm gibt keine Escape-Nachricht mehr aus, die man im CL abfangen könnte. Ergo muss ich alle meine Fehlerroutinen umstricken, und auf die Satzanzahl der Fehlerdatei prüfen. Dies ist nicht nur äußerst unelegant, ich kann auch im Batch nicht mehr gezielt die Weiterverarbeitung der einzelnen Quelldateien ansteuern, ohne noch einen weiteren Zwischenschritt einzubauen.

Wenn ich nur wüsste, wem ich den Schlamassel um die Ohren hauen könnte...

[usche]

Schau dir doch mal das PTF SI18900 an.

[Klaus Söllner]

Schau dir doch mal das PTF SI18900 an.

Danke für den Hinweis. Das PTF ist bereits installiert, bringt aber nichts. Dieses PTF reaktiviert die Abbruchnachricht CPF2817 lediglich bei Fehlern mit doppelten Satzschlüsseln, nicht aber bei Umsetzungsfehlern aufgrund ungültiger Daten.