![[V5.1 and later]](../../v51x.gif)
Install Network Deployment on AIX platforms
Contents
- Overview
- LaunchPad Tool
- Install Procedure
- Verify the SDK on the WAS
- Perform the installation with the wizard
- Perform a silent installation
- Install with a network file system mount
- Uninstalling and reinstalling
- Miscellaneous tips for AIX platforms
Overview
Some steps of the installation procedure require the root ID.
You can restart the installation if you encounter a problem, such as not having enough space, or not having the right fixpacks.
The installation uses InstallShield for Multiplatforms (ISMP) to perform the installation. You can use the Installation wizard or perform the installation from a command line, using the silent installation method.
Use the Network Deployment installation image to manage a multimachine environment, where you have installed the base product on different machines and want to manage the Application Servers in a group, or cell. If you buy the Network Deployment product, you also get the base product in the package.
WAS Server Foundation (WBISF) is the V5.1 level of the Enterprise product. WBISF, V5.1 extends the base WAS V5.1 product. After migrating the underlying product to V5.1, do not reinstall the V5.0.x Enterprise product. V5.0.x of the Enterprise product does not extend V5.1 of the base WAS product nor does it extend the V5.1 Network Deployment product.
If you buy the WBISF product, you also get the Network Deployment product and the base product in the package.
Creating multiple Application Servers on a single machine
Although you can create multiple servers on a base WAS node, the servers all share one set of configuration files. Changes that you make to one server affect the others. Configuration documents might become corrupted. The wsinstance command can create multiple configuration instances. Each instance is a stand-alone Application Server with its own set of configuration files. Or install the Network Deployment product to create and manage multiple base Application Servers.
Order of installation
Install the base product before installing the Network Deployment product when installing both products on the same machine. Install the Network Deployment product before the Integration Server product that extends the Network Deployment product. You can install the Integration Server product before the base product. The Integration Server product can install the base product in what is known as an umbrella installation but Integration Server cannot install the Network Deployment product. Some features of the base product cannot be installed by Integration Server.
The embedded messaging feature that is included in the default installation requires that you install base before Network Deployment when installing both on the same machine. Otherwise, the order does not matter.
This topic is available in Adobe PDF format
LaunchPad Tool
The launchpad tool lets you access the product overview, the readme.html file, and the installation guide.
You also use the launchpad during the installation procedure to install the product. The installation program performs the following actions:
- Checks prerequisites automatically
- Looks for a previous WAS installation, to determine whether to display the Migration panel or the Coexistence panel during the installation
After using the launchpad to view product documentation, perform the following procedure. The procedure includes several preliminary steps before actually launching the installer program.
Install Procedure
- Log on as root.
You cannot install the product correctly as a non-root user on a Linux or UNIX-based operating system platform, or from a user ID on a Windows platform that is not part of the administrators group. If you back up the product CD-ROM on a Linux or UNIX platform, do so as root. Backup copies made from non-root users do not preserve the correct file attributes and do not work.
In addition, Linux and UNIX installers must verify that the umask setting is 022. To verify the umask setting, issue the following command:
umask
To set the umask setting to 022, issue the following command:
umask 022
- Stop all WAS-related Java
processes on the machine where you are installing the product.
- Stop any Web server process such as the IBM HTTP Server, if you
are extending the base product.
- Install the prerequisite xlC.rte 6.0 run-time code on AIX 5.2 maintenance level 1.
You must install the xlC.rte 6.0 run-time code, which is a prerequisite of GSKit7. Download the run-time code as a fix from the AIX Support site.
- Install the mandatory APAR IY58143 fix pack for AIX 5.3.
You must install APAR IY58143. Download the run-time code as a fix from the AIX Fix Central site.
- Provide adequate disk space.The Network Deployment product requires the following disk space:
- 370 MB for the /usr/WebSphere/DeploymentManager directory
- The installation root directory contains the Network Deployment product.
- 150 MB for the /tmp directory
- The temporary directory is the working directory for the installation
program.
A message about free space occurs when less than 4 MB of free space remains after starting the installation. The InstallShield for MultiPlatforms (ISMP) program displays a message about using the -is:tempdir parameter to identify an alternate temporary space directory.
Ignore any -is:tempdir message. The -is:tempdir parameter is not supported. Cancel the installation, allocate at least 150 MB of free space in the /tmp directory, and start the installation again.
- 520 MB
- A significant amount of the required space is temporarily required during installation and is released after installation.
The Installation wizard displays required space for individual features on the Feature selection panel. The Installation wizard also warns you if you do not have enough space to install the product.If you plan to migrate applications and the configuration from a previous version, verify that application objects have available disk space. As a rough guideline, plan for space equal to 110 percent of the size of the application objects:
- For V3.5.x: The size of application Java archive (JAR) files,
Web archive (WAR) files, and servlet files
- For V4.0.x: The size of EAR files
- For V5.0.x: The size of EAR files
- Define the user groups and the user needed for the embedded messaging feature.
A user ID of the name mqm, with a primary group of mqm, owns the directories and files that contain the resources associated with the embedded messaging feature:
- Use the System Management Interface Tool (smit) to create the mqm and mqbrkrs user groups:
- Click...
Security | Users | Groups | Add a Group
- Set the name field to mqm and create the user group.
- Create the mqbrkrs user group in the same way.
- Click...
- Use smit to create the mqm user:
- Click...
Security | Users | Users | Add a User
- Set the name field to mqm and create the user.
- Click...
Security | Users | Change a Users Password | Passwords
...to add a password to the new user ID.
- Use the System Management Interface Tool (smit) to create the mqm and mqbrkrs user groups:
- Use smit to add the mqm and root users to the mqm group:
- Click...
Security | Users | Users | Change / Show Characteristics of a User.
- Enter mqm in the User Name field.
- Add mqm to the Group SET field, which is a comma-separated list
of the groups to which the user belongs.
- Add root to the mqm group and the mqbrkrs group.
The recommended user ID for running the jmsserver process is root. If you do run the jmsserver process under another user ID, add that user ID to the mqm and mqbrkrs groups. User IDs longer than 12 characters cannot be used for authentication with the embedded WebSphere JMS provider.
The mqm user starts the jmsserver for general JMS support and the WebSphere embedded broker for WAS topic connections.
- Click...
- Log out and back in to pick up the secondary user
groups, mqm and mqbrkrs, for root.
Use ssh instead of telnet to log in or set up the display environment for a real root login on AIX systems by running the following command after logging on:
su -
In a normal root login, issue the command su. For a real root login, issue the command su -.
Display settings for a normal root login are automatic. For a real root login, set your display environment properly to successfully view the installation wizard. Otherwise, you see a message about Preparing Java(tm) Virtual Machine..., and seven rows of dots, but no installation GUI and no further messages. Refer to the documentation for your AIX platform to determine proper display settings.
Use the id -a command or the groups command to see defined groups for root. If mqm and mqbrkrs are not in the list that is returned, you cannot install the embedded messaging feature:
[root@wasdoc2 root]# id -a uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon), 3(sys),4(adm),6(disk),10(wheel),500(mqm),501(mqbrkrs) [root@wasdoc2 root]# groups root bin daemon sys adm disk wheel mqm mqbrkrs - Allocate adequate disk space for the embedded messaging feature if you are planning to install the feature.
The installation locations for the embedded messaging feature are fixed as shown in the following table, which lists the locations for the base messaging functions and the messaging broker functions for publish/subscribe messaging.
Space requirements for the embedded messaging feature on AIX
Component Base code Broker code Base data Broker data Path /usr/mqm /usr/opt/wemps /var/mqm /var/wemps Client subfeature 15 MB 15 MB 5 MB N/A
- Prepare to install the embedded messaging feature with WebSphere MQ.
The embedded messaging feature is based on the IBM WebSphere MQ product. The feature and the product each provide a Java message service (JMS) function that supports queues for point-to-point messaging and topics for publish and subscribe messaging. You can install the deployment manager with the embedded messaging client feature with or without the WebSphere MQ product on the same machine. To support both the embedded messaging feature and the WebSphere MQ product on the same machine, the WebSphere MQ product must be at a certain fix level and must have several of its features installed.
If you already have WebSphere MQ installed, you can configure it as the JMS provider. Otherwise, you can install the embedded messaging feature during the installation of the base Application Server. You can also install the WebSphere MQ product or another JMS provider after you install the WAS products.
On a machine where you want appservers to run messaging applications that use a JMS provider on another host, install IBM WebSphere Application Server or the deployment manager with the embedded messaging client feature.
Even though you might decide now to install only the embedded messaging feature, you can install the WebSphere MQ product later and use the IBM WebSphere MQ product as the JMS provider instead.
- Verify that you have upgraded to WebSphere
MQ 5.3 with the CSD04 update to install embedded messaging on a machine where
you already have WebSphere MQ installed.
Determine if your WebSphere MQ 5.3 installation is at the required level by running the mqver utility provided by WebSphere MQ.
The required level as indicated by mqver is shown below:
Name: WebSphere MQ Version: 530.4 CSD04 ...
- Verify that you have installed the required
WebSphere MQ 5.3 features to install embedded messaging on a machine where
you already have WebSphere MQ installed.
When installing the embedded messaging client feature, the required MQ feature is Java messaging.
If you attempt to install the embedded messaging feature when WebSphere MQ is already installed, the level of WebSphere MQ must be V5.3 with the required MQ features. Otherwise, the installation of the embedded messaging feature fails with prerequisite check errors.
- Create and mount a journalized file system called /var/mqm for your messaging working data.
Use a partitioning strategy with a separate volume for embedded messaging or WebSphere MQ data to isolate system activity from the potentially high volume of messaging work that can build up in the /var/mqm directory.
- Create separate file systems for log data
in the var/mqm/log directory and error files in the var/mqm/errors directory.
Store log files on a different physical volume from the embedded messaging queues, which are in the var/mqm directory. This ensures data integrity in the case of a hardware failure. If you are creating separate file systems, allow the following minimum free space:
- 30 MB
- /var/mqm
- 20 MB
- /var/mqm/log
- 4 MB
- /var/mqm/errors
The /var file system stores all the security logging information for the system and stores the temporary files for e-mail and printing. Therefore, it is critical that you maintain free space in /var for these operations. If you do not create a separate file system for messaging data, and /var fills up, all security logging stops on the system until free space is available in /var. Also, e-mail and printing do not work without some available free space in /var.
You have the same options for creating file systems for the embedded messaging feature as you do for WebSphere MQ. For example, if you cannot install the embedded messaging options in the required file system (for example, if it is too small), you can do one of the following before installing embedded messaging:
- Create and mount a new file system for the installation directory.
- Create a new directory anywhere on your machine, and create a symbolic
link from the required installation directory to the new directory. For example,
on AIX:
mkdir /bigdisk/mqm ln -s /bigdisk/mqm /usr/mqm
- Unmount file systems with broken links to
avoid java.lang.NullPointerException errors.
Unmount file systems with broken links before installing.
The installation of the cumulative fix can fail with the following error when broken links exist to file systems:
An error occurred during wizard bean change notification: java.lang.NullPointerException at com.ibm.wizard.platform.aix.AixFileUtils. getFileSystemData(AixFileUtils.java:388) at com.ibm.wizard.platform.aix.AixFileUtils. getPartitionDataWithExecs(AixFileUtils.java:172) at com.ibm.wizard.platform.aix.AixFileUtils. getPartitionData(AixFileUtils.java:104) at com.ibm.wizard.platform.aix.AixFileServiceImpl. getPartitionNames(AixFileServiceImpl.java:397) ...Use the df -k command to check for broken links to file systems. Look for file systems that list blank values in the 1024-blocks size column. Columns with a value of "-" (dash) are not a problem. The following example shows a problem with the /dev/lv00 file system:
> df -k Filesystem 1024-blocks Free %Used Iused %Iused Mounted on /dev/hd4 1048576 447924 58% 2497 1% / /dev/hd3 4259840 2835816 34% 484 1% /tmp /proc - - - - - /proc /dev/lv01 2097152 229276 90% 3982 1% /storage /dev/lv00 /dev/hd2 2097152 458632 79% 42910 9% /usr iw031864:/cdrom/db2_v72_eee_aix32_sbcs
The /proc file system is not a problem. The iw031864:/cdrom/db2_v72_eee_aix32_sbcs file system is a definite problem. The /dev/lv00 file system is also a likely problem. Use one of the following commands to solve this problem:
> umount /cdrom/db2_v72_eee_aix32_sbcs > umount /cdrom
If the problem continues, unmount any file systems that have blank values, such as the /dev/lv00 file system in the example. If you cannot solve the problem by unmounting file systems with broken links, reboot the machine and begin this procedure again.
- Verify that prerequisites and corequisites are at the required release levels.
Always consult the IBM WAS supported hardware, software, and APIs Web site to determine whether your operating system is supported when you receive a message from the prereqChecker program. The Web site lists all supported operating systems and the operating system fixes and patches that install to have a compliant operating system. After confirming that your operating system is supported and that you have installed all necessary patches, you can click Next to continue an installation when you receive an error message from the prereqChecker program.
Some operating systems that were not supported at the time that this product was shipped on CD-ROM might now be supported. You might receive a message from the prereqChecker program that an operating system is not supported when, in fact, the operating system is supported.
![[V5.1.1 and later]](../../v511x.gif)
AIX 5.3 support: See Install a V5.1.x product on a newly certified operating system for an overview of downloading a current prerequisites checker to use during installation of the product on a newly supported operating system. Use a current prerequisites checker file bypasses the operating system not supported error and checks the newly supported operating system to verify that it has the required patches installed.Use the prerequisites.xml file with the install command. For example:
# /cdrom/aix/install -W osLevelCheckActionBean.configFilePath="/tmp/prereqChecker.xml"
- Remove any entries from the /usr/bin/jitk.db file if you
have uninstalled WAS Enterprise Edition V4.1.
Remove any remaining artifacts from an uninstalled Enterprise Edition V4.1 system to prevent the display of the Coexistence panel or the Migration panel during installation.
The Installation wizard might display the Migration panel or the Coexistence panel even though you have uninstalled WAS V4.1. You can prevent the Installation wizard from recognizing a previously deleted V4.1 Application Server by removing the following entry from the /usr/bin/jitk.db file:
WAS 4.1
Remove other V4.x entries for WAS products that are no longer on your system.
- Verify the system cp command when using emacs or other freeware.
If you have emacs or other freeware installed on your AIX operating platform, verify that the system cp command is being used.
- Type which cp at the command prompt before running the installation
program for the WAS product.
- Remove the freeware directory from your PATH if the resulting
directory output includes freeware. For example, if the output is
similar to this /opt/freeware/bin/cp message, remove the directory
from the PATH.
- Install the WAS product.
- Add the freeware directory back to the PATH.
If you install with a cp command that is part of a freeware package, the installation might appear to complete successfully, but the Java 2 SDK that the product installs might have missing files in the install_root/java directory.
Missing files can destroy required symbolic links. If you remove the freeware cp command from the PATH, you can install the Application Server product successfully.
Perform the following step to verify that the Java 2 SDK is working correctly.
- Type which cp at the command prompt before running the installation
program for the WAS product.
- Verify the SDK on the WAS
CD.
Perform the following steps to verify that the SDK on the product CD-ROM is working correctly.
- Change directories to the /aix/WAS/jdk/java/bin directory
on the product CD-ROM.
For example:
cd /mnt/aix/WAS/jdk/java/bin
- Verify the SDK version.
Type the following command:
./java -version
The command completes successfully with no errors when the SDK is intact.
- Change directories to the /aix/WAS/jdk/java/bin directory
on the product CD-ROM.
- Select the Installation wizard method or the silent installation
method but do not start the installation yet.
The installer program has two interfaces, the Installation wizard and a silent command-line installation.
Perform the installation with the wizard
You can start the Installation wizard using the launchpad or directly using the install command.
The default installation method is to open a command window and issue the command to start the launchpad tool. Click the Install the product option on the launchpad.
This option launches the Installation wizard, which is an InstallShield for MultiPlatforms (ISMP) application. This action launches the Installation wizard in the language of your machine locale unless no translation exists for your locale, in which case you receive the English version.
A short delay occurs before the ISMP wizard displays. You do not need to click the Install the product option more than once to cause the wizard to display. The delay is particularly noticeable on x-windows platforms.
You can also start the Installation wizard using...
/cdrom/aix/install
To use the prerequisites xml file:
# /cdrom/aix/install -W osLevelCheckActionBean.configFilePath="/tmp/prereqChecker.xml"
Perform a silent installation
You can perform a silent installation using the -options responsefile parameter with the command method:
fully_qualified_CD_pathname/install
-options fully_qualified_HDD_pathname/responsefile
# /cdrom/aix/install -options /tmp/my_responsefile
Start the silent installation with a fully qualified path to the options response file. Otherwise, the Installation wizard starts.
A silent installation causes the installation program to read your responses from the options response file, instead of from the wizard interface. You must customize the responsefile before installing silently. See Customize the Network Deployment options response file.
After customizing the file, you can issue the command to silently install. See Install silently.
After issuing the command, the following text displays:
# ................................... .InstallShield Wizard Initializing InstallShield Wizard... Searching for Java(tm) Virtual Machine...
The silent installation runs without displaying status to the window:
- Press Enter when the installation is complete to return to the
command prompt.
- Press Enter at any time to return from a background job to the command prompt.
You can change the -W launchPRTBean.active option in the response file to display the Registration panel to indicate the completion of a silent installation on a local system with a graphical user interface.
To determine the status of the silent installation, review the installation logs in the install_root/logs directory or in the /tmp directory. See Troubleshooting the installation for more information about log files.
Silent installation is particularly useful if you install the product often.
The rest of this procedure assumes that you are using the Installation wizard. Corresponding entries in the response file exist for every prompt that is described as part of the wizard.
Review the description of the responsefile for more information. Comments in the file describe how to customize their options.
Asynchronous and synchronous command lines
After running the install command, the command line returns synchronously. A synchronous install command returns the command line after the installation is complete.
You can start the installation asynchronously with the installation process and its children processes all running as background processes. Consult your operating system documentation to learn how to issue asynchronous commands. After running the install command, the command line returns immediately.
Do not misinterpret an asynchronous command line to mean that the installation has finished when the command prompt returns. Although the command line returns, either the Installation wizard or a silent installation might still be in progress.
Install with a network file system mount
If use an NFS mount, see review platform-specific issues when dealing with network file systems
AIX 5.3 support: Download the new prereqChecker.xml file and the prereqChecker.dtd file from the Newly certified operating systems page on the Support site. Use the command line method to start the installation, as described in the next step.
Although you can install the product without the current prereqChecker.xml file, you risk not knowing of required patches for your operating system.
After downloading the prereqChecker.xml file and the prereqChecker.dtd file to a temporary directory (both files must be in the same directory), use the osLevelCheckActionBean.configFilePath parameter to pass the location of the new prereqChecker.xml file to the V5.1.0 installation program.
Use the same shell window throughout the installation procedure.
You can also start the installation directly with the /cdrom/aix/install command. The following example shows a fully qualified call to the installer program:
fully_qualified_CD_pathname/install # /cdrom/aix/install
AIX 5.3 support: If
you downloaded the current prerequisites checker files to install the product
on AIX 5.3, start the installation with the following command:
fully_qualified_CD_pathname/install # /cdrom/aix/install -W osLevelCheckActionBean.configFilePath="/tmp/prereqChecker.xml"
Readme link on the launchpad
The readme link in the launchpad is to the readme.html file in the CD root directory. The Getting Started document that contains installation information is in the docs directory on the CD.
Download the current version of the Getting Started document from:
ftp://ftp.software.ibm.com/software/webserver/appserv/library/wasv51nd_gs.pdf
The rest of this procedure assumes that you are using the Installation wizard. Corresponding entries in the response file exist for every prompt that is described as part of the wizard. Review the description of the responsefile for more information. Comments in the file describe how to customize the options.
The license agreement displays.
The Installation wizard does not support hot keys, such as Alt-N. You can tab to Next and press Enter to select it, for example.
After you accept the licensing terms, the Installation wizard checks for prerequisites and for previous versions, with which it can either migrate or coexist.
The prerequisites checker program recognizes the official supported level for AIX 5.2 as ML1 + APAR IY44183. AIX 5.2 ML2 is also supported. If you receive a message from the prerequisites checker program that AIX 5.2 ML2 is an unsupported operating system, ignore the message and continue the installation.
Update your operating system if it is missing required file sets. If you receive a message that a file set is missing, such as file set X11.fnt.ucs.ttf, cancel the installation, update the operating system, and restart the installation.
As the base WAS product version changes, its prerequisites and corequisites change. Updating your database, Web server, Software Development Kit (SDK), and other software is probably necessary.
The base WAS product simplifies migrating product prerequisites, by providing the option to install a complimentary Web server and SDK on your supported operating system. You can uninstall back-level prerequisites and let the Installation wizard install current versions.
If the wizard finds a previous version of WAS, it prompts you to migrate applications and the configuration from the previous version, or to coexist with it. If it finds more than one previous version, the Installation wizard lists them for you to select which one to migrate.
Migrating or coexisting with an existing WAS node that AIX does not recognize.
In some cases, the InstallShield for MultiPlatforms (ISMP) program might not detect a previously installed version of WAS because of a failure to read the registry keys on AIX. You can force the migration and coexistence panel to display, by starting the installation with an option on the /cdrom/aix/install command.
For example, use this command:
./install -W previousVersionDetectedBean.previousVersionDetected="true"
You can also force the appearance of the coexistence panel to change conflicting port number assignments. For example, force the coexistence panel to appear using this command:
./install -W coexistenceOptionsBean.showCoexistence="true"
On either panel, identify the location of the existing product instance to cause it to be recognized.
- Choose whether to install additional features
or to install the product again, when there is a previous installation of
the same level product.
You can add features at any time, by running the installation wizard again.
This installation wizard panel appears when the installer program detects a previous installation at the same product level. The panel lets you select whether to add features to the existing installation, or perform a new installation to another directory.
If you intend to install additional features, follow this procedure to avoid component regression problems:
- Uninstall any interim fixes.
- Uninstall any cumulative fixes you installed, starting with the last one and finishing with the first one.
- Uninstall any fix packs you installed, starting with the last one and finishing with the first one.
- Log off as root and back on.
- Install new features.
- Install the most current fix pack.
- Install the most current cumulative fix.
- Install any interim fixes to bring the node back to its previous fix level.
- Use the administrative console on the Network Deployment node to synchronize all node agents.
- Choose to migrate applications and the configuration
from a previous version, to coexist with another version, or to neither coexist
or migrate. Click Next to continue.
See Migrating and coexisting for more information.
All WAS products on a single machine share some of the code in the embedded messaging feature, if installed. The required level of the embedded messaging feature for V5.1 (CSD04) is not the same as for V5.0.0 or V5.0.1. The required level of the embedded messaging feature for V5.1 is the same as for V5.0.2.
If you attempt to install V5.1 on a machine where a version of the embedded messaging feature is at a release level earlier than CSD04, the installer program displays the message log in a panel. The message that you see is similar to one of the messages in the following example:
MQSeries or WebSphere MQ server at an earlier release than required to support embedded messaging is already installed on the system. Unsupported earlier maintenance level of MQSeries or WebSphere MQ detected. Unsupported earlier release of MQSeries client or WebSphere MQ client detected. Unsupported maintenance level of MQSeries client or WebSphere MQ client detected. Software conflict with MQSeries JMS SupportPac MA88 detected.
To correct the problem, perform one of the following actions:
- Upgrade the full MQSeries or WebSphere MQ product to WebSphere MQ at the
latest level that supports embedded messaging (CSD04).
See Install WebSphere embedded messaging as the
JMS provider
for more information.
- Uninstall the existing MQSeries or WebSphere MQ product if MQSeries or WebSphere MQ is not required on this system and reinstall the WebSphere Application Server product. Select the embedded messaging feature.
You can upgrade the WAS product to V5.0.2 before migrating it to V5.1 to avoid any problem with an incorrect level of the embedded messaging feature. See Upgrading a V5.0.0 or V5.0.1 product to V5.0.2.
You can also perform the procedure for migrating V5.0.0 or V5.0.1 with embedded messaging to V5.1. See Migrating V5.0.0 or V5.0.1 of WAS with embedded messaging to V5.1.
To share embedded messaging in a coexistence environment, the node names for each installation must be unique, so that each installation has a message queue manager that is named uniquely. To migrate V5.0.2 to V5.1, the node names must be identical. Therefore, the queue manager names are also identical, if you are migrating from V5.0.2 to V5.1.
To prevent losing the queue manager when you uninstall V5.0.2 (or V5.1), create a dummy queue manager before uninstalling one of the WAS versions. A series of migration topics in Migrating and coexisting describe how to migrate after the installation.
The first rule of migration is to migrate
after you install WBISF, if you are planning to install the Integration Server:
If you are planning to install these products: Select the migration option while installing this product: Network Deployment Integration Server Network Deployment Integration Server X X X X X The exception to the rule is to migrate V3.5.x to V5.1 during the installation of the base product or the Network Deployment product, before extending either product.
Migrating Integration Server also
migrates the product that Integration Server extends.You can perform a silent migration or configure for coexistence during a silent installation. Refer to Install silently for a description of performing a silent installation, including the options that you can specify.
The migration prompt appears only when the Installation wizard detects a previous version. The coexistence prompt appears when the Installation wizard detects any other installation, including another Version 5 installation.
If you choose to coexist, the wizard displays a Port selection panel, where you can specify port assignments that do not conflict with existing ports. For example, you can change the HTTP transport port for coexistence, from 9081 (one more than the default V5 port number) to 9085 or higher, to avoid potential conflicts with port numbers that previous versions of WAS commonly use.
Use the netstat -a command to display all ports in use.
In some cases, such as when installing a non-English version, the Installation wizard might not detect a previous version. You can force the Migration panel or the Coexistence panel to appear, by starting the installation with an option on the /cdrom/aix/install command, where mnt/cdrom is the mount point for the product CD-ROM and aix is the platform directory on the CD-ROM.
You can also force the appearance of the Coexistence panel to change conflicting port number assignments. For example, the AIX WebSM system management server listens on port 9090 by default. To avoid a conflict with the administrative console port (HTTP_TRANSPORT_ADMIN) assignment, which is also 9090 by default, force the Coexistence panel to appear using this command:
/cdrom/aix/install -W showCoexistencePanel.active="true"
The AIX WebSM system management server listens on port 9090 by default. If you suspect you have a port conflict, verify it by shutting down WAS and issuing the following command:
If you get a match, another process is already listening on port 9090. If you want the WebSM server and WAS to coexist, change the WebSphere Application Server administrative console port when installing WebSphere Application Server, or after installation. Although not recommended, you can also disable the WebSM server. To disable the WebSM server, issue the following command to permanently disable WebSM server startup:netstat -an |grep 9090
/usr/websm/bin/wsmserver -disable
If you choose neither the migration option nor
the coexistence option, you can run V5.1.x and the previous version,
but not at the same time. Although it is possible that both versions might
coexist without port conflicts, you can ensure that both versions run together
by selecting the coexistence option and checking for conflicting port assignments. The Migration panel lists all previous releases that it can identify. If you highlight a release, the text boxes labeled, "select previous version," show the location of the previous product. Select the product to migrate. If you do not see the previous version that you intend to migrate, click Select previous version to enter a location and configuration file name if you are migrating a WAS Advanced Edition Single Server Edition, Version 4.0.x installation.
The field labeled "Configuration file" is valid only for WAS Advanced Edition Single Server Edition, V4.0.x. For the other versions of WAS that are supported by migration (V3.5 Standard Edition, V3.5 Extended Edition, and V4.0 Advanced Edition), the admin.config file provides the host and port values for the administrative server. If you use a file name other than admin.config, issue the commands that call the migration tools instead of migrating while installing. Issuing the commands that call the migration tools is described in Migrating and coexisting.
Migrate V3.5.x to V5.1 during the installation of the base product or the Network Deployment product, before installing the Integration Server product.
You must start the administrative server of some previous versions so that the Installation wizard can export the configuration from the admin.config file.
Although you might select migration at this point in the installation process, the actual migration does not begin until after the V5 installation is complete. At that time, if the WASPreUpgrade tool fails, the Installation wizard does not call the WASPostUpgrade tool to complete the migration, but instead displays the WASPreUpgrade.log and WASPostUpgrade.log log files for you to diagnose the problem. After fixing the problem, such as starting the administrative server of a previous release, you can start the migration again, as described in Migrating and coexisting.
- Upgrade the full MQSeries or WebSphere MQ product to WebSphere MQ at the
latest level that supports embedded messaging (CSD04).
- Select features to install and click Next to continue.
A description of each feature appears at the bottom of the panel when you roll the cursor over the feature.
Choose from these features:
- Deployment manager
- Installs the product run time. It provides high performance and scalability across your deployment environment. It includes multiserver administration, server clustering, load balancing and workload management for hosting highly available e-business applications.
- Web services
- The UDDI registry and the IBM Web Services Gateway are enterprise applications
that you can deploy to:
- A base WAS product node federated within a Network
Deployment cell
- A stand-alone base WAS node
See Developing Web services
for more information.- UDDI Registry
- Installs a V2 compliant universal description, discovery, and identification
(UDDI) registry, accessible from the UDDI registry user console application,
or from SOAP or EJB interfaces.
See IBM WebSphere UDDI Registry
for more
information.
- Web Services Gateway
- Includes a gateway between Internet and intranet environments so that
clients can invoke Web services safely from outside a firewall. The gateway
uses automatic protocol conversion for externalizing Web services.
See Enabling Web services through the IBM Web Services
Gateway
for more information.
- A base WAS product node federated within a Network
Deployment cell
- Embedded messaging client
- Includes the client necessary for the administration of WebSphere MQ Queues and the mapping of JMS resources into the deployment manager JNDI namespace. It is the same client that you can install as part of the base product embedded messaging feature.
