Vern,
> I hope this is the truth - it sounds much too easy.
It really is just that easy! Isn't it great having a database that is CCSID aware at the file level? If you have a character data in a file tagged with CCSID X and read that file from a job running in CCSID Y then standard data management will convert the data encoding from X to Y (and the reverse if writing/updating the file). Just be aware that the conversion is done based on the actual job CCSID and NOT the default job CCSID. I point this out as a lot of systems run with a job CCSID of 65535 and a default job CCSID based on the job language ID. The default job CCSID comes into play at various times, but data management CCSID conversion isn't one of them. Also keep in mind that if you want to turn off CCSID conversion on some of your 'character' data (control values for instance) then changing the data type for the control field from character to hex is worth doing (and again fairly easy to do).
Using the file approach works quite well when you simply want to read text and display it as is. If, on the other hand, you need to merge data into (potentially translated) text then *MSGFs (or equivalent) are better as they provide for merging of replacement data along with CCSID conversion support. I use *MSGFs for all of my text, regardless of the need for data merge, just for the consistency of it. But that is just my personal preference.
The ability to have each individual message tagged with a CCSID (as opposed to all messages/records in a *FILE) is nice though I haven't had much need for that as I generally have a separate *MSGF for each language/CCSID environment. Just remember to tag the *MSGF as 65534 when you want each *MSGD to be individually CCSID tagged.
Bruce
Vern Hamberg <vhamberg@xxxxxxxxxxx> wrote:
Eric
I just ran into some of this with one of our products and running it in
a Spanish context. I spoke with a couple of the PartnerWorld support
folks and got at least a couple ideas on this.
If the text literals are IN the source code, they end up compiled with
the program and effectively are stuck at the CCSID when created. The
suggestion was to put literals into a PF record with a tagged CCSID - in
our case, 37 in US English. Then read them into a data structure. When
the program is run in a different job CCSID, these literals will be
converted automagically to the job CCSID. So will any data coming from
any other tagged field in a PF or LF.
I hope this is the truth - it sounds much too easy. And I welcome
thoughts and clarification - am trying to understand how to take
advantage of it. But it takes advantage, I am told, of the internal
tables for converting from one CCSID to another - the same ones used by
iconv. Table objects are deprecated and are actually labeled as such in
V6R1 documentation.
Other issues pertain when translation is involved. Message files seem to
largely be the IBM method - same MSGF name but located in the secondary
language-specific library - named QSYS2927 or whatever - I don't have a
number to relate to any language - sorry. I see that both a message file
and message descriptions can be tagged with a CCSID, too.
HTH
Vern
DeLong, Eric wrote:
I'm trying to get feedback on standard practices involved in the intranationalization of an app. This is just curiosity on my part, for now, but I expect there might be a project for this soon.
Here are some of the basic questions I have...
1) base field dimensions for currency fields. What scaling factors to use for aggregation field sizes?
2) Character fields should use some flavor of UCS; assuming that the %UCS2() bif make this flavor easiest to use?
3) Wondering about text constants: If building a new business logic interface that is intended to support web-service/webapp, are MSGF objects still the best way to support language-based resources?
I looked at this several years ago, and have a pretty decent grasp on IBMs recommendations at that time, but I wonder if these techniques are still preferred in light of IBM's modernization roadmap....
Thanks for any insights,
Eric DeLong
midrange.com
