1. Using Management Portal create a database for the VC/m application. We recommend naming it 'VCM'.

2. Create a namespace which uses that database. We recommend naming the namespace 'VCM'.

3. Mappings are required in order to place the VC/m globals (%vc*) and routines (%vc*) into the database created above. For host versions later than 2008.2 this can most conveniently be done using the %ALL pseudo-namespace. If you do not already have a %ALL namespace defined, create one. It is irrelevant which database the %ALL namespace points to, but CACHETEMP is suggested. Then attach the following mappings to %ALL, where they will be effective for all namespaces except DOCBOOK and SAMPLES. For more information about the %ALL namespace, search your InterSystems documentation for "Mapping a Package Across Multiple Namespaces" If you cannot use %ALL, contact VC/m Support for advice.

4. On %ALL map the %vc* globals, the %vc* routines to the database you created in Step 1. (This will override the default that % items are stored in CACHELIB.)

5. Also on %ALL map the VCmStudio package to the same database. On earlier Caché versions it is not possible to define a package mapping until at least one class exists in the package. In that case defer this step until after %vcins has been run.

1. Create a GT.M database file (mumps.dat) for VC/m in the installation directory. It should have a minimum record size of 512 and a key size of 255. It is also recommended that the mumps.dat file name be specified explicitly with a full path specification rather than a relative path.

Note: Do not use "./mumps.dat" or "mumps.dat" as this causes problems when extended global references are used.

The following is an example of how to use gde and mupip to create a suitable database:

2. If you want all users to have access to the VC/m terminal interface from any directory, add the VC/m directory "/usr/vcm" to the gtmroutines environment variable for all users.

3. Add a mapping to each mumps.gld, directing access for ^%vc* globals to the VC/m database file.

4. If you plan to use VC/m to manage globals (or sub-trees of globals), you need to ensure that each mumps.gld which VC/m addresses is referencing the mumps.dat database files explicitly rather than using a relative path. This is because VC/m uses extended global references to manipulate globals, and in GT.M these do not operate correctly if the mumps.dat database files are not referenced using an explicit path. For example: