Migrating a job manager profile and its registered set of servers

You can migrate a job manager profile and its registered set of servers from Version 7.0 or later to Version 9.0.

Before you begin

Supported configurations Supported configurations:

This article is about profile configuration migration. To migrate your applications to the latest version, use the WebSphere® Application Server Migration Toolkit. For more information, see the Migration Toolkit on WASdev.

sptcfg

Review the migration planning information at Knowledge Collection: Migration planning for WebSphere Application Server.

Tip: Rather than specifying individual parameters on migration commands, you can specify the -properties file_name.properties parameter to input a properties file. For more information, see Defining your migration through properties.

About this task

Job manager profiles can have one or more of the following server types registered:
  • Deployment manager servers
  • Managed base application servers (which are also registered to an administrative agent)
Avoid trouble Avoid trouble:
  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 Version 9.0 before you migrate managed base application servers and deployment manager servers to Version 9.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 Version 9.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.
gotcha

Procedure

  1. Install WebSphere Application Server, Network Deployment Version 9.0 onto the target host in a new directory.

    For more information, see the installation documentation.

  2. Create a Version 9.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:
    /QIBM/ProdData/WebSphere/AppServer/V9/ND/bin/manageprofiles -create -profileName 90JobMgr01 
    -profilePath /QIBM/ProdData/WebSphere/AppServer/V9/ND/profiles/90JobMgr01 
    -templatePath /QIBM/ProdData/WebSphere/AppServer/V9/ND/profileTemplates/management 
    -serverType JOB_MANAGER -nodeName JobMgrNode01 -cellName JobMgr01Cell01 -hostName myhost.company.com
  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 WebSphere Application Server 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 Version 7.0 or later installation root directory. For example:
      /QIBM/ProdData/WebSphere/AppServer/V9/ND/bin/WASPreUpgrade /mybackup/WAS70JobMgrbackup
      /QIBM/UserData/WebSphere/AppServer/V9/ND -oldProfile 70JobMgr01 
      -traceString *=all=enabled -tracefile /mybackup/logs/WASPreMigrationSummary.log
      For transitioning users For transitioning users: In versions prior to Version 9.0, the source instance or profile root directory was specified rather than the installation directory. In Version 9.0, specify the profile name on the -oldProfile parameter.trns
    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 Version 9.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 WebSphere Application Server install root bin directory to restore the previous job manager configuration that you saved in the migration backup directory.
    Avoid trouble Avoid trouble: To avoid database inconsistencies, run WASPostUpgrade immediately after WASPreUpgrade completes. As part of WASPreUpgrade, a backup of the database is created. If you 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.gotcha
    1. Run the WASPostUpgrade command to restore the saved job manager configuration into the new Version 9.0 administrative agent profile. For example:
      /QIBM/ProdData/WebSphere/AppServer/V9/ND/bin/WASPostUpgrade /mybackup/WAS70JobMgrbackup 
      -oldProfile 70JobMgr01 -profileName 90JobMgr01 
      -backupConfig TRUE -includeApps TRUE -keepDmgrEnabled FALSE 
      -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_name.timestamp.log
      • WASPostUpgrade.target_profile_name.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 Version 9.0.

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

  6. Start the Version 9.0 job manager and ensure that both Version 7.0 or later and Version 9.0 of the job manager are running.
    1. Change to the new Version 9.0 job manager profile bin directory.
    2. Run the startServer jobmgr command.
    3. Check the SystemOut.log file for warnings or errors.
      Note: This topic references one or more of the application server log files. As a recommended alternative, you can configure the server to use the High Performance Extensible Logging (HPEL) log and trace infrastructure instead of using SystemOut.log , SystemErr.log, trace.log, and activity.log files on distributed and IBM® i systems. You can also use HPEL in conjunction with your native z/OS® logging facilities. If you are using HPEL, you can access all of your log and trace information using the LogViewer command-line tool from your server profile bin directory. See the information about using HPEL to troubleshoot applications for more information on using HPEL.
  7. Migrate the registered servers.

    The Version 9.0 job manager can manage Version 7.0 or later registered servers. For the Version 7.0 or later topology to function with the Version 9.0 job manager, you are not required to migrate the registered servers.

    For each registered server that you plan to migrate to Version 9.0, perform the following steps:

Results

You migrated a job manager profile and its associated managed base application servers from WebSphere Application Server Version 7.0 or later to Version 9.0 using the migration tools.


Icon that indicates the type of topic Task topic



Timestamp icon Last updated: March 6, 2017 0:03
File name: tmig_migrate_job_mgr.html