Migrating QMF across different DB2 subsystems

This section describes how to migrate when both releases of QMF are in different DB2 subsystems.

When the DB2 subsystems are different, migration is complicated by the fact that QMF objects in the database for the earlier QMF release are not available to Version 7.2 users. Nor are these objects in the QMF Version 7.2 database available to users of the earlier QMF release.

The tables and views required by QMF must be made available in the new subsystem.

Providing a QMF profile

The installation process creates a new Q.PROFILES table when QMF Version 7.2 is in a different DB2 subsystem.

For QMF Version 3.1.1 users

There are no new columns in the Q.PROFILES table if you are migrating from Version 3.1.1.

For QMF Version 3.1 users

There are no new columns in the Q.PROFILES table if you are migrating from Version 3.1.

For QMF Version 2.4 users

The new Q.PROFILES table has an additional column, ENVIRONMENT.

For QMF version Version 2.2 and Version 2.3 users

The new Q.PROFILES table has two additional columns, MODEL and ENVIRONMENT.

For QMF Version 2.4, Version 2.3, or Version 2.2 users

The newly created table contains a single SYSTEM row. The values assigned to the columns appear in Table 103.

If CICS is installed, there is an additional SYSTEM row, in which SYNONYMS is set to null and ENVIRONMENT is set to CICS.

With only the SYSTEM row in the table, users begin their Version 7.2 sessions with the QMF profile provided by this row. This profile can differ from profiles on earlier QMF releases. You can recreate the earlier profiles with a series of INSERT queries, but users can also do this for themselves with SET or SAVE PROFILE.

Users cannot, however, change the values of the PFKEYS, SYNONYMS, and RESOURCE__GROUP parameters with SET or SAVE PROFILE. You must do this with an UPDATE query on the Q.PROFILES table. For an example of this, see Activating new function key definitions.

The PFKEYS, SYNONYMS, and RESOURCE__GROUP parameters play key roles in customizing the QMF environment. For a brief description of each, see Table 101.

Making objects from the earlier release available under QMF Version 7.2

DB2 tables and QMF objects can be exported from a subsystem under an earlier QMF release and then imported under QMF Version 7.2.

To migrate DB2 tables, any user with the proper DB2 authority can:

1. Unload the tables using a DB2-supplied application program, DSNTIAUL. For more on this program, see the DB2 UDB for OS390 Administration Guide.
2. Load the unloaded tables into the Version 7.2 DB2 subsystem using the DB2 loader. For details on using the loader see the DB2 UDB for OS390 Administration Guide

.

If you have DXT installed, you can also use DXT for unloading and loading tables. DXT is an IBM licensed program product. For more information on DXT, see the Data Extract: General Information manual.

If the two versions of QMF are on different OS/390 systems, use the available networking facilities to send the exported objects and unloaded tables to the system containing QMF Version 7.2.

To migrate QMF queries, forms, procedures, and applications, make sure you read the following section, Migrating QMF objects.

If you have QMF High Performance Option (HPO) installed, you can use the QMF HPO Object Manager for assistance with the migration of QMF objects from one DB2 subsystem to another.

For more information on Data Refresher or the QMF High Performance Option, see the web site at: http://www.ibm.com/software/data.

Views and synonyms

If you use QMF to export tables from a database and import them to a different database, you must create any views, indexes, synonyms, and authorizations on that table at the new database.