CPYTOIMPF nur bei DDS beschriebenen Dateien?

[ChristophS]

Hallo zusammen.

Ich hoffe ich mache hier kein altes Faß auf und wenn ja, dann bitte ich um Nachsicht.
Seit dem bei uns V6R1 installiert ist, habe ich Probleme mit dem cpytoimpf. PTF's sind aktuell.

Beispiel:
rmvblank(*trailing) entfernt nicht die Leerzeichen bei Feldern, die mit VARLEN definiert wurden, sondern ersetzt sie mit HEX 00. Was natürlich beim Import durch andere Programme für viel Heiterkeit sorgt.
Umgehen kann man das Ganze, wenn man den Feldinhalt beim Schreiben trimmt. Naja, nicht schön aber selten. Dies nur Info für Leidensgenossen.

Jetzt habe ich aber eine mit SQL (iSeries Naviagtor) erstellte Tabelle, die sich überhaupt nicht exportieren läßt.
Pumpe ich die Daten via SQL in eine DDS beschriebene Datei habe ich keine Probleme. Die SQL-Tablle besteht zum großen Teil aus varchar-Feldern.

Fehler aus dem JOBLOG:
-Speicher-Offset X'00019BD7'....liegt außerhalb der aktuellen Grenze....
The pointer parameter passed to free or realloc is not valid.
Die angeforderte Heap-Space-Operation ist ungültig.

Frage:
Funktioniert CPYTOIMPF nur bei Tabellen ohne VARCHAR oder VARLEN oder hat der Fehler eventuell eine noch andere Ursache?
Gibt es eine andere Möglichkeit direkt von der iSeries solche Dateien via SQL, RPG, CL oder Java zu exportieren?
Ich möchte, wenn es geht darauf verzichten die Tabelle durch eine DDS-beschriebene Tabelle zu ersetzen oder eine Zwischendatei zu basteln.

Ich hoffe jemand hat eine Idee.
freundliche Grüße
Christoph

[Fuerchau]

Da würde ich doch glatt eine Fehlermeldung an IBM abschicken.
Wobei ich nicht weiß, ob VARLEN früher schon korrekt behandelt wurde.

Ansonsten:
Java mit JDBC (Javatoolkit) geht immer, mit ILERPG wirds etwas schwieriger, aber auch lösbar.

SQL exportieren geht über einen Umweg mit z.B. QMQRY:
select char(Feld1) concat ";" concat ...
from myfile
STRQMQRY in Ausgabedatei
CPYTOIMPF ohne weitere Konvertierungen ausser *CRLF

[BenderD]

ergänzend zu Baldur: CPYTOIMPF und CPYFRMIMPF sind das Pendant zu load/unload anderer SQL Datenbanken und bei der Übertragung großer Datenbestände eher schneller als Satz orientierte Methoden.
Java geht natürlich immer (auf meiner Open Source Seite gibt es da auch ein kleines Tool).

D*B

Hallo zusammen.

Ich hoffe ich mache hier kein altes Faß auf und wenn ja, dann bitte ich um Nachsicht.
Seit dem bei uns V6R1 installiert ist, habe ich Probleme mit dem cpytoimpf. PTF's sind aktuell.

Beispiel:
rmvblank(*trailing) entfernt nicht die Leerzeichen bei Feldern, die mit VARLEN definiert wurden, sondern ersetzt sie mit HEX 00. Was natürlich beim Import durch andere Programme für viel Heiterkeit sorgt.
Umgehen kann man das Ganze, wenn man den Feldinhalt beim Schreiben trimmt. Naja, nicht schön aber selten. Dies nur Info für Leidensgenossen.

Jetzt habe ich aber eine mit SQL (iSeries Naviagtor) erstellte Tabelle, die sich überhaupt nicht exportieren läßt.
Pumpe ich die Daten via SQL in eine DDS beschriebene Datei habe ich keine Probleme. Die SQL-Tablle besteht zum großen Teil aus varchar-Feldern.

Fehler aus dem JOBLOG:
-Speicher-Offset X'00019BD7'....liegt außerhalb der aktuellen Grenze....
The pointer parameter passed to free or realloc is not valid.
Die angeforderte Heap-Space-Operation ist ungültig.

Frage:
Funktioniert CPYTOIMPF nur bei Tabellen ohne VARCHAR oder VARLEN oder hat der Fehler eventuell eine noch andere Ursache?
Gibt es eine andere Möglichkeit direkt von der iSeries solche Dateien via SQL, RPG, CL oder Java zu exportieren?
Ich möchte, wenn es geht darauf verzichten die Tabelle durch eine DDS-beschriebene Tabelle zu ersetzen oder eine Zwischendatei zu basteln.

Ich hoffe jemand hat eine Idee.
freundliche Grüße
Christoph

[ChristophS]

Danke, für die Antwort.
Wie es aussieht komme ich wohl nicht um die IBM herum.

Dann werde ich wohl solange die Daten via SQL-function(insert into xx (select * from ....)) in eine DDS-beschriebene Datei packen und von dort aus exportieren.

[ChristophS]

ergänzend zu Baldur: CPYTOIMPF und CPYFRMIMPF sind das Pendant zu load/unload anderer SQL Datenbanken und bei der Übertragung großer Datenbestände eher schneller als Satz orientierte Methoden.
Java geht natürlich immer (auf meiner Open Source Seite gibt es da auch ein kleines Tool).

D*B

Danke, werde das Tool mal testen.

[ChristophS]

Der Vollständigkeit halber:

Man fand bei IBM doch ein PTF im Keller.
Das PTF SI37467 beseitigte das Übel.