3

I am looking for a detailed definition/discussion of Mumps globals implementation. There is a document titled "MUMPS Globals and Their Implementation", but I have not been able to find any way to order it, let alone access a digital copy. (it was printed in 75)

In general I am trying to find an in depth discussion of Mumps' database internals.

mahonya
  • 9,247
  • 7
  • 39
  • 68

4 Answers4

3

Take a look at this paper, A Unified Local, Global and Routine Design for Mumps Micro-Computer System by Frank Brown. Dr. Brown was the designer of the global system from COMP Consultants Standard MUMPS. I was the implementer, in 8086 assembly! Yes, way back in 1981.

It was essentially a simple B-tree with compressed keys.

I. J. Kennedy
  • 24,725
  • 16
  • 62
  • 87
  • Thank you. I'm having difficulty accessing the paper though. Am I missing something or is it not available online? – mahonya Jan 23 '13 at 17:45
  • @sarikan, the link should take you to the article's page on citeseer. Look for the (tiny) pdf icon. Here is the direct link: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.8872&rep=rep1&type=pdf – I. J. Kennedy Jan 24 '13 at 02:04
  • I must have missed it before. Thanks a lot! – mahonya Jan 24 '13 at 07:13
1

I would assume that the database internals will differ greatly between the various MUMPS implementation. So, I think your best bet would be to look at how it is done in the open source MUMPS implementation :

Laurent Parenteau
  • 2,516
  • 20
  • 31
1

I am not exactly sure what you are after. Mumps globals are simply a sparse, multi-dimensional array. The programmer is free to implement their data base strategy as they see fit. For example, a customer database can be implemented as:

^CUSTOMER(custnum,"NAME")=name
^CUSTOMER(custNum,"ADDRESS")=address
^CUSTOMER(CustNum,"PHONE")=phone

alternatively, the customer database can be implemented as:

^CUSTOMER(custNum)=name|address|phoneNum

Here, I've used the pipe character "|" as a delimiter in the customer record. In most mumps implementations, the record string length is limited to 32k.

In a relational sense, the CUSTOMER global can be thought of as a table with custNum as the key and name, address and phone as the columns .

A similar scheme could be used for an orders table:

^ORDERS(orderNum)=date|invoiceNum|totalPrice

To relate a customer to an order, we could use a separate global:

^custOrders(custNum,orderNum)=""

or alternatively add them to the customer global:

^CUSTOMER(custNum)=name|address|phone
^CUSTOMER(custNum,orderNum)=""

or even combine the two tables into one global:

^CUSTOMER(custNum)=name|address|phone
^CUSTOMER(custNum,orderNum)=date|invoiceNum|totalPrice

The strategy used is up to the developer which is extremely flexible and powerful.

There are a couple of other documents that I would recommend in addition to the document that you reference above. For some basics on globals and what they are, I would recommend:

Extreme Database Programming with MUMPS globals

For a more advanced topic, I recommend:

A Universal NoSQL Engine, Using a Tried and Tested Technology

Both documents are authored by Rob Tweed who is a bit of a mumps evangelist with his company M/Gateway Developments. The first document gives good background on mumps globals and the second on using them in a variety of strategies including noSQL.

igotmumps
  • 549
  • 2
  • 7
  • Thanks for taking the time to respond. I was referring to how MUMPS functionality is implemented, that is, how globals are persisted to disk (b-tree?) how does the concurrency handling work. I am not looking into learning how to use MUMPS. I actually met Rob at an even a few months back. Maybe I should ping him :) – mahonya Sep 28 '12 at 12:02
  • 1
    Most Mumps implementations use a B+ tree for persistence. In the case of GT.M (which I am most familiar with), concurrency can be handled with transactions as GT.M is full ACID compatible. I would expect Cache to be the same. – igotmumps Oct 10 '12 at 19:54
0

Agree with previous answer; question is pointed to implementation details which would be considered proprietary by the vender. There is insight to the open source/historical versions, but Cache and current versions would deviate as they get into their modern scaling capabilities.

lschofield
  • 21
  • 3
  • Is this an answer or a comment? – WEFX Dec 13 '12 at 21:19
  • 1
    Answer - MUMPS database internals are left to the creator and not part of the standard. Balanced trees are the historical approach, but specifics of file writing is up to the implementer. Comment shifting lost context, I was referring to the response from Laurent Parenteau. Participating in open source projects is probably the only way to have detailed definition and discussion; the dominant vendor would consider their information proprietary I would guess. – lschofield Aug 22 '13 at 04:36