Re: FTP PF to Windows Server with Chinese Characters

On 27 Jun 2013 07:01, Robert Engelhardt wrote:

<<SNIP msg resent with corrected Subject line>>

On 26 Jun 2013 15:03, Robert Engelhardt wrote:

<<SNIP>>

I checked my PF and it has a longer field than originally
indicated (3500 O) When I do a DSPFFD the CCSID assigned is 937
Traditional Chinese.

Most of the file data is English, but with some Chinese text.

<<SNIP>>

Is there something that needs to be done on the receiving server
side to interpret this CCSID?

Here's the script I used to send the file:

*FTP xxx.xxx.xxx.xxx*
*UserID*
*Password*
"LType as400dbcs 937"
*CD /windowsDirectory*
*LCD WRKLIB*
*PUT PF_FILE WRKFILE.CSV*

<<SNIP>>

I generally use the IBM i FTP Server instead of the IBM i FTP client to move data between a non-i client and the server, so my recollection of the opposite direction may be a bit cloudy. However I am familiar with the use of UTF8 or UTF16 to assist generally to avoid data loss.

IIRC the "LTYPE C 937" tells the IBM i FTP Client to convert the data in the database file.mbr into the CCSID 937, before transporting the data using the /default/ CCSID for the ASCII file transfer. If so, and given the data in the file was appropriately tagged, then there likely was no change in the effect.? Because a "Double-byte character set (DBCS) CCSID values are not permitted for" the Coded character set identifier (CCSID) parameter, and given the FTP invocation shown in the above script apparently using CCSID(*DFT), apparently the defaulted target TYPE C is "The CCSID value 00819 (ISO 8859-1 8-bit ASCII)". Thus I think that the LTYPE invocation shown in the quoted message was of no help, and given the target ASCII CCSID 819 was a SBCS CCSID and not a mixed-CCSID, any DBCS data could not be properly transported.

IMO a better choice, might be to modify whatever data-write activity is currently targeting a database member of the file PF_FILE, to instead convert and deposit the data into a STMF with CCSID 1208, and then transport the data using UTF8, and finally open the file on the target system using an open-as-utf8 feature. There may be value in sharing with readers, what is the process for generating the data, to ask if there might be a different\better way.

However given the current setup remains entirely unchanged, except the scripted FTP subcommands delimited above with asterisks, I would try to resolve the issue, using each of the following one or two subcommand requests as a replacement for the one LTYPE request shown [¿but surely not as literally-specified?] in the above script:

LTYPE C 1208

or

TYPE C 1208

or

TYPE C 1208
LTYPE C 1208


p.s. My original reply was composed [but was pending send until I reviewed it this a.m.] in reply to the prior message with the Digest-mode Subject-line... and I was going to remind that should be corrected when replying. So thanks... for re-posting with the correct Subject. However additionally I had written to suggest that... By subscribing to individual messages instead of the digest, correcting the subject line and paring down the reply to only the relevant text is greatly eased. Besides, most newer email clients since the turn of the century have IMO, greatly diminished the value of having chosen the digest-mode over subscribing to the individual messages.