startview
Starts or connects to the view_server process of a dynamic view or to the rview _agent of an automatic view
Applicability
Product |
Command type |
---|---|
VersionVault |
cleartool subcommand |
VersionVault Remote Client |
rcleartool subcommand |
Platform |
---|
UNIX® |
Linux® |
Windows® |
Synopsis
- startview view-tag [ ... ]
Description
Prerequisite: The dynamic or automatic view that is being started must already have a view tag in the network's view tag registry file. See the mkview and mktag reference pages.
The startview command enables processes on the local host to access a view, as follows:
- Establishes a connection between the local host's MVFS (VersionVault multiversion file system) and the dynamic view's view_server process or the automatic view's rview_agent.
- Creates a view tag entry in the local host's viewroot directory. If a view_server process or rview_agent is not already running, startview invokes one on the host where the view storage area physically resides.
On UNIX® and Linux®, the default name of the viewroot directory is /view for a dynamic view and /rview for an automatic view. (See the init_ccase reference page for more information.) On Windows®, it is drive M:\ for a dynamic view and R:\ for an automatic view.
Thus, starting a view that has been registered with view tag main creates the directory entry /view/main, /rview/main, M:\main, or R:\main. After this directory entry is created, any process on the local host can access the view through view-extended pathnames.
The view's view tag must already be registered, which is accomplished either at view creation time (with a mkview command) or subsequently (with mktag -view).
When to use startview
Both mkview and mktag invoke startview. Typically, startview is used to establish view-extended naming access. There are two main cases:
- Because mkview and mktag invoke startview on the local host only, remote users of a dynamic view who want only view-extended naming access must use startview.
- After your system has been stopped and restarted (see the Examples section), both local and remote users of a dynamic view can use startview to reestablish view-extended naming access.
Restrictions
None.
Options and arguments
Specifying the view
- Default
- None.
- view-tag ...
- One or more currently registered view tags (that is, view tags visible to lsview).
Examples
The UNIX system and Linux examples in this section are written for use in csh. If you use another shell, you may need to use different quoting and escaping conventions.
The Windows examples that include wildcards or quoting are written for use in cleartool interactive mode. If you use cleartool single-command mode, you may need to change the wildcards and quoting to make your command interpreter process the command appropriately.
In cleartool single-command mode, cmd-context represents the UNIX system and Linux shells or Windows command interpreter prompt, followed by the cleartool command. In cleartool interactive mode, cmd-context represents the interactive cleartool prompt.
- The dynamic view anne_Rel2 is
registered, but its view_server process went
down in a system crash. On a Windows® system,
restart anne_Rel2, and make it the working
directory view.
cmd-context startview anne_Rel2
C:\> M:
M:\> cd \anne_Rel2\vob_pr2 - Create a dynamic view on the local UNIX® or Linux® host, and establish view-extended
naming access to the view on host3.
cmd-context mkview -tag mainRel2 /view_store/mainRel2.vws
Created view.
Host-local path: host2:/view-store/mainRel2.vws
Global path: /net/host2/view-store/mainRel2.vws
It has the following rights:
User : anne : rwx
Group: dev :
% rsh host3 cleartool startview mainRel2On host3, enter the following command:
cmd-context startview mainRel2