|
|
When creating resources, two approaches have proven to work:
Have definition files with the attributes for each resource in classes such as IBM.Application, IBM.ServiceIP. Those are referenced by a simple script that creates the resources using the RSCT mkrsrc -f command.
The advantages are that you learn how to create resources using RSCT commands and you will be able to change the script easily. You can mix and match definitions and scripts.
However, one of the chief drawbacks is that if you want to, for example, add a node, change the same NodeNameList parameter in each definition file.
Have a single configuration file that feeds a script to make the resources. The script must be sophisticated enough to assemble the mkrsrc command arguments from the configuration dynamically.
The advantage here is that you define variables in simple syntax only once in the configurations file, while the script interprets it and generates the various mkrsrc calls on the fly. However, you will not learn about the mkrsrc command and the attributes to make resources for other applications. The smart script is more difficult to understand and to change.
The recommendation is:
|
|
|
|
To benefit from both, we combine these approaches by providing a configuration file that can be tailored. Executing the cfg-script generates .def files and the corresponding script to make resources. If option -p is specified, the resources are created directly.
Note, that this is also useful in three other aspects:
| a. Studying the make script, you learn the commands to remove and generate automated resources. |
| b. If -p is not specified, then you can study the .def files to learn how the Tivoli System Automation definitions for the attributes look. That way, when you list resource attributes using Tivoli System Automation commands, you will be able to recognize the resources you created easily. |
| c. You can check what resources will be removed and created without really making them, and can read just the configuration and repeatedly run the configuration script until you are satisfied with the resources that will be created. |
Note that neither approach has direct support for removing resources selectively. A remove command must be used similar to what is generated in the make-script; this remove command must then be executed separately.
If the automation structure in terms of automated resources and their relationships will not change, use the configuration file approach.
