DataStage has had NLS (National Language Support) for a very long time. In the IBM InfoSphere Information Server versions, it is referred to as Globalization Support in the installer, but it is still called NLS in the DataStage clients. For the purpose of this discussion, I will call it NLS since our legacy users know that term and configuration after install uses it. When you are planning an upgrade to a new version of the software, you need to decide what NLS support you had and what you need for the new system.
The first thing you have to know is that you cannot change the NLS configuration of your engine after installation without doing a reinstall. Consequently, it is critical that you know how your current DataStage software is configured and use that information in conjunction with your processing requirements to ensure you configure NLS correctly for your needs.
The second thing you should know is that exporting from a system with NLS "on" to a system with NLS "off" is not supported. The DSX or isx will contain information that a system without NLS will not know how to handle. It might work. It may even work most of the time. But it is not a tested path and we have not put in the code to be sure it does work. Exporting from NLS "off" to NLS "on" is supported.
In general, IBM recommends enabling NLS. It allows you to handle data from and to different character sets. You need NLS enablement to be able to correctly parse multibyte characters. In the current global economy, systems that only have to deal with single byte data are becoming rare.
If you are primarily using the parallel engine, there is no performance impact for NLS enablement. However, if you are primarily using server jobs, going from NLS off to NLS on will impact performance and will usually require job changes. More information about the trade offs are below.
Determining if NLS is enabled on your source system
There are a number of ways to determine your NLS configuration. The one that works for all versions is to check your <installpath>/Server/DSEngine/uvconfig file. If NLSMODE is set to 1, NLS is enabled. While you are in the file, also note what your NLSOSMAP setting is.
If NLSMODE is in the file and set to 0, it could indicate that someone “turned off” NLS. Turning off NLS by setting NLSMODE to 0 does not work correctly and if you never noticed data corruption, you were lucky. Whether you choose to turn NLS on or off on your target system, you are going down an untested path.
If NLSMODE is not defined in the file, NLS is not enabled.
NLS is not enabled on your source system
If NLS support is not installed on your source system, extra consideration is needed depending on the type and composition of the existing jobs, and the likelihood of needing NLS features now or in the future.
If your operating system language is not English, installation will automatically enable NLS. If your operating system language is English, you will see a globalization panel with a check box titled “Install globalization support”. The box is checked by default. If you do not want NLS support you must uncheck it.
For existing jobs, the primary effect of enabling NLS support is on server jobs, and on parallel jobs which use server shared containers or the Basic transformer. The main areas of behavior which change in DSEngine with NLS enabled are:
Server jobs run internally in UTF8 rather than in host characterset bytes; this can have a performance impact due to conversion (if used) and due to higher overheads for internal manipulation.
Jobs which process non-ASCII characters may not work the same way. This includes extended ASCII, non-character bytestreams and EBCDIC characters.
Specifically, string handling functions with NLS enabled will interpret data as UTF8 characters of length one to three bytes. Jobs which assumed byte-based offsets with NLS not enabled will not necessarily work the same way with once enabled, unless they are processing just strict (7-bit) ASCII data. This applies to all character based functions, including string indexing constructs of the form string[start,count]
Locale behavior changes from the DSEngine defaults to locale-specific functions. This includes date and time representations and conversions (eg Iconv and Oconv), alphabetic sort orders, numeric representation, currency, and character classifications, including case handling.
NLS is enabled on your source system
If NLS support is enabled on your source system, you should also enable it on your destination system.
If you had NLS enabled on your source system, you should check the default character set defined by NLSOSDEF. If you are migrating from 8.0.1 or earlier, or if you are changing platforms, your new system may have a new default character set. If the default character set changes, you may need to change the default character set in the Project or jobs if you do not want the jobs' behavior to change. In addition, since sorts can be done at the OS level, a character set change could result in small order changes. If you decide you want to use the same character set as the source system, you need to set it in your operating system prior to installing. See https://www-01.ibm.com/support/knowledgecenter/SSZJPZ_11.3.0/com.ibm.swg.im.iis.productization.iisinfsv.install.doc/topics/wsisinst_upgrade_utf8.html