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