Migrating from HCL Z Asset Optimizer 2.2 to HCL Z Asset Optimizer 9.1 (SQLite database)

When you upgrade to HCL Z Asset Optimizer 9.1(SQLite database), there is porting of data within the Repository database. New SQLite objects are defined in the Repository. The existing 2.2 GKB database is dropped and re-created with the same database name for 9.1.

Before you begin

Make a backup of your 2.2 Repository database by running job HZASUT01 from your 2.2 JCLLIB.

Make a backup or rename your JCLLIB and PARMLIB data sets. HCL Z Asset Optimizer 9.1 uses the same dataset names for JCLLIB and PARMLIB.

Migration planning and consideration:

  1. If your existing 2.2 Repository database (including LKB/LKU) and GKB use different schema names, then you need to modify the migration jobs to suit your site requirements.
  2. Each SQLite repository with its own GKB and also its own hza.SHZAMOD1 load library should all be migrated to 9.1 at the same time. An 9.1 hza.SHZAMOD1 load library cannot be used by an 2.2 repository.
  3. Housekeeping:

    Perform housekeeping on the 2.2 Repository database before you start your migration process. This reduces the time required to migrate all the data.
    1. HZASLDEL - If you have any obsolete LPARs in the repository, you should delete the obsolete LPARs by running job HZASLDEL.
    2. HZASPDEL - TMODULE is one of the largest tables containing modules of which a huge percentage are in-house programs. To delete obsolete modules (especially in-house programs), refer to job HZASPDEL. You need to define a date range for deletion, and a sample SQL statement is provided in the job to list date ranges. HZASPDEL deletes modules based on any load libraries that have been marked as deleted.
    3. HZASUDEL - TUSEMTD is the largest table. Performing housekeeping on this table should be part of best practices. To determine the status of this table, run the following SQL statement:
      SELECT FPERIOD, COUNT(*) FROM &RESPZSCHM.TUSEMTD GROUP BY FPERIOD ;

      Following, in the Usage Deletion job HZASUDEL, select the date range for deletion. Follow the instructions in the job. If you have not used deletion before, you should delete Usage records in increments. Do this for all LPARs. Then run the SQL statement again to check the number of outstanding records in TUSEMTD.

      A good guideline on the number of records to be retained is to run HZASUDEL monthly for all LPARs with a fixed set of parameter settings:

      KEEPDETAIL=3 (or 6)
      KEEPAGGR=12

      This will retain detailed Usage records for the current month and the previous 3 (or 6) months, and summarized records for the current month and the previous 12 months.

  4. Continue to run your Usage Monitor job/started task (HZASUMON/ HZAJMON), but stop the Analyzer, and do not run any 2.2 operational jobs during the migration.

About this task

Perform these migration tasks for every SQLite Repository in your HCL Z Asset Optimizerenvironment.

Procedure

  1. In 9.1, make a copy of the HZASCUST member in the hza.SHZASAMP data set and modify the following parameters:
    1. Set the value of the DBTYPE parameter to SQLITE.
    2. Set HZAINST to the same value as the one defined for the existing 2.2 system. As stated in the section, “Before you begin”, it is imperative that you either backup or rename copies of 2.2 JCLLIB/PARMLIB datasets.
    3. Set the value of the SYS parameter to the same system that is defined for your existing 2.2 Repository database.
    4. Set the value of the REPZSCHM parameter to the same value that is defined for your 2.2 Repository database.
    5. Set the value of the new GKBZSCHM parameter to the same value that is defined for your 2.2 GKB database
    6. Add the value of the NOTFSCHMparameter.
    7. Set the value of the SQLTZFS parameter to the same value that is defined for your 2.2 zFS linear VSAM data set
    8. Set the value of the SQLTPATH parameter to same value that is defined for your 2.2 path of the z/OS UNIX for Systems Services directory
  2. Submit the HZASCUST job. The JCLLIB/PARMLIB datasets created use the same names as those created in 2.2. The same dataset names for JCLLIB/PARMLIB must be used in 9.1 because of the relationships between the high level qualifier HZAINST parameter and the SQLTZFS/SQLTPATH parameters.
    1. SQLTZFS = '&HZAINST..&SYS..ZFS'
    2. SQLTPATH = '/u/tadz/&SQLTZFS'
  3. Edit and update jobs in the JCLLIB library and parameters in the PARMLIB library if there are special site requirements.
  4. Run the following migration jobs:
    1. HZASMS31 – Submit this job to display the meta data of the 2.2 Repository, LKB and LKU objects. Verify that the number of 2.2 database objects match the expected result. If the expected result does not match, DO NOT proceed to the next job, HZASMS32. Investigate the differences. Possible reasons are described in the comments section of the job. Upon successful completion of the job, proceed to the next job, HZASMS32.
      A condition code of 0 is expected.
    2. HZASMS32– Submit this job to update the Repository database, define new Db2 objects, add new columns, and modify existing columns. These are required for new functions in 9.1. Upon successful completion of the job, proceed to the next job, HZASMS33.
      A condition code of 0 is expected.
    3. HZASMS33 Submit this job to rename 2.2 tables to names suffixed with _OLD, create new tables, and copy data from the renamed tables to the newly created tables. Upon successful completion of the job, proceed to the next job, HZASMS34.
      A condition code of 0 is expected.
    4. HZASMS34 – Submit this job to drop the _OLD tables created in the previous job, HZASMS33. Upon successful completion of the job, proceed to the next job, HZASMS35.
      A condition code of 0 is expected.
    5. HZASMS35 – Submit this job to verify database objects implemented in the previous job, HZASMS32, have been applied successfully. Upon successful completion of the job, proceed to the next job, HZASMS31.
      A condition code of 0 is expected.
    6. HZASMS31– Resubmit this job to display the meta data of the newly migrated 9.1 Repository, LKB and LKU objects. Verify that the number of 9.1 database objects match the expected result.
      A condition code of 0 is expected.
  5. HZASDB02– Submit this job to drop and create a new GKB database and its dependent objects. Before submitting this job, uncomment step //*DROPGKB. This will drop the 2.2 GKB database and create a new 9.1 GKB database. HCL Z Asset Optimizer 9.1 GKB has new database objects defined in the GKB database.
    A condition code of 0 is expected.
  6. HZASDB04 - Run this job to create the Notifications database and database objects.
    • Upon successful completion of the job, proceed to the next job.
    • A condition code of 0 is expected.
  7. HZASGKBL – Run this job to populate the GKB database. Always use the latest GKB version which can be found in the latest GKB PTF
    A GKB level is shipped with this migration. To download the latest GKB level, see Updating the Global Knowledge Base.

    A condition code of 0 is expected.

  8. Backup 9.1
    1. HZASUT01 – run the 9.1 job to backup the SQLite database.
  9. Recovery
    1. If failures occur during the migration, and a recovery is required, run the 2.2 job HZASUT02, to recover using the backup copy created just before the start of migration.

What to do next

See section "What to do next" in topic "Migrating from 8.2 to 9.1.