View Full Version : CPYTOSTMF
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.
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.
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.
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 N 00003591687000
= CRLF (brauche ich aber eigentlich nicht!!)
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.
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
Bei mir funktioniert es problemlos:
File CCSID 273, Job CCSID 273
CPYTOSTMF FROMMBR(&FROMMBR) TOSTMF(&PATHFIL) +
STMFOPT(*REPLACE) STMFCODPAG(*PCASCII)
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.
Habe andere Erfahrungen:
*PCASCII macht bei mir aus
273 -> 1252
870 -> 1250
1025 ->1251
funktioniert seit V4R5; aktuell V5R2