Setting up utility jobs could become a challenge for a large number of objects and a large number of DB2 subsystems. Automation allows you to generate the utility jobs in a uniform error free way. It is important to refresh the statements for newly created objects or when objects are dropped. Utility statements might also need to be refreshed when you want to deploy a change in one of the utility options.
Limitations of LISTDEF
The DB2 LISTDEF utility statement allows including objects using generic notations. DB2 identifies automatically at run time all the currently created objects that match the include notations. In addition, the DB2 TEMPLATE utility statement allows dynamic allocation of datasets using symbols that are resolved at run time based on the currently processed object. This makes it easy to set backup jobs for each database and removes the need to refresh the utility statements if objects in the database are created or dropped. However, this means that all the included objects are processed with the same utility options.
Different flavors of LISTDEF statements might be required for different utilities. You either want to include all tablespaces or all indexes, process at object level or at partition level, include auxiliary objects or dependent objects.
Some utilities do not allow you to use LISTDEF, so if you need to REPAIR, CHECK or LOAD tables, you still need to explicitly specify the object names.
The DB2 utilities are provided by various utility vendors: IBM, BMC, CA or CDB. It might be desired to easily move from one vendor to another or use multiple vendors in co-existence. The differences in functionality and in price between the different utility packages can be significant. Many shops choose to move from one vendor to another to cut the cost of licensing. This type of transition may affect the stability of your maintenance procedures.