CPYTOSTMF

[Fuerchau]

Hex 25 ist der LF im EBCDIC !
Setze den Job auf eine korrekte CCSID, warscheinlich hat dieser 65535 !

[hell]

Hallo Hr. Fuerchau,

der CPYTOSTMF läßt aber die CCSID nur bis 65533 zu.

das hatte ich auch schon probiert.

wissen Sie noch eine andere Möglichkeit?

Vielen Dank

Hell

[TARASIK]

Hallo Hell,
ist denn auf dem System das SI16636 aus 5722SS1 installiert ?

[hell]

Nein,
dieses PTF ist nicht installiert. Wir werden es in Kürze einspielen. Wird dch. diese PTF der Fehler behoben?

Hell

[Fuerchau]

Dass der CPYTOSTMF CCSID 65535 nicht zuläßt ist korrekt (das wäre eine Binary-Copy).
Prüfe die JOB-CCSID !
Da die Cmd's ja in EBCDIC arbeiten wird die Angabe *CRLF nur korrekt übersetzt, wenn der Job eine korrekte CCSID hat.

[BenderD]

Hallo,

hoffentlich nicht, denn x'25' für den Linefeed ist ja korrekt. Ich kann mir auch kaum vorstellen, dass das was mit CCSID zu tun haben kann; der Linefeed muss m.E. für alle Codepages gleich sein. Wo siehst du denn die % Zeichen???

mfg

Dieter Bender

Nein,
dieses PTF ist nicht installiert. Wir werden es in Kürze einspielen. Wird dch. diese PTF der Fehler behoben?

Hell

[Fuerchau]

@Dieter
x'25' ist Linefeed EBCDIC in ASCII = '%'
X'0A' ist Linefeed in ASCII
X'0D' ist CR in ASCII und EBCDIC

warum auch immer.

[BenderD]

@Baldur: das ist aber kein Bug, sondern ein Feature

Dieter

@Dieter
x'25' ist Linefeed EBCDIC in ASCII = '%'
X'0A' ist Linefeed in ASCII
X'0D' ist CR in ASCII und EBCDIC

warum auch immer.

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