Thank you for the question. It points out the fact that this section in the guide should be rewritten.
A little bit of history. The original MUMPS systems did not run on general purpose operating systems as they do now. They took over a machine and had there own OS built in. Everything was self contained.
The information given in the Associated Routines section is basically a relic of that era. It applies to all derivative systems of DSM-11 (physically or cloned) but not GT.M or MUMPSV1. The associated routine concept came from the fact that a partition had a routine buffer associated with it where the routine was loaded and executed. Routines were generally stored under the Global Module(the database). They could be loaded, edited and deleted using these Z commands within this buffer. It was the workplace for the programmer.
Since it was incredibly expensive to dedicate a machine to MUMPS only, MUMPS implementations migrated to general purpose OS's where other applications could be run. This gave the implementers choices as to how they wanted to handle creating, editing and executing a routine(s). Some stuck with the Z command approach. GT.M moved the routines to the file system to take advantage of the available editing tools, etc.
The bottom line is that routines are associated with a process through the execution process. Here's the explanation that applies to all MUMPS systems. What happens under the hood is irrelevant.
For any MUMPS process, you can execute a MUMPS program. The program consists of one or more MUMPS routines that call each other according to how the programmer designed them. Every program has as (at least) one entry point where execution starts. There are two modes in which execution can begin. First, when you are in programming mode, that is, when working at the ">" prompt. Second, in application mode where the program is executed from the actual MUMPS command line typically from a script.
Lets take the programming mode approach. To execute the routine, you would enter enter one of two commands:
> DO entryref or > GOTO entryref
without getting into the standard definitional formality of it, an entryref can be:
label [ +integer] [ ^routinename ] or simply ^routinename
That is:
DO ^PATENT where PATENT is the entry point routine. Execution will begin with the first line. or DO ENTER^PATENT where execution will begin at the line with the label ENTER. or DO ENTER+3^PATENT where execution will begin 3 lines beyond ENTER. This not recommended! or DO ENTER where it is assumed that the execution context is within the routine ^PATENT.
Before executing a routine, there is no routine associated with the process (or partition).When executed, the routine(s) are associated with the process. How this happens is implementation specific.
When executed in application mode, the entry point is specified on the MUMPS command line. An implicit DO is performed.
I hope this did not confuse you further. This seems like a perfect place for certain implementers to jump in.
_________________ Terry L. Wiechmann
|