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