Shared Table and Custom Hardware Dictionary migration


The following figure illustrates the differences between Shared Table or Custom Hardware Dictionary migration and Custom Huffman migration. Shared Tables and Custom Hardware Dictionaries are migrated independently from the segment registration records. When Custom Huffman segment registration records are migrated, the table record is migrated automatically.

Warning

Note

Custom Hardware Dictionary migration, which is not shown in the following figure, occurs in exactly the same manner as Shared Table.

GUID-4D19A26E-AB90-48FE-9FB6-C4132F20E9D9-low.png

After you build a Shared Table or Custom Hardware Dictionary and it is at RUN level, you can easily maintain the registration records that correspond to the Shared Table or Custom Hardware Dictionary through the migration process. You can build a current copy of the Shared Table or Custom Hardware Dictionary by running the Trial utility. When you run the Trial utility and specify an existing Shared Table or Custom Hardware Dictionary name, a more current table or dictionary is built for the data sampled. After the table or dictionary is rebuilt, you can promote and copy the table or dictionary record.

When you rebuild a Shared Table or Custom Hardware Dictionary during Trial utility execution, then promote the table or dictionary to RUN level, the table ID or dictionary ID for the rebuilt table or dictionary must be validated for uniqueness so that duplicate table IDs and duplicate dictionary IDs do not exist within the record set at the RUN level. You have to rebuild and promote only the Shared Table or Custom Hardware Dictionary; you do not have to promote or copy the registration records at the RUN or ARCHIVE level that refer to the Shared Table or Custom Hardware Dictionary. When you promote or copy a Shared Table or Custom Hardware Dictionary that has been rebuilt, all registration records at the RUN and ARCHIVE level that use the Shared Table or Custom Hardware Dictionary are updated automatically to reflect the appropriate table ID or dictionary ID.

In Shared Table rebuilt and promoted, Shared Table 1 (which has a table ID of 5C) is rebuilt during Trial utility execution, then promoted from STAGE to RUN level. When the table record is promoted, the table ID is changed from 5C to 2B because a table record already exists at the RUN level with a table ID of 5C. The RUN level record with table ID 5C is promoted to ARCHIVE level. The table IDs in the three segment registration records at RUN level that refer to the Shared Table are updated automatically to reflect the new table ID 2B. The segment registration records with table ID 5C are promoted to ARCHIVE.

Warning

Note

In the following figure, only the Shared Table is shown, although Custom Hardware Dictionary migration occurs in exactly the same manner.

The table records for Shared Tables and dictionary records for Custom Hardware Dictionaries are shared among many different segments. When these records are copied, the table ID or dictionary ID can be duplicated. Segments from multiple source DPICDSs can be copied to a single target data set. If these segments use the same Shared Table or Custom Hardware Dictionary, the table ID or dictionary ID can be duplicated. If you are copying from several test data sets to a production DPICDS, for example, and the segments use the same Shared Table or Custom Hardware Dictionary, the table ID or dictionary ID could be repeated in the production DPICDS. Data Packer issues an error message and does not allow the copy to take place if a duplicate table ID or dictionary ID is found in the target DPICDS.

Every Shared Table or Custom Hardware Dictionary registration record is examined to see whether the table ID for the table record or dictionary ID for the dictionary record being copied already exists. If duplicate IDs are found, you must run the Trial utility again to rebuild the table or dictionary. To avoid duplicate IDs when you are copying Shared Table or Custom Hardware Dictionary records, you should build all tables or dictionaries within a single DPICDS, and the migration source for the copy should always be the same DPICDS.

GUID-341E6A7E-233E-481E-AD62-12DB6CD1AB8A-low.png


 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*

BMC AMI Data Packer for IMS 3.1