CPYTOSTMF

[hell]

Das % Zeichen sieht man, wenn man die kopierte Datei z.B. mit WordPad öffnet.

Dadurch ist die kopierte Datei aber unbrauchbar.

CR und LF werden aber vom Empfänger der Datei benötigt.

[BenderD]

Hallo,

dann müsste aber doch der Rest der Daten auch "unbrauchbar" sein?

mfg

Dieter Bender

Das % Zeichen sieht man, wenn man die kopierte Datei z.B. mit WordPad öffnet.

Dadurch ist die kopierte Datei aber unbrauchbar.

CR und LF werden aber vom Empfänger der Datei benötigt.

[roman]

Hallo zusammen
Konnte dieses Problem nun wohl gelöst werden? Würde mich sehr interessieren. Ich kriege diese CRLF-Problematik auch nicht in den Griff:

Meine Aufgabenstellung: Dateiübermittlung mittels CD-ROM von AS/400 nach IBM-Host(MVS). Testhalber versuche ich dies zwischen AS/400->PC->AS/400 durchzuspielen:

Die Datei ist sequentiell ohne DDS-Source. Der Befehl lautet:
CPYTOSTMF FROMMBR ('/qsys.lib/zzrolu.lib/prtsel.FILE/prtsel.MBR') TOSTMF('
/QDLS/ROLU/PRTSEL_1') STMFOPT(*REPLACE) CVTDTA(*NONE)

Da auf dem IBM-Host die Uebertragungsmöglichkeiten der AS fehlen und sich FTP anbietet, mache ich den Rücktransfer auch mittels FTP (binary).

Statt:
*...+....1....+....2....+....3....+....4....+....5 ....+....6..
0000359800500000000000DANI 2006011310570100041507713*STD
0000359358900000000000DANI 2006011310530300041108930*STD

ist das Resultat:
*...+....1....+....2....+....3....+....4....+....5 ....+....6....+...
0000359800500000000000DANI 2006011310570100041507713*STD
0000359358900000000000DANI 2006011310530300041108930*STD


Uebrigens: JOB-CCSID habe ich auf 65535 gesetzt, Die CRLF-Codierung ist 0D 0A (ASCII)

Kann mir da ev. jemand weiterhelfen. Besten Dank.

[Fuerchau]

Bei CVTDTA werden zwar die Daten nicht gewandelt, der Default für *CRLF ist aber X'0D0A'. Soweit korrekt.
Benötigst du alles in EBCDIC dann gib als Ziel-CCSID z.B. 273 an.

[roman]

Danke Baldur.
CRLF erscheint nun zwar EBCDC-codiert 0D 25 - Doch löst es mein Problem nicht wirklich.
Beim FTP vom PC nach dem leeren phys.File "hängt" er nun die Datensätze aneinander. Wie kriege ich eine ordentliche Record-Trennung hin.

Ergebnis auf AS400:
0000359800500000000000DANI 20060113105701000415

berengstringen OVD2005123100046845072
000000000000000J05BFWOHNEN N00003591687000

= CRLF (brauche ich aber eigentlich nicht!!)

[Fuerchau]

Die Frage ist denn nun, wie du die Daten denn tatsächlich brauchst !
Mit *CRLF oder ohne. Wenn ohne, dann gib ENDLINFMT(*FIXED) an.

Wenn du allerdings direkt an den anderen IBM-Host überträgst, kannst du doch ohne Umweg über das IFS die Datei direkt übertragen.

[roman]

Die Frage ist denn nun, wie du die Daten denn tatsächlich brauchst !
Mit *CRLF oder ohne. Wenn ohne, dann gib ENDLINFMT(*FIXED) an.

Wenn du allerdings direkt an den anderen IBM-Host überträgst, kannst du doch ohne Umweg über das IFS die Datei direkt übertragen.

*FIXED ist ok! Vielen Dank! Das war's!
(diese Auswahlmöglichkeit muss ich übersehen haben...)

PS: Der IBM-Host steht in einem externen Rechenzentrum und somit nicht in unserem direkten Einflussbereich. Einziges Austauschmedium bisher waren relativ teure (v.a. wenn diese nicht mehr retourniert werden!!) 1/4-Zoll-Cartridges. CD-ROM sind einiges kostengünstiger. :-)

Grüsse
Roman

[alfredo]

Bei mir funktioniert es problemlos:
File CCSID 273, Job CCSID 273

CPYTOSTMF FROMMBR(&FROMMBR) TOSTMF(&PATHFIL) +
STMFOPT(*REPLACE) STMFCODPAG(*PCASCII)

[Fuerchau]

Das kommt auf das Zielsystem an:
*PCASCII ist Codepage 850 (DOS). Für Windwos solltest du 1252 verwenden (Umlaute und Sonderzeichen).
Beim obigen Problem war das Ziel ein anderer IBM-Rechner und der wollte kein *CRLF als Satztrenner.

[alfredo]

Habe andere Erfahrungen:
*PCASCII macht bei mir aus
273 -> 1252
870 -> 1250
1025 ->1251

funktioniert seit V4R5; aktuell V5R2