It is important to understand that the alias name acts as a pointer only. The VTS-TSR defined characteristics are properties of the VTS-TSR, and not the alias. Moreover, the VTS-TSR properties are not inherited by the alias name, nor does a switch transfer properties from one VTS-TSR to another.
The following rules apply to aliases and alias names:
- An alias name must be unique—it cannot be the same as an existing VTS-TSR or another alias name.
- A new VTS-TSR name must also be unique—it too, cannot be the same as an existing VTS-TSR or another alias name.
- An alias name can be assigned to only one VTS-TSR at a time.
- A VTS-TSR can be assigned only one alias name at a time.
- Accessing a VTS-TSR via an alias will continue to be valid until the alias name association is changed, or until the VTS-TSR is shut down.
- If a VTS-TSR is to change from one alias association to another, two switches will be required: one switch to de-assign the first alias name association, and a second switch to apply the new alias association.
- Changing an alias from one VTS-TSR to another requires only a single switch.
- Switching an alias from one VTS-TSR to another requires that both VTS-TSRs be up and running.
- Though not expressly restricted, it is assumed that when an alias is switched from one VTS-TSR to another, the “new” VTS-TSR will be no smaller than the one currently referenced by the alias, and will have the same, or mostly the same, characteristics, tables, and run-time options.
- If a VTS-TSR has an associated alias name, all tableBASE accesses must be made using the alias name; attempts to use the original defined VTS-TSR name will fail.
- Alias names and VTS-TSR switching do not apply to R/W VTS-TSRs.
- If a SWITCH is performed because of a change in table attributes (Example, Adding or removing a column, change in column definition etc.), Application changes associated with the change, should be coordinated along with the SWITCH process.