It is currently Mon May 21, 2018 8:05 am

All times are UTC - 8 hours [ DST ]

Post new topic Reply to topic  [ 1 post ] 
Author Message
 Post subject: Unit 2 - Lesson 2: Structured Programming
PostPosted: Sat May 28, 2011 8:28 am 
User avatar

Joined: Wed Nov 17, 2010 8:37 am
Posts: 136
Real Name: Terry L. Wiechmann
Began Programming in MUMPS: 0- 0-1971
In the early days of the MUMPS language, structured programming [url]([/url]) was in its infancy as well. It evolved over time forcing the language developers to address the issues created by “non-structured” design. The language elements covered in this lesson are a result of that movement.

Unfortunately, during the time before adoption of structured programming techniques, large amounts of MUMPS code was written that can still be found in operational environments. As a programmer you may have the misfortune of encountering this code. Unfortunately, it is always held up as an example of why you should never use MUMPS. Clearly, this code should be refactored and rewritten. That is an organizational decision. However, the best way to overcome this criticism is to write code that is structured and easy to read (support). Hopefully, that is what this lesson will accomplish.
It's worth noting that the Object Oriented paradigm shift that occurred in the late 1990's was a natural evolution of structured programming. It to evolved under the banner of improving software quality. It, in fact, moved further away from a monolithic code structure and toward modeling the problem domain as objects that contain the code and data. One of the best books written on the subject mapped all the new features of object orientation to software quality issues. It is Object-Oriented Software Construction by Bertrand Meyer and is worth reading.


The structured programming techniques of this lesson should be complemented with readability and supportability conventions.

Opinion: I've always felt that a useful utility would be a translation parser for MUMPS. It takes a code body as input and parses it. The parsed code can then be manipulated in various ways. Within an editor for example. It could produce code that would conform to established conventions. But I digress...

Some conventions for this course should include:
  • One command per line where possible.
  • Names (command, functions, etc.) should be spelled out in full.
  • Variable names should be descriptive and conform to a particular format such as camel back.
  • Liberal commenting of code.

One Command per Line

“Back in the old days”, performance was the big issue. MUMPS systems were interpretive and machines were slow by today's standards. Consequently, there were a whole lot of digressions from good programming practices as a way of increasing the performance of a program. (BTW, my definition of a program is one or more routines that performs an application function (Patient Entry, etc.) Packing as many commands as you could on a line (typically without wrapping on a 80 character terminal) was one technique. It eliminated processor time needed to transfer between lines but created code that deviated from other mainstream languages.

Fortunately we have grown beyond that at this point. Strict interpreters have given way to p-code generation and full compilation, not to mention the incredible increases in computer performance.

One command per line makes the code much easier to read. Remember, it's not about you, it's about the person who inherits your code and has to read it. Been there, done that!

Fully Spelled Names

Concerning spelling of names, the MUMPS language standard specifies that a name must be spelled in full or abbreviated one or two characters according to individual name specifications. For example, The function $TEXT must contain all character (fully spelled) or specified as $T. You cannot specify it as $TE or $TEX. However, the function $TRANSLATE must be spelled fully or specified as $TR since it would conflict with $TEXT if only one character were specified.

In my view, all command, function, special variable and structured special variable names should be spelled out. However, it is tedious and can be argued against. This is where the Pretty Program or a smart editor would be a great service - let the programmer code efficiently and then let it pretty things up.
You will notice that code examples within the student guide flip flop between fully spelled names and single character names. I will try to standardize this as we go.

Descriptive Variable Names

MUMPS variable arrays have two different scopes. They are locally and globally scoped. What is a scope? The scope of a variable defines accessibility boundaries.

A local variable is confined to your processes environment. It is only accessible to the program that is executing within the context of the process. It has a life span from the time it is created (SET or READ command) until it is destroyed (KILL command) or the process terminates.

A global variable resides on the disk and are persistent, typically within global directory confined by some artificial environment (file directory, UCI, etc.). It resides there until explicitly killed (KILL command) by a program.

Use descriptive variable names so that a person can simply look at it and have an idea of what data it contains.

Commented Lines

Use comments liberally. In todays compiled environments, they are stripped and do not reside in object code. Some implementations let you pass commented lines to the object code. We will cover that when we get to the $TEXT function.

These are just a few conventions that should be part of a larger set. They will suffice for this course.

New Command

The NEW command is essential to writing structured code. The student guide gives you a simple explanation of the command. Look at your MUMPS implementations language guide for a more in depth explanation if you are interested (we will be covering the command in depth later on).

In a nutshell, its function is to hide (stack) variables and their values between routine or subroutine calls. The simple example in the guide illustrates this concept. The only problem with using the NEW command is it relies upon the programmer to remember to use it and use it correctly.


Create a routine called xxxNEWEX (where xxx is your prefix). Type in the Calling Routine code followed by the subroutine SUBRTN code. File the routine and execute it. Play with it by adding a new variable, etc.


The Editing and Executing Routines section back in Unit 1 covered the DO, GOTO and QUIT command. The DO command is used to make calls to subroutines within the same routine or to call a completely different routine. The QUIT command terminates that call and causes execution to return to the next command beyond the call DO command.

If parameters did not exist, values required by the called- subroutine or routine would have to be passed by setting the value to a variable name and not NEW it so it is available to the called context. Unfortunately, this practice appears in old code. It contributes to software support problems since that variable is no protected. It was (is) often a source for what is called an “undefined variable” error.


Create a new routine named xxxPAREX. Type in the code listed in the Parameter Passing Example section. Execute the routine as shown. Play around with the values in the actual list. Try leaving the parameters empty and see what happens.

Extrinsic Variables

Intrinsic Variables are variables defined within the MUMPS language standard. They are implemented by the MUMPS vendor. Extrinsic Variables are implemented by you the programmer. An Extrinsic Variable begins with $$ followed by an entryref. Extrinsic Variables do not take parameter. However, they must have an empty parameter list, that is, simply the left and right parenthesis () specified. An Extrinsic Variable always has a QUIT with an argument specified to return a value.


Create a routine and type in the code shown in the guide to return the current year. Execute the variable code.

When at the programming prompt, write $H (or $HOROLOG). $H keeps track of the current day and time with sequential numbers. Day is the first “,” piece and represents the number of days since midnight, December 31, 1841. Time is the second “,” piece and is the number of seconds since the last midnight.

Teaser: OK, looking at the expression $H\365.25+1841, if $H is substituted in, it would create an expression 62239,37114\ 365.25+1841?? Normal everyday arithmetic says this will not calculate. What do you think MUMPS does to calculate the year without an error”? Don't worry, we will get to this “strange math” in the next lesson.

Extrinsic Functions

An Extrinsic Function is just like an Extrinsic Variable only it permits parameters to be passed in.

Exercise 1

Create a routine and enter the example code given in the guide. Execute the code. Notice the SET command uses a post conditional. Change this to an equivalent IF command.

Exercise 2

Create a new routine using the Extrinsic Variable code in the previous section. Convert it to an Extrinsic Function where the any $H value can be passed in as a parameter. Do you have to pass in the time piece?

Structured Blocks

Structured Blocks is a major contributor to structured MUMPS programming. Prior to this feature blocks of exclusive code executed only by the line using it had to be put in a subroutine. This is due to the line length restraint. Even if there was no length restraint, it would make readability a problem. Consequently, standardizing structured blocks was a necessity for structured programming.

Go through the example given in the student guide. Notice that an argumentless DO command is used to access a block of code under it defined by a period in front of each line in the block. Also, notice that you can nest blocks.

Exercise 1

Create a routine and copy in the code from the example. Execute the code. Modify the routine to play around with structured blocks.

Exercise 2

Go back to the NEW command routine you created. Copy the contents into a new routine. Now, change the SUBRTN subroutine to a structured block of code within the main routine.

POWER Example

The POWER example is illustrative of the standardization process. When functions (or what ever) have to be written over and over, it's a good sign that it should probably be pushed down to the MUMPS implementation level. This has happened in numerous other places. $REVERSE comes to mind since I was involved in it while on the MDCC working in Europe. In many cases, the MUMPS implementor implements the functionality before the standardization process picked it up.

Review the contents of this lesson. It contains some really important concepts. These concepts have been covered at a high level. We will be revisiting many of them later on.

Next we will study the concept of an expression. This is where the “rubber meets the road” so to speak.

Terry L. Wiechmann

Offline Profile  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1 post ] 

All times are UTC - 8 hours [ DST ]

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Theme created