Re: Language feature code: 2984 vs 2924 -- MIDRANGE-L

Simon Coulter wrote:

On 21/01/2010, at 7:06 AM, rob@xxxxxxxxx wrote:

Most of our systems are using language feature code 2924. However I noticed one lpar running 2984. Almost changed it back, out of force of habit. But after researching it I

>> figured "why not". What say ye?

I don't think there is any practical difference--especially
in your case where you are on current versions of the OS.

The differences are language related defaults; e.g. CCSID of the *DBXREF and model files. Some defaults may be desirable or preferable as DBCS vs SBCS [or vice versa]. Hoewver for lack of CCSID support in object text descriptions and similar, even the DBCS choice would be unable to express multiple DBCS languages under one DBCS CCSID. So even if DSPOBJD for ODOBTX has CCSID 5035, unless all of the objects being displayed have TEXT() data in code point consistent with that CCSID, the data is problematic.

At one time, if you wanted DBCS support you needed to install a DBCS-capable primary language. If you wanted your primary language to be English then you needed to install one of the DBCS
versions. 2984 if your devices had lower-case support and 2938
otherwise. Now that the OS is always DBCS-enabled (since VRM510)
it doesn't matter which language you install. I'm not aware of
any benefit or difference between 2924 and 2984.

The requirement was and is, that a DBCS-capable primary language is a requirement for having a DBCS-capable secondary language. It is because all languages since v5r1 are considered DBCS [per QIGC=1 on all NLVs], that any language can be primary, while enabling any DBCS secondary languages. The NLS guide describes some of the defaults which differ between nlv2924 & nlv2984 to help decide which might be a better fit. There is likely little reason for anyone to ever use 2984 any more; where any benefits are noticed, changes to the configuration may suffice to make the other choice similarly functional, and problems that would be seen are likely to exist regardless of which NLV is chosen as primary.

I have 2984 installed as primary on one system but that's only because I needed DBCS support prior to 510 and I've done upgrades
rather than scratch installs. My other system is running 2924 and
has DBCS support. At one time, to change from a non-DBCS primary
to a DBCS primary and vice versa required a scratch install. I'm
fairly sure that's no longer necessary.

The scratch install requirement was removed for the OS in v3r1; I do not recall what restrictions remained in QGPL, QUSRSYS, & LPPs. The first stumbling block was the OS, for the system database cross-reference. The conversion of the DBXREF file spanning the character sets was first resolved then, and improvements since should make the transition easier.

Regards, Chuck