Running BMC AMI LOBMaster

When running BMC AMI Reorg with a BMC AMI LOBMaster license, you can specify the AUX keyword to reorganize the base table space and associated LOB auxiliary table spaces concurrently.

Running BMC AMI Reorg on the base table space with the AUX keyword causes BMC AMI LOBMaster to perform the following actions:

• Perform all LOB checking.
• Correct all errors (where possible).

General LOBMaster considerations

The following general considerations apply to using BMC AMI Reorg with BMC AMI LOBMaster:

• Reorganizations of LOB data with base table spaces is not limited to universal table spaces (UTS). You can also use BMC AMI Reorg with BMC AMI LOBMaster when reorganizing base table spaces that are defined as classic partitioned or single-table segmented table spaces.
• You can use the BMC AMI Reorg REPORTONLY keyword with BMC AMI LOBMaster to produce LOB reports in the LOBREPRT DD output. These reports describe the distribution of LOBs by size and report the number of pages that the reorganization will save. Using the REPORTONLY keyword reads the table spaces without performing the reorganization.

For information about BMC AMI Reorg syntax when reorganizing LOB data, see REORG TABLESPACE.

Discarding data

When you discard data from a base table space during a reorganization, BMC AMI LOBMaster discards the LOB data along with the base row.

To use discard or SYSPUNCH data sets, you must dynamically allocate them. To enable BMC AMI LOBMaster to dynamically allocate these data sets, you must either include the XULDDYNM-unload-data-set-and-discards-automation-control-point in your NGTAUTO DD data set or specify the OUTPUT command. For more information about the OUTPUT command, see OUTPUT-statement-and-dynamic-allocation-of-output-data-sets.

For increased parallel processing, BMC AMI LOBMaster allocates a separate data set for each partition. Data sets are allocated only for partitions that contain rows that will be discarded.

If you choose to save discarded LOB data, BMC AMI LOBMaster writes the discarded data to the unload file, along with the base table data. The discarded data is written in spanned-record format, suitable to use with a load utility.

Detecting and controlling errors

When running BMC AMI Reorg with  BMC AMI LOBMaster:

• Performs all LOB checking
• Corrects errors where possible
• Discards base table space rows or LOBs that are in error

This processing simplifies LOB maintenance. Note the following considerations:

• Processing occurs in RW mode.
• BMC AMI LOBMaster does not require FLASHCOPY.
• BMC AMI LOBMaster does not invoke a sort routine.
• Non-correctible errors cause the reorganization to fail before performing rename processing.

BMC AMI LOBMaster classifies LOB errors into the following categories:

• LOB errors
• Missing LOBs
• Orphaned LOBs

The following sections provide additional information about these errors.

LOB errors

LOB errors include the following:

• A LOB is incomplete.
• A LOB data page is empty.
• The list of pages that are supposed to contain the LOB data is inconsistent.
• Multiple LOBs reference one or more of the pages that contain the LOB data.
• A LOB map page (that is, the first page of a LOB and the page referenced by the LOB index) is not marked as a map page or is inconsistent.

BMC AMI LOBMaster detects these errors when scanning the LOB table space and checks that:

• Only one different LOB references each data page
• All data pages are accounted for
• The accumulated size of all data pages for each LOB equals the total size of the LOB, as specified in the first map page

You can control how BMC AMI Reorg handles these errors by using the +LOBERRORS parameter.

Missing LOBs

BMC AMI LOBMaster detects a missing LOB in the LOB table space, based on information in the base table space or the LOB index. You can control how BMC AMI Reorg handles missing LOBs by using the +LOBMISSING parameter. For more information about this parameter and how each option affects the type of missing LOB, see LOBMISSING-action-message.

Orphaned LOBs

BMC AMI LOBMaster considers a LOB orphaned when it exists and is complete on the LOB table space but is not referenced by a row on the base table space. BMC AMI LOBMaster detects orphaned LOBs at the end of the read phase for the base table space.

You can control how BMC AMI Reorg handles orphaned LOBs by using the +LOBORPHANS parameter.