Preparing to convert

Before starting TOM and making it active for a group of newly converted CSM objects, you should disable CSM.

To disable CSM

Remove or comment out all CSM-related Rule sets in the RULESET parameter in AAOPRMxx, including:
- BMC AMI Ops Automation shipped Rule sets AAORULBC, AAORULBD, AAORULBE, and AAORULBG
- Rule sets defined by your site in setting up CSM. You can determine the CSM object name by looking at the contents of shared variable CSM.MVS.RULESET.
Remove or comment out the CSMREPDD, CSMREPDS, and CSMMDSPL variables from BBIVARxx.
Restart the BMC AMI Ops Automation PAS with the following parameters: START=COLD,VPOOL=RESET.
After migrating to TOM, you should clean up security resources that are no longer in use. After CSM is disabled, attempts to enter CSM from the BMC AMI Ops Automation Automation Menu will fail with the message CSM Inactive. At this point you can either delete resource names or modify authority within your External Security Manager (ESM) to deny access. The resources defined to your ESM are documented in the Managing security for BMC AMI Ops products.

To clean up after migration

Delete the commented out AAOPRMxx RULESET parameter.
Delete the commented out BBIVARxx CSM variables.
Delete the CSM PROFILE variables by using the AO REXX EXEC DELVARS command %DELVARS CSM* PROFILE in the AO Journal Log.
Remove any references to CSMALTDB from the AO PAS JCL.
Modify or delete EXEC IMFEOM. If you have modified this EXEC for your own automation, you should remove any modification to call, schedule, or select CSMEOM.
If CSM was active in the last start of the BMC AMI Ops Automation PAS, restart the PAS with the following parameters: START=COLD,VPOOL=RESET

To use test mode

The first time that you attempt to convert a CSM repository, use the conversion utility in TEST mode by specifying Convert Data Set?: TEST .
This specification allows the utility to attempt the conversion without creating TOM object definitions. Any exceptions that occur during the conversion process are written to the Conversion Log.
Review all information in the Conversion Log. This log provides information about CSM functions that were not converted for TOM and provides advice about how you can manually handle exceptions in conversion processing.

To define a valid system, Definition Base name, and initial control setting

For each CSM group that you want to convert, define settings for:

The name of a valid system on which to run each converted CSM group of objects
The name of a TOM Definition Base in which to store the newly converted objects
For CSM moveable objects, both the local and remote groups must be stored in the same Definition Base to maintain the object's original moving functionality
The initial control setting for the objects, either ACTIVE or SUSPEND.
If you select ACTIVE, the newly converted objects are started by TOM when the Definition Base is activated.

Important

Select SUSPEND for objects that are not active so that when the Definition Base is activated TOM does not bring them up automatically. You can manually ACTIVATE (un-suspend) each object.

To define the naming pattern

Define the default naming pattern. The conversion utility uses the following default naming pattern:

objectName.sysName

The values for the naming convention are:

objectName	Is the CSM name of the object
sysName	Is the name of the valid system on which the object will run

You can also use the node sysplex in the naming pattern, which resolves to the name of the sysplex in the converted object name. For example the following pattern resolves to the CSM object name as the first node and the sysplex name as the second node: objectName.sysplex.

The nodes for the object names can be entered in any order. For example the following configuration means that the valid system name appears before the CSM object name when the name nodes are resolved by the conversion: sysName.objectName