A routine file might look like this (for a routine called 'sampleproc'):
In this case, labels have been attached to the first, fourth and eighth lines, creating subroutines within the parent routine. The fifth line makes a subroutine call within the same routine, to a subroutine called 'subproc'. It would also be possible for any other program to call that subroutine by fully specifying it, as
do subproc^sampleproc(argument). Even though the fourth line appears to be inside another subroutine, it can still be called from other routines with
do dosets^sampleproc, and execution will continue with the first part of sampleproc() ignored.
Even though sampleproc is defined as needing an argument, dosets is not, ao you would not pass any arguments to dosets. MUMPS also allows the programmer to jump to an arbitrary line within a subroutine.
do sampleproc+3^sampleproc is equivalent to
MUMPS has a large set of string manipulation operators, and its hierarchical variable management system extends to both RAM-based and disk-based variables. Disk resident (ie, database) variables are automatically stored in hierarchical structures. Most implementations use caching, node indexes and name compression to reduce the time/space cost of disk references.
All variables are considered to be 'sparse' arrays. In a MUMPS context, this means that there is no requirement for sequential nodes to exist —
A(1), A(99) and
A(100) may be used without defining, allocating space for, or using any space for, nodes 2 through 98. Indeed, one can even use floating-point numbers and strings (
A(1.2), A(3.3), A("foo"), etc) where the subscript names have some meaning external to the program. The access function
$ORDER (A(1.2) ) returns the next defined key or subscript value, 3.3 in this example, so the program can readily manage the data. Subscripts are always returned (and usually stored) in sorted order.
Given their sorting and naming features, it's not uncommon for subscript/variable names to be used as data stores themselves, independent of any data stored at their locations. This feature is often used for database indexes. Eg,
results in creation of a new disk record, which is immediately inserted within the file structure of the disk. It is persistent, just as a file persists in most operating systems. Globals are stored in highly structured data files by MUMPS, and accessed only as MUMPS globals. MUMPS has a long history of efficient, stable, theoretically-sound cached, journaled, and balanced B-tree key/value disk storage, including transaction control for multiple file transaction 'commit' and 'roll-back' at the language/operating system level. Real-world databases can often grow unpredicatably (such as having 20 patients with a last name of 'Anderson' before you get any with surnames starting with 'B'), but modern MUMPS implementations are designed to structure the database efficiently as it grows.
For all of these reasons, one of the most common MUMPS applications is database management. MUMPS provides the classic ACID properties as part of any standard MUMPS implementation. FileMan is an example DBMS built with MUMPS. Intersystems' Caché implementation allows dual views of selected data structures—as MUMPS globals, or as SQL data—and has SQL built in (called M/SQL). The MUMPS view allows programmers rather more control of the data, as there is no requirement to fit the data into the assumed rows and columns of relational SQL.
new' command allows a routine to hide variables its caller might have created, and prevent itself from modifying them. It cannot prevent routines it calls from modifying its own variables, so good MUMPS programming practice is to have every routine 'new' the variables it uses.
To demonstrate the ease of network operations, consider:
which gives A a value as before, but this time on the remote machine "DENVER". MUMPS programs are accordingly nearly trivial to distribute over multiple machines. This ease of network operation made it easy to expose the same sorts of distributed operation in SQL (and other) layers with ease.
Another use of MUMPS in more recent times has been to create object databases. Intersystems' Caché implementation, for instance, includes such features natively.
MUMPS can generate text in HTML or XML format as well, and can be called via the CGI interface to serve web pages directly from the database. It can also be used as a backend for web applications using Ajax background communication.
MUMPS also reads delimited datasets easily, such as the .csv (comma-separated values) files commonly used as an interchange format (eg, in exports from spreadsheets).
MTA thrives on change. (John Colvin, VP of M Technology Assn) (Special section on M technology, a programming language derived from MUMPS, or Massachusetts General Hospital Utility Multiprocessing System) (Interview)
Jun 01, 1994; Q Why is the M Technology Association exhibiting at COMDEX this year? What does it hope to accomplish? What are the goals, and...