+

Search Tips   |   Advanced Search

Migrate a job manager profile and its registered set of servers

We can migrate a job manager profile and its registered set of servers from v7.0 or later to v9.0.

Review the migration planning information at Knowledge Collection: Migration planning for WAS.

Tip: Rather than specifying individual parameters on migration commands, we can specify the -properties file_name.properties parameter to input a properties file. See Define our migration through properties.

Job manager profiles can have one or more of the following server types registered:

  1. Managed base application servers and deployment manager servers cannot accept jobs from a job manager that is of a previous version. To avoid problems, migrate your job manager profiles to v9.0 before migrating managed base application servers and deployment manager servers to v9.0.

  2. When migrating the managed base application server or managed deployment manager in a flexible management environment, the node names must be the same in v9.0 and previous releases.

  3. Ensure that your setting for the maximum number of open files is 10000 or greater. If the number of open files is too low, this can cause a variety of migration failures.


Tasks

  1. Install WAS ND v9.0 onto the target host in a new directory.

    See installation documentation.

  2. Create a v9.0 job manager profile that will be the target of the job manager migration.

    Run the manageprofiles command with the appropriate parameters to create a new job manager profile.

    For example: 
    C:\WebSphere\AppServer90\bin>manageprofiles.bat -create -profileName 90JobMgr01 
-profilePath C:\WebSphere\AppServer90\profiles\90JobMgr01 
-templatePath C:\WebSphere\AppServer90\profileTemplates\management 
-serverType JOB_MANAGER -nodeName JobMgr01Node01 -cellName JobMgr01Cell01 -hostName localhost

  3. Stop the old job manager. Any jobs that exist within the old job manager database are migrated as part of the migration.

  4. Save the current job manager configuration to the migration backup directory by running the WASPreUpgrade command from the new WAS install root bin directory.

    The WASPreUpgrade command does not make any changes to the old configuration.

    1. Run the WASPreUpgrade command, specifying the migration backup directory and the v7.0 or later installation root directory. For example: 
      C:\WebSphere\AppServer90\bin>WASPreUpgrade.bat C:\WAS70JobMgrbackup C:\WebSphere\AppServer70 -oldProfile 70JobMgr01 
-traceString *=all=enabled -tracefile C:\WAS70JobMgrbackup\logs\WASPreMigrationSummary.log

    2. Review warnings or errors in the console output and WASPreUpgrade logs. After the WASPreUpgrade command is complete, check the console output for Failed with errors or Completed with warnings messages. Then, check the following log files for any warnings or errors:

      • migration_backup_dir/logs/WASPreMigrationSummary.log
      • WASPreUpgrade.timestamp.log
      • WASPreUpgrade.trace

      If there are errors, fix the errors and run the WASPreUpgrade command again. Check whether the warnings affect any other migration or runtime activities on v9.0.

      If the command completed successfully, it is not necessary to check the logs for errors or warnings.

  5. Restore the previous job manager configuration Run the WASPostUpgrade command from the new WAS install root bin directory to restore the previous job manager configuration that you saved in the migration backup directory.

    To avoid database inconsistencies, run WASPostUpgrade immediately after WASPreUpgrade completes. As part of WASPreUpgrade, a backup of the database is created. If we restart the old job manager before running WASPostUpgrade, the database in the backup and the database in the old job manager will be out of sync.

    1. Run the WASPostUpgrade command to restore the saved job manager configuration into the new v9.0 administrative agent profile. For example: 
      C:\IBM\WebSphere\AppServer90\bin>WASPostUpgrade.bat C:\WAS70JobMgrbackup 
-oldProfile 70JobMgr01 -profileName 90JobMgr01 
-traceString *=all=enabled -tracefile C:\WAS70JobMgrbackup\logs\WASPostMigrationSummary.log 
-username myuser -password mypass

    2. Review warnings or errors in the console output and WASPostUpgrade logs. After the WASPostUpgrade command is complete, check the console output for Failed with errors or Completed with warnings messages. Then, check the following log files for any warnings or errors:

      • migration_backup_dir/logs/WASPostMigrationSummary.log
      • WASPostUpgrade.target_profile.timestamp.log
      • WASPostUpgrade.target_profile.trace

      If there are errors, fix the errors and run the WASPostUpgrade command again. Check whether the warnings affect any other migration or runtime activities on v9.0.

      If the command completed successfully, it is not necessary to check the logs for errors or warnings.

  6. Start the v9.0 job manager and ensure that both v7.0 or later and v9.0 of the job manager are running.

    1. Change to the new v9.0 job manager profile bin directory.

    2. Run the startServer jobmgr command.

    3. Check the SystemOut.log file for warnings or errors.

      IBM recommends using the High Performance Extensible Logging (HPEL) log and trace infrastructure . We view HPEL log and trace information using the logViewer .

  7. Migrate the registered servers.

    The v9.0 job manager can manage v7.0 or later registered servers. For the v7.0 or later topology to function with the v9.0 job manager, we are not required to migrate the registered servers.

    For each registered server that we plan to migrate to v9.0...

We migrated a job manager profile and its associated managed base application servers from WAS v7.0 or later to v9.0 using the migration tools.

  • Migrate an administrative agent profile and its registered set of managed base application servers
  • Migrate cells using the command-line tools
  • Troubleshoot migration
  • Migration Toolkit on WASdev.

  • WASPreUpgrade command
  • WASPostUpgrade command