|
Thanks for your reply, Scott. I'd actually read about it in the Memo To Users v5r3 where I understood it to say that if the target (TOFILE parameter) has no explicit CCSID or it is 65535, no conversion occurs. In my case the TOFILE (TOSTMF) doesn't exist (CPYTOIMPF creates it) and the CCSID is explicitly specified with STMFCODPAG(*PCASCII). Yet no conversion is done - this seems counter intuitive to me. Furthermore when creating the temporary *PF with CRTPF FILETYPE(*DATA) no CCSID other than 65535 is allowed to be specified. I'm not complaining, CPYTOSTMF will do what I need to do :) Again, thanks for pointing me in the right direction. Best regards, Moe Scott Klement wrote:
Please read the following APAR: http://www-912.ibm.com/n_dir/nas4apar.NSF/51d11a683a56a5cc862564c000763b23/0cd39ad7f981e5bc86256e5400420e53 This is a FAQ. as400 wrote:On v5r1 I used to be able to copy a *SPLF to a *PF and then use CPYTOIMPF with STMFCODPAG(*PCASCII) to get an ascii file in the IFS. With v5r3 this no longer seems to work. When I display the file in the IFS, even tough it looks largely ok, I get the message 'File CCSID incorrect' (CPDB610) at the bottom of the screen: Cause . . . . . : The file CCSID was 01252, but the data in the file looks like EBCDIC. A CCSID of 00500 is being used. Recovery . . . : If another CCSID is needed, use F15 to change to the desired CCSID. When I ftp (bin or asc) off the file to a PC it looks like a mess (or as the above message suggests, like EBCDIC data). What am I doing wrong? Moe
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.