Conversion exception messages
The following tables list exception messages that you might find in the Conversion Log after converting a CSM object repository to a TOM definition base.
Table 1. Group exception messages
General group exception messages | Additional explanation |
|---|---|
Enable Plex not converted. Specifying the same TOMPLEX in BBIPARM members MAMPLXxx can enable TOM to TOM communication. | When you receive this message, you can edit the BBIPARM member MAMPLXxx in the data set specified on the BBIPARM DD statement listed in the TOM PAS JCL. For example, in MAMPLXxx you can specify TOMPLEX named BMCTOM1 as TOMPLEX(BMCTOM1). |
Alert Queues not converted. TOM issues exception messages to the MainView Logger. These messages can be captured with JRNL Rule(s) and converted to Alerts. | The TOM application has no feature equivalent to the CSM Alert queues. As an alternative, you can create Rules in MainView AutoOPERATOR that are initiated by JRNL messages, where a Rule fires for various TOM exception messages and creates an Alert. |
Statistics data set not converted. Feature not available in TOM. | The TOM application has no feature equivalent to the CSM statistics data set. |
Command Prefix 'group_command_interface' not converted. | Replace CSM Command prefix usage with TOM console commands. |
Table 2 lists exception messages that are specific to object definition differences between CSM and TOM objects.
Table 2. Object exception messages
Objects exception messages | Additional explanation |
|---|---|
Object renamed to <new_object_name> according to the selected Pattern. | This message appears for each converted object and shows the new name of the object based on the object name pattern that you selected (see Accessing-the-conversion-utility). |
Object already exists. Renamed to <old_object_name>.1 | During the conversion, the utility discovered that more than one CSM object would result in having the same object name in the TOM definition base. Because in TOM you cannot have two objects with the same name, the utility appends a number to subsequent objects of the same name (for example: TSO.SYSB.1, TSO.SYSB.2, and so on). |
The Start (also for Stop/Cancel) command for this object contains CSM variable. CSM variables are not supported in TOM. Please update the object and replace all &CSM variables with shared variables. | You can replace the CSM variables with object attribute, status variables, or other shared variables. |
Cancel command converted to Stop Retry command. | The TOM application does not use the CANCEL command. The CSM CANCEL command can be replaced with the STOP RETRY command in TOM (the TOM STOP RETRY command is issued only if the STOP command fails). |
Start and Stop events converted to Startup and Shutdown validation Rules. The TOM validation Rules currently do not support JOB Type. | This informational message explains that the CSM events are now called validations in TOM. The CSM Rules that used the additional fields JOB type, Word in message, Operand and Text string are not supported in the STM events. |
Abnormal Termination events converted to Abnormal Termination validation Rules. The TOM validation Rules currently do not support JOB Type, Word in message, Operand and Text string. | This informational message explains that the CSM events are now called validations in TOM. The CSM Rules that used the additional fields JOB type, Word in message, Operand and Text string are not supported in the STM events. |
Rules not generated. Object will be considered active when it is detected that the address space exists. If Rules are desired update the object to include Startup and Shutdown validation. | This informational message explains that the Rules were not generated. |
This object has a Post Start EXEC. The EXEC has been converted, however TOM does not pass internally parameters to the EXEC. You may need to modify the EXEC logic. The available variables to the EXEC are as follows: TOM_OBJECT, TOM_OBJTYPE, TOM_SYSNAME and TOM_REQUEST. | See Where-variables-can-be-entered for information about using variables in EXECs that are associated with TOM objects. |
This object has a Post Stop EXEC. The EXEC has been converted, however TOM does not pass internally parameters to the EXEC. You may need to modify the EXEC logic. The available variables to the EXEC are as follows: TOM_OBJECT, TOM_OBJTYPE, TOM_SYSNAME and TOM_REQUEST. | See Where-variables-can-be-entered for information about using variables in EXECs that are associated with TOM objects. |
TSO SEND not converted. Feature not available in TOM. | The TOM application has no feature equivalent to the CSM TSO Send field. |
Contact not converted. Feature not available in TOM. | The TOM application has no feature equivalent to the CSM Contact field. |
Info not converted. Feature not available in TOM. | The TOM application has no feature equivalent to the CSM Info field. |
Multiple Calendar Schedules detected. TOM Calendar has different behavior than CSM. Please review object Schedules for correctness. | In certain cases, the CSM Schedules must be manually re-created for TOM. For information about how to create Calendar dependencies for TOM objects, see Entering-calendar-dependencies. |
This object has a parent, which is a Grouping object. TOM does not support Grouping objects therefore the Grouping object is replaced with its parent. | TOM does not use grouping objects as they are used in CSM. When the conversion process discovers a grouping object, it is not converted. However the new TOM object has a dependency on the object that was the parent of the CSM grouping object. |
This object has multiple servers: '<server_name>'. To achieve the same functionality in TOM update object '<server_name>'. Include the connect command: '<connect_command>' in a Post-start EXEC and the disconnect command: '<disconnect_command>' in a Pre-stop EXEC. | TOM supports one server per object. The object being converted has more than one server. The first client-server entry has been converted. To accommodate the other client-server entries, code the server connect and disconnect commands into Post-start and pre-stop EXECs and define these EXECs as part of the new TOM object definition. |
The Start/Stop/Cancel command for this object contains stem variables. The format was converted to the TOM stem variables format. | Stem variables used in the START, STOP, or CANCEL commands for the CSM object definitions were converted to TOM stem variables format. |
This object is eligible for Move to another CSM Group. Please update the Valid Systems for this object and include any MVS systems to which you want to move the object. | This message is informational. |
If you had objects that were defined in CSM with Generate Rules = NO and issued the ACM901I and ACM902I messages to indicate that the objects are UP or DOWN, in TOM you will need to write Rules to capture the messages and schedule EXECs to issue TOM API commands to set the status of these objects to ACTIVE or STOPPED. See DELETE-function.
In addition, if you used the CSMACT EXEC in CSM, you must replace the CSMACT EXEC with a new EXEC that issues the appropriate TOM API commands.
If you use the CSMACT EXEC in a Rule, consider replacing it with an appropriate TOM console command to improve performance.