DB2 - application tables - EBCDIC vs UNICODE

Hi DB2_L members,

          I have a general question - In a DB2 for z/OS shop, if ALL our existing tables are encoded in EBCDIC, should we consider creating all new DB2 tables by default with CCSID UNICODE, (unless there is a compelling reason like application needs to store foreign language characters or emojis or something like that) .
What about "switching" existing DB2 tables from CCSID EBCDIC to CCSID UNICODE ?
What are the pros/cons of switching to UNICODE for existing applications ... are there any existing/upcoming DB2 features that are likely to be affected by this choice?

thank you for your feedback   

**please note my email address change**
Kapil,

You’d need to decide on that based on things like whether your data will be multilingual and/or extend beyond the EBCDIC set. Certainly, if you’re talking about a company which is going to write Web-facing applications oriented to the world community, you’re going to need UNICODE (probably UTF-16) data storage to handle what people will be expecting you to store/read/write. Other cases presumably exist. You want to make the decision based on the strategic needs of your company for data in extended byte encoding schemes.

It’s probably not a good idea to mix EBCDIC and UNICODE tables within a specific, homogeneous business application. At a minimum, JOIN logic would get pretty ugly. If you need to expand your current applications with new tables _and_ the tables need to be in UNICODE for reasons such as I mentioned above… then you probably will want to convert the existing tables as part of the change. (And, of course, I’m assuming that we’re not talking about hand-changing thousands of tables for a single application.)

Philip Sevetson
Computer Systems Manager
5 Manhattan West (33rd St at 10th Ave)
New York, NY 10001-2632
212-857-1688 w
917-991-7052 c
212-857-1659 f
[cid:[login to unmask email]

From: Kapil Mathur [mailto:[login to unmask email]
Sent: Friday, July 14, 2017 9:52 AM
To: [login to unmask email]
Subject: [DB2-L] - DB2 - application tables - EBCDIC vs UNICODE


Hi DB2_L members,

I have a general question - In a DB2 for z/OS shop, if ALL our existing tables are encoded in EBCDIC, should we consider creating all new DB2 tables by default with CCSID UNICODE, (unless there is a compelling reason like application needs to store foreign language characters or emojis or something like that) .
What about "switching" existing DB2 tables from CCSID EBCDIC to CCSID UNICODE ?
What are the pros/cons of switching to UNICODE for existing applications ... are there any existing/upcoming DB2 features that are likely to be affected by this choice?

thank you for your feedback

-----End Original Message-----
**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**

Kapil,

Apart from performance (which of course matters), from the DB2 side any combination of table encodings is compatible. Of course avoid primary keys (and foreygn keys) of datatype CHAR or VARCHAR in those mixed cases.

I would certainly *not* go for UTF-16 in DB2; always use UTF-8 ! Both can represent any character that you can imagine.  (There are several arguments against UTF-16 which I won't sum up here.)

From the application design side, however, be careful when planning to access DB2 Unicode tables: in that case your application should "speak" Unicode if you don't want to loose characters with a SELECT from DB2.
Most Windows and Unix applications should satisfy this condition nowadays, but you better check!

Strictly speaking, any application encoding would do, and when it does not access CHAR or VARCHAR columns from those tables, or if it is lucky to only select rows containing characters that it can represent, it would not see the "substitution character".
Otherwise said, all your COBOL programs will just continue to run fine.

So, when everything is carefully considered (including performance aspects), the simplest setup would be to just go ahead and create a new table with the CCSID UNICODE clause. In the longer run, you'll probably want to migrate more and more tables (maybe one at a time) to UTF-8 as well.

In Reply to Kapil Mathur:

In a DB2 for z/OS shop, if ALL our existing tables are encoded in EBCDIC, should we consider creating all new DB2 tables by default with CCSID UNICODE, (unless there is a compelling reason like application needs to store foreign language characters or emojis or something like that) .
What about "switching" existing DB2 tables from CCSID EBCDIC to CCSID UNICODE ?
What are the pros/cons of switching to UNICODE for existing applications ... are there any existing/upcoming DB2 features that are likely to be affected by this choice?

--      Peter Vanroose
        ABIS Training & Consulting,
        Leuven, Belgium.
        http://www.abis.be/

I would only ever go to a different code page if the business requirements demanded it (and paid for it!)
Changing code pages is not as easy as people think and the “jumping through the hoops” of middleware, PC and Mainframe code pages is the most fun you can have aside from sticking pins in the soles of your feet…



Roy Boxwell

SOFTWARE ENGINEERING GMBH and SEGUS Inc.
-Product Development-

Heinrichstrasse 83-85
40239 Duesseldorf/Germany
Tel. +49 (0)211 96149-675
Fax +49 (0)211 96149-32
Email: [login to unmask email]<mailto:[login to unmask email]>
http://www.seg.de http://www.seg.de

Software Engineering GmbH
Amtsgericht Düsseldorf, HRB 37894
Geschäftsführung: Gerhard Schubert, Bettina Schubert

From: Kapil Mathur [mailto:[login to unmask email]
Sent: Friday, July 14, 2017 3:52 PM
To: [login to unmask email]
Subject: [DB2-L] - DB2 - application tables - EBCDIC vs UNICODE


Hi DB2_L members,

I have a general question - In a DB2 for z/OS shop, if ALL our existing tables are encoded in EBCDIC, should we consider creating all new DB2 tables by default with CCSID UNICODE, (unless there is a compelling reason like application needs to store foreign language characters or emojis or something like that) .
What about "switching" existing DB2 tables from CCSID EBCDIC to CCSID UNICODE ?
What are the pros/cons of switching to UNICODE for existing applications ... are there any existing/upcoming DB2 features that are likely to be affected by this choice?

thank you for your feedback

-----End Original Message-----