RC/Migrator: How do I get rid of old/unwanted RCM Strategies?
Article ID: 25489
Updated On:
Products
Issue/Introduction
How do I get rid of old RCM Strategies?
Environment
Release: R20
Component: RCC, RCM
Resolution
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.
Batch Solution
Refer to the RC/Migrator User Guide at this location.
Manage Strategy Services,
Note:
Use the RCMMAINT job in hlq.CDBAJCL to delete old strategies by date, creator, type, and subsystem from PTMG1_STRAT_0200 with their related rows in PTMG2_ALTER_0200 and PTMG8_OUTPUT_0401. RCMMAINT generates delete statements for the specific tables depending on the parameters specified. A report and DDL file are created. The report file contains information about the selected strategies. The DDL file contains delete statements, with optional synchpoints after each delete for Batch Processor processing.
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 image copies 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 PTDB database tables have appropriate DB2 security to protect them from unauthorised updates of this nature.
Online Solution
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 see and 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.
"ADMINID option (ADMINID)
Specify a new administrator ID to let users access or delete any set or strategy. USERID is the default."
This is done using the Edit Parmlib Member function on the main menu and selecting the MIGRATOR member.
"ADMINID option...............> USERID (Administrator user id)"
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).
Additional Information
Generally, removing old and unused strategies and running a REORG on the product tablespaces helps to improve the performance of the products. The 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.
"Use the RCMMAINT job in hlq.CDBAJCL to delete old strategies by date, creator, type, and subsystem from PTMG1_STRAT_0200 with their related rows in PTMG2_ALTER_0200 and PTMG8_OUTPUT_0401. RCMMAINT generates delete statements for the specific tables depending on the parameters specified. A report and DDL file are created. The report file contains information about the selected strategies. The DDL file contains delete statements, with optional synchpoints after each delete for Batch Processor processing.."
Feedback
