Migrating from a previous version of Output Manager

This migration process does not change your existing Output Manager database. The migration runs from a copy of your existing Output Manager database.

Migrating data to Output Manager V3R1 from a previous version of Output Manager involves two stages:
  1. Making a copy of your current Output Manager database.
  2. Converting the copy to the Output Manager V3R1 format.
This process ensures that your current Output Manager setup will remain untouched during the migration.
Note:

It is highly recommended to do a trial run of the migration before migrating over your production system. In a trial run, you do not capture output. Instead, you test that you can view and reprint output captured by the previous version of Output Manager. You can also use a trial to validate that the related functions are working with the new database, including catalog synchronization, RUNSTATS, backups, and the web server.

Before you begin:

Decide whether you are going to create the Output Manager V3R1 database in the same Db2® subsystem as your previous Output Manager database:
  • If your V3R1 database will be on the same subsystem as your previous version, you will need to use new plan names and a new database name.
  • If your V3R1 database will be on a different Db2 subsystem, you can use the same plan names and database name. However, to help distinguish between your existing installation and V3R1, it is recommended to use new names.

The Output Manager customization members provided in SBJTSAMP are used to perform the copy and the formatting. Each stage of the migration process requires its own set of SBJTSAMP members; be prepared to create a data set for each one.

The following members are used to create these libraries:
  • BJT@CPY2: This member copies specific members from the SBJTSAMP installation library to a new HLQ, making a second samplib.The members in this samplib are used to unload the data from the current database.
  • BJT@CPY3: This member copies specific members from the SBJTSAMP installation library to a new HLQ, making a third samplib. The members in this samplib are used to create the new database for V3R1.
  • BJT@CPYU: This member copies all members from the SBJTSAMP installation library to a fourth samplib. The members in this samplib are customized for production.
Note: At the end of the migration process, follow the procedures in the Security chapter.

Performing a trial run of the migration

When doing a trial run, you complete some or all of the migration steps without impacting your existing installation. The key point of a trial is go through the migration steps without using the new installation to capture sysouts that are expected to be captured by your previous version that is still running.

In V3R1 you can test many of the functions available from the ISPF panels without running a started task. For testing during a trial run, you can bring up the started task with all selectors inactive by removing the "POLICY ACTIVATE" statement near the end of the V3R1 BJT#IN03 member. As a further safeguard while you are validating the V3R1 setup, you can use the admin panels to disable each selector.

You can also test the viewing and printing of reports from the V3R1 ISPF panels. If you have bundles configured, you can test bundle reprint for bundles that were already printed by your original Output Manager started task.

You can repeat each step of the migration. Once the copies of SBJTSAMP have been customized, there is no need to rebuild them. You repeat the migration by submitting the jobs that copy and rebuild the database, and submitting BJTCNPVM to load the configuration table.

When you are ready to switch production to V3R1, shutdown the original Output Manager started task. Run each migration job as described earlier in this chapter, starting with BJT@JCUO to unload the original database.