1. Using Management Portal create a database for the Deltanji application. We recommend naming it 'DELTANJI'.

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

3. Mappings are required in order to place the Deltanji 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 support@georgejames.com 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 Deltanji 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 Deltanji terminal interface from any directory, add the Deltanji directory "/usr/deltanji" to the gtmroutines environment variable for all users.

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

4. If you plan to use Deltanji to manage globals (or sub-trees of globals), you need to ensure that each mumps.gld which Deltanji addresses is referencing the mumps.dat database files explicitly rather than using a relative path. This is because Deltanji 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: