Summary: Learn how to use the IBM WebSphere Application Server (WAS) and WebSphere Portal Server (WPS) migration framework to quickly and easily move WAS and WPS on z/OS from WPS v6.1.5 on WAS v7.0 to WPS 8.0 on WAS v8.0. This white paper explains the steps required to migrate a multiple cluster and maintain 24x7 WebSphere Portal availability.
Table of Contents1 Introduction...............................................................................................................................2
2 Maintaining 24x7 availability in migration procedure.................................................................53 WAS migration steps.................................................................................................................7
3.1 zMMT WAS configuration..................................................................................................74 Illustrated WAS migration steps...............................................................................................7
4.1 Creating migration jobs using zMMT.................................................................................84.2 Generating the DMgr zMMT job........................................................................................94.3 Generating the Cluster A zMMT job.................................................................................20
4.3.1 Primary node in Cluster A........................................................................................204.3.2 Secondary node in Cluster A....................................................................................29
5 Migrating the cell.....................................................................................................................385.1 Cell migration preparation (24x7)....................................................................................385.2 DMgr migration steps......................................................................................................405.3 Cluster A primary node migration steps...........................................................................415.4 Cluster B primary node migration steps...........................................................................425.5 Traffic flip.........................................................................................................................425.6 Cluster A secondary node migration steps.......................................................................425.7 Cluster B secondary node migration steps......................................................................43
6 Preparing for the Portal migration process..............................................................................446.1 Database copy process...................................................................................................446.2 Portal Customization configuration..................................................................................456.3 Illustrated Portal migration steps.....................................................................................45
6.3.1 Creating migration job for DMgr...............................................................................516.3.2 Creating migration jobs for primary node of Cluster A..............................................616.3.3 Creating migration jobs for secondary node of Cluster A.........................................84
7 Migrating WebSphere Portal.................................................................................................1007.1 Preparing for the migration............................................................................................1007.2 DMgr Portal migration steps..........................................................................................1007.3 Cluster A primary node Portal migration steps...............................................................1007.4 Cluster B primary node Portal migration steps..............................................................1017.5 Traffic flip.......................................................................................................................1027.6 Cluster A Secondary Node Portal migration steps.........................................................1027.7 Cluster B secondary node Portal migration steps..........................................................1037.8 Completing the Portal migration steps...........................................................................103
1 IntroductionThe IBM® WebSphere® Portal version 8.0 release allows migration from either version 6.1.x or 7.x of IBM WebSphere Portal. Earlier style migrations (to 6.0 or to 6.1) required a significant number of manual steps; in effect, requiring you to execute a series of staging to production steps.
These steps were all manual and open to error as they required a significant amount of data movement, such as exports and imports using XMLAccess, as well as manual application deployment.
This white paper describes a simplified method to migrate a WebSphere Portal v6.1 configuration running on IBM WebSphere Application Server (WAS) v7.0 to WAS v8.0. Additionally, we explain the steps to migrate the Portal v6.1 profile to Portal v8.0. The advantages of this method over the old method are many but, most importantly, it does not require manual processes to move data.
The process described in this paper to migrate the WebSphere Portal configuration is simple, requiring only the execution of a few IBM z/OS® jobs and a minimal number of ConfigEngine command-line calls. At the same time, we eliminate the complexities of a fresh WebSphere Portal installation, including security configuration, database connect, and clustering.
After these core migration steps described in the paper have been completed, there are many post-migration steps that will be required based on how the Portal environment is being used.
2
Make sure to refer to the Portal Wiki to get detailed instructions on all the post migration steps.
Figure 1 depicts the migration process.
Figure 1. Schematic of the migration process
3
WAS 7.0WP 6.1
WP 6.1 on WAS 7.0 Profile
WP 6.1
WP 6.1 on WAS 7.0 Profile
WAS 8.0WAS 7.0
WAS 8.0WP 6.1
WP 6.1 Profile on WAS 8.0
WAS 7.0
WP 6.1
WP 6.1
Install WebSphere Application andPortal Server Version 8 binaries
Migrate the WebSphere Portal v6.1 profile to WebSphere Application Version 8
Portal v6.1 is now using WebSphere Application Version 8
Install the WebSphere Portal v8.0 binariesIf not installed with WAS 8 binaries
WAS 8.0WP 8.0
WP 6.1 Profile on WAS 8.0
WP 8.0
Migrate the WebSphere Portal v6.1 to WebSphere Portal v8.0
WAS 8.0
WP 8.0 Profile on WAS 8.0Portal v8.0 is now using WebSphere Application Version 8
1.1 PrerequisitesYou must satisfy the following list of prerequisites before attempting the migration procedures:
• An operational WebSphere Portal cell with the minimum levels of WAS V7R0.0.15 and Portal V6R1.0.5.
• The following Portal iFixes are installed or available for the appropriate level of WebSphere Portal:
◦ PM25140◦ PM57025◦ PM64098◦ PM68602
• The latest level of Portal Update Installer must be used.
• Primary and Secondary nodes for each cluster must be on separate logical partitions (LPARs).
• The Web server(s) must have temporary plug-ins available to activate that will restrict traffic to individual nodes within the clusters while another node is being migrated.
• WAS version 8.0.0.3 or later libraries installed via System Modification Program/Enhanced (SMP/E) with a hierarchical file system (HFS) mounted on all systems:
◦ may be shared read-only across multiple LPARs◦ latest level of WAS WebSphere Customization Tools (WCT) available to provide the
migration management tool (MMT).
• WebSphere Portal version 8.0.0.0 or later libraries installed via SMP/E with an HFS mounted on all systems. May be shared read-only across multiple LPARs.
• Authorization of new WAS and Portal 8.0 procedure names to Resource Access Control Facility (RACF)
1.2 Configuration detailsThe steps by which this document was tested consist of WebSphere Portal 6.1.5.1 multiple clusters on WAS 7.0.0.15, migrated to WebSphere Portal 8.0 multiple clusters on WAS 8.0. This is a coexistence migration, in which WAS/Portal 7.0/6.1 and WAS/Portal 8.0 are on the same systems.
Figure 2 shows how the multiple cluster environment was configured.
4
Figure 2. Environment configuration diagram
Additional details of the environment are outlined as follows:
• Default Portal and three Virtual Portals, with more than 30,000 total Pages & Portlets• Custom Themes and Skins• IBM Web Content Manager (WCM) data, consisting of more than 40,0000 WCM objects• 100,000 users in LDAP• Other custom configuration and data
2 Maintaining 24x7 availability in migration procedureTo maintain 24x7 availability in the Portal migration, we must make copies of the databases. The copy procedure allows the production environment to maintain availability while the migration is occurring with the “copied” databases.
5
WebServer 2
CUS
FEED
COM
LIKE
REL
JCR
LPAR2LPAR1
JCR
REL
WebServer 1
WAS 7.0
Portal v6.1CAN
1
WAS 7.0
Portal v6.1CAN
2
WAS 7.0
Portal v6.1CBN
1
WAS 7.0
Portal v6.1CBN
2
WAS 7.0
DMGR
Cluster A
Cluster B
CELLWAS 8.0
DMGR
WAS 8.0
Portal v8.0CAN
1
WAS 8.0
Portal v8.0CAN
2
WAS 8.0
Portal v8.0CBN
1
WAS 8.0
Portal v8.0CBN
2 COPYCOPY
CAN1, CAN2, CBN1, and CBN2 represent the Cluster and Node names. For example; CAN1: Cluster A Node 1.Also, the diagram show two different LDAPs, which are configured across all nodes through the DMGR, but in this diagram we are pointing to the cell.
LDAP 1
LDAP 2
REL
JCR JCR
REL
COPYCOPY
By doing this, Portal will “render” throughout the migration process while only limiting the “authoring” when upgrading the databases.
In this documented environment, the primary nodes (located on the same LPAR) were migrated in sequence, whereas the secondary nodes maintained constant user load. Once both primary nodes were migrated, traffic was switched to the migrated nodes, and the secondary nodes (located on the same LPAR) were migrated in sequence. Once the secondary nodes were migrated, traffic was adjusted to include all nodes, and the migration experiment was concluded.
To maintain 24x7 availability during the migration, we must restrict access to the nodes being migrated until the node migration is complete. We achieved this by redirecting the end user traffic through the Web server administration.
To ensure reliable results during the migration process, automatic synchronization must be disabled. Manual and automated synchronization invoked by the migration occur during the migration process on a per-node basis, and once the migration of all nodes is complete, automatic synchronization can be re-enabled.
As documented in this paper, we followed the high-level steps below to maintain 24x7 availability:
(1) Disable auto-synchronization(2) Switch traffic to secondary nodes (located on LPAR2)(3) Migrate WAS profiles for Deployment Manager (DMgr) and primary nodes (located on
LPAR1)(4) Switch traffic to primary nodes(5) Migrate WAS profiles for secondary nodes; at this time you time you have Portal 6.1
running on WAS 8. You will continue with the Portal migration.(6) Disable auto-synchronization, if re-enabled after WAS migration(7) Switch traffic to secondary nodes(8) Migrate Portal on primary nodes(9) Switch traffic to primary nodes(10)Migrate Portal on secondary nodes. Migration process is complete; you can proceed with
post-migration considerations.
Following the 24x7 procedure, we were able to sustain a consistent rendering load of 100 total users throughout the migration process. Each user is authenticating, navigating through 600 customized Pages/Portlets, and rendering WCM content on a 20-page setup.
Per the WAS product documentation, the user has the option to execute a monolithic command that performs all the jobs required to complete the migration. In our procedure, however, we run each job manually, specifically for the DMgr migration. We must do this for remote DMgr migrations to allow the WebSphere Portal migration plug-in to be added to the WAS migration framework.
In scenarios in which the DMgr is not on the same machine as the Portal node(s), the WAS/Portal 8 binaries are not available for the DMGR. Therefore, the plug-in must be applied after the profile creation, during the WAS migration. If the plug-in is not loaded into the WAS migration framework, the WebSphere Portal application will fail to migrate.
6
NOTE: Change the Web server plug-ins so that they use only the portals not being migrated. Refer to your Web server documentation on managing application server access; configuring the Web server plug-ins is beyond the scope of this paper.
3 WAS migration stepsAfter the prerequisites are satisfied, we begin the migration process by generating the WAS migration jobs, using the z/OS Migration Management Tool (zMMT). This tool is a GUI and does not run natively on the z/OS server, so it must be installed on an OS that supports a GUI.
Once all the WebSphere z/OS jobs are created, they must be uploaded to the z/OS server. At a high level, there are three main functions that the z/OS jobs perform, that is, profile creation, profile configuration extraction, and profile configuration import. An additional step is required to ensure the WebSphere Portal configuration is properly migrated.
The order of steps is as follows:
1. Profile creation. This job creates the profile, using values that replicate the basic configuration parameters of the source server. These parameters include the node name and the cell name.
2. Install the WebSphere Portal migration plug-in. This plug-in is required to properly handle the WebSphere Portal server configuration, applications, and file system artifacts. With Portal 8.0, this plug-in is installed with the Portal Binaries, through IIM.
3. Configuration extraction. This job calls WASPreUpgrade to export the WebSphere configuration, along with the applications, into a backup directory.
4. Configuration migration. This job calls WASPostUpgrade to transfer the contents of the backup directory into the profile created in Step 1. It examines the contents of the backup directory and performs the configuration or transformation required by WAS v8.
3.1 zMMT WAS configurationLet's now install the latest WAS WCT, including the zMMT. Refer to the WebSphere Application Server information center for details on installing the zMMT.
1. Launch zMMT and specify the parameters for your DMgr and WebSphere Portal nodes.
2. Use the proper ids and passwords:
• Identify proper mounting locations for new WAS configuration file systems for co-existence with the previous WAS level, as you won't want to move them around after the migration.
3. Upload the job files to the appropriate z/OS system.
4 Illustrated WAS migration stepsThis section describes the steps required to migrate WAS from V7R0 to V8R0 while keeping WebSphere Portal operational. The configuration used in this case is a single cell with two clusters of two nodes each (see figure 3).
Both primary nodes and the DMgr are on the same z/OS LPAR, whereas both secondary nodes share a second LPAR. Each LPAR has 10GB of memory, four shared General Central Processors (GCPs), one shared z/OS Integrated Information Processor (zIIP), and one shared z/OS Application on Assist Processor (zAAP).
Our procedure allows for continuous operation of Portal traffic during the WAS and Portal migration. The traffic used to validate the 24x7 capability of this procedure focuses on simple page navigation sessions by 100 simulated users per cluster. As mentioned before, each user is authenticating, navigating through 600 customized Pages/Portlets, and rendering WCM content on a 20-page setup.
The zAAP doesn't exceed 40% per LPAR, and the GCP's are mainly used for transition and task execution, not traffic. Each cluster has its own IBM HTTP Server (IHS).
4.1 Creating migration jobs using zMMTFirst, we use zMMT to create all the jobs for every node before executing any migration job. Ensuring all the jobs have been created first will make the migration process easier.
The below sample graphics (figures 4 – 40, in Sections 4.2 and 4.3) are only for the DMgr and the first cluster (Cluster A); however, the second cluster graphics should be similar to those of the first cluster.
8
4.2 Generating the DMgr zMMT jobTo do this:
1. Open the WCT, select the z/OS Migration Management Tool tab, and click the Add button on the right-hand side of the Migration Locations section (see figure 4).
Figure 4. Add a migration location
3. Select the “Create a new migration location” option and fill in the Name and Location fields; click Finish (see figure 5).
9
Figure 5. Add Migration Location window
4. Respond “Yes” to create a directory that didn't already exist (see figure 6).
Figure 6. Create directory prompt
5. Click the Migrate button on the right-hand side of the Migrate Definitions tab (see figure 7).
10
Figure 7. Initiate creation of migration definition
6. Select the “z/OS migrate a deployment manager” option; click Next (see figure 8).
11
Figure 8. Migration Node Type Selection window
7. Specify the Migration definition name; click Next (see figure 9).
Figure 9. Migration Definition Name window
12
8. Specify the high-level qualifier (HLQ) for the CNTL and DATA data sets where the migration jobs will be created, as shown in figure 10.
Figure 10. Target Data Sets window
9. Specify the procedure library, WAS product directory, and whether to create intermediate symbolic links (see figure 11).
13
Figure 11. Data Set Names and Product Directory window
10. Specify definition parameters for the DMgr's configuration file system (see figure 12).
14
Figure 12. Configuration File System window
11. Complete the fields to direct the migration to the proper location (see figure 13).
15
Figure 13. Server Customization (Part 1) window
12. Specify the actions to be taken during migration (see figure 14).
NOTE: Be sure to make the necessary adjustments to the JavaTM Virtual Machine (JVM) heap size(s) based on your environment and dataset. Insufficient JVM allocation can result in standard out-of-memory error(s) during the WAS migration.
16
Figure 14. Server Customization (Part 2) window
13. Specify the job control statement to be applied to each Job Control Language (JCL) Job for migration of the DMgr (see figure 15).
17
Figure 15. Job Statement Definition
14. Click the Create button at the bottom of the next window (see figure 16).
18
Figure 16. Migration Summary (no update)
The migration of the DMgr is complete, as shown in figure 17.
19
Figure 17. Migration Creation Summary
4.3 Generating the Cluster A zMMT job
4.3.1 Primary node in Cluster A1. Click the Migrate button on the right-hand side under the Migrate Definitions tab (see figure
18).
20
Figure 18. Initiate creation of migration definition
2. Select the “z/OS migrate a federated node” option (see figure 19).
21
Figure 19. Migration Node Type Selection window
3. Specify the Migration definition name (see figure 20).
22
Figure 20. Migration Definition Name window
4. Specify the HLQ for the CNTL and DATA data sets where the migration jobs will be created (see figure 21).
Figure 21. Target Data Sets window
23
5. Specify the procedure library, WAS product directory, and whether to create intermediate symbolic links (see figure 22).
Figure 22. Data Set Names and Product Directory
6. Specify the definition parameters for the Node's configuration file system (see figure 23).
24
Figure 23. Configuration File System window
7. Complete the fields to direct the migration to the proper location (see figure 24).
25
Figure 24. Server Customization (Part 1)
8. Specify the actions to be taken during migration (see figure 25).
NOTE: Be sure to make the necessary adjustments to the JVM heap size(s) based on your environment and dataset. Insufficient JVM allocation can result in standard out-of-memory error(s) during the WAS migration.
26
Figure 25. Server Customization (Part 2)
9. Specify the job control statement to be applied to each JCL Job for migration of the node (see figure 26).
27
Figure 26. Job Statement Definition window
10. Click the Create button at the bottom of the Migration Summary window (see figure 27).
Figure 27. Migration Summary window (no update)
28
11. Click Finish at the bottom of the next screen; the migration of the federated node is complete (see figure 28).
Figure 28. Migration Creation Summary
4.3.2 Secondary node in Cluster A1. Click the Migrate button under the Migrate Definitions tab, and then select the “z/OS
migrate a federated node” option (see figure 29).
29
Figure 29. Migration Node Type Selection window
3. Specify the migration definition name; see figure 30.
30
Figure 30. Migration Definition Name window
4. Specify the HLQ for the CNTL and DATA data sets where the migration jobs will be created (see figure 31).
Figure 31. Target Data Sets window
31
5. Specify the procedure library, WAS product directory, and whether to create intermediate symbolic links; see figure 32.
Figure 32. Data Set Names and Product Directory window
6. Specify definition parameters for the node's configuration file system (see figure 33).
32
Figure 33. Configuration File System window
7. Complete the fields to direct the migration to the proper location (see figure 34).
33
Figure 34. Server Customization (Part 1)
8. Specify the actions to be taken during migration (see figure 35).
NOTE: Be sure to make the necessary adjustments to the JVM heap size(s) based on your environment and dataset. Insufficient JVM allocation can result in standard out-of-memory error(s) during the WAS migration.
34
Figure 35. Server Customization (Part 2)
9. Specify the job control statement to be applied to each JCL Job for migration of the node (see figure 36).
35
Figure 36. Job Statement Definition
10. Click the Create button at the bottom of the Migration Summary window (see figure 37).
Figure 37. Migration Summary (no update)
36
11. Click the Finish button at the bottom of the next window (see figure 38).
Figure 38. Successful job creation summary
12. Finally, click the Process button to send the jobs for the DMgr and each node to your z/OS host, creating the z/OS data sets as necessary; see figure 39.
37
Figure 39. Process the definitions
5 Migrating the cellThe DMgr must be the first node migrated, after which it will resume responsibility of managing the Portal v6.1 node on WAS v8.0. WebSphere supports mixed node cells, but the WebSphere Portal recommendation is that you run it in a homogenous WAS environment.
During the migration, there will be a period in which there will be a mixture of WAS v7.0 nodes and v8.0 nodes. Keep in mind this should be a temporary state, and you should complete the migration of the WAS nodes for the long-term operation of your production environment. A mixed WAS Version Node environment can produce instability. All nodes need to be brought up to the same level prior to performing any WAS administration, updates, or using the environment for anything other than rendering pages on the nodes that have been migrated.
The DMgr must be updated with the WebSphere Portal migration plug-in, just as the target WAS node will be, for the migration to be successful. The plug-in for the DMgr is installed with the Portal Binaries, through IIM. In environments in which the Portal binaries are not shared with the DMgr, the plug-in can be installed with the a Portal customization job.
5.1 Cell migration preparation (24x7)Here are the steps required to ensure 24x7 operation during the migration of the cell:
38
1. Change the Web server plug-in(s) so that they only use the portals on the secondary nodes.
2. Stop both primary portals on LPAR #1, and apply iFixes (PM25140, PM57025, PM64098, and PM68602) on both Portal primary nodes with the DMgr active. Note that the combination of APARs PM64098 & PM68602 requires a restart of Portal and the execution of update-wcm and update-wcm-fp615 ConfigEngine tasks. Consult APAR instructions for details (Portal APAR PM25140 is included in Portal 6.1.0.6).
3. Verify that the iFixes are installed successfully, for example:
/<Cluster A Primary node 6.1 profile>/PortalServer/bin#>./WPHistoryInfo.sh
The following is an exampled of what you should see with APAR PM25140, but you need all APARs installed:
Installation Event--------------------------------------------------------------------------------Fix ID PM25140Action installLog File Name /PortalServer/1/Portal/version/log/20120530_032851_PM25140_install.logStart Time 2012-05-29T23:28:51-04:00End Time 2012-05-29T23:28:51-04:00Result succeededResult Message Successful installation
Component Installation Event ----------------------------------------------------------------------------- Fix ID PM25140 Component Name wp.migration.framework Action install Is Custom false Primary Content update.jar Update Action patch Is External false Log File Name /PortalServer/1/Portal/version/log/20120530_032851_PM25140_wp.migration.framework_install.log Backup File Name /PortalServer/1/Portal/version/backup/20120530_032851_PM25140_wp.migration.framework_undo.jar Start Time 2012-05-29T23:28:51-04:00 End Time 2012-05-29T23:28:51-04:00 Result succeeded Result Message Successful installation
--------------------------------------------------------------------------------End History Report
5. Manually synchronize both primary nodes on LPAR #1.
6. Use the DMgr Admin Console to turn OFF automatic synchronization for all four node agents:
)a Select System administration – Node agents – node agent name – File synchronization Service.
)b Deselect "Automatic synchronization" and deselect "Enable service at server startup."
7. Manually synchronize all nodes from the DMgr Admin Console. Note that this synchronization could take more than a few minutes (up to 80 minutes was experienced).
39
8. Stop DMgr and all node agents on LPAR #1 and LPAR #2. DO NOT stop the daemon on LPAR #2; otherwise, the portals will come down also.
9. Start DMgr and all node agents on LPAR #1 and LPAR #2, and verify automatic synchronization is no longer occurring.
10. Manually synchronize all nodes from the DMgr Admin Console.
5.2 DMgr migration stepsNOTE: Before executing any z/OS JCL jobs, consult the DMgr migration instructions in the BBODMINS file generated in the CNTL dataset from zMMT for the DMgr. This helps you to ensure that all preliminary steps are completed and provides additional information about each z/OS JCL job that will be run.
1. Run BBOMDHFS, to create a new DMgr HFS for WAS 8.0.
2. Run BBOMDCP, to copy z/OS procedures to a specified proclib for WAS 8.0; in our example, USER.PROCLIB.
3. Run BBOWDPRO to create the DMgr profile. If the system is under heavy load, you might need to modify the following to avoid a timeout:
NOTE: Red text throughout the remainder of this paper indicates things to look out for, either in the JCL itself or the subsequent output that's displayed, based on the migration procedures outlined and PM25140 enhancements.
4. If the DMgr is on the same machine as any WAS/Portal node(s) and shares the WAS/Portal binaries, then proceed to Step 6. If the DMgr is standalone and does not share the WAS/Portal node binaries, then run the Portal ISPF customization dialog to generate a new EJPSCFGD job (see listing 1). See Section 11.1 to create the EJPSCFGD job, and then return to this step.
5. Stop the DMgr (do NOT stop the daemon), run EJPSCFGD, and then restart the DMgr.
40
6. Run BBOWDPRE, to prepare the environment for migrating the DMgr. If the system is under heavy load, you might need to modify the following to avoid a timeout:
//PREUPGRD EXEC PGM=IKJEFT01,REGION=0M,COND=(4,LE),TIME=NOLIMIT7. Run BBOWDPOS, to migrate the DMgr to WAS 8.0. If the system is under heavy load, you
might need to modify the following to avoid a timeout:
8. Stop the DMgr daemon on LPAR #1 only; this stops all servers on LPAR #1.
WARNING: DO NOT start the v7.0 DMgr after this step.
9. Start the new WAS v8 DMgr, making sure to use the WAS 8 procedure name, and verify the ENV name in the WAS v8 DMgr's mounted directory (/WebSphere/dm2, in our example). It is generally the same as it was for v7R0, even though the procedure is different:
For example: S DMGR8CR,JOBNAME=DMGR7,ENV=M298CELL.M298MGR.DMGR7
10. Verify the WAS eyecatcher indicates the appropriate level of WAS; for example,
BBOM0007I CURRENT CB SERVICE LEVEL IS build level 8.0.0.03(cf031208.05) release WAS80.ZNATV date 02/23/12 19:23:41.
11. Start the primary node node agents on LPAR #1 (do NOT manually synchronize them).
5.3 Cluster A primary node migration stepsNOTE: Before executing any z/OS JCL jobs, consult the Cluster A primary node migration instructions in the BBOMMINS file generated in the CNTL dataset from zMMT for the Cluster A primary node. This helps you ensure all preliminary steps are completed and provides additional information about each z/OS JCL job that will be run.
1. Run BBOMMHFS, to create a new primary node HFS for WAS 8.0. (Note that we do run BBOWMG1F or BBOWMG2F, because we don't have any XA connectors installed in the previous server.)
2. Run BBOMMCP, to copy z/OS procedures to the specified proclib for WAS 8.0; in our example, USER.PROCLIB.
3. Run BBOWMPRO, to create the node-agent profile.
4. Run BBOWMPRE, to prepare the environment for migrating the node.
5. Run BBOWMPOS, to migrate the node to WAS 8.0.
6. Start the new WAS 8.0 node, being sure to use the correct WAS 8.0 procedure; for
41
example:
S CAN18CR,JOBNAME=CAN17NA,ENV=M298CELL.CAN17N.CAN17NA7. Manually synchronize the new WAS 8.0 node with the WAS 8.0 DMgr from the DMgr Admin
Console.
8. Start the primary node Portal from the DMgr Admin Console.
5.4 Cluster B primary node migration stepsBefore executing any z/OS JCL jobs, consult the Cluster B primary node migration instructions in the BBOMMINS file generated in the CNTL dataset from MMT for the Cluster A primary node.
1. Run BBOMMHFS, to create a new primary node HFS for WAS 8.0. (Note that we didn't run BBOWMG1F or BBOWMG2F, because we didn't have any XA connectors installed on the previous server.)
2. Run BBOMMCP, to copy z/OS procedures to the specified proclib for WAS 8.0; in our example, USER.PROCLIB.
3. Run BBOWMPRO, to create the node-agent profile.
4. Run BBOWMPRE, to prepare the environment for migrating the node.
5. Run BBOWMPOS, to migrate the node to WAS 8.0.
6. Start the new WAS 8.0 node, being sure to use the WAS 8.0 procedure; for example:
S CBN18CR,JOBNAME=CBN17NA,ENV=M298CELL.CBN17N.CBN17NA
7. Manually synchronize the new WAS 8.0 node with the WAS 8.0 DMgr from the DMgr Admin Console.
8. Start the primary Portal node from the DMgr Admin Console.
5.5 Traffic flip1. Switch the Web server plug-in files to include the primary nodes (keeping the secondary
nodes). There should be no session failures for just adding new nodes.
1. Once you verify that traffic is running to the primary nodes, switch the Web server plug-in files to exclude the secondary nodes. Note that some session loss is expected during this action.
2. Once the switch is complete, stop Portal on the secondary nodes.
4. Apply the PM25140 iFix with Portal down on both secondary nodes (the DMgr must be up). Portal APAR PM25140 is included in Portal 6.1.0.6.
5.6 Cluster A secondary node migration stepsNOTE: Before executing any z/OS JCL jobs, consult the Cluster A secondary node migration instructions in the BBOMMINS file generated in the CNTL dataset from MMT for the Cluster A
42
secondary node.
1. Run BBOMMHFS, to create a new secondary node HFS for WAS 8.0. (We didn't run BBOWMG1F or BBOWMG2F because we didn't have any XA connectors installed on the previous server.)
2. Run BBOMMCP, to copy z/OS procedures to the specified proclib for WAS 8.0; in our example, USER.PROCLIB.
3. Run BBOWMPRO, to create the node-agent profile.
4. Run BBOWMPRE, to prepare the environment for migrating the node.
5. Run BBOWMPOS to migrate the node to WAS 8.0.
6. Stop the daemon on LPAR #2; the WAS v8 daemon must be started with the first migrated node per system. (NOTE: This will stop all application servers on LPAR #2.)
7. Start the new WAS 8.0 node, being sure to use the WAS 8.0 procedure; for example:
S CAN28CR,JOBNAME=CAN27NA,ENV=M298CELL.CAN27N.CAN27NA
8. Manually synchronize the new WAS 8.0 node with the WAS 8.0 DMgr from the DMgr Admin Console.
9. Start the secondary Portal node from the DMgr Admin Console.
5.7 Cluster B secondary node migration stepsNOTE: Before executing any z/OS JCL jobs, consult the Cluster B Secondary node migration instructions in the BBOMMINS file generated in the CNTL dataset from MMT for the Cluster A Secondary node.
1. Start the WAS v6 secondary node agent for Cluster B, if it is still down from stopping the daemon on LPAR #2 (do NOT synchronize this node with the DMgr at this point).
2. Run BBOMMHFS, to create a new secondary node HFS for WAS 8.0. (We didn't run BBOWMG1F or BBOWMG2F because we didn't have any XA connectors installed on the previous server.)
3. Run BBOMMCP, to copy z/OS procedures to specified the proclib for WAS 8.0; in our example, USER.PROCLIB.
4. Run BBOWMPRO, to create the node-agent profile.
5. Run BBOWMPRE, to prepare the environment for migrating the node.
6. Run BBOWMPOS to migrate the node to WAS 8.0.
7. Start the new WAS 8.0 node, being sure to use the WAS 8.0 procedure; for example:
43
S CBN28CR,JOBNAME=CBN27NA,ENV=M298CELL.CBN27N.CBN27NA
8. Manually synchronize the new WAS 8.0 node with the WAS 8.0 DMgr from the DMgr Admin Console.
9. Start the secondary Portal node from the DMgr Admin Console.
10. Switch the Web server plug-in files to include all nodes; there should be no session failures for just adding new nodes.
11. Verify that traffic successfully uses all nodes.
12. Re-enable “Automatic synchronization” and “Enable service at server startup on all node agents,” using System Administration – Node agents – nodeagent, from the DMgr Admin Console.
13. Stop the DMgr and all node agents (do NOT stop the daemons), restart the DMgr and all node agents, and then verify automatic synchronization is working again.
6 Preparing for the Portal migration processNow that we have Portal functioning on our migrated WAS, we can begin the Portal migration process. It is important to note that Portal and all applications that have been deployed in this environment have not been modified and may not work after updating WAS, if there are any dependencies on features or specifications that have been deprecated or updated. Portal and WCM administration will not be available at this time and it is highly advised to test any custom applications in a Sandbox Portal 8 WAS 8 environment in order to prepare the applications for the new versions prior to migration, if they will be needed immediately after migration is complete.
All the Portal migration jobs are automated and can be generated by use of the WebSphere Portal for z/OS Customization dialog. Unlike the WAS zMMT, this interface runs natively on the z/OS server. In this paper, we navigate through the migration related panels.
Once all the WebSphere z/OS jobs are created, you will run a series of jobs to complete the Portal migration. At a high level, there are four main functions that the Portal administrator performs, including configuring the binaries and deployment manager, migrating Portal, and doing post-migration data updates. One additional step, copying the source JCR and Release databases, is highly recommended to accomplish 24x7 availability during migration.
The steps are as follows:
(1) Copy the source JCR and Release databases. This step is recommended to keep the previous Portal environment in production and reduce the amount of downtime during migration.
(2) Configure the WebSphere Portal files in preparation for migration. These jobs configure the WebSphere Portal binaries and initialize the WebSphere Portal file system.
(3) Configure the primary node to communicate with the DMgr. This job installs the files
44
required by WebSphere Portal into their proper location on the DMgr.
(4) Migrate the WebSphere Portal profile. These jobs will migrate the previous Portal profile data to the current installation.
(5) Post-migration data update. These jobs will update your target version's data with the latest data of the source, if the source was updated during migration.
6.1 Database copy processWhen migrating from WebSphere Portal, you are advised to use a recommended method for keeping the previous Portal environment in production and reducing the amount of downtime. Specifically, the process is to (1) copy the earlier WebSphere Portal server Java ContentRepository (JCR), (2) connect to the domain copies, and then (3) update the new server, using the domain copies. In addition to the JCR domain, you must also make copies of the Release domain and any other JCR-related databases.
The developerWorks white paper, “Migrating an IBM WebSphere Portal 6.1 database to WebSphere Portal 7.0 using the IBM DB2 Database Administration Tool V7.2 for z/OS," provides detailed steps to migrate the WebSphere Portal database(s) on z/OS. After copying the source server databases, you can proceed to the Portal customization.
6.2 Portal Customization configurationAs explained in the WebSphere Portal documentation, customizing WebSphere Portal is performed by use of the Customization Dialog, an ISPF Dialog that eliminates the need to tailor sample jobs supplied with the product. Through a series of panels, you choose options and define variables.
The Customization Dialog tailors the WebSphere Portal customization jobs for your variables. Here we highlight the steps required to migrate WebSphere Portal version 6.1 to version 8.0. Refer to the “Starting the Customization Dialog” product documentation topic for complete details on starting the Customization Dialog.
6.3 Illustrated Portal migration stepsWe use the Portal Customization Dialog to create all the Portal jobs for every node before executing any migration job. Ensuring all the jobs have been created first will make the migration process easier.
The below sample screenshots (figures 40 – 93) are for the DMgr and the first cluster (Cluster A) only; however, the second cluster screenshots should be similar to those of the first cluster.
1. After starting the Customization Dialog (see figure 40 and 41), load the base configuration data from WCT (zPMT or zMMT).
2. Next, configure WebSphere Portal for z/OS (see figure 42).
47
Figure 42. Option 2, Configure WebSphere Portal for z/OS
3. Follow the migration path by selecting Option 4, “Portal migration” (see figure 43).
48
Figure 43. Option 4, Portal migration
4. Select Option 1, “Select this option to migrate a previous WebSphere Portal for z/OS to the current version” (see figure 44).
49
Figure 44. Option 1, “Select this option to migrate a previous...”
5. In the next window (see figure 45) you see the main dialog options to migrate to WebSphere Portal 8. We will refer to this window as the “Portal Migration Dialog Home.”
50
Figure 45. Portal Migration Dialog Home
6.3.1 Creating migration job for DMgr1. From the Portal Migration Dialog Home, select Option 3, “Configure Deployment Manager”
(see figure 46).
51
Figure 46. Configure Deployment Manager
2. Select Option 1, “Allocate target data sets.” (see figure 47).
52
Figure 48. Allocate target data sets
3. Complete the allocation of the target data set (see figure 48).
53
Figure 48. Finish allocation of target data sets
4. Select Option 2, “Define variables” (see figure 49).
54
Figure 49. Define variables
5. Fill in the appropriate values and press Enter (see figure 50).
55
Figure 50. Define variables for DMgr
6. Select Option 3, “Generate customization jobs” (see figure 51).
56
Figure 51. Generate customization jobs
7. Select Option 1, “Generate customization jobs for this task” (see figure 52).
57
Figure 52. Generate customization jobs for this task
8. Specify job cards and press Enter (see figure 53).
58
Figure 53. Specify job cards
9. The next window (see figure 54) shows that the members exist; therefore, they are deleted and recreated.
59
Figure 54. Jobs created
The following are created:
CNTL -Data members containing jobs that will be executed.• EJPINDM. Instructions to configure the primary node to communicate with the deployment
manager.• EJPSCFGD. This job installs the files required by WebSphere Portal into their proper
location on the Deployment Manager.
10. Optionally, you can save your customization variables and proceed to the next step (see figure 55).
60
Figure 55. Save DMgr configuration
6.3.2 Creating migration jobs for primary node of Cluster A1. From the Portal Migration Dialog Home, select 2. “Configure the WebSphere Portal
binaries” (see figure 56).
61
Figure 56. Configure WebSphere Portal binaries
2. Optionally, you can select 1, “Allocate target data sets,” to allocate new target data sets, or you can reuse the data sets created for the DMgr jobs (see figure 57).
62
Figure 57. Allocate target data sets
3. Complete the allocation of the target data set (see figure 58).
63
Figure 58. Complete allocation of target data sets
4. Select 2, “Define variables” (see figure 59).
64
Figure 59. Define variables
5. Select “1 - System locations” (see figure 60).
65
Figure 60. System locations
6. Complete the System locations information (see figure 61).
66
Figure 61. System locations details
7. Now select “2 - Server configuration” (see figure 62).
67
Figure 62. Server configuration
8. Complete the server configuration (see figure 63).
68
Figure 63. Server configuration details
9. Upon returning to the “Configure the WebSphere Portal file system” window, back out one level to the “Install the WebSphere Portal binaries” window and select 3, “Generate customization jobs.” (see figure 64).
69
Figure 64. Generate customization jobs
10. Complete the customization panels to generate the jobs. The following jobs will be created in the Allocated target data sets defined in Step 2 of this section:
CNTL• EJPIBCM. Instructions to configure the WebSphere Portal files in preparation for migration.• EJPSCFGM. This job prepares the WebSphere Portal sections of the file system for
migration.• EJPSMICE. This job installs the configuration engine into the WAS profile directory and
performs the necessary localization.
DATA • EJP2BMPT. Data member that contains information for binary configuration.
70
11. Optionally, you can save your customization variables and proceed to the next step.
12. From the Portal Migration Dialog Home, select 4, “Migrate the WebSphere Portal profile” (see figure 65).
Figure 65. Migrate WP profile
13. Select 2, “Define variables” (see figure 66).
71
Figure 66. Define variables
14. Select “1 - Database driver configuration” (see figure 67).
72
Figure 67. Database driver configuration
15. Complete the next two Database driver configuration windows (see figures 68 and 69).
73
Figure 68. Database driver details 1
74
Figure 69. Database driver details 2
16. Select “2 - Database configuration” (see figure 70).
75
Figure 70. Database configuration
17. Complete the next series of windows with the database configuration information (see figures 71-- 76). NOTE: It is crucial to specify the copied database domains, leaving the original databases in production, providing 24x7 availability. Consult with your database administrator to confirm the correct values.
76
Figure 71. Database configuration release
77
Figure 72. Database configuration customization
78
Figure 73. Database configuration community
79
Figure 74. Database configuration JCR
80
Figure 75. Database configuration Feedback
81
Figure 76. Database configuration LikeMinds
18. Upon returning to the “Migrate profile” window, back out one level to the “Migrate the WebSphere Portal profile” window and select 3, “Generate customization jobs” (see figure 77).
82
Figure 77. Generate jobs
19. Complete the customization windows to generate the jobs. The following jobs will be created in the allocated target data sets defined in Step 2 of this section:
CNTL - Data members that contain jobs that will be executed• EJPIMPRF. Instructions to configure the WebSphere Portal files in preparation for
migration.• EJPSMPRE. This job performs premigration checks and setup prior to migrating the profile.• EJPSDBC. This job installs the configuration engine into the WAS profile directory and
performs the necessary localization. • EJPSMUD1. This job updates the database by running part one of the scripts generated in
the preceding step.• EJPSMCKD. This job invokes CHECK DATA for the portal table spaces that are in status
"CHECK PENDING" right after database transfer. It also executes the RUNSTATS utility on the database.
• EJPSMUD2. This job completes the database updates by running the second part of the scripts generated previously.
83
• EJPSMPRF. This job is used to upgrade the configuration data in the WebSphere Portal for z/OS profile.
DATA - Data members that contain information for migration.• EJP2DBT• EJP2UID
20. Optionally, you can save your customization variables, exit the Portal Customization Dialog, and proceed to the next step.
6.3.3 Creating migration jobs for secondary node of Cluster A1. From the Portal Migration Dialog Home on the secondary node, select 2, “Configure the
WebSphere Portal binaries” (see figure 78).
Figure 78. Configure WebSphere Portal binaries
2. Select 1, “Allocate target data sets,” to allocate new target data sets (see figure 79).
84
Figure 79. Allocate target data sets
3. Complete the allocation of the target data sets (see figure 80).
85
Figure 80. Complete allocation of target data sets
4. Select 2, “Define variables” (figure 81).
86
Figure 81. Define variables
5. Select “1 - System locations” (see figure 82).
87
Figure 82. System locations
6. Complete the system locations information (see figure 83).
88
Figure 83. System location details
7. Now select “2 - Server configuration” (see figure 84).
89
Figure 84. Server configuration
8. Complete the server configuration (see figure 85).
90
Figure 85. Server configuration details
9. Upon returning to the “Configure the WebSphere Portal file system” window, back out one level to the “Install the WebSphere Portal binaries” window and select 3, “Generate customization jobs” (see figure 86).
91
Figure 86. Generate customization jobs
10. Complete the customization windows to generate the jobs. The following jobs will be created in the Allocated target data sets defined in Step 2 of this section:
CNTL - Data members that contain jobs that will be executed• EJPIBCM. Instructions to configure the WebSphere Portal files in preparation for migration.• EJPSCFGM. This job prepares the WebSphere Portal sections of the file system for
migration.• EJPSMICE. This job installs the configuration engine into the WAS profile directory and
performs the necessary localization.
DATA - Data members that contain information for migration.• EJP2BMPT . Data member that contains information for binary configuration.
92
11. Optionally, you can save your customization variables and proceed to the next step.
12. From the Portal Migration Dialog Home, select 4, “Migrate the WebSphere Portal profile” (see figure 87).
Figure 87. Migrate WP profile
13. Select 2, “Define variables” (see figure 88).
93
Figure 88. Define variables
14. Select “1 - Database driver configuration” (see figure 89).
94
Figure 89. Database driver configuration
15. Complete the next two Database driver configuration windows (see figures 90 and 91).
95
Figure 90. DB driver configuration 1
96
Figure 91. DB driver configuration 2
16. Select “2 - Database configuration” (see figure 92).
97
Figure 92. Database configuration
17. Complete the next series of windows with the database configuration information. Since the secondary node is using the same database domains as the primary node, refer to figures 71 -- 76 in the previous section.
NOTE: Again, it is crucial to specify the copied database domains, leaving the original databases in production, and providing 24x7 availability. Consult with your database administrator to confirm the correct values.
18. Upon returning to the “Migrate profile” window, back out one level to the “Migrate the WebSphere Portal profile” window and select 3, “Generate customization jobs” (see figure 93).
98
Figure 93. Generate jobs
19. Complete the customization windows to generate the jobs. The following jobs will be created in the Allocated target data sets defined in Step 2 of this section:
CNTL - Data members that contain jobs that will be executed• EJPIMPRS. Instructions for profile migration of additional, non-primary nodes.• EJPSMPRF. This job is used to upgrade the configuration data in the WebSphere Portal for
z/OS profile.
DATA - Data members that contains information for migration.• EJP2DBT• EJP2UID
20. Optionally, you can save your customization variables, exit the Portal Customization Dialog, and proceed to the next step.
99
7 Migrating WebSphere Portal7.1 Preparing for the migrationIf automatic synchronization was re-enabled after the WAS migration, perform these steps to disable automatic synchronization, prior to migrating Portal.
1. Use the DMgr Admin Console to turn OFF automatic synchronization for all four node agents:
a) Select System administration – Node agents – node agent name – File synchronization Service.
b) Deselect “Automatic synchronization" and deselect "Enable service at server startup."
2. Manually synchronize all nodes from the DMgr Admin Console. Note that this synchronization could take more than a few minutes (up to 80 minutes was experienced).
3. Stop DMgr and all node agents on LPAR #1 and LPAR #2. DO NOT stop the daemon on LPAR #2; otherwise, the portals will come down also.
4. Start DMgr and all node agents on LPAR #1 and LPAR #2, and verify that automatic synchronization is no longer occurring.
5. Manually synchronize all nodes from the DMgr Admin Console.
7.2 DMgr Portal migration stepsNOTE: Consult the job instructions in the EJPINDM file generated in the CNTL dataset from Section 6.3.1. This helps to ensure that all preliminary steps are completed and provides additional information about each z/OS JCL job that will be run.
1. Stop the DMgr daemon on LPAR #1 only; this stops all servers on LPAR #1.
2. Run EJPSCFGD, to install the files required by Portal into their proper location on the DMgr.
3. Start the DMgr and node agent(s). Technically, you can start Portal on the primary node of the second cluster, if needed. Do not synchronize either node.
7.3 Cluster A primary node Portal migration stepsNOTE: Consult the job instructions in the EJPIBCM and EJPIMPRF files, generated in the CNTL dataset from section 6.3.2 This helps to ensure that all preliminary steps are completed and provides additional information about each z/OS JCL job that will be run.
1. Run EJPSCFGM, to prepare the WebSphere Portal sections of the file system for migration.
2. Confirm the DMgr is started and the WebSphere Portal server is stopped on the primary node of Cluster A.
3. Run EJPSMICE, to install the configuration engine into the WAS profile directory and perform the necessary localization.
4. Confirm that both DMgr and CAN1 node agent are started.
100
5. Optionally, you can run EJPSMPRE, which will generate database migration scripts for inspection.
6. Run EJPSDBC to modify the database connection for migration, essentially connecting to the copied databases.
7. Run EJPSMUD1 to update the database by running the first part of the scripts generated in preceding step.
8. Run EJPSMCKD to CHECK DATA for the portal table spaces that are in status "CHECK PENDING" state and execute the RUNSTATS utility on the database.
9. Run EJPSMUD2 to complete the database updates by running the second part of the scripts generated previously. This is the primary “database-upgrade” task, which may take hours, depending on the amount of content being migrated.
10. Run EJPSMCKD again, to CHECK DATA for the migrated portal table spaces that are in status "CHECK PENDING" state, and execute the RUNSTATS utility on the migrated database.
11. From the DMgr, synchronize only CAN1 by selecting System Administration, and then CAN1 node. Click the Synchronize button.
12. Run the final migration job, EJPSMPRF, to upgrade the configuration data in the WebSphere Portal for z/OS profile.
13. When WebSphere Portal is migrated from versions 6.1.0.5 to 8, the Portal context root is changed during the process because the Portal migration must migrate the themes from the wps Enterprise Application and ensure that the WebSphere Portal will function as designed. Based on this requirement for all customers, the context root will be automatically modified to original-context-root_migrated by the migration. Changing the Portal context root after migration is not required, but it is recommended for users who want to revert the context root to the original value. For example, before migration, you would render Portal with http://hostname:10039/wps/portal. After migration it is changed to http://hostname:10039/wps_migrated/portal. If you leave the portal context root at wps_migrated, WebSphere Portal will still work as designed. Confirm the migration by rendering WebSphere Portal with the modified context root; complete the verification test and proceed to the next step.
7.4 Cluster B primary node Portal migration stepsNOTE: Consult the job instructions in the EJPIBCM and EJPIMPRF files generated in the CNTL dataset from Section 6.3.2 Jobs shown in that section were created specifically for the primary node of Cluster A. This helps to ensure that all preliminary steps are completed and provides additional information about each z/OS JCL job that will be run.
1. Run EJPSCFGM, to prepare the WebSphere Portal sections of the file system for migration.
2. Confirm that the DMgr is started and the WebSphere Portal server is stopped on the primary node of Cluster B.
101
3. Run EJPSMICE to install the configuration engine into the WAS profile directory and perform the necessary localization.
4. Confirm that both DMgr and CBN1 node agent are started.
5. Optionally, you can run EJPSMPRE, which will generate database migration scripts for inspection.
6. Run EJPSDBC to modify the database connection for migration, essentially connecting to the copied databases.
7. Run EJPSMUD1 to update the database by running part one of the scripts generated in the preceding step.
8. Run EJPSMCKD to CHECK DATA for the portal table spaces that are in status "CHECK PENDING" state and execute the RUNSTATS utility on the database
9. Run EJPSMUD2 to complete the database updates by running the second part of the scripts generated previously. This is the primary “database-upgrade” task which may take hours, depending on the amount of content being migrated.
10. Run EJPSMCKD again, to CHECK DATA for the migrated portal table spaces that are in status "CHECK PENDING" state and execute the RUNSTATS utility on the migrated database.
11. From the DMgr, only synchronize CBN1, by selecting System Administration, and then CBN1 node. Press the Synchronize button.
12. Run the final migration job, EJPSMPRF to upgrade the configuration data in the WebSphere Portal for z/OS profile.
13. Confirm the migration by rendering WebSphere Portal with the modified context root; complete the verification test and proceed to the next step.
7.5 Traffic flip1. Switch the Web server plug-in files to include the primary nodes (keeping the secondary
nodes). There should be no session failures for just adding new nodes.
2. Once traffic is verified to be running to the primary nodes, switch the Web server plug-in files to exclude the secondary nodes. Note that some session loss is expected during this action.
3. Once the switch is complete, stop Portal on the secondary nodes.
7.6 Cluster A Secondary Node Portal migration stepsNOTE: Consult the job instructions in the EJPIBCM and EJPIMPRF files, generated in the CNTL dataset from section 6.3.3. This helps to ensure that all preliminary steps are completed and provides additional information about each z/OS JCL job that will be run.
1. Run EJPSCFGM, to prepare the WebSphere Portal sections of the file system for migration.
102
2. Confirm that the DMgr is started and the WebSphere Portal server is stopped on the secondary node of Cluster A.
3. Run EJPSMICE, to install the configuration engine into the WAS profile directory and perform the necessary localization.
4. Confirm that both DMgr and the CAN2 node agent are started.
5. Run EJPSDBC, to modify the database connection for migration, essentially connecting to the copied databases used for the primary node of the cluster. This is required for the secondary nodes to update the jdbc driver information for type 4 JDBC drivers.
6. From the DMgr, synchronize only CAN2 by selecting System Administration, and then CAN2 node. Click he Synchronize button.
7. Run the final migration job, EJPSMPRF, to upgrade the configuration data in the WebSphere Portal for z/OS profile.
8. Confirm the migration by rendering WebSphere Portal with the modified context root; complete the verification test and proceed to the next step.
7.7 Cluster B secondary node Portal migration stepsNOTE: Consult the job instructions in the EJPIBCM and EJPIMPRF files, generated in the CNTL dataset from section 6.3.3 Jobs shown in that section were created specifically for the secondary node of Cluster A. This helps to ensure that all preliminary steps are completed and provides additional information about each z/OS JCL job that will be run.
1. Run EJPSCFGM, to prepare the WebSphere Portal sections of the file system for migration.
2. Confirm that the DMgr is started and the WebSphere Portal server is stopped on the secondary node of Cluster B.
3. Run EJPSMICE, to install the configuration engine into the WAS profile directory and perform the necessary localization.
4. Confirm that both DMgr and CBN2 node agent are started.
5. Run EJPSDBC, to modify the database connection for migration, essentially connecting to the copied databases used for the primary node of the cluster. This is required for the secondary nodes to update the jdbc driver information for type 4 JDBC drivers.
6. From the DMgr, synchronize only CBN2 by selecting System Administration, and then CBN2 node. Click the Synchronize button.
7. Run the final migration job, EJPSMPRF, to upgrade the configuration data in the WebSphere Portal for z/OS profile.
8. Confirm the migration by rendering Portal with the modified context root; complete the verification test and proceed to the next step.
103
7.8 Completing the Portal migration steps1. Manually synchronize all nodes from the DMgr Admin Console.
2. Switch the Web server plug-in files to include all nodes; there should be no session failures for just adding new nodes.
3. Verify traffic successfully uses all nodes.
4. Re-enable “Automatic synchronization” and “Enable service at server startup on all node agents,” using System Administration – Node agents – nodeagent, from the DMgr Admin Console.
5. Stop the DMgr and all node agents (do NOT stop the daemons), restart the DMgr and all node agents, and then verify automatic synchronization is working again.
8 ConclusionWebSphere Portal 8 provides several new capabilities that you can exploit, including new social features, page and theme design, mobile updates, enhanced analytics support, and Web publishing enhancements. Refer to the Portal Post-migration activities section of the information center, to make the most of the new features.
Post-migration data update is another consideration after successfully migrating. This process allows you to update your target version's data with the latest data of the source, if the source was updated during migration. Essentially, a user connects to the source database, performs similar jobs outlined in this paper to migrate the database, and begins running with the new updated data.
It is recommended to upgrade the version of WebSphere Portal at the same time you upgrade the version of WAS on the system, since those levels experience the most co-verification during development of the products.
However, to minimize downtime and maintain 24x7 availability, it is necessary to support the migration of WAS while maintaining the same basic version of Portal. Due to the nature of the relationship between Portal and WAS, this means that the normal migration procedure for WAS must be interspersed with some toleration steps that update Portal as well.
This paper has provided the sequence of steps, along with sample commands and output, to make this transition a straightforward process for users.
Trial download: WebSphere Application Server V8:http://www.ibm.com/developerworks/downloads/ws/was/
Migrating IBM WebSphere Application Server on z/OS from v6.1 to v7.0 while keeping IBM WebSphere Portal Server at v6.1:http://www.ibm.com/developerworks/websphere/zones/portal/proddoc/migratingwaszos/
Migrating an IBM WebSphere Portal 6.1 database to WebSphere Portal 7.0 using the IBM DB2 Database Administration Tool V7.2 for z/OS:http://www.ibm.com/developerworks/websphere/zones/portal/proddoc/dw-w-portaldatmigration/
10 Author biographiesAdrian B Jordan currently works as a Staff Software Quality Engineer on the WebSphere Portal System Verification Test (SVT) team. He tests several areas of the product, focusing primarily on WebSphere Portal Server migration. Adrian has a B.Sc. degree in Computer Science from Alabama A&M University. You can reach him at [email protected].
Barry Pellas has been with IBM for twelve years, during which time he has worked on various parts of the WebSphere Portal Install, including Database Transfer, Configuration Framework, and Maintenance. He has a B.Sc. degree in Computer Engineering from The Pennsylvania State University. You can reach him at [email protected].
Trademarks• developerWorks, IBM, WebSphere, and z/OS are trademarks or registered trademarks of IBM
Corporation in the United States, other countries, or both.
• Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
• Other company, product, and service names may be trademarks or service marks of others.
