Re: Fw: forcing native access with websphere and toolbox

[cujo@xxxxxxxxxx]

You are right on all counts.

First, converting the data to unicode will cause your data (assuming it is
single-byte data today) to require more storage - double in most cases.
This is a major concern for some and not for others.  It is clearly a
performance trade off type issue and the answer will be dependant on your
situation.  What I generally suggest to customers is that you evaluate your
database tables based on your application needs.  For example, a customer
file is likely to have many character fields (name, address, city, state,
etc).  It is also likely to of reasonable size (I don't think we have many
customers with 110 million row customer files for example).  This might be
an example of a good candidate to change.  But it is all depends on your
environment/situation.

Second, using unicode columns can/will certainly add conversion cost to
legacy programs.  It would also assume that it could break legacy programs
that do not expect to have to handle conversion issue.  These are also
things that you have to consider before deciding to convert your tables to
unicode.

Perhaps it seems like a "baby with the bathwater" solution, and perhaps for
your situation (and many others) it is.  But our goal (meaning my team, not
IBM's - I do not speak on behalf of IBM) is to provide the solutions that
make JDBC as fast as it can be.  Many of the customers we work with
regularly are buying boxes only to run Java/JDBC/Websites.  Others are
willing to have two full copies of their data (one in the traditional CCSID
and one in unicode).  This can make sense when you have a table of
reasonable size which is pretty stable but that can get queried constantly
(a product table for many companies).

Clearly everyone has different needs.

I hope this helps people understand that table conversion to unicode isn't
a silver bullet that you can use to just magically help out performance,
but rather it can be a powerful tool when trying to make your Java
applications perform faster.

Regards,

Richard D. Dettinger
AS/400 Java Data Access Team

Think your job is safe?  Your future?  Your company's existence?  Think
again.
Right now there are people planning to do you in.  To replace you, steal
your
paycheck, obliterate your business, throw you out in the street.
...This is your wake-up call.  Digital Darwinism is unstoppable.
-Paul Somerson



Pluta@nexgensoftware.com on 11/12/99 12:01:48 PM

Please respond to JAVA400-L@midrange.com

To:   JAVA400-L@midrange.com
cc:
Subject:  Re: Fw: forcing native access with websphere and toolbox







Alex Garrison wrote:

One of the things the performance guide recommends is to  change your
physical files to use ccsid 13488 (unicode) for all character  data.  This
is supposed to speed things (...)
----------------
While I see how the conversion would benefit your Java programs, I do have
a certain concern... unicode requires two physical bytes of storage for
each character.  If you have large character fields, this could
significantly increase your DASD requirements.

Also, what's the legacy system downside?  Doesn't this actually ADD
conversion requirements to legacy systems?

There is a certain sense of "baby with the bathwater" in switching the
storage technique for character data in order to improve performance.

Joe



+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---