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

When you upgrade to HCL Z Asset Optimizer 9.1(Db2® database), there is porting of data within the Repository database. New Db2 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, or equivalent in-house backup job.

Make a backup or rename your JCLLIB and PARMLIB data sets.

Migration planning and consideration:

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.
If you have multiple 2.2 repositories sharing the same 2.2 GKB database, you need to phase the migration process.
- A 9.1 repository must use a 9.1 GKB.
- An 2.2 repository must use an 2.2 GKB.
  Note:
  HCL Z Asset Optimizer 9.1 code fails when accessing an 2.2 GKB database, due to newly defined 9.1 objects.
  For example, if you have 2.2 repositories REP1, REP2, REP3, and REP4 sharing the same 2.2 GKB, then migrate as follows:
  1. To migrate the first repository, REP1, in 9.1 customization job HZASCUST, create a new 9.1 GKB database. For example, GKB91:
    - Customize parameters DBGKB and GKBZSCHM with different names from those used in 2.2 GKB database. Repository parameter settings and values remain the same.
  2. Migrate REP1 and GKB database (GKB91) to 9.1 at the same time. Operational jobs for repository REP1 must now reference the 9.1 load library hza.SHZAMOD1.
  3. The remaining REPs continue to run at 2.2, with operational jobs still referencing the 2.2 load library hza.SHZAMOD1. These REPs continue to use the 2.2 GKB database (GKB22)
  4. Gradually migrate the remaining three repositories without creating another 9.1 GKB (GKB91).
  5. Once all REPs are migrated and are using the 9.1 GKB database (GKB91), the 2.2 GKB (GKB22) database can be dropped.
If each repository has its own GKB, then migrate the Repository database, GKB database, and hza.SHZAMOD1, to 9.1, all at the same time.
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, 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 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, 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.
Continue to run your 2.2 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 Db2 Repository in your HCL Z Asset Optimizer environment.

Procedure

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 DB2.
2. Set HZAINST to a different value to the one defined for the existing 2.2 system. This will ensure that the JCLLIB/PARMLIB datasets are created with different names. As stated in the section, “Before you begin”, 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 Repository database.
4. Set the value of the DB parameter to the same value that is defined for your existing 2.2 Repository database.
5. Set the value of the DBGKB parameter to the same value that is defined for your existing 2.2 Global Knowledge Base (GKB) database.
  
  Note:
  If you have multiple repositories sharing the same GKB database, you must use a different DBGKB name to create a new 9.1 GKB database. See Migration planning and consideration, step 3.
6. Add the value of the DBNOT parameter.
7. Set the value of the REPZSCHM parameter to the same value that is defined for your 2.2 Repository database.
8. Set the value of the GKBZSCHM parameter to the same value that is defined for your 2.2 GKB database.
  
  Note:
  If you have multiple repositories sharing the same GKB database, you must use a different GKBZSCHM name to create a new 9.1 GKB database. See Migration planning and consideration, step 3.
9. Add the value of the NOTFSCHM parameter.
10. Set values of the remaining Db2 parameters (e.g. DBSSID, LOC) to the same values that are defined for your 2.2 Repository database.
11. The default value for the BPIX parameter is set to BP8K0 and must be activated before usage. Compressed indexes require Bufferpools to be defined with BP8K0-BP8K9, BP16K0-BP16K9, or BP32K-BP32K9. It cannot be BP0-BP49.
Submit the HZASCUST job. DO NOT share members of JCLLIB/PARMLIB between 2.2 and 9.1. Some member names may be the same, but the contents differ.
Edit and update jobs in the JCLLIB library and parameters in the PARMLIB library if there are special site requirements.
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 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, 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, HZASMS35.
  A condition code of 0 is expected.
3. 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.
4. 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.
Backup 9.1
1. HZASUT01 – run the 9.1 job to backup all Repository, LKB and LKU UTS.
2. HZASUT04 – submit this job to run RUNSTATS for the 9.1 repository.
HZASDB02 – Submit this job to drop and create a new GKB database and its dependent objects.
- If you are creating a new 9.1 GKB database with different GKBDB/GKBZSCHM names, just submit the job. This creates a new 9.1 GKB database and its dependent objects. Use this approach if you have multiple 2.2 repositories sharing the same 2.2 GKB database. See Migration planning and consideration, step 3.
- If you are creating the 9.1 GKB database where the GKBDB/GKBZSCHM have identical names to 2.2, then uncomment step //*DROPGKB. This will drop the 2.2 GKB database and create a new 9.1 GKB database with the same GKBDB/GKBZSCHM names as 2.2.
- HCL Z Asset Optimizer 9.1 GKB has new database objects defined in the GKB database.
- Upon successful completion of the job, proceed to the next job.
- A condition code of 0 is expected.
Run the HZASDB04 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.
HZASGKBL – Submit this job to populate the newly created 9.1 GKB database.
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.
HZASGRTB – Optional. Submit this job to grant privileges to users that require SELECT access to newly created 9.1 tables.
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

After migration, use the following approach to manage the implementation to the latest version:

You must apply the latest GKB update. This will ensure that all product identifications are up to date when you run the Inquisitor Import job, HZASIQIM. For each repository, run HZASIQIM for all LPARs before you run any Usage Import (HZASUIMP) jobs . You can continue to use existing 2.2 Inquisitor fully-scanned files as inputs for the 9.1 HZASIQIM Inquisitor Import job.
Note:
Job HZASIQIM will fail if the GKB level used is older than 12 months.
For each repository, run the HZASIQIM job for every LPAR with setting of FULLREMATCH=Y. For performance reasons, exclude the Aggregator job step, except for the last HZASIQIM job. Please read the comments in the "Performance consideration" section of job HZASIQIM before you proceed.
For the last HZASIQIM job, update the Aggregator jobstep with COUNTUSAGEFULL=Y. For example:
```
////AGGR EXEC HZAJSQLE,PROG=HZACTLAG,TPARAM=HZASAGP1
    //USERPARM DD *
    COUNTUSAGEFULL=Y
```
Run the last HZASIQIM job with COUNTUSAGEFULL=Y for the Aggregator jobstep.
After running the last HZASIQIM job, in the Aggregator jobstep, set COUNTUSAGEFULL=N (the default setting).
Repeat steps 1 to 4 for the next repository.
Before you run any Usage Import job, HZASUIMP, you must run the Inquisitor Import job, HZASIQIM, for all LPARS (as described in step 1). Failure to complete running the Inquisitor Import job (HZASIQIM) for all LPARs before you start running Usage Import (HZASUIMP) could result in errors during the Aggregator jobstep due to the product identifications not being up-to-date.
1. For each repository, run the HZASUIMP job for every LPAR. For performance reasons, exclude the Aggregator jobstep, except for the last HZASUIMP job. Please read the comments in the "Performance consideration" section of job HZASUIMP before you proceed.
2. For the last HZASUIMP job, update the Aggregator jobstep with COUNTUSAGEFULL=Y. For example:
```
 ////AGGR EXEC HZAJSQLE,PROG=HZACTLAG,TPARAM=HZASAGP1
//USERPARM DD *
COUNTUSAGEFULL=Y
```
  Run the last HZASUIMP job with COUNTUSAGEFULL=Y for the Aggregator jobstep.
3. After running the last HZASUIMP job in the Aggregator jobstep, set COUNTUSAGEFULL=N (the default setting).
4. Repeat steps 6a through 6c for the next repository.
Configure APF authorization for the 9.1 hza.SHZAMOD1 load library.
You can run 9.1 operational jobs and discontinue 2.2 tasks once the 9.1 Inquisitor scans and Usage Monitors are ready for use.
1. Review the settings in the Inquisitor scan jobs, before submissions:
  HZASINQU – PACK=1 (default)
  HZASINQZ – PACK=1 (default)
2. Before starting HZASUMON, review parameters:
  PARMLIB member HZASMNPM – different parameters and default values.
3. HZASZCAT – different parameters and default values:
  Parameters 'JNM=Y,UID=Y,JAC=Y' are now the default.
4. HZASIQIM – parameter COUNTUSAGE = N is now the default.
5. HZASUIMP – parameter COUNTUSAGE = N is now the default.