MUMPS(ID:773/mum004)

Associative nested array language 

for Massachusetts [General Hospital] Utility Multi-Programming System

Greenes Pappalardo Marble Barnett Laboratory of Computer Science, Massachusetts General Hospital, Department of Medicine, Harvard Medical School 1969

A database-oriented OS and the language that goes with it. Used originally for medical records. Only data type is the character string. Persistent associative arrays.

A pretty simple command oriented, general purpose, procedural language with a fairly powerful string handling and multi-dimensional associative arrays and a very powerful built-in database.

Also used for managing data and communicating information between widely disparate units within an organization.  

An ANSI standard language since 1975


Structures:
Related languages
FILECOMP => MUMPS   Incorporated features of
STRINGCOMP => MUMPS   Augmentation of
MUMPS => ANS MUMPS   Standardisation
MUMPS => GNOSIS   Augmentation of
MUMPS => M   Renaming
MUMPS => Micro MUMPS   Subset
MUMPS => MIIS   Extension of
MUMPS => MQL   Compiled to
MUMPS => MRDB   embedded in
MUMPS => PLAIN   Extension of
MUMPS => UCD MUMPS   Implementation
References:
  • Greenes, R A; Pappalardo, A N; Marble, C W; Barnett, G O "Design and implementation of a clinical data management system" pp469-485 view details Extract:
    All application programs in this system are written in a high level interpretive language, a distant ancestor of which is JOSS,17 developed at the Rand Corporation in 1964. It has also been influenced by related languages such as TELCOMP and STRINGCOMP (developed by Bolt, Beranek and Newman, Inc.) and FILECOMP (specified by Medinet Division of General Electric Corp.). The MUMPS language allows the programmer to write a program, debug it, edit it, run it, and modify it concurrently at an interactive session at a console. The interpreter itself is a part of the executive system and is reentrant. The total space taken up by the time-sharing monitor, the input/output monitor, buffers, and reentrant interpreter is currently about 8,000 words of memory. The timesharing and I/O monitors have been specifically tailored to work efficiently with the interpreter. No attempt has been made to accommodate machine language user programs.


          in Computers and Biomedical Research 2(5) October 1969 view details
  • Greenes, R.A.; Papparaldo, A. N.; Marble, C. W. and Barnett, G. O. "A System for Clinical Data Management" pp287-297 view details Extract: Introduction
    Introduction

    The application of computers to the delivery of patient care is more a problem of "data management" than of "data processing." Although calculations and interpretation of data are often required, of much greater concern are the problems involved in the collection, communication, co-ordination, and presentation of information. As the process of delivery of medical care becomes increasingly complex, and involves increasing numbers of professional and non-professional personnel, responsibility for achieving the continuity and comprehensiveness that is essential to medical care seems to rest heavily on the development of appropriate computer-based data management systems. Such systems may further provide the primary feasible means by which quality control, auditing of the medical care process, and research into the diagnosis and treatment of disease can be achieved.

    These functions now are dependent on the use of the patient medical record, although they are fulfilled only to a minimal extent by it. Despite changing functions and increased demands on it, the medical record has changed little in form over the past century. Medical records possess no organization by diagnostic or therapeutic problem; notes relevant to a particular aspect of a patient's health may be accessed only by leafing through an entire volume. Terminology is not standard, data is not organized in well-defined formats, and notes are often illegible. As a consequence, the objective of using the computer for clinical data management is gaining considerable impetus.

    This paper will describe a number of criteria which the authors have found to be important in the design of systems for clinical data management, and a novel system which has been implemented to meet these requirements. The system to be described has been in operation for over a year. The extent to which it has proved useful has led the authors to believe that the criteria defined have general applicability for clinical data management. In the discussion to follow, the term "clinical data management system" refers to a timeshared computer system which supports on-line input, inquiry, and retrieval of clinical information from a central data base.
    Extract: High level programming language
    High level programming language

    One of the most time-consuming aspects of the development of information system programs involves the optimal interfacing of the system with its users in a particular application area. This requires much attention to human engineering, and repeated modification and revision of programs. The implementation of clinical data management applications has generally begun on relatively small computers. This has, in many cases, been necessary because development was a gradual process and started with limited objectives. Since high level languages have not typically been available on small machines, most programming has been done in machine language.

    The expense and inefficiency of writing, debugging, and modifying such programs have been serious obstacles to active research and development. A few clinical data management systems have used large general purpose computers which could provide much increased flexibility. However, the overhead of a large operating system on a major computer has often seemed excessive, because of the rather small amount of processing involved in many of these applications. Furthermore, because of the reliability requirements of a clinical data management system, modularity and duplication of hardware is desirable and often essential. Because of the expense entailed by hardware redundancy, this is typically feasible only with inexpensive, minimal equipment configurations.

    The MGH Utility Multi-Programming System (MUMPS) is a compact time-sharing system on a medium scale computer, dedicated to clinical data management applications. It is currently implemented on a PDP-9 (Digital Equipment Corporation) with 24,000 words of 18 bit memory and a Burroughs fixed head disk with three million characters of storage capacity. A set of terminal scanners is used to inter" face to remote devices: teletypes, buffered display scopes, line printers, card readers, and A/D converters. Both memory size and peripheral storage capacity can be expanded in the system. In the current version, 16 users may run simultaneously.

    All application programs in this system are written in a high-level interpretative language, a distant ancestor of which is JOSE, 1 developed at the Rand Corporation in 1964. It has also been influenced by related languages such as STRINGCOMP (developed by Bolt, Beranek and Newman, Inc.), and FILECOMP (specified by Medinet Division of General Electric Corp.). The MUMPS language allows the programmer to write a program, debug it, edit it, run it, and modify it concurrently during an interactive session at a console. The interpreter itself is a part of the executive system and is re-entrant. The total space taken up by the time-sharing monitor, the I/O monitor, buffers, and re-entrant interpreter is currently about 8,000 words of memory. The time-sharing and I/O monitors have been specifically tailored to work efficiently with the interpreter. No attempt has been made to accommodate machine language user programs. All active users are assigned partitions of core memory.

          in [AFIPS] Proceedings of the 1969 Fall Joint Computer Conference FJCC 35 view details
  • Sherertz, D. D., Wasserman, A. I., and Allison D. R. "Some Critical Comments Regarding MUMPS," Proc. 1974 MUMPS Users' Group Meeting, pp. 173-190 view details
          in [AFIPS] Proceedings of the 1969 Fall Joint Computer Conference FJCC 35 view details
  • Johnson, M. and Dayhoff, R. "MUMPS Primer." MDC 1/11, MUMPS Development Committee, 1975 view details
          in [AFIPS] Proceedings of the 1969 Fall Joint Computer Conference FJCC 35 view details
  • Wasserman, A. I., and Sherertz, D. D. "Implementation of the MUMPS Language Standard," MDC 2/3, MUMPS Development Committee, 1975 view details
          in [AFIPS] Proceedings of the 1969 Fall Joint Computer Conference FJCC 35 view details
  • Wasserman, A. I., Sherertz, D. D., and Rogerson, C. L. "MUMPS Globals and their Implementation." MDC 2/1, MUMPS Development Committee, 1975 view details
          in [AFIPS] Proceedings of the 1969 Fall Joint Computer Conference FJCC 35 view details
  • Wasserman, A. I., Sherertz, D. D., and Zears, R.W. "Design of a Multiprogramming System for the MUMPS Language," MDC 2/2, MUMPS Development Committee, 1975 view details
          in [AFIPS] Proceedings of the 1969 Fall Joint Computer Conference FJCC 35 view details
  • Bowie J, Barnett GO "MUMPS--an economical and efficient time-sharing system for information management" pp11-22 view details Abstract: MUMPS, the Massachusetts General Hospital Utility MultiProgramming System, is a compact time-sharing system for information management. This paper discusses the historical development of MUMPS and describes the basic modules found in its implementation. Detailed descriptions of the time-sharing executive, MUMPS language interpreter, input/output file system, and global data base are given, emphasizing their integration into an easy-to-use yet powerful system for application program design, development and maintenance.
          in Computers and Biomedical Research 6(1) April 1976 view details
  • Introduction to MUMPS-11 Language, DEC-11-MMLTA-C-D, Digital Equipment Corp., Maynard, Mass., 1976. view details
          in Computers and Biomedical Research 6(1) April 1976 view details
  • Wasserman, Anthony I. and Sherertz, David D. "A balanced view of MUMPS" pp16-26 view details Abstract: The MUMPS programming system was designed and developed to facilitate shared conversational access to a hierarchically-organized data base on a small computer. The MUMPS language, which has recently been standardized, contains features for numeric and string operations, along with a built-in file system called globals, embedded in a multiprogrammed execution environment. This paper gives an overview of the MUMPS language and a typical MUMPS system, then evaluates MUMPS in terms of modern notions of programming languages and software development. Despite the many attractive features for the development of interactive programs, MUMPS is seen to have a number of shortcomings when evaluated in this way. Among the problem areas are weakness of control structures, the ability to write self-modifying code, the incomprehensibility of most MUMPS programs, and the lack of support given by the language to notions of abstraction and modularity.

    External link: Online copy Extract: PLAIN and the lessons of MUMPS
    While the goals in the design of MUMPS meet the needs of a large number of computer users and potential users, the MUMPS language does not appear to realize those goals very well. The MUMPS language, with its highly cryptic lexical form, its constrained execution methodology, and its subtle syntactic and semantic rules is just not simple or straightforward enough to become the language of choice for the development of interactive programs. It does not offer enough to attract programmers away from their present languages or
    to make it worthwhile for organizations to invest large sums of money in retraining their programmers or converting their existing programs to MUMPS.
    MUMPS and the language standardization effort has been extremely valuable in defining the necessary capabilities of a programming language for the envisioned range of applications, but the MUMPS standard appears to be an interim step. While further steps could be taken to improve MUMPS, e.g., better control structures, it seems necessary to look beyond MUMPS and to design a new language oriented toward development of conversational programs.
    One such language being designed is named PLAIN (Programming LAnguage for INteraction) (Wasserman, 1976).
    PLAIN has many of the same design objectives as does MUMPS, in that it is intended to be usable on small-to-medium sized computers and to provide its users with conversational access to a data base. PLAIN will incorporate features comparable to the string-handling, pattern matching and data base management capabilities of MUMPS. Yet, it will also build upon modern concepts of data types, data independence, and program structure. PLAIN is rather eclectic in nature, and will draw upon features from a variety of languages and systems, although the strongest positive influences are from PASCAL. In short, the objectives of PLAIN are virtually identical to those of MUMPS, so that PLAIN can eventually serve as an alternative to MUMPS in addition to other possible uses.
    In conclusion, then, MUMPS has a loyal following because it fills a need that is not well met by other programming languages and systems. MUMPS systems can be acquired with relatively little capital expense and there is now considerable practical experience with its use within the MUMPS community. As with FORTRAN and BASIC, it represents an inviting target for criticism from computer scientists because of its highly pragmatic origins. The existence of an American standard for MUMPS and the investment in existing MUMPS software guarantees that MUMPS will continue to be used. Designers of new programming languages intended for the development of conversational programs would do well to study MUMPS in depth in order to make certain
    that new languages provide those capabilities for which MUMPS is best suited, while simultaneously attempting to overcome its inherent weaknesses.
          in [ACM SIGMINI/SIGPLAN] Proceedings of the ACM SIGMINI/SIGPLAN interface meeting on Programming systems in the small processor environment, March 04-06, 1976, New Orleans, Louisiana, United States view details
  • Imai T, Ogushi Y. "The optimal design of MUMPS global file" Med Inform 3(2) June 1978 pp145-59 view details Abstract: This paper presents the basic consideration of global file design on MUMPS language. The major goal of global design is to reduce the number of disc accesses made over the long-term use of a file. To attain this goal, the procedure for finding the global file which minimizes the average number of disc blocks accessed to obtain a data node is proposed. Furthermore, the total number of blocks in use with file design are demonstrated by simple examples.
          in [ACM SIGMINI/SIGPLAN] Proceedings of the ACM SIGMINI/SIGPLAN interface meeting on Programming systems in the small processor environment, March 04-06, 1976, New Orleans, Louisiana, United States view details
  • Noguchi H, Ogushi Y. "Computer-assisted system for a mycobacteria tuberculosis laboratory using MUMPS" Med Inform (3(4) Dec 1978 pp305-15 view details Abstract: A Laboratory Information System (LIS) has been developed and the main part of LIS is an on-line system with auto analysers. In April 1976, the Biochemistry Laboratory was computerized in Osaka Prefectural Habikino Hospital. This LIS uses a PDP 11/40 minicomputer system using MUMPS language. At present a Mycobacteria Tuberculosis Laboratory (MTL) is computerized using the same computer and MUMPS. In this laboratory, there is no auto analyser, so this computerization aims at saving on labour in paper work and increasing the reliability of test results. This paper shows that the computerization of MTL with no auto analyser can be effectively achieved using MUMPS.
          in [ACM SIGMINI/SIGPLAN] Proceedings of the ACM SIGMINI/SIGPLAN interface meeting on Programming systems in the small processor environment, March 04-06, 1976, New Orleans, Louisiana, United States view details
  • Ragan, Don P and Jones, Steven A "High-level language implementation of bit map inverted files" pp595-612 view details Abstract: A system of bit map inverted files has been implemented on an interactive interpreter computer system (MUMPS-PC). This has made search performance previously available only in machine language available to the high-level language programmer. The superior flexibility of the technique over conventional inverted files is shown for retrievals including inequalities. Increased storage overhead for the bit maps is 32% as opposed to 126% for conventional inverted files. Typical bit map searches are about 10 times faster than exhaustive file searching.

          in Computers and Biomedical Research 11(6) Dec 1978 view details
  • Ragan, Don P.; and Jones, Steven A. "High-level language implementation of bit map inverted files" Comput. Biomed. Res. 11, 6 (Dec. 1978), 595-612. view details Abstract: A system of bit map inverted files has been implemented on an interactive interpreter computer system (MUMPS-PC). This has made search performance previously available only in machine language available to the high-level language programmer. The superior flexibility of the technique over conventional inverted files is shown for retrievals including inequalities. Increased storage overhead for the bit maps is 32% as opposed to 126% for conventional inverted files. Typical bit map searches are about times faster than exhaustive file searching.

          in Computers and Biomedical Research 11(6) Dec 1978 view details
  • Sammet, Jean E "Roster of programming languages for 1976-77" pp56-85 view details
          in SIGPLAN Notices 13(11) Nov 1978 view details
  • Sandewall, Erik "Programming in an Interactive Environment: the Lisp Experience" pp35-71 view details Extract: Introduction
    INTRODUCTION
    Why do some programming systems have to be large and complex? In recent years there has been a trend towards simple designs in computer science research. The widespread revulsion against OS/360 in the academic community led to a quest for primitive concepts in operating systems and for very simple systems, which have been successfully developed by, for example, Brinch Hansen. Similarly, reaction against large and messy programming languages encouraged the development and adoption of languages that minimized the number of facilities and features, notably PASCAL. I believe that the great attraction of very simple programming languages such as BASIC and very simple database systems such as MUMPS in the world of practical computing are other examples of the same trend towards simplicity. Despite the above, the present paper is concerned with programming systems which by necessity have to be large and complex and which are very hard to structure well because we know so little about their design. Such systems are of interest for a combination of two reasons.

    First, there is a long list of things that one wants a programming system, particularly if it is interactive, to do for the programmer. ("Programming system", is used to mean an integrated piece of software which is used to support program development, including but not restricted to a compiler.) The reader can easily generate his own list of functions, but here are some possibilities:

  • Administration of program modules and of different generations of the same module (when errors are cor- rected and/or the scope of the program is extended);

  • Administration of test examples and their correct results (including side effects), so that the relevant tests are performed automatically or semiautomatically when sections of the pro gram are changed, and a report is made to the user if a discrepancy has been observed;

  • Administration of formal and informal documentation of program segments, and automatic generation of formal documentation from programs;
  • Interdialect translation;
  • Checking of compatibility between parts of programs;
  • Translation from general-purpose or specialized higher-level languages to the chosen base language ("preprocessors"), with appropriate support for compile-time and run-time error diagnostics in the base language, com ments, etc.;
  • Support for a given programming methodology. For example, if top-down programming is to be encouraged, then it is natural to let the interactive programming system maintain successive decomposition steps, and mutual references between an abstract step and its decomposi tion;
  • Support of the interactive session. For example, a history facility allows the user to refer back to previous commands to the system, edit them, and re-execute them. An undo facility  allows the programmer to back up and undo effects of previously performed incorrect commands, thus salvaging the data-structure environment that was interactively created during the interactive debugging session;
  • Specialized editing, performed with
  • an editor that understands at least the syntax of the chosen programming language, and which therefore allows the user to refer to natural entities in this language and to give fairly high-level instructions as to where additions to the program are to be inserted;
  • Optimizing programs which transform a program into an equivalent but more efficient one; Uniform insertion programs, which in a given program systematically insert additional statements, for example for producing trace printouts or for counting how often locations in the program are visited during execution.
  • Second, and this is the crucial point, if these functions are performed by separate and independent programs, a considerable duplication of effort will result. Syntax analysis has to be performed not only by a compiler or interpreter, but also by specialized editors, optimizing programs, uniform insertion programs, documentation generators (such as cross-indexers), and so on. Analysis of the relationships between modules (calling structure, data-flow structure, etc.) is needed for generation of documentation, administration of test examples, compatibility controls, and program optimization. Since the results of an execution count may be used to tell an optimizer where it should spend its efforts, programs for these two tasks should be able to communicate. Also, some of the above facilities, such as the undo facility, are only possible if they are integrated into the programming system. For these reasons, it is natural to try to integrate facilities such as the above into one coherent programming system, which is capable of performing them all in an economic and systematic fashion.

    I believe that the development of integrated, interactive programming systems, and the methodology for such systems, is the major research issue for programming systems and programming methodology today. It is significant for programming methodology, since every detailed recommendation on how to write programs is also a recommendation on how to design an interactive programming system that supports the methodology. In the area of research on programming systems, this is relatively unexplored territory waiting to be considered now that other problems such as compiler design for conventional languages seems to be fairly well understood. The task of designing interactive programming systems is hard because there is no way to avoid complexity in such systems. Because of all the dependencies between different parts of an interactive programming system, it is hard to break up the design into distinct subproblems.

    The only applicable research method is to accumulate experience by implementing a system, synthesize the experience, think for a while, and start over.

    Such systems have been built and used for the programming language LISP. I believe that the time is now ripe for a synthesis and discussion of the experience that has accumulated in this context. The present paper is intended to serve such a purpose.
          in [ACM] ACM Computing Surveys (CSUR) 10(1) March 1978 view details
  • Bowie J. "Methods of implementation of the MUMPS global data-base" Med Inform 4(3) Jul-Sep 1979 pp151-64 view details Abstract: Recent standardization of the MUMPS language (ANSI X11.1-1977) has resulted in increased investigations into its efficient implementation. Of particular concern is the method of implementation of the MUMPS hierarchical data file, or global. Two implementation techniques have found substantial support: a traditional technique utilizing linked physical blocks, and a more recent, self-indexing method based on the theory of balanced trees. Comparison of these methods shows that the balanced-tree implementation offers significant advantages in most MUMPS environments.
          in [ACM] ACM Computing Surveys (CSUR) 10(1) March 1978 view details
  • Hall DG "Experience of transferring an integrated hospital-administration system from a CODASYL data-base to a standard MUMPS file structure" pp93-103 view details Abstract: University College Hospital, a teaching hospital situated in Central London, has been using computers since 1964. Development of an integrated on-line hospital administration computer system was started in 1974. By mid 1977, the components of the system which had been implemented included a patient Master Index, Registration of new patients, Waiting Lists, Bed State, Out-patient Appointments, X-ray, Microbiology and Disease Index. The system was implemented using the Rank Xerox Data Systems (CODASYL based data-base management software, with the majority of applications running on a terminal network supported by transaction processing programs. The experience gained during three years of using such a system is reviewed, with particular emphasis on the ways in which the system matched up in practice to the expected benefits of data-base management facilities. In early 1977, it was decided to replace the Rank Xerox mainframe with a minicomputer which was considered to be a more cost-effective solution to the hospital's computing requirements. The machine selected a PDP 11-70, is running the Digital Equipment Corporation's implementation of Standard MUMPS, an interpretive language developed in a hospital environment, with its own file management software. The decisions which were made in redesigning the existing computer systems for the new machine are discussed. The progress made to date in the transfer of applications from the mainframe to the mini is reviewed, and some of the features of the software available on each machine and its suitability for the implementation of on-line data management and retrieval systems are compared.
          in Med Inform (Lond). April-June 1979 4(2) view details
  • Thompson M, Miller AC "Writing man-machine dialogues for a MUMPS system using the Application Controller Language (ACL)" Med Inform 4(2) April-June 1979 pp105-133 view details
          in Med Inform (Lond). April-June 1979 4(2) view details
  • Zimmerman J "Use of an interactive teaching program to teach medical workers, about MUMPS programming" Med Inform (Lond). 4(2) Apr-Jun 1979 pp127-32 view details Abstract: The MUMPS computer language is widely and increasingly used for medical applications. It is useful for medical students and others in the medical environment to have an understanding of such languages that can help them perform their jobs well. The author is therefore making available an interactive teaching program to instruct such people in the MUMPS computer language. Use of the teaching program is reported for 19 novice MUMPS programmers and compared with results for two experienced programmers. Free-text comments by the novices emphasize areas in which they had difficulty. There is a considerable variation in the mean time taken by the novices to answer the questions, and in the number of questions repeated because of erroneous answers. Most novices found the teaching program very helpful. A copy of the Standard MUMPS teaching program and the QUEST driver on which it is based has been sent to 24 institutions, including six in Europe and one in Japan, for further use.
          in Med Inform (Lond). April-June 1979 4(2) view details
  • Abel, P. review of Munnecke in view details Abstract: MUMPS (the Massachusetts General Hospital Multiprogramming System) was designed to "combine a simple yet high-level language with an easy-to-use database handling system" and "was implemented with a compact, time-sharing executive to make efficient use of all resources in a mini-computer environment." The comparison that Munnecke makes between the use of MUMPS and COBOL is reasonable because of the common use of COBOL (designed in 1959!), and because MUMPS could presumably replace COBOL in many installations. As Munnecke points out, there is a distinct difference between the two languages. COBOL is specifically a programming language that uses a variety of other supporting languages, such as a compiler, job control, linkage editor, database management system, and data communications monitor. MUMPS, however, is a "linguistically integrated data management system" that combines all of these functions.

    Munnecke compares the complexities of COBOL and its supporting languages to the relative simplicity of MUMPS; he cites a 3600- line COBOL program rewritten in MUMPS in 300 lines, the ease of locating errors, and the ease of changing a MUMPS program. The differences are dramatic, but the lack of methodology weakens credibility somewhat. (Munnecke does not make any claims about scientific rigor.)

    An installation concerned with programmer productivity could profitably investigate a system such as MUMPS. One could question the choice of the acronym--to me, MUMPS has a negative connotation. Since there are users in the non-medical arena, an acronym without a medical bias would be appropriate and would provide a more positive image. In all, however, MUMPS--dare I say it?-- is nothing to be sneezed at.
          in Med Inform (Lond). April-June 1979 4(2) view details
  • Arban, Hollis V. "Ans MUMPS in a multi-lingual operating system" pp93-96 view details Abstract: I have often wondered why the people of the world do not have one common language. Yet my international traveling experiences have shown me that I must accept a multi-lingual world and adjuster to it. Likewise, the computer industry has its reasons, deeply imbedded in the process of evolution, for being multi-lingual. As we move into the decade of the 80's, computer users are not going to find selection of software and hardware any easier than in the 70's. The trade-offs between developing your own custom software and adapting to available products may be even more complex. One thing is certain as we enter the 80's: the decrease in cost of hardware, such as micro systems and user terminals, is rapidly bringing computer power to the home and office for more routine use. As equipment becomes more commonly used, user interface software must adjust to meet the needs of: (a) less sophisticated computer users, and (b) sophisticated users who continually seek more power and versatility at their finger tips. It is into this environment that MUMPS takes its place, as though timely created for a key role as an interface language between the user and his machine.
          in Proceedings of the ACM 1980 annual conference January view details
  • Munneck, Thomas "A linguistic comparison of MUMPS and COBOL" pp723-730 view details
          in Proc. AFIPS 1980 NCC, vol. 49 view details
  • Brown, Frank M. "Design of a MUMPS Interpreter" view details
          in Software - Practice and Experience 11(12) December 1981 view details
  • Tan Watanabe, Tsuneharu Ohsawa, Hisao Kuma, Wakunaga Tsukada: "Micro MUMPS: An Interactive Database Language for Micro-Computers: view details
          in Software - Practice and Experience 11(12) December 1981 view details
  • Curtis AC "A comparison of LISP and MUMPS as implementation languages for knowledge-based systems" J Med Syst. 8(5) Oct 1984 pp399-406 view details Abstract: Major components of knowledge-based systems are summarized, along with the programming language features generally useful in their implementation. LISP and MUMPS are briefly described and compared as vehicles for building knowledge-based systems. The paper concludes with suggestions for extensions to MUMPS that might increase its usefulness in artificial intelligence applications without affecting the essential nature of the language.
          in Software - Practice and Experience 11(12) December 1981 view details
  • Duisterhout JS, Franken B, Witte F. "Structure and software tools of AIDA" Comput Methods Programs Biomed. 25(3) Nov-Dec 1987 pp259-73 view details Abstract: AIDA consists of a set of software tools to allow for fast development and easy-to-maintain Medical Information Systems. AIDA supports all aspects of such a system both during development and operation. It contains tools to build and maintain forms for interactive data entry and on-line input validation, a database management system including a data dictionary and a set of run-time routines for database access, and routines for querying the database and output formatting. Unlike an application generator, the user of AIDA may select parts of the tools to fulfill his needs and program other subsystems not developed with AIDA. The AIDA software uses as host language the ANSI-standard programming language MUMPS, an interpreted language embedded in an integrated database and programming environment. This greatly facilitates the portability of AIDA applications. The database facilities supported by AIDA are based on a relational data model. This data model is built on top of the MUMPS database, the so-called global structure. This relational model overcomes the restrictions of the global structure regarding string length. The global structure is especially powerful for sorting purposes. Using MUMPS as a host language allows the user an easy interface between user-defined data validation checks or other user-defined code and the AIDA tools. AIDA has been designed primarily for prototyping and for the construction of Medical Information Systems in a research environment which requires a flexible approach. The prototyping facility of AIDA operates terminal independent and is even to a great extent multi-lingual. Most of these features are table-driven; this allows on-line changes in the use of terminal type and language, but also causes overhead. AIDA has a set of optimizing tools by which it is possible to build a faster, but (of course) less flexible code from these table definitions. By separating the AIDA software in a source and a run-time version, one is able to write implementation-specific code which can be selected and loaded by a special source loader, being part of the AIDA software. This feature is also accessible for maintaining software on different sites and on different installations
          in Software - Practice and Experience 11(12) December 1981 view details
  • Duisterhout JS, Franken B. "MUMPS as a host language for AIDA" Comput Methods Programs Biomed. Nov-Dec 1987 25(3) pp349-63 view details Abstract: In this contribution, the main characteristics of MUMPS, the host language of AIDA, are briefly discussed. This is basically an introductory text for readers who had had no previous experience with MUMPS, on the programming side. After a short introduction, its history is summarized. Then the language itself is introduced and illustrated with examples; for the sake of brevity not all commands, functions and other features are discussed. In the next section, an introduction to MUMPS' stronghold is given: the database structure. Finally, we give the main reasons why we have chosen MUMPS as AIDA's host language. In the appendices, attention is given to the language standardization process, the visibility of MUMPS and its availability, sources of further information and the most important text books on MUMPS (in English).
          in Software - Practice and Experience 11(12) December 1981 view details
  • G. Octo Barnett, M.D. Judith L. Piggins, M.S.E.E. Gordon Moore, M.D. Ethan Foster, B.S. "The Use of Information Technology in an Experimental Curriculum at Harvard Medical School" ACM SIGBIO Newsletter archive 9(3) (September 1987) pp33-37 view details Abstract: It is obvious that very dramatic changes are occurring in medical practice: changes initiated by advances in biomedical knowledge, changes made possible by innovations in technology, and changes demanded by new patterns of practice and new forms of reimbursement. [...] The present graduate education of the physidan is poorly suited to prepare the medical student of today to become the physidan of the twenty-first century. The medical school curriculum must prepare medical students to learn throughout their professional lives rather than simply to master current informarion and techniques. A recent report from the Association of American Medical Colleges (the GPEP Report) I discusses many of these new forces and strongly recommends that medical schools undertake a fundamental reappraisal of how physicians are educated.
    Harvard Medical School has initiated a new curriculum - - called the "New Pathway" -- which involves a basic restructuring of medical education and a greater emphasis on problem solving and independent learning. (Figure 2) In September, 1985, the New Pathway program started with a group of 24 students selected from the entering class of 165 students. The 24 students will remain in this separate New Pathway curriculum for the total four years of medical school. In September, 1986, 38 new first:year students will begin the New Pathway program.
    The New- Pathway makes extensive use of active educational methods such as problem-solving and information management, self-paced leaming and small group discussions. In the New Pathway, there are few lectures; inswad there is more emphasis on the student assuming individual respomibility for his/her own education. One of the key dements of the New Pathway curriculum is the intemive use of information technology as a primary educational and infommtion management resource to assist the student in the mastery of the scientific basis of medicine, and in the development or problem-solving skills. This paper discusses the use of informarion technology in this experimental curriculum and describes several of the computer-based educational modules which have been developed.

    External link: Online copy bib:
    @article{39335,
    author = {G. O. Barnett and J. L. Piggins and G. Moore and G. O Foster},
    title = {The use of information technology in an experimental curriculum at Harvard Medical School},
    journal = {SIGBIO Newsl.},
    volume = {9},
    number = {3},
    year = {1987},
    issn = {0163-5697},
    pages = {33--37},
    doi = {http://doi.acm.org/10.1145/39330.39335},
    publisher = {ACM Press},
    }


          in ACM SIGBIO Newsletter archive 9(3) (September 1987) view details
  • van Ginneken AM, Smeulders AW, Jansen W. "Design of a diagnostic encyclopaedia using AIDA" Comput Methods Programs Biomed. 25(3) Nov-Dec 1987 pp339-47 view details Abstract: Diagnostic Encyclopaedia Workstation (DEW) is the name of a digital encyclopaedia constructed to contain reference knowledge with respect to the pathology of the ovary. Comparing DEW with the common sources of reference knowledge (i.e. books) leads to the following advantages of DEW: it contains more verbal knowledge, pictures and case histories, and it offers information adjusted to the needs of the user. Based on an analysis of the structure of this reference knowledge we have chosen AIDA to develop a relational database and we use a video-disc player to contain the pictorial part of the database. The system consists of a database input version and a read-only run version. The design of the database input version is discussed. Reference knowledge for ovary pathology requires 1-3 Mbytes of memory. At present 15% of this amount is available. The design of the run version is based on an analysis of which information must necessarily be specified to the system by the user to access a desired item of information. Finally, the use of AIDA in constructing DEW is evaluated.
          in ACM SIGBIO Newsletter archive 9(3) (September 1987) view details
  • Heffernan HG "Challenges for the MUMPS community" Comput Healthc. 1989 May;Spec No:20-1 view details
          in ACM SIGBIO Newsletter archive 9(3) (September 1987) view details
  • Lewkowicz, John M. The complete MUMPS: an introduction and reference manual for the MUMPS programming language Prentice-Hall, Inc. January 1989 view details
          in ACM SIGBIO Newsletter archive 9(3) (September 1987) view details
  • Mappes R, Wingo RA, Rousculp DE. "IBM and MUMPS: the first year. Interview by Ellen Pollock" Comput Healthc. 1989 May;Spec No:22-5 view details
          in ACM SIGBIO Newsletter archive 9(3) (September 1987) view details
  • Munnecke T "MUMPS: a key technology in a $1 billion system" Comput Healthc. 1989 May;Spec No:29-30, 32 view details
          in ACM SIGBIO Newsletter archive 9(3) (September 1987) view details
  • Pappalardo N. "The mind behind MUMPS. Interview by Eric Skjei" Comput Healthc. 1989 May;Spec No:16-8 view details
          in ACM SIGBIO Newsletter archive 9(3) (September 1987) view details
  • Schwarz V, Hohenberger P, Kohler CO, Schlag P. "Setting up a decision support system with decision tables." Methods Inf Med. 1989 Jul;28(3):126-32] view details Abstract: The aim of our study was to develop a decision support system using a conventional method which can be used as a shell for different applications. So it was necessary to find a method which allows separation of decision principles and decision algorithms. In addition, documentation of the patient records should be simplified. This could be attained by using the decision table technique and the programming language MUMPS. The general system developed was applied to the therapy decision for patients with liver metastases. The application system was clinically evaluated in a randomized group of patients. In 84% of the study group the therapy proposal of the system concurred with the therapy actually applied. Representation of knowledge in the form of tables is easily understandable by physicians. Since decision tables can be seen as a medium of communication between physician and system manager, knowledge acquisition is simplified.
          in ACM SIGBIO Newsletter archive 9(3) (September 1987) view details
  • Walters, Richard F. "ABCs of MUMPS: an introduction for novice and intermediate programmers" Digital Press Newton, MA, USA 1989 view details bib:
    @book{67602,
    author = {R. F. Walters},
    title = {ABCs of MUMPS: an introduction for novice and intermediate programmers},
    year = {1989},
    isbn = {0-13-000597-5},
    publisher = {Digital Press},
    }


          in ACM SIGBIO Newsletter archive 9(3) (September 1987) view details
  • "MUMPS Language Standard", ANS X11.1-1977, ASN X11-1990. MUMPS User's Group, Box 208, Bedford MA 01730. view details
          in ACM SIGBIO Newsletter archive 9(3) (September 1987) view details
  • Ragon T. "Opening new potential for MUMPS" Comput Healthc. 1991 Jun;Spec No:35-8 view details Abstract: In an interview with Computers in Healthcare, Terry Ragon, founder and president of InterSystems Corporation, says that as MUMPS-based technologies become further refined in the next few years, they will serve as platforms for additional technologies such as RDBMS and application generators. He also looks at the directions for the expanding international MUMPS community.
          in ACM SIGBIO Newsletter archive 9(3) (September 1987) view details
  • Russ DC "Western State Hospital: implementing a MUMPS-based PC network" Comput Healthc. 1991 Jun;Spec No:18-9, 22-3 view details Abstract: The past chairman of the MUMPS Users' Group and the MUMPS Development Committee, Richard Walters, traces the development of MUMPS from its inception through its subsequent fragmentation and eventual standardization. He also suggests what the future will look like for MUMPS-based technologies.
          in ACM SIGBIO Newsletter archive 9(3) (September 1987) view details
  • Schuller G. "An open, modular, distributed and redundant computer system for hospitals." Comput Healthc. 1991 Jun;Spec No:24-8, 31 view details Abstract: Based on his experience at the University of Wurzburg in Germany, Dr. Schuller shows how a successful MUMPS-based hospital information system can be developed, including goals and requirements, networking, software hierarchies, programming in MUMPS, medical applications, data security/privacy and international standards.
          in ACM SIGBIO Newsletter archive 9(3) (September 1987) view details
  • Walters RF "Twenty years later: where has MUMPS gone and how did it get there?" Comput Healthc. 1991 Jun;Spec No:14-6 view details Abstract: The past chairman of the MUMPS Users' Group and the MUMPS Development Committee, Richard Walters, traces the development of MUMPS from its inception through its subsequent fragmentation and eventual standardization. He also suggests what the future will look like for MUMPS-based technologies.
          in ACM SIGBIO Newsletter archive 9(3) (September 1987) view details
  • Library of Congress Subject Headings M85 view details
          in ACM SIGBIO Newsletter archive 9(3) (September 1987) view details
    Resources
    • Muups list
      MUMPS-L@UGA.BITNET
    • comp.lang.mumps
      "
    • Mumps/M home page
      external link
    • Student version ftp

      "
    • Usenet posting by Etienne Cherdlu

      I remember using TELCOMP back in 1969 (27 years ago). We used it, via a dial
      up line, on a PDP-7 (TELCOMP II) and later on a PDP-10 (TELCOMP III).


      I don't remember much about the machines that we used other than that we
      leased time from a company called Time Sharing Limited of Great Portland Street,
      London. I also have a note from that time about on-line storage charges. It cost
      30p (about 45 cents) per 640 byte block per month!


      The family resemblance between TELCOMP and M is just about recognizable
      especially if you were familiar with MUMPS-11. [refer code example above]


      Comparison with M:



      1. No variable declaration. No data typing (String support in TELCOMP III?)

      2. Sparse local arrays. No globals. File I/O was conventional, I think.

      3. For loop construct.

      4. TYPE command identical to MUMPS-11

      5. Part/Step numbering identical to MUMPS-11

      6. Form Input/Output feature was unique to TELCOMP.

      7. Do label+offset still exists in M today.


      external link