The Atmus Manager will consist of two parts. A web based GUI and collection of server side scripts and mumps routines. The Atmus Manager will provide simple tools for...

• Creating new GT.m Databases
• Creating new Atmus Workspaces (a.k.a. GT.m instances)
• Downloading (installing) libraries from the atmus.org repo
• Assigning libraries to workspace(s)
• Creating / Managing projects
• Assigning projects to workspace(s)
• Monitoring Databases
• Repairing Databases
• Enable / Disable journal files for Databases
• Configure journal file locations
• Enable backups
• Configure backup locations
• Viewing Atmus and GT.m log files
• Exploring databases
• Viewing and editing globals

Databases

The default database created by Atmus will use the following name and region mappings...

 

• All ^* globals map onto a 2k region
• All ^X* globals map onto 32k region
• All ^Z* globals map onto a separate 2k region (not journaled)
• All ^S* globals map onto a shared 2k region (the atmus core instance)

 

New projects developed under Atmus using these default database templates should adhere to a number of naming conventions.

All globals should start with a lower case letter. These globals are mapped to a default 2k region. This should provide a large enough global storage space for most uses whilst providing a good level of performance.  The default 2k region can optionally be adjusted to meet the exact developer's requirements.

Globals that start with a capital letter should be reserved for specific uses. Developers that come from alternative Mumps systems are used to having globals that store up to 32k. Atmus provides the ^X* mapping so that this option is available for new globals. Temporary globals in most cases do not need to be journaled and are more efficient running in a non journaled region using the ^Z* mapping. Atmus also has a number of projects in the pipeline that would benefit from inter-instance communications using globals as message queues. The ^S* mapping provides a shared global mapping that will map all ^S* globals to the Atmus core instance database.

Users that need to port legacy code into an Atmus workspace can create their own template scripts to meet the exacting needs of the code. However, the Atmus organisation will try to encourage the use of default templates for approved Atmus libraries.

Projects

Atmus will provide excellent support for managing code in projects. Project source code will be stored and grouped in Linux directories. As mentioned in the installation wiki page, the directory structure for projects will be...

/opt/atmus/libraries/{domain}/{project}/{version}/

Example storage: Company spudsLTD developing a project called foobar with a number of versions on the go...

/opt/atmus/libraries/spudsLTD/foobar/1.0/
/opt/atmus/libraries/spudsLTD/foobar/1.1/
/opt/atmus/libraries/spudsLTD/foobar/2.0/

The Atmus manager will provide a simple option to select which version is enabled in a particular workspace. This will provide flexible options for sharing the same project code across development / testing and live workspaces. It also provides a simple method for upgrading a workspace from one version (or downgrading) with a single click.

The Atmus Manager will also provide granular configuration of these projects so that different types of source code can be grouped separately.

Configuration and management of project will also be available via an Eclipse plug-in as part of the Atmus IDE.