Re: CCSID 37 / 500 issues with FTP -- MIDRANGE-L

I don't know why it'd matter if you did it from within the RPG or not. (Provided it's done before the FTP is run, and not opened until after the file is both created and transferred)

The other thing I'd try if pre-creating the file didn't work for some reason is to run CHGPF to change the CCSID to the correct one after the transfer.

I suppose SQL with CAST might do it, but then the file itself is still wrong... you're just doing a workaround when you read it. For me, I'd want my file to be correct so no workarounds are needed.

On 2/19/2010 5:49 PM, Dan wrote:

Hi Scott,

Thank you for your very thorough and quick response! On a Friday evening,
no less!

I suspected most of what you wrote. I had previously tried creating the
target file before the FTP get, but this failed, for reasons I do not
recall, but although the connection was made and navigation to the correct
server directory was successful, the GET failed.

That result shifted my strategy last last night to not pre-create the file,
and let the FTP transfer do it. In the course of attempting to replicate
this failure again (interactively) as a result of reading your reply, so
that I could tell you why it failed, now IT IS WORKING! Ugghhhhh.

Could the difference have been that the CRTPF was done in the RPG
application (via QCMDEXC call) vs. today's attempt to replicate and doing
the CRTPF at the command line? It would take a bit of work to return the
application back to do the CRTPF at this point, so I won't, and so it may
have to remain a mystery.

In the interim between my original post and your response, I dug up the SQL
CAST spec, and tried the following in an interactive SQL session:
SELECT cast(PRCLOGLINE as char (200) ccsid 37 ) as Cvtto37
FROM QTEMP/G002032100

This appeared to do the trick, so I am going to plug this into the
application and test it there. If it works similarly, I may call this a
done deal.

I'm still all ears if you or anyone else advises against the CAST technique
described above.

So you may need to find out what
CCSID the remote file is,

Any ideas how to determine this? And if I do find out, is that the number
to plug in on the FTP command?

TIA,
- Dan

On Fri, Feb 19, 2010 at 6:15 PM, Scott Klement
<midrange-l@xxxxxxxxxxxxxxxx>wrote:

Hi Dan,

Most computer systems (with IBM i being the exception) do not have any
clue what character encoding a file contains. On Windows you cannot
denote that a file is ASCII, Latin-1, or Unicode. Not in the "file
description", at least... some types of files (such as XML) store this
information inside the file data itself, but if it does that, it's
particular to that specific file format. It doesn't apply to the
computer's file systems as a whole.

Therefore, FTP has no way of knowing what CCSID the remote file is. It
has no way to detect that. All it knows is that it's a string of bytes.

If you ask FTP to translate it by using ASCII mode, it assumes the
remote file is in the CCSID you specified on the FTP command. So, on
the Windows side of the connection, it expects the file to be in ASCII,
and in the CCSID you specified. (That's why you can't specify 37 or 500
for that parameter -- it's supposed to be an ASCII CCSID)

FTP then uses a combination of the CCSID of an existing file, the CCSID
of your job, and the remote ASCII CCSID you specified to figure out what
CCSID to translate to on the EBCDIC end of things.

I'm not exactly sure how it's arriving at 500 in your case, though.

My suggestion is that you pre-create the local file in the CCSID you
want to use, and try the transfer again. It should therefore translate
to the CCSID of the pre-created file.

However, that still might not work -- because (again) FTP doesn't
actually know what the remote file is. So you may need to find out what
CCSID the remote file is, and specify that as the CCSID parameter on the
FTP command.