Migration Guide To IIS8 5

IBM InfoSphere Information Server
Version 8 Release 5
Migrating to IBM InfoSphere Information Server, Version 8.5 Revised September 17, 2010
IBM Confidential
SC18-9924
IBM InfoSphere Information Server

Version 8 Release 5
Migrating to IBM InfoSphere Information Server, Version 8.5 Revised September 17, 2010
IBM Confidential
SC18-9924
IBM Confidential
Edition notice - early release documentation This document contains proprietary information. All information contained herein shall be kept in confidence. None of this information shall be divulged to persons other than (a) IBM employees authorized by the nature of their duties to receive such information, or (b) individuals with a need to know in organizations authorized by IBM to receive this document in accordance with the terms (including confidentiality) of an agreement under which it is provided. This information might include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements or changes in the product or the programs described in this publication at any time without notice.
Copyright IBM Corporation 2006, 2010. US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
IBM Confidential
Contents
Part 1. Overview of migration . . . . 1
Chapter 1. Migrating to IBM InfoSphere Information Server, Version 8.5 . . . . . 3
Migration strategies . . . . . . . . . . . . 3
Chapter 6. Additional migration tasks for advanced or custom topologies . . 43

Export tasks for advanced and custom topologies Migrate databases manually by using scripts . Migrating the InfoSphere Information Analyzer analysis database . . . . . . . . . . Completing premigration activities for IBM InfoSphere QualityStage installations . . . . Import tasks for advanced and custom topologies Migrating to a different topology . . . . . Manually configuring the application server . Additional migration activities for IBM InfoSphere QualityStage . . . . . . . . Opening each project to complete the migration . 43 . 43 . 45 . 45 46 . 46 . 47 . 48 48
Part 2. Version 8.0.1 and later migrations . . . . . . . . . . . . . 5

Chapter 2. Overview and scenarios for 8.0.1 and later . . . . . . . . . . . . 7
Migration from Version 8.0.1 and later . . . . . . 7 Overview of the migration process . . . . . . . 8 Scenario: Migrating a single-computer installation . . 9 Scenario: Migrating a multi-computer installation. . 13
Chapter 7. Reference: Migration directories and files . . . . . . . . . 51

Default migration directories . migration.properties file . . . Host change file . . . . . . Userfiles specifies additional files archive . . . . . . . . . Migration log files . . . . . migration.todo.txt file . . . . . . . to . . . . . . . . . . . . . . . include in . . . . . . . . . . . . . . . . . . . 51 . 52 . 63 . 65 . 66 . 66
Chapter 3. Planning for migration . . . 19

Requirements for ismigration tool . . . . . . Gathering source installation information for the migration.properties file (optional). . . . . . Encrypting passwords . . . . . . . . . . Specifying installation environments in migration.properties files . . . . . . . . . Source installation requirements for using the migration tool to export . . . . . . . . . Verify Version 8.5 QualityStage module availability Verify Version 8.5 enterprise pack availability . . Additional considerations for migrating an existing Oracle database . . . . . . . . . . . . . 19 . 21 . 22 . 22 . 23 25 . 25 . 25
Part 3. Version 7.5.3 and earlier migrations . . . . . . . . . . . . 69

Chapter 8. Migrations from Version 7.5.3 and earlier . . . . . . . . . . . 71 Chapter 9. Migration from DataStage 7.5.3 and earlier versions . . . . . . . 73
Exporting projects . . . . . . . . . . . Exporting projects from the DataStage Manager client . . . . . . . . . . . . . . Exporting projects from the command line . . Saving DataStage settings files . . . . . . . Saving settings files (UNIX and Linux) . . . Saving the DSParams file (Windows) . . . . Move job dependency objects . . . . . . . Migrating hashed files . . . . . . . . . Remove previous versions of DataStage . . . . Removing a DataStage server (Windows) . . Removing a DataStage server (Linux, UNIX) . Removing DataStage clients . . . . . . . Importing DataStage projects . . . . . . . Restoring contents of DataStage 7.5.3 or earlier settings files . . . . . . . . . . . . . Restoring DataStage job dependencies . . . . Restoring hashed files . . . . . . . . . Recompiling jobs . . . . . . . . . . . Updating jobs that use the QualityStage 7.5 plug-in . 73 . . . . . . . . . . . . . . . . 73 74 75 75 75 76 76 77 77 77 77 78 78 78 79 80 80
Chapter 4. Commands for migration . . 27

ismigration tool commands . . . . . . Export command . . . . . . . . . Import command . . . . . . . . . Restart command . . . . . . . . . Encryption tool for use with ismigration tool . . . . . . . . . . . . . . . 27 28 29 30 31
Chapter 5. Migrating basic topologies

Exporting from your source installations. . . . Installing the ismigration tool on your source installations . . . . . . . . . . . . Validating the migration environment . . . Using the ismigration tool to export your source installation . . . . . . . . . . . . Completing the to-do activities . . . . . . Moving the archive files . . . . . . . . . Importing to your target installations . . . . . Preparing the target installation environment . Validating the migration environment . . . Using the ismigration tool to import to your target installation . . . . . . . . . . Completing the to-do activities . . . . . .
33
. 33 . 33 . 34 . . . . . . 34 35 36 37 37 37
. 40 . 41
Copyright IBM Corp. 2006, 2010
iii
IBM Confidential Switching between different versions of clients . . Multiple server method (Linux and UNIX only) . . Installing Version 8.5 in addition to existing DataStage servers . . . . . . . . . . . Installing IBM InfoSphere DataStage, Version 8.5 clients in addition to existing clients . . . . . Starting and stopping multiple DataStage servers Connecting to multiple DataStage servers . . . 81 81 83 83 84 84 Migrating RTIX files to Version 8.5 . . . . . . 97
Part 4. Client-only upgrades . . . . 99

Chapter 12. Upgrading a client tier-only installation to Version 8.5 . . 101
Chapter 10. Migration from QualityStage 7.5 and earlier releases. . 87

Job migration in legacy operational mode . . . QualityStage job migration in expanded form . . Rule set migration . . . . . . . . . . . Match specification migration . . . . . . . Installing the WebSphere QualityStage migration utility . . . . . . . . . . . . . . . Running the QualityStage migration utility . . . Importing the migrated files into the Version 8.5 Designer client . . . . . . . . . . . Preparing migrated QualityStage jobs for operation . . . . . . . . . . . . . Migrating real-time QualityStage jobs from Release 7 to Version 8.5 . . . . . . . . . . . . Replace InfoSphere QualityStage 7 data quality stages . . . . . . . . . . . . . . . . . . . 87 88 88 88
Part 5. Appendixes . . . . . . . . 103

Product accessibility . . . . . . . . 105 Accessing product documentation 107
Reading command-line syntax . . . . 109 Links to non-IBM Web sites . . . . . 111 Notices and trademarks . . . . . . . 113 Contacting IBM . . . . . . . . . . 117
. 89 . 89 . 91 . 92 . 93 . 94
Index . . . . . . . . . . . . . . . 119
Chapter 11. Migration from IBM WebSphere RTI 7.5, 7.5.1, and 7.5.2 installations . . . . . . . . . . . . 97
iv
Migrating to IBM InfoSphere Information Server, Version 8.5
IBM Confidential
Part 1. Overview of migration
IBM Confidential
IBM Confidential
Chapter 1. Migrating to IBM InfoSphere Information Server, Version 8.5

Migration enables you to move existing source installations to new IBM InfoSphere Information Server, Version 8.5, installations. The current version and the translated versions of this information are on the Web at http://publib.boulder.ibm.com/infocenter/iisinfsv/v8r5/topic/ com.ibm.swg.im.iis.productization.iisinfsv.migrate.doc/topics/migr_container.html. The version of your existing installation determines how you migrate to a new IBM InfoSphere Information Server, Version 8.5 installation.
Migration strategies
You will use different migration strategies and methods to migrate to Version 8.5 from existing installations. Plan your strategy and choose your migration method based on the version of your existing installation. Successful migration requires that you understand your IBM InfoSphere Information Server installation topology on the source computers and your InfoSphere Information Server installation topology on the target computers. You must use one of the following methods to migrate your source installation to a new Version 8.5 installation:
Table 1. Supported migrations to Version 8.5 Existing installation (source) Information Server, Version 8.0.1 and later Migration method If you want to do this type of migration, see www.ibm.com/support/ docview.wss?uid=swg21445403. Export projects and save the settings files from the existing installation. Then import the projects and move the settings files to the Version 8.5 installation. See Chapter 9, Migration from DataStage 7.5.3 and earlier versions, on page 73. Use the QualityStage migration utility. See Chapter 10, Migration from QualityStage 7.5 and earlier releases, on page 87. Use the WebSphere RTI Export Wizard. See Chapter 11, Migration from IBM WebSphere RTI 7.5, 7.5.1, and 7.5.2 installations, on page 97.
DataStage, releases from 7.5.3 and earlier
QualityStage, release 7.5 and earlier
IBM WebSphere RTI 7.5, 7.5.2, and 7.5.1
Note: You do not migrate computers that only have the client tier installed on them. Computers that only have client tier software installed do not contain installation information or data that requires migration. To upgrade these computers to Version 8.5, you run the InfoSphere Information Server suite installation program.
IBM Confidential
IBM Confidential
Part 2. Version 8.0.1 and later migrations
IBM Confidential
IBM Confidential
Chapter 2. Overview and scenarios for 8.0.1 and later

You can use the single-computer and multi-tier scenarios to prepare for your migration from 8.0.1 and later. The ismigration tool helps you move from your existing environment (the source) to your new Version 8.5 installation (the target).
Migration from Version 8.0.1 and later

Use the ismigration tool to migrate from IBM InfoSphere Information Server, Version 8.0.1 and later installations to new Version 8.5 installations. The ismigration tool supports migration from installations that are at Version 8.0.1 and later, which includes Version 8.1, Version 8.1.1, Version 8.1.2, and Version 8.5. The ismigration tool support extends to patched installations and installations at fix pack levels for these versions.
Migrated data
The ismigration tool process migrates data in the metadata repository. This includes work that is completed in the following products, if installed: IBM InfoSphere DataStage and QualityStage, IBM InfoSphere Information Analyzer, IBM InfoSphere FastTrack, IBM InfoSphere Business Glossary, IBM InfoSphere Information Services Director, and IBM InfoSphere Metadata Workbench. Note: There are exceptions. The following data is not migrated:
Table 2. Data that is not migrated in the ismigration tool process Product IBM InfoSphere DataStage What is not migrated v Data sets. v For 8.0.1 or 8.1 InfoSphere DataStage job run time, after you migrate to the target system, you must recompile and redeploy your jobs. v InfoSphere DataStage runtime logs. IBM InfoSphere QualityStage Postal validation reference and geocoding data reference files.
IBM WebSphere Application Server logs are also not migrated. Additional information for InfoSphere DataStage users: If you are planning to migrate only InfoSphere DataStage, it might be useful to know the difference between using the import and export (or asset interchange functionality) and migrating by using the ismigration tool. The ismigration tool performs a more complete migration because it works at the metadata repository level. A sample of the benefits of using this tool to migrate your work in InfoSphere DataStage are: v Copies your existing source InfoSphere DataStage projects and creates them in a directory that you specify on the Version 8.5 target installation
IBM Confidential
v Migrates and merges DSParams, including project environment variables and project settings v Project user roles, DSEngine maps, Message Handlers, and Parameter set files are brought across. v Checks the stages in the existing jobs for any referenced files and creates a report that you can use to copy referenced files to the target installation v Can validate your source system before export and can validate your target system before import v If using IBM InfoSphere QualityStage, customized overrides are brought across
Overview of the migration process

The migration to IBM InfoSphere Information Server, Version 8.5 from Version 8.01 or later installations is a two-phase process that runs the ismigration tool first on your source installation and then on your target Version 8.5 installation. The ismigration tool process follows these basic steps: 1. Plan for your migration. 2. Export your source installation. The ismigration tool export process generates an archive file (*.iar) and a migration.todo.txt file for each services tier computer and engine tier computer that you migrate. When you migrate basic topologies, the metadata repository database is included in the archive file that is generated for the services tier computer. 3. Move the archive file from each source installation computer to your target installation. You review and complete the manual activities that are specified in the migration.todo.txt file, and move the archive file to your target computers. 4. Install Version 8.5 on your target computers and ensure that the settings are like your source system. See Requirements for ismigration tool on page 19. 5. Import the files into your target installation. The ismigration tool import process imports the archive file to populate your new target Version 8.5 installation. The following diagram illustrates the migration process that uses the ismigration tool.
IBM Confidential
Export to generate the archive files
Import the archive files
Engine tier
Services (domain) tier
Move the archive files
Engine tier
Metadata repository tier
Version 8.0.1 or later Source installation
Version 8.5 Target installation
Figure 1. Migration process overview
Scenario: Migrating a single-computer installation

This scenario provides an example for migrating from a Version 8.0.1 or later source installation to a Version 8.5 target installation, where there are no installation topology changes. The source installation is on the single Computer A, and so the target installation is also on the single Computer B. The following diagram illustrates this migration scenario.
Computer A
Client tier
Computer B
Client tier
Engine tier
Services tier
Engine tier
Services tier
Figure 2. Single computer migration
If any of the following conditions apply to your installation, additional migration tasks are required beyond this basic scenario: v The metadata repository tier and services (domain) tier are not installed on the same computer in either the source or target installations. v You choose not to include the metadata repository tier in the archive file.
IBM Confidential
v You choose to manually configure the application server configuration settings. v IBM InfoSphere QualityStage and its modules are installed. v Your target installation will have different project locations or port numbers. You must log in as root or administrator with full privileges to complete the migration.
1. Export the 8.0.1 source installation

The following table describes the tasks that you do on the 8.0.1 source installation (Computer A) to export it. For details, see Exporting from your source installations on page 33.
Table 3. Exporting the Version 8.0.1 source installation Task a. Review the requirements and restrictions for running a successful migration. Back up the source installation. b. Download and install the latest version of the Update Installer and then the ismigration tool. c. Optional: Gather the required installation information from the source installation and confirm the stability of the source installation environment, by downloading and running IBM Support Assistant Lite for InfoSphere Information Server. For preinstalled database servers, contact the database administrator to gather the required information. d. Encrypt the user credential passwords for the migration.properties file. Example command: Details See Chapter 3, Planning for migration, on page 19 and Requirements for ismigration tool on page 19. For details about installing the Update Installer, see Installing the ismigration tool on your source installations on page 33. In IBM Support Assistant Lite, run General Diagnostic Health Checker to generate the Basic System Summary and the General Diagnostic Health Checker reports. See Gathering source installation information for the migration.properties file (optional) on page 21.
C:\IBM\InformationServer\Migration\bin\encrypt.bat <my_password> After you encrypt the passwords, copy the encrypted password from the command output, and use it in the migration.properties See Encryption tool for use with ismigration tool on page 31. file instead of using the actual passwords. e. Specify the 8.0.1 user names and paths in the Example contents of the properties file: migration.properties file. Do not specify is.suite.admin.username=admin values for the other properties. is.suite.admin.password=4Bdmc6yfQVmqCqirnRj2zg== xmeta.db.binpath=/opt/IBM/db2/V9/bin xmeta.db2.admin.username=db2inst1 xmeta.db2.installdir=/opt/IBM/InformationServer/Repository/xmeta datastage.engine.admin.username=dsadm datastage.engine.admin.password=4Bdmc6yfQVmqCqirnRj2zg== ia.db.binpath=/opt/IBM/db2/V9/bin ia.db2.installdir=/opt/IBM/InformationServer/Repository/iadb See Specifying installation environments in migration.properties files on page 22 and migration.properties file on page 52.
10
IBM Confidential Table 3. Exporting the Version 8.0.1 source installation (continued) Task f. Validate the source installation before you export by using the ismigration tool. Details Example command: C:\IBM\InformationServer\Migration\bin\ismigration.bat -export -archive C:\Migration\archives -config C:\Migration\ComputerA\ conf\migration.properties -work C:\migr_work -validateonly See Validating the migration environment on page 34. g. Run the ismigration tool at a command line to export the source installation. The export process creates the following files: v Archive file for the services tier: ComputerA_SERVICES_timestamp.iar v Archive file for the engine tier: ComputerA_ENGINE_timestamp.iar v To do file: migration.todo.txt h. Complete any required activities in the migration.todo.txt file. See migration.todo.txt file on page 66. Example command: C:\IBM\InformationServer\Migration\bin\ismigration.bat -export -archive C:\Migration\archives -config C:\Migration\ComputerA\ conf\migration.properties -work C:\migr_work See Using the ismigration tool to export your source installation on page 34.
2. Move the archive files

The following table describes the task to move the archive files from the 8.0.1 source installation (Computer A) to the 8.5 target installation (Computer B).
Table 4. Moving the archive files Task After you export the source installation, move the archive files and other required files: v ComputerA_ENGINE_timestamp.iar and ComputerA_SERVICES_timestamp.iar archive files. v Other required files, as defined in the migration.todo.txt file. Details See Moving the archive files on page 36.
3. Import the 8.0.1 source installation to the 8.5 target installation

The following table describes the tasks that you do on the 8.5 target installation (Computer B) to import the 8.0.1 source installation (Computer A). For details, see Importing to your target installations on page 37.
11
IBM Confidential Table 5. Importing the 8.0.1 source installation into the target 8.5 installation Task a. Create a new installation of Version 8.5: v The services tier, metadata repository tier, and engine tier must match the existing installation. v Install the same products and enterprise packs as your source installation. v The user credentials for the metadata repository database owner (xmeta) and the information analysis database owner (iauser) must match the user credentials on your source installation. If you used an external user registry, wasadmin and isadmin must also match the source installation. For dsadm, if credentials are different, you must update credential mappings after you complete the migration. b. Encrypt the user credential passwords for the migration.properties file. Details See the IBM InfoSphere Information Server Planning, Installation, and Configuration Guide. See Preparing the target installation environment on page 37. Optional: In IBM Support Assistant Lite, select General Diagnostic Health Checker to generate the Basic System Summary and the General Diagnostic Health Checker reports.
Example command:
C:\IBM\InformationServer\Migration\bin\encrypt.bat <my_password> After you encrypt the passwords, copy the encrypted password from the command output, and use it in the migration.properties See Encryption tool for use with ismigration tool on page 31. file instead of using the actual passwords. c. Specify the user names and paths in the migration.properties file. Do not specify values for the other properties. Example contents of the properties file: is.suite.admin.username=admin is.suite.admin.password=3lpi8OwUGOGqCqirnRj2zg== xmeta.db.binpath=C:\\IBM\\SQLLIB\\bin xmeta.db2.installdir=c:\\ xmeta.db2.admin.username=db2admin datastage.engine.admin.username=dstage datastage.engine.admin.password=3lpi8OwUGOGqCqirnRj2zg== ia.db.binpath=c:\\IBM\\ ia.db2.installdir=c:\\ See Specifying installation environments in migration.properties files on page 22 and migration.properties file on page 52. d. Validate the target installation before you import by using the ismigration tool. Example command: C:\IBM\InformationServer\Migration\bin\ismigration.bat -import -archive C:\Migration\archives -config C:\Migration\ComputerB\ conf\migration.properties -work C:\migr_work -validateonly See Validating the migration environment on page 34. e. Run the ismigration tool to import the source installation to the target installation. Example command: C:\IBM\InformationServer\Migration\bin\ismigration.bat -import -archive E:\Migration\archives -config C:\Migration\ComputerB\ conf\migration.properties -work C:\migr_work See Using the ismigration tool to import to your target installation on page 40. f. Complete any required activities in the migration.todo.txt file. g. Optional: Confirm the stability of the 8.5 installation. See migration.todo.txt file on page 66. In IBM Support Assistant Lite, select General Diagnostic Health Checker.
12
IBM Confidential
What to do next
After you complete the 8.0.1 migration, you upgrade the clients.
Scenario: Migrating a multi-computer installation

This scenario provides an example for migrating from a Version 8.0.1 or later source installation to a Version 8.5 target installation. The source installation is on two computers, and the target installation is on two computers. In this example, Version 8.0.1 is installed on two different computers and is migrating to a new Version 8.5 target installation on two different computers: v The Version 8.0.1 source installation consists of the following computers: Computer A (metadata repository tier and services tier) Computer B (engine tier) v The Version 8.5 target installation consists of the following computers: Computer C (metadata repository tier and services tier) Computer D (engine tier) The following diagram illustrates this migration scenario.
Computer A
Computer C
Computer B
Computer D
Engine tier
Engine tier

Figure 3. Multi-computer migration
If any of the following conditions apply to your installation, additional migration tasks are required beyond this basic scenario: v The metadata repository tier and services (domain) tier are not installed on the same computer in either the source or target installations.
13
IBM Confidential
v v v v
You choose not to include the metadata repository tier in the archive file. You choose to manually configure the application server configuration settings. IBM InfoSphere QualityStage and its modules are installed. Your target installation will have different project locations or port numbers.
You must log in as root or administrator with full privileges to complete the migration.
1. Export the 8.0.1 source installation

The following table describes the tasks that you do on the 8.0.1 source installation (Computers A and B) to export it. For details, see Exporting from your source installations on page 33.
Table 6. Exporting the Version 8.0.1 source installation Task a. Review the requirements and restrictions for running a successful migration. Back up the source installation. Details See Chapter 3, Planning for migration, on page 19 and Requirements for ismigration tool on page 19.
b. On Computers A and B (engine, services, For details about installing the Update Installer, see Installing the and metadata repository tiers), download and ismigration tool on your source installations on page 33. install the latest version of the Update Installer and then the ismigration tool. c. Optional: On Computers A and B (engine, services, and metadata repository tiers), gather the required installation information from the source installation and confirm the stability of the source installation environment, by downloading and running IBM Support Assistant Lite for InfoSphere Information Server. For preinstalled database servers, contact the database administrator to gather the required information. d. On Computer A (services and metadata repository tiers), encrypt the user credential passwords for the migration.properties file. Example command: C:\IBM\InformationServer\Migration\bin\encrypt.bat <my_password> In IBM Support Assistant Lite, run General Diagnostic Health Checker to generate the Basic System Summary and the General Diagnostic Health Checker reports. See Gathering source installation information for the migration.properties file (optional) on page 21.
After you encrypt the passwords, copy the See Encryption tool for use with ismigration tool on page 31. encrypted password from the command output, and use it in the migration.properties file instead of using the actual passwords. e. On Computer A (services and metadata repository tiers), specify the 8.0.1 user names and paths in the migration.properties file. Do not specify values for the other properties. Example contents of the properties file: is.suite.admin.username=admin is.suite.admin.password=3lpi8OwUGOGqCqirnRj2zg== xmeta.db.binpath=C:\\IBM\\SQLLIB\\bin xmeta.db2.admin.username=db2admin ia.db.binpath=c:\\IBM\\SQLLIB\\BIN ia.db2.installdir=c:\\ See Specifying installation environments in migration.properties files on page 22 and migration.properties file on page 52.
14
IBM Confidential Table 6. Exporting the Version 8.0.1 source installation (continued) Task Details
f. On Computer A (services and metadata Example command: repository tiers), validate the source installation C:\IBM\InformationServer\Migration\bin\ismigration.bat -export before you export by using the ismigration -archive C:\Migration\archives -config C:\Migration\ComputerA\ tool. conf\migration.properties -work C:\migr_work -validateonly See Validating the migration environment on page 34. g. On Computer A (services and metadata Example command: repository tiers), run the ismigration tool at a command line to export the source installation. C:\IBM\InformationServer\Migration\bin\ismigration.bat -export -archive C:\Migration\archives -config C:\Migration\ComputerA\ The export process creates the following files: conf\migration.properties -work C:\migr_work v Archive file for the services tier: ComputerA_SERVICES_timestamp.iar See Using the ismigration tool to export your source installation v To do file: migration.todo.txt h. On Computer A (services and metadata repository tiers), complete any required activities in the migration.todo.txt file. i. On Computer B (engine tier), encrypt the user credential passwords for the migration.properties file. on page 34. See migration.todo.txt file on page 66.
Example command: C:\IBM\InformationServer\Migration\bin\encrypt.bat <my_password>
After you encrypt the passwords, copy the See Encryption tool for use with ismigration tool on page 31. encrypted password from the command output, and use it in the migration.properties file instead of using the actual passwords. j. On Computer B (engine tier), specify the 8.0.1 Example contents of the properties file: user names and paths in the datastage.engine.admin.username=dstage migration.properties file. Do not specify datastage.engine.admin.password=3lpi8OwUGOGqCqirnRj2zg== values for the other properties. See Specifying installation environments in migration.properties files on page 22 and migration.properties file on page 52. k. On Computer B (engine tier), validate the source installation before you export by using the ismigration tool. Example command: C:\IBM\InformationServer\Migration\bin\ismigration.bat -export -archive C:\Migration\archives -config C:\Migration\ComputerB\ conf\migration.properties -work C:\migr_work -validateonly See Validating the migration environment on page 34. l. On Computer B (engine tier), run the ismigration tool at a command line to export the source installation. The export process creates the following files: v Archive file for the engine tier: ComputerB_ENGINE_timestamp.iar v To do file: migration.todo.txt m. On Computer B (engine tier), complete any required activities in the migration.todo.txt file. Example command: C:\IBM\InformationServer\Migration\bin\ismigration.bat -export -archive C:\Migration\archives -config C:\Migration\ComputerB\ conf\migration.properties -work C:\migr_work See Using the ismigration tool to export your source installation on page 34. See migration.todo.txt file on page 66.
15
IBM Confidential
2. Move the archive files

The following table describes the task to move the archive files from the 8.0.1 source installation (Computers A and B) to the 8.5 target installation (Computers C and D).
Table 7. Moving the archive files Task After you export the source installation, move the archive files and other required files: v Move the ComputerA_SERVICES_timestamp.iar archive file from Computer A (source installation) to Computer C (target installation). v Move the ComputerB_ENGINE_timestamp.iar archive file from Computer B (source installation) to Computer D (target installation). v As defined in the migration.todo.txt file, move other required files from the source installation computers to the target installation computers. Details See Moving the archive files on page 36.
3. Import the 8.0.1 source installation to the 8.5 target installation

The following table describes the tasks that you do on the 8.5 target installations (Computers C and D) to import the 8.0.1 source installation (Computers A and B). For details, see Importing to your target installations on page 37.
Table 8. Importing the 8.0.1 source installation into the target 8.5 installation Task a. On Computers C and D (engine, services, and metadata repository tiers), create a new installation of Version 8.5: v The services tier, metadata repository tier, and engine tier must match the existing installation. v Install the same products and enterprise packs as your source installation. v The user credentials for the metadata repository database owner (xmeta) and the information analysis database owner (iauser) must match the user credentials on your source installation. If you used an external user registry, wasadmin and isadmin must also match the source installation. For dsadm, if credentials are different, you must update credential mappings after you complete the migration. Details See the IBM InfoSphere Information Server Planning, Installation, and Configuration Guide. See Preparing the target installation environment on page 37. Optional: In IBM Support Assistant Lite, select General Diagnostic Health Checker to generate the Basic System Summary and the General Diagnostic Health Checker reports.
16
IBM Confidential Table 8. Importing the 8.0.1 source installation into the target 8.5 installation (continued) Task b. On Computer C (services and metadata repository tiers), encrypt the user credential passwords for the migration.properties file. Details Example command: C:\IBM\InformationServer\Migration\bin\encrypt.bat <my_password>
After you encrypt the passwords, copy the See Encryption tool for use with ismigration tool on page 31. encrypted password from the command output, and use it in the migration.properties file instead of using the actual passwords. c. On Computer C (services and metadata repository tiers), specify the user names and paths in the migration.properties file. Do not specify values for the other properties. Example contents of the properties file: is.suite.admin.username=admin is.suite.admin.password=3lpi8OwUGOGqCqirnRj2zg== xmeta.db.binpath=C:\\IBM\\SQLLIB\\bin xmeta.db2.installdir=c:\\ xmeta.db2.admin.username=db2admin ia.db.binpath=c:\\IBM\\ ia.db2.installdir=c:\\ See Specifying installation environments in migration.properties files on page 22 and migration.properties file on page 52. d. On Computer C (services and metadata repository tiers), validate the target installation before you import by using the ismigration tool. Example command: C:\IBM\InformationServer\Migration\bin\ismigration.bat -import -archive C:\Migration\archives -config C:\Migration\ComputerC\ conf\migration.properties -work C:\migr_work -validateonly See Validating the migration environment on page 34. e. On Computer C (services and metadata repository tiers), run the ismigration tool to import the source installation to the target installation. Example command: C:\IBM\InformationServer\Migration\bin\ismigration.bat -import -archive E:\Migration\archives -config C:\Migration\ComputerC\ conf\migration.properties -work C:\migr_work See Using the ismigration tool to import to your target installation on page 40. f. On Computer C (services and metadata repository tiers), complete any required activities in the migration.todo.txt file. g. On Computer D (engine tier), encrypt the user credential passwords for the migration.properties file. See migration.todo.txt file on page 66.
Example command: C:\IBM\InformationServer\Migration\bin\encrypt.bat <my_password>
After you encrypt the passwords, copy the See Encryption tool for use with ismigration tool on page 31. encrypted password from the command output, and use it in the migration.properties file instead of using the actual passwords. h. On Computer D (engine tier), specify the user names and paths in the migration.properties file. Do not specify values for the other properties. Example contents of the properties file: datastage.engine.admin.username=dstage datastage.engine.admin.password=3lpi8OwUGOGqCqirnRj2zg== See Specifying installation environments in migration.properties files on page 22 and migration.properties file on page 52.
17
IBM Confidential Table 8. Importing the 8.0.1 source installation into the target 8.5 installation (continued) Task i. On Computer D (engine tier), validate the target installation before you import by using the ismigration tool. Details Example command: C:\IBM\InformationServer\Migration\bin\ismigration.bat -import -archive C:\Migration\archives -config C:\Migration\ComputerD\ conf\migration.properties -work C:\migr_work -validateonly See Validating the migration environment on page 34. j. On Computer D (engine tier), run the ismigration tool to import the source installation to the target installation. Example command: C:\IBM\InformationServer\Migration\bin\ismigration.bat -import -archive E:\Migration\archives -config C:\Migration\ComputerD\ conf\migration.properties -work C:\migr_work See Using the ismigration tool to import to your target installation on page 40. k. On Computer D (engine tier), complete any required activities in the migration.todo.txt file. l. Optional: Confirm the stability of the 8.5 installation. See migration.todo.txt file on page 66.
In IBM Support Assistant Lite, select General Diagnostic Health Checker.
What to do next
After you complete the 8.0.1 migration, you upgrade the clients.
18
IBM Confidential
Chapter 3. Planning for migration

The primary planning for migration involves understanding and preparing your source and target installation topologies. Familiarize yourself with your source installation and plan your target installation topology, before you begin the migration process. Moreover, back up your source installation. Optionally, use the IBM Support Assistant Lite tool to gather the required installation information from your source installation. You can migrate from an existing installation to the same topology or to a different topology on a new Version 8.5 installation. v Migration from Release 7.5.3 and earlier to any Version 8.5 installation. v Migration from Version 8.0.1 and later to a new Version installation with the same or different installation topologies. v Migrate from an existing Version 8.5 installation to a new Version 8.5 installation. Tip: Plan a dedicated time to export your source installation. Your source installation halts during the migration process. Log off all users. You must manually restart your InfoSphere Information Server installation after the export is completed. Similarly for the target installation, consider any dependencies or requirements that the installation, its databases, and the application server might have.
Requirements for ismigration tool

The requirements for the ismigration tool apply to your source installation and your Version 8.5 target installation.
Verify that you have enough disk space for your migration
The ismigration tool is supported on installations that have enough available disk space. The work directory must have enough available disk space to hold the contents of a full database backup for both the metadata repository and the IBM InfoSphere Information Analyzer analysis databases. On both the source and target installations, increase the required disk space calculations by 25% to ensure that you have enough available disk space. You must also verify that there is sufficient available disk space for the project files in your Projects directories. The default Projects directory is in the default installation directory: v v
Linux Windows UNIX
/opt/IBM/InformationServer/Projects
C:\IBM\InformationServer\Projects
If you specified a different directory for projects for your installation, then verify the available disk space in that directory.
19
IBM Confidential
Requirements and restrictions

You can use the ismigration tool only if your target installation meets these requirements: v New installation of IBM InfoSphere Information Server, Version 8.5. Do not log on to the IBM InfoSphere Information Server console before you use the InfoSphere Information Server migration tool to import to your target Version 8.5 installation. v The available disk space on the target installation is twice the amount of the disk space that was required by the export. v The number of engines is the same as the source installation v The source system and target system must have the same product modules. You cannot install fewer or more InfoSphere Information Server product modules on the target installation. To add product modules to the target installation, you must complete the migration, then install the additional product modules. To remove product modules from the target installation, you must complete the migration, then remove the product modules. v The operating system is the same operating system as the source installation. Note: However, migration from 32-bit Linux to 64-bit Linux is supported. v The source system and target system must be using the same version of the ismigration tool. To check the version of the tool, use the -version option. For example, on Microsoft Windows, run the following the command on both systems and compare the output to verify that the versions on the source and target are the same:
C:\IBM\InformationServer\Migration\bin\ismigration.bat -version
v The database servers are the same database servers as the source installation. (For example, the source installation and target installation both us IBM DB2 database servers; or they both use Oracle database servers). v The NLS configuration must be the same as the source installation v The same packs that were installed on the source must be installed on the target installation before import v IBM InfoSphere QualityStage modules must be installed after import. See Completing premigration activities for IBM InfoSphere QualityStage installations on page 45. v The following database credentials and environments must be the same on the source and the target installations: Owner of the metadata repository Metadata repository database owner user name Information analysis database owner user name Database schema Database Endian environment Oracle tablespace name
The ismigration tool validates these requirements for each import and export. You can use the -validateonly parameter to validate these requirements before you use the tool to import or export.
20
IBM Confidential
Additional preparations for your migration

v Ensure that the work directory's parent folder (/home or /home/dsadm) has "drwxr-xr-x" (read/execute) permission for all users. v Passwords for all users must be valid and unexpired, which includes the following preconfigured users: InfoSphere Information Server administrator (for example, isadmin) WebSphere Application Server administrator (for example, wasadmin) InfoSphere DataStage administrator (for example, dsadm) DB2 non-fenced instance user (for example, db2inst1) Metadata repository database owner (for example, xmeta) Information analysis database owner (for example, iauser)
Gathering source installation information for the migration.properties file (optional)

Generate reports that provide the required installation information from your source installation. You use this information to create your migration.properties file. If your source installation system is Version 8.0.1 or later, download and install the IBM Support Assistant Lite for InfoSphere Information Server tool. For details on downloading and installing the tool, see the IBM Support Assistant Lite for InfoSphere Information Server Quick Start Guide. Note: If your source installation is Version 8.5, this step is not required before running the tool. Refer to the IBM Support Assistant Lite for Information Server Quick Server Guide contained in the ISALite folder in the InfoSphere Information Server, Version 8.5 installation folder. You can run IBM Support Assistant Lite for InfoSphere Information Server to generate reports that provide information and confirm the stability of your source installation environment. Run the tool and generate reports for each source installation computer that you plan to migrate. The health checker reports generated are intended to point out areas of interest that may warrant further analysis at the appropriate time. Further analysis before you proceed with migration tasks might not be required. When in doubt, please consult with your IBM Support personnel 1. Log in as a user with administrative privileges. 2. Start the IBM Support Assistant Lite for InfoSphere Information Server tool. 3. Select All Diagnostic Tools > General Diagnostic Health Checker to generate the Basic System Summary report to gather the required information that you need to create the migration.properties file for the local installation. 4. Select All Diagnostic Tools > General Diagnostic Health Checker to generate the General Diagnostic Health Checker reports to verify the stability of the local installation environment. Use the information in the Basic System Summary report to update the migration.properties file for the local installation.
21
IBM Confidential
Encrypting passwords
Use the encryption tool to encrypt passwords and other information. Use the encrypted properties values for entries that you specify in the migration.properties file. By default, information is stored in plain text in the migration.properties file. If you want to encrypt passwords or other information, follow this procedure to encrypt information and include it in the file. The encrypted values are accepted by the IBM InfoSphere Information Server migration tool on the source and target installations. 1. Create the migration.properties file. See Specifying installation environments in migration.properties files. 2. Run the encrypt command to generate encrypted information. The encryption tool is located in the bin directory: v
Linux UNIX
/opt/IBM/InformationServer/Migration/bin/encrypt.sh value_to_encrypt
Windows
C:\IBM\InformationServer\Migration\bin\encrypt.bat value_to_encrypt
For example:
C:\IBM\InformationServer\Migration\bin\encrypt.bat password4dsadm
The encrypted version of the specified information is displayed. For example:

5LxDQbAqU8dZhv8JT7w/cQ==
3. In the your migration.properties file, use the encrypted value instead of using your actual password. For example: v Original entry:
datastage.engine.admin.password=password4dsadm
v Encrypted entry:
datastage.engine.admin.password=5LxDQbAqU8dZhv8JT7w/cQ==
Specifying installation environments in migration.properties files

Before you use the ismigration tool, you must specify the details of the installation environment that you want to migrate in the migration.properties file. You prepare that file for each services tier and engine tier computer in your source and target installations. Optional: To gather the required information, use the IBM Support Assistant Lite for InfoSphere Information Server tool to generate installation reports. The migration.properties file defines the migration environment of the local installation. This file is required for each computer that you want to migrate. 1. Locate the migration.properties.sample file in the following directories: v Linux, UNIX: /opt/IBM/InformationServer/Migration/conf v Windows: C:\IBM\InformationServer\Migration\conf 2. Create a copy of the file in the same directory. 3. Name the new file migration.properties. 4. Use a text editor, such as Wordpad, to view and change the entries in the file.
22
IBM Confidential
5. Ensure that the following required suite-level entries are accurate and appropriate for the local installation. a. (Source only) is.suite.admin.username b. (Source only) is.suite.admin.password 6. (Services tier only) Ensure that the following required database entries are accurate and appropriate for the local installation. a. xmeta.db.binpath b. Properties that are required for your database server 7. (Engine tier only) Ensure that the following required engine entries are accurate and appropriate for the local installation. a. datastage.engine.admin.username b. datastage.engine.admin.password 8. Review the file and ensure that the additional entries as required by your environment are present and accurate. Use the -validateonly parameter to validate the properties file before you migrate.
Source installation requirements for using the migration tool to export

Ensure that your source installation meets the following validation requirements before you use the ismigration tool.
Validation environment
The validation requirements for the source installation are based on the installation tier and the products that are installed. This information assumes that you are using the default location and file name of the migration.properties file. References to the migration.properties file also apply to the properties file that is specified with the -config parameter.
All tiers
The following validation occurs on all tier computers in the source installation. Properties are defined in migration.properties file The default migration.properties file, or the file that is specified with the -config parameter, is present. The properties that are required for the installation tier are defined in the file. Source installation software version The version of your source installation of IBM InfoSphere Information Server is compatible with the version of the ismigration tool.
Services tier
The following validation occurs on the services tier computer in the source installation. Properties are defined in migration.properties file The required application server IBM InfoSphere Information Server properties are specified correctly: v is.suite.admin.username and is.suite.admin.password
23
IBM Confidential
v is.websphere.admin.username and is.websphere.admin.password The user that is specified with the is.suite.admin.username and is.suite.admin.password properties is a valid user with the required suite administrative privileges.
Engine tier
The following validation occurs on the engine tier computer on the source installation. Properties are defined in migration.properties file The required properties are specified correctly: v The user that is specified with the datastage.engine.admin.username and datastage.engine.admin.password properties has read and write access to the following directories: Engine directory and subdirectories The migration work directory v Verify that the directories exist as specified with the following properties: datastage.engine.enginepath datastage.engine.asbhome
IBM InfoSphere Information Analyzer

The following validation occurs on the source installation only when the InfoSphere Information Analyzer analysis database is installed on the local file system and is being migrated by the ismigration tool. Note: The following validation does not apply when you use the ia.gendb.enabled property to generate and use scripts to migrate the analysis database. Analysis database properties are defined in migration.properties file The required InfoSphere Information Analyzer analysis database properties are specified correctly, as appropriate for your database server: v IBM DB2 database server The directory that is specified with the ia.db2.db.binpath property exists, has read and write access, is on the local file system, and is connected. The directory that is specified with the ia.db2.installdir property exists and has read and write access. v Oracle database server The user that is specified with the ia.oracle.sys.username and ia.oracle.sys.password properties has sysadm, sysctrl, or sysmaint authority with read and write access to the following directories: - Engine directory and subdirectories - The migration work directory The Oracle system ID (SID) that is specified with the ia.oracle.sys.servicename property exists. The case-sensitive Oracle table space name that is specified with the ia.oracle.tablespacename property exists. v SQL Server database server
24
IBM Confidential
The directory that is specified with the ia.sqlserver.datafolder property exists, has read and write access, and is on the local file system.
Verify Version 8.5 QualityStage module availability

If your existing source installation uses IBM InfoSphere QualityStage modules, you must determine the Version 8.5 module availability as you plan your migration to Version 8.5. Before you migrate from your existing InfoSphere QualityStage installation, determine the availability of the InfoSphere QualityStage modules on Version 8.5: v IBM InfoSphere QualityStage v IBM InfoSphere QualityStage v IBM InfoSphere QualityStage U.S. Address Certification v IBM InfoSphere QualityStage Module for DPID Module for SERP Guide to IBM InfoSphere QualityStage Module for Worldwide Address Verification Interface
If your jobs depend on specific InfoSphere QualityStage modules, do not migrate until the module is available on Version 8.5. For general information about the InfoSphere QualityStage modules, see Standardizing address data with InfoSphere QualityStage.
Verify Version 8.5 enterprise pack availability

If your existing source installation uses IBM InfoSphere Information Server Packs, you must determine the Version 8.5 availability of the Packs as you plan your migration to Version 8.5. Before migrate from existing installation, determine the availability of the InfoSphere Information Server Packs on Version 8.5. If your jobs depend on specific packs, the availability of that pack influences your migration plan. For general information about the InfoSphere Information Server Packs, see InfoSphere Information Server PacksInfoSphere Information Server Packs.
Additional considerations for migrating an existing Oracle database

If you have an existing Oracle database, character encoding incompatibility can lead to import failure. If the NLS encoding of the source and target Oracle databases do not match, the migration will fail to restore the source table space on the target system. The IBM InfoSphere Information Server, Version 8.5 installation program enforces Oracle databases to have the following character encodings: v AL32UTF8 for NLS_CHARACTERSET v AL16UTF16 for NLS_NCHAR_CHARACTERSET The Version 8.0.1 installation program did not enforce this restriction, so your existing Oracle database might have a different encoding. If you attempt to import an existing Oracle database with incompatible character encodings, the import of the table space fails.
25
IBM Confidential
1. Before you import to the target system, ensure that the source database encoding matches the target database encoding. 2. If the character encodings on your source database and target database do not match, choose one of the following actions before you import to the target system: v Sync the source database NLS encoding: Upgrade the source database's character set encoding to AL32UTF8 for NLS_CHARACTERSET and AL16UTF16 for NLS_NCHAR_CHARACTERSET prior to export so that it matches target system. v Sync the target database NLS encoding: Install InfoSphere Information Server, Version 8.5, which will enforce the character encodings. After the installation, change the target database's character encoding to match source database's character encoding. To change the encoding by using one of these options, follow the Oracle documentation based on the appropriate database version.
26
IBM Confidential
Chapter 4. Commands for migration

The ismigration tool uses a command line interface to run the tool. Additional user interfaces with the ismigration tool involve using a text editor, such as WordPad, to create the required migration.properties file and other configuration files for each computer. The ismigration tool is installed with IBM InfoSphere Information Server, Version 8.5. You must install the ismigration tool on your Version 8.0.1 and Version 8.1 source installation computers to enable migration export. You run the ismigration tool at a command line on the services tier computer and engine tier computer on your source and your target installation computers. The ismigration tool uses the export, import, or restart parameters. The most important user interface for successful migration is when you create the migration.properties file for each computer in your source and target installation. You must plan your migration, gather the required information, and correctly configure your migration.properties file before you use the command line interface to run the ismigration tool. Important: Although you do not run the ismigration tool on the metadata repository tier, you can optionally generate database scripts that you run on the metadata repository tier computer. The encrypt tool is installed with the ismigration tool. Before you create your migration.properties files, use the encrypt tool to encrypt the sensitive property values that you specify in this file.
ismigration tool commands

You run the ismigration tool at a command line on the services tier computer and engine tier computer on your source and your target installation computers. The ismigration tool command syntax is as follows:
ismigration -export -archive iar_dir [-config config.file] [-userfiles UserFiles.txt] [-validateonly] [-work temp_dir] ismigration -import -archive iar_dir [-config config.file] [-gen-app-server appsvr_dir] [-host-change-config HostchangeConfig.xml] [-validateonly] [-work temp_dir] ismigration restart ismigration -version ismigration -help
You can specify the absolute path of the ismigration tool on the command line or you can run the ismigration tool at the command line from the install_dir\Migration\bin directory.
27
IBM Confidential
Export command
The ismigration tool export command exports your installation and creates an archive file on the local file system of your source installation computer. You run the export command on the services tier first, then the engine tier.
Linux, UNIX
/opt/IBM/InformationServer/Migration/bin/ismigration.sh -export -archive iar_dir [-work temp_dir] [-config config.file] [-userfiles UserFiles.txt] [-validateonly]
Windows
C:\IBM\InformationServer\migration\bin\ismigration.bat -export -archive iar_dir [-work temp_dir] [-config config.file] [-userfiles UserFiles.txt] [-validateonly]
Parameters
When you run the ismigration tool, you provide the parameters and values on the command line. Relative directory paths are supported. Run the export command on the services tier first, then the engine tier. -export Required. Exports the installation from the source computer. -archive iar_dir Required. Specifies the name of the directory where you want to store the archive file. -work work_dir Optional. Specifies the name of the directory where you want to store the exported work files. When you do not specify the -work_dir parameter, the default location of the work directory is in the temporary directory: v v
Linux Windows UNIX
/tmp/work
%TEMP%\work
Ensure that your work directory has enough available disk space. The work directory potentially contains large volumes of data. -config config.file Optional. Specifies the relative file name, or the explicit directory path and file name, of the required migration.properties file on the local file system. You must use this parameter if you changed the name or location of the migration.properties file that you created. Note: If you do not specify a file on the -config parameter, the default migration.properties file in the \conf directory is used. The default migration.properties file in the conf directory is used if the -config parameter is not specified. -userfiles filename Optional. Export only. Specifies the relative file name, or the absolute directory path and file name, of a text file that contains a list of additional files to include in the exported archive file. Enter each file name on a single line in the text file. -validateonly Optional. The current migration environment, including the existence of
28
IBM Confidential
required files, is validated without running the export command. Verifies the values that are specified in the migration.properties file, and confirms the existence of required files. Use -validateonly before you run the export.
Export command usage example (Windows)

This example exports the installation with the following results: v The hostname_TIER_timestamp.iar archive file is created in the C:\temp\archivedir directory. v The migration.properties file in the conf directory contains the required migration configuration information for the source installation. v The list of additional files in the C:\temp\filestoinclude.txt.
C:\IBM\InformationServer\migration\bin\ismigration.bat -export archive C:\temp\archivedir -userfiles C:\temp\filestoinclude.txt
Import command
The ismigration tool import command imports an archive file that is on the local file system. You run the import command on the services tier first, then the engine tier.
Linux, UNIX
/opt/IBM/InformationServer/Migration/bin/ismigration.sh -import -archive iar_dir [-work temp_dir] [-gen-app-server appsvr_dir] [-config config.file] [-host-change-config HostchangeConfig.xml] [-validateonly]
Windows
C:\IBM\InformationServer\migration\bin\ismigration.bat -import -archive iar_dir [-work temp_dir] [-gen-app-server appsvr_dir] [-config config.file] [-host-change-config HostchangeConfig.xml][-validateonly]
Parameters
When you run the ismigration tool, you provide the parameters and values on the command line. Relative directory paths are supported. Run the import command on the services tier first, then the engine tier. -import Required. Imports the installation to the target computer. -archive iar_dir Required. Specifies the name of the directory that stores the archive files that were generated from the source installation. -work work_dir Optional. Specifies the name of the directory that stores the migration work files from the source installation. When the -work_dir parameter is not specified, the default location of the work directory is in the temporary directory: v Linux, UNIX: /tmp/work v Windows: %TEMP%\work Ensure that your work directory has enough available disk space. The work directory potentially contains large volumes of data.
29
IBM Confidential
-config config.file Optional. Specifies the relative file name, or the explicit directory path and file name, of the required migration properties file on the local file system. Note: The migration properties file is required, although the -config parameter is optional. The default migration.properties file in the conf directory is used if the -config parameter is not specified. -host-change-config HostChangeConfig.xml Specifies the file name of the host change file. The host change file is required for target installations that have a different installation topology than the source installation. The host change file is also required when there is more than one engine tier. In this case, the host change file is required although the -host-change-config parameter is optional. The default HostChangeConfig.xml file in the conf directory is used when the -host-change-config parameter is not specified. -gen-app-server appsvr_dir Optional. Services tier only. Generates application server configuration scripts in the specified directory. When a directory name is specified, application server configuration scripts are created during the export process. You use these scripts to review the changes to be made to the application server during migration, and then manually run the scripts to configure your application server. -validateonly Optional. Use this parameter to validate the current migration environment, including the required files, without running the import command. Validation verifies the entries in the migration.properties file.
Import command usage example (Windows)

This sample command imports the installation to a Windows computer. v The archive file that was created during export was moved to the target computer and is in the C:\temp\archivedir directory. v The migration.properties file in the conf directory is automatically used because the -config parameter is not specified. The migration.properties file contains the required migration properties for the target installation. v The C:\temp\HostChangeFile.xml contains the required host change information for the target installation.
C:\IBM\InformationServer\migration\bin\ismigration.bat -import -archive C:\temp\archivedir -config C:\IBM\InformationServer\Migration\conf\migration.properties -host-change-config C:\temp\HostChangeFile.xml
Restart command
The ismigration tool restart command restarts the import or export process from the last saved checkpoint. The ismigration tool creates a checkpoint file at interim stages throughout the migration.
Linux, UNIX
/opt/IBM/InformationServer/Migration/bin/ismigration.sh -restart
Windows
30
IBM Confidential
C:\IBM\InformationServer\migration\bin\ismigration.bat -restart
Parameters
When you run the ismigration tool, enter the -restart parameter on the command line. -restart You can restart the migration from the last saved checkpoint. v Optional for export. Use the -restart parameter after the export fails and you resolve the errors. v Optional for import when the xmeta.gendb.directory property is not enabled. Use -restart after the import fails and you resolve errors. v Required for import when the xmeta.gendb.directory property is enabled.
Restart command usage example (Windows)

The migration resumes the import or the export from the last saved checkpoint.
C:\IBM\InformationServer\migration\bin\ismigration.bat -restart
Restart command usage example (Linux, UNIX)

You might see the following error:
Export side validation failed. DB2 user db2inst1 doesnt have authority to backup database. [ibm][db2][jcc][t4][2012][11248] Connection authorization failure occurred. Reason: Password expir
After you see this error and you fix the problem, run the restart command to resume the import or the export from the last saved checkpoint:
/opt/IBM/InformationServer/Migration/bin/ismigration.sh -restart
Encryption tool for use with ismigration tool

Use the encryption tool to generate encrypted properties values for entries that you specify in the migration.properties file. Typical values to encrypt include sensitive information, such as passwords.
Linux, UNIX
/opt/IBM/InformationServer/Migration/bin/encrypt.sh value_to_encrypt
Windows
C:\IBM\InformationServer\migration\bin\encrypt.bat value_to_encrypt
Parameters
encrypt value_to_encrypt Encrypts the value that is provided. Enter the encrypted value in the migration.properties file to substitute for the value_to_encrypt. This encrypted value is accepted by the ismigration tool on the source and target installations. The following sample encryption tool command for a Windows source installation generates the encrypted value oR5z2vAiRDU= for dsadm:
C:\IBM\InformationServer\migration\bin\encrypt.bat dsadm
oR5z2vAiRDU=
31
IBM Confidential
In the migration.properties file, use the encrypted oR5z2vAiRDU= value instead of the clear text password dsadm.
32
IBM Confidential

For single-computer and multi-computer topologies, you can perform the basic migration tasks for your topology. The streamlined migration is appropriate when you do not have to move the location of databases or tiers, to comply with database security measures for backups and creation, or to migrate InfoSphere QualityStage. Before you complete any migration tasks, you must complete the planning tasks.
Exporting from your source installations

Exporting your existing installation from your source computers involves a combination of manual premigration activities, using the ismigration tool, moving the archive files, and completing the to do lists for each computer.
Installing the ismigration tool on your source installations

Install the ismigration tool on the services tier computers and engine tier computers in your Version 8.0.1 and later source installations. Install the latest version in your Version 8.5 installation. You must download and install the latest Update Installer to install the ismigration tool on your services tier and engine tier computers in your Version 8.0.1 and later source installations. If there is a newer version of the Update Installer for Version 8.5, you must download and install it. You use the Update Installer to install updates to your installation, including installing the ismigration tool on your services tier and engine tier computers in your Version 8.0.1 and later source installations. The ismigration tool that you install and run on your Version 8.0.1 and later source installations computers does not change your InfoSphere Information Server installation during or after export. 1. Download the latest Update Installer from the download site. Choose the version of the Update Installer that is appropriate for your existing installation. v Version 8.0.1 Update Installer v Version 8.1 Update Installer v Version 8.5 Update Installer 2. Download the ismigration tool for each services tier and engine tier computer in your source installation. An .ispkg file is provided for each operating system: Migration_tool_os_85.ispkg. 3. Follow the installation instructions to download and install the ismigration tool.
Option Version 8.0.1 Version 8.1 Version 8.5 Description www.ibm.com/support/ docview.wss?uid=swg27011896 www.ibm.com/support/ docview.wss?uid=swg27012519 www.ibm.com/support/ docview.wss?uid=swg27016531
33
IBM Confidential
The ismigration tool is installed in the install_dir/Migration directory on the services tier and engine tier computers in your source and target installation. The default migration directories are as follows:
Table 9. Default ismigration tool directories Operating system Default InfoSphere Information Server migration directories Linux, UNIX Windows /opt/IBM/InformationServer/Migration C:\IBM\InformationServer\Migration
Ensure that you have completed all the tasks in planning for your migration, including creating the migration.properties file. See Chapter 3, Planning for migration, on page 19. Then, validate your migration environment. See Validating the migration environment.
Validating the migration environment

Run the ismigration tool with the -validateonly parameter to validate the migration environment on each services and engine tier computer before you run the ismigration tool. The migration environment is automatically validated when the ismigration tool is run. You can optionally validate the migration environment without running the migration export or import command. Validation verifies the values in the migration.properties file are appropriate for the local installation environment and the ismigration command that you specify. To ensure a successful migration, you should run the ismigration tool with the -validateonly parameter before you run the export or import command. Complete this validation step on each services and engine tier computer in your source and target installations. 1. Verify that you can log in with the user names and passwords that are specified in the migration.properties file on each computer. 2. Run the ismigration tool with the -validateonly parameter on each computer. For example, to validate the source installation for a migration export on a Windows computer:
ismigration.bat -export -archive C:\exportdir -validateonly
3. If the ismigration validation fails, review the migration log file for SEVERE error messages. Make the changes to your migration environment as needed. 4. Restart your validation. The restarted migration automatically includes the -validateonly parameter.
-ismigration.bat -restart
5. Resolve the problems as reported to the console window and restart the migration until the validation is successful.
Using the ismigration tool to export your source installation

Run the ismigration tool on each services and engine tier computer to export your source installation and generate the archive files. Export the services tier first, and then the engine tier. Before you export your source installation, run the ismigration tool with the -validateonly parameter to validate your migration environment for the export command.
34
IBM Confidential
Use the ismigration tool to export your source installation. The export process generates the archive files and the migration.todo.txt file for each services tier and engine tier computer. Run the export command only on the services tier and engine tier computers. The ismigration tool does not run on the metadata repository tier computers or on client-tier only computers. For details on migrating remote metadata repository databases, see . For details on upgrading client-tier only computers, see Chapter 12, Upgrading a client tier-only installation to Version 8.5, on page 101. 1. Log in to the services tier computer as a user with administrative privileges. 2. Run the ismigration tool at a command line with the parameters that are appropriate for your installation. For example, type the following command to export a services tier computer that is running on Microsoft Windows:
C:\IBM\InformationServer\Migration\bin\ismigration.bat -export archive C:\temp\archivedir
The following files are generated when the export is completed: C:\temp\archivedir\hostname_SERVICES_timestamp.iar C:\IBM\InformationServer\Migration\migration.todo.txt 3. Log in to the engine tier computer as a user with administrative privileges. 4. Run the ismigration tool at a command line with the parameters that are appropriate for your installation. For example, type the following command to export an engine tier computer that is running on Linux or UNIX:
ismigration.sh -export archive /opt/archivedir
The following files are generated when the export is completed: /opt/archivedir\hostname_ENGINE_timestamp.iar /opt/IBM/InformationServer/Migration/migration.todo.txt The archive files and the migration.todo.txt files are generated. Your source installation remains intact. Review the migration.todo.txt file for each computer and complete the specified to-do activities. See Completing the to-do activities.
Completing the to-do activities

You must review and complete the required to-do activities for each computer as specified in the migration.todo.txt file that is created when the migration is completed. The migration.todo.txt file is generated for each tier computer that is exported or imported by using the ismigration tool. The migration.todo.txt specifies the activities that you must complete before you continue the migration. For example, after you run the ismigration tool to export the source installation, the migration.todo.txt file identifies the required files that you must manually move to the target installation. Because the ismigration tool does not migrate the InfoSphere QualityStage modules, their associated reference databases, or the Match Designer database, you
35
IBM Confidential
might need to complete specific premigration and postmigration activities for QualityStage, depending on your source installation. See Additional migration activities for QualityStage. 1. Review the migration.todo.txt file that is generated for each computer after the migration is completed. 2. Complete all the required activities as specified in the migration.todo.txt file. 3. Run the IBM Support Assistant Lite for InfoSphere Information Server tool for Version 8.5 to verify the stability of your Version 8.5 installation environment. Your target installation is successfully migrated to Version 8.5. After the migration export is completed, move your files to the target installation. See Moving the archive files. After the migration import is completed, configure your Version 8.5 installation. See http://publib.boulder.ibm.com/infocenter/iisinfsv/v8r5/topic/ com.ibm.swg.im.iis.productization.iisinfsv.install.doc/topics/ cont_iisinfsrv_config.html. Optionally, you can change the products that are installed on your target installation. v Install additional product modules that did not exist in your source installation. v Remove any product modules that did exist in your source installation that you do not want in your target installation. Optionally, you can purge the IBM InfoSphere DataStage log files that were migrated from the source installation. See "Purging job log files" in the IBM InfoSphere DataStage and QualityStage Administrator Client Guide.
Moving the archive files

After you export your source installation computers, move the archive files and other required files from the services and engine tier computers in your source installation to the target installation computers. Run the ismigration tool to export your source installation and generate the hostname_SERVICES_timestamp.iar and hostname_ENGINE_timestamp.iar archive files and the migration.todo.txt files for each tier computer. See Using the ismigration tool to export your source installation on page 34. This procedure assumes that the services tier and the metadata repository tier are installed on the same computer. If your metadata repository tier is remote from the services tier computer, then additional steps are required. See Migrate databases manually by using scripts on page 43. Depending on your source installation, you might need to move other files from your source installation to your target installation. For example, files that are specified in the migration.todo.txt file or the QualityStage Match Designer database (see Additional migration activities for IBM InfoSphere QualityStage on page 48). Adjust these steps as appropriate for your installation. 1. On the services tier computer, locate your archive file. The archive file is created in the directory that you specified with the -archive parameter. For example, /home/dsadm/archive/systema_SERVICES_20100110_123500.iar.
36
IBM Confidential
2. On each engine tier computer, locate your archive file. The archive file is created in the directory that you specified with the -archive parameter. For example, /home/dsadm/archive/systema_ENGINE_20100610_151400.iar. 3. Copy or move the archive files to the appropriate target installation computers. For example, use the scp command to copy the services tier archive file from the source computer to a network location:
cd /home/dsadm/archive scp systema_SERVICES_20100110_123500.iar dsadm@systemb:/home/dsadm/archive
The archive files are available in a local file system on each target installation computer. Run the ismigration tool to import your installation. See .
Importing to your target installations

Prepare your target installation, and then run the ismigration tool on the services tier computers and the engine tier computers to import your existing installation to your target installation. Then complete the postmigration activities as required for your installation.
Preparing the target installation environment

Prepare your target installation environment before you import. Gather installation information about your source installation. See: Installing the ismigration tool on your source installations on page 33. 1. Ensure that you have correctly set up the migration.properties file and, if necessary, the host change file. 2. If you are setting up a cluster environment, make sure that IBM WebSphere Application Server Network Deployment is running on the services tier computer and that the NodeAgents processes are running on all cluster member computers in your target installation. 3. Install IBM InfoSphere Information Server, Version 8.5 with the same products that are installed on your source installation. Install the InfoSphere Information Server Packs, if applicable. 4. If you are using Java Message Service (JMS) queues on the services tier on your source installation, then the JMS configuration on your target installation must be the same as your source installation. 5. Complete all required activities that were specified in the migration.todo.txt files that were generated during the export of the source installations. Validating the migration environment task. See: Validating the migration environment on page 34.
Validating the migration environment

Run the ismigration tool with the -validateonly parameter to validate the migration environment on each services and engine tier computer before you run the ismigration tool. The migration environment is automatically validated when the ismigration tool is run. You can optionally validate the migration environment without running the migration export or import command. Validation verifies the values in the migration.properties file are appropriate for the local installation environment
37
IBM Confidential
and the ismigration command that you specify. To ensure a successful migration, you should run the ismigration tool with the -validateonly parameter before you run the export or import command. Complete this validation step on each services and engine tier computer in your source and target installations. 1. Verify that you can log in with the user names and passwords that are specified in the migration.properties file on each computer. 2. Run the ismigration tool with the -validateonly parameter on each computer. For example, to validate the source installation for a migration export on a Windows computer:
ismigration.bat -export -archive C:\exportdir -validateonly
3. If the ismigration validation fails, review the migration log file for SEVERE error messages. Make the changes to your migration environment as needed. 4. Restart your validation. The restarted migration automatically includes the -validateonly parameter.
-ismigration.bat -restart
5. Resolve the problems as reported to the console window and restart the migration until the validation is successful.
Requirements for using the ismigration tool to import to the target installation
Ensure that your target installation meets the following validation requirements before you use the ismigration tool.
Validation environment
The validation requirements for the target installation are based on the installation tier and the products that are installed. This information assumes that you are using the default location and file names of the migration.properties and HostChangeConfig.xml files. The information also applies to the files that you specify with the -config and -host-change-config parameters.
All tiers
The following validation occurs on all tiers in the source installation. Properties are defined in migration.properties file The default migration.properties file, or the file that is specified with the -config parameter, is present. The properties that are required for the installation tier are defined in the file. Properties are defined in migration.properties file The migration.properties file is present. The HostChangeConfig.xml file is present. The properties that are required for the installation tier are defined in the file. Source installation software version The version of your source installation of IBM InfoSphere Information Server is compatible with the version of the ismigration tool.
38
IBM Confidential
Services tier
The following validation occurs for the services tier in the target installation. Suite-wide properties are defined in migration.properties file The required IBM InfoSphere Information Server property is specified correctly: v (Export only) is.suite.admin.username and is.suite.admin.password from the source installation Software version The version of your target installation of IBM InfoSphere Information Server is compatible with the version of the ismigration tool. Products and product modules The target installation has the same products and product modules installed as the source installation. Number of engines The number of engines is the same as the source installation. Operating system The target installation has the same operating system as the source installation. New installation The Version 8.5 installation is a new installation.
Engine tier
The following validation occurs for the engine tier on the target installation. Host change configuration The engine tiers from the source and target installations are correctly mapped in the HostChangeConfig.xml file. NLS configuration The NLS configuration on your target installation of IBM InfoSphere Information Server is the same as the source installation. Properties are defined in migration.properties file The required properties are specified correctly: v The user that is specified with the datastage.engine.admin.username and datastage.engine.admin.password properties has read and write access to the following directories: Engine directory and subdirectories The migration work directory v Verify that the directories exist if specified with the following properties: datastage.engine.enginepath datastage.engine.asbhome
IBM InfoSphere Information Analyzer

The following validation occurs on the target installation only when the InfoSphere Information Analyzer analysis database is automatically migrated by the ismigration tool. Automatic migration of the analysis database requires that the analysis database must be on the local file system.
39
IBM Confidential
Note: The following validation does not apply when manual migration of the analysis database is specified with the ia.gendb.enabled property. Analysis database properties are defined in migration.properties file The required InfoSphere Information Analyzer analysis database properties are specified correctly: v IBM DB2 database server The directory that is specified with the ia.db2.db.binpath property exists, has read and write access, is on the local file system, and is connected. The directory that is specified with the ia.db2.installdir property exists and has read and write access. ia.db2.installdir v Oracle database server The user that is specified with the ia.oracle.sys.username and ia.oracle.sys.password properties has sysadm, sysctrl, or sysmaint authority with read and write access to the following directories: - Engine directory and subdirectories - The migration work directory The Oracle system ID (SID) that is specified with the ia.oracle.sys.servicename property exists. The Oracle tablespace name that is specified with the ia.oracle.tablespacename property exists. v SQL Server database server The directory that is specified with the ia.sqlserver.datafolder property exists, has read and write access, and is on the local file system.
Using the ismigration tool to import to your target installation

Run the ismigration tool to import to your target installation. Import the services tier first, and then the engine tier. Before you import to your target installation, run the ismigration tool with the -validateonly parameter to validate your migration environment. See: Validating the migration environment on page 34. Use the ismigration tool to import to your target installation. You run the ismigration tool only on the services tier computers and on the engine tier computers. The ismigration tool does not run on the metadata repository tier computers or on client-tier only computers. Client tier-only installations are not migrated. Use the suite installation program to upgrade the client tier software. See Chapter 12, Upgrading a client tier-only installation to Version 8.5, on page 101. The metadata repository database is automatically migrated when it is on the same computer with the services tier. For advanced migrations that use manual database migration, see Migrate databases manually by using scripts on page 43. 1. Log in to the services tier computer with administrative privileges. 2. Run the ismigration tool at a command line with the parameters that are appropriate for your installation. For example, type the following command to import the services tier to a Windows computers:
40
IBM Confidential ismigration.bat -import archive C:\temp\archivedir
where C:\temp\archive is the directory where you moved the hostname_SERVICES_timestamp.iar archive file. 3. Log in to the engine tier computer with administrative privileges. 4. Run the ismigration tool at a command line with the parameters that are appropriate for your installation. For example, type the following command to import the engine tier to a Linux computer:
ismigration.sh -import archive /opt/archivedir
where /opt/archivedir is the directory where you moved the hostname_ENGINE_timestamp.iar archive file. 5. Start the Version 8.5 installation. If the import is successful, a migration.todo.txt file is created for each computer. Complete the postmigration activities as defined in the migration.todo.txt files for each computer. If applicable, follow the readme.txt to import the metadata repository database or IBM InfoSphere Information Analyzer analysis databases. See: Manually migrating the metadata repository database on page 44 and Migrating the InfoSphere Information Analyzer analysis database on page 45.
Completing the to-do activities

You must review and complete the required to-do activities for each computer as specified in the migration.todo.txt file that is created when the migration is completed. The migration.todo.txt file is generated for each tier computer that is exported or imported by using the ismigration tool. The migration.todo.txt specifies the activities that you must complete before you continue the migration. For example, after you run the ismigration tool to export the source installation, the migration.todo.txt file identifies the required files that you must manually move to the target installation. Because the ismigration tool does not migrate the InfoSphere QualityStage modules, their associated reference databases, or the Match Designer database, you might need to complete specific premigration and postmigration activities for QualityStage, depending on your source installation. See Additional migration activities for QualityStage. 1. Review the migration.todo.txt file that is generated for each computer after the migration is completed. 2. Complete all the required activities as specified in the migration.todo.txt file. 3. Run the IBM Support Assistant Lite for InfoSphere Information Server tool for Version 8.5 to verify the stability of your Version 8.5 installation environment. Your target installation is successfully migrated to Version 8.5. After the migration export is completed, move your files to the target installation. See Moving the archive files on page 36.
41
IBM Confidential
After the migration import is completed, configure your Version 8.5 installation. See http://publib.boulder.ibm.com/infocenter/iisinfsv/v8r5/topic/ com.ibm.swg.im.iis.productization.iisinfsv.install.doc/topics/ cont_iisinfsrv_config.html. Optionally, you can change the products that are installed on your target installation. v Install additional product modules that did not exist in your source installation. v Remove any product modules that did exist in your source installation that you do not want in your target installation. Optionally, you can purge the IBM InfoSphere DataStage log files that were migrated from the source installation. See "Purging job log files" in the IBM InfoSphere DataStage and QualityStage Administrator Client Guide.
42
IBM Confidential
Chapter 6. Additional migration tasks for advanced or custom topologies

If you have a more complex topology that you want to migrate, such as a different database location or specific backup security requirements, you must complete additional tasks. v Before you complete any migration tasks, you must complete the planning tasks. v Before you complete any migration tasks for advanced or custom topologies, you must review and complete the basic migration tasks.
Export tasks for advanced and custom topologies

Before you export your source installation, you might need to complete additional tasks depending on your requirements.
Migrate databases manually by using scripts

If your metadata repository tier is not on same computer as the services tier, you must generate the scripts on the services tier computer and move them to the metadata repository tier computer to migrate the databases. If your metadata repository tier is on the same computer as the services tier, you do not need to migrate your databases manually unless it is required by company security policies. Important: Migrate your database manually only if it is required for your migration. Confirm with an expert database administrator if you are unsure. Attention: If your migration does not require this option, ensure that you do not enable the xmeta.gendb.directory property or the ia.gendb.enabled property in the migration.properties file. If you specify a directory for this property when your migration does not match one of the scenarios below, you might experience loss of data and other serious issues. You must use this procedure in the following situations: v The services tier and metadata repository tier are on different computers. Note: This is the only scenario that requires a manual backup and restore of the metadata repository database. If InfoSphere Information Analyzer is installed, you must also generate and use scripts to migrate the InfoSphere Information Analyzer analysis database. This procedure is also required if your company establishes any of the following requirements or security policies: v You must audit every script that runs against a corporate database or on a restricted database server environment. v You cannot provide database administrator credentials to run a data dump from a remote client computer. If any of the above situations apply to your migration, ensure that you complete all of the applicable activities that are specified in the migration.todo.txt file. This file is generated for each computer after the ismigration tool export and import process is completed. You must log in as a user with database administrator privileges to run the scripts.
43
IBM Confidential
To use this option, you must specify a valid absolute directory name in the xmeta.gendb.directory or the ia.gendb.enabled property before you export your source installation and before you import to your target installation. During import to the target installation, the import process on the services tier computer halts until you run the scripts on the metadata repository tier computer and load the database. The migration process halts until you run the scripts and restart the migration. If none of the above situations apply to your migration, do not generate and use scripts to migrate your databases on the metadata repository tier. Ensure that the xmeta.gendb.directory or the ia.gendb.enabled properties are disabled in the migration.properties file.
Manually migrating the metadata repository database

These steps apply only to migrations that have chosen to back up and restore the metadata repository tier manually. When you migrate the metadata repository database manually, you must generate and move additional database dump files and follow these additional steps. This procedure assumes that you have chosen, during the planning stage of your migration, to back up and restore the metadata repository tier manually. See Migrate databases manually by using scripts on page 43. A detailed README file and a script to export the data are generated in the directory that is specified with the xmeta.gendb.directory property to allow a database administrator to manually run the script to import the metadata repository database. The exported metadata repository database must be moved to the metadata repository tier on the target installation. Use the readme.txt file for the details and required procedures for each of these steps. 1. On the source installation, run the export command on the services tier computer to generate the script. 2. Move the script to the metadata repository tier computer on the source installation. 3. On the target installation, do the following steps to import the metadata repository tier databases to your target installation: a. Dump the data. On the metadata repository tier computer, before restoring the source database, some model data must be preserved by dumping on the file system. This data is loaded again, after you restore the source database. This saves the Version 8.5 new installation data that would otherwise be overwritten when the source installation metadata repository database is restored. b. Run the import command on the services tier computer to generate the scripts and readme.txt files. The metadata repository tier import pauses here so that the database administrator complete the import manually. c. Move the scripts to the metadata repository tier computer. Edit the script file for your migration. d. Run the scripts on the target installation metadata repository tier computer to import . 4. After the source database is restored on the target installation, follow the steps in the readme.txt to load the data.
44
IBM Confidential
Migrating the InfoSphere Information Analyzer analysis database

You can optionally migrate the IBM InfoSphere Information Analyzer analysis database when you migrate to IBM InfoSphere Information Server, Version 8.5. You choose whether to migrate the analysis database automatically or manually. During your planning phase for migration, determine whether you need to migrate the InfoSphere Information Analyzer analysis database. If you want to migrate the InfoSphere Information Analyzer analysis database, set the ia.migrate.analysisdb.enabled property to true. If you choose to migrate the analysis database, determine whether you need to migrate the analysis database manually. See Migrate databases manually by using scripts on page 43. If you must migrate the analysis database manually, set ia.gendb.enabled to true and specify a valid path for the ia.gendb.directory property. To manually migrate the analysis database to the Version 8.5 target system, review the following steps. These steps point out the analysis database migration actions that are needed during your overall migration. Use the readme.txt file for the details and required procedures for each of these steps. The following steps apply only to migrations that are required to or have chosen to back up and restore the metadata repository tier manually. When you migrate the IBM InfoSphere Information Analyzer analysis databases manually, you must generate and move additional database dump files and follow these additional steps. 1. On the source installation, run the export command on the services tier computer to generate the script. 2. Move the script to the metadata repository tier computer on the source installation. Then run the script to back up the analysis databases. 3. On the target installation, run the import command on the services tier computer to generate the restore script and readme.txt files. 4. Move the script to the metadata repository tier computer on the target installation. Edit the script file for your migration. 5. Run the script on the target installation metadata repository tier computer to restore the databases. 6. After the source databases are restored on the target installation, follow the steps in the readme.txt to load the data.
Completing premigration activities for IBM InfoSphere QualityStage installations

Complete these premigration activities if your source installation includes InfoSphere QualityStage modules or the Match Designer database. The ismigration tool does not migrate InfoSphere QualityStage modules, their associated reference databases, or the Match Designer database. As appropriate for your installation, complete these premigration activities before you export your Version 8.1 source installations. 1. If your source installation includes the Match Designer database, make a complete backup of that database. This step is required only if your DB2
45
IBM Confidential
database server was installed by the IBM InfoSphere Information Server installation program.If your database server was preinstalled, ensure that you configure the target installation as required to use the Match Designer database. 2. If your source installation includes InfoSphere QualityStage modules, verify that the modules are available in Version 8.5. See IBM InfoSphere QualityStage module availability.
Import tasks for advanced and custom topologies

Before you import your source installation into your new 8.5 installation, you might need to complete additional tasks depending on your requirements.
Migrating to a different topology

You must edit the host change file before you run the ismigration tool to import the archive file to your target installation before you import. If your target installation has topology changes, project location changes, or port number changes, you must edit the host change file and specify it when you run the ismigration tool to import your source installation. Identifying your source installation host names After a successful migration export from the source installation, the HostChangeConfigTemplate.xml file is generated in the Migration directory. The file contains accurate host name entries for the engine tier and the services tier computers. You can add entries for the target installation computers, and use this file during the import migration on the target installation. Identifying your target installation host names On the target installation, run the migration import with the -validateonly parameter. The install_dir\Migration\HostChangeConfigTemplate.xml file that is created contains the host change entries that are required for import. Optionally, you can also run the IBM Support Assistant Lite for InfoSphere Information Server tool to gather the required installation information from your source and target installations. For details on downloading, installing, and using the tool, see the IBM Support Assistant Lite for InfoSphere Information Server Quick Start Guide at www.ibm.com/support/docview.wss?uid=swg24022700. The host change file is required when you run the ismigration tool to import to a new Version 8.5 installation that has installation topology changes, project location changes, host name changes, or port number changes. The host change file is not required for migrations with the same installation topology and no port number changes. By default, the ismigration tool uses the HostChangeConfig.xml file in the conf directory. If your host change file is in a different directory or has a different file name, you can specify the host change directory and file name with the -host-change-config parameter when you run the ismigration tool. 1. On each services and engine tier computer in your source installation, locate the HostChangeConfigTemplate.xml file that is in the Migration directory of the after the migration export is completed. 2. Copy or move the file to the install_dir/Migration/conf directory on each services and engine tier computer in your target installation: 3. Rename the file to HostChangeConfig.xml.
46
IBM Confidential
4. Use a text editor to view and change the entries in the HostChangeConfig.xml file on each services and engine tier computer in your target installation. For example, the following entries for an engine tier computer that is running on Linux or UNIX specify changes to the host name, the project location, and the port number:
<HostConfig> <Host name="SourceHost" tier="ENGINE" newName="TargetHost"> <PortChange portNumber="31531" newPortNumber="31561"/> <ProjectLocation name="ProjectA" directory="/opt/IBM/DataStage/projects/ProjectB"/> </Host> </HostConfig>
The host change file is on each target installation computer. 5. Specify this file on the import command when you import the archive file.
Manually configuring the application server

You can manually configure the application server configuration settings. You specify a parameter during the import to your target installation. You can enable manual configuration of the application server configuration settings by specifying the -gen-app-server paramter. You specify the -gen-app-server parameter during the import to your target installation, after you validate your migration environment for the import command. 1. Log in to the services tier computer with administrative privileges. 2. Include the -gen-app-server parameter when you run the ismigration tool at a command line with all the parameters that are appropriate for your installation. For example, type the following command to import the services tier to a Windows computers:
C:\IBM\InformationServer\Migration\bin ismigration.bat -import archive C:\temp\archivedir -gen-app-server C:\IBM\InformationServer\Migration\appserver
where C:\temp\archive is the directory where you moved the hostname_SERVICES_timestamp.iar archive file and where C:\IBM\InformationServer\Migration\appserver is the directory where you want to create the application server configuration scripts are 3. The import halts with the following message:
An application server script has been written to directory. The script will need to be run by an application server administrator before migration can continue. After successfully running the script, migration can be restarted using the ismigration -restart command.
4. Conduct your internal audit of the scripts as appropriate for your installation. 5. Review and follow the instructions in the readme.txt file that is generated in the directory where the application server configuration scripts are created. 6. Restart the migration to complete the import. Type the following command to restart the import:
ismigration.sh -restart
The import is completed. A migration.todo.txt file is created for each computer. Review the migration.todo.txt file for each computer and complete the specified to-do activities. See
47
IBM Confidential
Additional migration activities for IBM InfoSphere QualityStage

If your target installation includes InfoSphere QualityStage modules, you can optionally perform these postmigration activities to complete the InfoSphere QualityStage migration. InfoSphere QualityStage modules If you want to migrate the InfoSphere QualityStage postal reference files that are associated with your InfoSphere QualityStage modules, complete these manual steps on the target installation. These required activities are not included in the migration to-do lists because the ismigration tool does not migrate InfoSphere QualityStage modules or the reference files for the InfoSphere QualityStage postal modules. Complete the following activities. 1. Install the InfoSphere QualityStage, Version 8.5 module on your target installation. 2. Reinstall the associated module reference files on your target installation. 3. Edit the InfoSphere QualityStage module jobs to point to the reference files location. 4. Edit the InfoSphere QualityStage module jobs as needed for any updates to the modules. Match Designer database If your installation includes the InfoSphere QualityStage Match Designer database, complete the following postmigration activities: 1. Move or re-create the Match Designer database on your target installation, using one of the following options: v Move the Match Designer database from your source installation to your target installation. v Re-create the database in the Match Designer on the target installation, then update the test environment for each match specification. If your installation includes an IBM DB2 database that was not installed by the IBM InfoSphere Information Server suite installer and your target installation uses a DB2 database that was installed with the suite installer, restore the Match Designer database that you preserved from your source installation. 2. Download the latest version of the postal database. 3. Re-create the ODBC data source name (DSN) and DSN connections. See "Configuring IBM InfoSphere QualityStage Match Designer" in the IBM InfoSphere Information Server Planning, Installation, and Configuration Guide.
Opening each project to complete the migration

If you did not enable the datastage.engine.update.project property in the migration.properties file, you must open each IBM InfoSphere DataStage and QualityStage project and click Migrate to complete the migration to Version 8.5. Complete the migration import and the postmigration activities as required for your installation.
48
IBM Confidential
The InfoSphere DataStage and QualityStage clients in the new installation cannot connect to the projects until each project is opened and migrated. 1. In the InfoSphere DataStage and QualityStage Administrator client, open each project on the target Version 8.5 installation. 2. Click Migrate to complete the migration.
49
IBM Confidential
50
IBM Confidential
Chapter 7. Reference: Migration directories and files

This reference information can help you to plan, prepare, and manage your migrations to new IBM InfoSphere Information Server, Version 8.5 installations.
Default migration directories

The ismigration tool is automatically installed with Version 8.5, so the migration default directories are in your Version 8.5 installation. The migration default directories exist on Version 8.0.1 and Version 8.1 installations after you install the ismigration tool. The default migration directory is: v v
Linux Windows UNIX
/opt/IBM/InformationServer/Migration
C:\IBM\InformationServer\Migration
conf directory
You configure your migration with the migration configuration files. These configuration files are in the conf directory: v v
Linux Windows UNIX
/opt/IBM/InformationServer/Migration/conf
C:\IBM\InformationServer\Migration\conf
The following configuration files are in the conf directory: v HostChangeConfig.xml.sample v logging.properties v migration.properties.sample
bin directory
You run the ismigration tool at a command line by using the ismigration tool scripts that are in the default bin directories:
Linux UNIX
v /opt/IBM/InformationServer/Migration/bin/ismigration.sh v /opt/IBM/InformationServer/Migration/bin/encrypt.sh
Windows
v C:\IBM\InformationServer\Migration\bin\ismigration.bat v C:\IBM\InformationServer\Migration\bin\encrypt.bat
logs directory
The ismigration log files reside in the default logs directory: v v
Linux Windows UNIX
/opt/IBM/InformationServer/Migration/logs
C:\IBM\InformationServer\Migration\logs
51
IBM Confidential
migration.properties file
The migration.properties file contains installation information that is required for all migrations. Correct configuration of this file for each computer is a critical planning task.
Purpose
The entries in the migration.properties file define the installation environment for migration. Use a text editor, such as WordPad, to view and change the entries in the migration.properties file. You will need to be familiar with your source and target installations to gather the information that you need to create the entries in the migration.properties files. You will need a migration.properties file for each services and engine tier computer in your source installation, and for each services and engine tier computer in your target installation. A sample files is provided in the conf directory: v v
Linux UNIX /opt/IBM/InformationServer/Migration/conf/ migration.properties.sample
C:\IBM\InformationServer\Migration\conf\ migration.properties.sample
Windows
When the ismigration tool is run, it uses the following default directory and file name of the migration.properties file: v v
Linux UNIX /opt/IBM/InformationServer/Migration/conf/ migration.properties Windows
C:\IBM\InformationServer\Migration\conf\migration.properties
If you do not use the default directory and file name, use the -config parameter on the ismigration tool commands to specify a different directory path or file name of your migration properties file.
Properties
Enter properties according to these guidelines: v The format of each property is property.name=entry, where: property.name is the property The equal sign (=) is the separator entry is the clear text or encrypted value that applies to the local installation v Use the encryption tool to encrypt sensitive data, especially passwords. v Properties that do not apply to the local installation are ignored. v
Windows Use the backslash (\) escape character to specify directory path names. For example, type C:\\IBM\\SQLLIB\\bin for the C:\IBM\SQLLIB\bin directory.
The following descriptive tags provide context and details for the properties. v Tiers: specifies the tier that the property applies to v Commands: specifies the migration command that the property applies to: Import, Export, or both Import, Export v Components: specifies the product modules and components that the property applies to v Required or Optional
52
IBM Confidential
IBM InfoSphere Information Server properties for services tier computers and engine tier computers
Set the following properties to define the InfoSphere Information Server installation environment for your services tier computer and engine tier computers. is.suite.admin.username This property defines the InfoSphere Information Server administrator user name of your source installation. The sample file includes the following default entry and value: is.suite.admin.username=isadmin v Tiers: Services v Commands: Export v Components: All v Required for export is.suite.admin.password This property defines the InfoSphere Information Server administrator user password of your source installation. Passwords are typically encrypted. The sample file includes the following default entry and value: is.suite.admin.password=snE4oBBsg+c/qkvcYc2o1Q== v v v v Tiers: Services Commands: Export Components: All Required for export
is.websphere.admin.username Do not enable this property if you are using the default internal user registry. This property is needed only when the IBM WebSphere Application Server administrator user name on the target installation is different than the source installation. For example, if the operating system user name or the LDAP user name changes after the export from the source installation and before the import to the target installation. The sample file includes the following default entry and value: is.websphere.admin.username=wasadmin v Tiers: Services v Commands: Import v Components: All v Optional Note: After a successful import, the WebSphere Application Server user name on the target installation is set to the user name that is specified for IBM WebSphere Application Server administrator user name on the source installation. is.websphere.admin.password Do not enable this property if you are using the default internal user registry. This property is needed only when the IBM WebSphere Application Server administrator password on the target installation is different than the source installation. For example, if the operating system password or the LDAP password changes after the export from the source installation and before the import to the target installation.
53
IBM Confidential
The sample file includes the following default entry and value: is.websphere.admin.password=snE4oBBsg+c/qkvcYc2o1Q== v Tiers: Services v Commands: Import v Components: All v Optional
Engine tier properties

Set the following properties to define your InfoSphere Information Server engine tier environment. datastage.engine.admin.username This property defines the user name of the InfoSphere Information Server engine authenticated user. The InfoSphere Information Server engine authenticates users separately from other InfoSphere Information Server components. The user that you specify for this property must meet the following requirements: v Is the operating system user or the LDAP user that your local installation uses to connect to the InfoSphere Information Server engine v Has credentials that correspond to the engine tier operating system user credentials v Has read and write access to the engine directory and subdirectories v Has read and write access to the migration work directory The sample file includes the following default entry and value: datastage.engine.admin.username=dsadm v Tiers: Engine v Commands: Import, Export v Components: DataStage, QualityStage, Information Analyzer v Required datastage.engine.admin.password This property defines the password of the InfoSphere Information Server engine authenticated user. Passwords are typically encrypted. The sample file includes the following default entry and value: datastage.engine.admin.password=y010UWxT1hqqCqirnRj2zg== v Tiers: Engine v Commands: Import, Export v Components: DataStage, QualityStage, Information Analyzer v Required datastage.engine.enginepath This property defines the absolute path to the InfoSphere Information Server engine directory. If you do not specify a directory name for this property, the directory that is specified in the Version.xml file is used.
Windows The sample file includes the following default entry and value: datastage.engine.enginepath=C:\\IBM\\InformationServer\\Server\\ DSEngine. Linux UNIX Specify a value for other operating systems as appropriate: datastage.engine.enginepath=/opt/IBM/InformationServer/ Server/DSEngine
54
IBM Confidential
v v v v
Tiers: Engine Commands: Import, Export Components: DataStage, QualityStage, Information Analyzer Optional
datastage.engine.asbhome This property defines the absolute path to the ASBNode directory. If you do not specify a directory name for this property, the directory that is specified in the Version.xml file is used and a single ASBnode directory is assumed to exist in the default /install_dir/ASBNode directory. The sample file includes the following default entry and value: datastage.engine.asbhome=C:\\IBM\\InformationServer\\ASBNode.
Windows
Specify a value for other operating systems as appropriate: datastage.engine.asbhome=/opt/IBM/InformationServer/ Server/ASBNode

Linux UNIX
v Tiers: Engine v Commands: Import, Export v Components: DataStage, QualityStage, Information Analyzer v Optional datastage.engine.update.project When this property is not specified, or is set to true, the default behavior is to automatically update the projects. Your projects are automatically updated if your target installation meets the following requirements: v The services tier and engine tier are on the same computer, or v The services tier is connect to the engine tier that is on a different computer, and the InfoSphere Information Server services are running You must set this property to false if your target installation does not meet the requirements, or if you want to prevent automatic update of the migrated projects on the target installation. If you set this property to false, you must complete the to-do activities in the migration.todo.txt file to update the migrated projects. The sample file includes the following default entry and value: datastage.engine.update.project=true v Tiers: Engine v Commands: Import v Components: DataStage, QualityStage, Information Analyzer v Optional
Metadata repository database properties

Set the following properties in the migration.properties file on the services tier to define the metadata repository environment. xmeta.gendb.directory Use this property to manually backup and restore your metadata repository database. You must specify the absolute path to the directory where you want to generate the database migration scripts on the services tier computer. Enable this property only when your installation meets at least one of the following requirements:
55
IBM Confidential
v Your services tier and your metadata repository tier are installed on different computers in the source installation. v Your services tier and your metadata repository tier are installed on different computers in the target installation. v Your site requires a database administrator to do the metadata repository database migration, for example, database migration requires an audit or a different user.
Windows The sample file includes the following default entry and value: xmeta.gendb.directory=C:\\Migration\\db-scripts.
Specify a value for other operating systems as appropriate: xmeta.gendb.directory=/opt/users/db2inst1/sqllib/db-scripts v Tiers: Services v Commands: Import, Export v Components: All v Required when the metadata repository database is remote from the services tier v Optional when the metadata repository database is on the same computer as the services tier
Linux UNIX
When you do not specify a directory for this property, the metadata repository tier is assumed to be on the same computer as the services tier and the exported archive file automatically includes the metadata repository database. For more details on using this property, see Migrate databases manually by using scripts on page 43. xmeta.db.binpath This property specifies the absolute path to the metadata repository bin directory. For example, the metadata repository bin directory entries for Windows database servers might be as follows: v IBM DB2: xmeta.db.binpath=C:\\IBM\\SQLLIB\\bin v Oracle: xmeta.db.binpath=C:\\OracleHome\\app\\oracle\\product\\ 11.2.0\\dbhome_\\bin v SQL Server: xmeta.db.binpath=C:\\Program Files\Microsoft SQL Server\90\Tools\Binn The sample file includes the following default entry and value: xmeta.db.binpath=C:\\IBM\\SQLLIB\\bin.
Windows
Specify a value for your database server and other operating systems as appropriate. For example, for DB2 database system, Version 9.5 on Linux and UNIX: xmeta.db.binpath=/opt/BM/db2/V9.5/bin v Tiers: Services
Linux UNIX
v Commands: Import, Export v Components: All v Required
IBM DB2 database: Metadata repository properties

The following property defines the metadata repository environment when the metadata repository is hosted on an IBM DB2 database server.
56
IBM Confidential
xmeta.db2.installdir This property specifies the absolute path to the directory where the metadata repository database is stored on the metadata repository tier computer. The sample file includes the following default entry and value: xmeta.db2.installdir=c:\\.
Windows Linux UNIX Specify a value for other operating systems as appropriate: xmeta.gendb.directory=/opt/IBM/InformationServer/Repos v Tiers: Services v Commands: Import v Components: All v Required when the metadata repository database is installed on a DB2 database server
xmeta.db2.admin.username This property specifies the user name of the DB2 database user who has SYSADM, SYSCTRL, or SYSMAINT privileges and who can run backup and restore operations on the metadata repository database. Default: xmeta.db2.admin.username=db2inst1 v Tiers: Services v Commands: Import, Export v Components: All v Required when the metadata repository database is installed on a DB2 database server
Oracle database: Metadata repository properties

The following properties define the metadata repository environment when the metadata repository is hosted on an Oracle database server. xmeta.oracle.sys.username This property specifies the name of the metadata repository database system user who has sysadm, sysctrl, or sysmaint authorization. Default: xmeta.oracle.sys.username=system v Tiers: Services v Commands: Import, Export v Components: All v Required when the metadata repository database is installed on an Oracle database server xmeta.oracle.sys.password This property specifies the password of the metadata repository database system user. Default: xmeta.oracle.sys.password= y010UWxT1hqqCqirnRj2zg== v Tiers: Services v Commands: Import, Export v Components: All v Required when the metadata repository database is installed on an Oracle database server
57
IBM Confidential
xmeta.oracle.sys.servicename This property specifies the metadata repository database system ID (SID). Default: xmeta.oracle.sys.servicename=XMETA v Tiers: Services v Commands: Import, Export v Components: All v Required when the metadata repository database is installed on an Oracle database server xmeta.oracle.tablespacename The case-sensitive name of table space on the metadata repository database. The table space name must be the same on the source and target installations. Default: xmeta.oracle.tablespacename=XMETATBS v v v v Tiers: Services Commands: Import, Export Components: All Required when the metadata repository database is installed on an Oracle database server
xmeta.oracle.datadumpfolder This property specifies the absolute path to the directory where the exported dump data is generated by Oracle. The sample file includes the following default entry and value: xmeta.oracle.datadumpfolder=C:\\oracle\\product\\10.2.0\\admin\\ souce_inst\\dpdump.
Windows Linux UNIX Specify a value for other operating systems as appropriate: xmeta.oracle.datadumpfolder=/opt/oracle\\product\\ 10.2.0\\admin\\souce_inst\\dpdump v Tiers: Services v Commands: Export
v Components: All v Required when the metadata repository database is installed on an Oracle database server xmeta.oracle.datafilefolder This property specifies the absolute path to the directory where the data file is stored. The sample file includes the following default entry and value: xmeta.oracle.datafilefolder=C:\\oracle\\product\\10.2.0\\oradata\\ target_inst.
Windows
Specify a value for other operating systems as appropriate: xmeta.oracle.datadumpfolder=/opt/oracle/product/10.2.0/ admin/souce_inst/dpdump v Tiers: Services
Linux UNIX
v Commands: Import v Components: All v Required when the metadata repository database is installed on an Oracle database server
58
IBM Confidential
Microsoft SQL Server: Metadata repository properties

The following property defines the metadata repository environment on the target installation when the metadata repository is hosted on an SQL Server database. xmeta.sqlserver.datafolder This property specifies the absolute path to the directory where the metadata repository database is stored on the target installation.
Windows Default: xmeta.sqlserver.datafolder=C:\\Program Files\\Microsoft SQLServer\\Data v Tiers: Services v Commands: Import v Components: All v Required when the metadata repository database is remotely installed on an SQL Server database server
IBM InfoSphere Information Analyzer analysis database properties

When InfoSphere Information Analyzer is installed, use the following properties to define the database environment for the InfoSphere Information Analyzer analysis database. ia.migrate.analysisdb.enabled If you want to migrate the InfoSphere Information Analyzer analysis database, set this property to true. v Tier: Services v Commands: Import, Export v Components: Information Analyzer v Optional. Use only if you want to migrate the analysis database from the source system to the target system. ia.gendb.enabled If you need to migrate the analysis database manually, use this property to enable ia.gendb.directory, which generates the database scripts that you use to manually backup and restore your InfoSphere Information Analyzer analysis database. When you set ia.gendb.enabled=true and the ia.gendb.directory is set to valid path, the InfoSphere Information Analyzer scripts are generated. The database administrator must manually execute scripts to move the analysis database. Note: If you want to set this property to true, make sure that you also set ia.migrate.analysisdb.enabled=true. v Tiers: Services v Commands: Import, Export v Components: Information Analyzer v Required when the analysis database is installed on a remote database server v Optional when the analysis database is on the same computer as the services tier ia.gendb.directory Directory where the InfoSphere Information Analyzer repository scripts will be generated for the database administrator to execute.
59
IBM Confidential
If you set ia.gendb.enabled=true, you must specify the absolute path to the directory where you want the migration scripts to be generated on the services tier computer. If your analysis database is not on the services tier computer, you must move the scripts to the metadata repository tier computer before you can run the scripts. You must review the readme.txt file that is generated with the scripts, and then manually edit the scripts for your database environment. After the migration import is completed, before you can run the scripts to export and import the analysis database. (You wait until the import is completed before you run these scripts on the target installation.) Windows The sample file includes the following default entry and value: ia.gendb.directory=C:\\Migration\\ia-db-scripts. Linux UNIX Specify a value for other operating systems as appropriate: ia.gendb.directory=/opt/Migration/ia-db-scripts Note: The ia.gendb.directory property works independently of the xmeta.gendb.directory property. Be sure to specify a directory name that is different from the directory that might be specified for xmeta.gendb.directory. v Tiers: Services v Commands: Import, Export v Components: Information Analyzer v Required only if you set ia.gendb.enabled=true to migrate the analysis databases manually ia.keep.analysisengine.options This property specifies to retain the When set to true, preserve the InfoSphere Information Server engine settings on the target installation. When this property is set to false or is omitted, the engine settings on the target installation are not preserved and the engine settings from the source installation are set. Default: ia.keep.analysisengine.options=true v Tiers: Services v Commands: Import, Export v Components: Information Analyzer v Optional ia.keep.analysisdb.options When set to true, preserve the InfoSphere Information Analyzer analysis database settings on the target installation. When this property is set to false or is omitted, the analysis database settings on the target installation are not preserved and the analysis database settings from the source installation are set. Default: ia.keep.analysisdb.options=true v Tiers: Services v Commands: Import, Export v Components: Information Analyzer v Optional
60
IBM Confidential
IBM DB2: Analysis database properties

The following properties define the database environment when the InfoSphere Information Analyzer analysis database is hosted on an IBM DB2 database server. Specify these properties to define the migration properties. For installations with multiple InfoSphere Information Analyzer analysis databases, you must specify properties for each unique database name. ia.db2.db.binpath Absolute path to the analysis database bin directory.
Windows The sample file includes the following default entry and value: ia.db2.db.binpath=c:\\IBM\\SQLLIB\\BIN.
Specify a value for your database server and other operating systems as appropriate. For example, for DB2 database system, Version 9.5 on Linux and UNIX: ia.db2.binpath=\opt\IBM\db2\V9.5\bin
Linux UNIX
v Tiers: Services v Commands: Import, Export v Components: Information Analyzer v Required when the analysis database is installed on the DB2 database server ia.db2.installdir Absolute path to the directory where the analysis database is stored on the metadata repository tier computer.
Windows The sample file includes the following default entry and value: ia.db2.installdir=c:\\. Linux UNIX Specify a value for other operating systems as appropriate: ia.db2.installdir=/opt/users/db2insta1/sqllib
v Tiers: Services v Commands: Import, Export v Components: Information Analyzer v Required when the analysis database is installed on the DB2 database server
Oracle database: Analysis database properties

The following properties define the database environment when the InfoSphere Information Analyzer analysis database is hosted on an Oracle database server. Specify these properties to define the migration environment for the analysis database. Migrations of multiple InfoSphere Information Analyzer analysis databases is currently not supported. ia.oracle.sys.username The analysis database system user name. This user must have sysadm, sysctrl, or sysmaint authorization. Default: ia.oracle.sys.username=system v Tiers: Services v Commands: Import, Export
61
IBM Confidential
v Components: Information Analyzer v Required when the analysis database is installed on the Oracle database server ia.oracle.sys.password The analysis database system user password. Default: ia.oracle.sys.password= y010UWxT1hqqCqirnRj2zg== v Tiers: Services v Commands: Import, Export v Components: Information Analyzer v Required when the analysis database is installed on the Oracle database server ia.oracle.sys.servicename The analysis database system ID (SID). Default: ia.oracle.sys.servicename=IADB v Tiers: Services v Commands: Import, Export v Components: Information Analyzer v Required when the analysis database is installed on the Oracle database server ia.oracle.tablespacename The case-sensitive name of the table space on the analysis database. The table space name must be the same on the source and target installations. Default: ia.oracle.tablespacename=IADBTBS v v v v Tiers: Services Commands: Import, Export Components: Information Analyzer Required when the analysis database is installed on the Oracle database server
ia.oracle.datafilepath Absolute path to the directory where the analysis database table space is stored on an Oracle database server.
Windows The sample file includes the following default entry and value: ia.oracle.datafilepath=C:\\oracle\\product\\10.2.0\\oradata\\ source_inst\\IADBTBS.DBF. Linux UNIX Specify a value for other operating systems as appropriate: ia.oracle.datafilepath=/opt/oracle\\product\\10.2.0\\ admin\\souce_inst\\IADBTBS.DBF v Tiers: Services v Commands: Export v Components: Information Analyzer
v Required when the analysis database is installed on the Oracle database server ia.oracle.datadumpfolder Absolute path to the directory where the exported dump data is generated by Oracle.
62
IBM Confidential
Windows The sample file includes the following default entry and value: ia.oracle.datadumpfolder=C:\\oracle\\product\\10.2.0\\admin\\ souce_inst\\dpdump.
Specify a value for other operating systems as appropriate: ia.oracle.datadumpfolder=/opt/oracle/product/10.2.0/admin/ souce_inst/dpdump

Linux UNIX
v v v v
Tiers: Services Commands: Export Components: Information Analyzer Required when the analysis database is installed on the Oracle database server
ia.oracle.datafilefolder The absolute path to the directory where the datafile is stored.
Windows The sample file includes the following default entry and value: ia.oracle.datafilefolder=C:\\oracle\\product\\10.2.0\\oradata\\ target_inst.
Specify a value for other operating systems as appropriate: ia.oracle.datadumpfolder=/opt/oracle/product/10.2.0/admin/ target_inst v Tiers: Services v Commands: Import
Linux UNIX
v Components: Information Analyzer v Required when the analysis database is installed on the Oracle database server
Microsoft SQL Server: Analysis database properties

The following property defines the database environment on the target installation when the InfoSphere Information Analyzer analysis database is hosted on an SQL Server database server. ia.sqlserver.datafolder The absolute path to the directory where the analysis database is stored on the target installation.
Windows Default: ia.sqlserver.datafolder=C:\\Program Files\\Microsoft SQLServer\\Data v Tiers: Services v Commands: Import v Components: Information Analyzer v Required when the analysis database is installed on the SQL Server database server
Host change file

The host change file is required when your target installation topology is different than your source installation, has more than one engine tier, or when the engine tier is installed on a computer without a services tier.
63
IBM Confidential
Purpose
The host change file identifies the host names of the engine tier computers in the source and target installations. You can also include entries in the host change file to specify different port numbers and project locations for your target installation. The ismigration tool automatically resolves host information for the following migrations: v Single tier topology installations v Services tier The HostChangeConfig.xml.sample file is provided in the install_dir\Migration\ conf directory. You can also reference the install_dir\Migration\HostChangeConfigTemplate.xml file that is created when the export is completed. Optionally, you can use the IBM Support Assistant Lite for InfoSphere Information Server tool to gather the required installation information from your source and target installation.
Syntax
The host change file adheres to the following conventions: v XML format Case-sensitive Create a Host tag for each computer that you are migrating Create an entry for each engine tier, if your installation has more than one Enter values for the source installation computer and the target installation computer, as appropriate for your installation v Specify the full host name, if required. For example, if your computer host name uses a long host name, specify Clv00012.afq.trew.uvn.ComputerA instead of ComputerA. v v v v The following example host change file supports migration from a single-tier source installation with the services, metadata repository, and engine tiers installed to a three-computer target installation. There is no change to port numbers or project locations.
Table 10. One-computer source installation migration to three-computer target installation Installation tier Services Engine Source values ComputerA SystemA Target values ProdB ProdC
<HostConfig> <Host tier=SERVICES name=ComputerA newName=ComputerB/> <Host tier=ENGINE name=ComputerA newName=ComputerC/> </HostConfig>
This example host change file supports migration from one source computer to two target computers, and the port number and project location change. The source installation engine tier computer contains the following server name and port number:
64
IBM Confidential agent.servername=ComputerA agent.port=31531
The engine tier computer on your target installation contains the following server name and port number in the agent.properties file:
agent.servername=ComputerC agent.port=31561 Table 11. One-computer source installation to two-computer target installation with port and project location changes Installation tier Engine Port number Project location Source values SourceHost 31531 ProjectA Target values Target.Host.2 31561 /opt/IBM/DataStage/ projects/Test
<HostConfig> <Host name="SourceHost" tier="ENGINE" newName="Target.Host.2"> <PortChange portNumber="31531" newPortNumber="31561"/> <ProjectLocation name="ProjectA" directory="/opt/IBM/DataStage/projects/Test"/> </Host> </HostConfig>
Note: Use the host name that you specified at installation. For example, if you the host name that you provided at installation is xyz00011.ghi.amsu.hal.com, you must specify the host name as xyz00011.ghi.amsu.hal.com, not xyz00011.
Userfiles specifies additional files to include in archive

To specify the list of files to include, use the -userfiles parameter when you run the ismigration tool to export your installation. The -userfiles parameter specifies the name of a text file that contains a list of additional files to include in the migration archive file. The file that you specify with the -userfiles parameter must adhere to the following conventions: v Is a text file on your local computer. v Each file name is specified with an absolute path name. v Each line contains a single file name. You might find it useful to specify a list of files that you want to include in the archive file (hostname_TIER_timestamp.iar) that you generate with the export command. When you import the archive file to your target installation, the files that are listed in the text file that you specify with the -userfiles parameter are also imported. After the ismigration tool export process is completed, all the files that you are required to move to your target installation are automatically specified in the migration.todo.txt file that is generated for each services and engine tier computer. For example, the configuration files that are required for your IBM InfoSphere DataStage and QualityStage jobs are listed in the migration.todo.txt file that is generated for the services tier computer.
65
IBM Confidential
Note: The files that are specified in the migration.todo.txt file are listed, regardless of whether you include the files in the text file that you specify with the -userfiles parameter. The following command exports the source installation and generates an archive file that includes the files that are listed in the specified text file. v
Linux UNIX
/opt/IBM/InformationServer/Migration/bin/ismigration.sh -export -archive /tmp/archive -userfiles /opt/IBM/InformationServer/Migration/conf/exportfiles.dat
Windows
C:\IBM\InformationServer\Migration\bin\ismigration.bat -export -archive \tmp\archive -userfiles C:\IBM\InformationServer\Migration\conf\exportfiles.txt
Migration log files

The ismigration tool log files contain information that can be used for troubleshooting purposes. The ismigration log files are in the default logs directory as follows: v v
Linux Windows UNIX
/opt/IBM/InformationServer/Migration/logs
C:\IBM\InformationServer\Migration\logs
There are informational and error log files. v The information such as command syntax, debug, and tracing information is written to the migrationn.log.n file. v The ismigration errors that display on the screen during migration are captured in the migrationn.error.log.n. Note: When no errors occur, the migrationn.error.log.n file is generated with a size of 0 KB. where n is an incremental number starting at 0, and incremented at 1 with each subsequent migration. When new log files are generated, the newest log files start at 0 and the existing files are renamed with incremented file names. Up to ten log files are retained in the logs directory.
migration.todo.txt file
The ismigration tool generates a migration.todo.txt file for each computer after the export and import processes are completed.
Purpose
The migration.todo.txt file is generated in the Migration folder on each services and engine tier computer after the migration is completed. You must review each section in the file, and complete the required to-do activities before you continue the migration. Entries in the migration.todo.txt file vary, based on your installation environment.
66
IBM Confidential
Export entries in the migration.todo.txt file

After the migration export is completed on each source installation computer, the required activities that are listed in the migration.todo.txt file reflect your installation environment and configuration. Review each section carefully and complete the required activities. IBM InfoSphere Information Server entries Entries vary, based on your installation environment. For example, when the Java messaging system exists, an entry like the following is shown:
Please ensure that the following JMS elements, which are referenced by one or more ISD applications, are configured in the application server on the target computer. jms/Queue1 jms/ConnFactory1 jms/ActSpec1
The source installation host names are recorded in the HostChangeConfigTemplate.xml file in the Migration directory. The entry in the migration.todo.txt file is provided as a reference to the HostChangeConfigTemplate.xml. The InfoSphere Information Server entry in a migration export looks like the following example:
HostChangeConfigTemplate.xml was generated and placed in Migration directory. You can use this file as a starting point if you plan to migrate the product to different servers. Additionally, you can run import on the SERVICES tier with -validateonly option to have source and target host names for both ENGINE and SERVICES tiers printed exactly as they are used in the installation. You can then enter these host names in the host change configuration file.
Oracle export When you export the metadata repository database or the IBM InfoSphere Information Analyzer analysis database, any existing database dump file is preserved and renamed. To preserve disk space, you must manually delete the renamed file if it is not needed.
When using Oracle during the export there is possibility that an existing <driveLetter>:\app\<username>\admin\IADB\dpdump\ IADBSPACE.DMP has been renamed to ensure the success of the Oracle export. Please delete the renamed file if it is not needed.
Import entries in the migration.todo.txt file

After the migration import is completed on each source installation computer, the required activities that are listed in the migration.todo.txt file reflect your installation environment and configuration. Review each section of the file and complete the required to-do activities. IBM InfoSphere DataStage entries When your target installation includes InfoSphere DataStage, the migration.todo.txt file specifies the activities that are required to ensure that the migrated jobs will run in the new Version 8.5 installation. The InfoSphere DataStage entries in a migration import to a Microsoft Windows computer with InfoSphere DataStage installed looks like the following example:
67
IBM Confidential In order to ensure your migrated Jobs function correctly, please make sure you install all Information Server Packs that were installed on the source system. ... The following SQL users were not transferred across to the new system. NT AUTHORITY\system hawk IS85MIGQA-07\hawk A copy of the file default.apt from the source system has been copied to the current system. The file was copied to C:\IBM\InformationServer\ Server\Configurations\default.apt_source_bak15500. Please check this is still valid for the current system. If you specified a different location for the APT config file using the APT_CONFIG_FILE environment variable, it will need to be copied over manually. The following SQL users were not transferred across to the new system. ... A copy of the file FTPTemplate.ftp from the source system has been copied to the current system. The file was copied to C:\IBM\InformationServer\ Server\Projects\RTIDeployTC\FTPTemplate.ftp. Please check this is still valid for the current system. To complete migration of each project, please run the UPDATEPROJECT script to "Upgrade" them to release 8.5. Steps are: From an OS shell, cd to a project directory. Enter the engine command shell. Type the following to run the tool:UPDATEPROJECT ALL
68
IBM Confidential
Part 3. Version 7.5.3 and earlier migrations
69
IBM Confidential
70
IBM Confidential
Chapter 8. Migrations from Version 7.5.3 and earlier

You can migrate from previous versions of DataStage, QualityStage, and WebSphere RTI to a new IBM InfoSphere Information Server, Version 8.5 installation. Export projects and jobs from release 7.5.3 and earlier versions of DataStage and QualityStage and then import the projects and jobs to an InfoSphere Information Server, Version 8.5 installation. You can also migrate from IBM WebSphere RTI 7.5, 7.5.1, and 7.5.2 to IBM InfoSphere Information Services Director, Version 8.5 and subsequent releases. DataStage Version 6 is the earliest release that is supported for migration to Version 8.5. Note: This export and import migration method for release 7.5.3 and earlier versions of DataStage, QualityStage, and WebSphere RTI does not use the ismigration tool. The DataStage Version Control component is not supported by InfoSphere Information Server, Version 8.5. Instead, use Information Server Manager to integrate a supported source control system.
71
IBM Confidential
72
IBM Confidential
Chapter 9. Migration from DataStage 7.5.3 and earlier versions

Migration involves exporting DataStage projects and saving the settings files from the existing installation, and then importing the projects and moving the settings files to the Version 8.5 installation. This migrate method applies to the development environment where the design-time information resides and moves all of your migrated projects to IBM InfoSphere Information Server, Version 8.5. Complete the following activities to migrate your source DataStage 7.5.3 and earlier environment to your target Version 8.5 development environment: 1. Export projects. See Exporting projects. 2. Save the DataStage settings files. See Saving DataStage settings files on page 75. 3. Installing InfoSphere Information Server, Version 8.5, including IBM InfoSphere DataStage. See "Installing IBM InfoSphere Information Server software" in the IBM InfoSphere Information Server Planning, Installation, and Configuration Guide. 4. Integrating the contents of your saved settings and configuration files. a. Restore the settings files. See Restoring contents of DataStage 7.5.3 or earlier settings files on page 78. b. Move job dependency objects such as flat files, libraries, schema files, and hashed files that your project uses. See Move job dependency objects on page 76. 5. Import projects. See Importing DataStage projects on page 78. 6. Recompile jobs in your projects. See Recompiling jobs on page 80. Note: Use the migration from DataStage 7.5.3 and earlier method to migrate to different computers for your Version 8.5 installation, or to the same computers by using an ITAG installation. This migration method information applies to migration to different target computers or the same computers for source and target installations. ITAG installations exist when you install more than one instance of DataStage or InfoSphere Information Server on the same set of Linux or UNIX computers.
Exporting projects
You export your DataStage projects from your source installation before migrating the projects to your Version 8.5 target installation. Ensure that nobody is using DataStage and that all clients are disconnected. You can export projects by using one of the following methods: v Export from the DataStage Manager client. v Export from the command line of a DataStage client computer.
Exporting projects from the DataStage Manager client

You can use the DataStage Manager client to export projects from your development environment.
73
IBM Confidential
Note: The current version of your installation determines the name of the DataStage Manager client. Your installation might refer to the client as the DataStage client. 1. Open the DataStage Manager client, and attach to project that you want to export. 2. Ensure View Host View is selected. 3. Select Export DataStage Components. 4. In the Export window, specify details about the project that you want to export: a. In the Export to file field, type or browse for the path name of the file in which to store the project. By default, export files have the suffix .dsx. b. In the Components tab, select the Whole Project option. 5. Click OK. The project is exported to the file that you specified. 6. In the left pane of the DataStage Manager window, select the next project and repeat the export process from step 3, specifying a different name for the export file.
Exporting projects from the command line

You can use the command line on the client computer to export your projects from your development environment. You can create a script that runs these commands and exports all of your projects in a single operation. Export your projects from your source installation before you import the projects to your target installation. 1. Open a command line editor and go to the DataStage client directory (the default path is C:\Ascential\Program Files\Ascential\DataStageversion). 2. Enter the command: dscmdexport /H=hostname /U=username /P=password project_name export_file_path [/V] The arguments are as follows: v hostname is the name of the DataStage server computer where the project is located. v username is your user name on the server computer. v password is the password for that user name. v project_name is the name of the project that you are exporting. v export_file_path is the path name of the destination file. By convention, export files have the suffix .dsx. v /V is optional. Including /V turns the verbose option on so that you can follow the progress of the export procedure. For example, the following command exports the project named monthlyaudit that is located on the DataStage server named R101 and writes the project to a file named monthlyaudit.dsx. The target file is located in a directory named migrated_projects on the client computer.
dscmdexport /H=R101 /U=BillG /P=paddock monthlyaudit C:\migrated_projects\monthlyaudit.dsx
You can enter a command for each project that you want to export, or you can create a script that contains commands for all of the projects on your DataStage server computer.
74
IBM Confidential
Saving DataStage settings files

Back up your settings files on your existing DataStage server. After you install IBM InfoSphere Information Server, Version 8.5, you can compare each of your saved settings files with the equivalent new file. You can then integrate the two files. You must not replace the new files with the files that you saved from your existing installation, because you will overwrite new settings. The files that you copy depend on whether your DataStage server is on a Windows computer, or a UNIX or Linux computer.
Saving settings files (UNIX and Linux)

If you are migrating an existing DataStage server on a UNIX or Linux computer, you must save copies of certain settings files. The environment variable $DSHOME identifies the engine directory of your DataStage installation. By default the engine directory is /user_home/Ascential/DataStage/DSEngine, where user_home is the home directory of the DataStage administrator who originally installed DataStage (by default, dsadm). Each project is in its own directory in the /user_home/Ascential/DataStage/Projects directory. 1. Copy the $DSHOME/dsenv file to a location outside of the DataStage file structure. 2. To keep a record of the existing configuration and the configuration of your ODBC drivers, copy the following files to a location outside of the DataStage file structure: v $DSHOME/.odbc.ini v $DSHOME/uvodbc.config v The uvodbc.config file located in each project directory 3. Copy the DSParams file from each project directory to a location outside of the DataStage file structure. 4. Also, copy the DSParams file from the Template project. $DSHOME/../Template/ DSParams
Saving the DSParams file (Windows)

If you are migrating an existing DataStage server on a Windows computer, save a copy of the DSParams file from each project directory. Each project has its own directory located, by default, in the directory C:\Ascential\DataStage\Projects. Save the DSParams file so that you can move it to your target installation. 1. Copy the DSParams file from each project directory to a safe location. 2. Also, copy the DSParams file from the Template project. For example, save the C:\Ascential\DataStage\Template\DSParams file. 3. Copy the $DSHOME/uvodbc.config in the engine directory. 4. The uvodbc.config file located in each project directory.
75
IBM Confidential
Move job dependency objects

The jobs in your projects might depend on objects outside of DataStage. You must move these objects to the Version 8.5 target installation. You need to move job dependency objects in the following situations: v If the files are in the DataStage server or client directory structures, or v If you are installing InfoSphere DataStage on a different computer. Note: If you have flat files, hashed files, or other dependencies that are located in your DataStage directory structure, or if you are migrating to a different computer, then you must move these files yourself. These files are not saved as part of the export procedure. The DataStage export procedure exports DataStage objects, such as job designs, table definitions and custom routines. If the jobs in your projects have other dependencies, then you might need to move these dependencies. Dependencies include flat files, files containing schemas used by parallel jobs, and libraries that are called by parallel job custom routines. It does not include parallel job data sets or file sets. If you are using data sets or file sets to permanently store data, then you must design a job to write the data to a flat file or other data target. You can move flat files, libraries, and schema files by using normal operating system commands. You might need to modify job designs to identify the new locations of these files. If there are server jobs in your projects that use hashed files, then you must use a dedicated procedure to move the hashed files.
Migrating hashed files

If your DataStage project contains server jobs that use hashed files, then you need to move the hashed files to a new location as part of the migration procedure. Before moving the files, stop the DataStage server to ensure that dynamic hashed files are copied correctly. If you previously added indices to the hashed files, remove the indices. The hashed files from your source installation need to be saved and moved to the target installation. 1. Locate the hashed files in your directory structure: v Each static hashed file is represented by two operating system files. For example, a static hashed file named price_lookup is contained in the two files named price_lookup and d_price_lookup. v Each dynamic hashed file is represented by a directory with the same name as the hashed file and a file named D_hashed_file_name. For example, a dynamic hashed file named code_lookup is represented by the directory named code_lookup and the file named D_code_lookup. 2. Copy the files or directories that represent each of your hashed files to a safe location outside of the DataStage directory structure. You can restore these files after you install and configure InfoSphere DataStage.
76
IBM Confidential
Remove previous versions of DataStage

Removing DataStage completely removes your current version of DataStage from server and client computers. Ensure that your DataStage server computer is backed up before you remove DataStage, and that no one is using DataStage. There are separate procedures for removing DataStage clients and removing DataStage servers.
Removing a DataStage server (Windows)

You use Windows Add or Remove Programs to remove an existing DataStage server from a Windows computer. Ensure that DataStage is not running and ensure that no clients are connected to the server. Removes the DataStage server. 1. Open the control panel. 2. In the control panel, select Add or Remove Programs. 3. In the list of installed programs, select DataStage server. 4. Click Change/Remove.
Removing a DataStage server (Linux, UNIX)

You run the uninstallation program to remove an existing DataStage server from a UNIX or Linux computer. Mount the original installation CD, or copy the CD contents to your computer. Removes the DataStage server. 1. Log in as the root user. 2. Change directory to the top level directory of the CD, or the directory to which you copied the CD contents. 3. Type the relevant uninstallation command:
Operating System Solaris AIX
Command uninstll.sh uninstll.sh UNINSTLL.SH;1 uninstll.sh
HP-UX LINUX
The uninstallation program guides you through the procedure for removing the DataStage server.
Removing DataStage clients

You use Windows Add or Remove Programs to remove existing DataStage clients from a Windows computer. Ensure that nobody is using DataStage and that no clients are connected to the DataStage server.
77
IBM Confidential
Removes DataStage clients. 1. Open the Windows control panel. 2. In the control panel, select Add or Remove Programs. 3. In the list of installed programs, select DataStage Clients. 4. Click Change/Remove.
Importing DataStage projects

Import the projects to your Version 8.5 installation. Import projects from earlier versions of DataStage to your Version 8.5 development environment. 1. Move the .dsx file or files that you created to the computer where the IBM InfoSphere DataStage and QualityStage, Version 8.5 clients are installed. 2. Open the Administrator client and create a project or projects to contain the objects from your exported projects: a. On the Projects page, click Add. b. In the Add Project window, type the name of the project that you want to create and specify a path name for it. You can use the names of the original projects if required. c. Click OK to create the project. d. Repeat these steps for each project that you want to create. You might want to create a project for each of the projects that you exported and give it the same name as the original project. 3. Open the Designer client and attach to the target project. 4. Select Import DataStage Components. 5. Specify the name of the .dsx file that you want to import, and click OK. 6. After you unit test the migrated components in your Version 8.5 development environment, you must export the DataStage components from your Version 8.5 environment and then import them to your Version 8.5 production environment.
Restoring contents of DataStage 7.5.3 or earlier settings files

If you previously customized any of your DataStage 7.5 or earlier settings files, you might need to restore these customizations. Do not copy your saved versions over the new ones to restore the settings files. You must merge the contents of your saved files with the new files. You must only add or edit settings in the new files. Do not delete settings. Use this procedure with any of the settings files that you saved earlier. 1. Open the saved version of the settings file in a text editor. 2. Open the new version of the same file in a text editor. 3. Compare the contents of the saved file with the new file. 4. Add any required entries to the new file. 5. Save the new file and close the text editor.
Restoring DataStage job dependencies

You must restore any DataStage job dependencies that you saved.
78
IBM Confidential
After you migrate to Version 8.5, restore job dependency files to your new installation. 1. For each file, find the location for the file in the new IBM InfoSphere Information Server directory structure. For example, if the file that you want to restore was in the project directory in your previous DataStage installation, find the project directory to which you imported the project contents. 2. Use operating system commands to copy the saved file to the required location. 3. Ensure that the jobs that reference these files can locate them. If the file is referred to directly, you must edit the path name in the job design. If the file is referred to by a job parameter, you might need to edit the default value of the parameter to reference the new location for the file.
Restoring hashed files

You need to restore the hashed files that you saved. To restore hashed files, use IBM InfoSphere DataStage to create empty hashed files for each of the files that you want to restore. You then replace the empty files with the saved files. To restore hashed files, follow one of the two procedures. 1. For jobs in your migrated project that create the hashed files, open the InfoSphere DataStage and QualityStage Director client, and attach to the migrated project that uses the hashed files. 2. Run or validate the job that creates the hashed files. 3. Close all InfoSphere DataStage clients and stop the DataStage services. 4. Locate the newly created files in your directory structure and copy the saved hashed files over the top of them. 5. Restart the DataStage services. Your hashed files are now available for use.
Designing a job to create new hashed files

To design a job to create the new hashed files. 1. Open the Designer client, and attach to the migrated project that uses the hashed files. 2. Create a new server job. 3. For each hashed file that you need to restore, add a Sequential File stage linked to a Hashed File stage. 4. In the Sequential File stage, point to an empty text file and define one column in the Outputs page Columns tab. 5. In the Hashed File stage, specify the name of the hashed file that you are restoring, then select the Create File option and specify the file type of the hashed file that you are restoring. 6. When you have added stages for all the hashed files that you want to restore, compile and then validate or run the job to create the empty hashed files. 7. Close all InfoSphere DataStage clients and stop the DataStage services 8. Locate the newly-created files in your directory structure and copy your saved hash files over the top of them. 9. Restart the DataStage services.
79
IBM Confidential
Your hashed files are now available for use.
Recompiling jobs
You must recompile the jobs and routines in the migrated projects to create new executable jobs. You can start the wizard from the Tools menu of the Designer client. Select Tools Multiple Job Compile . You can also select multiple items in the repository tree or Advanced Find window and use the shortcut menu to start the compiler wizard. 1. If you started the wizard from the Tools menu, specify the criteria for selecting jobs to compile. Choose one or more of: Server Parallel Mainframe Sequence Custom server routines Custom parallel stage types You can also specify that only currently uncompiled jobs will be compiled, and that you want to manually select the items to compile. 2. Click Next>. If you chose the Show manual selection page option, the Job Selection Override screen appears. Choose jobs in the left pane and add them to the right pane by using the Add buttons or remove them from the right pane by using the Remove buttons. Clicking Add while you have a folder selected selects all the items in that folder and moves them to the right pane. All the jobs in the right pane will be compiled. 3. Click Next>. If you are compiling parallel or mainframe jobs, the Compiler Options screen appears, allowing you to specify the following: v v v v v v v Force compile (for parallel jobs). v An upload profile for mainframe jobs you are generating code for. 4. Click Next>. The Compile Process screen appears, displaying the names of the selected items and their current compile status. 5. Click Start Compile to start the compilation. As the compilation proceeds, the status changes from Queued to Compiling to Compiled OK or Failed and details about each job are displayed in the compilation output window as it compiles. Click the Cancel button to stop the compilation, although you can only cancel between compilations so the Designer client might take some time to respond. 6. Click Finish. If the Show compile report checkbox was selected, the job compilation report screen appears, displaying the report generated by the compilation.
Updating jobs that use the QualityStage 7.5 plug-in

If you have existing DataStage jobs that use the QualityStage plug-in stage to connect to QualityStage 7.5, and you want to continue running those jobs, then you must rewrite those jobs to use the parallel canvas and the Version 8.5 stages. You must rewrite the jobs that use the QualityStage 7.5 plug-ins. After you import the jobs to Version 8.5, rewrite the jobs to use the parallel canvas and the Version 8.5 stages.
80
IBM Confidential
Switching between different versions of clients

You can install different versions of DataStage clients on a single Windows computer and switch between them by using the Multi-client Manager. The Multi-client Manager is installed on the Version 8.5 client tier. Note: The Multi-client Manager is not supported on DataStage releases earlier than 7.0. For DataStage releases earlier than 7.0, install each client version on a separate computer. When your organization is using different versions of DataStage, it is useful to have different client versions on your Windows computer. You can then switch between the clients according to which DataStage server you want to connect to. For example, if you are evaluating IBM InfoSphere DataStage, Version 8.5 on one of your installations, while still running WebSphere DataStage, Version 7.5.3 on another installation, you can have the clients for both releases on a client tier computer, and switch between the clients as necessary. You can install multiple DataStage clients by running the client installer (versions earlier than WebSphere DataStage 8.0), or running the suite installer and selecting only the client tier (Version 8.0.1 and later). You must install the Version 8.5 client after you install any earlier client versions, so that the Version 8.5 Multi-Client Manager is the latest version installed. 1. Start the Multi-client Manager by double-clicking the desktop shortcut. 2. In the Current installation field, check whether the currently selected version is the version that you want. v If the correct version is selected, you need take no further action. v If the correct version is not selected, select the correct client in the Known installations list and click Select. 3. Click Close to close the Multi-client Manager.
Multiple server method (Linux and UNIX only)

If your DataStage server is on a Linux or UNIX computer, you can keep that instance and install IBM InfoSphere Information Server, Version 8.5. You can also install multiple IBM InfoSphere DataStage engine tiers. Each engine tier must be registered to a different instance of the IBM InfoSphere Information Server services tier. Note: There is a change of terminology between DataStage 7 and InfoSphere DataStage, Version 8.0.1 and later. In earlier versions the engine component was identified as the DataStage server, for release 8.0.1 and later, the engine component is identified as the engine tier. If you maintain different releases of DataStage server, or multiple instances of the same server, you can keep all of those instances. You can also upgrade each of these servers to InfoSphere DataStage, Version 8.5 and keep their existing identity information. Each instance of a DataStage server is identified by a tag ID (an ITAG) and allocated a different port. You also specify a different home directory for each
81
IBM Confidential
server. Each DataStage server has a different set of projects that you access through that server. You connect to different servers by specifying the port number in addition to the UNIX server ID. The existing DataStage server instance retains the default port number, 31538, and uses the default ITAG, ADE. If you already have multiple server instances, then you already have servers that use different ports and ITAGs. Each version of DataStage requires clients of the same version. You must use the Multi-Client Manager program to switch between different client versions on your Windows client computers. You can use the multi-server facility to install multiple instances of the InfoSphere DataStage, Version 8.5 engine tier on the same computer. When multiple instances of the engine tier are installed on the same computer, each engine tier requires a unique profile for IBM WebSphere Application Server. The following table shows a scenario of a multi-server installation, and illustrates the use of port numbers and ITAGs.
Table 12. Scenario 1: InfoSphere DataStage, Version 8.5 server installed on the same computer as an existing DataStage 7.5.1 server Engine tier instance WebSphere DataStage, release 7.5.1 server Server details v Itag ADE v Port 31538 v /disk1/Ascential/DataStage InfoSphere DataStage, Version 8.5 server v Itag 123 v Port 31540 v /opt/IBM/InformationServer/Server
The following table shows a scenario of a multi-server installation with three servers, and illustrates the use of port numbers and ITAGs.
Table 13. Scenario 2: InfoSphere DataStage, Version 8.5 server installed on the same computer as two existing DataStage 7.5.1 servers Engine tier instance WebSphere DataStage, release 7.2 server Server details v Itag ADE v Port 31538 v /disk1/Ascential/DataStage WebSphere DataStage, release 7.5.1 server v Itag A23 v Port 31546 v /disk2/Ascential/DataStage InfoSphere DataStage, Version 8.5 server v Itag 123 v Port 31540 v /opt/IBM/InformationServer/Server
The following table shows a scenario of with three Version 8.5 servers, and illustrates the use of port numbers and ITAGs for Version 8.5 installations.
82
IBM Confidential Table 14. Scenario 3: Three instances of InfoSphere DataStage, Version 8.5 server installed on the same computer Engine tier instance InfoSphere DataStage, Version 8.5 server Server details v Itag ADE v Port 31538 v /opt/IBM/InformationServer/Server InfoSphere DataStage, Version 8.5 server v Itag BED v Port 31540 v /opt2/IBM/InformationServer/Server InfoSphere DataStage, Version 8.5 server v Itag 123 v Port 31542 v /opt3/IBM/InformationServer/Server
Installing Version 8.5 in addition to existing DataStage servers

You can maintain existing DataStage server instances while installing IBM InfoSphere Information Server, Version 8.5. The Version 8.5 installation wizard detects existing DataStage servers during installation. You must provide a unique ITAG value and port number to use for the Version 8.5 server.
Installing IBM InfoSphere DataStage, Version 8.5 clients in addition to existing clients
When you maintain multiple versions of the InfoSphere DataStage server on Linux or UNIX computers, you must maintain corresponding client versions on Windows computers. You need the IBM InfoSphere Information Server, Version 8.5 client installation software and the IBM InfoSphere Information Server Planning, Installation, and Configuration Guide, which is in the top-level directory of the installation media. You can install clients for InfoSphere DataStage, Version 8.5 on the same Windows computer as your existing DataStage clients, and use the Multi-client Manager to switch between the different versions. You can also install InfoSphere DataStage, Version 8.5 clients on a separate Windows computer. If you are installing clients on a computer with existing clients, the client installation program detects their presence and installs the Multi-Client Manager program. 1. Log on to the Windows computer as an administrator. 2. Turn off any firewall software that is installed on the computer. 3. Optional: Turn off your antivirus software. 4. Go to the root directory on the InfoSphere Information Server, Version 8.5 installation media or downloaded installation image. 5. Double-click setup.exe. The installation program starts and guides you through the installation procedure. 6. When asked for an installation directory, select the New installation option and either use the default directory, or specify a new directory. 7. When asked to select the product modules and components, select InfoSphere DataStage and QualityStage. Select other components as required by your installation plan.
83
IBM Confidential
Starting and stopping multiple DataStage servers

When multiple DataStage servers are on a single computer, you must identify the server that you want to start or stop. You identify the DataStage server that you want to start or stop by setting the $DSHOME environment variable to reference the DSEngine subdirectory of the server. For example, there are two servers on the same computer with the following DSEngine subdirectories: v /disk1/Ascential/DataStage/DSEngine (existing 7.5.1 server) v /opt/IBM/InformationServer/Server/DSEngine (IBM InfoSphere DataStage, Version 8.5 server) 1. Set the $DSHOME environment variable to point to the /opt/IBM/ InformationServer/Server/DSEngine directory. 2. Stop the server by using the following command: $DSHOME/bin/uv -admin -stop 3. Wait thirty seconds to give the server time to stop. 4. Start the server by using the following command: $DSHOME/bin/uv -admin -start
Connecting to multiple DataStage servers

To connect to a DataStage server from a client when you have multiple servers, you must specify the server port number in addition to the name of the computer where the server is located. You use a different procedure depending on the version of DataStage server and the client, and whether you are connecting from the command line. The clients for DataStage release 7 attach directly to the engine; the clients for InfoSphere DataStage, Version 8.0.1 and later attach to the engine by way of the services tier, and so the default port numbers are different for each type of client. Use the Multi-Client Manager to switch between different versions of the clients. The client version must match the server version.
Connecting to DataStage version 7.5.3 or earlier

Use this procedure to connect to a DataStage version 7.5.3 or earlier server from any client other than the Administrator client. If multiple versions of the DataStage clients are on your computer, ensure that the same version as the server version is currently selected in the Multi-Client Manager. Connects clients to DataStage servers. 1. Select the Manager, Designer, or Director client from the Start menu. 2. In the Host System field of the Attach to Project window, type the identity of the server computer in the form hostname:portnumber where portnumber is the port number that the server uses. For example, type R101:31538 in the Host System field. 3. Type your user name and password. 4. Specify the name of the project that you want to attach to.
84
IBM Confidential
Connecting to DataStage version 7.5.3 or earlier from the Administrator client

Use this procedure to connect to a DataStage version 7.5.3 or earlier server from the Administrator client. If multiple versions of the DataStage clients are on your computer, ensure that the same version as the server version is currently selected in the Multi-Client Manager. Connect Administrator clients to a DataStage version 7.5.3 or earlier server. 1. Select the Administrator client from the Start menu. 2. In the Host System field of the Attach to DataStage window, type the identity of the server computer in the form hostname:portnumber where portnumber is the port number that the server uses. For example, type R101:31538 in the Host System field. 3. Type your user name and password.
Connecting to IBM InfoSphere Information Server, Version 8.5

Use this procedure to connect to an IBM InfoSphere DataStage and QualityStage, Version 8.5 server from any client other than the Administrator client. If multiple versions of the DataStage clients are on your computer, ensure that the same client version as the server version is currently selected in the Multi-Client Manager. Connects clients to Version 8.5 server. 1. Select the Designer client or Director client from the Start menu. 2. In the Domain field of the Attach to Project window, type the name of the domain to which your InfoSphere DataStage server belongs in the form DomainServer:9080. For example, type R101:9080. 3. Type your user name and password. 4. In the Project field, specify the identity of the project that you want to attach to in the form hostname:portnumber/project where portnumber is the port number that the server uses. For example, type R101:31348/datastage.
Connecting to IBM InfoSphere DataStage and QualityStage, Version 8.5 from an Administrator client
Use this procedure to connect to a Version 8.5 server from the Administrator client. If multiple versions of the InfoSphere DataStage clients are installed on your computer, ensure that the same version as the server version is currently selected in the Multi-Client Manager. Connects Administrator clients to a Version 8.5 server. 1. Select the Administrator client from the Start menu. 2. In the Domain field of the Attach to DataStage window, type the name of the domain to which your InfoSphere DataStage server belongs in the form DomainServer:9080. For example, type R101:9080 in the Domain field or type R201:80 if you are using a front-end Web server. 3. Type your user name and password. 4. In the DataStage Server field, specify the identity of the computer where the server that you want to attach to is located in the form hostname:portnumber
85
IBM Confidential
where portnumber is the port number that the server uses. For example, type R201:9080 or type R301:80 if you are using a front-end Web server.
Connecting to a Version 8.5 DataStage server from the command line

You can use the command line interface to control DataStage jobs in different projects. These instructions assume that you are logged in to the operating system as the user that runs the job. v To connect to a project from the command line, you specify the server name and port number of the required instance with the -server argument in the form -server server:portnumber for local computers. v For remote computers that run InfoSphere DataStage, Version 8.5 server instances, you must specify the domain and the server name in the form -domain domain:domain_portnumber -server server:portnumber. The default domain port number is 9080. For example, to run a job on the local computer on the server that uses port 31359, run this command: dsjob -server r101:31359 -run myproj myjob v To run a job on the local computer on the default server, run this command: dsjob -run myotherproj myotherjob v To run a job on a remote computer called R101 on the Version 8.5 server that uses port 31360, you must also specify the host computer, the domain, and supply the login information. For example, enter the following command: dsjob -domain mydomain:9080 -server r101:31360 -user billg -password paddock -run myproj myjob
86
IBM Confidential
Chapter 10. Migration from QualityStage 7.5 and earlier releases

Required premigration tasks if your Version 7.5 or earlier source installation includes QualityStage. If QualityStage 7 is installed, you need to migrate your jobs to Version 8.5. (The term 'QualityStage 7' refers to all releases between 7.0 and 7.5.) If you were using the QualityStage plug-in stage in DataStage jobs, the jobs will need to be edited after they are migrated to the Version 8.5 installation. To run these jobs after migration, you must configure the jobs to use the available stages in Version 8.5. The QualityStage plug-in is not available or supported in Version 8.5. QualityStage 7 provides a method to migrate QualityStage 7 jobs, match specifications, and standardization rule sets to the InfoSphere DataStage and QualityStage Designer client in the Version 8.5 environment. In legacy mode your migrated job will use the QualityStage Legacy stage. In expanded form, your migrated job will make full use of all the specialized data quality stage types as well as the QualityStage Legacy stage. If you are migrating to a platform that was supported by QualityStage 7, then you can migrate by using legacy mode or expanded form. If the platform was not supported for QualityStage 7, then only expanded mode migration is available, and any QualityStage Legacy stage types in the migrated job must be replaced. The migration utility uses information in the QualityStage 7 server project directory to build the .dsx file format that InfoSphere DataStage and QualityStage requires to import jobs. The migration utility migrates the following QualityStage 7 objects: v Standardization rule set v Jobs in full legacy operational mode v Jobs in expanded form, in which some legacy operations are replaced by InfoSphere DataStage and QualityStage, Version 8.5 stages v Match specification You export projects to create a .dsx file that contains migrated jobs, rule sets, and match specifications in the Temp directory in the QualityStage 7 project directory.
Job migration in legacy operational mode

When you migrate QualityStage 7 jobs in full legacy operational mode, the original job is replaced with a single instance of a QualityStage Legacy stage and Sequential File stages linked as source and target stages. If you migrate a QualityStage 7 job in legacy operational mode, you can make only minor changes to the resulting QualityStage Legacy stage. Use this option only for stable jobs that will not be modified or jobs that are due to be replaced.
87
IBM Confidential
Note that, in a Japanese environment, the migrated job uses Data Set stages instead of Sequential File stages. In this case, you must create an additional job that reads the source data from the sequential file and writes it to a data set. The data set can then be read by the migrated job. If your original job wrote results to a sequential file, then you must create another job to write the results from the data set produced by the migrated job to a sequential file. Do not use the legacy operational mode option if you are migrating a job that contains the following QualityStage 7 stages because their functionality is not supported by the QualityStage Legacy stage: v Postal stages such as CASS and SERP v v v v Program stage Multinational Standardize stage WAVES stage Format Convert stage
QualityStage job migration in expanded form

When you migrate a QualityStage 7 job in expanded form, the QualityStage migration utility replaces the original job with one or more parallel job stages for each stage in the QualityStage 7 job, and with Sequential File stages that are linked together to represent the QualityStage 7 job flow. A job migrated in expanded form might have a mixture of data quality, processing, and Legacy stages when you open the job in the Designer client. For complex jobs, you can move the stages around on the canvas to make the job more intelligible. You can also replace a QualityStage Legacy stage with a data quality stage that has equivalent functions.
Rule set migration

The migration of a QualityStage 7 standardization rule set option migrates the rule sets explicitly by name. When a QualityStage 7 job is migrated, the migration utility detects the dependent rule sets and displays them. You can then choose to include the rule sets in the .dsx file with the job. The migration utility renames the rule sets within the .dsx file to prevent a naming duplication with a built-in IBM InfoSphere QualityStage, Version 8.5 rule set. The utility uses the following naming convention:
QS-7-Ruleset-Name_QS-7-Project-Name
Match specification migration

When you migrate a QualityStage job that contains match and unduplicate stages, the Match specifications are migrated with the job. The QualityStage migration utility includes the match processing information in the .dsx file with the job, if you selected the option "plus dependencies" to migrate the job. Once the job is imported, you can locate the match specification in the IBM InfoSphere DataStage and QualityStage Repository Match Specifications folder.
88
IBM Confidential
As with rule sets, match specifications are renamed when the information is imported. The match specification name has the following form:
QS-7-RefMatch-or-UndupMatch-Stage-Name_QS-7-Project-Name
Installing the WebSphere QualityStage migration utility

Use the WebSphere QualityStage migration utility to migrate QualityStage Version 7 to IBM InfoSphere QualityStage, Version 8.5. (The term 'QualityStage 7' refers to all releases between 7.0 and 7.5.) Installs the QualityStage migration utility on your source installation. 1. Choose one of the following options, depending on operating system type and whether you want to install the IBM InfoSphere DataStage and QualityStage server on the same computer as the QualityStage 7 server.
Option Installing the InfoSphere DataStage and QualityStage server on the same computer as the QualityStage 7 server Description Install IBM Information Server, installing the engine tier on the computer where the QualityStage 7 server is installed. The migration utility is installed with the engine tier. Install IBM Information Server on the target computer. The migration utility is installed with the engine tier. Before you run the migration utility on the target computer, make the QualityStage 7 project metadata available to the target computer. Make the metadata available by copying the entire QualityStage 7 project directory and all its contents to the target computer, or by making the directory available via the network (for example, by mapping a drive on Windows).
Installing the InfoSphere DataStage and QualityStage server on a different computer from the QualityStage 7 server (Windows or UNIX or Linux)
2. If you are migrating from a Unicode-enabled version of QualityStage Version 7, make the following changes to the qsmig.env file (located in the directory where the migration tool is installed). Make the changes before you use the migration utility. v Change the line, FLDEXTPR=0 to FLDEXTPR=1 v For the Japanese language, add the line, QSLCHARSET="CP932" v For the Chinese language, add the line QSLCHARSET="CP936" 3. On Windows, if the QualityStage Version 7 project directories are on a different drive from the migration utility, add the following line to the qsmig.env file: v APPCLIB=${PROJ}/Controls After you install the QualityStage migration utility, you can migrate QualityStage Version 7 jobs to InfoSphere DataStage and QualityStage, Version 8.5.
Running the QualityStage migration utility

Run the migration utility to create a file that contains the project metadata that is stored on a QualityStage 7 server.
89
IBM Confidential
The QualityStage migration utility runs on UNIX and Linux. For Windows, the script requires the MKS (Mortice Kerns Systems) Toolkit. The MKS toolkit is installed with the IBM InfoSphere Information Server client. The QualityStage migration utility is automatically installed when you install the InfoSphere DataStage and QualityStage component of the suite. By default, the QualityStage migration utility is in the /opt/IBM/InformationServer/Server/ PXEngine/bin directory on a UNIX or Linux computer or C:\IBM\ InformationServer\Server\PXEngine\bin on a Windows computer. 1. Ensure that the QualityStage project metadata is accessible from the computer on which the migration utility is installed. 2. From the migration utility directory, run the script to start the utility. v On UNIX or Linux computers, enter ./qsmigrate.sh. v On Windows, double-click the qsmigrate.bat file. 3. When prompted, enter the full path name of the QualityStage 7 project directory that contains the jobs that you want to migrate. The utility returns a list of the jobs and rule sets in the project. 4. Enter the number of an option from the list of options. 5. Select one of the following procedures, depending on the migration option that you selected:
Option 1. Migrate multiple QualityStage 7.x jobs plus dependencies OR 2. Migrate multiple QualityStage 7.x jobs in expanded form plus dependencies Steps for options 1. Enter a name for the output file that the migration utility produces. All the objects that you migrate are written to this file. The utility reports the path name of this file each time it informs you of the success or failure of an object migration. 2. When prompted with a job name, enter Y to migrate that job or N to skip that job. Repeat this step until you have migrated or skipped all the jobs. 3. When prompted with the name of a rule set or a match specification, enter Y to migrate that object or N to skip that object. Repeat this step until you have migrated or skipped all the objects. 3. Migrate individual QualityStage 7.x job OR 4. Migrate individual QualityStage 7.x job in expanded form 5. Migrate individual QualityStage 7.x job plus dependencies OR 6. Migrate individual QualityStage 7.x job in expanded form plus dependencies 1. When prompted, enter the name of the job that you want to migrate. The output file name is derived from the job name. 2. When prompted with the name of a rule set or a match specification, enter Y to migrate that object or N to skip that object. Repeat this step until you have migrated or skipped all the objects When prompted, enter the name of the job that you want to migrate. The output file name is derived from the job name.
90
IBM Confidential Option 7. Migrate individual QualityStage 7.x standardization rule set Steps for options When prompted, enter the name of the rule set or match specification that you want to migrate. The output file name is derived from this name.
The QualityStage migration utility places the .dsx files that it creates in the Temp directory under the project directory. After you complete the migration of all of your jobs and objects, move the .dsx files to the computer where the Version 8.5 IBM InfoSphere DataStage and QualityStage client is installed.
Importing the migrated files into the Version 8.5 Designer client
After you complete the file migration, you must import the files into the metadata repository. Imports the contents of the migrated files into the Designer client. The QualityStage clients in 7.5.3 and earlier are referred to as InfoSphere DataStage and QualityStage clients in Version 8.5. 1. Move the .dsx file or files that you created when you ran the migration script to the computer where theInfoSphere DataStage and QualityStage clients are installed. 2. Open the Designer client and attach to the project where you want to save the InfoSphere DataStage and QualityStage jobs. 3. Select Import DataStage Components. 4. Specify the name of the migration file and click OK. The migrated jobs, rules sets, and match specifications are saved in the following folders: v Project_name Jobs folder. v Project_name Standardization Rules Imported Rules Rule Sets folder. v Project_name Match Specifications folder.
Provisioning imported rule sets

You need to provision imported rule sets from the Designer client before a job that uses them can be compiled. Provisions the imported rule sets. 1. In the Designer client, find the rule set within the repository tree Project Standardization Rules Imported Rules Rule Sets folder. 2. Select the rule set. 3. Right-click and select Provision All from the menu. You can compile and run any job that uses the rule set, except for migrated jobs that used the expanded mode to migrate. If you used the expanded form, read the instructions for preparing migrated jobs in the expanded format.
Preparing imported match specifications for use

You need to save the imported match specification in the InfoSphere DataStage and QualityStage Designer client and then provision the specification before you can use it in a job. Prepares imported match specifications for use.
91
IBM Confidential
1. In the Designer client, find the match specification within the repository tree Project Match Specifications folder. 2. Select the match specification and double-click to open the Match Designer. 3. Select Save All Passes. 4. Select Save Specification. 5. Click OK to close the Match Designer. 6. From the repository, select the match specification. 7. Right-click the match specification and select Provision All from the menu. You can now use the match specification in a Match job.
Preparing migrated QualityStage jobs for operation

You must prepare migrated jobs before they can be run. The steps can vary depending on the migration option that you selected. For jobs that you migrated in Legacy operational mode (options 1, 3, or 5), compile the job to prepare it. Prepares migrated jobs for operation in the target installation. 1. Double-click the job in the Designer client repository tree to open it on the Designer canvas. When you run the migrated job, the results will vary depending on how you ran the job in previous versions of QualityStage. If you used any mode other than the parallel extender mode, the results might be significantly different from previous runs. 2. If you did not previously run the job in parallel extender mode, insert a sort operation into the job design: a. Double-click the target Sequential File stage to open the Input Partitioning page. b. Select Sort Merge from the Collector type list. c. Under the Sorting section, click Perform sort. 3. Click OK to close the window. 4. Select File Compile to compile the job.
Preparing migrated jobs in the expanded format

You must prepare jobs migrated in expanded format before they can be run. Prepares jobs migrated in expanded format. 1. Double-click the job in the Designer client repository tree view to open it. The job contains both QualityStage Legacy stages and Data Quality stages. 2. If you have Standardize, Survive, MNS, or WAVES stages, double-click each stage to open it and then click OK. 3. Review any migration warnings that are displayed at the bottom of the job and resolve these issues. 4. Save the job. 5. Select File Compile. When you run the migrated job, the results will vary depending on how you ran the job in previous versions of QualityStage. If you used any mode other than the parallel extender mode, the results might be significantly different from previous runs. 6. If you did not previously run the job in parallel extender mode, insert a sort operation into the job design:
92
IBM Confidential
a. Double-click the target Sequential File stage to open the Input Partitioning page. b. Select Sort Merge from the Collector type list. c. Under the Sorting section, click Perform sort. 7. Optional: Replace QualityStage Legacy stages with the equivalent data quality or processing stage. a. Double-click the QualityStage Legacy stage to open the Properties window. b. Find the stage that offers functionality that is equivalent to the Legacy stage functionality from the Data Quality section of the palette. c. Substitute the QualityStage Legacy stage with the equivalent data quality stage or stages. To optimize your job, it is more efficient to replace the QualityStage Legacy stages. d. Configure the new stage or stages. e. Compile the job.
Preparing migrated jobs to use updated Address Verification Interface and SERP libraries
The IBM InfoSphere QualityStage, Version 8.5 includes updated libraries for the Address Verification Interface and SERP modules. You must update the migrated jobs to use these updated libraries before they can be run. For details on the new output columns and how to update the migrated jobs, see the release notes for the InfoSphere QualityStage modules.
Migrating real-time QualityStage jobs from Release 7 to Version 8.5

To migrate Version 7 jobs that use the IBM InfoSphere QualityStage Real Time Client API, you run the migration utility, replace legacy stages, and publish the job as a service. Before you publish real-time jobs as services, you must complete the following tasks: v Install IBM InfoSphere Information Services Director, which is a component of IBM InfoSphere Information Server. Unlike version 7, Version 8.5 requires that you use InfoSphere Information Services Director to publish jobs as services. For more information about installing InfoSphere Information Server, see IBM InfoSphere Information Server Planning, Installation, and Configuration Guide. Migrates jobs in expanded form. 1. Migrate the job by running the migration utility in expanded form. 2. Replace the legacy stages with appropriate stages according to the table of replacement stages. 3. If your migrated job contains more than one input stage and more than one output stage, reconfigure your job to reduce the number of inputs and outputs. Alternately, you can reconfigure a job with more than one input to align with the behavior of the real-time stages. For more information about creating real-time jobs with two input sources InfoSphere DataStage and QualityStage, see IBM InfoSphere Information Services Director User Guide. A job can have only one ISD Input stage and only one ISD Output stage. 4. Update your jobs to add the ISD Output and ISD Input stages to replace the sequential input and output stages that exist in the migrated jobs.
93
IBM Confidential
5. Use InfoSphere Information Services Director to connect to InfoSphere QualityStage. For more information about connecting to InfoSphere DataStage and QualityStage, see IBM InfoSphere Information Services Director User Guide. 6. Develop an application, service, and operation by using InfoSphere Information Services Director. Your migrated real-time job is the information provider for the operation of the service. For more information about developing applications, services, and operations, see IBM InfoSphere Information Services Director User Guide. 7. Deploy the application as a service. For more information about deploying applications, see IBM InfoSphere Information Services Director User Guide.
Replace InfoSphere QualityStage 7 data quality stages

You can use the table of replacement stages to select the InfoSphere DataStage stage to substitute for the QualityStage 7 stage. The following table lists replacement stages for previous versions of QualityStage stages.
Table 15. Replacement InfoSphere DataStage and QualityStage stages for migrated QualityStage stages. QualityStage 7 Abbreviate Purpose Creates match keys from company names. Replacement stage No direct replacement. Use the Standardize stage to reformat company names and pair with an appropriate match.
Build
Rebuilds a single record from No direct replacement. Build was multiple records that are often used with Parse to analyze created with a Parse stage. multi-domain data fields. Use Standardize to accomplish the same function in one step. Generates a list of each unique value in single-domain data fields. Sort stage
Collapse
Collapse
Generates frequency counts of Aggregate stage data values in a field or a group of fields. Reformats files from delimited to fixed-length and vice versa. Provides I/O to an ODBC database. Analysis of data quality. Sequential File stage
Format Convert
Format Convert Investigate
ODBC stage or database specific stage Investigate stage and the Reporting tab for the WebConsole for IBM Information Server.
Match
Identifying data duplicates in Unduplicate Match stage in a single file by using fuzzy conjunction with the Match Frequency stage. match logic. Pairing records from one file with those in another by using fuzzy match logic. Standardize multinational address data. Reference Match stage in conjunction with the Match Frequency stage. MNS stage
Match
Multinational Standardize
94
IBM Confidential Table 15. Replacement InfoSphere DataStage and QualityStage stages for migrated QualityStage stages. (continued) QualityStage 7 Parse Purpose Tokenizes a text field by resolving free-form text fields into fixed-format records that contain individual data elements. Invokes a customer-written program. Replacement stage No direct replacement. Parse was often used with Build to analyze multi-domain data fields. Use the Standardize stage to accomplish the same function in one step. Depends on the functionality of the customer-written program. Possibilities include adding a Parallel Build, Custom, or Wrapped stage type. Switch and Filter stages
Program
Select
Conditionally routes records that are based on values in selected fields. Sorts a list. Breaks down multi-domain data columns into a set of standardized single-domain columns. Produces the best results record from a group of related records. Rearranges and reformats columns in a record. Acts as a gatekeeper for files in non-standard formats (variable length records, non-standard code page, binary or packed data). Produces multiple output records from a single input record. Adds record keys that consists of sequence number plus an optional fixed "file identifier." Join records from two files based on a key. Pairing records from one file with those in another by using fuzzy match logic. Merges data from multiple records into one. Manipulate and transform data record. Standardize and validate multinational address data.
Sort Standardize
Sort stage Standardize stage
Survive
Survive stage
Transfer Transfer
No separate stage is required to do this in QualityStage 8. Sequential File or Complex Flat File stage
Transfer
Splitting records can be achieved by Copy stage followed by Funnel stage Surrogate Key Generator stage
Transfer
Unijoin Unijoin
Join stage or Lookup stage Reference Match stage in conjunction with Match Frequency stage. Join stage and Merge stage Transformer stage WAVES stage
Unijoin Unijoin WAVES
95
IBM Confidential
96
IBM Confidential
Chapter 11. Migration from IBM WebSphere RTI 7.5, 7.5.1, and 7.5.2 installations
Use the WebSphere RTI Export Wizard to migrate from WebSphere RTI 7.5, 7.5.1, and 7.5.2 installations to an IBM InfoSphere Information Services Director, Version 8.5 installation. After migration, you can use one of the following methods to administer and deploy InfoSphere Information Services Director: v InfoSphere Information Services Director command line interface v IBM InfoSphere Information Server console
Migrating RTIX files to Version 8.5

Use the WebSphere RTI Export Wizard to migrate to IBM InfoSphere Information Services Director, Version 8.5 installations. Use the WebSphere RTI Export Wizard to migrate from IBM WebSphere RTI 7.5, 7.5.1, and 7.5.2 installations to InfoSphere Information Services Director, Version 8.5 installations. 1. Halt WebSphere RTI. 2. Use the WebSphere RTI Export Wizard on the source computer to create an RTIX file. This RTIX file contains descriptions of operations and services. 3. Move the RTIX file to the Version 8.5 computer. 4. Use the IBM InfoSphere Information Server console Import function to import the RTIX file. This imported file is the equivalent of the output of the console design function. 5. You must associate the imported service descriptions with an application object before you can deploy the services. The import function is done at the application level to create this association. The imported service description is the equivalent of a service that is designed in InfoSphere Information Server. You can deploy the service description like any natively designed information service.
97
IBM Confidential
98
IBM Confidential
Part 4. Client-only upgrades
99
IBM Confidential
100
IBM Confidential
Chapter 12. Upgrading a client tier-only installation to Version 8.5

Use the IBM InfoSphere Information Server installation program to upgrade existing client tier computers to Version 8.5. Before you run the installation program: v Complete the preparation steps that are described in "Preparing to run the installation program" in the IBM InfoSphere Information Server Planning, Installation, and Configuration Guide. v If you are installing Metabrokers and bridges, remove any existing installations of MetaBrokers and bridges from the target computer before you run the InfoSphere Information Server installation program. v See "Configuring your browser" in the Installation Guide to ensure that your Web browser is configured properly. The installation program directly upgrades InfoSphere Information Server client software to Version 8.5. To upgrade client software directly by using the installation program, InfoSphere Information Server server-side software must not be installed on the computer. The installation program cannot directly upgrade the server-side software, or client software on a computer that also contains server-side software. To upgrade a computer that includes server-side software, you must create a new installation of InfoSphere Information Server, Version 8.5 that includes the client tier. To retain existing client versions, you must select a different installation directory location for Version 8.5. You can upgrade your client software at any time before, during, or after installing the server-side software on other computers. To upgrade a client tier-only computer, use one of the following two scenarios: v Manually uninstall existing client versions and install new client versions. Note: If you choose to manually remove existing client software, be sure to follow the documented procedure for your installation version to completely remove the software, restart the computer, and then use the Version 8.5 installation software to install the Version 8.5 client software. v Automatically upgrade the existing client versions on a client tier-only computer by using the following procedure. Procedure 1. Start the installation program in graphical mode as described in "Starting the installation program in graphical mode" in the Installation Guide. 2. Follow the prompts in the wizard as they appear. When the installation program detects that the target directory contains a client installation, confirm that you want to upgrade the installation. The current client installation is uninstalled. Note: To retain your existing client versions, you must select a different installation directory location for Version 8.5 to ensure that your existing versions remain intact.
101
IBM Confidential
When the installation program has collected your settings, it saves a response file for you. This file is a text file that contains the settings that you made in the previous pages. When you run the installation program again, you can load the settings into the program instead of manually selecting them again. Note: Passwords are not saved in the response file. You must edit the response file by using a text editor to add passwords. Based on your settings, the installation program runs a prerequisites check. During this check, it analyzes the resources and file system of the computer to determine whether the new client installation is likely to succeed. The wizard page displays each check. If the prerequisites check fails, it is marked FAILED for the corresponding items. 3. If you receive a FAILED message, double-click the message to learn more about resolving it. Try to resolve the issue without exiting the installation program. If you believe that you solved the problem, click Check Again in the Prerequisites Check page. If it is necessary to exit the installation program, click Cancel and close the browser window. Resolve the issue and then restart the installation program. 4. The installation program summarizes your settings and then begins the installation. 5. Monitor the installation as described in "Installation progress monitoring" in the Installation Guide. Leave the terminal window open until the installation is complete. Note: During the installation process, the installation process might occasionally request a response from you. Check periodically to make sure that the system is not waiting for you to respond. The installation process might fail if the installation process halts for a long time. 6. After the installation is completed, install the correct Microsoft XML Core Services (MSXML) Service Pack. 7. Repeat the upgrade process for each client computer. If the installation fails: 1. View the installation logs for more information. See "Log files" in the Installation Guide. 2. Resolve any issues that are listed in the installation log files. 3. Remove the installation directory structure and the installation log file.
Windows Restart the computer. 4. 5. Run the installation program again.
Client tier computers that include DataStage client software include the Version 8.5 Multi-client Manager. After Version 8.5 is installed, use Version 8.5 is the active version. To use an earlier version of the client software, use the Version 8.5 Multi-client Manager.
102
IBM Confidential
Part 5. Appendixes
103
IBM Confidential
104
IBM Confidential
Product accessibility
You can get information about the accessibility status of IBM products. The IBM InfoSphere Information Server product modules and user interfaces are not fully accessible. The installation program installs the following product modules and components: v IBM InfoSphere Business Glossary v IBM InfoSphere Business Glossary Anywhere v IBM InfoSphere DataStage v IBM InfoSphere FastTrack v v v v IBM IBM IBM IBM InfoSphere InfoSphere InfoSphere InfoSphere Information Analyzer Information Services Director Metadata Workbench QualityStage
For information about the accessibility status of IBM products, see the IBM product accessibility information at http://www.ibm.com/able/product_accessibility/ index.html.
Accessible documentation
Accessible documentation for InfoSphere Information Server products is provided in an information center. The information center presents the documentation in XHTML 1.0 format, which is viewable in most Web browsers. XHTML allows you to set display preferences in your browser. It also allows you to use screen readers and other assistive technologies to access the documentation.
IBM and accessibility

See the IBM Human Ability and Accessibility Center for more information about the commitment that IBM has to accessibility.
105
IBM Confidential
106
IBM Confidential
Accessing product documentation

Documentation is provided in a variety of locations and formats, including in help that is opened directly from the product client interfaces, in a suite-wide information center, and in PDF file books. The information center is installed as a common service with IBM InfoSphere Information Server. The information center contains help for most of the product interfaces, as well as complete documentation for all the product modules in the suite. You can open the information center from the installed product or from a Web browser.
Accessing the information center

You can use the following methods to open the installed information center. v Click the Help link in the upper right of the client interface. Note: From IBM InfoSphere FastTrack and IBM InfoSphere Information Server Manager, the main Help item opens a local help system. Choose Help > Open Info Center to open the full suite information center. v Press the F1 key. The F1 key typically opens the topic that describes the current context of the client interface. Note: The F1 key does not work in Web clients. v Use a Web browser to access the installed information center even when you are not logged in to the product. Enter the following address in a Web browser: http://host_name:port_number/infocenter/topic/ com.ibm.swg.im.iis.productization.iisinfsv.home.doc/ic-homepage.html. The host_name is the name of the services tier computer where the information center is installed, and port_number is the port number for InfoSphere Information Server. The default port number is 9080. For example, on a Microsoft Windows Server computer named iisdocs2, the Web address is in the following format: http://iisdocs2:9080/infocenter/topic/ com.ibm.swg.im.iis.productization.iisinfsv.nav.doc/dochome/ iisinfsrv_home.html. A subset of the information center is also available on the IBM Web site and periodically refreshed at http://publib.boulder.ibm.com/infocenter/iisinfsv/v8r5/ index.jsp.
Obtaining PDF and hardcopy documentation

v PDF file books are available through the InfoSphere Information Server software installer and the distribution media. A subset of the PDF file books is also available online and periodically refreshed at www.ibm.com/support/ docview.wss?rs=14&uid=swg27016910. v You can also order IBM publications in hardcopy format online or through your local IBM representative. To order publications online, go to the IBM Publications Center at http://www.ibm.com/e-business/linkweb/publications/ servlet/pbi.wss.
107
IBM Confidential
Providing feedback about the documentation

You can send your comments about documentation in the following ways: v Online reader comment form: www.ibm.com/software/data/rcf/ v E-mail: comments@us.ibm.com
108
IBM Confidential
Reading command-line syntax

This documentation uses special characters to define the command-line syntax. The following special characters define the command-line syntax: [] ... | Identifies an optional argument. Arguments that are not enclosed in brackets are required. Indicates that you can specify multiple values for the previous argument. Indicates mutually exclusive information. You can use the argument to the left of the separator or the argument to the right of the separator. You cannot use both arguments in a single use of the command. Delimits a set of mutually exclusive arguments when one of the arguments is required. If the arguments are optional, they are enclosed in brackets ([ ]).
{}
Note: v The maximum number of characters in an argument is 256. v Enclose argument values that have embedded spaces with either single or double quotation marks. For example: wsetsrc[-S server] [-l label] [-n name] source The source argument is the only required argument for the wsetsrc command. The brackets around the other arguments indicate that these arguments are optional. wlsac [-l | -f format] [key... ] profile In this example, the -l and -f format arguments are mutually exclusive and optional. The profile argument is required. The key argument is optional. The ellipsis (...) that follows the key argument indicates that you can specify multiple key names. wrb -import {rule_pack | rule_set}... In this example, the rule_pack and rule_set arguments are mutually exclusive, but one of the arguments must be specified. Also, the ellipsis marks (...) indicate that you can specify multiple rule packs or rule sets.
109
IBM Confidential
110
IBM Confidential
Links to non-IBM Web sites

This information center may provide links or references to non-IBM Web sites and resources. IBM makes no representations, warranties, or other commitments whatsoever about any non-IBM Web sites or third-party resources (including any Lenovo Web site) that may be referenced, accessible from, or linked to any IBM site. A link to a non-IBM Web site does not mean that IBM endorses the content or use of such Web site or its owner. In addition, IBM is not a party to or responsible for any transactions you may enter into with third parties, even if you learn of such parties (or use a link to such parties) from an IBM site. Accordingly, you acknowledge and agree that IBM is not responsible for the availability of such external sites or resources, and is not responsible or liable for any content, services, products or other materials on or available from those sites or resources. When you access a non-IBM Web site, even one that may contain the IBM-logo, please understand that it is independent from IBM, and that IBM does not control the content on that Web site. It is up to you to take precautions to protect yourself from viruses, worms, trojan horses, and other potentially destructive programs, and to protect your information as you deem appropriate.
111
IBM Confidential
112
IBM Confidential
Notices and trademarks

This information was developed for products and services offered in the U.S.A.
Notices
IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not grant you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A. For license inquiries regarding double-byte character set (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to: Intellectual Property Licensing Legal and Intellectual Property Law IBM Japan Ltd. 1623-14, Shimotsuruma, Yamato-shi Kanagawa 242-8502 Japan The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web
113
IBM Confidential
sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact: IBM Corporation J46A/G4 555 Bailey Avenue San Jose, CA 95141-1003 U.S.A. Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee. The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us. Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurements may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. All statements regarding IBM's future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only. This information is for planning purposes only. The information herein is subject to change before the products described become available. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to
114
IBM Confidential
IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. The sample programs are provided "AS IS", without warranty of any kind. IBM shall not be liable for any damages arising out of your use of the sample programs. Each copy or any portion of these sample programs or any derivative work, must include a copyright notice as follows: (your company name) (year). Portions of this code are derived from IBM Corp. Sample Programs. Copyright IBM Corp. _enter the year or years_. All rights reserved. If you are viewing this information softcopy, the photographs and color illustrations may not appear.
Trademarks
IBM, the IBM logo, and ibm.com are trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at www.ibm.com/legal/copytrade.shtml. The following terms are trademarks or registered trademarks of other companies: Adobe is a registered trademark of Adobe Systems Incorporated in the United States, and/or other countries. IT Infrastructure Library is a registered trademark of the Central Computer and Telecommunications Agency which is now part of the Office of Government Commerce. Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office UNIX is a registered trademark of The Open Group in the United States and other countries. Cell Broadband Engine is a trademark of Sony Computer Entertainment, Inc. in the United States, other countries, or both and is used under license therefrom.
Notices and trademarks
115
IBM Confidential
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. The United States Postal Service owns the following trademarks: CASS, CASS Certified, DPV, LACSLink, ZIP, ZIP + 4, ZIP Code, Post Office, Postal Service, USPS and United States Postal Service. IBM Corporation is a non-exclusive DPV and LACSLink licensee of the United States Postal Service. Other company, product or service names may be trademarks or service marks of others.
116
IBM Confidential
Contacting IBM
You can contact IBM for customer support, software services, product information, and general information. You also can provide feedback to IBM about products and documentation. The following table lists resources for customer support, software services, training, and product and solutions information.
Table 16. IBM resources Resource IBM Support Portal Description and location You can customize support information by choosing the products and the topics that interest you at www.ibm.com/support/ entry/portal/Software/ Information_Management/ InfoSphere_Information_Server You can find information about software, IT, and business consulting services, on the solutions site at www.ibm.com/ businesssolutions/ You can manage links to IBM Web sites and information that meet your specific technical support needs by creating an account on the My IBM site at www.ibm.com/account/ You can learn about technical training and education services designed for individuals, companies, and public organizations to acquire, maintain, and optimize their IT skills at http://www.ibm.com/software/swtraining/ You can contact an IBM representative to learn about solutions at www.ibm.com/connect/ibm/us/en/
Software services
My IBM
Training and certification
IBM representatives
Providing feedback
The following table describes how to provide feedback to IBM about products and product documentation.
Table 17. Providing feedback to IBM Type of feedback Product feedback Action You can provide general product feedback through the Consumability Survey at www.ibm.com/software/data/info/ consumability-survey
117
IBM Confidential Table 17. Providing feedback to IBM (continued) Type of feedback Documentation feedback Action To comment on the information center, click the Feedback link on the top right side of any topic in the information center. You can also send comments about PDF file books, the information center, or any other documentation in the following ways: v Online reader comment form: www.ibm.com/software/data/rcf/ v E-mail: comments@us.ibm.com
118
IBM Confidential
Index A
Abbreviate stage replacing QualityStage legacy 94 Administrator client, Version 8.5 importing 7.5.3 and earlier DataStage projects 78 advanced migration application server 47 archive parameter ismigration tool export command syntax 28 ismigration tool import command syntax 29 connect to Version 7.5.3 and earlier Designer, Manager, and Director clients 84 conversion script QualityStage migration utility 92 creating migration.properties file 22 customer support contacting 117 Designer and Director clients connecting to multiple servers on Version 8.5 85 Designer client compiling jobs and routines 80 exporting projects before migration from 7.5.3 and earlier 74 importing 7.5.3 and earlier DataStage projects 78 importing files after migrating from 7.5.3 and earlier 91 importing migrated files (QualityStage) 91 importing projects to 78 installing multiple versions with Multi-Client Manager 83 recompiling DataStage jobs for 80 restoring hashed files after migration from 7.5.3 and earlier 79 Designer Manager client exporting projects before migration from 7.5.3 and earlier 74 different versions of clients switching between 81 Director client using to restore hashed files 79 directories default for ismigration tool 51 dscmdexport command exporting DataStage 7.5.3 and earlier projects 74 dsenv environment variable saving DataStage 7.5.3 and earlier 75 DSHOME environment variable saving DataStage 7.5.3 and earlier 75 dsjob command using to connect to a Version 8.5 after migration 86 DSParams file saving DataStage 7.5.3 and earlier, Linux and UNIX 75 saving DataStage 7.5.3 and earlier, Windows 75
D
database requirements ismigration tool 19 DataStage 7.5.3 and earlier export using command line 74 export using Manager client 73 importing projects to Version 8.5 78 job dependencies, moving 76 legacy projects, exporting 73 moving schema files 76 saving setting files 75 DataStage Administrator client importing 7.5.3 and earlier DataStage projects 78 DataStage client uninstalling 77 DataStage Designer client compiling jobs and routines 80 exporting projects before migration from 7.5.3 and earlier 74 importing files after migrating from 7.5.3 and earlier 91 installing multiple versions with Multi-Client Manager 83 restoring hashed files after migration from 7.5.3 and earlier 79 DataStage projects completing migration 48 DataStage servers attaching to multiple 84 connecting to DataStage Version 7.5.3 and earlier 84 connecting to multiple 84 uninstalling Linux and UNIX 77 uninstalling Windows 77 datastage.engine.admin.password property for ismigration tool 52 datastage.engine.admin.username property for ismigration tool 52 datastage.engine.asbhome property for ismigration tool 52 datastage.engine.enginepath property 52 datastage.engine.update.project property 52 default directories ismigration tool 51
B
bin directory ismigration tool 51 Build stage replacing QualityStage legacy 94
C
client tiers upgrading client-only installation 101 Collapse stage replacing QualityStage legacy 94 command line interface connecting to DataStage 7.5.3 and earlier projects 86 exporting DataStage 7.5.3 and earlier projects 74 command syntax ismigration tool export command syntax 28 ismigration tool import command syntax 29 command-line syntax conventions 109 commands syntax 109 commands, ismigration tool encryption tool for passwords 31 export 28 import 29 restart 30 compile DataStage 7.5.3 and earlier jobs after migration 80 DataStage 7.5.3 and earlier routines after migration 80 conf directory ismigration tool 51 config parameter ismigration tool export command syntax 28 ismigration tool import command syntax 29
E
edit host change file for topology changes 46 encrypt passwords 22 encryption ismigration tool 31 enterprise packs verify availability on Version 8.5 25 expanded job migration QualityStage 7.5.3 and earlier 88 export about DataStage 7.5.3 and earlier projects 73
119
IBM Confidential
export (continued) DataStage 7.5.3 and earlier projects using Manager client 74 ismigration tool command syntax 28 ismigration tool export command syntax 28 using ismigration tool 34 ia.gendb.directory property for ismigration tool 52 ia.gendb.enabled property for ismigration tool 52 when to use 45 ia.keep.analysisdb.options property for ismigration tool 52 ia.keep.analysisengine.options property for ismigration tool 52 ia.oracle.datadumpfolder property for ismigration tool 52 ia.oracle.datafilefolder property for ismigration tool 52 ia.oracle.datafilepath property for ismigration tool 52 ia.oracle.sys.password property for ismigration tool 52 ia.oracle.sys.servicename property for ismigration tool 52 ia.oracle.sys.username property for ismigration tool 52 ia.oracle.tablespacename property for ismigration tool 52 ia.sqlserver.datafolder property for ismigration tool 52 import about ismigration tool 37 importing 7.5.3 and earlier DataStage projects 78 importing Version 7.5.3 and earlier QualityStage jobs 91 ismigration tool import command syntax 29 using ismigration tool 40 ini files saving DataStage 7.5.3 and earlier 75 install client-only installation 101 ITAG, multiple servers 81 Version 8.5 on target installation for ismigration tool 37 installation environment validate using ismigration tool 34, 37 installismigration tool 33 interface ismigration tool 27 Investigate stage replacing QualityStage legacy 94 is.migration.leaveworkdir property for ismigration tool 52 is.migration.skipvalidation property for ismigration tool 52 is.suite.admin.password property for ismigration tool 52 is.suite.admin.username property for ismigration tool 52 is.websphere.admin.password property for ismigration tool 52 is.websphere.admin.username property for ismigration tool 52 ISA Lite information for migration 21 ismigration directories conf 51 logs 51 ismigration tool completing to do activities 35, 41 ismigration tool (continued) exporting 34 exporting source installation 34 importing 40 log files 66 manual application server configuration 47 properties file 52 requirements and restrictions 19 user interface 27 userfiles 65 ismigration tool syntax import command 29 ITAG installation migrating multiple DataStage servers 83 iTag installations multiple servers Linux, UNIX 81
F
files .ini, saving DataStage 7.5.3 and earlier 75 DSParams, saving DataStage 7.5.3 and earlier 75 HostChangeConfig.xml for ismigration tool 64 log for ismigration tool 66 migration.properties for ismigration tool 52 migration.todo.txt for ismigration tool 66 odbc.ini, saving DataStage 7.5.3 and earlier 75 userfiles for ismigration tool 65 uvodbc.config, saving DataStage 7.5.3 and earlier 75 flat files moving DataStage 7.5.3 and earlier 76 Format Convert stage replacing QualityStage legacy 94
J
job migration (QualityStage) legacy 87 match specification 88
L
legacy migration replacing QualityStage Legacy stages 92 legacy migration (QualityStage) QualityStage jobs 87 legacy operational mode QualityStage 7.5.3 and earlier 87 legacy stages QualityStage, replacing 94 legal notices 113 locations, projects ismigration tool host change file 64 log files ismigration tool 66 logs directory ismigration tool 51 logsdirectories 51
G
gen-app-server parameter ismigration tool export command syntax 28 ismigration tool import command syntax 29
H
hashed files importing into Designer client after migration 79 migrating DataStage 7.5.3 and earlier 76 health checker 21 host change file required for topology changes 64 host names changing in host change file, ismigration tool 46 host-change-config parameter ismigration tool import command syntax 29
M
Manager client 74 match specification migration 88 Match stage replacing QualityStage legacy 94 migrated files (QualityStage) importing 91 provisioning 91 migrating hashed files 76 migration client tiers 101 command line interface 27 compiling jobs after 80 DataStage schema files 79 exporting source 33 from release 7.5.3 and earlier 71 from Version 8.0.1 and later 7 host change file 64
I
ia.db2.db.binpath property for ismigration tool 52 ia.db2.installdir property for ismigration tool 52
120
IBM Confidential
migration (continued) ITAG installations 73 overview 8 planning overview 19 process overview 3 QualityStage modules 25 QualityStage v7.5.3 or earlier 87 real-time QualityStage jobs 93 reference topics 51 restart command syntax 30 RTI 7.5.2 and earlier 97 RTI 7.5.3 and earlier 97 scenarios and methodology 3 strategies 3 supported migrations 19 tool user interface 27 verify source credentials 34, 37 migration directories, Version 8.5 bin 51 conf 51 scripts 51 migration from 7.5.3 and earlier DataStage flat files 79 migration from 8.0.1 and later changing topology 46 completing migration for DataStage projects 48 ismigration tool 7 migration utility running QualityStage 90 migration.properties ISA Lite Tool for system summary reports 21 migration.todo.txt file manual activities for ismigration tool 66 migrationfrom 8.0.1 and 8.1 ismigration tool, installing on 8.0.1 and 8.1 33 migrationvalidation, source 23 migrationvalidation, target 38 move ismigration tool files from source to target 36 Multi-client Manager using to switch between different client versions 81 Multi-Client Manager 83 installing multiple DataStage client versions 83 multi-computer migrations 13 Multinational Standardize stage replacing QualityStage legacy 94 multiple DataStage clients connecting to 84 multiple DataStage servers connecting to Version 7.5.1 and earlier 85 connecting to Version 8.5 85 Multiple Job Compile tool for recompiling DataStage jobs 80
O
odbc files saving DataStage 7.5.3 and earlier odbc.ini file saving DataStage 7.5.3 and earlier Oracle databases character encodings 25 overview migration 3 75 75
P
Parse stage replacing QualityStage legacy 94 passwords encryption, for ismigration tool 31 plan migrations 19 port numbers host change file for ismigration tool 64 prepare target installation for ismigration tool 37 product accessibility accessibility 105 product documentation accessing 107 Program stage replacing QualityStage legacy 94 project locations ismigration tool host change file 64 projects (DataStage) exporting 74 properties file migration 52
reference ismigration tool 51 replacing legacy stages QualityStage version 7.5.3 and earlier 94 requirements ismigration tool 19 restart command ismigration tool command syntax 30 restore 7.5.3 and earlier DataStage settings files 78 DataStage 7.5.3 and earlier settings files 78 restrictions ismigration tool 19 RTI 7.5.2 and earlier migration export 97 rule sets, QualityStage migrating 7.5.3 and earlier 88
S
scenarios multiple computers 13 single computer 9 Version 8.0.1 migration 9, 13 scripts ismigration tool 51 Select stage replacing QualityStage legacy 94 settings files restoring DataStage 7.5.3 and earlier files 78 saving DataStage 7.5.3 and earlier 75 single-computer migrations 9 software services contacting 117 Sort stage replacing QualityStage legacy 94 special characters in command-line syntax 109 Standardize stage replacing QualityStage legacy 94 start DataStage 7.5.3 and earlier server 84 stop DataStage 7.5.3 and earlier server 84 strategy migration 3 support customer 117 supported migrations scenarios 19 Survive stage replacing QualityStage legacy 94 syntax command-line 109 system summary 21
Q
QualityStage postmigration activities 48 QualityStage 7.0 to 7.5 job migration legacy form 87 QualityStage 7.5 plug-in rewriting jobs after migration 80 QualityStage 7.5.3 and earlier job migration, expanded form 88 premigration steps for ismigration tool 45 QualityStage migration utility installing 89 UNIX and Linux 90 Windows 90 QualityStage modules verify availability on Version 8.5 25 QualityStage rule sets migrating 7.5.3 and earlier 88 QualityStage stages replacing legacy 94
N
non-IBM Web sites links to 111
R
real-time QualityStage jobs migrating 93
T
target installation moving ismigration tool files 36 preparing to use ismigration tool 37
Index
121
IBM Confidential
to do activities for ismigration tool 35, 41 to-do file ismigration tool manual activities 66 topology changes host change file 46 trademarks list of 113 Transfer stage replacing QualityStage legacy 94 wizards WebSphere RTI Export 97 work parameter ismigration tool export command syntax 28 ismigration tool import command syntax 29
X
xmeta.db.binpath property for ismigration tool 52 xmeta.db2.installdir property for ismigration tool 52 xmeta.gendb.directory property for ismigration tool 52 xmeta.oracle.datadumpfolder property for ismigration tool 52 xmeta.oracle.datafilefolder property for ismigration tool 52 xmeta.oracle.sys.password property for ismigration tool 52 xmeta.oracle.sys.servicename property for ismigration tool 52 xmeta.oracle.sys.username property for ismigration tool 52 xmeta.oracle.tablespacename property for ismigration tool 52 xmeta.sqlserver.datafolder property for ismigration tool 52
U
Unijoin stage replacing QualityStage legacy 94 uninstall DataStage client 77 DataStage server, Windows 77 DataStage servers, Linux and UNIX 77 overview, previous DataStage versions 77 UNIX and Linux installing QualityStage 7 migration utility 89 upgrade client-only installation 101 user interface ismigration tool 27 userfiles migration reference 65 userfiles parameter ismigration tool export command syntax 28 utility QualityStage migration 90 uvodbc.config file saving DataStage 7.5.3 and earlier 75
V
validate source installation criteria 23 target installation criteria 38 using ismigration tool 34, 37 validateonly parameter ismigration tool export command syntax 28 ismigration tool import command syntax 29 using to validate environment 34, 37 Version 8.0.1 and later scenarios 9, 13
W
WAVES stage replacing QualityStage legacy 94 Web sites non-IBM 111 Websphere RTI 7.5.3 and earlier migration 97 Windows installing QualityStage migration utility 89
122
IBM Confidential Printed in USA

Migration Guide To IIS8 5

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Migration Guide To IIS8 5

Cargado por

Copyright:

Formatos disponibles

IBM InfoSphere Information Server

IBM InfoSphere Information Server

Chapter 6. Additional migration tasks for advanced or custom topologies . . 43

Part 2. Version 8.0.1 and later migrations . . . . . . . . . . . . . 5

Chapter 7. Reference: Migration directories and files . . . . . . . . . 51

Chapter 3. Planning for migration . . . 19

Part 3. Version 7.5.3 and earlier migrations . . . . . . . . . . . . 69

Chapter 4. Commands for migration . . 27

Chapter 5. Migrating basic topologies

Copyright IBM Corp. 2006, 2010

Part 4. Client-only upgrades . . . . 99

Chapter 10. Migration from QualityStage 7.5 and earlier releases. . 87

Part 5. Appendixes . . . . . . . . 103

Migrating to IBM InfoSphere Information Server, Version 8.5

Part 1. Overview of migration

Copyright IBM Corp. 2006, 2010

Migrating to IBM InfoSphere Information Server, Version 8.5

Chapter 1. Migrating to IBM InfoSphere Information Server, Version 8.5

DataStage, releases from 7.5.3 and earlier

QualityStage, release 7.5 and earlier

IBM WebSphere RTI 7.5, 7.5.2, and 7.5.1

Copyright IBM Corp. 2006, 2010

Migrating to IBM InfoSphere Information Server, Version 8.5

Part 2. Version 8.0.1 and later migrations

Copyright IBM Corp. 2006, 2010

Migrating to IBM InfoSphere Information Server, Version 8.5

Chapter 2. Overview and scenarios for 8.0.1 and later

Migration from Version 8.0.1 and later

Copyright IBM Corp. 2006, 2010

Overview of the migration process

Migrating to IBM InfoSphere Information Server, Version 8.5

Export to generate the archive files

Import the archive files

Services (domain) tier

Move the archive files

Services (domain) tier

Metadata repository tier

Metadata repository tier

Version 8.0.1 or later Source installation

Version 8.5 Target installation

Figure 1. Migration process overview

Scenario: Migrating a single-computer installation

Metadata repository tier

Metadata repository tier

Version 8.0.1 or later Source installation

Version 8.5 Target installation

Figure 2. Single computer migration

1. Export the 8.0.1 source installation

Migrating to IBM InfoSphere Information Server, Version 8.5

2. Move the archive files

3. Import the 8.0.1 source installation to the 8.5 target installation

Chapter 2. Overview and scenarios for 8.0.1 and later

Migrating to IBM InfoSphere Information Server, Version 8.5

Scenario: Migrating a multi-computer installation

Services (domain) tier

Services (domain) tier

Version 8.0.1 or later Source installation

Version 8.5 Target installation

1. Export the 8.0.1 source installation

Migrating to IBM InfoSphere Information Server, Version 8.5

Example command: C:\IBM\InformationServer\Migration\bin\encrypt.bat <my_password>

Chapter 2. Overview and scenarios for 8.0.1 and later