How do I get rid of old RCM Strategies?
Old and unwanted strategies often begin to accumulate over time on many busy systems. These may impact the performance of RC/Migrator adversely. Many of these could belong to users who have left that workplace and so should be removed or in some other way dealt with. The strategies may have been protected with the SHARE OPTION by that user for security reasons and won't be visible to other regular users. An administrative task requiring special privileges is recommended to alleviate this problem periodically.
Refer to the RC/Migrator User Guide at this location.
Chapter 5: Strategy Services Facility, Sub-Section: Manage Strategies, Note: .
This section refers to a batch job in hlq.CDBASRC called RCMMAINT. This JCL is designed to generate SQL to delete unwanted strategies in bulk from table PTI.PTMG1_STRAT_0200 with their related rows in PTMG2_ALTER_0200 and PTMG8_OUTPUT_0401. Rows from table PTMGA_LNAME_0200 are also deleted since release R115SP0.
A report is provided which contains strategies that have been selected for deletion for review by the user before submitting the job. The SQL can then be executed if the user has appropriate DB2 authority to update these product tables. This section is worth reading as it contains other options for this process.
Caution: This operation should be treated as you would with any other maintenance operation and so proper imagecopies of the tablespaces belonging to the PTDB database should be current before this is done. Consultation with other users to ensure strategies may be deleted would avoid any problems. Make sure the above tables and the other CA PTDB tables have appropriate DB2 security to protect them from unauthorised updates of this nature.
To do this online your userid must be set as the ADMINID in the hlq.CDBAPARM member MIGRATOR. Once your userid is an ADMINID you will then be able to remove strategies created by other users one by one with the "D" line command and as such this method is not suited to large numbers of strategies. Note that the ADMINID is located within a specification block of options which is specific to ONE subsystem. If you are working with more than one subsystem you will need to add a block for each subsystem at the bottom of the MIGRATOR member and specify the ADMINID for each SSID ensuring that each SSID is still represented in the SETUPxx member.
This is sometimes useful if the creator of the strategy has left the organisation and a clean-up of those strategies is required or the new person replacing that person who left must take over using a new userid. Normally if these strategies have a Share Option of "N" they are not even visible unless your own userid has ADMIN privileges in hlq.CDBAPARM(MIGRATOR).
Generally, removing old and unused strategies and running a REORG the CA product tablespaces helps to improve the performance of the products. The CA products are applications like any other which access DB2. Smaller numbers of database records to sort through when looking for strategies will improve performance for all users.
That is the direct benefit of doing this cleanup work. Make sure that the hlq.CDBAPARM is itself protected from unauthorized changes as this function allows a user to get around the SHARE OPTION if they can get to the MIGRATOR member.
These strategies may not need to be removed merely made visible to other users by changing the SHARE OPTION. This would then allow these to be TEMPLATED or reused by others without the need to create them again.