When a new resource type is registered, its RTR file must be accessible on disk.
When a resource of the new type is created, all declared method path names and the monitor program for the new type must be on disk and be executable. The old method and monitor programs must remain in place as long as the resource is in use.
To determine the correct packaging to use, consider the following questions:
Does the RTR file change?
Does the default value or tunability of a property change?
Does the min or max value of a property change?
Does the upgrade add or delete properties?
Does the monitor code change?
Does the method code change?
Are the new methods, the monitor code, or both compatible with the previous versions?
The answers to these questions will help you determine the correct packaging to use for your new resource type.
You do not necessarily need to create new method or monitor code when you modify a resource type. For example, you might only change the default value or tunability of a resource property. In this instance, because you do not change the method code, you only require a new valid path name to a readable RTR file.
If you do not need to reregister the old resource type, the new RTR file can overwrite the previous version. Otherwise, place the new RTR file in a new path.
If the upgrade changes the default value or tunability of a property, use the Validate method for the new version of the resource type to verify that the existing property attributes are valid for the new resource type. If they are not, the cluster administrator can change the properties of an existing resource to the correct values. If the upgrade changes the min, max, or type attributes of a property, the clresourcetype(8CL) command automatically validates these constraints when the cluster administrator upgrades the resource type.
If the upgrade adds a new property or deletes an old property, you probably need to change callback methods or monitor code.
If you change only the method code in a resource type, you must determine whether the new method code is compatible with the old method code. The answer to this question determines whether the new method code must be stored in a new path or whether the old methods can be overwritten.
If you can apply the new Stop, Postnet_stop, and Fini methods (if declared) to resources that were initialized or started by the old versions of the Start, Prenet_stop, or Init methods, the old methods can be overwritten with the new methods.
If applying a new default value to a property causes a method such as Stop, Postnet_stop, or Fini to fail, the cluster administrator must accordingly restrict the state of the resource when the resource type is upgraded.
You enable the cluster administrator to restrict the state of the resource when it is upgraded by limiting the tunability of the Type_version property.
One approach to packaging is to include all earlier versions of a resource type that are still supported in the package. This approach permits the new version of a package to replace the old version of the package, without overwriting or deleting the old paths to the methods. You must decide the number of previous versions to support.
The following table summarizes the packaging schemes to use for your new resource types.