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

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

Before you begin

  1. If your existing version 1.1 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. The version 2.2 Usage Monitor job/started task (HZASUMON/HZAJMON) requires a minimum level of z/OS V2.3 or later. It will fail if run in z/OS V2.2 or earlier.

  3. Each SQLite repository with its own GKB and also its own HZA.SHSMOD1 load library should be migrated to version 2.2 all at the same time. A version 2.2 HZA.SHZAMOD1 load library cannot be used by a version 1.1 repository.

  4. Perform housekeeping on the version 1.1 Repository database before you start your migration process:
    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 biggest tables and it contains 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 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 &REPZSCHM.TUSEMTD
GROUP BY FPERIOD ;
      Next, in the Usage Deletion job HZASUDEL, select the date range for deletion. Follow the instructions in the job – if you have never deleted before, you should delete Usage records in increments. Do it for all LPARs. 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.
  5. Continue to run your version 1.1 Usage Monitor job/started task (HZASUMON/HZAJMON), but stop the Analyzer and do not run any version 1.1 operational jobs during the migration.

About this task

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

Procedure

  1. In HCL Z Asset Optimizer version 2.2, make a copy of the HZASCUST member in the HZA.SHZASAMP data set and modify the following parameters:
    1. Set the value of the new DBTYPE parameter to SQLITE.
    2. Set HZAINST to the same value to the one defined for the existing 1.1 system. As stated in the section, “Before you begin”, it is imperative that you either backup or rename copies of version 1.1 JCLLIB/ PARMLIB data sets.
    3. Set the value of the SYS parameter to the same system that is defined for your existing version 1.1 Repository database.
    4. Set the value of the REPZSCHM parameter to the same value that is defined for your version 1.1 Repository database.
    5. Set the value of the new GKBZSCHM parameter to the same value that is defined for your version 1.1 GKB database.
    6. Set the value of the SQLTZFS parameter to the same value that is defined for your version 1.1 zFS linear VSAM data set.
    7. Set the value of the SQLTPATH parameter to same value that is defined for your version 1.1 path of the USS directory.
  2. Submit the HZASCUST job. The JCLLIB/PARMLIB datasets created use the same names as created in version 1.1. The same dataset names for JCLLIB/PARMLIB must be used in version 2.2 because of the relationships between the high level qualifier HZAINST parameter and the SQLTZFS/SQLTPATH parameters. 
    1.  SQLTZFS = '&HZAINST..&SYS..ZFS'
 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. Submit the HZASCUST job. DO NOT share members of JCLLIB/PARMLIB between V1.1 and V2.2. Some member names may be the same, but the contents differ.
  5. Edit and update jobs in the JCLLIB library and parameters in the PARMLIB library if there are special site requirements.
  6. Run the following migration jobs:
    1. HZASMI01 - Submit the job to display the meta data of the version 1.1 Repository, LKB and LKU objects. Verify that the number of version 1.1 SQLite objects match the expected result. If the expected result does not match, DO NOT proceed to the next job, HZASMI02. Investigate why there are differences. Possible reasons are described in the comments section of the job. Upon successful completion of the job, proceed to the next job, HZASMI02.
      A condition code of 0 is expected.
    2. HZASMI02 – Submit the job to update the Repository database, define new Db2 objects, add new columns and modify existing columns. These are required for new functions in version 2.2. Upon successful completion of the job, proceed to the next job, HZASMI03.
      A condition code of 0 is expected.
    3. HZASMI03 – Submit the job to rename version 1.1 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, HZASMI04.
      A condition code of 0 is expected.
    4. HZASMI04 – Submit the job to drop the renamed version 1.1 tables suffixed with _OLD. Upon successful completion of the job, proceed to the next job, HZASMI05.
      A condition code of 0 is expected.
    5. HZASMI05 – Submit the job to populate data to the version 2.2 Repository database. Upon successful completion of the job, proceed to the next job, HZASMI01.
      A condition code of 0 is expected.
    6. HZASMI01 - Submit the job to display the meta data of the newly migrated version 2.2 Repository, LKB and LKU objects. Verify that the number of version 2.2 Db2 objects match the expected result.
      A condition code of 0 is expected.
    7. HZASGKBL – Submit the job to populate the newly created version 2.2 GKB database. A GKB level is shipped with this migration. To download the latest GKB level, see Updating the Global Knowledge Base.
      Note: Using a version 1.1 GKB level is not supported, as the table layouts are different.

      A condition code of 0 is expected.

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

What to do next

See What to do next in the "Migrating from version 1.1 to IBM Z Software Asset Management Version 2.2 (Db2 database)" topic .