This chapter presents procedures for rendering a VOB or view temporarily inaccessible to all client processes. ClearCase's central storage registry makes this easy.
In some situations, you may not need to make the data totally inaccessible. For example, if you merely wish to prevent a VOB from being modified, you can lock it with having to take it “off-line”:
% cleartool lock -vob pathname |
To lock an entire VOB, you must be either root or the VOB owner. The pathname you specify can be either the VOB storage directory or the VOB-tag (mount point), or any pathname under the VOB-tag. In the latter case, you must enter the command in a view context.
Suppose that the VOB to be taken out of service has storage directory /net/sol/vobstore/libpub.vbs, and has VOB-tag /proj/libpub. Follow these steps to make the VOB inaccessible:
Have all clients deactivate the VOB—On each client, this command unmounts the VOB:
% cleartool umount /proj/libpub |
(ClearCase Release 1 client hosts must use the system-level umount(1M) command.)
Remove the VOB from the object registry—This will prevent anyone from reactivating the VOB:
% cleartool unregister -vob /net/sol/vobstore/libpub.vbs |
(optional) Remove the VOB from the tag registry—If you leave the VOB-tag for this VOB in the tags registry, attempts to mount the VOB will produce an unattractive message:
% cleartool mount /proj/libpub cleartool: Error: An error occurred mounting. Refer to the log file "/usr/adm/atria/log/mntrpc_server_log" for more information on the warning or failure. |
This message may be tolerable—even desirable. But if you would prefer a less verbose message, remove the VOB-tag:
% cleartool rmtag -all -vob /proj/libpub % cleartool mount /proj/libpub cleartool: Error: /proj/libpub is not a registered vob tag. |
(The -all option ensures correctness in a network with multiple regions—the VOB-tag is removed from all the logically-distinct tags registries.)
If the VOB has ClearCase Release 1 clients, rename the VOB storage directory—Release 1 clients do not use the object registry to determine the location of the VOB storage directory. Step #2 does not “hide” the VOB from such clients, so you must move its storage directory aside. For example:
% rlogin sol -l root Password: <enter password> % mv /vobstore/libpub.vbs /vobstore/libpub.vbs.NOACCESS % exit |
Terminate the VOB's server processes—Search the process table of the VOB host for the ClearCase vob_server and vobrpc_server processes that manage that VOB. Use ps -ax or ps -ef, and search for “/vobstore/libpub.vbs”; use kill(1) to terminate any such processes. (Only the root user can kill a vobrpc_server process.)
When the VOB is to be restored to service, follow these steps:
(if necessary) Rename the VOB storage directory—If you moved the VOB storage directory aside in Step #4 above, move it back:
% rlogin sol -l root Password: <enter password> % mv /vobstore/libpub.vbs.NOACCESS /vobstore/libpub.vbs % exit |
Restore the VOB to the object registry.
% cleartool register -vob /net/sol/vobstore/libpub.vbs |
(if necessary) Restore the VOB to the tag registry—This is necessary only if you removed the VOB-tag in Step #3 above:
% cleartool mktag -vob -tag /proj/libpub \ /net/sol/vobstore/libpub.vbs |
(Repeat, as necessary, for other network regions.)
Have clients reactivate the VOB—On each client host, this command mounts the VOB:
% cleartool mount /proj/libpub |
(ClearCase Release 1 client hosts must use the system-level mount(1M) command.)
The procedure for taking a view out of service temporarily is essentially equivalent to the VOB procedure described in “Taking a VOB Out of Service”. The salient differences are:
There is no specific “unmount” command for views. In particular, there is no command that removes a view-tag from a client hosts' viewroot directory.
The only view-related server process to be terminated is the view_server, which runs on the host where the view storage directory resides.
The procedure for restoring a view to service is essentially similar to that described in “Restoring the VOB to Service”.