migration guide to iis8.5

IBM InfoSphere Information ServerVersion 8 Release 5

Migrating to IBM InfoSphereInformation Server, Version 8.5Revised September 17, 2010

SC18-9924

IBM Confidential

��

Edition notice - early release documentationThis document contains proprietary information. All information contained herein shall be kept in confidence. None of thisinformation shall be divulged to persons other than (a) IBM employees authorized by the nature of their duties to receivesuch information, or (b) individuals with a need to know in organizations authorized by IBM to receive this document inaccordance with the terms (including confidentiality) of an agreement under which it is provided. This information mightinclude technical inaccuracies or typographical errors. Changes are periodically made to the information herein; thesechanges will be incorporated in new editions of the publication. IBM may make improvements or changes in the product orthe 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 Contractwith IBM Corp.

IBM Confidential

Contents

Part 1. Overview of migration . . . . 1

Chapter 1. Migrating to IBM InfoSphereInformation Server, Version 8.5 . . . . . 3Migration strategies . . . . . . . . . . . . 3

Part 2. Version 8.0.1 and latermigrations . . . . . . . . . . . . . 5

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

Chapter 3. Planning for migration . . . 19Requirements for ismigration tool . . . . . . . 19Gathering source installation information for themigration.properties file (optional). . . . . . . 21Encrypting passwords . . . . . . . . . . . 22Specifying installation environments inmigration.properties files . . . . . . . . . . 22Source installation requirements for using themigration tool to export . . . . . . . . . . 23Verify Version 8.5 QualityStage module availability 25Verify Version 8.5 enterprise pack availability . . . 25Additional considerations for migrating an existingOracle database . . . . . . . . . . . . . 25

Chapter 4. Commands for migration . . 27ismigration tool commands . . . . . . . . . 27Export command . . . . . . . . . . . . 28Import command . . . . . . . . . . . . 29Restart command . . . . . . . . . . . . 30Encryption tool for use with ismigration tool . . . 31

Chapter 5. Migrating basic topologies 33Exporting from your source installations. . . . . 33

Installing the ismigration tool on your sourceinstallations . . . . . . . . . . . . . 33Validating the migration environment . . . . 34Using the ismigration tool to export your sourceinstallation . . . . . . . . . . . . . 34Completing the to-do activities . . . . . . . 35

Moving the archive files . . . . . . . . . . 36Importing to your target installations . . . . . . 37

Preparing the target installation environment . . 37Validating the migration environment . . . . 37Using the ismigration tool to import to yourtarget installation . . . . . . . . . . . 40Completing the to-do activities . . . . . . . 41

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

Migrate databases manually by using scripts . . 43Migrating the InfoSphere Information Analyzeranalysis database . . . . . . . . . . . 45Completing premigration activities for IBMInfoSphere QualityStage installations . . . . . 45

Import tasks for advanced and custom topologies 46Migrating to a different topology . . . . . . 46Manually configuring the application server . . 47Additional migration activities for IBMInfoSphere QualityStage . . . . . . . . . 48Opening each project to complete the migration 48

Chapter 7. Reference: Migrationdirectories and files . . . . . . . . . 51Default migration directories . . . . . . . . 51migration.properties file . . . . . . . . . . 52Host change file . . . . . . . . . . . . . 63Userfiles specifies additional files to include inarchive . . . . . . . . . . . . . . . . 65Migration log files . . . . . . . . . . . . 66migration.todo.txt file . . . . . . . . . . . 66

Part 3. Version 7.5.3 and earliermigrations . . . . . . . . . . . . 69

Chapter 8. Migrations from Version7.5.3 and earlier . . . . . . . . . . . 71

Chapter 9. Migration from DataStage7.5.3 and earlier versions. . . . . . . 73Exporting projects . . . . . . . . . . . . 73

Exporting projects from the DataStage Managerclient . . . . . . . . . . . . . . . 73Exporting projects from the command line . . . 74

Saving DataStage settings files . . . . . . . . 75Saving settings files (UNIX and Linux) . . . . 75Saving the DSParams file (Windows) . . . . . 75

Move job dependency objects . . . . . . . . 76Migrating hashed files . . . . . . . . . . 76

Remove previous versions of DataStage . . . . . 77Removing a DataStage server (Windows) . . . 77Removing a DataStage server (Linux, UNIX) . . 77Removing DataStage clients . . . . . . . . 77

Importing DataStage projects . . . . . . . . 78Restoring contents of DataStage 7.5.3 or earliersettings files . . . . . . . . . . . . . . 78Restoring DataStage job dependencies . . . . . 78

Restoring hashed files . . . . . . . . . . 79Recompiling jobs . . . . . . . . . . . . 80Updating jobs that use the QualityStage 7.5 plug-in 80

IBM Confidential

© Copyright IBM Corp. 2006, 2010 iii

Switching between different versions of clients . . 81Multiple server method (Linux and UNIX only) . . 81

Installing Version 8.5 in addition to existingDataStage servers . . . . . . . . . . . 83Installing IBM InfoSphere DataStage, Version 8.5clients in addition to existing clients . . . . . 83Starting and stopping multiple DataStage servers 84Connecting to multiple DataStage servers . . . 84

Chapter 10. Migration fromQualityStage 7.5 and earlier releases. . 87Job migration in legacy operational mode . . . . 87QualityStage job migration in expanded form . . . 88Rule set migration . . . . . . . . . . . . 88Match specification migration . . . . . . . . 88Installing the WebSphere QualityStage migrationutility . . . . . . . . . . . . . . . . 89Running the QualityStage migration utility . . . . 89

Importing the migrated files into the Version 8.5Designer client . . . . . . . . . . . . 91Preparing migrated QualityStage jobs foroperation . . . . . . . . . . . . . . 92

Migrating real-time QualityStage jobs from Release7 to Version 8.5 . . . . . . . . . . . . . 93Replace InfoSphere QualityStage 7 data qualitystages . . . . . . . . . . . . . . . . 94

Chapter 11. Migration from IBMWebSphere RTI 7.5, 7.5.1, and 7.5.2installations . . . . . . . . . . . . 97

Migrating RTIX files to Version 8.5 . . . . . . 97

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

Chapter 12. Upgrading a clienttier-only installation to Version 8.5 . . 101

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

Index . . . . . . . . . . . . . . . 119

IBM Confidential

iv Migrating to IBM InfoSphere Information Server, Version 8.5

Part 1. Overview of migration

IBM Confidential

© Copyright IBM Corp. 2006, 2010 1

IBM Confidential

2 Migrating to IBM InfoSphere Information Server, Version 8.5

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 Webat 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 newIBM InfoSphere Information Server, Version 8.5 installation.

Migration strategiesYou will use different migration strategies and methods to migrate to Version 8.5from existing installations. Plan your strategy and choose your migration methodbased on the version of your existing installation.

Successful migration requires that you understand your IBM InfoSphereInformation Server installation topology on the source computers and yourInfoSphere Information Server installation topology on the target computers.

You must use one of the following methods to migrate your source installation to anew Version 8.5 installation:

Table 1. Supported migrations to Version 8.5

Existing installation (source) Migration method

Information Server, Version 8.0.1 and later If you want to do this type of migration, seewww.ibm.com/support/docview.wss?uid=swg21445403.

DataStage, releases from 7.5.3 and earlier Export projects and save the settings filesfrom the existing installation. Then importthe projects and move the settings files tothe Version 8.5 installation. See Chapter 9,“Migration from DataStage 7.5.3 and earlierversions,” on page 73.

QualityStage, release 7.5 and earlier Use the QualityStage migration utility. SeeChapter 10, “Migration from QualityStage7.5 and earlier releases,” on page 87.

IBM WebSphere RTI 7.5, 7.5.2, and 7.5.1 Use the WebSphere RTI Export Wizard. SeeChapter 11, “Migration from IBM WebSphereRTI 7.5, 7.5.1, and 7.5.2 installations,” onpage 97.

Note: You do not migrate computers that only have the client tier installed onthem. Computers that only have client tier software installed do not containinstallation information or data that requires migration. To upgrade thesecomputers to Version 8.5, you run the InfoSphere Information Server suiteinstallation program.

IBM Confidential


http://publib.boulder.ibm.com/infocenter/iisinfsv/v8r5/topic/com.ibm.swg.im.iis.productization.iisinfsv.migrate.doc/topics/migr_container.html

http://publib.boulder.ibm.com/infocenter/iisinfsv/v8r5/topic/com.ibm.swg.im.iis.productization.iisinfsv.migrate.doc/topics/migr_container.html

http://www.ibm.com/support/docview.wss?uid=swg21445403


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 yourmigration from 8.0.1 and later. The ismigration tool helps you move from yourexisting environment (the source) to your new Version 8.5 installation (the target).

Migration from Version 8.0.1 and laterUse 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.1and 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 atfix pack levels for these versions.

Migrated data

The ismigration tool process migrates data in the metadata repository. Thisincludes work that is completed in the following products, if installed: IBMInfoSphere DataStage® and QualityStage, IBM InfoSphere Information Analyzer,IBM InfoSphere FastTrack, IBM InfoSphere Business Glossary, IBM InfoSphereInformation 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 What is not migrated

IBM InfoSphere DataStage v Data sets.

v For 8.0.1 or 8.1 InfoSphere DataStage jobrun time, after you migrate to the targetsystem, you must recompile and redeployyour jobs.

v InfoSphere DataStage runtime logs.

IBM InfoSphere QualityStage Postal validation reference and geocodingdata 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 toknow the difference between using the import and export (or asset interchangefunctionality) and migrating by using the ismigration tool. The ismigration toolperforms a more complete migration because it works at the metadata repositorylevel.

A sample of the benefits of using this tool to migrate your work in InfoSphereDataStage 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 andproject settings

v Project user roles, DSEngine maps, Message Handlers, and Parameter set filesare brought across.

v Checks the stages in the existing jobs for any referenced files and creates areport that you can use to copy referenced files to the target installation

v Can validate your source system before export and can validate your targetsystem before import

v If using IBM InfoSphere QualityStage, customized overrides are brought across

Overview of the migration processThe migration to IBM InfoSphere Information Server, Version 8.5 from Version 8.01or later installations is a two-phase process that runs the ismigration tool first onyour 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 tiercomputer and engine tier computer that you migrate. When you migrate basictopologies, the metadata repository database is included in the archive file thatis generated for the services tier computer.

3. Move the archive file from each source installation computer to your targetinstallation. You review and complete the manual activities that are specified inthe migration.todo.txt file, and move the archive file to your targetcomputers.

4. Install Version 8.5 on your target computers and ensure that the settings arelike your source system. See “Requirements for ismigration tool” on page 19.

5. Import the files into your target installation. The ismigration tool importprocess imports the archive file to populate your new target Version 8.5installation.

The following diagram illustrates the migration process that uses the ismigrationtool.

IBM Confidential


Scenario: Migrating a single-computer installationThis scenario provides an example for migrating from a Version 8.0.1 or latersource installation to a Version 8.5 target installation, where there are noinstallation topology changes.

The source installation is on the single Computer A, and so the target installationis also on the single Computer B. The following diagram illustrates this migrationscenario.

If any of the following conditions apply to your installation, additional migrationtasks 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.

Export to generatethe archive files

Enginetier

Services(domain)

tier

Metadatarepository

tier

Version 8.0.1 or laterSource installation

Import thearchive files

Enginetier

Services

tier(domain)

Metadatarepository

tier

Version 8.5Target installation

Move thearchive

files

Figure 1. Migration process overview

Computer A

Client tier

Enginetier

Servicestier

Metadata repository tier

Computer B

Client tier

Enginetier

Servicestier

Metadata repository tier



Figure 2. Single computer migration

IBM Confidential

Chapter 2. Overview and scenarios for 8.0.1 and later 9

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 themigration.

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 sourceinstallations” on page 33.

Table 3. Exporting the Version 8.0.1 source installation

Task Details

a. Review the requirements and restrictions forrunning a successful migration. Back up thesource installation.

See Chapter 3, “Planning for migration,” on page 19 and“Requirements for ismigration tool” on page 19.

b. Download and install the latest version ofthe Update Installer and then the ismigrationtool.

For details about installing the Update Installer, see “Installing theismigration tool on your source installations” on page 33.

c. Optional: Gather the required installationinformation from the source installation andconfirm the stability of the source installationenvironment, by downloading and runningIBM Support Assistant Lite for InfoSphereInformation Server.

For preinstalled database servers, contact thedatabase administrator to gather the requiredinformation.

In IBM Support Assistant Lite, run General Diagnostic HealthChecker to generate the Basic System Summary and the GeneralDiagnostic Health Checker reports.

See “Gathering source installation information for themigration.properties file (optional)” on page 21.

d. Encrypt the user credential passwords forthe migration.properties file.

After you encrypt the passwords, copy theencrypted password from the commandoutput, and use it in the migration.propertiesfile instead of using the actual passwords.

Example command:

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

See “Encryption tool for use with ismigration tool” on page 31.

e. Specify the 8.0.1 user names and paths in themigration.properties file. Do not specifyvalues for the other properties.

Example contents of the properties file:

is.suite.admin.username=adminis.suite.admin.password=4Bdmc6yfQVmqCqirnRj2zg==xmeta.db.binpath=/opt/IBM/db2/V9/binxmeta.db2.admin.username=db2inst1xmeta.db2.installdir=/opt/IBM/InformationServer/Repository/xmetadatastage.engine.admin.username=dsadmdatastage.engine.admin.password=4Bdmc6yfQVmqCqirnRj2zg==ia.db.binpath=/opt/IBM/db2/V9/binia.db2.installdir=/opt/IBM/InformationServer/Repository/iadb

See “Specifying installation environments in migration.propertiesfiles” on page 22 and “migration.properties file” on page 52.

IBM Confidential


Table 3. Exporting the Version 8.0.1 source installation (continued)

Task Details

f. Validate the source installation before youexport by using the ismigration tool.

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 lineto export the source installation. The exportprocess 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

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.

h. Complete any required activities in themigration.todo.txt file.

See “migration.todo.txt file” on page 66.

2. Move the archive files

The following table describes the task to move the archive files from the 8.0.1source installation (Computer A) to the 8.5 target installation (Computer B).

Table 4. Moving the archive files

Task Details

After you export the source installation, movethe archive files and other required files:

v ComputerA_ENGINE_timestamp.iar andComputerA_SERVICES_timestamp.iar archivefiles.

v Other required files, as defined in themigration.todo.txt file.

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.

IBM Confidential


Table 5. Importing the 8.0.1 source installation into the target 8.5 installation

Task Details

a. Create a new installation of Version 8.5:

v The services tier, metadata repository tier,and engine tier must match the existinginstallation.

v Install the same products and enterprisepacks as your source installation.

v The user credentials for the metadatarepository database owner (xmeta) and theinformation analysis database owner (iauser)must match the user credentials on yoursource installation. If you used an externaluser registry, wasadmin and isadmin mustalso match the source installation. Fordsadm, if credentials are different, you mustupdate credential mappings after youcomplete the migration.

See the IBM InfoSphere Information Server Planning, Installation, andConfiguration Guide.

See “Preparing the target installation environment” on page 37.

Optional: In IBM Support Assistant Lite, select General DiagnosticHealth Checker to generate the Basic System Summary and theGeneral Diagnostic Health Checker reports.

b. Encrypt the user credential passwords forthe migration.properties file.


Example command:



c. Specify the user names and paths in themigration.properties file. Do not specifyvalues for the other properties.


is.suite.admin.username=adminis.suite.admin.password=3lpi8OwUGOGqCqirnRj2zg==xmeta.db.binpath=C:\\IBM\\SQLLIB\\binxmeta.db2.installdir=c:\\xmeta.db2.admin.username=db2admindatastage.engine.admin.username=dstagedatastage.engine.admin.password=3lpi8OwUGOGqCqirnRj2zg==ia.db.binpath=c:\\IBM\\ia.db2.installdir=c:\\


d. Validate the target installation before youimport 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


e. Run the ismigration tool to import thesource 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 themigration.todo.txt file.


g. Optional: Confirm the stability of the 8.5installation.

In IBM Support Assistant Lite, select General Diagnostic HealthChecker.

IBM Confidential


What to do next

After you complete the 8.0.1 migration, you upgrade the clients.

Scenario: Migrating a multi-computer installationThis scenario provides an example for migrating from a Version 8.0.1 or latersource installation to a Version 8.5 target installation. The source installation is ontwo computers, and the target installation is on two computers.

In this example, Version 8.0.1 is installed on two different computers and ismigrating 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.

If any of the following conditions apply to your installation, additional migrationtasks 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.


Computer C

Services

tier(domain)

Metadatarepository tier

Computer D

Enginetier


Computer A

Services

tier(domain)

Metadatarepository tier

Computer B

Enginetier

Figure 3. Multi-computer migration

IBM Confidential


v You choose not to include the metadata repository tier in the archive file.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 themigration.

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 sourceinstallations” on page 33.

Table 6. Exporting the Version 8.0.1 source installation

Task Details

a. Review the requirements and restrictions forrunning a successful migration. Back up thesource installation.

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,and metadata repository tiers), download andinstall the latest version of the Update Installerand then the ismigration tool.

For details about installing the Update Installer, see “Installing theismigration tool on your source installations” on page 33.

c. Optional: On Computers A and B (engine,services, and metadata repository tiers), gatherthe required installation information from thesource installation and confirm the stability ofthe source installation environment, bydownloading and running IBM SupportAssistant Lite for InfoSphere InformationServer.

For preinstalled database servers, contact thedatabase administrator to gather the requiredinformation.

In IBM Support Assistant Lite, run General Diagnostic HealthChecker to generate the Basic System Summary and the GeneralDiagnostic Health Checker reports.

See “Gathering source installation information for themigration.properties file (optional)” on page 21.

d. On Computer A (services and metadatarepository tiers), encrypt the user credentialpasswords for the migration.properties file.


Example command:



e. On Computer A (services and metadatarepository tiers), specify the 8.0.1 user namesand paths in the migration.properties file. Donot specify values for the other properties.


is.suite.admin.username=adminis.suite.admin.password=3lpi8OwUGOGqCqirnRj2zg==xmeta.db.binpath=C:\\IBM\\SQLLIB\\binxmeta.db2.admin.username=db2adminia.db.binpath=c:\\IBM\\SQLLIB\\BINia.db2.installdir=c:\\


IBM Confidential


Table 6. Exporting the Version 8.0.1 source installation (continued)

Task Details

f. On Computer A (services and metadatarepository tiers), validate the source installationbefore you export by using the ismigrationtool.

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


g. On Computer A (services and metadatarepository tiers), run the ismigration tool at acommand line to export the source installation.The export process creates the following files:

v Archive file for the services tier:ComputerA_SERVICES_timestamp.iar


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


h. On Computer A (services and metadatarepository tiers), complete any requiredactivities in the migration.todo.txt file.


i. On Computer B (engine tier), encrypt theuser credential passwords for themigration.properties file.


Example command:



j. On Computer B (engine tier), specify the 8.0.1user names and paths in themigration.properties file. Do not specifyvalues for the other properties.


datastage.engine.admin.username=dstagedatastage.engine.admin.password=3lpi8OwUGOGqCqirnRj2zg==


k. On Computer B (engine tier), validate thesource installation before you export by usingthe 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


l. On Computer B (engine tier), run theismigration tool at a command line to exportthe source installation. The export processcreates the following files:

v Archive file for the engine tier:ComputerB_ENGINE_timestamp.iar


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


m. On Computer B (engine tier), complete anyrequired activities in the migration.todo.txtfile.


IBM Confidential


2. Move the archive files

The following table describes the task to move the archive files from the 8.0.1source installation (Computers A and B) to the 8.5 target installation (Computers Cand D).

Table 7. Moving the archive files

Task Details

After you export the source installation, movethe archive files and other required files:

v Move theComputerA_SERVICES_timestamp.iar archivefile from Computer A (source installation) toComputer C (target installation).

v Move the ComputerB_ENGINE_timestamp.iararchive file from Computer B (sourceinstallation) to Computer D (targetinstallation).

v As defined in the migration.todo.txt file,move other required files from the sourceinstallation computers to the targetinstallation computers.

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 Details

a. On Computers C and D (engine, services,and metadata repository tiers), create a newinstallation of Version 8.5:

v The services tier, metadata repository tier,and engine tier must match the existinginstallation.

v Install the same products and enterprisepacks as your source installation.

v The user credentials for the metadatarepository database owner (xmeta) and theinformation analysis database owner (iauser)must match the user credentials on yoursource installation. If you used an externaluser registry, wasadmin and isadmin mustalso match the source installation. Fordsadm, if credentials are different, you mustupdate credential mappings after youcomplete the migration.

See the IBM InfoSphere Information Server Planning, Installation, andConfiguration Guide.

See “Preparing the target installation environment” on page 37.

Optional: In IBM Support Assistant Lite, select General DiagnosticHealth Checker to generate the Basic System Summary and theGeneral Diagnostic Health Checker reports.

IBM Confidential


Table 8. Importing the 8.0.1 source installation into the target 8.5 installation (continued)

Task Details

b. On Computer C (services and metadatarepository tiers), encrypt the user credentialpasswords for the migration.properties file.


Example command:



c. On Computer C (services and metadatarepository tiers), specify the user names andpaths in the migration.properties file. Do notspecify values for the other properties.


is.suite.admin.username=adminis.suite.admin.password=3lpi8OwUGOGqCqirnRj2zg==xmeta.db.binpath=C:\\IBM\\SQLLIB\\binxmeta.db2.installdir=c:\\xmeta.db2.admin.username=db2adminia.db.binpath=c:\\IBM\\ia.db2.installdir=c:\\


d. On Computer C (services and metadatarepository tiers), validate the target installationbefore you import by using the ismigrationtool.

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


e. On Computer C (services and metadatarepository tiers), run the ismigration tool toimport the source installation to the targetinstallation.

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


f. On Computer C (services and metadatarepository tiers), complete any requiredactivities in the migration.todo.txt file.


g. On Computer D (engine tier), encrypt theuser credential passwords for themigration.properties file.


Example command:



h. On Computer D (engine tier), specify theuser names and paths in themigration.properties file. Do not specifyvalues for the other properties.


datastage.engine.admin.username=dstagedatastage.engine.admin.password=3lpi8OwUGOGqCqirnRj2zg==


IBM Confidential


Table 8. Importing the 8.0.1 source installation into the target 8.5 installation (continued)

Task Details

i. On Computer D (engine tier), validate thetarget installation before you import by usingthe ismigration tool.

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


j. On Computer D (engine tier), run theismigration tool to import the sourceinstallation 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


k. On Computer D (engine tier), complete anyrequired activities in the migration.todo.txtfile.


l. Optional: Confirm the stability of the 8.5installation.

In IBM Support Assistant Lite, select General Diagnostic HealthChecker.

What to do next

After you complete the 8.0.1 migration, you upgrade the clients.

IBM Confidential


Chapter 3. Planning for migration

The primary planning for migration involves understanding and preparing yoursource and target installation topologies.

Familiarize yourself with your source installation and plan your target installationtopology, before you begin the migration process. Moreover, back up your sourceinstallation. Optionally, use the IBM Support Assistant Lite tool to gather therequired installation information from your source installation.

You can migrate from an existing installation to the same topology or to a differenttopology 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 sourceinstallation halts during the migration process. Log off all users. You mustmanually restart your InfoSphere Information Server installation after the export iscompleted. Similarly for the target installation, consider any dependencies orrequirements that the installation, its databases, and the application server mighthave.

Requirements for ismigration toolThe requirements for the ismigration tool apply to your source installation andyour 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 diskspace. The work directory must have enough available disk space to hold thecontents of a full database backup for both the metadata repository and the IBMInfoSphere Information Analyzer analysis databases. On both the source and targetinstallations, increase the required disk space calculations by 25% to ensure thatyou have enough available disk space.

You must also verify that there is sufficient available disk space for the project filesin your Projects directories. The default Projects directory is in the defaultinstallation directory:

v Linux UNIX /opt/IBM/InformationServer/Projects

v Windows C:\IBM\InformationServer\Projects

If you specified a different directory for projects for your installation, then verifythe available disk space in that directory.

IBM Confidential


Requirements and restrictions

You can use the ismigration tool only if your target installation meets theserequirements: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 theInfoSphere Information Server migration tool to import to your target Version8.5 installation.

v The available disk space on the target installation is twice the amount of thedisk space that was required by the export.

v The number of engines is the same as the source installationv The source system and target system must have the same product modules. You

cannot install fewer or more InfoSphere Information Server product modules onthe 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. Forexample, on Microsoft Windows, run the following the command on bothsystems and compare the output to verify that the versions on the source andtarget 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 DB2database servers; or they both use Oracle database servers).

v The NLS configuration must be the same as the source installationv The same packs that were installed on the source must be installed on the target

installation before importv IBM InfoSphere QualityStage modules must be installed after import. See

“Completing premigration activities for IBM InfoSphere QualityStageinstallations” on page 45.

v The following database credentials and environments must be the same on thesource 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. Youcan use the -validateonly parameter to validate these requirements before you usethe tool to import or export.

IBM Confidential


Additional preparations for your migrationv 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.propertiesfile (optional)

Generate reports that provide the required installation information from yoursource installation. You use this information to create your migration.propertiesfile.

If your source installation system is Version 8.0.1 or later, download and install theIBM Support Assistant Lite for InfoSphere Information Server tool. For details ondownloading and installing the tool, see the IBM Support Assistant Lite forInfoSphere Information Server Quick Start Guide.

Note: If your source installation is Version 8.5, this step is not required beforerunning the tool. Refer to the IBM Support Assistant Lite for Information Server QuickServer 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 togenerate reports that provide information and confirm the stability of your sourceinstallation environment. Run the tool and generate reports for each sourceinstallation computer that you plan to migrate.

The health checker reports generated are intended to point out areas of interestthat may warrant further analysis at the appropriate time. Further analysis beforeyou proceed with migration tasks might not be required. When in doubt, pleaseconsult with your IBM Support personnel1. 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 youneed to create the migration.properties file for the local installation.

4. Select All Diagnostic Tools > General Diagnostic Health Checker to generatethe General Diagnostic Health Checker reports to verify the stability of the localinstallation environment.

Use the information in the Basic System Summary report to update themigration.properties file for the local installation.

IBM Confidential

Chapter 3. Planning for migration 21

Encrypting passwordsUse the encryption tool to encrypt passwords and other information. Use theencrypted properties values for entries that you specify in themigration.properties file.

By default, information is stored in plain text in the migration.properties file. Ifyou want to encrypt passwords or other information, follow this procedure toencrypt information and include it in the file. The encrypted values are acceptedby the IBM InfoSphere Information Server migration tool on the source and targetinstallations.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

v 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 usingyour 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 filesBefore you use the ismigration tool, you must specify the details of the installationenvironment that you want to migrate in the migration.properties file. Youprepare that file for each services tier and engine tier computer in your source andtarget installations.

Optional: To gather the required information, use the IBM Support Assistant Litefor InfoSphere Information Server tool to generate installation reports.

The migration.properties file defines the migration environment of the localinstallation. 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/confv 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.

IBM Confidential


5. Ensure that the following required suite-level entries are accurate andappropriate 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 areaccurate and appropriate for the local installation.a. xmeta.db.binpath

b. Properties that are required for your database server7. (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 yourenvironment 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 exportEnsure that your source installation meets the following validation requirementsbefore you use the ismigration tool.

Validation environment

The validation requirements for the source installation are based on the installationtier and the products that are installed.

This information assumes that you are using the default location and file name ofthe migration.properties file. References to the migration.properties file alsoapply 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 fileThe 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 thefile.

Source installation software versionThe version of your source installation of IBM InfoSphere InformationServer is compatible with the version of the ismigration tool.

Services tier

The following validation occurs on the services tier computer in the sourceinstallation.

Properties are defined in migration.properties fileThe required application server IBM InfoSphere Information Serverproperties are specified correctly:v is.suite.admin.username and is.suite.admin.password

IBM Confidential


v is.websphere.admin.username and is.websphere.admin.password

The user that is specified with the is.suite.admin.username andis.suite.admin.password properties is a valid user with the required suiteadministrative privileges.

Engine tier

The following validation occurs on the engine tier computer on the sourceinstallation.

Properties are defined in migration.properties fileThe 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 writeaccess to the following directories:– Engine directory and subdirectories– The migration work directory

v Verify that the directories exist as specified with the followingproperties:– datastage.engine.enginepath

– datastage.engine.asbhome

IBM InfoSphere Information Analyzer

The following validation occurs on the source installation only when theInfoSphere Information Analyzer analysis database is installed on the local filesystem and is being migrated by the ismigration tool.

Note: The following validation does not apply when you use the ia.gendb.enabledproperty to generate and use scripts to migrate the analysis database.

Analysis database properties are defined in migration.properties fileThe required InfoSphere Information Analyzer analysis database propertiesare specified correctly, as appropriate for your database server:v IBM DB2 database server

– The directory that is specified with the ia.db2.db.binpath propertyexists, has read and write access, is on the local file system, and isconnected.

– The directory that is specified with the ia.db2.installdir propertyexists 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 sysmaintauthority 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 theia.oracle.sys.servicename property exists.

– The case-sensitive Oracle table space name that is specified with theia.oracle.tablespacename property exists.

v SQL Server database server

IBM Confidential


– The directory that is specified with the ia.sqlserver.datafolderproperty exists, has read and write access, and is on the local filesystem.

Verify Version 8.5 QualityStage module availabilityIf your existing source installation uses IBM InfoSphere QualityStage modules, youmust determine the Version 8.5 module availability as you plan your migration toVersion 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 Module for DPIDv IBM InfoSphere QualityStage Module for SERPv IBM InfoSphere QualityStage Guide to IBM InfoSphere QualityStage Module for

U.S. Address Certificationv IBM InfoSphere QualityStage Worldwide Address Verification Interface

If your jobs depend on specific InfoSphere QualityStage modules, do not migrateuntil the module is available on Version 8.5.

For general information about the InfoSphere QualityStage modules, seeStandardizing address data with InfoSphere QualityStage.

Verify Version 8.5 enterprise pack availabilityIf your existing source installation uses IBM InfoSphere Information Server Packs,you must determine the Version 8.5 availability of the Packs as you plan yourmigration to Version 8.5.

Before migrate from existing installation, determine the availability of theInfoSphere Information Server Packs on Version 8.5. If your jobs depend on specificpacks, the availability of that pack influences your migration plan.

For general information about the InfoSphere Information Server Packs, seeInfoSphere Information Server PacksInfoSphere Information Server Packs.

Additional considerations for migrating an existing Oracle databaseIf you have an existing Oracle database, character encoding incompatibility canlead to import failure. If the NLS encoding of the source and target Oracledatabases do not match, the migration will fail to restore the source table space onthe target system.

The IBM InfoSphere Information Server, Version 8.5 installation program enforcesOracle 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 yourexisting Oracle database might have a different encoding. If you attempt to importan existing Oracle database with incompatible character encodings, the import ofthe table space fails.

IBM Confidential


http://publib.boulder.ibm.com/infocenter/iisinfsv/v8r5/topic/com.ibm.swg.im.iis.qs.nav.doc/topics/cont_qs_modules.html

http://publib.boulder.ibm.com/infocenter/iisinfsv/v8r5/topic/com.ibm.swg.im.iis.productization.iisinfsv.overview.doc/topics/cisocomppacksintro.html

1. Before you import to the target system, ensure that the source databaseencoding matches the target database encoding.

2. If the character encodings on your source database and target database do notmatch, choose one of the following actions before you import to the targetsystem:v Sync the source database NLS encoding: Upgrade the source database's

character set encoding to AL32UTF8 for NLS_CHARACTERSET andAL16UTF16 for NLS_NCHAR_CHARACTERSET prior to export so that itmatches target system.

v Sync the target database NLS encoding: Install InfoSphere InformationServer, Version 8.5, which will enforce the character encodings. After theinstallation, change the target database's character encoding to match sourcedatabase's character encoding.

To change the encoding by using one of these options, follow the Oracledocumentation based on the appropriate database version.

IBM Confidential


Chapter 4. Commands for migration

The ismigration tool uses a command line interface to run the tool. Additionaluser interfaces with the ismigration tool involve using a text editor, such asWordPad, to create the required migration.properties file and other configurationfiles for each computer.

The ismigration tool is installed with IBM InfoSphere Information Server, Version8.5. You must install the ismigration tool on your Version 8.0.1 and Version 8.1source installation computers to enable migration export.

You run the ismigration tool at a command line on the services tier computer andengine tier computer on your source and your target installation computers. Theismigration tool uses the export, import, or restart parameters.

The most important user interface for successful migration is when you create themigration.properties file for each computer in your source and target installation.You must plan your migration, gather the required information, and correctlyconfigure your migration.properties file before you use the command lineinterface to run the ismigration tool.

Important: Although you do not run the ismigration tool on the metadatarepository tier, you can optionally generate database scripts that you run on themetadata repository tier computer.

The encrypt tool is installed with the ismigration tool. Before you create yourmigration.properties files, use the encrypt tool to encrypt the sensitive propertyvalues that you specify in this file.

ismigration tool commandsYou run the ismigration tool at a command line on the services tier computer andengine 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 –restartismigration -versionismigration -help

You can specify the absolute path of the ismigration tool on the command line oryou can run the ismigration tool at the command line from theinstall_dir\Migration\bin directory.

IBM Confidential


Export commandThe ismigration tool export command exports your installation and creates anarchive file on the local file system of your source installation computer. You runthe export command on the services tier first, then the engine tier.

Linux, UNIX

/opt/IBM/InformationServer/Migration/bin/ismigration.sh -export -archiveiar_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 thecommand line. Relative directory paths are supported. Run the export commandon the services tier first, then the engine tier.

-exportRequired. Exports the installation from the source computer.

-archive iar_dirRequired. Specifies the name of the directory where you want to store thearchive file.

-work work_dirOptional. Specifies the name of the directory where you want to store theexported work files. When you do not specify the -work_dir parameter, thedefault 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 workdirectory potentially contains large volumes of data.

-config config.fileOptional. Specifies the relative file name, or the explicit directory path and filename, of the required migration.properties file on the local file system. Youmust use this parameter if you changed the name or location of themigration.properties file that you created.

Note: If you do not specify a file on the -config parameter, the defaultmigration.properties file in the \conf directory is used. The defaultmigration.properties file in the conf directory is used if the -config parameteris not specified.

-userfiles filenameOptional. Export only. Specifies the relative file name, or the absolute directorypath and file name, of a text file that contains a list of additional files toinclude in the exported archive file. Enter each file name on a single line in thetext file.

-validateonlyOptional. The current migration environment, including the existence of

IBM Confidential


required files, is validated without running the export command. Verifies thevalues that are specified in the migration.properties file, and confirms theexistence 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 commandThe ismigration tool import command imports an archive file that is on the localfile system. You run the import command on the services tier first, then the enginetier.

Linux, UNIX

/opt/IBM/InformationServer/Migration/bin/ismigration.sh -import -archiveiar_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 thecommand line. Relative directory paths are supported. Run the import commandon the services tier first, then the engine tier.

-importRequired. Imports the installation to the target computer.

-archive iar_dirRequired. Specifies the name of the directory that stores the archive files thatwere generated from the source installation.

-work work_dirOptional. Specifies the name of the directory that stores the migration workfiles from the source installation. When the -work_dir parameter is notspecified, the default location of the work directory is in the temporarydirectory:v Linux, UNIX: /tmp/workv Windows: %TEMP%\work

Ensure that your work directory has enough available disk space. The workdirectory potentially contains large volumes of data.

IBM Confidential

Chapter 4. Commands for migration 29

-config config.fileOptional. Specifies the relative file name, or the explicit directory path and filename, of the required migration properties file on the local file system.

Note: The migration properties file is required, although the -config parameteris optional. The default migration.properties file in the conf directory is usedif the -config parameter is not specified.

-host-change-config HostChangeConfig.xmlSpecifies the file name of the host change file.

The host change file is required for target installations that have a differentinstallation topology than the source installation. The host change file is alsorequired when there is more than one engine tier. In this case, the host changefile is required although the -host-change-config parameter is optional. Thedefault HostChangeConfig.xml file in the conf directory is used when the-host-change-config parameter is not specified.

-gen-app-server appsvr_dirOptional. Services tier only. Generates application server configuration scriptsin the specified directory. When a directory name is specified, applicationserver configuration scripts are created during the export process. You usethese scripts to review the changes to be made to the application server duringmigration, and then manually run the scripts to configure your applicationserver.

-validateonlyOptional. Use this parameter to validate the current migration environment,including the required files, without running the import command. Validationverifies 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 filecontains the required migration properties for the target installation.

v The C:\temp\HostChangeFile.xml contains the required host change informationfor 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 commandThe ismigration tool restart command restarts the import or export process fromthe last saved checkpoint. The ismigration tool creates a checkpoint file at interimstages throughout the migration.

Linux, UNIX

/opt/IBM/InformationServer/Migration/bin/ismigration.sh -restart

Windows

IBM Confidential


C:\IBM\InformationServer\migration\bin\ismigration.bat -restart

Parameters

When you run the ismigration tool, enter the -restart parameter on the commandline.

-restartYou 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 doesn’t have authority to backup database.[ibm][db2][jcc][t4][2012][11248] Connection authorization failure occurred. Reason: Password expired.

After you see this error and you fix the problem, run the restart command toresume the import or the export from the last saved checkpoint:/opt/IBM/InformationServer/Migration/bin/ismigration.sh -restart

Encryption tool for use with ismigration toolUse the encryption tool to generate encrypted properties values for entries that youspecify in the migration.properties file. Typical values to encrypt includesensitive 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_encryptEncrypts the value that is provided. Enter the encrypted value in themigration.properties file to substitute for the value_to_encrypt. This encryptedvalue is accepted by the ismigration tool on the source and target installations.

The following sample encryption tool command for a Windows source installationgenerates the encrypted value oR5z2vAiRDU= for dsadm:C:\IBM\InformationServer\migration\bin\encrypt.bat dsadm

oR5z2vAiRDU=

IBM Confidential

Chapter 4. Commands for migration 31

In the migration.properties file, use the encrypted oR5z2vAiRDU= value instead ofthe clear text password dsadm.

IBM Confidential


Chapter 5. Migrating basic topologies

For single-computer and multi-computer topologies, you can perform the basicmigration tasks for your topology. The streamlined migration is appropriate whenyou do not have to move the location of databases or tiers, to comply withdatabase security measures for backups and creation, or to migrate InfoSphereQualityStage.

Before you complete any migration tasks, you must complete the planning tasks.

Exporting from your source installationsExporting your existing installation from your source computers involves acombination of manual premigration activities, using the ismigration tool, movingthe archive files, and completing the to do lists for each computer.

Installing the ismigration tool on your source installationsInstall the ismigration tool on the services tier computers and engine tiercomputers in your Version 8.0.1 and later source installations. Install the latestversion in your Version 8.5 installation.

You must download and install the latest Update Installer to install the ismigrationtool on your services tier and engine tier computers in your Version 8.0.1 and latersource installations. If there is a newer version of the Update Installer for Version8.5, you must download and install it.

You use the Update Installer to install updates to your installation, includinginstalling the ismigration tool on your services tier and engine tier computers inyour Version 8.0.1 and later source installations.

The ismigration tool that you install and run on your Version 8.0.1 and later sourceinstallations computers does not change your InfoSphere Information Serverinstallation 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 Installerv Version 8.1 Update Installerv Version 8.5 Update Installer

2. Download the ismigration tool for each services tier and engine tier computerin your source installation. An .ispkg file is provided for each operatingsystem: Migration_tool_os_85.ispkg.

3. Follow the installation instructions to download and install the ismigration tool.

Option Description

Version 8.0.1 www.ibm.com/support/docview.wss?uid=swg27011896

Version 8.1 www.ibm.com/support/docview.wss?uid=swg27012519

Version 8.5 www.ibm.com/support/docview.wss?uid=swg27016531

IBM Confidential








The ismigration tool is installed in the install_dir/Migration directory on theservices tier and engine tier computers in your source and target installation. Thedefault migration directories are as follows:

Table 9. Default ismigration tool directories

Operating system Default InfoSphere Information Server migration directories

Linux, UNIX /opt/IBM/InformationServer/Migration

Windows 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 formigration,” on page 19. Then, validate your migration environment. See“Validating the migration environment.”

Validating the migration environmentRun the ismigration tool with the -validateonly parameter to validate themigration environment on each services and engine tier computer before you runthe ismigration tool.

The migration environment is automatically validated when the ismigration tool isrun. You can optionally validate the migration environment without running themigration export or import command. Validation verifies the values in themigration.properties file are appropriate for the local installation environmentand the ismigration command that you specify. To ensure a successful migration,you should run the ismigration tool with the -validateonly parameter before yourun the export or import command. Complete this validation step on each servicesand 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 aWindows computer:ismigration.bat -export -archive C:\exportdir -validateonly

3. If the ismigration validation fails, review the migration log file for SEVEREerror 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 themigration until the validation is successful.

Using the ismigration tool to export your source installationRun the ismigration tool on each services and engine tier computer to export yoursource installation and generate the archive files. Export the services tier first, andthen the engine tier.

Before you export your source installation, run the ismigration tool with the-validateonly parameter to validate your migration environment for the exportcommand.

IBM Confidential


Use the ismigration tool to export your source installation. The export processgenerates the archive files and the migration.todo.txt file for each services tierand engine tier computer.

Run the export command only on the services tier and engine tier computers. Theismigration tool does not run on the metadata repository tier computers or onclient-tier only computers.

For details on migrating remote metadata repository databases, see . For details onupgrading client-tier only computers, see Chapter 12, “Upgrading a client tier-onlyinstallation 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 toexport 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.iarC:\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 toexport 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 sourceinstallation remains intact.

Review the migration.todo.txt file for each computer and complete the specifiedto-do activities. See “Completing the to-do activities.”

Completing the to-do activitiesYou must review and complete the required to-do activities for each computer asspecified in the migration.todo.txt file that is created when the migration iscompleted.

The migration.todo.txt file is generated for each tier computer that is exported orimported by using the ismigration tool. The migration.todo.txt specifies theactivities that you must complete before you continue the migration. For example,after you run the ismigration tool to export the source installation, themigration.todo.txt file identifies the required files that you must manually moveto the target installation.

Because the ismigration tool does not migrate the InfoSphere QualityStagemodules, their associated reference databases, or the Match Designer database, you

IBM Confidential

Chapter 5. Migrating basic topologies 35

might need to complete specific premigration and postmigration activities forQualityStage, depending on your source installation. See Additional migrationactivities 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 targetinstallation.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 weremigrated from the source installation. See "Purging job log files" in the IBMInfoSphere DataStage and QualityStage Administrator Client Guide.

Moving the archive filesAfter you export your source installation computers, move the archive files andother required files from the services and engine tier computers in your sourceinstallation to the target installation computers.

Run the ismigration tool to export your source installation and generate thehostname_SERVICES_timestamp.iar and hostname_ENGINE_timestamp.iar archivefiles and the migration.todo.txt files for each tier computer. See “Using theismigration tool to export your source installation” on page 34.

This procedure assumes that the services tier and the metadata repository tier areinstalled on the same computer. If your metadata repository tier is remote from theservices tier computer, then additional steps are required. See “Migrate databasesmanually by using scripts” on page 43.

Depending on your source installation, you might need to move other files fromyour source installation to your target installation. For example, files that arespecified in the migration.todo.txt file or the QualityStage Match Designerdatabase (see “Additional migration activities for IBM InfoSphere QualityStage” onpage 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. Forexample, /home/dsadm/archive/systema_SERVICES_20100110_123500.iar.

IBM Confidential


http://publib.boulder.ibm.com/infocenter/iisinfsv/v8r5/topic/com.ibm.swg.im.iis.productization.iisinfsv.install.doc/topics/cont_iisinfsrv_config.html



2. On each engine tier computer, locate your archive file. The archive file iscreated in the directory that you specified with the -archive parameter. Forexample, /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 fromthe source computer to a network location:cd /home/dsadm/archivescp systema_SERVICES_20100110_123500.iar dsadm@systemb:/home/dsadm/archive

The archive files are available in a local file system on each target installationcomputer.

Run the ismigration tool to import your installation. See .

Importing to your target installationsPrepare your target installation, and then run the ismigration tool on the servicestier computers and the engine tier computers to import your existing installation toyour target installation. Then complete the postmigration activities as required foryour installation.

Preparing the target installation environmentPrepare your target installation environment before you import.

Gather installation information about your source installation. See: “Installing theismigration 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 tiercomputer and that the NodeAgents processes are running on all clustermember computers in your target installation.

3. Install IBM InfoSphere Information Server, Version 8.5 with the same productsthat are installed on your source installation. Install the InfoSphere InformationServer Packs, if applicable.

4. If you are using Java Message Service (JMS) queues on the services tier on yoursource installation, then the JMS configuration on your target installation mustbe the same as your source installation.

5. Complete all required activities that were specified in the migration.todo.txtfiles that were generated during the export of the source installations.

Validating the migration environment task. See: “Validating the migrationenvironment” on page 34.

Validating the migration environmentRun the ismigration tool with the -validateonly parameter to validate themigration environment on each services and engine tier computer before you runthe ismigration tool.

The migration environment is automatically validated when the ismigration tool isrun. You can optionally validate the migration environment without running themigration export or import command. Validation verifies the values in themigration.properties file are appropriate for the local installation environment

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 yourun the export or import command. Complete this validation step on each servicesand 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 aWindows computer:ismigration.bat -export -archive C:\exportdir -validateonly

3. If the ismigration validation fails, review the migration log file for SEVEREerror 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 themigration until the validation is successful.

Requirements for using the ismigration tool to import to thetarget installationEnsure that your target installation meets the following validation requirementsbefore you use the ismigration tool.

Validation environment

The validation requirements for the target installation are based on the installationtier and the products that are installed.

This information assumes that you are using the default location and file names ofthe migration.properties and HostChangeConfig.xml files. The information alsoapplies to the files that you specify with the -config and -host-change-configparameters.

All tiers

The following validation occurs on all tiers in the source installation.

Properties are defined in migration.properties fileThe default migration.properties file, or the file that is specified with the-config parameter, is present.


Properties are defined in migration.properties fileThe migration.properties file is present.

The HostChangeConfig.xml file is present.


Source installation software versionThe version of your source installation of IBM InfoSphere InformationServer is compatible with the version of the ismigration tool.

IBM Confidential


Services tier

The following validation occurs for the services tier in the target installation.

Suite-wide properties are defined in migration.properties fileThe required IBM InfoSphere Information Server property is specifiedcorrectly:v (Export only) is.suite.admin.username and is.suite.admin.password

from the source installation

Software versionThe version of your target installation of IBM InfoSphere InformationServer is compatible with the version of the ismigration tool.

Products and product modulesThe target installation has the same products and product modulesinstalled as the source installation.

Number of enginesThe number of engines is the same as the source installation.

Operating systemThe target installation has the same operating system as the sourceinstallation.

New installationThe Version 8.5 installation is a new installation.

Engine tier

The following validation occurs for the engine tier on the target installation.

Host change configurationThe engine tiers from the source and target installations are correctlymapped in the HostChangeConfig.xml file.

NLS configurationThe NLS configuration on your target installation of IBM InfoSphereInformation Server is the same as the source installation.

Properties are defined in migration.properties fileThe 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 writeaccess 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 InfoSphereInformation Analyzer analysis database is automatically migrated by theismigration tool. Automatic migration of the analysis database requires that theanalysis database must be on the local file system.

IBM Confidential


Note: The following validation does not apply when manual migration of theanalysis database is specified with the ia.gendb.enabled property.

Analysis database properties are defined in migration.properties fileThe required InfoSphere Information Analyzer analysis database propertiesare specified correctly:v IBM DB2 database server

– The directory that is specified with the ia.db2.db.binpath propertyexists, has read and write access, is on the local file system, and isconnected.

– The directory that is specified with the ia.db2.installdir propertyexists 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 sysmaintauthority 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 theia.oracle.sys.servicename property exists.

– The Oracle tablespace name that is specified with theia.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 filesystem.

Using the ismigration tool to import to your target installationRun the ismigration tool to import to your target installation. Import the servicestier 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: “Validatingthe migration environment” on page 34.

Use the ismigration tool to import to your target installation. You run theismigration tool only on the services tier computers and on the engine tiercomputers. The ismigration tool does not run on the metadata repository tiercomputers or on client-tier only computers.

Client tier-only installations are not migrated. Use the suite installation program toupgrade the client tier software. See Chapter 12, “Upgrading a client tier-onlyinstallation to Version 8.5,” on page 101.

The metadata repository database is automatically migrated when it is on the samecomputer with the services tier. For advanced migrations that use manual databasemigration, 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 toimport the services tier to a Windows computers:

IBM Confidential


ismigration.bat -import –archive C:\temp\archivedir

where C:\temp\archive is the directory where you moved thehostname_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 toimport the engine tier to a Linux computer:ismigration.sh -import –archive /opt/archivedir

where /opt/archivedir is the directory where you moved thehostname_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 filesfor each computer.

If applicable, follow the readme.txt to import the metadata repository database orIBM InfoSphere Information Analyzer analysis databases. See: “Manually migratingthe metadata repository database” on page 44 and “Migrating the InfoSphereInformation Analyzer analysis database” on page 45.

Completing the to-do activitiesYou must review and complete the required to-do activities for each computer asspecified in the migration.todo.txt file that is created when the migration iscompleted.

The migration.todo.txt file is generated for each tier computer that is exported orimported by using the ismigration tool. The migration.todo.txt specifies theactivities that you must complete before you continue the migration. For example,after you run the ismigration tool to export the source installation, themigration.todo.txt file identifies the required files that you must manually moveto the target installation.

Because the ismigration tool does not migrate the InfoSphere QualityStagemodules, their associated reference databases, or the Match Designer database, youmight need to complete specific premigration and postmigration activities forQualityStage, depending on your source installation. See Additional migrationactivities 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.

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 targetinstallation.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 weremigrated from the source installation. See "Purging job log files" in the IBMInfoSphere DataStage and QualityStage Administrator Client Guide.

IBM Confidential





Chapter 6. Additional migration tasks for advanced or customtopologies

If you have a more complex topology that you want to migrate, such as a differentdatabase location or specific backup security requirements, you must completeadditional 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 topologiesBefore you export your source installation, you might need to complete additionaltasks depending on your requirements.

Migrate databases manually by using scriptsIf your metadata repository tier is not on same computer as the services tier, youmust generate the scripts on the services tier computer and move them to themetadata repository tier computer to migrate the databases. If your metadatarepository tier is on the same computer as the services tier, you do not need tomigrate your databases manually unless it is required by company securitypolicies.

Important: Migrate your database manually only if it is required for yourmigration. Confirm with an expert database administrator if you are unsure.Attention: If your migration does not require this option, ensure that you do notenable the xmeta.gendb.directory property or the ia.gendb.enabled property in themigration.properties file. If you specify a directory for this property when yourmigration does not match one of the scenarios below, you might experience loss ofdata 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 themetadata repository database. If InfoSphere Information Analyzer is installed,you must also generate and use scripts to migrate the InfoSphere InformationAnalyzer analysis database.

This procedure is also required if your company establishes any of thefollowing requirements or security policies:

v You must audit every script that runs against a corporate database or on arestricted database server environment.

v You cannot provide database administrator credentials to run a data dump froma remote client computer.

If any of the above situations apply to your migration, ensure that you completeall of the applicable activities that are specified in the migration.todo.txt file. Thisfile is generated for each computer after the ismigration tool export and importprocess is completed. You must log in as a user with database administratorprivileges to run the scripts.

IBM Confidential


To use this option, you must specify a valid absolute directory name in thexmeta.gendb.directory or the ia.gendb.enabled property before you export yoursource installation and before you import to your target installation. During importto the target installation, the import process on the services tier computer haltsuntil you run the scripts on the metadata repository tier computer and load thedatabase. The migration process halts until you run the scripts and restart themigration.

If none of the above situations apply to your migration, do not generate and usescripts to migrate your databases on the metadata repository tier. Ensure that thexmeta.gendb.directory or the ia.gendb.enabled properties are disabled in themigration.properties file.

Manually migrating the metadata repository databaseThese steps apply only to migrations that have chosen to back up and restore themetadata repository tier manually. When you migrate the metadata repositorydatabase manually, you must generate and move additional database dump filesand follow these additional steps.

This procedure assumes that you have chosen, during the planning stage of yourmigration, 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 directorythat is specified with the xmeta.gendb.directory property to allow a databaseadministrator to manually run the script to import the metadata repositorydatabase. The exported metadata repository database must be moved to themetadata repository tier on the target installation. Use the readme.txt file for thedetails 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 onthe file system. This data is loaded again, after you restore the sourcedatabase. This saves the Version 8.5 new installation data that wouldotherwise be overwritten when the source installation metadata repositorydatabase is restored.

b. Run the import command on the services tier computer to generate thescripts and readme.txt files.The metadata repository tier import pauses here so that the databaseadministrator complete the import manually.

c. Move the scripts to the metadata repository tier computer. Edit the scriptfile for your migration.

d. Run the scripts on the target installation metadata repository tier computerto import .

4. After the source database is restored on the target installation, follow the stepsin the readme.txt to load the data.

IBM Confidential


Migrating the InfoSphere Information Analyzer analysisdatabase

You can optionally migrate the IBM InfoSphere Information Analyzer analysisdatabase when you migrate to IBM InfoSphere Information Server, Version 8.5. Youchoose whether to migrate the analysis database automatically or manually.

During your planning phase for migration, determine whether you need to migratethe InfoSphere Information Analyzer analysis database. If you want to migrate theInfoSphere Information Analyzer analysis database, set theia.migrate.analysisdb.enabled property to true.

If you choose to migrate the analysis database, determine whether you need tomigrate the analysis database manually. See “Migrate databases manually by usingscripts” on page 43. If you must migrate the analysis database manually, setia.gendb.enabled to true and specify a valid path for the ia.gendb.directoryproperty.

To manually migrate the analysis database to the Version 8.5 target system, reviewthe following steps. These steps point out the analysis database migration actionsthat are needed during your overall migration.

Use the readme.txt file for the details and required procedures for each of thesesteps.

The following steps apply only to migrations that are required to or have chosen toback up and restore the metadata repository tier manually. When you migrate theIBM InfoSphere Information Analyzer analysis databases manually, you mustgenerate and move additional database dump files and follow these additionalsteps.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 InfoSphereQualityStage installations

Complete these premigration activities if your source installation includesInfoSphere QualityStage modules or the Match Designer database.

The ismigration tool does not migrate InfoSphere QualityStage modules, theirassociated reference databases, or the Match Designer database. As appropriate foryour installation, complete these premigration activities before you export yourVersion 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

IBM Confidential

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

database server was installed by the IBM InfoSphere Information Serverinstallation program.If your database server was preinstalled, ensure that youconfigure the target installation as required to use the Match Designer database.

2. If your source installation includes InfoSphere QualityStage modules, verifythat the modules are available in Version 8.5. See IBM InfoSphere QualityStagemodule availability.

Import tasks for advanced and custom topologiesBefore you import your source installation into your new 8.5 installation, youmight need to complete additional tasks depending on your requirements.

Migrating to a different topologyYou must edit the host change file before you run the ismigration tool to importthe archive file to your target installation before you import.

If your target installation has topology changes, project location changes, or portnumber changes, you must edit the host change file and specify it when you runthe ismigration tool to import your source installation.

Identifying your source installation host namesAfter a successful migration export from the source installation, theHostChangeConfigTemplate.xml file is generated in the Migration directory.The file contains accurate host name entries for the engine tier and theservices tier computers. You can add entries for the target installationcomputers, and use this file during the import migration on the targetinstallation.

Identifying your target installation host namesOn the target installation, run the migration import with the -validateonlyparameter. The install_dir\Migration\HostChangeConfigTemplate.xml filethat is created contains the host change entries that are required for import.

Optionally, you can also run the IBM Support Assistant Lite for InfoSphereInformation Server tool to gather the required installation information from yoursource and target installations. For details on downloading, installing, and usingthe tool, see the IBM Support Assistant Lite for InfoSphere Information Server QuickStart 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 anew Version 8.5 installation that has installation topology changes, project locationchanges, host name changes, or port number changes. The host change file is notrequired for migrations with the same installation topology and no port numberchanges.

By default, the ismigration tool uses the HostChangeConfig.xml file in the confdirectory. If your host change file is in a different directory or has a different filename, 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 theafter the migration export is completed.

2. Copy or move the file to the install_dir/Migration/conf directory on eachservices and engine tier computer in your target installation:

3. Rename the file to HostChangeConfig.xml.

IBM Confidential


http://www.ibm.com/software/data/infosphere/qualitystage/requirements.html

http://www.ibm.com/software/data/infosphere/qualitystage/requirements.html


4. Use a text editor to view and change the entries in the HostChangeConfig.xmlfile on each services and engine tier computer in your target installation. Forexample, the following entries for an engine tier computer that is running onLinux or UNIX specify changes to the host name, the project location, and theport 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 serverYou can manually configure the application server configuration settings. Youspecify a parameter during the import to your target installation.

You can enable manual configuration of the application server configurationsettings by specifying the -gen-app-server paramter. You specify the-gen-app-server parameter during the import to your target installation, after youvalidate 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 aWindows computers:C:\IBM\InformationServer\Migration\bin ismigration.bat -import –archiveC:\temp\archivedir -gen-app-server C:\IBM\InformationServer\Migration\appserver

where C:\temp\archive is the directory where you moved thehostname_SERVICES_timestamp.iar archive fileand where C:\IBM\InformationServer\Migration\appserveris the directory where you want to create the application server configuration scripts are created.

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 administratorbefore 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 specifiedto-do activities. See

IBM Confidential


Additional migration activities for IBM InfoSphereQualityStage

If your target installation includes InfoSphere QualityStage modules, you canoptionally perform these postmigration activities to complete the InfoSphereQualityStage migration.

InfoSphere QualityStage modules

If you want to migrate the InfoSphere QualityStage postal reference filesthat are associated with your InfoSphere QualityStage modules, completethese manual steps on the target installation. These required activities arenot included in the migration to-do lists because the ismigration tool doesnot migrate InfoSphere QualityStage modules or the reference files for theInfoSphere 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 databaseIf your installation includes the InfoSphere QualityStage Match Designerdatabase, 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 matchspecification.If your installation includes an IBM DB2 database that was notinstalled by the IBM InfoSphere Information Server suite installerand your target installation uses a DB2 database that was installedwith the suite installer, restore the Match Designer database that youpreserved 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 theIBM InfoSphere Information Server Planning, Installation, and ConfigurationGuide.

Opening each project to complete the migrationIf you did not enable the datastage.engine.update.project property in themigration.properties file, you must open each IBM InfoSphere DataStage andQualityStage project and click Migrate to complete the migration to Version 8.5.

Complete the migration import and the postmigration activities as required foryour installation.

IBM Confidential


The InfoSphere DataStage and QualityStage clients in the new installation cannotconnect 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.

IBM Confidential


IBM Confidential


Chapter 7. Reference: Migration directories and files

This reference information can help you to plan, prepare, and manage yourmigrations to new IBM InfoSphere Information Server, Version 8.5 installations.

Default migration directoriesThe ismigration tool is automatically installed with Version 8.5, so the migrationdefault directories are in your Version 8.5 installation. The migration defaultdirectories exist on Version 8.0.1 and Version 8.1 installations after you install theismigration tool.

The default migration directory is:

v Linux UNIX /opt/IBM/InformationServer/Migration

v Windows C:\IBM\InformationServer\Migration

conf directory

You configure your migration with the migration configuration files. Theseconfiguration files are in the conf directory:

v Linux UNIX /opt/IBM/InformationServer/Migration/conf

v Windows 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 toolscripts 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 Linux UNIX /opt/IBM/InformationServer/Migration/logs

v Windows C:\IBM\InformationServer\Migration\logs

IBM Confidential


migration.properties fileThe migration.properties file contains installation information that is required forall migrations. Correct configuration of this file for each computer is a criticalplanning task.

Purpose

The entries in the migration.properties file define the installation environment formigration. Use a text editor, such as WordPad, to view and change the entries inthe migration.properties file. You will need to be familiar with your source andtarget installations to gather the information that you need to create the entries inthe migration.properties files. You will need a migration.properties file for eachservices and engine tier computer in your source installation, and for each servicesand engine tier computer in your target installation. A sample files is provided inthe conf directory:

v Linux UNIX /opt/IBM/InformationServer/Migration/conf/migration.properties.sample

v Windows C:\IBM\InformationServer\Migration\conf\migration.properties.sample

When the ismigration tool is run, it uses the following default directory and filename of the migration.properties file:

v Linux UNIX /opt/IBM/InformationServer/Migration/conf/migration.properties

v Windows C:\IBM\InformationServer\Migration\conf\migration.properties

If you do not use the default directory and file name, use the -config parameter onthe ismigration tool commands to specify a different directory path or file name ofyour 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 pathnames. For example, type C:\\IBM\\SQLLIB\\bin for the C:\IBM\SQLLIB\bindirectory.

The following descriptive tags provide context and details for the properties.v Tiers: specifies the tier that the property applies tov 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 propertyapplies to

v Required or Optional

IBM Confidential


IBM InfoSphere Information Server properties for services tiercomputers and engine tier computers

Set the following properties to define the InfoSphere Information Serverinstallation environment for your services tier computer and engine tier computers.

is.suite.admin.usernameThis property defines the InfoSphere Information Server administrator username of your source installation.

The sample file includes the following default entry and value:is.suite.admin.username=isadmin

v Tiers: Servicesv Commands: Exportv Components: Allv Required for export

is.suite.admin.passwordThis property defines the InfoSphere Information Server administrator userpassword 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 Tiers: Servicesv Commands: Exportv Components: Allv Required for export

is.websphere.admin.usernameDo not enable this property if you are using the default internal userregistry. This property is needed only when the IBM WebSphereApplication Server administrator user name on the target installation isdifferent than the source installation. For example, if the operating systemuser name or the LDAP user name changes after the export from thesource 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: Servicesv Commands: Importv Components: Allv Optional

Note: After a successful import, the WebSphere Application Server username on the target installation is set to the user name that is specified forIBM WebSphere Application Server administrator user name on the sourceinstallation.

is.websphere.admin.passwordDo not enable this property if you are using the default internal userregistry. This property is needed only when the IBM WebSphereApplication Server administrator password on the target installation isdifferent than the source installation. For example, if the operating systempassword or the LDAP password changes after the export from the sourceinstallation and before the import to the target installation.

IBM Confidential

Chapter 7. Reference: Migration directories and files 53

The sample file includes the following default entry and value:is.websphere.admin.password=snE4oBBsg+c/qkvcYc2o1Q==

v Tiers: Servicesv Commands: Importv Components: Allv Optional

Engine tier properties

Set the following properties to define your InfoSphere Information Server enginetier environment.

datastage.engine.admin.usernameThis property defines the user name of the InfoSphere Information Serverengine authenticated user. The InfoSphere Information Server engineauthenticates users separately from other InfoSphere Information Servercomponents. The user that you specify for this property must meet thefollowing requirements:v Is the operating system user or the LDAP user that your local

installation uses to connect to the InfoSphere Information Server enginev Has credentials that correspond to the engine tier operating system user

credentialsv Has read and write access to the engine directory and subdirectoriesv 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: Enginev Commands: Import, Exportv Components: DataStage, QualityStage, Information Analyzerv Required

datastage.engine.admin.passwordThis property defines the password of the InfoSphere Information Serverengine authenticated user. Passwords are typically encrypted.

The sample file includes the following default entry and value:datastage.engine.admin.password=y010UWxT1hqqCqirnRj2zg==

v Tiers: Enginev Commands: Import, Exportv Components: DataStage, QualityStage, Information Analyzerv Required

datastage.engine.enginepathThis property defines the absolute path to the InfoSphere InformationServer engine directory. If you do not specify a directory name for thisproperty, 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 asappropriate: datastage.engine.enginepath=/opt/IBM/InformationServer/Server/DSEngine

IBM Confidential


v Tiers: Enginev Commands: Import, Exportv Components: DataStage, QualityStage, Information Analyzerv Optional

datastage.engine.asbhomeThis property defines the absolute path to the ASBNode directory. If youdo not specify a directory name for this property, the directory that isspecified in the Version.xml file is used and a single ASBnode directory isassumed to exist in the default /install_dir/ASBNode directory.

Windows The sample file includes the following default entry and value:datastage.engine.asbhome=C:\\IBM\\InformationServer\\ASBNode.

Linux UNIX Specify a value for other operating systems asappropriate: datastage.engine.asbhome=/opt/IBM/InformationServer/Server/ASBNode

v Tiers: Enginev Commands: Import, Exportv Components: DataStage, QualityStage, Information Analyzerv Optional

datastage.engine.update.projectWhen this property is not specified, or is set to true, the default behavioris to automatically update the projects. Your projects are automaticallyupdated if your target installation meets the following requirements:v The services tier and engine tier are on the same computer, orv 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 notmeet the requirements, or if you want to prevent automatic update of themigrated projects on the target installation. If you set this property tofalse, you must complete the to-do activities in the migration.todo.txtfile to update the migrated projects.

The sample file includes the following default entry and value:datastage.engine.update.project=true

v Tiers: Enginev Commands: Importv Components: DataStage, QualityStage, Information Analyzerv Optional

Metadata repository database properties

Set the following properties in the migration.properties file on the services tier todefine the metadata repository environment.

xmeta.gendb.directoryUse this property to manually backup and restore your metadatarepository database. You must specify the absolute path to the directorywhere you want to generate the database migration scripts on the servicestier computer. Enable this property only when your installation meets atleast one of the following requirements:

IBM Confidential


v Your services tier and your metadata repository tier are installed ondifferent computers in the source installation.

v Your services tier and your metadata repository tier are installed ondifferent computers in the target installation.

v Your site requires a database administrator to do the metadata repositorydatabase migration, for example, database migration requires an audit ora different user.

Windows The sample file includes the following default entry and value:xmeta.gendb.directory=C:\\Migration\\db-scripts.

Linux UNIX Specify a value for other operating systems asappropriate: xmeta.gendb.directory=/opt/users/db2inst1/sqllib/db-scripts

v Tiers: Servicesv Commands: Import, Exportv Components: Allv Required when the metadata repository database is remote from the

services tierv Optional when the metadata repository database is on the same

computer as the services tier

When you do not specify a directory for this property, the metadatarepository tier is assumed to be on the same computer as the services tierand the exported archive file automatically includes the metadatarepository database. For more details on using this property, see “Migratedatabases manually by using scripts” on page 43.

xmeta.db.binpathThis property specifies the absolute path to the metadata repository bindirectory. For example, the metadata repository bin directory entries forWindows 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 SQLServer\90\Tools\Binn

Windows The sample file includes the following default entry and value:xmeta.db.binpath=C:\\IBM\\SQLLIB\\bin.

Linux UNIX Specify a value for your database server and otheroperating 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: Servicesv Commands: Import, Exportv Components: Allv Required

IBM DB2 database: Metadata repository properties

The following property defines the metadata repository environment when themetadata repository is hosted on an IBM DB2 database server.

IBM Confidential


xmeta.db2.installdirThis property specifies the absolute path to the directory where themetadata repository database is stored on the metadata repository tiercomputer.

Windows The sample file includes the following default entry and value:xmeta.db2.installdir=c:\\.

Linux UNIX Specify a value for other operating systems asappropriate: xmeta.gendb.directory=/opt/IBM/InformationServer/Repos

v Tiers: Servicesv Commands: Importv Components: Allv Required when the metadata repository database is installed on a DB2

database server

xmeta.db2.admin.usernameThis property specifies the user name of the DB2 database user who hasSYSADM, SYSCTRL, or SYSMAINT privileges and who can run backupand restore operations on the metadata repository database.

Default: xmeta.db2.admin.username=db2inst1

v Tiers: Servicesv Commands: Import, Exportv Components: Allv 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 themetadata repository is hosted on an Oracle database server.

xmeta.oracle.sys.usernameThis property specifies the name of the metadata repository databasesystem user who has sysadm, sysctrl, or sysmaint authorization.

Default: xmeta.oracle.sys.username=system

v Tiers: Servicesv Commands: Import, Exportv Components: Allv Required when the metadata repository database is installed on an

Oracle database server

xmeta.oracle.sys.passwordThis property specifies the password of the metadata repository databasesystem user.

Default: xmeta.oracle.sys.password= y010UWxT1hqqCqirnRj2zg==



IBM Confidential


xmeta.oracle.sys.servicenameThis property specifies the metadata repository database system ID (SID).

Default: xmeta.oracle.sys.servicename=XMETA



xmeta.oracle.tablespacenameThe case-sensitive name of table space on the metadata repositorydatabase. The table space name must be the same on the source and targetinstallations.

Default: xmeta.oracle.tablespacename=XMETATBS



xmeta.oracle.datadumpfolderThis property specifies the absolute path to the directory where theexported dump data is generated by Oracle.

Windows The sample file includes the following default entry and value:xmeta.oracle.datadumpfolder=C:\\oracle\\product\\10.2.0\\admin\\souce_inst\\dpdump.

Linux UNIX Specify a value for other operating systems asappropriate: xmeta.oracle.datadumpfolder=/opt/oracle\\product\\10.2.0\\admin\\souce_inst\\dpdump

v Tiers: Servicesv Commands: Exportv Components: Allv Required when the metadata repository database is installed on an


xmeta.oracle.datafilefolderThis property specifies the absolute path to the directory where the datafile is stored.

Windows The sample file includes the following default entry and value:xmeta.oracle.datafilefolder=C:\\oracle\\product\\10.2.0\\oradata\\target_inst.

Linux UNIX Specify a value for other operating systems asappropriate: xmeta.oracle.datadumpfolder=/opt/oracle/product/10.2.0/admin/souce_inst/dpdump

v Tiers: Servicesv Commands: Importv Components: Allv Required when the metadata repository database is installed on an


IBM Confidential


Microsoft SQL Server: Metadata repository properties

The following property defines the metadata repository environment on the targetinstallation when the metadata repository is hosted on an SQL Server database.

xmeta.sqlserver.datafolderThis property specifies the absolute path to the directory where themetadata repository database is stored on the target installation.

Windows Default: xmeta.sqlserver.datafolder=C:\\ProgramFiles\\Microsoft SQLServer\\Data

v Tiers: Servicesv Commands: Importv Components: Allv Required when the metadata repository database is remotely installed on

an SQL Server database server

IBM InfoSphere Information Analyzer analysis databaseproperties

When InfoSphere Information Analyzer is installed, use the following properties todefine the database environment for the InfoSphere Information Analyzer analysisdatabase.

ia.migrate.analysisdb.enabledIf you want to migrate the InfoSphere Information Analyzer analysisdatabase, set this property to true.v Tier: Servicesv Commands: Import, Exportv Components: Information Analyzerv Optional. Use only if you want to migrate the analysis database from the

source system to the target system.

ia.gendb.enabledIf you need to migrate the analysis database manually, use this property toenable ia.gendb.directory, which generates the database scripts that youuse to manually backup and restore your InfoSphere Information Analyzeranalysis database. When you set ia.gendb.enabled=true and theia.gendb.directory is set to valid path, the InfoSphere InformationAnalyzer scripts are generated. The database administrator must manuallyexecute scripts to move the analysis database.

Note: If you want to set this property to true, make sure that you also setia.migrate.analysisdb.enabled=true.v Tiers: Servicesv Commands: Import, Exportv Components: Information Analyzerv Required when the analysis database is installed on a remote database

serverv Optional when the analysis database is on the same computer as the

services tier

ia.gendb.directoryDirectory where the InfoSphere Information Analyzer repository scriptswill be generated for the database administrator to execute.

IBM Confidential


If you set ia.gendb.enabled=true, you must specify the absolute path tothe directory where you want the migration scripts to be generated on theservices tier computer. If your analysis database is not on the services tiercomputer, you must move the scripts to the metadata repository tiercomputer before you can run the scripts. You must review the readme.txtfile that is generated with the scripts, and then manually edit the scriptsfor 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 thetarget 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 asappropriate: ia.gendb.directory=/opt/Migration/ia-db-scripts

Note: The ia.gendb.directory property works independently of thexmeta.gendb.directory property. Be sure to specify a directory name that isdifferent from the directory that might be specified forxmeta.gendb.directory.v Tiers: Servicesv Commands: Import, Exportv Components: Information Analyzerv Required only if you set ia.gendb.enabled=true to migrate the analysis

databases manually

ia.keep.analysisengine.optionsThis property specifies to retain the When set to true, preserve theInfoSphere Information Server engine settings on the target installation.When this property is set to false or is omitted, the engine settings on thetarget installation are not preserved and the engine settings from thesource installation are set.

Default: ia.keep.analysisengine.options=true

v Tiers: Servicesv Commands: Import, Exportv Components: Information Analyzerv Optional

ia.keep.analysisdb.optionsWhen set to true, preserve the InfoSphere Information Analyzer analysisdatabase settings on the target installation. When this property is set tofalse or is omitted, the analysis database settings on the target installationare not preserved and the analysis database settings from the sourceinstallation are set.

Default: ia.keep.analysisdb.options=true

v Tiers: Servicesv Commands: Import, Exportv Components: Information Analyzerv Optional

IBM Confidential


IBM DB2: Analysis database properties

The following properties define the database environment when the InfoSphereInformation 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.binpathAbsolute 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.

Linux UNIX Specify a value for your database server and otheroperating 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

v Tiers: Servicesv Commands: Import, Exportv Components: Information Analyzerv Required when the analysis database is installed on the DB2 database

server

ia.db2.installdirAbsolute path to the directory where the analysis database is stored on themetadata 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 asappropriate: ia.db2.installdir=/opt/users/db2insta1/sqllib

v Tiers: Servicesv Commands: Import, Exportv Components: Information Analyzerv 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 InfoSphereInformation Analyzer analysis database is hosted on an Oracle database server.Specify these properties to define the migration environment for the analysisdatabase.

Migrations of multiple InfoSphere Information Analyzer analysis databases iscurrently not supported.

ia.oracle.sys.usernameThe analysis database system user name. This user must have sysadm,sysctrl, or sysmaint authorization.

Default: ia.oracle.sys.username=system

v Tiers: Servicesv Commands: Import, Export

IBM Confidential


v Components: Information Analyzerv Required when the analysis database is installed on the Oracle database

server

ia.oracle.sys.passwordThe analysis database system user password.

Default: ia.oracle.sys.password= y010UWxT1hqqCqirnRj2zg==

v Tiers: Servicesv Commands: Import, Exportv Components: Information Analyzerv Required when the analysis database is installed on the Oracle database

server

ia.oracle.sys.servicenameThe analysis database system ID (SID).

Default: ia.oracle.sys.servicename=IADB


server

ia.oracle.tablespacenameThe case-sensitive name of the table space on the analysis database. Thetable space name must be the same on the source and target installations.

Default: ia.oracle.tablespacename=IADBTBS


server

ia.oracle.datafilepathAbsolute path to the directory where the analysis database table space isstored 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 asappropriate: ia.oracle.datafilepath=/opt/oracle\\product\\10.2.0\\admin\\souce_inst\\IADBTBS.DBF

v Tiers: Servicesv Commands: Exportv Components: Information Analyzerv Required when the analysis database is installed on the Oracle database

server

ia.oracle.datadumpfolderAbsolute path to the directory where the exported dump data is generatedby Oracle.

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.

Linux UNIX Specify a value for other operating systems asappropriate: ia.oracle.datadumpfolder=/opt/oracle/product/10.2.0/admin/souce_inst/dpdump

v Tiers: Servicesv Commands: Exportv Components: Information Analyzerv Required when the analysis database is installed on the Oracle database

server

ia.oracle.datafilefolderThe 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.

Linux UNIX Specify a value for other operating systems asappropriate: ia.oracle.datadumpfolder=/opt/oracle/product/10.2.0/admin/target_inst

v Tiers: Servicesv Commands: Importv Components: Information Analyzerv 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 installationwhen the InfoSphere Information Analyzer analysis database is hosted on an SQLServer database server.

ia.sqlserver.datafolderThe absolute path to the directory where the analysis database is stored onthe target installation.

Windows Default: ia.sqlserver.datafolder=C:\\Program Files\\MicrosoftSQLServer\\Data

v Tiers: Servicesv Commands: Importv Components: Information Analyzerv Required when the analysis database is installed on the SQL Server

database server

Host change fileThe host change file is required when your target installation topology is differentthan your source installation, has more than one engine tier, or when the enginetier is installed on a computer without a services tier.

IBM Confidential


Purpose

The host change file identifies the host names of the engine tier computers in thesource and target installations. You can also include entries in the host change fileto specify different port numbers and project locations for your target installation.

The ismigration tool automatically resolves host information for the followingmigrations:v Single tier topology installationsv 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.xmlfile that is created when the export is completed.

Optionally, you can use the IBM Support Assistant Lite for InfoSphere InformationServer tool to gather the required installation information from your source andtarget installation.

Syntax

The host change file adheres to the following conventions:v XML formatv Case-sensitivev Create a Host tag for each computer that you are migratingv Create an entry for each engine tier, if your installation has more than onev Enter values for the source installation computer and the target installation

computer, as appropriate for your installationv 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 ofComputerA.

The following example host change file supports migration from a single-tiersource installation with the services, metadata repository, and engine tiers installedto a three-computer target installation. There is no change to port numbers orproject locations.

Table 10. One-computer source installation migration to three-computer target installation

Installation tier Source values Target values

Services ComputerA ProdB

Engine SystemA 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 totwo target computers, and the port number and project location change.

The source installation engine tier computer contains the following server nameand port number:

IBM Confidential


agent.servername=ComputerAagent.port=31531

The engine tier computer on your target installation contains the following servername and port number in the agent.properties file:agent.servername=ComputerCagent.port=31561

Table 11. One-computer source installation to two-computer target installation with port andproject location changes

Installation tier Source values Target values

Engine SourceHost Target.Host.2

Port number 31531 31561

Project location ProjectA /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 thehost name that you provided at installation is xyz00011.ghi.amsu.hal.com, youmust specify the host name as xyz00011.ghi.amsu.hal.com, not xyz00011.

Userfiles specifies additional files to include in archiveTo specify the list of files to include, use the -userfiles parameter when you runthe ismigration tool to export your installation. The -userfiles parameter specifiesthe name of a text file that contains a list of additional files to include in themigration archive file.

The file that you specify with the -userfiles parameter must adhere to thefollowing 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 thearchive file (hostname_TIER_timestamp.iar) that you generate with the exportcommand. When you import the archive file to your target installation, the filesthat are listed in the text file that you specify with the -userfiles parameter are alsoimported.

After the ismigration tool export process is completed, all the files that you arerequired to move to your target installation are automatically specified in themigration.todo.txt file that is generated for each services and engine tiercomputer. For example, the configuration files that are required for your IBMInfoSphere DataStage and QualityStage jobs are listed in the migration.todo.txtfile that is generated for the services tier computer.

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 archivefile 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

v Windows

C:\IBM\InformationServer\Migration\bin\ismigration.bat -export -archive \tmp\archive-userfiles C:\IBM\InformationServer\Migration\conf\exportfiles.txt

Migration log filesThe ismigration tool log files contain information that can be used fortroubleshooting purposes.

The ismigration log files are in the default logs directory as follows:

v Linux UNIX /opt/IBM/InformationServer/Migration/logs

v Windows 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 witha size of 0 KB.where n is an incremental number starting at 0, and incremented at 1 with eachsubsequent migration. When new log files are generated, the newest log filesstart at 0 and the existing files are renamed with incremented file names. Up toten log files are retained in the logs directory.

migration.todo.txt fileThe ismigration tool generates a migration.todo.txt file for each computer afterthe export and import processes are completed.

Purpose

The migration.todo.txt file is generated in the Migration folder on each servicesand engine tier computer after the migration is completed. You must review eachsection in the file, and complete the required to-do activities before you continuethe migration. Entries in the migration.todo.txt file vary, based on yourinstallation environment.

IBM Confidential


Export entries in the migration.todo.txt file

After the migration export is completed on each source installation computer, therequired activities that are listed in the migration.todo.txt file reflect yourinstallation environment and configuration. Review each section carefully andcomplete the required activities.

IBM InfoSphere Information Server entries

Entries vary, based on your installation environment. For example, whenthe Java messaging system exists, an entry like the following is shown:Please ensure that the following JMS elements, which are referenced byone or more ISD applications, are configured in the application serveron the target computer.

jms/Queue1jms/ConnFactory1jms/ActSpec1

The source installation host names are recorded in theHostChangeConfigTemplate.xml file in the Migration directory. The entry inthe migration.todo.txt file is provided as a reference to theHostChangeConfigTemplate.xml.

The InfoSphere Information Server entry in a migration export looks likethe following example:’HostChangeConfigTemplate.xml’ was generated and placed in Migrationdirectory.You can use this file as a starting point if you plan to migrate theproduct to different servers.Additionally, you can run import on the SERVICES tier with -validateonlyoption to have source and target host names for both ENGINE and SERVICEStiers printed exactly as they are used in the installation. You can thenenter these host names in the host change configuration file.

Oracle exportWhen you export the metadata repository database or the IBM InfoSphereInformation Analyzer analysis database, any existing database dump file ispreserved and renamed. To preserve disk space, you must manually deletethe 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, therequired activities that are listed in the migration.todo.txt file reflect yourinstallation environment and configuration. Review each section of the file andcomplete the required to-do activities.

IBM InfoSphere DataStage entriesWhen your target installation includes InfoSphere DataStage, themigration.todo.txt file specifies the activities that are required to ensurethat the migrated jobs will run in the new Version 8.5 installation.

The InfoSphere DataStage entries in a migration import to a MicrosoftWindows computer with InfoSphere DataStage installed looks like thefollowing example:

IBM Confidential


In order to ensure your migrated Jobs function correctly, please make sureyou install all Information Server Packs that were installed on the sourcesystem....The following SQL users were not transferred across to the new system.NT AUTHORITY\systemhawkIS85MIGQA-07\hawkA copy of the file ’default.apt’ from the source system has been copied tothe 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 theAPT_CONFIG_FILE environment variable, it will need to be copied overmanually.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 copiedto 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 scriptto "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

IBM Confidential


Part 3. Version 7.5.3 and earlier migrations

IBM Confidential


IBM Confidential


Chapter 8. Migrations from Version 7.5.3 and earlier

You can migrate from previous versions of DataStage, QualityStage, andWebSphere RTI to a new IBM InfoSphere Information Server, Version 8.5installation.

Export projects and jobs from release 7.5.3 and earlier versions of DataStage andQualityStage and then import the projects and jobs to an InfoSphere InformationServer, Version 8.5 installation.

You can also migrate from IBM WebSphere RTI 7.5, 7.5.1, and 7.5.2 to IBMInfoSphere Information Services Director, Version 8.5 and subsequent releases.

DataStage Version 6 is the earliest release that is supported for migration toVersion 8.5.

Note: This export and import migration method for release 7.5.3 and earlierversions of DataStage, QualityStage, and WebSphere RTI does not use theismigration tool.The DataStage Version Control component is not supported by InfoSphereInformation Server, Version 8.5. Instead, use Information Server Manager tointegrate a supported source control system.

IBM Confidential


IBM Confidential


Chapter 9. Migration from DataStage 7.5.3 and earlier versions

Migration involves exporting DataStage projects and saving the settings files fromthe existing installation, and then importing the projects and moving the settingsfiles to the Version 8.5 installation.

This migrate method applies to the development environment where thedesign-time information resides and moves all of your migrated projects to IBMInfoSphere Information Server, Version 8.5.

Complete the following activities to migrate your source DataStage 7.5.3 andearlier 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 theIBM 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” onpage 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 todifferent computers for your Version 8.5 installation, or to the same computers byusing an ITAG installation. This migration method information applies tomigration to different target computers or the same computers for source andtarget installations. ITAG installations exist when you install more than oneinstance of DataStage or InfoSphere Information Server on the same set of Linux orUNIX computers.

Exporting projectsYou export your DataStage projects from your source installation before migratingthe 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 clientYou can use the DataStage Manager client to export projects from yourdevelopment environment.

IBM Confidential


Note: The current version of your installation determines the name of theDataStage Manager client. Your installation might refer to the client as theDataStage 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 inwhich 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 exportfile.

Exporting projects from the command lineYou can use the command line on the client computer to export your projects fromyour development environment. You can create a script that runs these commandsand exports all of your projects in a single operation.

Export your projects from your source installation before you import the projects toyour 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_nameexport_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 thatis located on the DataStage server named R101 and writes the project to a filenamed monthlyaudit.dsx. The target file is located in a directory namedmigrated_projects on the client computer.dscmdexport /H=R101 /U=BillG /P=paddock monthlyauditC:\migrated_projects\monthlyaudit.dsx

You can enter a command for each project that you want to export, or you cancreate a script that contains commands for all of the projects on your DataStageserver computer.

IBM Confidential


Saving DataStage settings filesBack up your settings files on your existing DataStage server.

After you install IBM InfoSphere Information Server, Version 8.5, you can compareeach of your saved settings files with the equivalent new file. You can thenintegrate the two files. You must not replace the new files with the files that yousaved from your existing installation, because you will overwrite new settings.

The files that you copy depend on whether your DataStage server is on a Windowscomputer, 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 yourDataStage installation.

By default the engine directory is /user_home/Ascential/DataStage/DSEngine,where user_home is the home directory of the DataStage administrator whooriginally installed DataStage (by default, dsadm). Each project is in its owndirectory in the /user_home/Ascential/DataStage/Projects directory.

1. Copy the $DSHOME/dsenv file to a location outside of the DataStage filestructure.

2. To keep a record of the existing configuration and the configuration of yourODBC drivers, copy the following files to a location outside of the DataStagefile structure:v $DSHOME/.odbc.ini

v $DSHOME/uvodbc.config

v The uvodbc.config file located in each project directory3. 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 acopy of the DSParams file from each project directory.

Each project has its own directory located, by default, in the directoryC:\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.

IBM Confidential

Chapter 9. Migration from DataStage 7.5.3 and earlier versions 75

Move job dependency objectsThe jobs in your projects might depend on objects outside of DataStage. You mustmove 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, orv If you are installing InfoSphere DataStage on a different computer.

Note: If you have flat files, hashed files, or other dependencies that are located inyour 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 theexport procedure.

The DataStage export procedure exports DataStage objects, such as job designs,table definitions and custom routines. If the jobs in your projects have otherdependencies, then you might need to move these dependencies. Dependenciesinclude flat files, files containing schemas used by parallel jobs, and libraries thatare called by parallel job custom routines. It does not include parallel job data setsor file sets. If you are using data sets or file sets to permanently store data, thenyou 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 operatingsystem commands. You might need to modify job designs to identify the newlocations of these files.

If there are server jobs in your projects that use hashed files, then you must use adedicated procedure to move the hashed files.

Migrating hashed filesIf your DataStage project contains server jobs that use hashed files, then you needto 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 hashedfiles 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 thetarget 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 twofiles named price_lookup and d_price_lookup.

v Each dynamic hashed file is represented by a directory with the same nameas the hashed file and a file named D_hashed_file_name. For example, adynamic hashed file named code_lookup is represented by the directorynamed code_lookup and the file named D_code_lookup.

2. Copy the files or directories that represent each of your hashed files to a safelocation outside of the DataStage directory structure.

You can restore these files after you install and configure InfoSphere DataStage.

IBM Confidential


Remove previous versions of DataStageRemoving DataStage completely removes your current version of DataStage fromserver and client computers.

Ensure that your DataStage server computer is backed up before you removeDataStage, and that no one is using DataStage.

There are separate procedures for removing DataStage clients and removingDataStage servers.

Removing a DataStage server (Windows)You use Windows Add or Remove Programs to remove an existing DataStageserver from a Windows computer.

Ensure that DataStage is not running and ensure that no clients are connected tothe 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 aUNIX 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 Command

Solaris uninstll.sh

AIX® uninstll.sh

HP-UX ‘UNINSTLL.SH;1‘

LINUX ‘uninstll.sh‘

The uninstallation program guides you through the procedure for removing theDataStage server.

Removing DataStage clientsYou use Windows Add or Remove Programs to remove existing DataStage clientsfrom a Windows computer.

Ensure that nobody is using DataStage and that no clients are connected to theDataStage server.

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 projectsImport the projects to your Version 8.5 installation.

Import projects from earlier versions of DataStage to your Version 8.5 developmentenvironment.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 originalprojects 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 thesame 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.5environment and then import them to your Version 8.5 productionenvironment.

Restoring contents of DataStage 7.5.3 or earlier settings filesIf 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 onlyadd or edit settings in the new files. Do not delete settings. Use this procedurewith 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 dependenciesYou must restore any DataStage job dependencies that you saved.

IBM Confidential


After you migrate to Version 8.5, restore job dependency files to your newinstallation.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 torestore was in the project directory in your previous DataStage installation, findthe 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 isreferred to by a job parameter, you might need to edit the default value of theparameter to reference the new location for the file.

Restoring hashed filesYou need to restore the hashed files that you saved.

To restore hashed files, use IBM InfoSphere DataStage to create empty hashed filesfor each of the files that you want to restore. You then replace the empty files withthe 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 themigrated 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 thehashed 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 services8. 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.

IBM Confidential


Your hashed files are now available for use.

Recompiling jobsYou must recompile the jobs and routines in the migrated projects to create newexecutable 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 orAdvanced 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:v Serverv Parallelv Mainframev Sequencev Custom server routinesv 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 SelectionOverride screen appears. Choose jobs in the left pane and add them to the rightpane by using the Add buttons or remove them from the right pane by usingthe Remove buttons. Clicking Add while you have a folder selected selects allthe items in that folder and moves them to the right pane. All the jobs in theright pane will be compiled.

3. Click Next>. If you are compiling parallel or mainframe jobs, the CompilerOptions screen appears, allowing you to specify the following: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 theselected items and their current compile status.

5. Click Start Compile to start the compilation. As the compilation proceeds, thestatus changes from Queued to Compiling to Compiled OK or Failed anddetails about each job are displayed in the compilation output window as itcompiles. Click the Cancel button to stop the compilation, although you canonly cancel between compilations so the Designer client might take some timeto respond.

6. Click Finish. If the Show compile report checkbox was selected, the jobcompilation report screen appears, displaying the report generated by thecompilation.

Updating jobs that use the QualityStage 7.5 plug-inIf you have existing DataStage jobs that use the QualityStage plug-in stage toconnect to QualityStage 7.5, and you want to continue running those jobs, thenyou 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 importthe jobs to Version 8.5, rewrite the jobs to use the parallel canvas and the Version8.5 stages.

IBM Confidential


Switching between different versions of clientsYou can install different versions of DataStage clients on a single Windowscomputer 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 than7.0. For DataStage releases earlier than 7.0, install each client version on a separatecomputer.

When your organization is using different versions of DataStage, it is useful tohave different client versions on your Windows computer. You can then switchbetween 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 oneof your installations, while still running WebSphere DataStage, Version 7.5.3 onanother installation, you can have the clients for both releases on a client tiercomputer, and switch between the clients as necessary.

You can install multiple DataStage clients by running the client installer (versionsearlier than WebSphere DataStage 8.0), or running the suite installer and selectingonly 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 thatinstance and install IBM InfoSphere Information Server, Version 8.5. You can alsoinstall multiple IBM InfoSphere DataStage engine tiers.

Each engine tier must be registered to a different instance of the IBM InfoSphereInformation Server services tier.

Note: There is a change of terminology between DataStage 7 and InfoSphereDataStage, Version 8.0.1 and later. In earlier versions the engine component wasidentified as the DataStage server, for release 8.0.1 and later, the engine componentis identified as the engine tier.

If you maintain different releases of DataStage server, or multiple instances of thesame server, you can keep all of those instances. You can also upgrade each ofthese servers to InfoSphere DataStage, Version 8.5 and keep their existing identityinformation.

Each instance of a DataStage server is identified by a tag ID (an ITAG) andallocated a different port. You also specify a different home directory for each

IBM Confidential


server. Each DataStage server has a different set of projects that you access throughthat server. You connect to different servers by specifying the port number inaddition to the UNIX server ID.

The existing DataStage server instance retains the default port number, 31538, anduses the default ITAG, ADE. If you already have multiple server instances, thenyou already have servers that use different ports and ITAGs.

Each version of DataStage requires clients of the same version. You must use theMulti-Client Manager program to switch between different client versions on yourWindows client computers.

You can use the multi-server facility to install multiple instances of the InfoSphereDataStage, Version 8.5 engine tier on the same computer. When multiple instancesof the engine tier are installed on the same computer, each engine tier requires aunique profile for IBM WebSphere Application Server.

The following table shows a scenario of a multi-server installation, and illustratesthe use of port numbers and ITAGs.

Table 12. Scenario 1: InfoSphere DataStage, Version 8.5 server installed on the samecomputer as an existing DataStage 7.5.1 server

Engine tier instance Server details

WebSphere DataStage, release 7.5.1 server 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 threeservers, and illustrates the use of port numbers and ITAGs.

Table 13. Scenario 2: InfoSphere DataStage, Version 8.5 server installed on the samecomputer as two existing DataStage 7.5.1 servers


WebSphere DataStage, release 7.2 server v Itag ADE

v Port 31538


WebSphere DataStage, release 7.5.1 server v Itag A23

v Port 31546



v Port 31540


The following table shows a scenario of with three Version 8.5 servers, andillustrates the use of port numbers and ITAGs for Version 8.5 installations.

IBM Confidential


Table 14. Scenario 3: Three instances of InfoSphere DataStage, Version 8.5 server installedon the same computer


InfoSphere DataStage, Version 8.5 server v Itag ADE

v Port 31538


InfoSphere DataStage, Version 8.5 server v Itag BED

v Port 31540

v /opt2/IBM/InformationServer/Server


v Port 31542

v /opt3/IBM/InformationServer/Server

Installing Version 8.5 in addition to existing DataStage serversYou can maintain existing DataStage server instances while installing IBMInfoSphere Information Server, Version 8.5.

The Version 8.5 installation wizard detects existing DataStage servers duringinstallation. You must provide a unique ITAG value and port number to use forthe Version 8.5 server.

Installing IBM InfoSphere DataStage, Version 8.5 clients inaddition to existing clients

When you maintain multiple versions of the InfoSphere DataStage server on Linuxor UNIX computers, you must maintain corresponding client versions on Windowscomputers.

You need the IBM InfoSphere Information Server, Version 8.5 client installationsoftware and the IBM InfoSphere Information Server Planning, Installation, andConfiguration 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 Windowscomputer as your existing DataStage clients, and use the Multi-client Manager toswitch between the different versions. You can also install InfoSphere DataStage,Version 8.5 clients on a separate Windows computer. If you are installing clients ona computer with existing clients, the client installation program detects theirpresence 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 yourinstallation plan.

IBM Confidential


Starting and stopping multiple DataStage serversWhen multiple DataStage servers are on a single computer, you must identify theserver 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 theserver. For example, there are two servers on the same computer with thefollowing 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 serversTo 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 computerwhere the server is located.

You use a different procedure depending on the version of DataStage server andthe client, and whether you are connecting from the command line. The clients forDataStage release 7 attach directly to the engine; the clients for InfoSphereDataStage, 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 earlierUse this procedure to connect to a DataStage version 7.5.3 or earlier server fromany client other than the Administrator client.

If multiple versions of the DataStage clients are on your computer, ensure that thesame version as the server version is currently selected in the Multi-ClientManager.

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 theport number that the server uses. For example, type R101:31538 in the HostSystem field.

3. Type your user name and password.4. Specify the name of the project that you want to attach to.

IBM Confidential


Connecting to DataStage version 7.5.3 or earlier from theAdministrator clientUse this procedure to connect to a DataStage version 7.5.3 or earlier server fromthe Administrator client.

If multiple versions of the DataStage clients are on your computer, ensure that thesame version as the server version is currently selected in the Multi-ClientManager.

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 isthe port number that the server uses. For example, type R101:31538 in the HostSystem field.

3. Type your user name and password.

Connecting to IBM InfoSphere Information Server, Version 8.5Use 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 thesame client version as the server version is currently selected in the Multi-ClientManager.

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 formDomainServer: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 numberthat the server uses. For example, type R101:31348/datastage.

Connecting to IBM InfoSphere DataStage and QualityStage,Version 8.5 from an Administrator clientUse 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 yourcomputer, ensure that the same version as the server version is currently selectedin 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 formDomainServer:9080. For example, type R101:9080 in the Domain field or typeR201: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

IBM Confidential


where portnumber is the port number that the server uses. For example, typeR201:9080 or type R301:80 if you are using a front-end Web server.

Connecting to a Version 8.5 DataStage server from the commandlineYou can use the command line interface to control DataStage jobs in differentprojects.

These instructions assume that you are logged in to the operating system as theuser 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 serverinstances, you must specify the domain and the server name in the form-domain domain:domain_portnumber -server server:portnumber. The default domainport number is 9080. For example, to run a job on the local computer on theserver that uses port 31359, run this command: dsjob -server r101:31359 -runmyproj 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 thatuses port 31360, you must also specify the host computer, the domain, andsupply the login information. For example, enter the following command: dsjob-domain mydomain:9080 -server r101:31360 -user billg -password paddock-run myproj myjob

IBM Confidential


Chapter 10. Migration from QualityStage 7.5 and earlierreleases

Required premigration tasks if your Version 7.5 or earlier source installationincludes QualityStage.

If QualityStage 7 is installed, you need to migrate your jobs to Version 8.5. (Theterm '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 willneed to be edited after they are migrated to the Version 8.5 installation. To runthese jobs after migration, you must configure the jobs to use the available stagesin Version 8.5. The QualityStage plug-in is not available or supported in Version8.5.

QualityStage 7 provides a method to migrate QualityStage 7 jobs, matchspecifications, and standardization rule sets to the InfoSphere DataStage andQualityStage Designer client in the Version 8.5 environment. In legacy mode yourmigrated job will use the QualityStage Legacy stage. In expanded form, yourmigrated job will make full use of all the specialized data quality stage types aswell as the QualityStage Legacy stage.

If you are migrating to a platform that was supported by QualityStage 7, then youcan migrate by using legacy mode or expanded form. If the platform was notsupported 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 projectdirectory to build the .dsx file format that InfoSphere DataStage and QualityStagerequires to import jobs.

The migration utility migrates the following QualityStage 7 objects:v Standardization rule setv Jobs in full legacy operational modev Jobs in expanded form, in which some legacy operations are replaced by

InfoSphere DataStage and QualityStage, Version 8.5 stagesv Match specification

You export projects to create a .dsx file that contains migrated jobs, rule sets, andmatch specifications in the Temp directory in the QualityStage 7 project directory.

Job migration in legacy operational modeWhen you migrate QualityStage 7 jobs in full legacy operational mode, the originaljob is replaced with a single instance of a QualityStage Legacy stage andSequential File stages linked as source and target stages.

If you migrate a QualityStage 7 job in legacy operational mode, you can make onlyminor changes to the resulting QualityStage Legacy stage. Use this option only forstable jobs that will not be modified or jobs that are due to be replaced.

IBM Confidential


Note that, in a Japanese environment, the migrated job uses Data Set stages insteadof Sequential File stages. In this case, you must create an additional job that readsthe source data from the sequential file and writes it to a data set. The data set canthen be read by the migrated job. If your original job wrote results to a sequentialfile, then you must create another job to write the results from the data setproduced by the migrated job to a sequential file.

Do not use the legacy operational mode option if you are migrating a job thatcontains the following QualityStage 7 stages because their functionality is notsupported by the QualityStage Legacy stage:v Postal stages such as CASS and SERPv Program stagev Multinational Standardize stagev WAVES stagev Format Convert stage

QualityStage job migration in expanded formWhen you migrate a QualityStage 7 job in expanded form, the QualityStagemigration utility replaces the original job with one or more parallel job stages foreach stage in the QualityStage 7 job, and with Sequential File stages that are linkedtogether 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 hasequivalent functions.

Rule set migrationThe migration of a QualityStage 7 standardization rule set option migrates the rulesets explicitly by name.

When a QualityStage 7 job is migrated, the migration utility detects the dependentrule 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 namingduplication with a built-in IBM InfoSphere QualityStage, Version 8.5 rule set. Theutility uses the following naming convention:QS-7-Ruleset-Name_QS-7-Project-Name

Match specification migrationWhen 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 inthe .dsx file with the job, if you selected the option "plus dependencies" to migratethe job. Once the job is imported, you can locate the match specification in the IBMInfoSphere DataStage and QualityStage Repository → Match Specifications folder.

IBM Confidential


As with rule sets, match specifications are renamed when the information isimported. The match specification name has the following form:QS-7-RefMatch-or-UndupMatch-Stage-Name_QS-7-Project-Name

Installing the WebSphere QualityStage migration utilityUse the WebSphere QualityStage migration utility to migrate QualityStage Version7 to IBM InfoSphere QualityStage, Version 8.5. (The term 'QualityStage 7' refers toall 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 QualityStageserver on the same computer as the QualityStage 7 server.

Option Description

Installing the InfoSphere DataStage andQualityStage server on the same computeras the QualityStage 7 server

Install IBM Information Server, installing theengine tier on the computer where theQualityStage 7 server is installed. Themigration utility is installed with the enginetier.

Installing the InfoSphere DataStage andQualityStage server on a differentcomputer from the QualityStage 7 server(Windows or UNIX or Linux)

Install IBM Information Server on the targetcomputer. The migration utility is installedwith the engine tier. Before you run themigration utility on the target computer,make the QualityStage 7 project metadataavailable to the target computer. Make themetadata available by copying the entireQualityStage 7 project directory and all itscontents to the target computer, or bymaking the directory available via thenetwork (for example, by mapping a driveon Windows).

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 directorywhere the migration tool is installed). Make the changes before you use themigration 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 differentdrive 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 QualityStageVersion 7 jobs to InfoSphere DataStage and QualityStage, Version 8.5.

Running the QualityStage migration utilityRun the migration utility to create a file that contains the project metadata that isstored on a QualityStage 7 server.

IBM Confidential

Chapter 10. Migration from QualityStage 7.5 and earlier releases 89

The QualityStage migration utility runs on UNIX and Linux. For Windows, thescript requires the MKS (Mortice Kerns Systems) Toolkit. The MKS toolkit isinstalled with the IBM InfoSphere Information Server client.

The QualityStage migration utility is automatically installed when you install theInfoSphere DataStage and QualityStage component of the suite. By default, theQualityStage 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 projectdirectory that contains the jobs that you want to migrate. The utility returns alist 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 Steps for options

1. Migrate multiple QualityStage 7.x jobsplus dependencies

OR

2. Migrate multiple QualityStage 7.x jobs inexpanded form plus dependencies

1. Enter a name for the output file that themigration utility produces. All the objectsthat you migrate are written to this file.The utility reports the path name of thisfile each time it informs you of thesuccess or failure of an object migration.

2. When prompted with a job name, enter Yto migrate that job or N to skip that job.Repeat this step until you have migratedor skipped all the jobs.

3. When prompted with the name of a ruleset or a match specification, enter Y tomigrate that object or N to skip thatobject. Repeat this step until you havemigrated or skipped all the objects.

3. Migrate individual QualityStage 7.x job

OR

4. Migrate individual QualityStage 7.x job inexpanded form

When prompted, enter the name of the jobthat you want to migrate. The output filename is derived from the job name.

5. Migrate individual QualityStage 7.x jobplus dependencies

OR

6. Migrate individual QualityStage 7.x job inexpanded form plus dependencies

1. When prompted, enter the name of thejob that you want to migrate. The outputfile name is derived from the job name.

2. When prompted with the name of a ruleset or a match specification, enter Y tomigrate that object or N to skip thatobject. Repeat this step until you havemigrated or skipped all the objects

IBM Confidential


Option Steps for options

7. Migrate individual QualityStage 7.xstandardization rule set

When prompted, enter the name of the ruleset or match specification that you want tomigrate. The output file name is derivedfrom this name.

The QualityStage migration utility places the .dsx files that it creates in the Tempdirectory under the project directory. After you complete the migration of all ofyour jobs and objects, move the .dsx files to the computer where the Version 8.5IBM InfoSphere DataStage and QualityStage client is installed.

Importing the migrated files into the Version 8.5 Designerclient

After you complete the file migration, you must import the files into the metadatarepository.

Imports the contents of the migrated files into the Designer client. TheQualityStage clients in 7.5.3 and earlier are referred to as InfoSphere DataStage andQualityStage 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 areinstalled.

2. Open the Designer client and attach to the project where you want to save theInfoSphere 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 setsYou need to provision imported rule sets from the Designer client before a job thatuses 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 jobsthat used the expanded mode to migrate. If you used the expanded form, read theinstructions for preparing migrated jobs in the expanded format.

Preparing imported match specifications for useYou need to save the imported match specification in the InfoSphere DataStage andQualityStage Designer client and then provision the specification before you canuse it in a job.

Prepares imported match specifications for use.

IBM Confidential


1. In the Designer client, find the match specification within the repository treeProject → 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 operationYou must prepare migrated jobs before they can be run. The steps can varydepending on the migration option that you selected.

For jobs that you migrated in Legacy operational mode (options 1, 3, or 5), compilethe 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 varydepending on how you ran the job in previous versions of QualityStage. If youused any mode other than the parallel extender mode, the results might besignificantly different from previous runs.

2. If you did not previously run the job in parallel extender mode, insert a sortoperation 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 formatYou 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 youused any mode other than the parallel extender mode, the results might besignificantly different from previous runs.

6. If you did not previously run the job in parallel extender mode, insert a sortoperation into the job design:

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 qualityor 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 theQualityStage Legacy stages.

d. Configure the new stage or stages.e. Compile the job.

Preparing migrated jobs to use updated Address VerificationInterface and SERP librariesThe IBM InfoSphere QualityStage, Version 8.5 includes updated libraries for theAddress Verification Interface and SERP modules. You must update the migratedjobs to use these updated libraries before they can be run.

For details on the new output columns and how to update the migrated jobs, seethe release notes for the InfoSphere QualityStage modules.

Migrating real-time QualityStage jobs from Release 7 to Version 8.5To migrate Version 7 jobs that use the IBM InfoSphere QualityStage Real TimeClient API, you run the migration utility, replace legacy stages, and publish the jobas a service.

Before you publish real-time jobs as services, you must complete the followingtasks:v Install IBM InfoSphere Information Services Director, which is a component of

IBM InfoSphere Information Server. Unlike version 7, Version 8.5 requires thatyou use InfoSphere Information Services Director to publish jobs as services. Formore information about installing InfoSphere Information Server, see IBMInfoSphere 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 withthe behavior of the real-time stages. For more information about creatingreal-time jobs with two input sources InfoSphere DataStage and QualityStage,see IBM InfoSphere Information Services Director User Guide. A job can have onlyone ISD Input stage and only one ISD Output stage.

4. Update your jobs to add the ISD Output and ISD Input stages to replace thesequential input and output stages that exist in the migrated jobs.

IBM Confidential


5. Use InfoSphere Information Services Director to connect to InfoSphereQualityStage. For more information about connecting to InfoSphere DataStageand QualityStage, see IBM InfoSphere Information Services Director User Guide.

6. Develop an application, service, and operation by using InfoSphere InformationServices Director. Your migrated real-time job is the information provider forthe operation of the service. For more information about developingapplications, services, and operations, see IBM InfoSphere Information ServicesDirector User Guide.

7. Deploy the application as a service. For more information about deployingapplications, see IBM InfoSphere Information Services Director User Guide.

Replace InfoSphere QualityStage 7 data quality stagesYou can use the table of replacement stages to select the InfoSphere DataStagestage to substitute for the QualityStage 7 stage.

The following table lists replacement stages for previous versions of QualityStagestages.

Table 15. Replacement InfoSphere DataStage and QualityStage stages for migratedQualityStage stages.

QualityStage 7 Purpose Replacement stage

Abbreviate Creates match keys fromcompany names.

No direct replacement. Use theStandardize stage to reformatcompany names and pair with anappropriate match.

Build Rebuilds a single record frommultiple records that arecreated with a Parse stage.

No direct replacement. Build wasoften used with Parse to analyzemulti-domain data fields. UseStandardize to accomplish thesame function in one step.

Collapse Generates a list of eachunique value insingle-domain data fields.

Sort stage

Collapse Generates frequency counts ofdata values in a field or agroup of fields.

Aggregate stage

Format Convert Reformats files fromdelimited to fixed-length andvice versa.

Sequential File stage

Format Convert Provides I/O to an ODBCdatabase.

ODBC stage or database specificstage

Investigate Analysis of data quality. Investigate stage and theReporting tab for the WebConsolefor IBM Information Server.

Match Identifying data duplicates ina single file by using fuzzymatch logic.

Unduplicate Match stage inconjunction with the MatchFrequency stage.

Match Pairing records from one filewith those in another byusing fuzzy match logic.

Reference Match stage inconjunction with the MatchFrequency stage.

MultinationalStandardize

Standardize multinationaladdress data.

MNS stage

IBM Confidential


Table 15. Replacement InfoSphere DataStage and QualityStage stages for migratedQualityStage stages. (continued)

QualityStage 7 Purpose Replacement stage

Parse Tokenizes a text field byresolving free-form text fieldsinto fixed-format records thatcontain individual dataelements.

No direct replacement. Parse wasoften used with Build to analyzemulti-domain data fields. Use theStandardize stage to accomplishthe same function in one step.

Program Invokes a customer-writtenprogram.

Depends on the functionality ofthe customer-written program.Possibilities include adding aParallel Build, Custom, orWrapped stage type.

Select Conditionally routes recordsthat are based on values inselected fields.

Switch and Filter stages

Sort Sorts a list. Sort stage

Standardize Breaks down multi-domaindata columns into a set ofstandardized single-domaincolumns.

Standardize stage

Survive Produces the best resultsrecord from a group ofrelated records.

Survive stage

Transfer Rearranges and reformatscolumns in a record.

No separate stage is required todo this in QualityStage 8.

Transfer Acts as a gatekeeper for filesin non-standard formats(variable length records,non-standard code page,binary or packed data).

Sequential File or Complex FlatFile stage

Transfer Produces multiple outputrecords from a single inputrecord.

Splitting records can be achievedby Copy stage followed by Funnelstage

Transfer Adds record keys thatconsists of sequence numberplus an optional fixed "fileidentifier."

Surrogate Key Generator stage

Unijoin Join records from two filesbased on a key.

Join stage or Lookup stage

Unijoin Pairing records from one filewith those in another byusing fuzzy match logic.

Reference Match stage inconjunction with Match Frequencystage.

Unijoin Merges data from multiplerecords into one.

Join stage and Merge stage

Unijoin Manipulate and transformdata record.

Transformer stage

WAVES Standardize and validatemultinational address data.

WAVES stage

IBM Confidential


IBM Confidential


Chapter 11. Migration from IBM WebSphere RTI 7.5, 7.5.1, and7.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, Version8.5 installation.

After migration, you can use one of the following methods to administer anddeploy InfoSphere Information Services Director:v InfoSphere Information Services Director command line interfacev IBM InfoSphere Information Server console

Migrating RTIX files to Version 8.5Use the WebSphere RTI Export Wizard to migrate to IBM InfoSphere InformationServices 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.5installations.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 consoledesign function.

5. You must associate the imported service descriptions with an application objectbefore you can deploy the services. The import function is done at theapplication level to create this association.

The imported service description is the equivalent of a service that is designed inInfoSphere Information Server. You can deploy the service description like anynatively designed information service.

IBM Confidential


IBM Confidential


Part 4. Client-only upgrades

IBM Confidential


IBM Confidential


Chapter 12. Upgrading a client tier-only installation to Version8.5

Use the IBM InfoSphere Information Server installation program to upgradeexisting 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 installationsof MetaBrokers and bridges from the target computer before you run theInfoSphere Information Server installation program.

v See "Configuring your browser" in the Installation Guide to ensure that your Webbrowser is configured properly.

The installation program directly upgrades InfoSphere Information Server clientsoftware to Version 8.5. To upgrade client software directly by using theinstallation program, InfoSphere Information Server server-side software must notbe installed on the computer. The installation program cannot directly upgrade theserver-side software, or client software on a computer that also contains server-sidesoftware. To upgrade a computer that includes server-side software, you mustcreate a new installation of InfoSphere Information Server, Version 8.5 that includesthe client tier. To retain existing client versions, you must select a differentinstallation directory location for Version 8.5.

You can upgrade your client software at any time before, during, or after installingthe 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 tofollow the documented procedure for your installation version to completelyremove the software, restart the computer, and then use the Version 8.5installation software to install the Version 8.5 client software.

v Automatically upgrade the existing client versions on a client tier-only computerby using the following procedure.

Procedure

1. Start the installation program in graphical mode as described in "Starting theinstallation 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 clientinstallation, confirm that you want to upgrade the installation. The currentclient installation is uninstalled.

Note: To retain your existing client versions, you must select a differentinstallation directory location for Version 8.5 to ensure that your existingversions remain intact.

IBM Confidential


When the installation program has collected your settings, it saves a responsefile for you. This file is a text file that contains the settings that you made inthe previous pages. When you run the installation program again, you can loadthe settings into the program instead of manually selecting them again.

Note: Passwords are not saved in the response file. You must edit the responsefile 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 todetermine whether the new client installation is likely to succeed. The wizardpage displays each check. If the prerequisites check fails, it is marked FAILEDfor the corresponding items.

3. If you receive a FAILED message, double-click the message to learn more aboutresolving it.Try to resolve the issue without exiting the installation program. If you believethat you solved the problem, click Check Again in the Prerequisites Checkpage.If it is necessary to exit the installation program, click Cancel and close thebrowser window. Resolve the issue and then restart the installation program.

4. The installation program summarizes your settings and then begins theinstallation.

5. Monitor the installation as described in "Installation progress monitoring" in theInstallation Guide.Leave the terminal window open until the installation is complete.

Note: During the installation process, the installation process mightoccasionally request a response from you. Check periodically to make sure thatthe system is not waiting for you to respond. The installation process might failif the installation process halts for a long time.

6. After the installation is completed, install the correct Microsoft XML CoreServices (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.

4. Windows Restart the computer.5. Run the installation program again.

Client tier computers that include DataStage client software include the Version 8.5Multi-client Manager. After Version 8.5 is installed, use Version 8.5 is the activeversion. To use an earlier version of the client software, use the Version 8.5Multi-client Manager.

IBM Confidential


Part 5. Appendixes

IBM Confidential


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 arenot fully accessible. The installation program installs the following productmodules and components:v IBM InfoSphere Business Glossaryv IBM InfoSphere Business Glossary Anywherev IBM InfoSphere DataStagev IBM InfoSphere FastTrackv IBM InfoSphere Information Analyzerv IBM InfoSphere Information Services Directorv IBM InfoSphere Metadata Workbenchv IBM InfoSphere QualityStage

For information about the accessibility status of IBM products, see the IBM productaccessibility information at http://www.ibm.com/able/product_accessibility/index.html.

Accessible documentation

Accessible documentation for InfoSphere Information Server products is providedin an information center. The information center presents the documentation inXHTML 1.0 format, which is viewable in most Web browsers. XHTML allows youto set display preferences in your browser. It also allows you to use screen readersand other assistive technologies to access the documentation.

IBM and accessibility

See the IBM Human Ability and Accessibility Center for more information aboutthe commitment that IBM has to accessibility.

IBM Confidential


http://www.ibm.com/able/product_accessibility/index.html

http://www.ibm.com/able/product_accessibility/index.html

http://www.ibm.com/able

IBM Confidential


Accessing product documentation

Documentation is provided in a variety of locations and formats, including in helpthat is opened directly from the product client interfaces, in a suite-wideinformation center, and in PDF file books.

The information center is installed as a common service with IBM InfoSphereInformation Server. The information center contains help for most of the productinterfaces, as well as complete documentation for all the product modules in thesuite. You can open the information center from the installed product or from aWeb 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 ServerManager, the main Help item opens a local help system. Choose Help > OpenInfo Center to open the full suite information center.

v Press the F1 key. The F1 key typically opens the topic that describes the currentcontext 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. Thehost_name is the name of the services tier computer where the informationcenter is installed, and port_number is the port number for InfoSphereInformation Server. The default port number is 9080. For example, on aMicrosoft® Windows® Server computer named iisdocs2, the Web address is inthe 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 andperiodically refreshed at http://publib.boulder.ibm.com/infocenter/iisinfsv/v8r5/index.jsp.

Obtaining PDF and hardcopy documentationv PDF file books are available through the InfoSphere Information Server software

installer and the distribution media. A subset of the PDF file books is alsoavailable 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 yourlocal IBM representative. To order publications online, go to the IBMPublications Center at http://www.ibm.com/e-business/linkweb/publications/servlet/pbi.wss.

IBM Confidential


http://publib.boulder.ibm.com/infocenter/iisinfsv/v8r5/index.jsp

http://publib.boulder.ibm.com/infocenter/iisinfsv/v8r5/index.jsp

http://www.ibm.com/support/docview.wss?rs=14&uid=swg27016910

http://www.ibm.com/support/docview.wss?rs=14&uid=swg27016910

http://www.ibm.com/e-business/linkweb/publications/servlet/pbi.wss

http://www.ibm.com/e-business/linkweb/publications/servlet/pbi.wss

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: [email protected]

IBM Confidential


http://www.ibm.com/software/data/rcf/

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 inbrackets are required.

... Indicates that you can specify multiple values for the previous argument.

| Indicates mutually exclusive information. You can use the argument to theleft of the separator or the argument to the right of the separator. Youcannot use both arguments in a single use of the command.

{ } Delimits a set of mutually exclusive arguments when one of the argumentsis 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. Thebrackets 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 andoptional. The profile argument is required. The key argument is optional. Theellipsis (...) that follows the key argument indicates that you can specify multiplekey names.

wrb -import {rule_pack | rule_set}...

In this example, the rule_pack and rule_set arguments are mutually exclusive, butone of the arguments must be specified. Also, the ellipsis marks (...) indicate thatyou can specify multiple rule packs or rule sets.

IBM Confidential


IBM Confidential


Links to non-IBM Web sites

This information center may provide links or references to non-IBM Web sites andresources.

IBM makes no representations, warranties, or other commitments whatsoeverabout any non-IBM Web sites or third-party resources (including any Lenovo Website) that may be referenced, accessible from, or linked to any IBM site. A link to anon-IBM Web site does not mean that IBM endorses the content or use of suchWeb site or its owner. In addition, IBM is not a party to or responsible for anytransactions 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 andagree that IBM is not responsible for the availability of such external sites orresources, and is not responsible or liable for any content, services, products orother 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 controlthe content on that Web site. It is up to you to take precautions to protect yourselffrom viruses, worms, trojan horses, and other potentially destructive programs,and to protect your information as you deem appropriate.

IBM Confidential


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 inother countries. Consult your local IBM representative for information on theproducts and services currently available in your area. Any reference to an IBMproduct, program, or service is not intended to state or imply that only that IBMproduct, program, or service may be used. Any functionally equivalent product,program, or service that does not infringe any IBM intellectual property right maybe used instead. However, it is the user's responsibility to evaluate and verify theoperation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matterdescribed in this document. The furnishing of this document does not grant youany license to these patents. You can send license inquiries, in writing, to:

IBM Director of LicensingIBM CorporationNorth Castle DriveArmonk, 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 sendinquiries, in writing, to:

Intellectual Property LicensingLegal and Intellectual Property LawIBM Japan Ltd.1623-14, Shimotsuruma, Yamato-shiKanagawa 242-8502 Japan

The following paragraph does not apply to the United Kingdom or any othercountry where such provisions are inconsistent with local law:INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THISPUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHEREXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIEDWARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESSFOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express orimplied warranties in certain transactions, therefore, this statement may not applyto you.

This information could include technical inaccuracies or typographical errors.Changes are periodically made to the information herein; these changes will beincorporated in new editions of the publication. IBM may make improvementsand/or changes in the product(s) and/or the program(s) described in thispublication at any time without notice.

Any references in this information to non-IBM Web sites are provided forconvenience only and do not in any manner serve as an endorsement of those Web

IBM Confidential


sites. The materials at those Web sites are not part of the materials for this IBMproduct 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 itbelieves appropriate without incurring any obligation to you.

Licensees of this program who wish to have information about it for the purposeof enabling: (i) the exchange of information between independently createdprograms and other programs (including this one) and (ii) the mutual use of theinformation which has been exchanged, should contact:

IBM CorporationJ46A/G4555 Bailey AvenueSan 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 materialavailable for it are provided by IBM under terms of the IBM Customer Agreement,IBM International Program License Agreement or any equivalent agreementbetween us.

Any performance data contained herein was determined in a controlledenvironment. Therefore, the results obtained in other operating environments mayvary significantly. Some measurements may have been made on development-levelsystems and there is no guarantee that these measurements will be the same ongenerally available systems. Furthermore, some measurements may have beenestimated through extrapolation. Actual results may vary. Users of this documentshould verify the applicable data for their specific environment.

Information concerning non-IBM products was obtained from the suppliers ofthose products, their published announcements or other publicly available sources.IBM has not tested those products and cannot confirm the accuracy ofperformance, compatibility or any other claims related to non-IBM products.Questions on the capabilities of non-IBM products should be addressed to thesuppliers of those products.

All statements regarding IBM's future direction or intent are subject to change orwithdrawal without notice, and represent goals and objectives only.

This information is for planning purposes only. The information herein is subject tochange before the products described become available.

This information contains examples of data and reports used in daily businessoperations. To illustrate them as completely as possible, the examples include thenames of individuals, companies, brands, and products. All of these names arefictitious and any similarity to the names and addresses used by an actual businessenterprise is entirely coincidental.

COPYRIGHT LICENSE:

This information contains sample application programs in source language, whichillustrate programming techniques on various operating platforms. You may copy,modify, and distribute these sample programs in any form without payment to

IBM Confidential


IBM, for the purposes of developing, using, marketing or distributing applicationprograms conforming to the application programming interface for the operatingplatform for which the sample programs are written. These examples have notbeen thoroughly tested under all conditions. IBM, therefore, cannot guarantee orimply reliability, serviceability, or function of these programs. The sampleprograms are provided "AS IS", without warranty of any kind. IBM shall not beliable 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, mustinclude 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 rightsreserved.

If you are viewing this information softcopy, the photographs and colorillustrations may not appear.

Trademarks

IBM, the IBM logo, and ibm.com are trademarks of International BusinessMachines Corp., registered in many jurisdictions worldwide. Other product andservice names might be trademarks of IBM or other companies. A current list ofIBM 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 UnitedStates, and/or other countries.

IT Infrastructure Library is a registered trademark of the Central Computer andTelecommunications Agency which is now part of the Office of GovernmentCommerce.

Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo,Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks orregistered trademarks of Intel Corporation or its subsidiaries in the United Statesand other countries.

Linux is a registered trademark of Linus Torvalds in the United States, othercountries, or both.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks ofMicrosoft Corporation in the United States, other countries, or both.

ITIL is a registered trademark, and a registered community trademark of the Officeof Government Commerce, and is registered in the U.S. Patent and TrademarkOffice

UNIX is a registered trademark of The Open Group in the United States and othercountries.

Cell Broadband Engine is a trademark of Sony Computer Entertainment, Inc. in theUnited States, other countries, or both and is used under license therefrom.

IBM Confidential

Notices and trademarks 115

http://www.ibm.com/legal/copytrade.shtml

Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in theUnited States, other countries, or both.

The United States Postal Service owns the following trademarks: CASS, CASSCertified, DPV, LACSLink, ZIP, ZIP + 4, ZIP Code, Post Office, Postal Service, USPSand United States Postal Service. IBM Corporation is a non-exclusive DPV andLACSLink licensee of the United States Postal Service.

Other company, product or service names may be trademarks or service marks ofothers.

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 productsand documentation.

The following table lists resources for customer support, software services, training,and product and solutions information.

Table 16. IBM resources

Resource Description and location

IBM Support Portal You can customize support information bychoosing the products and the topics thatinterest you at www.ibm.com/support/entry/portal/Software/Information_Management/InfoSphere_Information_Server

Software services You can find information about software, IT,and business consulting services, on thesolutions site at www.ibm.com/businesssolutions/

My IBM You can manage links to IBM Web sites andinformation that meet your specific technicalsupport needs by creating an account on theMy IBM site at www.ibm.com/account/

Training and certification You can learn about technical training andeducation services designed for individuals,companies, and public organizations toacquire, maintain, and optimize their ITskills at http://www.ibm.com/software/sw-training/

IBM representatives You can contact an IBM representative tolearn about solutions atwww.ibm.com/connect/ibm/us/en/

Providing feedback

The following table describes how to provide feedback to IBM about products andproduct documentation.

Table 17. Providing feedback to IBM

Type of feedback Action

Product feedback You can provide general product feedbackthrough the Consumability Survey atwww.ibm.com/software/data/info/consumability-survey

IBM Confidential


http://www.ibm.com/support/entry/portal/Software/Information_Management/InfoSphere_Information_Server




http://www.ibm.com/businesssolutions/

http://www.ibm.com/businesssolutions/

http://www.ibm.com/account/

http://www.ibm.com/software/sw-training/

http://www.ibm.com/software/sw-training/

http://www.ibm.com/connect/ibm/us/en/

http://www.ibm.com/software/data/info/consumability-survey/

http://www.ibm.com/software/data/info/consumability-survey/

Table 17. Providing feedback to IBM (continued)

Type of feedback Action

Documentation feedback To comment on the information center, clickthe Feedback link on the top right side ofany topic in the information center. You canalso send comments about PDF file books,the information center, or any otherdocumentation in the following ways:

v Online reader comment form:www.ibm.com/software/data/rcf/

v E-mail: [email protected]

IBM Confidential


http://www.ibm.com/software/data/rcf/

Index

AAbbreviate stage

replacing QualityStage legacy 94Administrator client, Version 8.5

importing 7.5.3 and earlier DataStageprojects 78

advanced migrationapplication server 47

archive parameterismigration tool export command

syntax 28ismigration tool import command

syntax 29

Bbin directory

ismigration tool 51Build stage

replacing QualityStage legacy 94

Cclient tiers

upgrading client-onlyinstallation 101

Collapse stagereplacing QualityStage legacy 94

command line interfaceconnecting to DataStage 7.5.3 and

earlier projects 86exporting DataStage 7.5.3 and earlier

projects 74command syntax

ismigration tool export commandsyntax 28

ismigration tool import commandsyntax 29

command-line syntaxconventions 109

commandssyntax 109

commands, ismigration toolencryption tool for passwords 31export 28import 29restart 30

compileDataStage 7.5.3 and earlier jobs after

migration 80DataStage 7.5.3 and earlier routines

after migration 80conf directory

ismigration tool 51config parameter



connectto Version 7.5.3 and earlier Designer,

Manager, and Director clients 84conversion script

QualityStage migration utility 92creating

migration.properties file 22customer support

contacting 117

Ddatabase requirements

ismigration tool 19DataStage 7.5.3 and earlier

export using command line 74export using Manager client 73importing projects to Version 8.5 78job dependencies, moving 76legacy projects, exporting 73moving schema files 76saving setting files 75

DataStage Administrator clientimporting 7.5.3 and earlier DataStage

projects 78DataStage client

uninstalling 77DataStage Designer client

compiling jobs and routines 80exporting projects before migration

from 7.5.3 and earlier 74importing files after migrating from

7.5.3 and earlier 91installing multiple versions with

Multi-Client Manager 83restoring hashed files after migration

from 7.5.3 and earlier 79DataStage projects

completing migration 48DataStage servers

attaching to multiple 84connecting to DataStage Version 7.5.3

and earlier 84connecting to multiple 84uninstalling Linux and UNIX 77uninstalling Windows 77

datastage.engine.admin.passwordproperty

for ismigration tool 52datastage.engine.admin.username

propertyfor ismigration tool 52

datastage.engine.asbhome propertyfor ismigration tool 52

datastage.engine.enginepath property 52datastage.engine.update.project

property 52default directories

ismigration tool 51

Designer and Director clientsconnecting to multiple servers on

Version 8.5 85Designer client

compiling jobs and routines 80exporting projects before migration

from 7.5.3 and earlier 74importing 7.5.3 and earlier DataStage

projects 78importing files after migrating from

7.5.3 and earlier 91importing migrated files

(QualityStage) 91importing projects to 78installing multiple versions with

Multi-Client Manager 83recompiling DataStage jobs for 80restoring hashed files after migration

from 7.5.3 and earlier 79Designer Manager client

exporting projects before migrationfrom 7.5.3 and earlier 74

different versions of clientsswitching between 81

Director clientusing to restore hashed files 79

directoriesdefault for ismigration tool 51

dscmdexport commandexporting DataStage 7.5.3 and earlier

projects 74dsenv environment variable

saving DataStage 7.5.3 and earlier 75DSHOME environment variable

saving DataStage 7.5.3 and earlier 75dsjob command

using to connect to a Version 8.5 aftermigration 86

DSParams filesaving DataStage 7.5.3 and earlier,

Linux and UNIX 75saving DataStage 7.5.3 and earlier,

Windows 75

Eedit

host change file for topologychanges 46

encryptpasswords 22

encryptionismigration tool 31

enterprise packsverify availability on Version 8.5 25

expanded job migrationQualityStage 7.5.3 and earlier 88

exportabout DataStage 7.5.3 and earlier

projects 73

IBM Confidential


export (continued)DataStage 7.5.3 and earlier projects

using Manager client 74ismigration tool command syntax 28ismigration tool export command

syntax 28using ismigration tool 34

Ffiles

.ini, saving DataStage 7.5.3 andearlier 75

DSParams, saving DataStage 7.5.3 andearlier 75

HostChangeConfig.xml forismigration tool 64

log for ismigration tool 66migration.properties for ismigration

tool 52migration.todo.txt for ismigration

tool 66odbc.ini, saving DataStage 7.5.3 and

earlier 75userfiles for ismigration tool 65uvodbc.config, saving DataStage 7.5.3

and earlier 75flat files

moving DataStage 7.5.3 andearlier 76

Format Convert stagereplacing QualityStage legacy 94

Ggen-app-server parameter



Hhashed files

importing into Designer client aftermigration 79

migrating DataStage 7.5.3 andearlier 76

health checker 21host change file

required for topology changes 64host names

changing in host change file,ismigration tool 46

host-change-config parameterismigration tool import command

syntax 29

Iia.db2.db.binpath property

for ismigration tool 52ia.db2.installdir property

for ismigration tool 52

ia.gendb.directory propertyfor ismigration tool 52

ia.gendb.enabled propertyfor ismigration tool 52when to use 45

ia.keep.analysisdb.options propertyfor ismigration tool 52

ia.keep.analysisengine.options propertyfor ismigration tool 52

ia.oracle.datadumpfolder propertyfor ismigration tool 52

ia.oracle.datafilefolder propertyfor ismigration tool 52

ia.oracle.datafilepath propertyfor ismigration tool 52

ia.oracle.sys.password propertyfor ismigration tool 52

ia.oracle.sys.servicename propertyfor ismigration tool 52

ia.oracle.sys.username propertyfor ismigration tool 52

ia.oracle.tablespacename propertyfor ismigration tool 52

ia.sqlserver.datafolder propertyfor ismigration tool 52

importabout ismigration tool 37importing 7.5.3 and earlier DataStage

projects 78importing Version 7.5.3 and earlier

QualityStage jobs 91ismigration tool import command

syntax 29using ismigration tool 40

ini filessaving DataStage 7.5.3 and earlier 75

installclient-only installation 101ITAG, multiple servers 81Version 8.5 on target installation for

ismigration tool 37installation environment

validate using ismigration tool 34, 37installismigration tool 33interface

ismigration tool 27Investigate stage

replacing QualityStage legacy 94is.migration.leaveworkdir property

for ismigration tool 52is.migration.skipvalidation property

for ismigration tool 52is.suite.admin.password property

for ismigration tool 52is.suite.admin.username property

for ismigration tool 52is.websphere.admin.password property

for ismigration tool 52is.websphere.admin.username property

for ismigration tool 52ISA Lite

information for migration 21ismigration directories

conf 51logs 51

ismigration toolcompleting to do activities 35, 41

ismigration tool (continued)exporting 34exporting source installation 34importing 40log files 66manual application server

configuration 47properties file 52requirements and restrictions 19user interface 27userfiles 65

ismigration tool syntaximport command 29

ITAG installationmigrating multiple DataStage

servers 83iTag installations

multiple servers Linux, UNIX 81

Jjob migration (QualityStage)

legacy 87match specification 88

Llegacy migration

replacing QualityStage Legacystages 92

legacy migration (QualityStage)QualityStage jobs 87

legacy operational modeQualityStage 7.5.3 and earlier 87

legacy stagesQualityStage, replacing 94

legal notices 113locations, projects

ismigration tool host change file 64log files

ismigration tool 66logs directory

ismigration tool 51logsdirectories 51

MManager client 74match specification

migration 88Match stage

replacing QualityStage legacy 94migrated files (QualityStage)

importing 91provisioning 91

migratinghashed files 76

migrationclient tiers 101command line interface 27compiling jobs after 80DataStage schema files 79exporting source 33from release 7.5.3 and earlier 71from Version 8.0.1 and later 7host change file 64

IBM Confidential


migration (continued)ITAG installations 73overview 8planning overview 19process overview 3QualityStage modules 25QualityStage v7.5.3 or earlier 87real-time QualityStage jobs 93reference topics 51restart command syntax 30RTI 7.5.2 and earlier 97RTI 7.5.3 and earlier 97scenarios and methodology 3strategies 3supported migrations 19tool user interface 27verify source credentials 34, 37

migration directories, Version 8.5bin 51conf 51scripts 51

migration from 7.5.3 and earlierDataStage flat files 79

migration from 8.0.1 and laterchanging topology 46completing migration for DataStage

projects 48ismigration tool 7

migration utilityrunning QualityStage 90

migration.propertiesISA Lite Tool for system summary

reports 21migration.todo.txt file

manual activities for ismigrationtool 66

migrationfrom 8.0.1 and 8.1ismigration tool, installing on 8.0.1

and 8.1 33migrationvalidation, source 23migrationvalidation, target 38move

ismigration tool files from source totarget 36

Multi-client Managerusing to switch between different

client versions 81Multi-Client Manager 83

installing multiple DataStage clientversions 83

multi-computer migrations 13Multinational Standardize stage

replacing QualityStage legacy 94multiple DataStage clients

connecting to 84multiple DataStage servers

connecting to Version 7.5.1 andearlier 85

connecting to Version 8.5 85Multiple Job Compile tool

for recompiling DataStage jobs 80

Nnon-IBM Web sites

links to 111

Oodbc files

saving DataStage 7.5.3 and earlier 75odbc.ini file

saving DataStage 7.5.3 and earlier 75Oracle databases

character encodings 25overview

migration 3

PParse stage

replacing QualityStage legacy 94passwords

encryption, for ismigration tool 31plan

migrations 19port numbers

host change file for ismigrationtool 64

preparetarget installation for ismigration

tool 37product accessibility

accessibility 105product documentation

accessing 107Program stage

replacing QualityStage legacy 94project locations

ismigration tool host change file 64projects (DataStage)

exporting 74properties file

migration 52

QQualityStage

postmigration activities 48QualityStage 7.0 to 7.5 job migration

legacy form 87QualityStage 7.5 plug-in

rewriting jobs after migration 80QualityStage 7.5.3 and earlier

job migration, expanded form 88premigration steps for ismigration

tool 45QualityStage migration utility

installing 89UNIX and Linux 90Windows 90

QualityStage modulesverify availability on Version 8.5 25

QualityStage rule setsmigrating 7.5.3 and earlier 88

QualityStage stagesreplacing legacy 94

Rreal-time QualityStage jobs

migrating 93

referenceismigration tool 51

replacing legacy stagesQualityStage version 7.5.3 and

earlier 94requirements

ismigration tool 19restart command

ismigration tool command syntax 30restore

7.5.3 and earlier DataStage settingsfiles 78

DataStage 7.5.3 and earlier settingsfiles 78

restrictionsismigration tool 19

RTI 7.5.2 and earliermigration export 97

rule sets, QualityStagemigrating 7.5.3 and earlier 88

Sscenarios

multiple computers 13single computer 9Version 8.0.1 migration 9, 13

scriptsismigration tool 51

Select stagereplacing QualityStage legacy 94

settings filesrestoring DataStage 7.5.3 and earlier

files 78saving DataStage 7.5.3 and earlier 75

single-computer migrations 9software services

contacting 117Sort stage

replacing QualityStage legacy 94special characters

in command-line syntax 109Standardize stage

replacing QualityStage legacy 94start

DataStage 7.5.3 and earlier server 84stop

DataStage 7.5.3 and earlier server 84strategy

migration 3support

customer 117supported migrations

scenarios 19Survive stage

replacing QualityStage legacy 94syntax

command-line 109system summary 21

Ttarget installation

moving ismigration tool files 36preparing to use ismigration tool 37

IBM Confidential

Index 121

to do activitiesfor ismigration tool 35, 41

to-do fileismigration tool manual activities 66

topology changeshost change file 46

trademarkslist of 113

Transfer stagereplacing QualityStage legacy 94

UUnijoin stage

replacing QualityStage legacy 94uninstall

DataStage client 77DataStage server, Windows 77DataStage servers, Linux and

UNIX 77overview, previous DataStage

versions 77UNIX and Linux

installing QualityStage 7 migrationutility 89

upgradeclient-only installation 101

user interfaceismigration tool 27

userfilesmigration reference 65

userfiles parameterismigration tool export command

syntax 28utility

QualityStage migration 90uvodbc.config file

saving DataStage 7.5.3 and earlier 75

Vvalidate

source installation criteria 23target installation criteria 38using ismigration tool 34, 37

validateonly parameterismigration tool export command


syntax 29using to validate environment 34, 37

Version 8.0.1 and laterscenarios 9, 13

WWAVES stage

replacing QualityStage legacy 94Web sites

non-IBM 111Websphere RTI 7.5.3 and earlier

migration 97Windows

installing QualityStage migrationutility 89

wizardsWebSphere RTI Export 97

work parameterismigration tool export command


syntax 29

Xxmeta.db.binpath property

for ismigration tool 52xmeta.db2.installdir property

for ismigration tool 52xmeta.gendb.directory property

for ismigration tool 52xmeta.oracle.datadumpfolder property

for ismigration tool 52xmeta.oracle.datafilefolder property

for ismigration tool 52xmeta.oracle.sys.password property

for ismigration tool 52xmeta.oracle.sys.servicename property

for ismigration tool 52xmeta.oracle.sys.username property

for ismigration tool 52xmeta.oracle.tablespacename property

for ismigration tool 52xmeta.sqlserver.datafolder property

for ismigration tool 52

IBM Confidential


��

IBM ConfidentialPrinted in USA

migration guide to iis8.5

Documents