Re: AW: Question(s) on converting names and addresses to UNICODE

Birgitta
as always, MUCH appreciated for your reply



Alan Shore
Programmer/Analyst, Distribution
E:AShore@xxxxxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill
midrange-l-bounces@xxxxxxxxxxxx wrote on 07/22/2009 12:32:14 AM:

Hi,

in the first step, I'd create views over all tables where addresses and

name

fields are located.
Within this views I'd define all address and name field values as

Unicode,

the conversion occurs automatically.

Create View MySchema/MyView as
Select AddressNo,
Cast(Name as VarGraphic(50) CCSID 13488) as Name,
Cast(City as NVarChar(50)) as City ...

From MyTable;

In Release 6.1 you can use NVarChar or NChar to define Unicode fields

before

6.1 you have to define the fields as Graphic or VarGraphic with CCSID.

These views can be used when passing address and name information to a

3rd

party vendor.
After having created all views, change your programs to access these

views

instead of the underlying physical files.
(BTW with Release 6.1 RPG will be smart enough to automatically convert
between EBCDIC and Unicode, i.e. Built-In-Functions to convert are no

longer

necessary.)

After the complete program conversion you may convert your data within

your

physical files and voilà everything is in Unicode.
(Agreed it is not as easy as it sounds, but IMHO the only way to move

from

EBCDIC to Unicode).

For the field lengths I'd use in either way varying field lengths.
We currently use for all our name and address fields 64 Characters

(varying

length) where 32 are allocated within the record (Keyword VARLEN(32)

within

DDS and ALLOCATE(32) within SQL.

Hope this helps.

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training

them

and keeping them!"

-----Ursprüngliche Nachricht-----
Von: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von Alan Shore
Gesendet: Tuesday, 21. July 2009 22:29
An: Midrange Systems Technical Discussion
Betreff: Question(s) on converting names and addresses to UNICODE

Good afternoon all
I hope I can ask the correct question, so here goes
We have been asked to look into converting our Name and address fields

from

EBCDIC to UNICODE to capture "foreign" characters
Part of that conversion is the passing of said names and addresses to a

3rd

party vendor
This is NOT really a technical question per se, but I don't really know
where to start investigating the following question.

For ALL the names and addresses that have to be captured world wide (in
whatever characters that will be passed down), what would be considered a
good "size" for fields like
first name
last name
Address lines (including street names, city names, provinces, county

names,

country names etc. etc.)
Like I said - not really a technical question, but if someone knows the
answer, or can point me in the right direction, it would be MUCH
appreciated


Thanks in advance



Alan Shore
Programmer/Analyst, Distribution
E:AShore@xxxxxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.