Re: Another weird v5r4 Client Access problem for JapaneseWindowsMachines

I did omit comment about the fact that model database files and the database cross-reference files and SQL catalog will be affected, becoming SBCS with default CCSID 37; i.e. database files in QSYS and QSYS2. Files in QUSRSYS and QGPL will AFaIK be similarly affected. That *may* be problematic for text data that is actually DBCS, but will then be stored in SBCS character fields when using a mixed-case English environment; e.g. DSPOBJD for its ODOBTX would write data from object TEXT() as SBCS character even if they are actually shifted DBCS character string data. So do be aware [and\or beware] of the differences that might be of concern. It would probably be best to upgrade a test partition first in preparation for the real upgrade.

FWiW since the database cross-reference must be converted with an essentially invalid mapping [i.e. DBCS to SBCS], there may be difficulties in conversions; any error(s) might effect a requirement to reclaim the dbxref after the upgrade. The ALTER of these files is an exception path to enable the upgrade, and it is likely not [well] tested even though there is an API which mimics the feature. IMO the best results would be had by first deleting [before the upgrade] the relations in SYSIBM and all catalog VIEW files from all users libraries; optionally from QSYS2 as well. Since the catalog VIEW file definitions are updated in newer releases, recreating those files [if even there is any reason that they should exist; rarely if ever, since the same named VIEWs are available in QSYS2] will get the updated CREATE statement. IIRC the feature to delete the views is CALL QSQXRLF (DLT 'LIB_NAME') /* *pgm left unqualified as I do not recall which library for that undocumented API */

Regards, Chuck

Burns, Bryan wrote:

Thanks much Chuck. I'll recommend we go to 2924 at the next
upgrade and blame you if anything goes wrong.

Just kidding. I'll make the recommendation when we go to V61.

Burns, Bryan wrote:

<<SNIP>>

What's your primary language? Our is 2984 ENGLISH DBCS which
is often overlooked by business partners until I point it out.
Our secondary languages are 2962 Japanese Kanji DBCS and 2924 ENGLISH. The necessity for these is beyond me and I've
wondered whether we still need them but that's been our OS for
10 years at least. With these languages installed, it's
possible to change the code page within the client properties
tab. Also, I'd like to point out that IBM provides a DBCS
version of the client.

<<SNIP>>

CRPence wrote:

FWiW: Since some V5R# [v5r3?] all languages ship as DBCS capable,
whereby QIGC system value is '1' [and the sysval becomes
read-only] for every language. Since that release [as I
understand, was the intent that] there should be no reason any
longer for NLV2984 as primary language solely to enable any
secondary DBCS languages.