You can migrate a job manager profile and its registered
set of servers from Version 7.0 or later to Version 9.0.
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: - 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.
- 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.
- 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
- Install WebSphere Application Server, Network Deployment
Version 9.0 onto the target host in a new directory.
For more information, see the installation documentation.
- 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:
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
- Stop the old job manager. Any jobs that exist within the old job manager database are migrated as part of the
migration.
- 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.
- Run the WASPreUpgrade command, specifying the migration backup directory and
the Version 7.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
- 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.
- 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: 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
- Run the WASPostUpgrade command to restore the saved job manager
configuration into the new Version 9.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
- 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.
- 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.
- Change to the new Version 9.0 job manager profile
bin directory.
- Run the startServer jobmgr command.
- 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.
- 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.