Difference between revisions of "MUMPS Overview"

From VistApedia
Jump to: navigation, search
 
(One intermediate revision by the same user 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 component of the whole VistA structural stack.
+
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 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
  
−
The structural components of most VistA implementations includes in its execution stack stack-
+
==== local variables ====
−
1. computer hardware running as a server -
+
* Their name does NOT start with a caret ("^").
−
      from PC's to much larger CPUs
+
* Their name DOES start with either a percent character ('%') or an alphabetic character
−
      the VA ran many DEC(now HP) VAX
+
* Their name after the first character, has any number of characters, either alphabetic or numeric.
−
      the VA converted to Linux PCs
+
* Their name is case-SENSITIVE.
−
      A PC may run {{g|Linux}} - GT.M Stacks
+
*: The local variable named "A" and the local variable named "a" are distinct.
−
2. An Operation system- Linux or Windows or DEC/HP VMS
+
* All local variables names can be followed by a parenthetized list of string valued subscripts.
−
3. MUMPS/M System  - Cache' or GT.M are the usual
+
*: some local variable names followed by subscripts have no value.  
−
4. VA Kernel (FileMan Sub component) - standardizes communications betwen OS and FileMan and MUMPS VistA Apps
+
*: some local variable names followed by subscripts have a string value.  
−
4. 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)
+
* Their names are only visible inside a single JOB.
−
  It 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.
+
* Their names can be hidden with the NEW command
−
  It adds support for defined {{g|data types}}, control of data entry and encoding and decoding formats for output.
+
*: the QUIT command on the same level as the NEW command erases the new name and unhides the previous name with its values.
−
5. VistA {{g|Application}}s, written in MUMPS with heavy dependence upon FileMan for the structure and design framework and includes many modules.
+
* local variable names can be passed with a dot (".") prefixed when being called as an argument to an extrinsic routine.
−
  5a. The core modules handle structures/Files for patient identification(ADT or Registration) and visits and Files for various actors- physicians, nurses, clerks, administrators, etc.
+
*: 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.
−
  5b. Modules stacked upon the Core manage many specific medical functions- eg. medications, notes, insurance claims, radiology.
+
* The $DATA and $ORDER and $QUERY and $NAME intrinsic functions can be used with local variable names.
 +
==== global variables ====
  
−
The Client Server structure of VistA is implemented with a combination of technologies. {{g|CPRS}} is the main GUI interface running on a client PC and Windows OS. It communicates over a standard LAN or Internet TCP/IP connection to the VistA 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 [[application~|Application]] written in Delphi.
+
* 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.
  
−
Other components of VistA are evolving to use standard Browsers instead of {{g|CPRS}} to provide the User GUI interface via the Browser.
+
==== 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.
  
−
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.
+
==== 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 ===

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.

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-

  1. 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
  2. An Operation system- Linux or Windows or DEC/HP VMS
  3. MUMPS/M System - Cache' or GT.M are the usual
  4. 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.
  1. VistA Applications, written in MUMPS with heavy dependence upon FileMan for the structure and design framework and includes many modules.
    1. The core modules handle structures/Files for patient identification(ADT or Registration) and visits and Files for various actors- physicians, nurses, clerks, administrators, etc.
    2. 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

  1. 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.
  2. 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.

  1. local variables (lvns) usually just called "locals"
  2. global variables (gvns) usually just called "globals"
  3. intrinsic variables (isvs) are usually referred to specifically, but rarely referred to as a group.
  4. extrinsic variables (no argument calls to tags in MUMPS routines)
  5. Some people refer to "glocal" variables, for variables that have the Template:$JOB intrinsic variable as a subscript
  6. 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

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:

MUMPS implementations
Vendor Implementation Documentation
website
Intersystems Caché
Fidelity GT.M
YottaDB YottaDB

Also, more here: M/Mumps Language Issues

If we think we need more details, we should add them here.

Retrieved from "https://vistapedia.com/index.php?title=MUMPS_Overview&oldid=18246"