| What
is the MDC? When was it set up and why? |
| In the
mid-sixties, in one of the laboratories at the
Massachusetts General Hospital, a programming language
was developed that was nick-named "MUMPS". It
didn't take long before this "neat little
lab-system" became quite popular and a number of
people started to create their own implementations that
worked on the type of computer that they had. Today,
there are only a couple of main types of CPUs left, but
in those days, there was no compatibility whatsoever
between the various CPU boards ("names that I
remember from these days are PDP7, PDP8, PDP9, DEC10,
PDP11, Varian, HP, Philips-800, and I'm sure that many
more names can be added to this list" - Ed de
Moel). Since the various developers were building an
integrated product consisting of operating system,
database handler and programming language for their
specific hardware, you can imagine that they all also
injected their version of "MUMPS" with their
own little additions and inventions. The result was that,
by 1973, there were almost 20 popular dialects of this
language, each with its own following, and portability
between the various MUMPS-look-alikes was almost
impossible. This lack of
portability usually creates a competition in which the
"fittest" survives, but in this case, the
proponents of the various dialects found that there was
more strength in unison than in diversion, and they
started a reconsolidation project. This project led to
the first ANSI standard for the language MUMPS in 1977,
and the group of people who worked on this effort called
their committee the "MUMPS Development
Committee".
Now, twenty years later, the
committee still has the same name, and the purpose is
still (almost) the same, this being to maintain
portability between the various implementations of this
programming language (whether you call that one M or
MUMPS, or by the product name that your favorite vendor
attaches to it). A new purpose of the committee is to
advance the language and to introduce modern concepts
into it.
|
| Who
are the organizations behind the MDC? |
| The original
members of the MDC were vendors and end-users, and the
same is still true. Surely, some members are from US
Government organizations and from universities, but their
participation in the MDC is mainly because they are users
of the language. In the early seventies there were a
couple of implementers and vendors that no longer exist
today, or that are now merged with other vendors.
Although the ratio of end-users to vendors has changed,
the mix is still more or less the same. Some of the
members used to work for end-users and are now working
for vendors, and some people moved the other way.
Overall, I think that the committee consists of a number
of individuals who are dedicated to keeping the M(UMPS)
language up to speed with current-day development in the
world of computing.
Some of the fairly well known organizations that are
represented in the MDC are:
- InterSystems and Micronetics (of course)
- the (US) Veterans Administration (VA)
- the (US) Department of Defense
- Brigham and Women's Hospital
- Kaiser Permanente
- Cap Gemini (who recently acquired Hoskyns)
- IBM and DEC (off and on)
But we don't want to create the
impression that we're forgetting the efforts of the
individuals and smaller or lesser known organizations who
contribute greatly to the work of the MDC: Ackerman
Business Consultants, Antrim, Atlantic Consultants,
BewiData, Bradfield Enterprises, Connections Group, ESI,
Globalware, Greystone Technology, IDX, Indian Health
Services, Isotech, Jacquard Systems Research, JJ
Althouse, LabCorp, Matchups, McIntyre Consulting,
MedSite, MUMPS AudioFax, Polylogics, Richardson Computer
Research, SAIC, Sentient Systems, Thomas Consulting and
the members from an academic background: Goethe
University, Robert Morris College, University of
California at Davis, University of Missouri.
|
| What
is the relation between the MDC and the various other
M-related groups? |
| We don't think
that there is any direct relation, but many people who
work on the MDC are dedicated enough that they also work
on the local interest group in their area, are typically
involved in teaching activities at the annual meetings
(be it in Europe or in the USA) and serve on the boards
of the various M(UMPS) related organizations.
Of course, whenever we travel, we
typically check in with the local interest groups: if
they happen to have a meeting where we could drop in,
they are often happy to have someone there who can tell
them "what's cooking" and what to look forward
to in future releases of their systems. |
| M is an ANSI standard and an ISO
standard. Are there any benefits entailed in it being
ANSI or ISO standard from the user's point of view? |
| The original
purpose of the standardization effort was to increase the
level of portability. That purpose has not changed over
the years, although our perception of what
"portability" means has changed somewhat. In
1975, it was important to be able to move software from a
PDP-8 to a DEC- 10 or a HP computer. This part of
portability still exists, to some extent, but we are now
also a lot more aware of the life-span of software.
Software should, of course, run on the computers that we
have today, but we should still be able to use the
software that we are using today (at least to the extent
of its functional specifications) in about 10 years, when
we will be using CPU chips that nobody has ever even
heard of today and names like Microsoft and Gates may be
well forgotten as relics of a distant past. This type of
compatibility (the MDC often calls it "backward
compatibility) is one of the strongest points in the
succession of standards that M(UMPS) has seen.
A standard is often a "gentleman's
agreement": as long as all parties stick to it, then
everything will continue to work. Of course, there must
be a valid reason to continue to wish to adhere to
something that once was a standard.For instance, the MDC put quite
some work in "standardizing" the interaction
with a terminal, and, now that we finally have a binding
to ANSI X3.64 in the M(UMPS) standard (that is the
standard that describes how to do boldface and italics,
how to move the cursor and how to change colors and such
device specific issues), the world around us has moved to
be "windows" oriented, and not many people will
see a long-term need for this particular standard. Of
course, when the work on this liaison between M(UMPS) and
this other ANSI standard began, Windows 2.0 had not even
hit the market yet...Sometimes, working according to
a standard is a contractual matter. In many contracts
that the US Federal Government enters into, they require
that software be written in a specific manner. Standards,
in this case, can be a valuable method of describing
"how things are supposed to be done".As long as the programmers of
the contracted software producers don't exceed the limits
specified in the standard, and as long as all
implementations support at least these limits, the
customer can be reassured that the software to be
acquired will run on many platforms, and that a switch
from an environment that uses one implementation to an
environment that uses a different implementation can be
achieved without too many problems.
There are many cases where it
doesn't matter whether a standard is from
"ANSI", ‘"ISO" or any other
organization. As long as it exists as a written standard,
and all parties involved can agree that "this is a
standard they wish to follow", the standard as such
has met its purpose.
In many other cases, however,
there is an additional value if a standard has been
approved by a well respected organization. ANSI (the
American National Standards Institute) does not just
approve any document as one of their standards. They
attach great value to their reputation that is built on a
basis of openness in standards development, and wholesale
consensus before a document can be approved as a
standard. ISO (the International Standards Organization)
goes even a step further. They don't just demand that a
document finds consensus in one country, but in all
countries that wish to cast a vote on the document in
question.
|
|
Want to join a M Group?
Our readers span the age-ometer, activity-ometer, and
would like to learn a bit more about M user groups and the benefits these groups
offer.If they don't read about these groups, our readers will be missing out on the potential
opportunities open to them.M Groups need members to exist. If one takes away the room where M Groups meet,
one could always substitute the building, but if one dwindles out the members, there would be no
M Group
MWM would like to act as an introduction agency for the two sides of this singleton.
The only difference between MWM and an introduction agency is the fee; we provide this
service for free.
If you already form part of an M Group, request our free information
pack on how to set off on an a member-increasing route. The M Group does not need to have a
web site or (e-mail for that matter).
I would like more information please
|
