Tucson Tindalls

Aaron and Kristin's Virtual Home

Introduction:

Visual MUMPS is an implementation of the ANSI standard language of MUMPS. MUMPS is an imperative, unstructured programming database language. It contains very powerful intrinsic string processing capabilities as well as a parallel and multithreaded design. This particular implementation is also heavily distributed with client machines executing all foreground programs and the server running only background jobs and servicing database requests.

MUMPS is a language with a long, rich, and colorful history. This manual assumes a working knowledge of classical ANSI MUMPS. For those unfamiliar with the language many good, simple to read books are available. Since it’s a consistent and simplistic language the learning curve is minimal. Indeed I have taught MUMPS as an introductory programming language to many programmers who picked it up in a matter of days. Skilled programmers can grasp the whole of the language in a day or two especially if coming with multi-threaded and/or database programming backgrounds.

Features of Visual MUMPS:

The feature set and usage of features beyond the conventional language specifications are provided in the pages that follow. Exact details of the current set of implemented features can be found in the current ReadMe.txt file as it is kept better up to date than this manual. Current releases and updates can be found on the Visual MUMPS homepage located at http://www.tucsontindalls.net/VMumps.html.

The backend of Visual MUMPS is implemented in Java for maximum platform independence. MUMPS has historically enjoyed a very platform independent existence and Visual MUMPS continues in that vein. Visual MUMPS Version 0.07 alpha, the most current version as of this manuel's writing, requires Sun’s most recent Java Runtime Environment (or JRE), Java 1.4.0 beta 2. This can be found and downloaded for free at http://java.sun.com/j2se/1.4/; only the JRE is required, not the full JDK. Because the backend is written in Java Visual MUMPS client applets are not far off, meaning that Visual MUMPS will be able to run inside a browser. Already Visual MUMPS applications use Intranets, or even the Internet as the connection for clients to the server as well as a delivery mechanism.

As large a revolution to classic MUMPS as that is there is yet a more striking architectural improvement. MUMPS was originally designed in the era of servers and dumb terminals. In today’s working environment terminal clients themselves are full-fledged computers. Visual MUMPS offloads foreground process execution, and in the future some background process execution, distributing the load off of the server. This allows the server to focus on database service. In practical terms this means that the server need not be as powerful, or conversely that more users can use the same server without over burdening it.

In addition to the back-end of the server a pleasant GUI front-end is provided if the server is so equipped. A four-panel display provides a quick view into the status of the server:

All panels can be resized or removed and scroll when needed. The northwest panel provides an easy to view examination of the current state of the database and the data it contains. The northeast panel contains the set of locks currently on the system. The southwest panel contains a list of the clients currently connected to the server. The southeast panel contains the names of the background jobs presently executing on the server. No MUMPS vender currently offers such an easy and intuitive method of providing the server’s status in real time. Whether or not the server is GUI capable a comprehensive system log is generated including what clients connected and disconnected when and where from.

The last major enhancement of Visual MUMPS over its predecessors is what gives it its name. Visual MUMPS will shortly include full GUI event driven features built right into the language. This eliminates the need to use another language as the front end to a MUMPS server greatly simplifying the design and adding performance and reliability to the overall system.

The Visual MUMPS interpreter provides excellent, context sensitive, meaningful and readable error messages for quick, easy debugging. At the same time a pseudo compiler preprocesses code into an easier to interpret version for faster execution. Even instructions generated through the language’s very powerful indirection are subject to the pseudo-compilation.

Syntactic differences and additions:

All additions to the language follow the ANSI standard convention that non-ANSI standard commands begin with a ‘Z’ and non-ANSI standard intrinsic functions begin $Z.

$Zevent – (the first lower case ‘e’ is required) a new intrinsic function that is true if event trapping is on, false if it is not. $Ze cannot be directly modified, but must be changed by using the ZEvent command described below. GUI events are handled only when $Ze is true. If it is false they queue and are handled when $Ze is once again true.

$ZIp – a new intrinsic function that returns the IP address of the machine in which the process is running. For foreground processes this means the IP address of the client machine whereas this will be the IP address of the server for background jobs.

$ZPrevious – a commonly found addition to the set of functions, this function works like $Order in reverse with the same parameter options.

ZEvent – changes the value of $Ze. ZEvent takes one parameter. That parameter is evaluated as a boolean expression. $Ze takes on the result of that evaluation as its value.

ZWindow – initializes or updates a GUI window in one command with the standard abstract windowing tools (AWT) found in all major GUI packages. ZWindow takes one parameter that is a reference to the root node of a sparse array, which describes the windows components and properties, as well as specify routine references to handle events.

Open – although Open is an ANSI standard command it’s parameter’s syntax is not defined by the language specification. The options are provided below:

for files:

O <device number>:("F":"RW":filename)[:timeout]

for remote ports:

O <device number>:("R":"RW":server:port)[:timeout]

for local ports:

O <device number>:("L":"RW":port)[:timeout]

R-Read access; W-Write access

Open for remote ports is non-blocking where Open for local ports is blocking.

Pattern match, the '?' operator, is syntactically slightly different from the ANSI standard.  In Visual MUMPS the '?' operator works like all other binary operators in that it evaluates both operands and then performs the operation.  The ANSI standard for pattern match calls for the right hand side to be a hard coded pattern rather than an expression.  In Visual MUMPS it is an expression.  For converting MUMPS programs this simply means putting quotation marks areound the right hand side operand.  But for developing programs this allows for patterns to be generated at run-time.  This can be accomplished under standard MUMPS via pattern indirection but is much more straightforward and consistent in Visual MUMPS.  Future versions of Visual MUMPS will likely be written to conform to the ANSI standard.

Using Visual MUMPS:

To start the Visual MUMPS server enter the following on the server’s console:

java [-server] VMumpsServer <database filename> [<port number>] [noGUI]

Optional entries are in square braces; entries that require a parameter entered are in angle braces.  The -server option specifies to use Java’s server VM for performance reasons.  It is not required for any functionality.  The database filename is the operating file to use to store the database.  If the specified file does not exist one will be created and the database will be empty.  Multiple Visual MUMPS servers may run on a machine concurrently, but each must use a separate database file.  Since each MUMPS server is already multi-threaded there would be no advantage to multiple servers for a single database anyway.  The port number is the local port to use for clients to connect to.  If left unspecified 8189 will default.  If noGUI is specified no attempt to display a GUI interface will be made.  If unspecified the server application will check if the hardware can support a GUI and if so displays one.

To start a Visual MUMPS client enter the following on the client’s console:

java VMumps <host address> <port> [routine to execute]

The host address is the address of the Visual MUMPS server to connect to.  It may be a name, so long as the name is properly dereferenced, or it may be the server’s IP address.  Port is the port specified when the server was started.  When the server is started its IP address, name, and port are sent to the log file.  If routine to execute is specified the client will run the program from the server’s database matching that name.  If left unspecified the program named SHELL will default.  More than one client can run on a single machine with potentially multiple connections to a single server or to multiple servers.  A client can run on the same machine as the server it is connecting to.

To import a program from a text file to the server’s database and make executable enter the following line on any console:

java ImportProg <host address> <port> <input file> <routine name>

 The host address is the address of the Visual MUMPS server to send the program to.  As with a client it may be a name, so long as the name is properly dereferenced, or it may be the server’s IP address.  Port is the port specified when the server was started.  The input file is the filename of the text file to import into the database.  The routine name is the name of the program once it is in the database.  The routine name is case sensitive.