PROSPRO(ID:8183/)IBM process control languagefor PROcess Supervisory PROgram Related languages
References: in Proceedings of seventh international conference on APL Pisa, Italy 1975 view details in Proceedings of seventh international conference on APL Pisa, Italy 1975 view details In the early 1970?s, further reduction in hardware cost was reflected in systems such as the IBM System/7 for sensor based applications. A host program preparation facility was developed for generating the System17 real-time operating system, as well as application programs, on large systems such as System/360 for subsequent transmission to a System/7. In addition, the Application Program Generator (APG),3 a PL/I-like language, was developed to further reduce software effort. In spite of these developments, and the availability of specialized application packages for System/7, the installation effort was not reduced dramatically, in part because many customer installations could not justify a fulltime programmer. Thus computer vendors were forced to provide extensive software support. With the introduction of yet smaller and less expensive process control systems such as the IBM Seriedl, it has become mandatory to strive toward a programmerless environment in many applications so that the benefits of digital computer control can be provided with a reasonable software/hardware cost ratio. Extract: APG To avoid difficulties for the facilities engineer who is unfamiliar with programming, it is desirable to automate this process. The fill-in-the-blanks facility for provides some degree of automation for preparing the MSP/7 nucleus, with a reasonable degree of validity checking of answers. This facility was extended to tailor a complete application source program, step by step as follows: The application source, written in the high-level language of APG/7, is made into a ?prototype? which is processed according to the user?s answers to form a compilable source. Portions of the prototype are shown in Figure 1, and the program source after processing is illustrated in Figure 2. Dimensions are filled in, source code is eliminated, repeated, or retained, and variables are defined, all based on the user?s answers. A file containing the APG fill-in-the-blanks answers for generating the System/7 operating system macro source was itself made into a prototype, which was processed according to a minimum of user answers. This in effect allowed the creation of system parameters such as the number of multiprogram partitions, and it allowed specification of the storage location of programs based on user answers regarding machine memory size and whether the system incorporates disk storage. The job control language required to assemble the system supervisor and compile the application programs created in the first two steps was also made into a prototype file. This file was processed according to user answers, creating a system tailored to fit the application requirements based on the user?s machine configuration. In essence, the user answers questions on forms prepared for the application, enters the answers by means of a keyboard or punched cards, and follows a prescribed ten-step procedure to generate his system. The ten steps themselves could have been automated, but an inaccurate answer, recognized at the end of system generation, could require total system regeneration. In addition, it was decided to provide the user with system information between procedural steps. Further, a programmer can intercede between steps to add or modify application programs or modify the system nucleus. Depending on the complexity of the user?s application, total system generation, after specifying the user answers, took 5 to 12 hours of System/7 time. In almost all System/7 energy management installations, systems engineering assistance was required for system generation. When the stepwise procedure was followed, program generation and installation went smoothly. Difficulties arose when program modifications and functional extensions to the application were required, mainly because it was necessary to have operational knowledge of nucleus generation, system macro definitions, the job control procedure for the compiler, the assembler, the linkage editor, and the source language. in Proceedings of seventh international conference on APL Pisa, Italy 1975 view details There are many languages for computer control based on existing procedural languages; there are also a number of problem-oriented languages, for example, PROSPRO, BICEPS, BATCH, and AUTRAN. (For AUTRAN, see Section 111.) Although those languages are excellent in particular in the intended fields, it seems those are biased to computer science and do not catch all aspects of sequential control. After all, there is no higher-level control-oriented language which is general, natural, flexible, and powerful. We usually use ladder diagrams for sequential control description. Thus our way of description basically remains on a level with Shannon's work. Extract: CONDOR Conclusion This paper illustrated a controller description language Condor, which is Algol-like and nonprocedural. It is worth calling a spatial programming language. Condor is to Algol what space is to time. A Condor program represents an organization of reactors which work together in a parallel manner and use tools if necessary. Condor is a language for describing the roles of the reactors. A nested block structure expresses a hierarchy of reactors. This paper proposed the meaning of "hierarchy" for a sequential controller. A distant source of this paper was the concept of parallel action and teamwork of cellular automata [...] ......In general, controllers neither terminate nor conclude, so that they form a class different from the class of all algorithms. We should investigate and classify nonalgorithms. "program" is not a synonym of "algorithm." The problem of loops is fatal for any system. Little difficulty will arise in investigating a system with no loops. The problem of loops is important especially in control-oriented circuit theories. How to handle loops characterizes a theory. Since a circuit is a simultaneous equation system, circuit loops are different from computer program loops in the following respect: all the circuit loops basically operate in a parallel manner. This is a difficult and interesting problem. There are some kinds of positive and negative feedback loops in a relay circuit. A negative feedback loop is a cause-killing circuit. Note: Condor is intended for bringing tree structures into relief. A system is composed of trees and loops. We can discuss the subroutine concept and extensibility of Condor. They have properties different from those of a procedural language. The most interesting course of future research are efforts to build both the pattern recognition (or responding-to- pattern) ability and the learning ability into a controller. A language for describing patterns, pattern processing, and learning is needed. The language should be founded on circuit theory. A learning description language will be concerned with a Condor-handling language, because to learn is to generate a new or improved behavioral program. The handling language should handle not only Condor, but also the handling language itself. For a learning mechanism itself is learned. (This selfreference property of the handling language is somewhat similar to that of a list processing language.) For pattern recognition, the pandemonium model seems suited to the philosophy of this paper. Our ultimate objective is to make the level of a descriptive language so high that an ethologist's description of animal behavior can be a controller description program itself. in Proceedings of seventh international conference on APL Pisa, Italy 1975 view details The third operating system for the IBM 1710 was released in 1964. It was called the FORTRAN Executive and was a significant milestone in the evolution of realtime systems, since, for the first time, the high-level language FORTRAN was available for use by the real-time application programmer. While FORTRAN Executive had limited acceptance because it came late in the life of the IBM 1710, it pointetdh e direction for the use of high-level languages in real-time applications. All subsequent realtime systems have provided FORTRAN or other high-level languages for application development. In November 1964, the Time-sharing Executive (TSX) system was announced in conjunction with the IBM 1800. When delivered in early 1966, TSX was the first IBM operating system to provide real-time support with concurrent background batch capability. This allowed the user to prepare, compile, and link into real-time application programs without taking the system off line. The background batch capability further allowed commercial and engineering programs to be compiled and executed concurrently with real-time programs. FORTRAN was the primary user real-time language under TSX. The use of assembler language could be relegated to those areas where the performance or size of the generated code from FORTRAN was unacceptable. A specialized control program facility, called PROSPRO, was developed in 1966 to reside on top of TSX. It was intended primarily for use in the control of continuous processes such as those found in an oil refinery. PROSPRO provided built-in functions familiar to the process engineer, such as the controller equation described earlier, which could be invoked using terminology known to control engineers. In addition, it featured a ?fill-in-the-blanks?? programming technique whereby data from forms prepared by the control engineer were used to create tables that determined program sequences and computer responses needed to control the process. It allowed the control engineer to utilize the system with very little specialized knowledge of computers [18]. In its original release, it effectively supported the supervisory (setpoint) control philosophy, but a later release (PROSPRO 11) for MPX provided DDC. in Proceedings of seventh international conference on APL Pisa, Italy 1975 view details in Annals of the History of Computing 4(1) January 1982 IEEE view details |