1. Thanks for your detailed reply, it only occurred to me to change the
local type, which is why I posted to this forum.
2. Please excuse me for not paring this reply down further...it all seemed
3. Google email client, by default, makes the user dig to change the
subject line on a reply.
Boy am I glad I found it!
Something tells me that doing this from a Windows machine to a Windows
machine would have been much more intuitive.
Wonder what the future holds for IBM?
On Thu, Jun 27, 2013 at 7:20 AM, <midrange-l-request@xxxxxxxxxxxx> wrote:
Send MIDRANGE-L mailing list submissions to
1. Re: FTP PF to Windows Server with Chinese Characters (CRPence)
date: Thu, 27 Jun 2013 08:50:27 -0500
from: CRPence <CRPbottle@xxxxxxxxx>
subject: 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:
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
Most of the file data is English, but with some Chinese text.
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:
"LType as400dbcs 937"
*PUT PF_FILE WRKFILE.CSV*
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
TYPE C 1208
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.