IBM Tivoli Software IBM Tivoli Software

[ Bottom of Page | Previous Page | Next Page | Contents ]


Catalog manager

V2.1 contains a new catalog manager. The most important difference is that it now acts directly on the master catalog, so there is no need for the importing and exporting activities performed in V1.1.1. You still import a new IBM catalog from time-to-time, but any changes you make to products using the catalog manager are saved directly into the administration server database.

The catalog itself has also changed quite significantly. The details are as follows:

New hierarchical tree structure:
In the V1.1.1 catalog a product's version and release identified a single licensable entity, for which an entry existed in the COMPONENT table. For example, consider the following product in version 1.1.1:
Table 4. Lotus Notes, version 3.5 in V1.1.1
Product name Version
Lotus(R) Notes(R) 3.5
In V2.1 a separate entry is made in the catalog for each product, version and release, and a license can be assigned to any of these. The migration examines the version field in the V1.1.1 COMPONENT table, and creates a hierarchical structure of product, version and release in the V2.1 COMPONENT table.

The migration behaves differently, depending on whether product in the V1.1.1 COMPONENT table has a version field that is in a valid format for V1.1.1:

Version field valid
If the product has a version field that is already in the format "n.n" or "n.n.*", the tool is able to create the full hierarchy.

Thus, for example, for the above entry for Lotus Notes, version 3.5 it would create the following entries in the V2.1 COMPONENT table:

Table 5. Lotus Notes, version 3.5 in V2.1
Product Version Tree level
Lotus Notes * 1
Lotus Notes 3.* 2
Lotus Notes 3.5.* 3

Where, the Tree level value has the following meaning:

1
Product
2
Version
3
Release

In this example, a license specifically assigned to Lotus Notes, version 3.5 would be assigned to the release entity.

Note:
In the case of custom products (products that are not in the IBM catalog), the version field
Version field not valid
If the version field is not in the format "n.n" or "n.n.*", the migration tool cannot create a correct structure. Instead, it creates a matching release entry, and extrapolates the product and version entries. For example, there could be an entry for Lotus Notes, version Beta 3.5 in the V1.1.1 catalog, as follows:
Table 6. Lotus Notes, version Beta 3.5 in V1.1.1
Product Version
Lotus Notes Beta 3.5
The migration would create the following entries:
Table 7. Lotus Notes, version 3.5 Beta in V2.1
Product Version Tree level
Lotus Notes * 1
Lotus Notes Beta 3.5.* 2
Lotus Notes Beta 3.5 3

There are some additional rules:

Any other changes that you may observe will come from the IBM catalog that you have imported, where the version field may have been changed by IBM into the valid structure.

The following are some examples:

Table 8. Product conversion examples
Version 1.1 Version 2.1 Notes
Product Version Product Version Tree level
$tock Exchange 32 2.0 $tock Exchange 32 * 1 This is a product in the IBM catalog with a valid version.
$tock Exchange 32 2 2
$tock Exchange 32 2.0.* 3
IBM DB2 UDB Enterprise Edition for HP 7.2.5 IBM DB2 UDB Enterprise Edition for HP * 1 This is a product in the IBM catalog with a valid version.
IBM DB2 UDB Enterprise Edition for HP 7.* 2
IBM DB2 UDB Enterprise Edition for HP 7.2.* 3
123-Talk
1.2
2.0
123-Talk * 1 This is a product in the IBM catalog with 2 valid versions.
123-Talk 1.* 2
123-Talk 2.* 2
123-Talk 1.2.* 3
123-Talk 2.0.* 3
Accounting B.10.10 Accounting * 1 This is a product that has had its version number changed when the new IBM catalog was imported. The new version number is "10.1.*", and so is in a valid format, even though the old catalog entry had a non-valid format.
Accounting 10.* 2
Accounting 10.1.* 3
- - Microsoft Windows Notepad * 1 This is a product generated by the migration because another product had a module associated with it that the migration recognized as belonging to a product in the IBM catalog.
Microsoft Windows Notepad 4.* 2
Microsoft Windows Notepad 4.0.* 3
myApplication1 1.1 myApplication1 * 1 This is a custom product with a valid version number.
myApplication1 1.* 2
myApplication1 1.1 3
myApplication2 B 1.1 myApplication2 * 1 This is a custom product with a non-valid version number.
myApplication2 B 1.1.* 2
myApplication2 B 1.1 3
myApplication3
1.2.1
1.2.3
1.2.4B
myApplication3 * 1 This is a custom product with 2 versions in valid formats and one version in a non-valid format.
myApplication3 1.* 2
myApplication3 1.2.4B.* 2
myApplication3 1.2.1 3
myApplication3 1.2.3 3
myApplication3 1.2.4B 3
To do, before the migration
You are strongly advised to use the V1.1.1 catalog manager before starting the migration to clean up the version fields of custom products, so that the migration tool will make a good match. If you leave the cleanup until after the migration, the task will be more complicated, as you may have to change all the entries in a product's hierarchy in order to get the correct structure. In particular, you should avoid having custom entries with the format "n.n.*", (the asterisk in this case is a literal value) which the tool cannot convert into the correct structure.
Note:
If, after the migration, you use the catalog manager of V2.1 to access a non-standard entry like the one for Lotus Notes, version Beta 3.5 , a message is displayed reminding you that the version field is not in the correct format.
Collapsing IBM catalog entries:
During the migration, the converter needs to deal with any entries it finds that have the same product name, version, release and modification level (for example, "3.7.1" and "3.7.2"), which is a structure not allowed in V2.1. The convertor collapses the entries into a generic entry, for example "3.7.*". All modules, licenses, and other properties of both original products are moved from the old entry into the one new entry, whereas the license entitlement details are merged.

When IBM catalog entries are merged, if the entitlement settings are the same, the merged entry will have that value. However, if the entitlement settings on the different merged products are not the same, the following decisions are made:

Conflicting entitlement settings Values in V1.1.1 Value given to merged entries in V2.1
Software Monitoring If all values are No No
If at least one value is Yes Yes
License control If all values are User-defined User-defined
If at least one value is Default Default
Run offline If all values are No No
If at least one value is Yes Yes
Server response If all values are Required Required
If at least one value is Not required Not required

Similar sets of non-IBM catalog entries are not collapsed. They are migrated to the new catalog just as they are, because each entry may have a different license or be associated with different modules, that cannot be merged.


[ Top of Page | Previous Page | Next Page | Contents ]