My current employer makes extensive use of a software I expected never to encounter in my life, MUMPS! It turns out that MUMPS (much older than Perl) is a database and language, much like SQL or Oracle, but it's heirarchical and not relational. I'm told. Whatever that means.

I feel your pain, because MUMPS has become part of my current job, much more than I ever wanted it to be part of my job.

MUMPS is a database in that all "globals" are stored on disk rather than just in memory. The globals are stored as trees (heirarchical), not as tables (relational). A global, like any MUMPS variable, can store a single value (like a perl scalar), or it can store key-value pairs (much like a perl hash, but with implicitly sorted keys), or it can store both at the same time. The values of the key-value pairs can again be single values or key-value pairs, deeply nested. But there is nothing like SQL to query these trees, you have to write MUMPS code. (Caché (see below) does offer an SQL interface to the trees, but it looks very strange.)

Oh, by the way: Did you know that MUMPS started as an operating system running on bare metal of ancient computers? All current implementations still provide the grey-haired coder with this illusion.

I need to report on certain transactions found in Journals, in particular I need to extract the Global Variables from the record types in which they are created, modified, or cleared.

There are several very different implementations of MUMPS, despite being standardised by ANSI or some other authority. I know only the Micronetics implementation (MSM) from personal experience, the Caché implementation from a big distance, and the Perl implementation from a short "just forget it" experience.

Parsing MUMPS code is easy for the common case, but there are some edges that make your live really hard. The indirection operator (@) is my favorite here, directly followed by the string-eval command XECUTE. As soon as you find one of them, you are essentially lost with a simple parser. You need to know the current values of the variables referenced in the code to continue. So, you can't simply parse MUMPS, you have to interpret it. It's the "only perl can parse Perl" of the punch card age. With the minor difference that each and every MUMPS implementation has its own set of incompatible extensions.

From the Micronetics implementation, I know that there are several tools for handling MUMPS code. The INDEX program is able to generate a cross-reference for a single MUMPS program or a bunch of MUMPS programs, with variables, syntax warnings, and so on. See ftp://ftp.intersys.com/pub/msm/docs/msm44/utility.pdf for details. Of course, it's just a MUMPS parser, not a MUMPS interpreter, and it seems to be ported from a really ancient version. It can be confused by "modern" code that uses device mnemonics, but it's the best available tool for the job (simply because it's the only one).

Generally, don't try to work with MUMPS code outside a MUMPS system. You will fail at writing a MUMPS interpreter. Try to solve your problem inside MUMPS, or export your data from MUMPS to text files and handle those exports in a modern language. It's quite easy to write even XML or JSON from MUMPs to files, but parsing those formats correctly from MUMPS is nearly impossible.

Alexander