I have struggled with FPTAPI and Japanese
data, with not a lot of success.
I support systems for Japanese users,
and have Japanese Client Access etc.
I am certainly willing to help. I offer
to help test any changes you suggest.
I had problems even compiling the FTPAPI
programs in the Japanese environments.
Lower case English characters got converted
SBCS Katakana. I converted the source
to upper case and used Hex to spell
out the APIs that had lower case.
I think I may need a special verion
of the source for Japanese, maybe someone
knows a better way.
Chinese will be easier as the UPPER
case issue does not arise.
Frank Kolmann
PS. on a related topic I am very interested
in how to get UCS-2 working on AS400.
PPS. I am an old RPG guy, but very interested
in learning free form ILE etc.
but when I see RPGIII code I refuse
to work with it and convert it to ILE form
so there is some hope for me I think.
Christian <chrisv5@xxxxxx> Sent by: owner-ftpapi@xxxxxxxxxxxxx
08/06/2006 09:06 PM
Please respond to ftpapi
To:
ftpapi@xxxxxxxxxxxxx
cc:
Subject:
FTPAPI - my plans for improvement
Sender: Christian <chrisv5@xxxxxx>
As I got into fixing FTPAPI due to code page (CCSID) issues, which Scott
does not hurt that much, being lucky to live in a country with a simple
language (just kidding, folks!), that's where I want to put my efforts.
I want to fix the "receiving file in ASCII mode where file exists
already with wrong CCSID" bug and add the possibility to convert to/from
UCS-2 and UTF-8. If we are lucky, that'll also add support for
double-byte and mixed-byte.
Honestly, I cannot test anything other than UCS-2 and UTF-8 and I do not
understand CJK encodings well, either. When it comes to testing and
fixing those char sets, I'll need help from people who use that stuff.
Any Chinese, Korean or Japanese willing to help once we get there? Cause
I am not going to install that stuff on my PCs (though that would be
possible, if I feel crazy enough) nor do I have the slightest idea how
I
could get our iSeries to work with that.
Now, looking at the conversion code, that stuff is really old. I intend
to rewrite or at least re-format it, in order to make it easier to
understand (also for those who come after me) and extend. I tend to be
rather radical, once I touch old code (well, if it is not more than
fixing a single line), thus I want to ask Scott first what he thinks
about it. Anyone else who thinks he got reasons to object, raise your voice!
Here are the first few things which I want to change:
- naming; it's not ASCII or EBCDIC, it's local and remote; client or
server perhaps; both can be anything, at least on the data connection,
just imagine you download an EBCDIC file from a remote iSeries into your
local IFS and want it to be Latin-1. Boy, isn't that confusing right now?
- do we really need conversion descriptors for each session on the
control channel? It's always ASCII on the remote side and should be the
job CCSID on the local end. No need for all the hassle with creating and
storing CDs for each session, right?
- would like to convert all the data structures used for conversion to
"qualified"; makes it easier to use (LikeDS) and clearer with
regard to
which subfield belongs to what DS, without severly shortened variable names
- want to move globals to local static variables where possible (e.g.
InitIconv & wkXLInit/wkXLFinit etc.)
Any objections, comments, additional ideas? Of course I want Scott's
opinion, but anyone else with a good idea, make yourself heard.
Regards,
Christian
P.S: for anyone curious why I push so hard for modernization and code
cleanup, you should know that I have a strong background in object
oriented languages (Object Pascal, Delphi, C++, Java) and I am just
forced to program in RPG (mostly RPG/400 *puke*) to feed my hungry
children ;-)
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubsribe from the list send
mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------