DM-1(ID:5333/dm:001)Data Manager 1Data Manager 1 Auerbach Related languages
References: In the past, computerized data files have been designed and programmed largely to meet the record keeping needs of the user. It has usually been painful, to say the least, to change such programs and file structures. Now the field is recognizing that more flexibility is essential. So "Data management" systems are being developed by which data files may be created or restructured much more easily than in the past, and which readily perform common file processing Mctions. Four such systems are analyzed in this paper: GE Integrated Data Store (IDS); Computer Command and Control Multi-List; Auerbach Data Manager-1 (DM-1); NAA-IBM Information Control System (ICS). in [AFIPS] Proceedings of the 1967 Spring Joint Computer Conference, April 18-20, Atlantic City, N. J. SJCC 30 view details Concept of Syntax-Directed Processing The problem of building a language translator can be partitioned into two parts. The first is concerned with the specification of the syntax of the source language and the actions to be taken upon recognition of each syntactic type. The second is concerned with an algorithm for simultaneuosly scanning the source language string and the syntax specification and producing an object language string. That the problem could be broken up in this way has been known for some time and has been extensively reported in the literature. [...]One of the theoretical results of partitioning the problem in this way is that the same scanning algorithm can be used with each of several syntax specifications for parsing and translating several languages. Although this has been theoretically understood and often mentioned in the literature of syntax-directed compiling, very little use has been made of multi-language translators in a system context. The ADAM system and the AUERBACH generalized data management system called DM-1 are two systems which have attempted to do this. The purpose of this paper is to discuss some of the possible modes of use of a syntax-directed processor, and the design and use of a particular syntax-directed language processor, called Inscan, which is part of DM-1. It is believed that Inscan is unique in that it offers a convenient user-oriented language for language and language processor specification. Our premise is that the route to optimal language interface with the users of a system (users at all levels, programmers, analysts, experimenters, and managers) is to provide a universal processor rather than a universal language (or even several universal languages). In Inscan, the syntax of the language to be processed, and the actions to be taken, are specified by the designer in a chart called an action graph. Inscan allows an experimental or adaptive approach to language development, and, furthermore, permits both interpretive and translational modes of operation. Processing Framework A syntax-directed language processor can be used in several modes within a given system context. Consider, for example, the language processing needs of a hypothetical user-interactive system which manages an on-going data base. Within this context there may be several types of user languages: (l) compiler language (2) macro-assembler language (3) command language (4) data description language (5) data language (6) job description language (7) data service language (8) on-line computational language It should be possible to perform a large part of the input stream scanning and analysis functions on these languages with basically the same, or similar, syntaxdirected scanners and analyzers. Yet an examination of the language processing contexts for most of the above languages shows that the roles of their processors are quite different. In some, such as the compiler, macroassembler and data language processors, the language processor behaves as a translator. This mode is illustrated in Figure 1. In others, such as the command and data service language processors, it must function in the interpretive mode, executing the command or service request as it is recognized. This mode is illustrated in Figure 2. Inscan has been designed to function in either mode, depending on the nature of the action graph which is controlling it. More generally, Inscan can be used in a mode which combines both translational and interpretive aspects, as illustrated in Figure 3. An important by-product of using a syntax-directed processor for the language-scanning functions in a user-oriented system is that the languages themselves can become the object of experimentation. For this to be feasible it must be easy to introduce a new action graph (or a new version of an old one)into the system without impact on existing system or user programs. In DM-1 this is done by using Inscan in a translational mode to translate an action graph specified in a symbolic language called STAG (STring Action Graph) into an absolute form called the Action Graph Table (AGT), which is the form actually used by Inscan. Thus, the use of Inscan can be viewed as a two-stage process. In the first stage, corresponding to assembly time, an AGT is generated from a STAG source language specification (or "program"). In the second stage, corresponding to execution time, a userlanguage text is scanned by Inscan under control of the AGT. Extract: Metalanguage Requirements Metalanguage Requirements It is important that a language should respond to, and adapt to, the needs of the user. Since the syntax and semantics of languages are specified in metalanguage, it is appropriate to examine the characteristics which a metalalanguage should have when considered as a design language for the user. There are several properties that the metalanguage should have: (1) It should be capable of expressing the notation and syntax of a context-free language. (2) It should be capable of expressing the operations of a push-down automaton which will generate the output stream. (3) It should be capable of expressing a subroutine call to a processor which can take some interpretive action, such as execute a command, respond to a modal operator (or pseudo-op), or expand a macro call in the output stream. To this list of important characteristics should be added the following desirable features: (4) It should be representable in an easily-read graphical format that exhibits the structure of the language. (5) It should be capable of expressing several levels of structure so that the overall structure of the language can be expressed before linguistic subtypes need be defined. (6) It should also be representable by readable linear strings amenable to computer input and it should be easy to translate from the graphical to the linear version, and vice versa. in Proceedings of the 23rd ACM national conference January 1968 view details in Proceedings of the twenty-fourth ACM national conference August 1969 view details AUERBACH/DM-1 Background. Data Manager-1 (DM-1) is a generalized data management software system designed by Auerbach Corporation as a proprietary package. The system is being implemented on two distinctly different hardware systems: on a Univac 1218 (Mil Spec 418) for the U.S. Air Force under contract through the Rome Air Development Center and on the IBM 360/50 for the Western Electric Corporation. Summary of Capabilities. The DM-1 system provides program and job library services, data storage and access services, and job execution control. The job library contains a number of general-purpose systemjobs for building, maintaining, and querying the data base and job library. User jobs can be added to this library. The structure of the data pool provides logically for definition of items and defines a structure for a set of directory tables. Basically DM-1 provides a nucleus system with emphasis on data definition, data structuring, and data access methods. Features such as generalized report generators, user query and maintenance languages, and recording services are not defined in the DM-1 design. It is intended that these items be developed for each customer as separate units to be integrated into the system, and currently COBOL can be used as a retrieval language. Programs (generalized report generators) would be added to the job library with no unique status. The syntax of system languages (query, maintenance) can be defined by the user through a meta language (similar to ALGOL). Specific Features. DM-1 has been designed independently of a specific computer: however, the system is designed to utilize fully the capabilities of whatever operating system that DM-1 is to run under. A standard interface is provided to the computer through the use of the data service routines, which are theoretically the only computer dependent routines of the system. DM-1 has a very comprehensive logical file structuring capability. The system has been designed to provide a very powerful data structure facility that can provide complex hierarchies of logical relationships in the form of general linked-tree structures. The data description language permits the use of variable length data elements, optional data elements, and nested structures. The DM-1 data pool is a series of fixed length data segments containing an unformatted stream of bits. The segment size of the data pool is independent of the logical file organization and theoretically utilizes the maximum buffer size of the operating system. The DM-1 access mechanism, which utilizes the IOCS, transfers the data between the data pool and core. The segmented data stream is interpreted in core by the data service routines with the aid of the system directories and the segment index. in Proceedings of the twenty-fourth ACM national conference August 1969 view details in [ACM] ACM Computing Surveys (CSUR) 8(1) March 1976 view details |