Difference between revisions of "MUMPS Overview"
(Added glossary link to Application~) |
DavidWhitten (talk | contribs) |
||
(6 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
MUMPS is a general purpose ANSI and ISO standard computer language which is a key component of VistA systems. As with VistA, there is considerable history. | MUMPS is a general purpose ANSI and ISO standard computer language which is a key component of VistA systems. As with VistA, there is considerable history. | ||
− | MUMPS is the middle | + | MUMPS is a layer in the middle of the whole [[VistA structural stack]]. |
+ | == Structure of VistA == | ||
+ | === The Server Structure of VistA === | ||
+ | Structural components of most VistA implementations depends on a server machine that includes in its execution stack stack- | ||
+ | # computer hardware running as a server - | ||
+ | #: from PC's to much larger CPUs | ||
+ | #: the VA ran many DEC(now HP) VAX before 2010 | ||
+ | #: the VA converted to Linux PCs | ||
+ | #: Many non-VA VistA systems run on {{g|Linux}} either using {{Cache}} or GT.M or YottaDB software Stacks | ||
+ | # An Operation system- Linux or Windows or DEC/HP VMS | ||
+ | # MUMPS/M System - Cache' or GT.M are the usual | ||
+ | # VA Kernel (FileMan Sub component) - standardizes communications betwen OS and FileMan and MUMPS VistA Apps | ||
+ | #: VA FileMan is Software written in MUMPS which adds a higher level DataBase Manager than the inherent database function of MUMPS (known in MUMPS as Globals) | ||
+ | #: VA FileMan has features analogous to SQL with many maintenance features, data dictionaries of {{g|Files}}(a superset of SQL Tables) and fields defined within those Files. It supports powerful cross referencing of Files, complex relationships between Files. | ||
+ | It adds support for defined {{g|data types}}, control of data entry and encoding and decoding formats for output. | ||
+ | #: VistA {{g|Application}}s, written in MUMPS with heavy dependence upon FileMan for the structure and design framework and includes many modules. | ||
+ | ## The core modules handle structures/Files for patient identification(ADT or Registration) and visits and Files for various actors- physicians, nurses, clerks, administrators, etc. | ||
+ | ## Modules stacked upon the Core manage many specific medical functions- eg. medications, notes, insurance claims, radiology. | ||
− | The | + | === The Client structure of VistA === |
− | + | implemented with a combination of technologies. | |
− | + | ==== CPRS ==== | |
− | + | # {{g|CPRS}} is the main GUI interface running on a client PC and Windows OS. | |
− | + | #: CPRS communicates over a standard LAN or Internet TCP/IP connection to the VistA Server. | |
− | + | # Client communication to a Server | |
− | + | #: The Server end is managed by a VistA Module called the RPC Broker which connects the clients to the FileMan VistA data. | |
− | + | #: {{g|CPRS}} as it runs on the client is a special {{g|Application}} written in Delphi. | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | ==== Other structural components of VistA ==== | |
+ | to use standard Browsers instead of {{g|CPRS}} to provide the User GUI interface via the Browser. | ||
− | + | ==== Text Interface ==== | |
+ | The oldest components of VistA and FileMan use a {{g|roll and scroll}} interface with a client terminal emulator connecting to the server securely over TCP/IP. One example of this is putty.exe running on an MS Windows OS. | ||
− | + | === What is a Variable === | |
+ | There are four kinds of variables in MUMPS or [[Cache Object Script]]. | ||
+ | # local variables (lvns) usually just called "locals" | ||
+ | # global variables (gvns) usually just called "globals" | ||
+ | # intrinsic variables (isvs) are usually referred to specifically, but rarely referred to as a group. | ||
+ | # extrinsic variables (no argument calls to tags in MUMPS routines) | ||
+ | # Some people refer to "glocal" variables, for variables that have the {{$JOB}} intrinsic variable as a subscript | ||
+ | # Structured System variables (ssvns) are usually referred to specifically, but rarely referred to as a group. | ||
+ | ==== Common to all variables ==== | ||
+ | * Their names are a shortcut to the value stored there. | ||
+ | * Their value is a string of characters | ||
+ | |||
+ | ==== local variables ==== | ||
+ | * Their name does NOT start with a caret ("^"). | ||
+ | * Their name DOES start with either a percent character ('%') or an alphabetic character | ||
+ | * Their name after the first character, has any number of characters, either alphabetic or numeric. | ||
+ | * Their name is case-SENSITIVE. | ||
+ | *: The local variable named "A" and the local variable named "a" are distinct. | ||
+ | * All local variables names can be followed by a parenthetized list of string valued subscripts. | ||
+ | *: some local variable names followed by subscripts have no value. | ||
+ | *: some local variable names followed by subscripts have a string value. | ||
+ | * Their names are only visible inside a single JOB. | ||
+ | * Their names can be hidden with the NEW command | ||
+ | *: the QUIT command on the same level as the NEW command erases the new name and unhides the previous name with its values. | ||
+ | * local variable names can be passed with a dot (".") prefixed when being called as an argument to an extrinsic routine. | ||
+ | *: local variable names followed by a parenthetized list of string valued subscripts can NOT be prefixed by a dot "." and passed as an argument to a subroutine call. | ||
+ | * The $DATA and $ORDER and $QUERY and $NAME intrinsic functions can be used with local variable names. | ||
+ | ==== global variables ==== | ||
+ | |||
+ | * Their name DOES start with one caret ("^"). | ||
+ | * Their name does have as the second character either a percent character ('%') or an alphabetic character | ||
+ | * Their name after the second character, has any number of characters, either alphabetic or numeric. | ||
+ | * Their name is case-SENSITIVE. | ||
+ | *: The global variable named "^A" and the global variable named "^a" are distinct. | ||
+ | * Global variables (and their values) are persistent and always available after being SET unless KILLed | ||
+ | * Global variables (and their values) are shared. Any JOB running on a MUMPS system can access them. | ||
+ | * Global variable names whether with a parenthetized list of string valued subscripts or not, may not be prefixed by a dot (".") and passed as an argument to a subroutine call. | ||
+ | * The $DATA and $ORDER and $QUERY and $NAME intrinsic functions can be used with global variable names. | ||
+ | |||
+ | ==== intrinsic variables ==== | ||
+ | * Their name DOES start with one dollar sign ("$"). | ||
+ | * Their name does have as the second and later characters an abbreviation only from a select list in the MUMPS Standard | ||
+ | * Their name after the abbreviation consists solely of the full name as referenced on the select list in the MUMPS Standard | ||
+ | * Their name is case-INsensitive. | ||
+ | *: The intrinsic variable named "$I" is the same intrinsic variable named as "$i". | ||
+ | * Some intrinsic variables are the limited to a particular JOB, such as $PRINCIPAL or $JOB | ||
+ | * Some intrinsic variables are common to all JOBs, such as $SYSTEM | ||
+ | * Intrinsic variables may NOT be followed by a parenthetized list of string values. | ||
+ | *: If a name starts with the "$" character and is followed by a parenthetized list of string values, it is NOT an Intrinsic Variable, it is an Intrinsic Function. | ||
+ | |||
+ | ==== extrinsic variables ==== | ||
+ | * An extrinsic name DOES start with two dollar signs ("$$"). | ||
+ | * Their name is case-SENSITIVE. | ||
+ | *: The intrinsic variable named "$$A" and the intrinsic variable named "$$a" are distinct. | ||
+ | * after the "$$" prefix, an extrinsic variable has an entry reference. | ||
+ | * An entry reference may have a label or tag of a routine as the third and later characters | ||
+ | *: The tag or label is an existing tag or label in an existing routine. | ||
+ | *:: The tag name has as a first character either the percent ('%') character or an alphabetic character or a numeric character. | ||
+ | *::: if there is any character after the second character, it will be any number of characters, either an alphabetic or numeric. | ||
+ | *: after the tag there MAY be a caret ("^") followed by a routine name. | ||
+ | *:: The routine name has as a first character either a percent ('%') character or an alphabetic character | ||
+ | *::: after the second character, has any number of characters, either alphabetic or numeric. | ||
+ | *: If a name starts with the "$$" character and is followed by a parenthetized list of string values, it is NOT an Extrinsic Variable, it is an Extrinsic Function. | ||
+ | |||
+ | ==== glocal variables ==== | ||
+ | * A Glocal variable name is case-SENSITIVE, in common with all global variable names. | ||
+ | * Glocal variables are global variables that have a $JOB as a subscript | ||
+ | * Glocal variables are are persistent and always available after being SET unless KILLed | ||
+ | * Glocal variables (and their values) are shared. Any job running on a MUMPS system can access them. | ||
+ | * The $DATA and $ORDER and $QUERY and $NAME intrinsic functions can be used with glocal variable names. | ||
+ | |||
+ | ==== Structured System variables ==== | ||
+ | * Their name DOES start with the caret ("^") followed by a dollar sign ("$") ie: the prefix is "^$" | ||
+ | * Their name does have as the second and later characters an abbreviation only from a select list in the MUMPS Standard | ||
+ | * Their name after the abbreviation consists solely of the full name as referenced on the select list in the MUMPS Standard | ||
+ | * Their name is case-INsensitive. | ||
+ | *: The intrinsic variable named "^$r" is the same structured system variable named as "^$r". | ||
=== Implementations and Vendors === | === Implementations and Vendors === | ||
− | It is important for new people to know the difference between the language and the implementation of the language. Vendors sell implementations of MUMPS. In the process, they are allowed to add commands, functions, and special variables to their implementation of the language. This does not increase what is in the language, but simply in their product. | + | It is important for new people to know the difference between the language and the implementation of the language. The language itself is an agreed upon way of interacting with the computer, with descriptions of what the language will do using certain commnds. Vendors sell programs which are implementations of MUMPS. In the process, they are allowed to add commands, functions, and special variables to their implementation of the language. This does not increase what is in the language, but simply in their product. |
Currently there are several active Vendors of MUMPS, and MUMPS-like languages. | Currently there are several active Vendors of MUMPS, and MUMPS-like languages. | ||
Line 37: | Line 127: | ||
! Vendor | ! Vendor | ||
! Implementation | ! Implementation | ||
+ | | Documentation<br>website | ||
|- | |- | ||
| Intersystems | | Intersystems | ||
Line 43: | Line 134: | ||
| Fidelity | | Fidelity | ||
| GT.M | | GT.M | ||
+ | |- | ||
+ | | YottaDB | ||
+ | | YottaDB | ||
|- | |- | ||
|} | |} |
Latest revision as of 16:47, 10 February 2020
MUMPS is a general purpose ANSI and ISO standard computer language which is a key component of VistA systems. As with VistA, there is considerable history.
MUMPS is a layer in the middle of the whole VistA structural stack.
Contents
Structure of VistA
The Server Structure of VistA
Structural components of most VistA implementations depends on a server machine that includes in its execution stack stack-
- computer hardware running as a server -
- from PC's to much larger CPUs
- the VA ran many DEC(now HP) VAX before 2010
- the VA converted to Linux PCs
- Many non-VA VistA systems run on Linux either using Template:Cache or GT.M or YottaDB software Stacks
- An Operation system- Linux or Windows or DEC/HP VMS
- MUMPS/M System - Cache' or GT.M are the usual
- VA Kernel (FileMan Sub component) - standardizes communications betwen OS and FileMan and MUMPS VistA Apps
- VA FileMan is Software written in MUMPS which adds a higher level DataBase Manager than the inherent database function of MUMPS (known in MUMPS as Globals)
- VA FileMan has features analogous to SQL with many maintenance features, data dictionaries of Files(a superset of SQL Tables) and fields defined within those Files. It supports powerful cross referencing of Files, complex relationships between Files.
It adds support for defined data types, control of data entry and encoding and decoding formats for output.
- VistA Applications, written in MUMPS with heavy dependence upon FileMan for the structure and design framework and includes many modules.
- The core modules handle structures/Files for patient identification(ADT or Registration) and visits and Files for various actors- physicians, nurses, clerks, administrators, etc.
- Modules stacked upon the Core manage many specific medical functions- eg. medications, notes, insurance claims, radiology.
The Client structure of VistA
implemented with a combination of technologies.
CPRS
- CPRS is the main GUI interface running on a client PC and Windows OS.
- CPRS communicates over a standard LAN or Internet TCP/IP connection to the VistA Server.
- Client communication to a Server
- The Server end is managed by a VistA Module called the RPC Broker which connects the clients to the FileMan VistA data.
- CPRS as it runs on the client is a special Application written in Delphi.
Other structural components of VistA
to use standard Browsers instead of CPRS to provide the User GUI interface via the Browser.
Text Interface
The oldest components of VistA and FileMan use a roll and scroll interface with a client terminal emulator connecting to the server securely over TCP/IP. One example of this is putty.exe running on an MS Windows OS.
What is a Variable
There are four kinds of variables in MUMPS or Cache Object Script.
- local variables (lvns) usually just called "locals"
- global variables (gvns) usually just called "globals"
- intrinsic variables (isvs) are usually referred to specifically, but rarely referred to as a group.
- extrinsic variables (no argument calls to tags in MUMPS routines)
- Some people refer to "glocal" variables, for variables that have the Template:$JOB intrinsic variable as a subscript
- Structured System variables (ssvns) are usually referred to specifically, but rarely referred to as a group.
Common to all variables
- Their names are a shortcut to the value stored there.
- Their value is a string of characters
local variables
- Their name does NOT start with a caret ("^").
- Their name DOES start with either a percent character ('%') or an alphabetic character
- Their name after the first character, has any number of characters, either alphabetic or numeric.
- Their name is case-SENSITIVE.
- The local variable named "A" and the local variable named "a" are distinct.
- All local variables names can be followed by a parenthetized list of string valued subscripts.
- some local variable names followed by subscripts have no value.
- some local variable names followed by subscripts have a string value.
- Their names are only visible inside a single JOB.
- Their names can be hidden with the NEW command
- the QUIT command on the same level as the NEW command erases the new name and unhides the previous name with its values.
- local variable names can be passed with a dot (".") prefixed when being called as an argument to an extrinsic routine.
- local variable names followed by a parenthetized list of string valued subscripts can NOT be prefixed by a dot "." and passed as an argument to a subroutine call.
- The $DATA and $ORDER and $QUERY and $NAME intrinsic functions can be used with local variable names.
global variables
- Their name DOES start with one caret ("^").
- Their name does have as the second character either a percent character ('%') or an alphabetic character
- Their name after the second character, has any number of characters, either alphabetic or numeric.
- Their name is case-SENSITIVE.
- The global variable named "^A" and the global variable named "^a" are distinct.
- Global variables (and their values) are persistent and always available after being SET unless KILLed
- Global variables (and their values) are shared. Any JOB running on a MUMPS system can access them.
- Global variable names whether with a parenthetized list of string valued subscripts or not, may not be prefixed by a dot (".") and passed as an argument to a subroutine call.
- The $DATA and $ORDER and $QUERY and $NAME intrinsic functions can be used with global variable names.
intrinsic variables
- Their name DOES start with one dollar sign ("$").
- Their name does have as the second and later characters an abbreviation only from a select list in the MUMPS Standard
- Their name after the abbreviation consists solely of the full name as referenced on the select list in the MUMPS Standard
- Their name is case-INsensitive.
- The intrinsic variable named "$I" is the same intrinsic variable named as "$i".
- Some intrinsic variables are the limited to a particular JOB, such as $PRINCIPAL or $JOB
- Some intrinsic variables are common to all JOBs, such as $SYSTEM
- Intrinsic variables may NOT be followed by a parenthetized list of string values.
- If a name starts with the "$" character and is followed by a parenthetized list of string values, it is NOT an Intrinsic Variable, it is an Intrinsic Function.
extrinsic variables
- An extrinsic name DOES start with two dollar signs ("$$").
- Their name is case-SENSITIVE.
- The intrinsic variable named "$$A" and the intrinsic variable named "$$a" are distinct.
- after the "$$" prefix, an extrinsic variable has an entry reference.
- An entry reference may have a label or tag of a routine as the third and later characters
- The tag or label is an existing tag or label in an existing routine.
- The tag name has as a first character either the percent ('%') character or an alphabetic character or a numeric character.
- if there is any character after the second character, it will be any number of characters, either an alphabetic or numeric.
- The tag name has as a first character either the percent ('%') character or an alphabetic character or a numeric character.
- after the tag there MAY be a caret ("^") followed by a routine name.
- The routine name has as a first character either a percent ('%') character or an alphabetic character
- after the second character, has any number of characters, either alphabetic or numeric.
- The routine name has as a first character either a percent ('%') character or an alphabetic character
- If a name starts with the "$$" character and is followed by a parenthetized list of string values, it is NOT an Extrinsic Variable, it is an Extrinsic Function.
- The tag or label is an existing tag or label in an existing routine.
glocal variables
- A Glocal variable name is case-SENSITIVE, in common with all global variable names.
- Glocal variables are global variables that have a $JOB as a subscript
- Glocal variables are are persistent and always available after being SET unless KILLed
- Glocal variables (and their values) are shared. Any job running on a MUMPS system can access them.
- The $DATA and $ORDER and $QUERY and $NAME intrinsic functions can be used with glocal variable names.
Structured System variables
- Their name DOES start with the caret ("^") followed by a dollar sign ("$") ie: the prefix is "^$"
- Their name does have as the second and later characters an abbreviation only from a select list in the MUMPS Standard
- Their name after the abbreviation consists solely of the full name as referenced on the select list in the MUMPS Standard
- Their name is case-INsensitive.
- The intrinsic variable named "^$r" is the same structured system variable named as "^$r".
Implementations and Vendors
It is important for new people to know the difference between the language and the implementation of the language. The language itself is an agreed upon way of interacting with the computer, with descriptions of what the language will do using certain commnds. Vendors sell programs which are implementations of MUMPS. In the process, they are allowed to add commands, functions, and special variables to their implementation of the language. This does not increase what is in the language, but simply in their product.
Currently there are several active Vendors of MUMPS, and MUMPS-like languages.
A partial list includes:
Vendor | Implementation | Documentation website |
---|---|---|
Intersystems | Caché | |
Fidelity | GT.M | |
YottaDB | YottaDB |
- Ed de Moel has a good description of MUMPS language elements in his MUMPS By Example page.
Also, more here: M/Mumps Language Issues
If we think we need more details, we should add them here.