At my first workplace we were using Digital Standard MUMPS on a PDP 11-clone (TPA 440), then we've switched to Micronetics Standard MUMPS running on a Hewlett-Packard machine, HP-UX 9, around early 90's.

Is still MUMPS alive? Are there anyone using it? If yes, please write some words about it: are you using it in character mode, does it acts as web server? etc. (I mean Caché, too.)

If you've been used it, what was your feelings about it? Did you liked it?

  • 1
    I don't think anyone likes something that looks like this. At least perl is expressive. – imgx64 Sep 20 '10 at 9:35
  • 13
    "Is MUMPS alive?" - Yes, but all of the developers are killing themselves. – Steven Evers Sep 20 '10 at 20:39
  • @imgx64 God that looks horrible! – TheLQ Sep 20 '10 at 20:41
  • You needn't use the short form of commands, " D H S Y=%Y K %H,%Y Q ", you should write complete command names (and use longer label/variable names): "Do HourCount Set Year=%YearParam Kill %HourParam,%YearParam Quit". Also, after years of using short command form, I wrote a 20-lines program with usng long-form commands and long named variables. My collegues were told: "okay, it's a good joke, but don't do it again", it was 10 times harder to read than short commands. – ern0 Sep 22 '10 at 7:59
  • 3

11 Answers 11


Intersystems sell a MUMPS derivative : http://www.intersystems.com

Some of the most interesting people in MUMPS are probably here : http://www.outoftheslipstream.com/

I started blogging about Cache (the MUMPS derivative) a couple of years ago : http://cachetastic.blogspot.com/ (but then changed jobs)

Having been out of that world for a couple of years, my thinking is that the NoSQL movement is probably the best and worst thing to happen to MUMPS. Ultimately it's likely to both vindicate and kill it. Because somebody, at some point, is going to reinvent MUMPS's database and query structure almost identically, but with no connection to the MUMPS tradition. Then people will rave about this new storage system. But no-one will ever choose a MUMPS derivative again.

For example, a month or two ago, I was talking with a colleague about using redis to cache a look-up of something in our Django application. We had a large number of records addressed by a triple of three keys, and needed to quickly get subsets matching one or two of these keys (but different combinations at different times).

This is the kind of thing that MUMPS eats for breakfast. But we were finding it hard to squash into redis's key,val pair structure. Even with dictionaries. (Same would be true of memcached etc.) For the first time in my life, I found myself actually regretting that I couldn't write this module in Cache ObjectScript.

Some more thoughts on Cache here :

Good : http://cachetastic.blogspot.com/2008/07/ok-after-mentioning-some-bad-things.html

Bad : http://cachetastic.blogspot.com/2008/07/some-mumps-dissing-and-more-positive.html


Funny interstar should mention Redis. I've actually reverse engineered almost all of Redis's behaviour using Mumps (both Cache and GT.M). Emulating its simplistic and basic key/value pair structure and APIs has been a piece of cake and the Redis clients I've tested don't even know they're talking to a Mumps database instead of the proper Redis.

However, like interstar says, the Mumps database is capable of so much more in terms of both its data structure (actually a Mumps database can easily emulate all 4 NoSQL database types: key/value, tabular, document and graph, and can also model relational and object dbs - all at once if needed), and the properly sorted out and automatic balance between in-memory versus on disk. Unlike the NoSQL databases that have been around for just a few years, the Mumps technologies are mature, tried, tested, well supported and have analytics and administration packages available, and have the kind of performance that many NoSQL databases such as CouchDB would die for.

So why aren't the vendors of Cache and GT.M promoting hard into the NoSQL market rather than let someone reinvent their wheel as you say?

As to the tired old bickering about the language and the use of that ancient and outdatad example from the Wikipedia site:

a) The Mumps database can be accessed by your pet sexy modern language of choice if you want

b) that style of programming went out with the ark, and was written at the time like that to squeeze amazing performance from PDP computers that had less processing power than the chip in your watch. Modern Mumps coding is actually very similar in style to Python and can be just as clean, readable and maintainable.

c) Like any language there are good examples you can find and terrible ones. Don't assume that Mumps coding needs to be as opaque and old-fashioned as the example on the Wikipedia site.

..and Mason, my conclusion would be that perhaps you aren't as familiar with the database landscape as you thought you were! :-) If you've had any form of medical treatment in your life, your information will have been through umpteen Mumps systems along the way, including ones that manage requesting of your tests. The contents of your daily newspaper may be managed by a Mumps system and even the pizza you ordered online was probably via a Mumps system too. The logistics of items you might have had shipped overseas was probably managed via a Mumps system, and if you happened to be a researcher who needed some fancy metals or ceramics, you'll have probably ordered them via a Mumps system.

One of the reasons you rarely hear about what is actually a surprisingly pervasive database is that the vendors have traditionally dealt directly with application/system developers rather than end users, so the database is usually embedded behind the scenes into products.

  • 1
    I think the language is not bad. I didn't tried but it must be pretty quick on a modern hardware. The latest version of MSM was supporting structured programming: local variables (New command), function parameters, inline subroutines for multi-lines. We were so happy with these features, and we've created a bunch of utilities: list viewer, menu etc. Finally, we ran out of stack, so we asked Micronetics to increase stack size. They compiled us a 32-deep stack custom version of MSM instead of the default 16-deep. – ern0 Sep 23 '10 at 13:08
  • 1
    To push back a bit Rob, while I think the MUMPS db is worth paying attention to, I wonder if just the db, accessed from another language can still be called MUMPS. Anyone who chooses MUMPS expects to be able to run legacy code. So MUMPS, like it or not, equals the db + the language. – interstar Sep 25 '10 at 1:44
  • 2
    As I mentioned elsewhere, the real disaster / dealbreaker for the language is dynamic scoping. I don't think any engineer, today, can justify choosing a language without local variables that stay local. So, by all means use the MUMPS db as a black box component, but the language is beyond redemption and should be put to rest. – interstar Sep 25 '10 at 1:57
  • 1
    Mumps has full lexical scoping of variables - it has done for years, but a lot of people don't seem to have noticed! Mumps code can be just as clean and well behaved as any other language. In fact Mumps has a great many similarities to Javascript in terms of variable scoping. eg New in Mumps is, in effect, the same as var in Javascript. By default, however, variables are globally scoped in both languages. – Rob Sep 25 '10 at 13:21
  • 1
    Rob. I certainly didn't notice the lexical scoping of variables in Cache. What about my example in cachetastic.blogspot.com/2008/07/… ? That uses the "new" keyword, but is absolutely NOT the scoping rule you want. The x in f and the x in g should NOT be the same variable WITHOUT g having to explicitly hide any x that happened to be on the stack. The same thing converted into javascript, replacing COS's "new" with "var" correctly gives x in f as undefined. – interstar Sep 26 '10 at 17:04

MUMPS is very much alive. It has been one of the most trust-worthy systems going in the proper hands. The programming staff is usually small and the up-time is impressive. It may seem to the uninitiated that MUMPS is obtuse, but it is possible to write very lucid and highly functional code in very few key strokes and the data structures supported by MUMPS make it extremely powerful and very transportable across various different architectures. All of the VA hospitals are using MUMPS and the mean-time-to-repair is very quick in most cases. The VistA system written in MUMPS is easily downloaded from Source Forge and the poly-modal nature (the database can be accessed by many ways, roll and scroll, thin client, browser, or RPC, or other program interface) of VistA and MUMPS comes through for many who delve into it. MUMPS is a simple language with very few commands and one data type. It is easy to learn because it is an interpreted language and leaves the stack and the symbol table intact to see exactly what was going on when the application stopped for debug. VistA has been used to run the Department of Defense hospitals (Composite Health Care System, CHCS) as well as the Indian Health Service (IHS RPMS), and the was once used by the US Public Health Service. It saved the country many millions of dollars in operational costs. MUMPS runs on nearly anything. It models nearly any other database model easily and provides surprisingly fast access to the databases. The MUMPS model can actually get faster performance with more users on the system (in some cases, due to the cacheing aspects of MUMPS where the pointer blocks needed to find a data block are already in memory and they don't need to be fetched again, BTW, the pointer overhead for MUMPS runs just about 2%, so most of your database is actual user data). MUMPS was originally written to run on a 2K machine. The onslaught of new technology has only expanded the full features of the MUMPS environment into a realm where whole hospitals are now being run on low-cost commodity servers. Early on, MUMPS divorced itself from the hardware and has benefited very well from that decision. We don't worry about the word size or the precision, or how many or how big. The database is late binding and grows as the specific record needs. No record in any database is any larger than it needs to be. The database can be expanded or pruned as per part of a record or as a whole record. Is MUMPS still around?, you betcha? An instead of getting 8 users on a PDP-11/34, you can get a couple of hundred users on the desk-top PC under your desk. It is being used in Banking, the European Stock Exchange, the travel industry (hotels and bookings agents), some auto parts houses, and most successful hospitals (commercial, private, or community) are running MUMPS in some form. The VA currently has over 30 years of outcomes histories for their over 9 million patients. That in itself is something that no other healthcare system has accomplished, except for Beth Israel/Deaconess Hospital in Boston that has over 35 years of outcome in their home built MUMPS system.


there are a couple of serious mumps questions on SO:


  • Why the downvote? The question was Is still MUMPS alive? Are there anyone using it? - surely this is relevant evidence of someone seriously writing new code and/or learning MUMPS? – Colin Pickard Apr 28 '11 at 16:57

Yes MUMPS is very much alive. A good portion of the VA Hospitals in the US use MUMPS.

  • 3
    And good portion of patients are alive? :-) – Maniero Sep 20 '10 at 16:46
  • 8
    @bigown: Of course. If not, they wouldn't still be patients. – Mason Wheeler Sep 20 '10 at 19:58

VistA (Veterans Health Information Systems and Technology Architecture) is AFAIK still in active development: http://en.wikipedia.org/wiki/VistA_EMR


I am also new to g.tm, but I can answer this :

Yes, Mumps is alive. There are still people working on it. here are some examples :

http://georgejames.com/ who wrote an Openstreetmap api server in gt.m that I am learning now.

There are also now modern enterprise web tools for g.tm http://gradvs1.mgateway.com/main/

and the last proof that it is alive is that it has been ported to the latest GNU/linux and cloud platforms.



One of the big companies working in medical records, Epic Systems, still uses MUMPS in their applications.


You should read this:


about MUMPS.

On the other hand, I work in the DC area and run into people fairly regularly that not only know what MUMPS is they work in it frequently.

  • That.... that HORRIFIED me. I feel like I need to bathe, now. :( – Matt DiTrolio Sep 20 '10 at 13:37
  • 1
    It's hard to explain in the age of SQL, that these issues, which that article lists, are features. One letter is for speed. One type is far better than automatic typing. Etc. – ern0 Sep 21 '10 at 8:27

Well, I have never ever heard of anyone using it, in any context or for any reason, except for on The Daily WTF. What conclusions can be drawn from this are up to the reader. ;)


Interstar's example correctly written to use functions:

f ;   
  new x  
  set x=$$g()  
  write x  

  new x  
  set x = 5  
  quit x  

do f  

f is a procedure which is invoked with a do. If, as in this case, it has no formal parameters, you don't need the (). A procedure just Quits and doesn't return anything.

g() on the other hand is a function. The new x is crucial to correctly scope x. A function is invoked by preceding its name with $$ and it QUITs with a return value. A function must have a formal parameter list declared even if it's empty as here. Actually you could write this instance of g() as just:

 quit 5

It will all behave perfectly now. For some reason a lot of Mumps developers don't seem to have noticed or understood the existence of functions, or understand the difference between them and procedures. I think this is one of the reasons why people new to Mumps throw their hands up in horror (not surprisingly) - there's an awful lot of terrible code out there.

Written as shown above, it's all quite clean and respectable stuff. However, it's up to the programmer to explicitly scope variables within functions and procedures. Leave them out and they'll be global and leak everywhere. The trick is to build and test each function as you go in isolation and ensure that they rely on nothing but their formal parameters and, when finished, they leave nothing behind.

  • Now one of the reasons you see Mumps code out there that doesn't use new commands and which relies on the variables being global (so it breaks if you New the variables) is because it was written at a time in the past before functions and lexical scoping were added to the language. Unfortunately there is a LOT of legacy code out there and, yes, it ends up being a nightmare to maintain, but that's legacy for you. On the other hand, it's quite possible to write clean, modern, well-behaved Mumps code, provided you're writing new stuff from scratch without any legacy stuff to worry about. – Rob Sep 26 '10 at 19:26
  • Looking at your original example, the value x, when new'd in procedure f is automatically available to g - that's just the way Mumps is. In the same way, people who are used to C-syntax languages are surprised when they discover that scope in Javascript is only applied to functions, and not, eg, to within loops or blocks inside a function. That's just the way it is - once you know it, you deal with it accordingly. Such idiosyncrasies have not stopped people accepting and adopting Javascript. – Rob Sep 26 '10 at 19:54
  • Rob : "Looking at your original example, the value x, when new'd in procedure f is automatically available to g - that's just the way Mumps is." Indeed! And that's what it means to say that MUMPS has dynamic scope and not lexical scope. In a lexically scoped language, you don't need to have the "new x" in function g, because the lexical structure of the program (ie. the fact that g is defined outside the definition of f), is sufficient to guarantee that the xs refered to in g and f are two entirely different variables. – interstar Sep 28 '10 at 4:38
  • Rob. On the wider point, that a well disciplined team of MUMPS programmers, writing from scratch, and carefully using "new" to ensure that all variables are local, can avoid the pains of dynamic scoping. Sure, I agree. But why should we need iron discipline and hundreds of extra lines of code, to replicate what every other contemporary language gives you for free? Also, if you're faced with legacy code that wasn't written with this discipline, it's almost impossible to put it in later, because you can't tell if the system is relying on one of these non-locals to pass information around. – interstar Sep 28 '10 at 5:09
  • There're other (older) methods to separate subroutine variables: all the variable names of system utilities begin with '%' sign, so they are in the "system namespace". Also, naming variables in New is about the speed: if you use an explicite command to push re-used variables onto the stack, the interpreter has to do nothing itself upon entering a routine. Also, you can use New, without parameters, which hides all the current variables. – ern0 Sep 28 '10 at 5:21

Not the answer you're looking for? Browse other questions tagged or ask your own question.