Cganging CCSID's.

Martin Wolff

Cganging CCSID's.
We have been told that we should change our default CCSID from 500 to 37 to
be fully compliant with DB2 V8 when we get there. As far as I can tell, we
don't have any of the characters that are different between the two code
pages in any of our CHAR strings but since V8 is probably 2 years away for
us, this could change.

The approach that seems to make sense to me is to:-

1) Modify start up parms so that new default code page is 37.

2) Alter Database for each existing database so that new tablespaces use the
new code page.

3) Alter Tablespace for each existing tablespace so that after reorgs, the
code page will switch.

4) Verify that SYSIBM.SYSSTRINGS has entries for both code page conversions.


The only problem is that when I look in the SQL Reference (V6), the Alter
Database gives the following warning:-

Changing a CCSID can be disruptive to the system and requires several steps.
For each encoding scheme of a system (ASCII or EBCDIC), DB2 supports only
one CCSID. Therefore, the CCSID for all databases and all table spaces
within an encoding scheme should be altered at the same time. Otherwise,
unpredictable results might occur.


If I read this correctly, and probably I don't, I will have to convert a
whole load of tablespaces at once rather than spread the conversion over the
next few years. Is that correct? Is it still correct even if I have the
SYSSTRINGS entries set up correctly?

I would be grateful for any help on what my best actions are.

Martin Wolff,
Global Crossing.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Roger Miller

Re: Cganging CCSID's.
(in response to Martin Wolff)
Who told you that? The more common problem is that your emulator is using
one code page, while you tell DB2 something else. That is almost certain
to cause problems with some characters on releases as far back as V2, but
the problem keeps getting worse. Other problems include using multiple
code pages over time. You need to contact Chris Crone, [login to unmask email]
There are many different possibilities, and he can check to see what you
really need to do.

Roger Miller

On Tue, 13 Jan 2004 13:53:58 -0600, Martin Wolff
<[login to unmask email]> wrote:

>We have been told that we should change our default CCSID from 500 to 37
to
>be fully compliant with DB2 V8 when we get there. As far as I can tell, we
>don't have any of the characters that are different between the two code
>pages in any of our CHAR strings but since V8 is probably 2 years away for
>us, this could change.
>
>The approach that seems to make sense to me is to:-
>
>1) Modify start up parms so that new default code page is 37.
>
>2) Alter Database for each existing database so that new tablespaces use
the
>new code page.
>
>3) Alter Tablespace for each existing tablespace so that after reorgs, the
>code page will switch.
>
>4) Verify that SYSIBM.SYSSTRINGS has entries for both code page
conversions.
>
>
>The only problem is that when I look in the SQL Reference (V6), the Alter
>Database gives the following warning:-
>
>Changing a CCSID can be disruptive to the system and requires several
steps.
>For each encoding scheme of a system (ASCII or EBCDIC), DB2 supports only
>one CCSID. Therefore, the CCSID for all databases and all table spaces
>within an encoding scheme should be altered at the same time. Otherwise,
>unpredictable results might occur.
>
>
>If I read this correctly, and probably I don't, I will have to convert a
>whole load of tablespaces at once rather than spread the conversion over
the
>next few years. Is that correct? Is it still correct even if I have the
>SYSSTRINGS entries set up correctly?
>
>I would be grateful for any help on what my best actions are.
>
>Martin Wolff,
>Global Crossing.
>
>--------------------------------------------------------------------------
-------
>Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page
select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at DB2-L-
[login to unmask email] Find out the latest on IDUG conferences at
http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm