The first step, indeed, is to let the committee know. Writing a letter to the Secretariat should work (same address as the MTA: 1738 Elton Road, Suite 205 in Silver Spring, Maryland 20903, USA); sending e-mail to the chairman should also work (currently: demoel@radix.net). At the very next meeting of the MDC, the request will be delegated to a task group. Now, most task groups already have their hands quite full, and sometimes it does happen that they are requested to work on a proposal, and it takes a while before any results become visible. Don't hesitate to prod us if you think we're forgetting you.

We all know the explanation that "a hippopotamus is a race-horse designed by a committee", and the MDC is very well aware of that stigma. Indeed, we do try to look at a problem from all angles, and indeed we do try to insert all caveats and contingencies that we can think of. But we also try to keep in mind that (here it comes in handy that there are so many end-users in the committee) eventually we will have to work with the result ourselves.

The stages that all proposals go through in the committee are:

• incoming mail
• assignment to a task group (Type C status)
• technically complete (Type B status)
• functionally approved (Subcommittee Type A status)
• fully approved for inclusion in "the next" standard (MDC Type A status)

Type B status (technically complete) means that a subcommittee feels that a document has all the appropriate language in it to describe the intended change (in section xxx strike "this text" and insert "this other text" in this other section).

Subcommittee Type A status means that a subcommittee feels that a document is ready for inclusion in a next standard.

The final step (taking a document from "Subcommittee" Type A to "MDC" Type A) is necessary to resolve any final issues that may have crept into a document. Also, "in task group" and "in subcommittee" the issues are discussed by only a subset of the members of the whole committee. This final step allows all members to cast their votes on the matter.

Of course, this "last step" is only the last one in the sense that it is a step within the MDC. The most important step comes after this: when all the changes to be made to the "previous" version of the standard are consolidated into one new document, this "draft new standard" is circulated for a vote among the M[UMPS] community at large. This step is called the "canvass process". Anybody who is interested in casting a vote at this stage can write to the MTA and request to be put "the canvass list".

A good way to see whether the MDC is acting on your suggestions, and also a good way to keep track of what's going on in the development of the language as a whole, is to subscribe to the "proceedings" of the MDC. The MTA makes all MDC mailings available to anybody, at cost (about $150 per year).

People who would interview people for MWM. Prospective volunteers must be capable of formulating interesting questions and above all possess good communicative abilities.

Accepted candidates will always be guided on each interview if they require this help and will be assisted in numerous ways, making this task a relatively simple job. Each person whose interview appears in MWM will receive, upon request, a statement showing the talents and capabilities of the interviewer.

If you would like more information or have someone in mind, drop send us an e-mail at mwm@mcenter.com with the subject line set to MWM Who

In the case of MUMPS, the US Federal Government has placed a lot of emphasis on the need of products meeting Government Approved Standards that apply to the field of application for those standards.

Because so many people rely upon those standards, it is important that nobody gets short-changed when these standards are established. In other words, the standards relating to M[UMPS] are (hopefully) important to people who read this magazine, so, if an effort is announced that involves the approval of one of these standards, it is important that you get involved in the process of casting a vote on its approval. Getting involved is as easy as writing a letter to the MTA stating that you want to be included in future "canvass procedures" for specific (or all) M[UMPS] related standards.

If the proposed standards are "what you want", things are easy: you can just vote in favor, and that will be it. If you have a problem with the contents of the proposed new standard(s), you will want to make your objection(s) known.

The first step to do that is to write to the MUMPS Development Committee, and make your concerns known. There is no need to wait for a vote on a document to write any letter to this committee: their job is to listen to the M[UMPS] community, and they should respond to any incoming mail, always.

"Yes, yes, I am the current chairman, and I know that, on occasion, we drop the ball, and responses don't get mailed appropriately. If you wrote to the MDC, and you didn't get a response, be certain to write a reminder to the Secretariat, or e-mail me directly (demoel@radix.net). And, if you didn't get a response after a number of tries, you might want to complain to ANSI, our parent organization. Of course, we don't like getting our wrists slapped "from above", but if needs be, that is the way to go." - Ed de Moel

If you feel that the MDC made a decision that affects your interests in a negative way, or if you feel that the MDC should have taken some action, your first duty is to let the MDC know, and give them a reasonable opportunity to correct the situation. If the MDC fails to respond to you in a manner that clarifies or justifies their actions, or lack thereof, you are entitled to file an appeal with the MDC.

In order to be able to process an appeal, you will need to provide three statements: "the actual problem", "the damage" (how this problem affects you directly and materially) and "the solution" (an action that the MDC could take to alleviate or correct the problem). In the past, the MTA could afford to bear the expense of processing all the related paperwork and copying. Currently, a deposit of $250 is required to be able to process an appeal.

Appeals are heard by a panel that is selected by both the appellant and the MDC, and both parties must find a majority of the panel members acceptable. So far, panels have consisted of three people, which means that two was such a majority. A hearing will be convened (typically by telephone-conference, to reduce the expense of the effort), and the panel will hear both sides. After this, the panel will meet at their discretion in closed session, and they will rule on the issue of the appeal.

So far, the only appeals that the MDC has had to deal with were by one single individual, and in all cases, the panels ruled that there was no reason to delay the MDC any further in proceeding with the canvass process, and made some recommendations that for future efforts, the MDC use some stricter procedures. The MDC fully intends to follow these recommendations.

When an MDC appeals panel has ruled in such a way that the MDC can continue what they were doing, you might still feel "bulldozed". That is where ANSI comes in. As our parent organization, they are the next higher authority. Typically, they only deal with appeals in the context of a standard to be approved, but, also typically, that is when you probably want to be most vocal should your interests be impaired by a proposed standard.

So... when the MDC is "canvassing" a proposed standard, you might want to vote in opposition to that proposed standard, and let the MDC know your reasons for a negative vote. The next step is that the MDC will attempt to resolve your objection. Such attempts to resolve issues will typically be conducted by (paper) mail being sent back and forth. On occasion e-mail and phone calls may be used as well, but the nice thing about paper mail is that multiple people (on both sides of the issue) can deliberate on the next letter to write, and there will be an easy to follow paper trail of what happened.

If the MDC happens to agree with you that there is a fatal mistake in the proposed standard, their policy is to withdraw the document from consideration, bring it back into the various working groups, fix the problem, and then start a new "canvass procedure" for the corrected document.

If, on the other hand, an objection cannot be resolved in the course of a canvass process, you will be invited to present a statement to be included in the "report of unresolved objections". This report will be sent to all the same people who received the original ballot for the document in question, and they will be offered the opportunity to change their votes, based on the new information presented.

Now we get to the "juicy" situations... If a significant portion of the M[UMPS] community feels that you are right, they will change their votes from "approve" to "disapprove", and the proposed document will go back to the MDC for remedial action. So far, this has never happened, but if it does, we will take matters seriously, and bring the document back to the various subcommittees and task groups, do the work that is needed, and start a new "canvass process" for a corrected document.

What has happened over the past 10 years, is that the proposed documents received substantial approval from the majority of the M[UMPS] community, while a small group maintained their objections.

In these cases, the MDC felt that the M[UMPS] community had established a consensus that the proposed documents were acceptable as American National Standards, and forwarded them to ANSI for final approval. ANSI subsequently gave their approval, and this is where the next series of rounds of appeals starts.

The first appeal is to ANSI for approving a document. The office at ANSI to write to is the "Board of Standards Review" (BSR). Of course, you have to specify grounds why ANSI should not have approved the document in question. The easiest is to document how your business interests are affected in a negative way by the new standard. In fact, the first thing that ANSI will ask you is to document how you are "directly and materially affected" by the standard in question at all. If you cannot answer that question, your case is seriously weakened and may not even be heard. Of course, if you are not "directly or materially affected", why would you be interested at all in what the standard exactly says...?

Over the past 10 years, the MDC has been involved in five (three in 1990 and two in 1995) of these appeals. The appellants in those cases attempted to convince ANSI that the MDC had not paid enough attention to their comments about the language of M[UMPS] and the activities in which the MDC should engage. In all cases, ANSI ruled that the appeals were without merit.

Should the BSR rule against you, there is a last opportunity (like the Supreme Court in the US legal system). This board is the ANSI Appeals Board. The only appeals that you can file with this board is to rectify errors that ANSI offices have made. In order to file an appeal with this board, you have to present evidence that makes it obvious "a prima facie" that an error has been made, and you have to pay $500 to cover administrative fees. Having been involved in the mailing and photocopying that goes on in the processing of an appeal, I can assure you that this $500 is only a token amount: the actual administrative expenses are a lot more.

If this board rules in your favor, the issue goes back to the previous level, and it is pretty unlikely that they will make the same mistake again, and from there it will probably bounce further back until the matter gets back to a level where it can actually be addressed.

What has happened in the case of the MDC is that, in 1990 and in 1996, there have been such appeals, both by the same individual. In 1990, the ANSI Appeals Board heard his case and denied it. In 1996, they found that he had not even produced enough evidence to justify a hearing, and denied his case outright.

So... that is a lot of talk about "appeals" and how often they were "denied". Does that mean that is us a useless waste of effort to appeal to the MDC, or to ANSI as their parent body? I would hope not. Of course, typically, it is better to try and work with the committee and make certain that the outcome of a certain issue in the next proposed standard is such that is helps your business. If the committee fails to respond to your issues, the path of filing appeals is a good and valid means to get your point across.

From our personal perspective: if your issues are of a technical nature, the committee will typically understand them at an early phase in the process, and the text that will be presented as a draft standard will not harm you.

On the other hand, appeals that appear to have no other purpose than to be a means of delaying the progress of the standardization process will continue to have the desired effect, but will also continue to have little or no hope that they will ever prevail. The MDC is committed to work by its rules, so any appeal will be processed as it should be, but, as yet, the MDC has seen no appeal of its activities that addressed any technical issues.

MWM hosts two non-computing sections which we are sure you'll enjoy. Wasted is our humor page with which we hope to encourage a smile or two. If you have a joke, anecdote or other piece you would like to share with us send in you humor to mwm@mcenter.com. Please set the subject line to MWM Wasted

M[UMPS] started out as a simple language to facilitate the storage and retrieval of information in a hierarchical database. In 25 years, we have seen this language grow into a basis for database management systems, relational ones as well as hierarchical ones; we have seen the addition of transaction processing to support high volume banking work; we have seen the addition of more flexible control structures, and we have seen the language grow to be closer to modern theories about what an information processing language should look like.

Over the next 10 years, we will see more growth in the directions that support "modern" needs. One such need is the ability to communicate with "object oriented environments". What the interface with such environments is going to look like is hard to say at this moment, but several implementors already have some working prototypes, so the list of possibilities is getting pretty narrow already.

Another such need is "academic acceptance". The behavior of IF, ELSE and $TEST is an eyesore to many people, both inside and outside of the M[UMPS] world. Of course, this behavior is well defined, and all M[UMPS] programmers have learned to live with it, to love it and to hate it. We don't think that we will ever eradicate $TEST and its complexities completely out of the language, but do think that we will see viable alternatives that will allow new programmers to use the techniques and strategies that schools teach currently.

One of the topics discussed in our Commentary is a lack of information about the programming language M in some electronic encyclopedias. By adding an entry about this programming not only will these companies further increase the value of their product, but they will be doing justice to a programming language that merits a place within them.

Irrespective if you're new to M or someone who already uses this programming language, we ask you to spare a few minutes and send the sample letter to the three companies listed in the Commentary. We can only make them aware of the lack in their product if you, like many others send in this letter.