Re: ftp ifs file between partitions changing ccsid

On 25-Apr-2014 13:20 -0500, Charles Wilt wrote:

On Fri, Apr 25, 2014 at 1:37 PM, Jim Franz wrote:

Ftp'd an xml file from a V6R1 partition to a V7R1 partition.
same name
used namefmt 1 and bin
file not previously exist on v7 partition
file changed from ccsid 1252 to 819 ??

file contains only xml
on V7R1 partition used opt 2 in wrklnk (EDTF) to change a couple
characters for a test, no insert or delete.

This is before and after EDTF - the 0A (line feed) replaced by 8E
??

3E0D0D0A 3C537461 7475733E 54413C2F 53746174> <Status>TA</Stat
3E0D0D8E 3C537461 7475733E 54453C2F 53746174> <Status>TE</Stat

Now in the area of the change unrecognized characters (hex 8E)
appear when view from NotePad+.

Could be 2 unrelated issues - why the ccsid change from ftp? Is
EDTF for a ccsid 819 an issue or any other ideas?

FTP doesn't send objects, it sends a stream of bytes.

The CCSID on the original file isn't sent. Thus the receiving system
has to guess.

You can either use SAVE/RESTORE to send actual objects. Or pre-create
the file on the receiving system with the correct CCSID.

Or tell the FTP server what is the expected CCSID of the target data, and the file [as container of the transferred data] that is created at the server will have the specified CCSID; that CCSID should either match CCSID of the source-data [or the transfer request should be IMAGE instead of ASCII]:

QUOTE TYPE C 1252

As I recall the FTP client can establish the BIN [TYPE IMAGE] transfer type [which is communicated to the server], and then issue the above TYPE request [sent to the server via the QUOTE FTP subcommand] to establish the IBM i FTP server's CCSID expectation, such that the data is untranslated yet the resultant stream file has the specified CCSID attribute.