1. Using Management Portal create a database for the Deltanji application. We recommend naming it 'DELTANJI', and creating a new security resource to control access to the database. Accept the default name for this security resource (e.g %DB_DELTANJI). For ease of initial setup, grant Read and Write public privileges on the new security resource. You may subsequently decide to tighten up security by removing these public privileges and giving them only to the users that need them.

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 yet have a %ALL namespace, create it. After entering %ALL as the new namespace name, tab off the field so that the options on the page can update (2016.1 or later). If you are required to pick a database, select CACHETEMP (this setting will never be used). If given the option, choose not to create a default web application for it. Once you have a %ALL namespace proceed to the steps below in which you will attach 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 and the %vc* routines to the database you created in Step 1. This overrides the default behavior, which would otherwise cause these globals and routines to be sought and stored in the read-only CACHELIB database.

5. Also on %ALL map the VCmStudio package to the same database. On some early 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 in a later step.

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: