|
You can change the CCSID of your job to 037 to see what will happens. See http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg242154.html? Open for more information and specially Appendix A National Language Versions. Michel-Claude Ducrest tel. +41 21 924 16 14 fax +41 21 924 2882 -----Original Message----- From: Urbanek, Marty [mailto:Marty_Urbanek@xxxxxxxxxxxx] Sent: Wednesday,10. September 2003 17:35 To: 'midrange-l@xxxxxxxxxxxx' Subject: Impact of QCCSID change Our QCCSID is set at 65535 because that was the default when I installed OS/400 and I never had a reason to change it. We have also checked with some of our US customers and they also run 65535. We know we have customers outside the US who run other CCSIDs and we occassionally have a support issue but no big deal. We are now running into some complications storing unicode data in DB2/400 databases (VARGRAPHIC + CCSID 13488), and it seems like some things might be easier if QCCSID was non-hex, like perhaps 037. The problem with 65535 is not so much accessing the data via JDBC, but rather through native utilities like STRSQL screen. I am leery of changing QCCSID because I don't know what else might happen, i.e. would components of OS/400 start up under the new value and misunderstand existing data in files, etc, bringing the system to its knees and/or start converting things so it would then be impossible to change back to 65535 if we needed to? I am pretty ignorant of this whole subject because my OS/400 background was mostly in communications, so to me 65535 always seemed like the ideal. I didn't want the system changing any data as I did my I/O. If I wrote a byte to disk, that was the exact byte I wanted recorded and the exact byte I wanted to read back, regardless of where my comm program was running. What do you all use for QCCSID, do you store any unicode data in DB2/400 and if so do you use GRAPHIC/VARGRAPHIC or FOR MIXED DATA or what? All advice appreciated. THANKS, -Marty _______________________________________________ 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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.