IBM Books

Planning Volume 2, Control Workstation and Software Environment

Question 4: Which levels of AIX do you need?

New RS/6000 SP systems come with AIX 5L 5.1 (or later) or AIX 4.3.3 (or later) and PSSP 3.4 on installation media. Before you decide, you need to consider which existing and new hardware and software features you need and what they require. For instance, do you want PSSP services that support 64 bit addressing? If you are not planning an entirely new system but are adding to an existing one, you especially need to consider the current migration and coexistence support to best understand the requirements.

Considering AIX and PSSP in another language

|As of PSSP 3.2, the software is NLS-enabled and ready for Internationalization. This means that the software has been made translation-ready and can be translated to a language that is supported by AIX. It is not already translated. Contact your IBM representative if you choose to consider translating it. This discussion is meant to inform you of the possibilities.

All of the PSSP software components and the following PSSP-related licensed programs have been enabled with National Language Support (NLS):

The SP software is configured by default to operate in the US English language locale. Before you decide to translate the software and run AIX and PSSP in another language, you need to consider the effects of using different language locales. If you decide to use another language locale, after you get the software translated, do the following:

Effects of using different language locales

For AIX, the installation default language locale refers to the locale selected during AIX system installation as the system-wide locale. On an SP system, that AIX process still applies on each node. On an SP system, you can install AIX on the control workstation in any supported language, followed by network setup, the PSSP software installation, SDR configuration, activation of the setup server, then node install of AIX based on mksysb images provided by IBM or generated by you, followed by node install of PSSP based on mksysb images. The PSSP 3.2 software supports a heterogeneous (multilingual) system configuration. That means you can operate with the system locale on some nodes being different from the administrative locale on the control workstation. The SP will function correctly in such a case, but output from commands or processes that span multiple nodes might be received in mixed languages and might be unreadable. Therefore, the nodes and control workstation can run with different locales but with the following restrictions:

  1. When installing, configuring, and customizing a multilingual SP system, any system-wide control and configuration data (data written to the SDR) must be written in the SP administrative locale or in the US English locale. If, for instance, a node is running in a locale different from the administrative locale, any system-wide control or configuration data written to the SDR on behalf of that node must be restricted to the portion of the locale code set that is common across all locales: the standard 7-bit ASCII character set.
  2. If the SP administrative locale is a multibyte character set (MBCS) locale, system-wide control and configuration data can be stored in the SDR using multibyte character data (MBCD) specific to the SP administrative locale. However, IBM strongly suggests that in a heterogeneous environment all system-wide control and configuration data be stored using the standard 7-bit ASCII character set because it is available in all code sets and locales. That assures that data written to the SDR can be displayed and is readable from the SP administrative locale. It also reduces the probability of MBCD from several different locales being written into the SDR in the event that the SP administrative locale is changed.
  3. If the SP administrative locale is an MBCS locale and system-wide control and configuration MBCD is stored into the SDR, the system will not be able to use the IBM domain name server (DNS) code. The general DNS standard for host names forbids any characters not in the set [A-Z, a-z, 0-9, -]. The upper and lower case English letters, the Arabic numerals, the hyphen, and for HACMP only the underscore character (_), are included in the set. You can use a different name resolution mechanism that is MBCS-enabled.
  4. If the SP system is configured as a multilingual heterogeneous system, any distributed application or client-server application that spans several nodes which might be running different locales can receive responses in the node's default installation locale or in the SP administrative locale. The response will be in the language in which the node is operating and might not be readable. The application can compensate by imposing a homogeneous restriction, ensuring that daemons are initiated in the same locale or in the SP administrative locale. It can compensate by providing an API to transport the locale information from the client to the server and daemons. If the serviceability and functioning of the application is not impacted, the application might handle different language responses from nodes.
  5. Administration of several languages from a single point of control and ensuring that all information can be displayed and is readable across different code pages is available only when using Unicode. Unicode only works if the AIX system platform across the SP system is declared to be Unicode only.

Setting the AIX language locale

For AIX, the installation default language locale refers to the locale selected during AIX system installation as the system-wide locale. On an SP system, that AIX process still applies on each node.

This locale is defined in the LANG environment variable in the /etc/environment file. The /usr/lib/nls/loc directory contains the system-wide locale set during installation of AIX. These two directories are defined in the /etc/environment file under the environment variables LOCPATH and NLSPATH, respectively.

To change the locale, you can use the AIX chlang or export LANG=locale command, where locale is the AIX-supported locale you choose and, preferably, the one to which you translated the PSSP and related licensed programs, and with which you want PSSP to operate.

Changes made to the NLS environment are not immediate. Changes made to the /etc/environment file requires rebooting the system. Changes made in the user's .profile file requires executing .profile or logging in to AIX again.

The AIX locale command lists all local environment variables with which you can set up a locale category preference. An application can impose the values of locale categories, but then it is not considered to be a code set independent application.

Setting the SP administrative locale

The purpose of the SP administrative locale includes the following:

The default is for all nodes to operate in the administrative locale. In this locale, the SP system administrator experiences a consistent view of the SP system control and external information.

The administrative locale is set by the install_cw process during installation and can be changed at any time using the spsitenv command.

Considering new features

You should plan to order the basic operating system and levels that support the functions and hardware you need. You might need to stay at earlier levels of AIX to support specific hardware you already have installed. On the other hand, you might want to use the newest hardware and it might require the newest software as well. |PSSP 3.4 is supported on AIX 5L 5.1 (or later) and on |AIX 4.3.3 (or later).

|PSSP 3.4 is supported by the binary compatibility and the 32 |and 64-bit application coexistence and concurrent execution capabilities of |AIX. PSSP 3.4 with AIX 5L 5.1 does support a 64-bit |processing environment. PSSP with AIX 4.3.3 does not |exploit 64-bit addressing and cannot be called for services by any 64-bit |applications.

Before deciding on program levels, consider the new features available in the new releases. See What's new in AIX and PSSP? for brief descriptions of new features.

Considering migration and coexistence

Migration addresses upgrading AIX, PSSP, and PSSP-related licensed programs on an existing RS/6000 SP or a cluster of |IBM e(logo)server pSeries or RS/6000 nodes from earlier supported levels to the new level. Coexistence refers to the ability of a program to support multiple levels of AIX, PSSP, and itself in the same system partition. Coexistence is important in the ability to migrate one node at a time and is a key component of migration.

|Support is provided for migrating to PSSP 3.4 running on AIX |5L 5.1 or on AIX 4.3.3. Table 4 lists the migration paths to PSSP 3.4 that are |available.

|Table 4. Migration paths

From To
PSSP 2.4 and AIX 4.2.1 or 4.3.3 PSSP 3.4 and AIX 5L 5.1 or AIX 4.3.3
PSSP 3.1.1 and AIX 4.3.3 PSSP 3.4 and AIX 5L 5.1 or AIX 4.3.3
PSSP 3.2 and AIX 4.3.3 PSSP 3.4 and AIX 5L 5.1 or AIX 4.3.3

In general coexistence is supported in the same system partition or a single default system partition (the entire SP system) for nodes running any combination of:

|PSSP 2.4 and AIX 4.2.1 or 4.3.3 |is supported for migration only. For more exceptions and information, |see Chapter 11, "Planning for migration".

Recording your decision for question 4

Now you should know which level of AIX you need. If you need to run more than one level, you might require SP system partitions. Planning for SP system partitions is discussed in Chapter 7, Planning SP system partitions.

The ABC Corporation's worksheet appears in Table 5.

|Table 5. Operating system level selected by the ABC Corporation

Need to run   AIX   PSSP
x AIX 5L 5.1 PSSP 3.4

AIX 4.3.3 PSSP 3.4

AIX 4.3.3 PSSP 3.2

AIX 4.3.3 PSSP 3.1.1

[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]