Introduced in the 1977 ANSI M[UMPS] language standard.
Clarification (no change intended) in a future ANSI M[UMPS] language standard:
Any keywords in the argument of the command are processed in strict left-to-right order. When multiple equivalent parameters are encountered, the last occurrence processed will define the action(s) to be taken.
OPEN VDU,PRINT
FOR I=1:1:END FOR DEV=VDU,PRINT USE DEV
WRITE !,X(I)
CLOSE VDU,PRINT
Print the same text on two devices.
OPEN DEVICE::50 ELSE WRITE "Can't
open..." QUIT
Attempt to open the device. If the device does not become
available within the time-out period (50 seconds), stop trying
and set the value of $TEST to false.
Addition in the 1995 ANSI M[UMPS] language standard.
OPEN DEVICE:::"X3.64"
USE DEVICE::"X3.64"
Open a device with the mnemonicspace "X3.64" (VT-
100 compatible terminal).
The most common functions in ANSI X3.64 are itemized in X3.64 description.
OPEN DEVICE::10:("X3.64","GKS")
This command opens a device and specified both the
mnemonicspaces X3.64 and GKS. It also specifies a time-out
of 10 seconds. X3.64 will be the initial mnemonicspace for
the device; GKS may be selected in subsequent USE
commands, and X3.64 may be re-selected. No other mnemonicspaces
may be selected in subsequent USE commands.
Additions in a future ANSI M[UMPS] language standard.
More mnemonicspaces are becoming available.
The ability to specify "user-defined" mnemonicspaces is added. It will be possible to specify to an implementation to use entries in a specific routine (let's call it USER for the purpose of this discussion) for the processing of the commands OPEN, USE and CLOSE and the various controlmnemonics for specific combinations of device and mnemonicspace.
When this feature is active, the controlmnemonic /ABC(P1,P2) will be executed as DO ABC^USER(P1,P2), and the command USE device:(PARAM1:KEY2=VALUE2) will be executed as:
DO . NEW X,Y . SET (X,Y)=2 ; Number of deviceparameters . SET X(1)="PARAM1" ; First deviceparameter . SET X(2)="KEY2",Y(2)=VALUE2 . DO %USE^USER(device,.X,.Y,"") . QUIT
The name of a device may contain an environment specification
USE |"LONDON"|MTA47
A time-out for output operations may be specified. In order for this capability to be available, the current device must have established a mnemonicspace that supports this feature.
Use device:(OUTPUTTIMEOUT=duration)
will establish a time-out period of duration seconds. If
any subsequent output-producing argument of a READ or
WRITE command fails to complete execution within this
time-out period, this condition will be visible in two fashions:
If the value of duration in the example above would not be greater than zero, no time-out would apply for the device in question.
The ability to specify an "output time-out" is added. An output time-out is specified as a device parameter in an OPEN or USE command.
OPEN "TTY2":OUTPUTTIMEOUT=5:"X3.64"
Assuming that the implementation allows for the
deviceparameter OUTPUTTIMEOUT in the class
library called "X3.64" (VT-100 compatible devices), an
error with code M100 will occur when an attempt is made
to output data to the device called "TTY2", and it is
not possible to produce this output within 5 seconds.
Until external action has cleared this error condition, the value of ^$D[EVICE]("TTY2","OUTSTALLED") will have the value 1 (true).
USE "TTY2":OUTPUTTIMEOUT=0
will cancel the recognition of output time-out conditions, and
will cause the system to wait until output to the device in
question has completed.
The addition of a binding to TCP/IP socket devices includes a number of new deviceparameters.
Below, a number of sample programs are shown that could be used as clients and servers in a network of programs that communicate through TCP/IP sockets.
; connect to any server providing the service SET timeout=10 OPEN dev:(connect="myservice"):timeout:"SOCKET" IF '$TEST WRITE !,"Unable to connect to server" QUIT USE dev ;==> WRITE/READ dialogue with server ... CLOSE dev QUIT ; restrict the search to TCP/IP servers OPEN dev:(connect="myservice:IP:TCP")::"SOCKET" IF '$TEST WRITE !,"Unable to connect to server" QUIT SET sockindx=^$DEVICE(dev,"SOCKETINDEX") SET address=^$DEVICE(dev,sockindx,"REMOTEADDRESS") USE $PRINCIPAL WRITE !,"Connected to server at ",address USE dev ;==> WRITE/READ dialogue with server ... CLOSE dev QUIT
or
; connect to a specific server and port OPEN dev:(connect="128.200.1.5:IP:TCP:2001")::"SOCKET" USE dev ;==> WRITE/READ dialogue with server ... CLOSE dev QUIT
SET timeout=10 ; obtain a socket OPEN dev:(listen=":IP:TCP:2001"):timeout:"SOCKET" IF '$TEST WRITE !,"Unable to open server port" QUIT ; establish a queue depth of 3 USE dev WRITE /listen(3) ; wait for a client connection FOR USE dev WRITE /wait(timeout) QUIT:$DEVICE IF $KEY'="" d . ;==> READ/WRITE dialogue with client ... . SET sockindx=^$DEVICE(dev,"SOCKETINDEX") . SET sockhndl=^$DEVICE(dev,sockindx,"SOCKETHANDLE") . ; close current device . CLOSE dev:(socket=sockhndl) CLOSE dev QUIT
SET timeout=10 ; obtain a socket OPEN dev:(listen=":IP:TCP:2001"):timeout:"SOCKET" IF '$TEST WRITE !,"Unable to open server port" QUIT ; establish a queue depth of 3 USE dev WRITE /listen(3) ; wait for a client connection FOR USE dev WRITE /wait(timeout) QUIT:$DEVICE IF $KEY'="" d . SET sockindx=^$DEVICE(dev,"SOCKETINDEX") . SET sockhndl=^$DEVICE(dev,sockindx,"SOCKETHANDLE") . USE dev:(detach=sockhndl) . JOB server^srv(sockhndl) CLOSE dev QUIT
In this example, the routine ^srv could look like
... server(sockhndl) ; ... OPEN dev:(attach=sockhndl)::"SOCKET" USE dev ;==> READ/WRITE dialogue with client CLOSE dev QUIT
SET timeout=10 OPEN dev:::"SOCKET" ; acquire M[UMPS] device USE dev:(listen=":IP:TCP:2001") ; Establish TCP protocol IF $DEVICE USE $PRINCIPAL WRITE !,"Unable to listen for TCP connections" CLOSE dev QUIT SET tcpindx=^$DEVICE(dev,"SOCKETINDEX") SET tcphndl=^$DEVICE(dev,tcpindx,"SOCKETHANDLE") USE dev:(listen=":SPX:1025") ; Establish SPX protocol IF $DEVICE USE $PRINCIPAL WRITE !,"Unable to listen for SPX connections" CLOSE dev QUIT SET spxindx=^$DEVICE(dev,"SOCKETINDEX") SET spxhndl=^$DEVICE(dev,spxindx,"SOCKETHANDLE") ; wait for a client connection on either protocol FOR USE dev WRITE /wait(timeout) QUIT:$DEVICE IF $KEY'="" d . SET sockindx=^$DEVICE(dev,"SOCKETINDEX") . SET sockhndl=^$DEVICE(dev,sockindx,"SOCKETHANDLE") . IF $KEY'="CONNECT" USE $PRINCIPAL WRITE "Shouldn't happen" CLOSE dev:(socket=sockhndl) QUIT . USE dev:(detach=sockhndl) . JOB server^srv(sockhndl) ; Same server as above example CLOSE dev QUIT
For a program that parses a programming language, it is hard
to see the difference between:
...:(abc=xyz):...
and
...:(FILENAME="C:\temp\ABC.TMP"):...
In the former example, the text between the parentheses should be
an expression that happens to return a boolean value, whereas in
the latter example, the text between the parentheses could be a
"keyword equals value" combination that has a meaning in certain
mnemonicspaces.
In order to make it easier to indicate this difference, the
option to precede a devicekeyword with a slash has been
introduced. This would make the latter example look like:
...:(/FILENAME="C:\temp\ABC.TMP"):...
Examples with naked references:
USE DEVICE
SET ^ABC(1,2)="reset naked indicator"
; Naked indicator is now ^ABC(1,
USE ^(3,4)
; Naked indicator is now: ^ABC(1,3,
; Actual reference is: ^ABC(1,3,4)
USE DEVICE:PARAMETERS
SET ^ABC(1,2)="reset naked indicator"
; Naked indicator is now ^ABC(1,
USE ^(3,4):^(5,6)
; 1. fetch ^(3,4) = ^ABC(1,3,4)
; 2. fetch ^(5,6) = ^ABC(1,3,5,6)
; Naked indicator is now: ^ABC(1,3,5,
This document is © Ed de Moel, 1995-2005.
It is part of a book by Ed de Moel that is published under
the title "M[UMPS] by Example" (ISBN 0-918118-42-5).
Printed copies of the book are no longer available.
This document describes the various commands that are defined in the M[UMPS] language standard (ANSI X11.1, ISO 11756).
The information in this document is NOT authoritative
and subject to be modified at any moment.
Please consult the appropriate (draft) language standard for an
authoritative definition.
In this document, information is included that will
appear in
future standards.
The MDC cannot guarantee that these 'next'
standards will indeed appear.