Migration overview
WebSphere Process Server for z/OS V7.0 WebSphere Enterprise Service Bus for z/OS V7.0 Migration overview
This presentation will cover the migration to WebSphere® Process Server for z/OS V7 and WebSphere Enterprise Service Bus for z/OS V7.
Agenda
Agenda Migration methods Overview of migration process Migration process Install the V7 product Create nodes Migrate configuration Perform data migration
First you will see an overview of the various migration methods available to you. Then an overview of the migration process for WebSphere Process Server for z/OS V7 is provided. Finally, you will see the migration process at a high level.
Migration methods
Migration methods Section
The first thing you are going to look at in this presentation are the various migration methods available to you for migration to WebSphere Process Server for z/OS V7 or WebSphere Enterprise Service Bus for z/OS V7.
Migration methods
Migration methods Manual migration Artifact migration Runtime migration
There are three methods you can choose to use in migrating from a previous version of WebSphere Process Server for z/OS or WebSphere Enterprise Service Bus for z/OS to version 7 of the product. They are manual migration, artifact migration and runtime migration. You will look briefly at each of these methods on the next few slides.
Manual migration
Manual migration Parallel target production environment Configured from scratch so can be different than source production environment Applications selectively redeployed to new environment New database tables created Long-running processes finish in original production environment V6.0.2, V6.1.0, V6.1.2 or V6.2.0 Node Migrated V7 Node Applications
With a manual migration, you create a new parallel target production environment. Since it is configured from scratch, you can change the configuration in any way that you deem necessary. The new environment will not share the database data from your original environment in this case. You are required to create new database tables in the case of a manual migration. When you have the new parallel production environment up and running to your satisfaction, you can then selectively move applications to the environment. Since the two environments do not share database data, long-running processes need to finish processing in the original environment. After moving the long-running applications to the new environment, new processes will start there. Both environments need to be in production, however, until all applications are moved and all long-running processes that were started before the migration finish.
Artifact migration
Artifact migration Same as manual migration Parallel production environment User applications are also upgraded to make them compatible with WebSphere Process Server V7.0 Allows exploitation of new capabilities delivered in version 7 V6.0.2, V6.1.0, V6.1.2 or V6.2.0 Node Migrated V7 Node Applications WebSphere Integration Developer V7
The artifact migration is the same as the manual migration where you create a parallel production environment but in this case, the user applications will also be upgraded to be compatible with WebSphere Process Server V7.0. This application upgrade is done using WebSphere Integration Developer V7.0. With the manual migration, you move the applications to the new environment unchanged. The artifact migration method allows you to exploit the new capabilities delivered by version 7 in your applications.
Runtime migration
Runtime migration Move configuration data, applications, and database data from source environment to target environment Upgraded inline Results in replicated environment Source environment unusable after migration Long-running processes can finish in new environment Migrated V7 Node Run migration scripts V6.0.2, V6.1.0, V6.1.2 or V6.2.0 Node V7 Node V6.0.2, V6.1.0, V6.1.2 or V6.2.0 Node
With a runtime migration, you will create a target environment and move the configuration, applications and database data over to the target environment. It is upgraded inline and when the process is complete, the source environment becomes unusable. Only one environment can be in use at one time. It results in a copy of your source environment however. If you have long-running tasks, they will move to the new target environment and are able to finish there since you are using the same database data. You will see the runtime migration method in this presentation.
Migration – software levels
Migration – software levels WebSphere Process Server version 6.2.0 WebSphere Process Server version 6.1.2 WebSphere Process Server version 6.1.0 WebSphere Process Server version 6.0.2
Runtime migration is supported from the versions shown on the slide. It is a good idea to be at the latest PTF level on any of the levels before proceeding, however it is not required.
Overview of migration process
Overview of migration process Section
This section provides an overview of the migration process.
Migration process on z/OS
Migration process on z/OS Install the V7 product code, using SMP/E Create WebSphere Process Server for z/OS V7 or WebSphere Enterprise Service Bus for z/OS V7 nodes, mimicking your V6 environment Migrate configuration, one node at a time, by running customized jobs Perform data migration
In order to migrate your WebSphere Process Server for z/OS or WebSphere Enterprise Service Bus for z/OS environment, you must first install the Version 7 product code with SMP/E. This includes WebSphere Application Server for z/OS, WebSphere Process Server for z/OS (or WebSphere Enterprise Service Bus for z/OS), and the required feature packs (SCA, XML and SDO). Once installed, you are required to configure V7 nodes that mimic your V6 environment. The WebSphere Process Server for z/OS or WebSphere Enterprise Service Bus for z/OS configurations will, however, be very basic with none of the typical customizations completed, such as Business Process Choreographer or Human Task Manager. Once you have a basic V7 environment set up, you can then proceed to migrate each node by running the customized jobs provided. Finally, you will need to perform data migration so that your database schemas are at the V7 level. If using BPC, you will also need to migrate your runtime data. For example, you will need to migrate your runtime data associated with long running processes and process templates. In a network deployment configuration, you must always start with the deployment manager node. You will see these steps in greater detail in the remaining slides.
Install V7 product
Install V7 product Section
The first step necessary in migrating to V7 is installing the product. This presentation will provide some basic information for this.
Prerequisites: Base WebSphere Application Server for z/OS
Prerequisites: Base WebSphere Application Server for z/OS Minimum WebSphere base application server level: WebSphere Application Server for z/OS V7.0.0.9 -OR- WebSphere Application Server for z/OS V7.0.0.7 with ++APAR AK99267 This ++APAR also includes the V7.0.0.8 fixpack so no need to install 7.0.0.8 when available Minimum optional materials levels: WebSphere Application Server for z/OS V7.0.0 Optional Materials are required SCA 1.0.1.1 (APAR PM03322) XML 1.0.0.1 (APAR PM03323) SDO 2.1.1 (APAR PM03324)
In order to migrate to WebSphere Process Server for z/OS V7 or WebSphere Enterprise Service Bus for z/OS V7, you must be running WebSphere Application Server for z/OS V7.0.0.9 or V7.0.0.7 with the ++APAR indicated. You are also required to install optional materials SDO 1.0.1.1, XML 1.0.0.1 and SDO 2.1.1, as shown on the slide. The corresponding APAR numbers for these feature packs are listed.
Prerequisites: WebSphere Process Server for z/OS, WebSphere Enterprise Service Bus for z/OS and feature packs
Prerequisites: WebSphere Process Server for z/OS, WebSphere Enterprise Service Bus for z/OS and feature packs WebSphere Process Server for z/OS V7.0.0.1 or WebSphere Enterprise Service Bus for z/OS V7.0.0.1. Program directory: http://www.ibm.com/e-business/linkweb/publications/servlet/pbi.wss?CTY=US&FNC=SRX&PBL=GI13-0553 PSP Bucket: http://www.ibm.com/support/docview.wss?uid=isg1_WPSZ_HWPS700 APAR and PTF table: http://www.ibm.com/support/docview.wss?rs=2307&uid=swg27017812
WebSphere Process Server for z/OS and WebSphere Enterprise Service Bus for z/OS V7.0.0.1 is the minimum required level for full function of the product. It became available in January 2010 and should be the minimum level for a successful configuration and running of the products. Also included on this slide are links to important installation materials, including the Program Directory, the PSP Bucket for the latest installation information and finally the APAR and PTF table for WebSphere Process Server for z/OS V7.
Structure for WebSphere Process Server for z/OS and WebSphere Enterprise Service Bus for z/OS
Structure for WebSphere Process Server for z/OS and WebSphere Enterprise Service Bus for z/OS H28W700 JIWO700 HWPS700 (HESB700) hlq.SBBOHFS /usr/lpp/zWebSphere/V7R0 hlq.SBPZHFS (hlq. SBSBHFS) /usr/lpp/zWPS/V7R0 (/usr/lpp/zWESB/V7R0 1000 cyls (550 cyls) hlq.SIWOHFS /usr/lpp/zWebSphere_OM/V7R0 Configured on top
WebSphere Process Server for z/OS and WebSphere Enterprise Service Bus for z/OS are configured on top of WebSphere Application Server for z/OS and the WebSphere Application Server for z/OS Optional Materials FMID, as seen on the slide. Starting with V7, all products involved in the configuration are completely contained within its HFS. When WebSphere Process Server for z/OS or WebSphere Enterprise Service Bus for z/OS are completely configured, you will point to a minimum of three product HFSes. WebSphere Application Server for z/OS, WebSphere Application Server for z/OS Optional Materials and WebSphere Process Server for z/OS (or WebSphere Enterprise Service Bus for z/OS) each SMP/E install into their own HFS. You should note that while the Program Directory specifies 774 cylinders for the WebSphere Process Server HFS and 440 cylinders for WebSphere Enterprise Service Bus HFS, you will actually use more than that. WebSphere Process Server uses 1000 cylinders and WebSphere Enterprise Service Bus uses 550 cylinders.
Create V7 nodes
Create V7 nodes Section
The next step in migrating to V7 is configuring WebSphere Process Server for z/OS or WebSphere Enterprise Service Bus for z/OS nodes.
Configure V7 ‘copy’ of your V6 environment
Configure V7 ‘copy’ of your V6 environment SYSA V6 NodeA SYSB V6 NodeB V6 Cell SYSA V7.0 NodeA SYSB V7.0 NodeB V7 Cell V6 ServerA V7 deployment manager V6 ServerA V6 deployment manager
On this slide you see an example of a V6 configuration on the left. To migrate this environment to version 7, you need to replicate that environment on version 7 first. This means you need to configure WebSphere, augment it with all required feature packs and then finally augment it with WebSphere Process Server for z/OS or WebSphere Enterprise Service Bus for z/OS. You should just make it a ‘basic’ configuration as the migration will configure the various pieces as you had it on the V6 cell. ‘Basic’ configuration simply means that you should install and augment your servers with WebSphere Process Server for z/OS V7 but then do no further configuration. You need to use the same cell name and node names, however. Any managed nodes should not be federated as depicted by the dashed line on the right.
Version 7 configuration
Version 7 configuration . . . . . .
As mentioned, the version 7 configuration that you create should use the same cell name and node names that were used in your version 6 configuration. On the left, you see a version 6.1 configuration that is going to be migrated to version 7. On the right, you see the version 7 configuration that was created in preparation for the migration. You’ll notice that the cell name, node name and server names were all kept the same. This is required for the WebSphere Process Server for z/OS migration. This slide is showing a stand-alone server configuration but the idea is the same for a deployment manager configuration; you just will not have servers in the managed node configuration yet.
Two environments
Two environments Stand-alone server environment Network deployment environment Deployment manager node Managed nodes Each node needs to be augmented with: SCA XML SDO WebSphere Process Server for z/OS (or WebSphere Enterprise Service Bus for z/OS)
There are two environments that you might need to migrate. The first one is the stand-alone server environment and involves only one configuration. In the case of the network deployment environment, you need to create both a version 7 environment for the deployment manager node and each of the managed nodes. You will see each of these on the next slides. Note that since you are creating a target version 7 environment, each node you configure needs to be augmented with the required feature packs and WebSphere Process Server for z/OS or WebSphere Enterprise Service Bus for z/OS.
Stand-alone server environment
Stand-alone server environment Create a version 7 customization definition using the WebSphere Customization Tools Start with V6 response file if you have it Cell and node names ‘moved’
This presentation will not take you through all the steps necessary to set up the version 7 environments. There are other presentations that talk about the installation and customization of the version 7 environments in great detail. Here you will see the differences and some suggestions needed to prepare the environments for migration to version 7. The first thing you need to do is create a customization definition in the WebSphere Customization Tools. You’ll notice that this starts with an Application server with the feature pack for SCA here. Once that is created, you will then have to augment it with SCA, XML and finally WebSphere Process Server or WebSphere Enterprise Service Bus. Also note that if you have it available, you should start with the response file used to create the version 6 environment you are migrating. This will help to ensure the cell and node names are correct in addition to some other information.
Stand-alone server environment: augment with WebSphere Process Server
Stand-alone server environment: augment with WebSphere Process Server Create a bare-bones configuration in version 7 Uncheck the configuration of the various functions
As you move to the WebSphere Process Server augmentation piece of the configuration, uncheck all of the ‘configure’ options. These functions will move from your V6 configuration if you have them configured there.
Stand-alone server environment: WebSphere Process Server database configuration
Stand-alone server environment: WebSphere Process Server database configuration Select the same database on the version 7 target node as you are using on the version 6 source node Recommend creating a database design file Upgrade SQL is generated
You need to specify the same database during augmentation of the version 7 node that you are currently using in the version 6 source configuration. You should follow the directions to run the DbDesignGenerator shell script to create a database design file as there are upgrade SQL scripts that are created for the migration. More information is provided for this task in the ‘data migration’ section of this presentation.
Stand-alone server environment: WebSphere Process Server augmentation
Stand-alone server environment: WebSphere Process Server augmentation Manually add this keyword to the generated response file for a stand-alone augmentation: -createDefaultProfileForMigration=true This prevents duplicate CEI messaging engines from being created
One manual step needed with the stand-alone augmentation is to add the createDefaultProfileForMigration keyword to the response file. This keyword must be set to ‘true’ so that duplicate CEI messaging engines are not created.
Network deployment environment
Network deployment environment Creating the deployment manager and managed target nodes is similar to the stand-alone configuration Configuration is more bare bones by default
For the network deployment environment, you will again create version 7 customization definitions using the WebSphere Customization Tools. You will need to create a configuration for your target version 7 deployment manager environment and for each managed node in the current version 6 cell that you plan to migrate. By default, these configurations are more bare bones because much of the WebSphere Process Server configuration takes place after augmentation. In this environment, you don’t have to worry about not configuring some of the functions like you do in the stand-alone environment. You do need to provide database information however. Again, you should run the DbDesignGenerator shell script to create a dbDesign file to define the database to the configuration.
Migrate configuration
Migrate configuration Section
Now that you have created a target configuration, you are ready to run some migration jobs. You will look at that next.
Migration jobs
Sample migration jobs found in the SBPZJCL member shipped with WebSphere Process Server for z/OS BPZWMG3D –> job for Deployment Manager migration BPZWMG1B, BPXWMG2B, BPXWMG3B –> jobs for stand-alone server migration BPZWMG1F, BPXWMG2F, BPXWMG3F –> jobs for federated node migration BPZWMG1* and BPZWMG2* jobs are only needed if XA connectors were used BPZWMG3* jobs perform the main migration Migration jobs
Sample migration jobs are shipped with the product in the SBPZJCL PDS for WebSphere Process Server for z/OS. All migration members start with ‘BPZWM’. Each environment uses a different letter at the end where ‘D’ is for deployment manager environments, ‘B’ is for stand-alone server environments and ‘F’ is for federated node environments. The numbers are used to distinguish each job’s purpose. The number three signifies the job that performs the main migration. The numbers one and two signify jobs that are needed only if XA connectors were being used in the source environment. The first one enables the servers on the application server node being migrated to start in PRR processing mode. PRR processing mode resolves any outstanding transactions, clears the transaction logs, and terminates the server. The second one then disables PRR mode and returns all servers to normal operating state.
Update required jobs
Update required jobs For most migrations, the BPZWMG3* job is the only one needed Copy it to a PDS where you can update it Customize for your environment For example, ‘c #tempdir# WPSmigration’ //* The following change has been made to handle the WPS migration; * //* 1. bbomigrt2.sh has been replaced with wbimigrt2.sh. * //* * //* The following parameters will need to be amended for the users * //* own configuration, and correspond to the parameters entered on * //* the WebSphere Customisation panels. * //* * //* #tempdir# temporary working directory * //* eg. v70dm1 * //* * //* #wpsndir# directory of the v7.0 WPS product * //* eg. /usr/lpp/zWPS/V7R0 * //* * //* #wpsosvr# home directory of the old wps server * //* eg. /WebSphere/V62DM1 * . . .
Unless you use XA connectors, the BPZWMG3* jobs are the only ones you will need. Copy the appropriate jobs to a PDS where you can update them. Paging down in the member, you will see a list of parameters that need to be updated before you have a working job. You can do a ‘replace’ using the variables shown with the values that fit your environment.
ENVVARS
ENVVARS Updated parameters //ENVVARS DD * wpsMigEnabledPrivate=true scriptCompat=true timestamp=attempt1 tempDir=/tmp/migrate migType=default FROM_ConfigRoot=/etc/wasv61config/s6basea/s6nodea FROM_HomeDir=/AppServer FROM_ProfileName=default TO_SMPEHome=/etc/wasv7config/s6basea/s6nodea_wassmpe TO_ConfigRoot=/etc/wasv7config/s6basea/s6nodea TO_HomeDir=/AppServer TO_CtrlProcName=S6ACRA TO_DmnProcName=S6DEMNA TO_SvrProcName=S6ASRA TO_AdjProcName=S6CRAA TO_AdminUserid=S6ADMIN TO_AdminPassword=FR1DAY appsPath1=/etc/wasv7config/s6basea/s6nodea/ appsPath2=AppServer/profiles/default/installedApps . . . Split over two lines
Many of the changes you make are to customize the ‘response file’ parameters in the JCL. You will find these as part of the ENVVARS DD JCL statement. A partial list for a stand-alone migration is shown on the slide. These fields should match what was entered during customization of the nodes. Since JCL is limited to 80 columns, a second variable for appsPath might be required. You see in this example that the appsPath was too long to fit on one line.
wbimigrt2.sh
wbimigrt2.sh The wbimigrt2 shell script replaces the bbomigrt2 shell script which is used in WebSphere migrations As part of wbimgrt2.sh processing, the WebSphere Application Server profile is also migrated The same processing occurs during a WebSphere Process Server for z/OS migration as seen in a WebSphere Application Server for z/OS migration The BPZWMG3* jobs consist of many steps
In the JCL, you’ll see that the wbimgrt2 shell script is used for the WebSphere Process Server for z/OS migration processing. This does much of the same processing as bbomigrt2 does in a base WebSphere Application Server environment migration. The BPZWMG3 jobs are multi-step jobs with each step taking care of a particular function to complete the migration. To see more information about the various steps that are run during migration processing, you can reference the Migration overview presentation for WebSphere Application Server for z/OS V7. During processing the wbimgrt2 shell script also migrates the base WebSphere Application Server profile.
Run the jobs
Run the jobs Once you are satisfied with the customizations in the JCL, you are ready to perform the migration To migrate the nodes Stop the servers in the node you are migrating BACKUP the database and the configuration!!! Submit the job You must use the administrator user name and password When doing a network deployment environment, you must migrate the deployment manager node first!
Once you are satisfied with the customization of the JCL, you are ready to perform the migration. Before migrating you need to stop all servers in the node you are migrating. You should also make backups of the source and target configurations and the database before proceeding. When this has been done, you are ready to submit the job. Note that the migration jobs must be submitted with the administrator user ID and password. Also note that you must migrate the deployment manager node first before any other nodes in a network deployment environment.
Verify migration
Verify migration Ensure that you receive a return code of zero when the job finishes If errors occurred, you can look in the /tmp/migrate/#tempdir# directory BPZWMG3*.err BPZWMG3*.out For additional information on errors, tracing can be enabled in the JCL by changing the values of these parameters: TraceState=enabled profileTrace=disabled preUpGradeTrace=disabled postUpGradeTrace=enabled
When finished, ensure that the migration job receives a return code of zero. If errors occurred, you can look at the BPXWMG3*.err and BPZWMG3*.out file that are generated in the /tmp/migrate/#tempdir# directory in the HFS. If you need additional information on errors you encounter, tracing can be enabled by changing the parameters shown on the slide in the JCL.
Perform data migration
Perform data migration Section
The last step in the migration process before starting the migrated nodes is to upgrade the data to the new schema being used in version 7.
Run DbDesignGenerator
Run the DbDesignGenerator shell script to generate the required upgrade SQL scripts Select to create a design for a single component Select Common and BPC Select default locations for SQL script generation Run DbDesignGenerator (2)Create a database design for a single component (e.g. BPC, CEI etc) [info] Please pick one of the following [component(s)] : (1)bpc (2)bpcreporting (3)bspace (4)cei (5)commondb (6)sibme [info] Please pick one of the following [scenario(s)] : (1)Configuration (2)Migration (3)Removal
There are a couple of components where you need to upgrade the schema for version 7. You should run the dbDesignGenerator script in order to do this. Select to create a database design for a single component and then select ‘bpc’ and ‘commondb’. In the case of ‘bpc’, you will have three choices and you should select ‘Migration’ as seen on the slide. In order to use the next script, upgradeDB, you should select to have the SQL generated to the default locations.
Generated SQL
Generated SQL DB2-zOS-8-CommonDB esbserver_upgradeSchema610_Recovery.sql esbserver_upgradeSchema610_lockmanager.sql upgradeSchema610DB2zOSV7.sql upgradeSchema610_CommonDB.sql upgradeSchema610_DirectDeploy.sql upgradeSchema610_governancerepository.sql upgradeSchema610_relationshipService.sql wbiserver_upgradeSchema610_Recovery.sql DB2-zOS-8-BPC upgradeSchema610.ddl upgradeSchema610.sql upgradeSchema610DB2zOSV7.ddl upgradeSchema610DB2zOSV7.sql upgradeTablespace610.ddl upgradeTablespace610.sql upgradeTablespace610DB2zOSV7.ddl upgradeTablespace610DB2zOSV7.sql
When looking in the directories where the SQL was generated, you will see many ‘upgrade’ scripts. They are all named appropriately to distinguish what level you are upgrading from. On the slide, you’ll see the SQL generated that needs to be run for a system that is being upgraded from version 6.1. In the directories are other scripts to upgrade from 6.0.2 and 6.2.0 as required.
Run upgradeDB script
Run upgradeDB script The upgradeDB shell script is provided in: -prefix-/usr/lpp/zWPS/V7R0/zos.config/samples Works like the createDB shell script Copy to a work directory and update Results found in cdbtmp/output.out and cdbtmp/error.out if SQL is run Sample invocation: ./upgradeDB.sh -SourceVersion 610 _________________________________________________________________ Alternatively, manually run the upgrade SQL that is created by the DbDesignGenerator script
You need to run all the upgrade SQL scripts generated for the version you are migrating from. To do this more seamlessly, an upgradeDB script is provided with the product. It works similar to the createDB script that is described in the z/OS DB2® Configuration presentation. The upgradeDB script has one required parameter, SourceVersion. This tells it which SQL it needs to run to perform the needed upgrade.
Summary
Summary Migration from V6.2.0, 6.1.2, 6.1.0 and 6.0.2 supported Migration process Performed on a node-by-node basis
This presentation covered the process of migrating an existing V6 WebSphere Process Server for z/OS configuration to version 7. Migration from version V6.2.0, 6.1.2, 6.1.0 and 6.0.2 is supported. You should now be familiar with the migration process. Just like a regular WebSphere Application Server migration, you saw that the WebSphere Process Server migration needs to be performed on a node-by-node basis.
Feedback
Feedback Your feedback is valuable You can help improve the quality of IBM Education Assistant content to better meet your needs by providing feedback. Did you find this module useful? Did it help you solve a problem or answer a question? Do you have suggestions for improvements? Click to send e-mail feedback: mailto:iea@us.ibm.com?subject=Feedback_about_WBPMv70_zOS_MigrationOverview.ppt This module is also available in PDF format at: ../WBPMv70_zOS_MigrationOverview.pdf
You can help improve the quality of IBM Education Assistant content by providing feedback.
Trademarks