× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.