Migrating an administrative agent profile and its registered set of managed base application servers on z/OS

Administrative agent profiles manage multiple base application servers in environments such as development, unit test, or that portion of a server farm that resides on a single machine. Before you can migrate managed base application servers from Version 7.0 or later to Version 8.5, you must first migrate the administrative agent.

1. Back up the administrative agent and node configuration
   In case of failure during the migration, run the backupConfig command to save the current administrative agent and node configuration to a file that you can use later for recovery purposes.
   1. Change to the administrative_agent_profile_root/bin directory.
   2. Run the backupConfig command with the appropriate parameters on the administrative agent and all managed base application servers.
      For example:

      /opt/WebSphereV61/profiles/v61dmgr01/bin/backupConfig.sh 
      /mybackupdir/v61dmgr01backupBeforeV7migration.zip 
      -username myuser -password mypass -nostop

   3. For each node in the configuration, change to the profile_root/bin directory.
   4. Run the backupConfig command with the appropriate parameters, and save the current profile configuration to a file.
      For example:

      /opt/WebSphereV70/profiles/v70mas01/bin/backupConfig.sh 
      /mybackupdir/v70mas01rbackupBeforeV85migration.zip 
      -username myuser -password mypass -nostop

   5. Alternately, you can use the PAX command to back up all HFS files. For more information, see Using the z/OS UNIX pax command
2. Install WebSphere Application Server Version 8.5
   1. Install the correct version (Network Deployment, Base, Express) of WebSphere Application Server onto each target host using the SMP/E tool. For more information, see the documentation about installing an application-serving environment.
3. Specify an administrative agent migration configuration in the z/OS Migration Management Tool
   Use the z/OS Migration Management Tool to create a migration definition and upload the jobs for migrating the administrative agent.
   Note: The Version 8.5 cell name must match the cell name in the Version 7.0 or later configuration. If you create a profile with a new cell name, then the migration will fail.
   1. Complete the worksheet found in the following topic:
      Specifying a deployment manager migration configuration in the z/OS Migration Management Tool: Worksheet
   2. On the Migration Node Type Selection panel, select z/OS migrate a administrative agent.
   3. Complete the fields on the subsequent panels using the values from your worksheet.
   4. Review the administrative agent migration definition to make sure that all the values are correct.
      • In the WebSphere Application Server for z/OS migration definition table, select the migration definition that you want to review.
      • Click View.
      • For information about the migration definition, click the Summary, Instructions, or Response file tab.
   5. Upload the migration jobs to the target z/OS system.
4. Ensure that all in-progress jobs are completed on the managed profiles
   1. Ensure that all in-progress jobs are completed on the managed profiles.
      Before you run the WASPreUpgrade command on a managed application server or deployment manager, all in-progress jobs must be complete.
5. Stop polling the job manager
   1. Stop polling the job manager before you run the WASPreUpgrade command on profiles that receive jobs from the job manager.
      Before you start polling for jobs, run the WASPreUpgrade and WASPostUpgrade commands for the managed profile. For more information, see ManagedNodeAgent command group for the AdminTask object using wsadmin scripting.
6. Run the migration jobs for the administrative agent
   1. Follow the instructions in the 'Migration Instructions' view of the z/OS Migration Management Tool or in the BBOMAINS member of the CNTL dataset that you uploaded to the target z/OS system.
      The CRPROF (profile create), PREUPGRD (preUpgrade) and UPGRADE steps are all executed during this process.
7. Verify the migration output that is generated
   1. Verify all output created in the working directory of the HFS/ZFS (specified in ZMMT) and all MVS job output created by the batch jobs.
      Verify that you are getting return codes of 0, and review the log files in the migration temp directory on the configuration file system. The migration temporary directory is temporary_directory_location/nnnnn, where temporary_directory_location is the directory specified for the temporary directory location and nnnnn is the numeric value generated for the migration identifier when you generated your migration jobs. The default temporary directory location is /tmp/migrate.
8. Add STEPLIB statements that include the previous version's load modules to the migrated Daemon's startup proc
   1. If you are running in a mixed-cell environment, add STEPLIB statements that include the previous version's load modules to the migrated Daemon's startup proc
      STEPLIB statements apply to WebSphere Application Server Version 6.1 and earlier. If you are running with multiple nodes on the same LPAR, or if you are running with a node on the same LPAR as the migrated DMGR (which will create a mixed cell environment), you must add STEPLIB statements that include the previous version's load modules to the migrated Daemon's startup proc. This is due to the fact that the Daemon must run at the highest WAS level on that LPAR. This is necessary if for any reason you need to stop and restart the down level node agent or application server. For example, after migration of the DMGR, the BBO7DMN procedure was modified to include:

      //*                                           
      //STEPLIB  DD DISP=SHR,DSN=xxxxxxxx.SBBOLD2   
      //         DD DISP=SHR,DSN=xxxxxxxx.SBBOLOAD  
      //         DD DISP=SHR,DSN=xxxxxxxx.SBBOLPA

      Where xxxxxxxx are pointers to the previous WebSphere Application Server level. This enables the Daemon to manage the migrated DMGR and previous level node agents.
9. Specify a managed application migration configuration in the z/OS Migration Management Tool
   Use the z/OS Migration Management Tool to create a migration definition and upload the jobs for migrating the managed base application servers.
   Avoid trouble: The Version 8.5 cell name must match the cell name in the Version 7.0 or later configuration. If you create a profile with a new cell name, then the migration will fail.
   1. Complete the worksheet found in the following topic:
      Specifying a deployment manager migration configuration in the z/OS Migration Management Tool: Worksheet
   2. On the Migration Node Type Selection panel, select z/OS migrate a managed base application server.
   3. Complete the fields on the subsequent panels using the values from your worksheet.
   4. Review the federated node migration definition to make sure that all the values are correct.
      • In the WebSphere Application Server for z/OS migration definition table, select the migration definition that you want to review.
      • Click View.
      • For information about the migration definition, click the Summary, Instructions, or Response file tab.
   5. Upload the migration jobs to the target z/OS system.
10. Run the migration jobs for the managed base application server
    1. Run the migration jobs for the managed base application server.
       Avoid trouble:

       • Ensure that the Version 7.0 administrative agent is running. This allows the application server to be de-registered with the administrative agent.
       • If the managed application server is also registered to a job manager, you must unregister from the job manager before you run a managed application server migration. After the migration is complete, register to the administrative agent and job manager again.

       Follow the instructions in the Migration Instructions view of the z/OS Migration Management Tool or in the BBOMDINS member of the CNTL dataset that you uploaded to the target z/OS system. The CRPROF (profile create), PREUPGRD (preUpgrade) and UPGRADE steps are all executed during this process.
11. Verify all of the migration output that is generated
    1. Verify all output created in the working directory of the HFS (specified in ZMMT) and all MVS job output created by the batch jobs.
       Verify that you are getting return codes of 0, and review the log files in the migration temp directory on the configuration file system. The migration temporary directory is temporary_directory_location/nnnnn, where temporary_directory_location is the directory specified for the temporary directory location and nnnnn is the numeric value generated for the migration identifier when you generated your migration jobs. The default temporary directory location is /tmp/migrate.
12. Add STEPLIB statements that include the previous version's load modules to the migrated Daemon's startup proc
    1. If you are running a mixed-cell environment, add STEPLIB statements that include the previous version's load modules to the migrated Daemon's startup proc.
       STEPLIB statements apply to WebSphere Application Server Version 6.1 and earlier. If you are running with multiple nodes on the same LPAR, or if you are running with a node on the same LPAR as the migrated DMGR (which will create a mixed cell environment), you must add STEPLIB statements that include the previous version's load modules to the migrated Daemon's startup proc. This is due to the fact that the Daemon must run at the highest WebSphere Application Server level on that LPAR. This is necessary if for any reason you need to stop and restart the down level node agent or application server. For example, after migration of the DMGR, the BBO7DMN procedure was modified to include:

       //*                                            
       //STEPLIB  DD DISP=SHR,DSN=xxxxxxxx.SBBOLD2    
       //         DD DISP=SHR,DSN=xxxxxxxx.SBBOLOAD   
       //         DD DISP=SHR,DSN=xxxxxxxx.SBBOLPA

       Where xxxxxxxx are pointers to the previous WebSphere Application Server level. This enables the Daemon to manage the migrated DMGR and previous level node agents.
13. Change to the new Version 8.5 migrated administrative agent
    Avoid trouble: Be sure all the managed application server registered to the old administrative agent are migrated. These should have all been de-registered during their migration process.
    1. Stop the old Version 7.0 or later administrative agent.
    2. Start the new Version 8.5 administrative agent.
14. Start the managed application server
    Check the Node Agent logs for errors.
    1. Start each managed base application server.
    2. Register each managed application server with the new administrative agent.