CMS-2(ID:711/cms001)Compiler Monitor Systemfor Compiler Monitor System version 2 General purpose language used for command and control applications in the US Navy. Mandated for Navy use until Ada. Related languages
References: of the Navy DOI Extract: Background 2. Background. a. The Navy Tactical Data System (NTDS) began as an R&D project at the Naval Electronics Lab (NEL) in the late 1950st involving a team of Navy officers and scientists, and employees of UNIVAC. By any measure, the team consisted of very capable people, and the result was a very successful product. To put the system in perspective, consider the computer on which it was implemented -- the UNIVAC AN/USQ-20. This machine has 32K words (30 bits each) of core, 16 I/O channels (each capable of an 800KC transfer rate), a 62 instruction repertoire, and an 8 microsecond memory cycle time. And it was running aboard ship in 1961; by 1963, the faster (4 microsecond cycle) Q-20B was available. Compared to the large computers of that era (e.g. the IBM 7090 or 7094), that's pretty good. And it is packed into a single box of 42.5 cubic feet, water cooled, and rugged. (The architecture of the Q-20 resembles the UNIVAC 490, and is a subset of the UNIVAC 1230, with which more readers may be familiar.) b. The NTDS software was likewise a product of its time; the early programs were written in an assembler called CS-I, which offered much the same power as AUTOCODER (an assembler on the IBM 7000 and 1400 series computers of that era). Those who would prefer now to have NTDS implemented in some higher order language (HOL) must recall that an appropriate HOL just did not exist in 1960. Some programming was also done in NELIAC, an Algol-like language (but, significantly, not Algol 60). c. NTDS, its hardware and software, is now installed in dozens of ships in the Fleet. Those same vintage computers (and some vintage code too, as well as more recent modifications and additions) are still running. True, there have been changes; e.g., in the early 1970s, the Navy added the extended core memory unit (ECMU) to the Q-20s to relieve the core crunch. But there has been no wholesale replacement of hardware and software as often occurs in some applications. d. Elsewhere in DOD, other systems were being built with other machines and other languages. And they too have survived, in some form. e. By 1969, the Navy was planning to procure a new, larger computer, the UNIVAC AN/UYK-7. Meanwhile, an improved language, CMS-2, had been implemented for the Q-20 computers. A version of CMS-2 was procured for the UYK-7; and thereby hangs a tale. At least one consultant (the author) advised the Navy to make the source language of CMS-2 as nearly uniform as possible, regardless of whether the target machine was to be the UYK-7 or the Q-20. But in 1969-1970, the technical and political climates were not proper for such advice to be accepted. Thus an incompatible version of CMS-2 was designed and implemented for the UYK-7. f. In the early 1970s, an ambitious R&D project began, to produce a new, fast, reliable, inexpensive, powerful airborne computer for Navy use. It was to have its own new version of the language, known as CS-4, specifically designed to exploit the power of the computer to do tactical problems. Extract: Current Status 3. Current Status. a. The Navy, and Don, like most large users of computers, have learned that the major expense today is in the production and maintenance of software, not hardware. Whereas our managers of the late 1960s and early 1970s were often the victims of circumstances, today's leaders deserve much credit for defying circumstances in order to make progress possible. Some key items follow. b. In 1975, the Army and Navy formed a joint committee to select nominees for a compatible family of computers, based on one architecture. Thus, Don will be able in future years to realize the same benefits that several major computer vendors realize today by extending the capability of an existing architecture. (Burroughs, CDC, DEC, IBM, UNIVAC, and others each produce computers which are software upwards compatible across a significant performance and price range.) c. Earlier, DOD had begun the search for (or definition of) a Standard HOL, so that in the future, tactical systems could realize benefits similar to those now available to long-time users of COBOL and FORTRAN. (NOTE: The CFA and DOD-i projects are certainly not incompatible; they are alternate approaches to a common goal, each offering a measure of benefit, and an amount of risk.) d. In late 1977, the Navy committed to the redesign and redevelopment of NTDS, with the programming to be done entirely in a standard subset of the CMS-2 language, such that, via recompilation, programs can be hosted on the Q-20, the UYK-7, or the AN/UYK-20 (mini-computer). Extract: Probable Future 4. Probable Future. (author's opinions) a. The DOD will select (or develop) a standard HOL. This will likely take the remainder of the decade (i.e., until 1980), at least; and the major benefits may not be measurable for another decade. But it will happen. We have gotten by two major obstaclesr viz. "It can't be doner" and "Languages must explicitly exploit the computer's strengths." (It has been done elsewhere; and exploitation is now widely recognized as an implementation issue -- e.g., FORTRAN for the CRAY-I.) There remains the possible pitfall of wanting to create a new language, when adoption (with modifications) of an existing language might suffice. (And this is one of the places where SIGPLAN can offer much help.) b. The DOD will likewise adopt a compatible family architecture, covering a wide range of price and performance. This too will take time to accomplish, and even more time to measure the benefits; but it will happen. c. The goals are, in both cases, the capture and transfer of valuable software. Technology makes such changes possible; economics makes them desireable; and an enlightened management will make them happen. in SIGPLAN Notices 13(03) March 1978 view details in SIGPLAN Notices 13(11) Nov 1978 view details This paper describes the work that Unisys and the Navy computer and support software standards office, NAVSEA PMS-412, are doing to support transitioning existing realtime tactical Navy Computer Monitor System-2 (CMS-2)1 software systems to Ada. The objective of the work is to provide a means for system implementors to gradually integrate Ada software into existing systems until all functions are written in Ada and the systemsbecome totally Ada systems. The method is to modify an existing realtime tactical operating system so that it continues to support the current CMS-2 application software but also supports Navy-standard Ada software at an executive level. Communication between the existing and Ada application software is through common data and message passing. Extract: Introduction Introduction Existing Navy tactical systems need a more cost effective, lower risk, more easily manageable way of transitioning to Ada than an immediate, total conversion. Existing CMS-2 systems are large (an estimated 100 million lines of CMS-2 code is currently in existence) and proven. Even in relatively new developments, large bodies of code are often captured from preexisting applications. These facts, combined with tighter budgets, makes DoD Directive 3405.2, "Use of Ada in Weapon Systems," and Section 8092 of the DoD Appropriations Act, 1991, Public Law 101-511, difficult to effect. The directive states that "Ada shall be the single, common, high-order programming language" for "all new weapon systems" and "major upgrades." "A major upgrade, as it applies to a specific system or subsystem, is the redesign or addition of more than one-third of the software." The law requires that, "where cost effective, Department of Defense software shall be written in the programming language Ada..." Thus, a project could be required to make a substantial transition to Ada all at once with all of the costs and risks that switching to a new technology entails-e.g., lack of expefiise and immature development and runtime implementations. A reasonable assumption might be that projects would be creative in finding ways to stay under the one-third mark or persistent in trying to get waivers. In other words, a reasonable assumption might be that projects would work to avoid using Ada because of the directive and in spite of the law when the intent is to get Ada used sooner in real systems. This paper presents a method of fulfilling the intent of DoD Directive 3405.2 and the House Appropriations Bill for 1991, Section 8092, by a less threatening means than immediate, total conversion to Ada. The method provides for the cohabitation of Ada and existing software; it allows existing systems to continue using their existing applications software while at the same time incorporating Ada applications software. Therefore, as shown in Figure 1, projects can decide how much transition makes sense at anyone time for their systems so that transition to Ada can be incremental. At the same time they can build their Ada expertise, advance the maturity of Ada development and runtime implementations, and spread their transition costs over time. Extract: Method Method Work thus far toward the cohabitation of Ada and existing software has been specific. For existing software, Unisys and PMS-412 have directed the majority of the effort toward CMS-2 systems executing under the AN/UYK-43 Runtime Support Software (43RSS) operating system, generated by the Machine Transferable Support Software (MTASS), and running in the AN/UYK-43 large-scale, Navy-standard computer. For an Ada implementation, Unisys and PMS+12 use the Ada Language System/Nay for the AN/UYK-43 computer (AWN Ada/L). However, Unisys for PMS-412 has also done prelimirwy analyses of the AEGIS Tactical Executive System for AN/UYK-43 computers (AS/43), the Naval ‘Mctical Executive Program (NTEP), and the Standard AN/ UYK-44 Executive (SDEX/44) relative to Ada and CMS-2 Cohabitation. The analyses found these operating systems likewise conducive to a Cohabitation implementation. Ada and CMS-2 Cohabitation makes explicit use of the structure of the AIJVN Runtime Operating System (RTOS). The ALS/N RTOS consists of two paxts, the Runtime Executive and the Runtirne Liirary. The Runtime Executive, for the most part, does what any execution must do: it controls the hardware resources for useby the software. For instance, the Runtime Executive controls use of the Central Processing Units (CPUS), controls use of the Input/Output (f/O) channels and shared peripheral devices, it initially handles interrupts, and it controls the hardware clocks. The Runtime Liirary, on the other hand, for the most part does those functions that are more Ada specific, that most existing CMS-2 operating systems do not do. For instance, the Runtirne Librarymaintains the Ada task dependency relationships, provides dynamic storage management, provides stack operations, and routes Ada exceptions to their proper in SIGPLAN Notices 13(11) Nov 1978 view details in SIGPLAN Notices 13(11) Nov 1978 view details OVERVIEW OF THE TRANSLATOR EVALUATION PROCESS The CMS-2 programming language is comprised of many dialects. Each is almost a full set of the language. The five principal dialects are CMS-2Y, CMS-2L, CMS-2M, CMS-2A, and CMS-2K. Translators were exercised with CMS-2Y, CMS-2M and CMS-2L source code samples selected to exercise all major CMS-2 constructs. The CMS-2A and CMS-2K dialects only differ from the three dialects exercised in the direct code that they allowed. The CMS-2 to Ada translators do not translate the embedded assembler, but rather bypass it or convert it to Ada comments. The Machine Transferable Support Software (MTASS) CMS-2 User Handbook describes the syntax (structure) and semantics (meaning) of the CMS-2 language. pdf in SIGPLAN Notices 13(11) Nov 1978 view details Resources
|