- Email: [email protected]
Polo problem oriented language organizer
Computers & Structures, Vol. 2, pp. 555-572.
PROBLEM
Pergamon Press 1972. F’rinted in Great Britaio
ORIENTED
POLO LANGUAGE
ORGANIZER
L. A. LOPEZ? University of Illinois, Urbana, Illinois, U.S.A. Abstract-The design process requires that engjneers integrate the operation of several separate but related subtasks. The result of each subtask either creates data for the next lower level in the design, or dictates that earlier decisions be modified before proceeding further. The use of the computer as an aid to design can lead to a number of problems with respect to communication, which do not exist in the conventional design process. Problem Oriented Language (POL) supervisory systems such as ICES and the Translator Generator are available for engineers to use in communicating with the computer. However, a number of problems concerning data management and machine dependence indicate that a second look at POL supervisory systems is needed. The purpose of this paper is to present a brief review of the development of current POL’s and to present the concept of the POLO system. POLO is a machine independent prototype computer system whose purpose is to provide engineers with an environment in which thay can develop their own computer-aided design environment.
INTRODUCTION POLO is a prototype computer system designed to aid engineers in creating their own computer-aided design environment. The purpose of this paper is to present the general concept of POLO and to demonstrate how it can be used in design. The design process requires engineers to integrate the operation of several separate but related subprocesses. The result of each subprocess either creates data for the next lower level in the design hierarchy or, in the case of conflicts, i.e., vilation of previously defined design constraints, dictates that earlier decisions be modified and a number of steps in the process repeated. Complete design is attained when the subprocesses at the lowest level in the hierarchy can be completed without conflict with earlier decisions. When one considers the computer as an aid to design, a number of problems which are taken for granted in a conventional design process become critical. The problem on which attention is focused herein is communication, both between the designer and the computer, and between the various programs used in the design process. As noted above, design is an integration of a series of related steps and decisions. With computer-aided design many of these steps should logically be carried out in an interactive environment [l]; i.e., where the engineer is in constant communication with the computer system, can make decisions and immediately see the effect of his decisions on the design. In other instances, it is desirable to examine results for a period of hours or days before a decision is made or the next step in the process is begun. Throughout this interaction, manmachine communication is a critical factor. Computer systems which allow engineers to communicate easily with their programs and with the computer itself are mandatory for such an environment to exist. t AssistantProfessor of Civil Engineering. 555
556
L.
A.
LOPEZ
Design, however, is an engineering function, and it is engineers who must be responsible for developing design processes and programs. Hence computer systems are needed which not only provide engineers with th.e desired design environment but also provide them with the tools necessary to create this enivronment. Again man-machine communication is a critical factor. Engineers must be concerned primarily with the problem of design; they must not be required to delve into the innards of an operating system in order to produce a workable design system. It is important to note here that there are at least two levels at which engineers are expected to communicate with the comptlter; at the design system implementation level and at the design level itself. One method of man-machine communication which has been very well received by engineers, and which offers a possible solution to the communications problem is problemoriented languages (POL’s). A POL is a language which allows an engineer to describe problems to the computer in terms similar to those he would use in describing the problem to a colleague. Computer systems such as STRESS, COGO, and HYDRO, which use a POL for input of commands and data were successes primarily because of the ease with which engineers could describe and obtain solutions to complex problems. The development of these systems SW both time-consuming and costly. Hence a number of investigators developed computer systems which aid engineers in creating new POL’s, thus minimizing the time and cost per POL. The Translator Generator (TG), developed at the University of Illinois 12, 31, and the Integrated Civil Engineering Systems (ICES), developed at MIT [4], are examples of this effort. The TG aids its users in developing new POL’s. Each new system is a completely independent POL. POL’s developed under ICES are, however, integrated into the ICES system as subsystems, Interaction between subsystems is possible and POL generation is simple when compared to the techniques used to develop earlier POL driven systems. Both the TG and ICES systems represent significant contributions to the engineering profession. However, each of these systems lacks a comprehensive automatic data management facility. The latter is, as will be demonstrated herein, a necessity if computer-aided design is ever to be accomplished as a series of simple and separate tasks. POL SYSTEMS In order to place the structure and development of POL driven systems into the proper perspective, it is necessary to examine closely the anatomy and growth of these systems. Figure l(a) shows the structure of a well-written program which does not use a POL for input of data. The MAIN routine is used primarily as a driver to call the individual subprograms at the proper time. Flags in the input data are usually used to indicate control functions; e.g. a 1 in column 80 might indicate that this is the last data card in a group and that processing is to be initiated. For convenience the MAIN or driver routine is written in the same procedural language as the subroutines it drives. The first logical improvement over the above is to write a MAIN or driver routine which allows free form input and possibly uses a POL for input of data and commands. In general, such a program would be structured as shown in Fig. l(b). The driver routine calls a scanner subprogram which examines the next item of data and places its result, in fixed format, into a specified location of memory. In the figure, the result is placed at the top of the communication vector. The driver routine then examines the result and determines, based on previous input, if it is acceptable. Tf acceptable, processing continues; if the POL
Problem Oriented LanguageOrganizer
557
(cl
Fro. 1. Translator configurations.
input statement is not an acceptable construct of the POL being translated, an error message is sent and error recovery is initiated. Note that processing continues usually implies initiating a subprogram to move the data item from the scanner output area to the program data area. A command such as SOLVE normally causes a series of checks to be performed on previously input data. If all checks are affirmative, the solution process is initiated. If not. error messages are generated. The primary difficulty with the above is that algorithmic procedural languages such as FORTRAN are not well suited to POL development. POL drivers written in algorithmic langugages are difficult to develop and are usually more difficult to modify and extend. The approach shown in Fig. l(c) has been used with success in the TG and ICES systems, and is also used in POLO. In this method, the MAIN routine of Fig. l(b) is replaced by the POLO translator and a table called the grammar. In this scheme, the POL developer describes his now POL by writing a grammar. The translator then uses the grammar to determine if the statements being entered as data are acceptable. Changing the grammar in essence changes the POL to be translated. Thus the same translator and scanner can be used to translate a number of different POL’s.
558
L.
A.
LOPEZ
The next logical step in POL development is to create a POL supervisory system which is capable of coordinating the operation of a number of different POL’s within one computer run. Historically, this step was carried out as part of the development of both the TG and ICES systems. In reality three steps were taken at one time. The result is shown in Fig. 2.
Monitor Grammar
FIG. 2. Multiple POL systems.
First, a number of grammars and the corresponding subsystem subprograms have been combined under one translator, and a monitor subsystem (subsystem 1 in the figure) has been added. In general the function of the monitor is to interpret and execute all commands which coordinate the activities of the various subsystems. Second, a virtual memory system has been added as an aid to POL developers. The virtual memory is indicated in the figure as the memory manager, the memory overflow disk file, and the dynamic pool section of the communication vector. Programmed references to data which has been declared by the POL developer to reside in virtual memory, result in calls to the memory manager. The latter locates the data and if it is not resident in memory, unwanted data is transferred to the memory overflow disk and the desired data made present in memory. Control is then given to the original program requesting the data. The process is automatic and transparent to the POL programmer once he has declared the structure of data in virtual memory. Implementation of the above is highly machine dependent. For example, on the Burroughs B5500 computer the virtual memory is integrated with the hardware and the operating system. All programs have a virtual memory by virtue of being run on the B5500 computer. Thus programmers using the TG system (developed on a B5500) need not concern themselves with this problem. In contrast to the above, most models of the IBM 360 do not possess a virtual memory as a hardware function. Consequently, the ICES system maintains a memory manager as part of the POL supervisory system.
Problem Oriented LanguageOrganizer
559
In general, data residing in virtual memory is lost at the end of a job unless the programmer specifically writes the data into a private disk file. The third step in developing current multiple POL systems was aimed at solving the last-mentioned problem; i.e. saving data for future use and reference. In ICES, the subsystem developer can define the structure of a permanent data file into which subsystem users can move data from virtual memory and/or from a file into virtual memory. The structure of these files is shown in the figure with the corresponding POL grammar and is denoted the “data definition”. Only data defined in the data definition table can be moved; i.e. only preprogrammed references to data are permissible. A similar data management facility denoted the Information Organizer was developed for the TG environment. The Information Organizer is considerably more flexible than its ICES counterpart, primarily because the complete data definition is stored within the file itself; i.e. the file is self-documenting with respect to the names and structure of data in the file. As a result of this latter feature, a number of different programs can use the documentation to easily access the same data file in order to obtain and/or create data. Although all of the data in a file is available through this scheme, the system was designed for preprogrammed access only. Hence, it is still quite limited in use. At first glance, computer systems similar to ICES and TG appear to provide engineers with an ideal environment for developing and using computer aided design systems. However, in both ICES and TG the data management systems were developed after the supervisory system. Consequently, POL developers and users must use two separate data management facilities where one could, and should, do the job. For example, an ICES subsystem programmer must create an ICETRAN data structure for dynamic arrays which reside in the virtual memory and then a completely different data definition for use with the data management and transfer system. Additional programming must then be done in order to integrate the operation of the two systems. A similar situation exists in the TG environment. In view of the above restrictions and inconsistencies, it seems reasonable to reexamine the structure of POL supervisory systems and to develop a prototype system more suited toward computer aided design as presented in the introduction of this paper.
SYSTEM REQUIREMENTS In order to determine the requirements of the proposed system it is first necessary to examine the computer-aided design process from a conceptual and operational point of view. Conceptually, computer-aided design may be pictured as shown in Fig. 3. All basic data concerning the design is stored in a data file designated the “project file”. Thus architectural data concerning owner specifications, layout, etc., as well as lower level data derived during the design process by structural engineers, general contractors and subcontractors, etc., is all stored within this file. The structure of the data in the file, denoted “project me definition” in the figure, is also stored within the file for use by programs which access the file [5, 61. Individuals involved in the design process constantly use programs (e.g. layout, analysis, sizing) which extract data from or place data into the project file. As noted earlier, conflicts in the form of previously defined design constraints, will occur at various stages within the design process. Consequently, manual and/or automatic techniques must be made available to resolve them as they arise.
560
L.
A. LOPEZ ,-Project
File
Defin~hon
FIG. 3. Design process.
As shown in the figure, POL’s are used to drive the individual design programs, and data files created by one program may be used as input to another program. In general, there are two ways in which a user must be permitted to access data files, interpretively or preprogrammed access. As an example of the interpretive mode of operation consider an inquiry system, i.e. a program where an engineer can inquire through a POL about data stored in a file. Since it is not known a priori what data is to be displayed, the inquiry program must interpret the POL statement entered by the engineer and, using the file definition stored within the data file, interpretively locate the required data and display it. The preprogrammed mode of operation is the most commonly used of the two. In this mode the POL programmer makes program references to data which will, at execution time, be stored in a file of a given file definition or structure. Then, a compiler can, using the file definition, compile the program and create within the object program, commands to directly locate the required data in the file. Execution of the resulting object program can proceed with only occasional reference to the actual file definition. Note, however, that this program can operate only on files structured according to the file definition used at compile time. The above modes of operation can be applied to the example of Fig. 3 as follows. If design program No. 1 is to be capable of accessing a number of different project files relating
Problem Oriented Language Organizer
561
to the various design projects currently active within a company, it must do so in an interpretive mode of operation. The reason for this is that each project file can have a different data structure; it would not be reasonable to expect that the data concerning a bridge design be structured in the same manner as the data for a building design. Assume now that program No. 1 is an analysis program. Then the following objections may be raised: (a) the data stored within the project file may not be structured in a manner efficient for use during the analysis; (b) to access data interpretively during the analysis would be grossly inefficient with respect to computer time. In order to eliminate the above objections it is necessary to introduce an intermediate level of programming support into the design process. For example, assume now that program No. 2 is the analysis program, and program No. 1 a general purpose inquiry and data transformation system which can be used to interpretively locate and move data between files. Program No. 2, unlike program No. 1, can operate only on files structured in a particular manner; i.e. the file structure is compiled directly into the program as described earlier. Hence, program No. 2 can directly locate data in the file with only occasional reference to the file definition, provided, of course, that the file is structured from the file definition used to compile the program. Now, in order to perform the desired analysis, the designer must, (a) enter POL statements which direct program No. 1 to interpretively move data from the project file to a file suitably structured for input to program No. 2, and (b) enter POL statements which give additional data and commands to program No. 2 so that the desired analysis can be accomplished. It is important to note here that program No. 2 does not require the presence of a project file. All data can be entered using POL input statements of step (b). Step (a) can then be omitted. The results of the analysis might be stored in the analysis output file. This file can be used directly by other subsystems for postprocessing of data; e.g. POL commands can then be used to print the data and/or a program similar to program No. 1 used to move segments of output data back into the project file. The latter operations are not shown in the figure. In general the output from program i can be used directly for input to program i+ 1 if the data structures are compatible. If they are not compatible, the output from program i must be interpretively moved to a file which is compatible for input to program i+ 1. A number of points concerning the above scheme are worth emphasizing before proceeding further. 1. POL’s must be available for each individual design program. 2. File definitions are required at two levels: (a) to interpretively move data within or between files; (b) to compile programs which are to access data files directly as opposed to interpretively, during execution. 3. The function of individual files change during the design process. In the example, the input file for program No. 2 was initially an output file for program No. 1. Similarly, the output file of program No. 2 would be the input file to another program when results are moved back to the project file.
563
L.
A.
LOPEZ
4. Most design programs are similar to program No. 2. Interpretive accessing of data files such as that done by program No. I, would be used only to transform and move data as in the example, to display data in an inquiry mode of operation, or to enter a limited amount of data directly into the project file. 5. Development of programs which use POL’s for input of data and which simultaneously access a number of structured data files is a complex and costly task. However, if all design programs operate under a common supervisor program, the management of files as well as the translation of POL input can be done at the supervisory level, thus saving a considerable amount of time in developing design programs. The Problem Oriented Language Organizer (POLO) has been developed as an attempt to help solve a number of the problems described in the preceding paragraphs. POLO is a prototype computer system designed to provide engineers with a computeraided environment for developing and using design systems. POLO is based on the Translator Generator and ICES concepts as presented earlier in this paper. In general, engineers can use POLO to use, create, integrate, and maintain computer programs which use a POL for input of data and/or which require a comprehensive data management facility. POLO subsystem developers need not be sophisticated programmers. All subsystem development is done in procedural languages such as FORTRAN or ALGOL. The POLO virtual memory system, which makes it appear to the programmer as if all data in all global files is resident in core at all times, is completely compatible with FORTRAN, ALGOL, etc. Hence the subsystem programmer need never operate directly on a disk file. POLO operates in the batch time shared, and interactive modes, depending on the operating system of the machine on which it is operational. The system is written in FORTRAN and readily transportable to machines of various manufacturers. POLO STRUCTURE Figure 4 is a schematic representation of POLO and corresponds to the TG and ICES schematic of Fig. 2. There are, however, a number of important differences. First, the data management and virtual memory systems have been combined into one unit within POLO. The POLO virtual memory system is capable of providing subsystem subprograms with access to data residing in a number of separate user or system-supplied global files. Secondly, the translator drives the v-irtual memory system through commands imbedded in the POL grammar. This feature represents a major difference between POLO and its predecessor systems. In the ICES and TG systems, programmed references within subsystem subprograms to data stored within the virtual memory, caused commands which operate the virtual memory system to be imbedded by the compiler into the object code of the subsystem subprograms. In POLO, references to data stored in global files (virtual memory) cause commands which operate the virtual memory system to be imbedded by subsystem GENERATOR into the tabular form of the grammar. During execution of a subsystem these commands cause the POLO translator to give control to the data management system which locates the data in virtual memory and returns control to the POLO translator. The translator then passes the data as arguments to subsystem subprograms. Except for the above interface, the data management system is independent of the POLO translating system. The subprograms are written assuming that a normal (static) data pool exists; i.e. the operation of the virtual memory system is transparent to the subsystem programmer
563
Problem Oriented LanguageOrganizer
File
File
Definition No.
I
Definition
Subsystem Monitor Grammar
I Sub
I
Communication vector SCCWW output
_I~~~~
:
: :
Usws
Individual structur9d oata Filer (Global Filer)
FIG.4. POLO configuration. The third and last major difference between POLO and its predecessors is that, since structured data files (global files) are not associated with a particular subsystem, the file definitions for these files, which are shown at the left of Fig. 4, are independent of the grammars shown immediately to the right. Any file definition can be used with any subsystem, Inquiry systems such as program No. 1 in the example can interpretively access all data in all global files as opposed to only programmed access in the TG and ICES systems. This latter capability is possible because the structure of all data in a global file is stored within the tie, and hence available to inquiry systems for locating problem data. Figure 5 is a condensed representation of POLO, and is more suited to a description of use of the system. The block labeled “POLO SYSTEM” contains the POLO translating and virtual memory systems. All POL statements must enter the system through the input stream, Other types of data may be entered through the input stream if desired. Printed output normally leaves the system through the output stream. In batch computer operations the input stream is initially the card reader; i.e. data are entered through cards. In time-shared systems the input stream is initially a teletypewriter. However, the location of both the input and output streams is controlled by the user through POLO commands. Thus a card in the POLO input stream can direct that data be read from a disk file or that output be directed to a Teletype, etc. The form of these statements is described later in the paper. All structured data files (global files), such as the project file and the analysis input and output f?les of the previous example, are attached to POLO through the standard operating system control language of the machine being used. As far as POLO is concerned, they are FORTRAN direct access files. Similarly, the input stream consists of any sequential data file containing card or line images. Each file to be used, designated el, e2, . , . , e,, in the figure is equated to one POLO internal FORTRAN number or label (time-shared machines usually use labels), designated il, i2, . . . , in in the figure. For example, the real disk file named DATA could be equated to the FORTRAN unit 20, etc.
564
I,.
A.
I.OPEZ
I
I
1 File
Card
Definition u
I
Subsystem NO. 2
I
Global Filer
7
.---_-
I -\
\
Reader -/
.sequentiol Film
FIG. 5. POLO configuration.
A number of design programs, henceforth termed subsystems, are attached to POLO as shown in the figure. In essence, the POLO system plus the subsystems are combined into a single working program using the standard system loader on the machine being used. Conflicts between subsystem subprogram names are avoided by assigning a two-letter prefix to each subsystem. All subprograms within a subsystem are required to begin with the assigned prefix Overlays, etc. are defined through control cards to the loader (if the loader has overlay capabilities). In addition to subsystem subprograms, POLO maintains two libraries, one containing the definition of all POL’s currently operational in the system (grammars), and the other containing the file definitions required to use these POL’s. Generation of these libraries is quite simple and discussed in the Section ‘Subsystem generation’. As noted in the preceding paragraphs, real gobal files, el, e2, . . . , e, are associated with internal POLO files ir, i2, . . . , in. A method must now be devised which assigns global files to the proper subsystem at the proper time. Subsystems cannot be allowed to refer to files by absolute POLO number il, i2, . . . , in; to do so, would severely restrict POLO’s ability to pass files from subsystem to subsystem. Hence the following scheme is used. When a subsystem, such as program No. 2, is created, the POL developer must assign a relative file number, and the corresponding file definition to each global file to be used by the subsystem. In the figure, subsystem No. 2 is shown with two relative files rr and
Problem Oriented LanguageOrganizer
565
r2. File rl is structured from INPUT and t2 from OUTPUT. The required tie definitions must be stored in the tile definition library prior to creating the subsystem. After the subsystem is created, any real file which contains the same file definition as was used to create the subsystem, can be used in that relative position during execution of the subsystem. For example, if global file e, is structured according to file definition INPUT, it can be used as relative file rr during execution of program No. 2. The need for relative files and their structuring must appear in the user’s manual for each subsystem. A new disk file, e,, can be prepared for use as global file, ik, through the POLO FORMAT command. Similarly, relative files are assigned to subsystems during execution through the POLO FILES command. These commands, as well as others required for the operation of POLO are given in the following section. POLO COMMAND
STRUCTURE
In order to provide users with the desired environment, a simple command language has been implemented within the POLO system. The purpose of this language is to provide users with a means to control execution of the various subsystems, to control the location of the input and output streams, and to inform the virtual memory system of operations to be performed on global files. It should be noted here that the POLO command system is, in fact, a POLO subsystem and can easily be modified using the subsystem generating facilities in POLO. Commands are normally acceptable at any time during a POLO run. Each request by a subsystem for a new line of data is in reality a request to POLO to run the monitor subsystem. The monitor reads and examines the next line of data. If it contains a POLO command, the command is executed and a new line of data obtained and examined. The first line of data which does not contain a POLO command causes the monitor to terminate its operation, and execution resumes in the subsystem which made the request for data. In order to make this process as efficient as possible, the monitor is always resident in memory. In addition, a subsystem may request data without monitor intervention, if desired. In the latter mode, POLO commands are not recognized. POLO commands are logically divided into three groups; (a) subsystem control, (b) input and output stream control and (c) global data file control. The following is a description of the commands: Subsystem control RUN < subsystem name > causes the named subsystem to be initiated. The subsystem in control when the RUN command is encountered, is “put to sleep.” EXIT causes the current subsystem to end. POLO returns control to the subsystem in use prior to the one being terminated and at the point where the RUN command was encountered. FINISH terminates a POLO run. Input and output stream control INPUT FROM FILES il, i2, . . . , in causes POLO to immediately switch to the sequential file ii for input of data. encountering an end of file on ii POLO automatically switches to i2, etc., . . _ .
On
566
L. A. LOPEZ
OUTPUT TO ii causes the output stream to be sent to file ii. The above commands are extremely useful for time-sharing users. Disk files can be easily merged into a POLO run and large volumes of output can be directed away from the teletypewriter to a high-speed printer. GlobalJile control
FORMAT ik FROM (CODE =
PROBLEM
Pergamon Press 1972. F’rinted in Great Britaio
ORIENTED
POLO LANGUAGE
ORGANIZER
L. A. LOPEZ? University of Illinois, Urbana, Illinois, U.S.A. Abstract-The design process requires that engjneers integrate the operation of several separate but related subtasks. The result of each subtask either creates data for the next lower level in the design, or dictates that earlier decisions be modified before proceeding further. The use of the computer as an aid to design can lead to a number of problems with respect to communication, which do not exist in the conventional design process. Problem Oriented Language (POL) supervisory systems such as ICES and the Translator Generator are available for engineers to use in communicating with the computer. However, a number of problems concerning data management and machine dependence indicate that a second look at POL supervisory systems is needed. The purpose of this paper is to present a brief review of the development of current POL’s and to present the concept of the POLO system. POLO is a machine independent prototype computer system whose purpose is to provide engineers with an environment in which thay can develop their own computer-aided design environment.
INTRODUCTION POLO is a prototype computer system designed to aid engineers in creating their own computer-aided design environment. The purpose of this paper is to present the general concept of POLO and to demonstrate how it can be used in design. The design process requires engineers to integrate the operation of several separate but related subprocesses. The result of each subprocess either creates data for the next lower level in the design hierarchy or, in the case of conflicts, i.e., vilation of previously defined design constraints, dictates that earlier decisions be modified and a number of steps in the process repeated. Complete design is attained when the subprocesses at the lowest level in the hierarchy can be completed without conflict with earlier decisions. When one considers the computer as an aid to design, a number of problems which are taken for granted in a conventional design process become critical. The problem on which attention is focused herein is communication, both between the designer and the computer, and between the various programs used in the design process. As noted above, design is an integration of a series of related steps and decisions. With computer-aided design many of these steps should logically be carried out in an interactive environment [l]; i.e., where the engineer is in constant communication with the computer system, can make decisions and immediately see the effect of his decisions on the design. In other instances, it is desirable to examine results for a period of hours or days before a decision is made or the next step in the process is begun. Throughout this interaction, manmachine communication is a critical factor. Computer systems which allow engineers to communicate easily with their programs and with the computer itself are mandatory for such an environment to exist. t AssistantProfessor of Civil Engineering. 555
556
L.
A.
LOPEZ
Design, however, is an engineering function, and it is engineers who must be responsible for developing design processes and programs. Hence computer systems are needed which not only provide engineers with th.e desired design environment but also provide them with the tools necessary to create this enivronment. Again man-machine communication is a critical factor. Engineers must be concerned primarily with the problem of design; they must not be required to delve into the innards of an operating system in order to produce a workable design system. It is important to note here that there are at least two levels at which engineers are expected to communicate with the comptlter; at the design system implementation level and at the design level itself. One method of man-machine communication which has been very well received by engineers, and which offers a possible solution to the communications problem is problemoriented languages (POL’s). A POL is a language which allows an engineer to describe problems to the computer in terms similar to those he would use in describing the problem to a colleague. Computer systems such as STRESS, COGO, and HYDRO, which use a POL for input of commands and data were successes primarily because of the ease with which engineers could describe and obtain solutions to complex problems. The development of these systems SW both time-consuming and costly. Hence a number of investigators developed computer systems which aid engineers in creating new POL’s, thus minimizing the time and cost per POL. The Translator Generator (TG), developed at the University of Illinois 12, 31, and the Integrated Civil Engineering Systems (ICES), developed at MIT [4], are examples of this effort. The TG aids its users in developing new POL’s. Each new system is a completely independent POL. POL’s developed under ICES are, however, integrated into the ICES system as subsystems, Interaction between subsystems is possible and POL generation is simple when compared to the techniques used to develop earlier POL driven systems. Both the TG and ICES systems represent significant contributions to the engineering profession. However, each of these systems lacks a comprehensive automatic data management facility. The latter is, as will be demonstrated herein, a necessity if computer-aided design is ever to be accomplished as a series of simple and separate tasks. POL SYSTEMS In order to place the structure and development of POL driven systems into the proper perspective, it is necessary to examine closely the anatomy and growth of these systems. Figure l(a) shows the structure of a well-written program which does not use a POL for input of data. The MAIN routine is used primarily as a driver to call the individual subprograms at the proper time. Flags in the input data are usually used to indicate control functions; e.g. a 1 in column 80 might indicate that this is the last data card in a group and that processing is to be initiated. For convenience the MAIN or driver routine is written in the same procedural language as the subroutines it drives. The first logical improvement over the above is to write a MAIN or driver routine which allows free form input and possibly uses a POL for input of data and commands. In general, such a program would be structured as shown in Fig. l(b). The driver routine calls a scanner subprogram which examines the next item of data and places its result, in fixed format, into a specified location of memory. In the figure, the result is placed at the top of the communication vector. The driver routine then examines the result and determines, based on previous input, if it is acceptable. Tf acceptable, processing continues; if the POL
Problem Oriented LanguageOrganizer
557
(cl
Fro. 1. Translator configurations.
input statement is not an acceptable construct of the POL being translated, an error message is sent and error recovery is initiated. Note that processing continues usually implies initiating a subprogram to move the data item from the scanner output area to the program data area. A command such as SOLVE normally causes a series of checks to be performed on previously input data. If all checks are affirmative, the solution process is initiated. If not. error messages are generated. The primary difficulty with the above is that algorithmic procedural languages such as FORTRAN are not well suited to POL development. POL drivers written in algorithmic langugages are difficult to develop and are usually more difficult to modify and extend. The approach shown in Fig. l(c) has been used with success in the TG and ICES systems, and is also used in POLO. In this method, the MAIN routine of Fig. l(b) is replaced by the POLO translator and a table called the grammar. In this scheme, the POL developer describes his now POL by writing a grammar. The translator then uses the grammar to determine if the statements being entered as data are acceptable. Changing the grammar in essence changes the POL to be translated. Thus the same translator and scanner can be used to translate a number of different POL’s.
558
L.
A.
LOPEZ
The next logical step in POL development is to create a POL supervisory system which is capable of coordinating the operation of a number of different POL’s within one computer run. Historically, this step was carried out as part of the development of both the TG and ICES systems. In reality three steps were taken at one time. The result is shown in Fig. 2.
Monitor Grammar
FIG. 2. Multiple POL systems.
First, a number of grammars and the corresponding subsystem subprograms have been combined under one translator, and a monitor subsystem (subsystem 1 in the figure) has been added. In general the function of the monitor is to interpret and execute all commands which coordinate the activities of the various subsystems. Second, a virtual memory system has been added as an aid to POL developers. The virtual memory is indicated in the figure as the memory manager, the memory overflow disk file, and the dynamic pool section of the communication vector. Programmed references to data which has been declared by the POL developer to reside in virtual memory, result in calls to the memory manager. The latter locates the data and if it is not resident in memory, unwanted data is transferred to the memory overflow disk and the desired data made present in memory. Control is then given to the original program requesting the data. The process is automatic and transparent to the POL programmer once he has declared the structure of data in virtual memory. Implementation of the above is highly machine dependent. For example, on the Burroughs B5500 computer the virtual memory is integrated with the hardware and the operating system. All programs have a virtual memory by virtue of being run on the B5500 computer. Thus programmers using the TG system (developed on a B5500) need not concern themselves with this problem. In contrast to the above, most models of the IBM 360 do not possess a virtual memory as a hardware function. Consequently, the ICES system maintains a memory manager as part of the POL supervisory system.
Problem Oriented LanguageOrganizer
559
In general, data residing in virtual memory is lost at the end of a job unless the programmer specifically writes the data into a private disk file. The third step in developing current multiple POL systems was aimed at solving the last-mentioned problem; i.e. saving data for future use and reference. In ICES, the subsystem developer can define the structure of a permanent data file into which subsystem users can move data from virtual memory and/or from a file into virtual memory. The structure of these files is shown in the figure with the corresponding POL grammar and is denoted the “data definition”. Only data defined in the data definition table can be moved; i.e. only preprogrammed references to data are permissible. A similar data management facility denoted the Information Organizer was developed for the TG environment. The Information Organizer is considerably more flexible than its ICES counterpart, primarily because the complete data definition is stored within the file itself; i.e. the file is self-documenting with respect to the names and structure of data in the file. As a result of this latter feature, a number of different programs can use the documentation to easily access the same data file in order to obtain and/or create data. Although all of the data in a file is available through this scheme, the system was designed for preprogrammed access only. Hence, it is still quite limited in use. At first glance, computer systems similar to ICES and TG appear to provide engineers with an ideal environment for developing and using computer aided design systems. However, in both ICES and TG the data management systems were developed after the supervisory system. Consequently, POL developers and users must use two separate data management facilities where one could, and should, do the job. For example, an ICES subsystem programmer must create an ICETRAN data structure for dynamic arrays which reside in the virtual memory and then a completely different data definition for use with the data management and transfer system. Additional programming must then be done in order to integrate the operation of the two systems. A similar situation exists in the TG environment. In view of the above restrictions and inconsistencies, it seems reasonable to reexamine the structure of POL supervisory systems and to develop a prototype system more suited toward computer aided design as presented in the introduction of this paper.
SYSTEM REQUIREMENTS In order to determine the requirements of the proposed system it is first necessary to examine the computer-aided design process from a conceptual and operational point of view. Conceptually, computer-aided design may be pictured as shown in Fig. 3. All basic data concerning the design is stored in a data file designated the “project file”. Thus architectural data concerning owner specifications, layout, etc., as well as lower level data derived during the design process by structural engineers, general contractors and subcontractors, etc., is all stored within this file. The structure of the data in the file, denoted “project me definition” in the figure, is also stored within the file for use by programs which access the file [5, 61. Individuals involved in the design process constantly use programs (e.g. layout, analysis, sizing) which extract data from or place data into the project file. As noted earlier, conflicts in the form of previously defined design constraints, will occur at various stages within the design process. Consequently, manual and/or automatic techniques must be made available to resolve them as they arise.
560
L.
A. LOPEZ ,-Project
File
Defin~hon
FIG. 3. Design process.
As shown in the figure, POL’s are used to drive the individual design programs, and data files created by one program may be used as input to another program. In general, there are two ways in which a user must be permitted to access data files, interpretively or preprogrammed access. As an example of the interpretive mode of operation consider an inquiry system, i.e. a program where an engineer can inquire through a POL about data stored in a file. Since it is not known a priori what data is to be displayed, the inquiry program must interpret the POL statement entered by the engineer and, using the file definition stored within the data file, interpretively locate the required data and display it. The preprogrammed mode of operation is the most commonly used of the two. In this mode the POL programmer makes program references to data which will, at execution time, be stored in a file of a given file definition or structure. Then, a compiler can, using the file definition, compile the program and create within the object program, commands to directly locate the required data in the file. Execution of the resulting object program can proceed with only occasional reference to the actual file definition. Note, however, that this program can operate only on files structured according to the file definition used at compile time. The above modes of operation can be applied to the example of Fig. 3 as follows. If design program No. 1 is to be capable of accessing a number of different project files relating
Problem Oriented Language Organizer
561
to the various design projects currently active within a company, it must do so in an interpretive mode of operation. The reason for this is that each project file can have a different data structure; it would not be reasonable to expect that the data concerning a bridge design be structured in the same manner as the data for a building design. Assume now that program No. 1 is an analysis program. Then the following objections may be raised: (a) the data stored within the project file may not be structured in a manner efficient for use during the analysis; (b) to access data interpretively during the analysis would be grossly inefficient with respect to computer time. In order to eliminate the above objections it is necessary to introduce an intermediate level of programming support into the design process. For example, assume now that program No. 2 is the analysis program, and program No. 1 a general purpose inquiry and data transformation system which can be used to interpretively locate and move data between files. Program No. 2, unlike program No. 1, can operate only on files structured in a particular manner; i.e. the file structure is compiled directly into the program as described earlier. Hence, program No. 2 can directly locate data in the file with only occasional reference to the file definition, provided, of course, that the file is structured from the file definition used to compile the program. Now, in order to perform the desired analysis, the designer must, (a) enter POL statements which direct program No. 1 to interpretively move data from the project file to a file suitably structured for input to program No. 2, and (b) enter POL statements which give additional data and commands to program No. 2 so that the desired analysis can be accomplished. It is important to note here that program No. 2 does not require the presence of a project file. All data can be entered using POL input statements of step (b). Step (a) can then be omitted. The results of the analysis might be stored in the analysis output file. This file can be used directly by other subsystems for postprocessing of data; e.g. POL commands can then be used to print the data and/or a program similar to program No. 1 used to move segments of output data back into the project file. The latter operations are not shown in the figure. In general the output from program i can be used directly for input to program i+ 1 if the data structures are compatible. If they are not compatible, the output from program i must be interpretively moved to a file which is compatible for input to program i+ 1. A number of points concerning the above scheme are worth emphasizing before proceeding further. 1. POL’s must be available for each individual design program. 2. File definitions are required at two levels: (a) to interpretively move data within or between files; (b) to compile programs which are to access data files directly as opposed to interpretively, during execution. 3. The function of individual files change during the design process. In the example, the input file for program No. 2 was initially an output file for program No. 1. Similarly, the output file of program No. 2 would be the input file to another program when results are moved back to the project file.
563
L.
A.
LOPEZ
4. Most design programs are similar to program No. 2. Interpretive accessing of data files such as that done by program No. I, would be used only to transform and move data as in the example, to display data in an inquiry mode of operation, or to enter a limited amount of data directly into the project file. 5. Development of programs which use POL’s for input of data and which simultaneously access a number of structured data files is a complex and costly task. However, if all design programs operate under a common supervisor program, the management of files as well as the translation of POL input can be done at the supervisory level, thus saving a considerable amount of time in developing design programs. The Problem Oriented Language Organizer (POLO) has been developed as an attempt to help solve a number of the problems described in the preceding paragraphs. POLO is a prototype computer system designed to provide engineers with a computeraided environment for developing and using design systems. POLO is based on the Translator Generator and ICES concepts as presented earlier in this paper. In general, engineers can use POLO to use, create, integrate, and maintain computer programs which use a POL for input of data and/or which require a comprehensive data management facility. POLO subsystem developers need not be sophisticated programmers. All subsystem development is done in procedural languages such as FORTRAN or ALGOL. The POLO virtual memory system, which makes it appear to the programmer as if all data in all global files is resident in core at all times, is completely compatible with FORTRAN, ALGOL, etc. Hence the subsystem programmer need never operate directly on a disk file. POLO operates in the batch time shared, and interactive modes, depending on the operating system of the machine on which it is operational. The system is written in FORTRAN and readily transportable to machines of various manufacturers. POLO STRUCTURE Figure 4 is a schematic representation of POLO and corresponds to the TG and ICES schematic of Fig. 2. There are, however, a number of important differences. First, the data management and virtual memory systems have been combined into one unit within POLO. The POLO virtual memory system is capable of providing subsystem subprograms with access to data residing in a number of separate user or system-supplied global files. Secondly, the translator drives the v-irtual memory system through commands imbedded in the POL grammar. This feature represents a major difference between POLO and its predecessor systems. In the ICES and TG systems, programmed references within subsystem subprograms to data stored within the virtual memory, caused commands which operate the virtual memory system to be imbedded by the compiler into the object code of the subsystem subprograms. In POLO, references to data stored in global files (virtual memory) cause commands which operate the virtual memory system to be imbedded by subsystem GENERATOR into the tabular form of the grammar. During execution of a subsystem these commands cause the POLO translator to give control to the data management system which locates the data in virtual memory and returns control to the POLO translator. The translator then passes the data as arguments to subsystem subprograms. Except for the above interface, the data management system is independent of the POLO translating system. The subprograms are written assuming that a normal (static) data pool exists; i.e. the operation of the virtual memory system is transparent to the subsystem programmer
563
Problem Oriented LanguageOrganizer
File
File
Definition No.
I
Definition
Subsystem Monitor Grammar
I Sub
I
Communication vector SCCWW output
_I~~~~
:
: :
Usws
Individual structur9d oata Filer (Global Filer)
FIG.4. POLO configuration. The third and last major difference between POLO and its predecessors is that, since structured data files (global files) are not associated with a particular subsystem, the file definitions for these files, which are shown at the left of Fig. 4, are independent of the grammars shown immediately to the right. Any file definition can be used with any subsystem, Inquiry systems such as program No. 1 in the example can interpretively access all data in all global files as opposed to only programmed access in the TG and ICES systems. This latter capability is possible because the structure of all data in a global file is stored within the tie, and hence available to inquiry systems for locating problem data. Figure 5 is a condensed representation of POLO, and is more suited to a description of use of the system. The block labeled “POLO SYSTEM” contains the POLO translating and virtual memory systems. All POL statements must enter the system through the input stream, Other types of data may be entered through the input stream if desired. Printed output normally leaves the system through the output stream. In batch computer operations the input stream is initially the card reader; i.e. data are entered through cards. In time-shared systems the input stream is initially a teletypewriter. However, the location of both the input and output streams is controlled by the user through POLO commands. Thus a card in the POLO input stream can direct that data be read from a disk file or that output be directed to a Teletype, etc. The form of these statements is described later in the paper. All structured data files (global files), such as the project file and the analysis input and output f?les of the previous example, are attached to POLO through the standard operating system control language of the machine being used. As far as POLO is concerned, they are FORTRAN direct access files. Similarly, the input stream consists of any sequential data file containing card or line images. Each file to be used, designated el, e2, . , . , e,, in the figure is equated to one POLO internal FORTRAN number or label (time-shared machines usually use labels), designated il, i2, . . . , in in the figure. For example, the real disk file named DATA could be equated to the FORTRAN unit 20, etc.
564
I,.
A.
I.OPEZ
I
I
1 File
Card
Definition u
I
Subsystem NO. 2
I
Global Filer
7
.---_-
I -\
\
Reader -/
.sequentiol Film
FIG. 5. POLO configuration.
A number of design programs, henceforth termed subsystems, are attached to POLO as shown in the figure. In essence, the POLO system plus the subsystems are combined into a single working program using the standard system loader on the machine being used. Conflicts between subsystem subprogram names are avoided by assigning a two-letter prefix to each subsystem. All subprograms within a subsystem are required to begin with the assigned prefix Overlays, etc. are defined through control cards to the loader (if the loader has overlay capabilities). In addition to subsystem subprograms, POLO maintains two libraries, one containing the definition of all POL’s currently operational in the system (grammars), and the other containing the file definitions required to use these POL’s. Generation of these libraries is quite simple and discussed in the Section ‘Subsystem generation’. As noted in the preceding paragraphs, real gobal files, el, e2, . . . , e, are associated with internal POLO files ir, i2, . . . , in. A method must now be devised which assigns global files to the proper subsystem at the proper time. Subsystems cannot be allowed to refer to files by absolute POLO number il, i2, . . . , in; to do so, would severely restrict POLO’s ability to pass files from subsystem to subsystem. Hence the following scheme is used. When a subsystem, such as program No. 2, is created, the POL developer must assign a relative file number, and the corresponding file definition to each global file to be used by the subsystem. In the figure, subsystem No. 2 is shown with two relative files rr and
Problem Oriented LanguageOrganizer
565
r2. File rl is structured from INPUT and t2 from OUTPUT. The required tie definitions must be stored in the tile definition library prior to creating the subsystem. After the subsystem is created, any real file which contains the same file definition as was used to create the subsystem, can be used in that relative position during execution of the subsystem. For example, if global file e, is structured according to file definition INPUT, it can be used as relative file rr during execution of program No. 2. The need for relative files and their structuring must appear in the user’s manual for each subsystem. A new disk file, e,, can be prepared for use as global file, ik, through the POLO FORMAT command. Similarly, relative files are assigned to subsystems during execution through the POLO FILES command. These commands, as well as others required for the operation of POLO are given in the following section. POLO COMMAND
STRUCTURE
In order to provide users with the desired environment, a simple command language has been implemented within the POLO system. The purpose of this language is to provide users with a means to control execution of the various subsystems, to control the location of the input and output streams, and to inform the virtual memory system of operations to be performed on global files. It should be noted here that the POLO command system is, in fact, a POLO subsystem and can easily be modified using the subsystem generating facilities in POLO. Commands are normally acceptable at any time during a POLO run. Each request by a subsystem for a new line of data is in reality a request to POLO to run the monitor subsystem. The monitor reads and examines the next line of data. If it contains a POLO command, the command is executed and a new line of data obtained and examined. The first line of data which does not contain a POLO command causes the monitor to terminate its operation, and execution resumes in the subsystem which made the request for data. In order to make this process as efficient as possible, the monitor is always resident in memory. In addition, a subsystem may request data without monitor intervention, if desired. In the latter mode, POLO commands are not recognized. POLO commands are logically divided into three groups; (a) subsystem control, (b) input and output stream control and (c) global data file control. The following is a description of the commands: Subsystem control RUN < subsystem name > causes the named subsystem to be initiated. The subsystem in control when the RUN command is encountered, is “put to sleep.” EXIT causes the current subsystem to end. POLO returns control to the subsystem in use prior to the one being terminated and at the point where the RUN command was encountered. FINISH terminates a POLO run. Input and output stream control INPUT FROM FILES il, i2, . . . , in causes POLO to immediately switch to the sequential file ii for input of data. encountering an end of file on ii POLO automatically switches to i2, etc., . . _ .
On
566
L. A. LOPEZ
OUTPUT TO ii causes the output stream to be sent to file ii. The above commands are extremely useful for time-sharing users. Disk files can be easily merged into a POLO run and large volumes of output can be directed away from the teletypewriter to a high-speed printer. GlobalJile control
FORMAT ik FROM
) is used to prepare a new file for use in POLO. The file definition listed in the command is written on internal file ik, which corresponds to external global file eL. The code word is optional and is used to prevent future unauthorized use of the file. Once formatted a global file can be assigned to various subsystems as a relative file. OPEN &(CODE = )(READ ONLY) is used to programmatically attach internal file ik to POLO. The file must have been previously formatted. The code word is required only if the file was code protected when it was formatted. The option READ ONLY prohibits writing on the file during execution of this job. CLOSE i, causes internal file ik to be programmatically disconnected from POLO. The file can be re-attached through an OPEN command. Data in core and associated with the file ik is written on disk file ek. SECURE ik causes all data which is currently in core and which is associated with internal file ik to be written in disk file ek. This command is similar to CLOSE except that since the programmatic disconnect is not performed, it is not necessary to OPEN the file again for further use. Hence, its primary use is to protect a file and/or obtain space in the dynamic pool. FILES il, i2, . . . is used to associate the internal files il, i2, . . . , ik with the relative files rl, t-2, . . . , rk of the subsystem currently in operation. Position in the list establishes the relative file to’which it is assigned. Thus the command FILES 10 20 causes internal file 10 to be associated with relative file t-1 of the subsystem currently in operation, and internal file 20 to be associated with r2. The FILES command may occur at any time during execution of a subsystem. Hence, the global files associated with a subsystem can be changed dynamically. In addition to the above, there are a number of POLO commands available as aids to debugging of new systems. Space does not allow for their presentation in this paper. EXAMPLES
The following contains two examples which demonstrate the use of POLO commands. The first is designed primarily to demonstrate subsystem and input stream control. The second demonstrates global file manipulation capabilities. Example 1
Assume that subsystem A is a complete subsystem whose operation can be logically divided into a number of separate parts. For the purpose of demonstration herein, two parts Al and A2 are used. In normal use, the flow of data would cause A2 to be executed immediately after Al. However, it is necessary for this job to interrupt normal processing
Problem Oriented LanguageOrganizer
567
and execute subsystem B before executing A2. For example, B might be used to modify the results of Al before proceeding to A2. The process is illustrated in Fig. 6. Assume further that the POL input data for part Al is on two sequential disk Cles which have been assigned internal numbers 25 and 28, and that the data for A2 is on internal file 36. The POL input data for subsystem B is on cards to be entered in the card reader. The latter is designated as internal file No. 5. The necessary commands and data flow are shown in Fig. 7. Example 2 The analysis problem used in the first part of the paper can be used to demonstrate the use of global files within POLO. The program and file layout are shown in Fig. 8. Assume that the following exist : 1. Subsystem TRANSFORM,
which is used to move data, and/or transform data stored in global tiles. The subsystem requires two relative files, rr and r2. POL input commands describing the required moves are entered through the input stream. The relative ties do not require a specific tie structure and are used as follows: rr = input global files r2 = output global files
2. Subsystem ANALYZE which performs the desired computations. ANALYZE uses two relative tiles rr and r2. Relative tie rr is the input tie with tie structure
--*-Normal
L
This Job
---+-,
Path Subsystrm 6
. 0
Subsystsm
A
Part A2
FIG. 6. Programflow in example1.
568
L.
,,
A.
FINISH
LOPEZ
I
IV
RUN 8
FIG. 7. Data for example 1.
ANALYZE 1NPUT; r2 is the output file with file structure ANALYZE OUTPUT. The file definitions were created when the ANALYZE subsystem was defined and are stored in the library. 3. A project file, its file definition, and project data. With respect to Fig. 8, the project tie has been assigned to internal file 10. 4. Two sequential files. The first, which is shown as internal file 30 in Fig. 5, contains POL input commands which describe the movement of data from the project file to the ANALYZE input file. The second, which is shown as internal file 35 in Fig. 8, describes movements from the ANALYZE output file to the project file. The corresponding card input stream is shown and described below. FORMAT
20 FROM
ANALYZEINPUT
FORMAT
15 FROM
ANALYZEOUTPUT
RUN TRANSFORM OPEN 10 CODE=PROJECT
FILES INPUT
10 20 FROM
FILES 30 5
I. Global file 20 is a new file. Prepare it for use as an input file to the ANALYZE subsystem by putting the proper file definition on the file. 2. Prepare global file 15 for use as an output file for the ANALYZE subsystem. 3. Initiate the TRANSFORM subsystem. 4. Global file 10 is the project file. This is an old tilecontainingdata to be used in this run. This statement programmatically attaches the file to POLO. 5. Assign relative files to subsystem TRANSFORM. Global tile ri=lO=input file; global file r2=20=output file. 6. File 30 contains POL input commands which cause TRANSFORM to interpretively move data from the project file to the ANALYZE input file. After reading these commands the POLO system returns to the card reader for more data.
569
Problem Oriented Language Organizer
7. Protect the project file. 8. Initiate the ANALYZE program. 9. Assign relative files to subsystem ANALYZE. File ri =20=input tile; file rz-15=output the.
SECURE 10 RUN ANALYZE FILES 20 15
10. Read POL commands for analysis.
(POL1
11. Leave ANALYZE and return to TRANSFORM. 12. Reassign relative ties for TRANSFORM. File rr=15=ANALYZF outnut tile becomes input to TRANSFORM; & r2=lO=project file becomes output to TRANSFORM. 13. Read commands to move data from output to nroiect file. Return to card reader when done. 14.. ciose all files and terminate the job.
EXIT FILES 15 10
INPUT FROM FILES 35 5 FINISH
Format From ,WALYSEOUTPUT
Formal From ANALYSEINPUT ANALYSE
TRANSFCftM
.I
I
Project Fllr
‘Blank* Fllr To Ba Used For ANALYSE Input File
‘Blank* Flh To Be Uwd For AN$= Output
\ %@antiol File ContainWig CcmmordcTo Mow Dota From Project File To ANALYSE Input File
6
Sqwntiol Fllr Containing Commands To Mow Data Fmm ANALYSE Output File To Pmjrct Fh
Fro. 8. Program and layout for example 2. SUBSYSTEM
GENERATION
As shown in Fig. 5, there are three components of subsystems which are of concern to the subsystem developer; they are the subsystem subprograms, the subsystem grammar, and, if the subsystem requires specific global file structures, the required file definitions. The process of creating and interconnecting components is described in the following paragraphs.
510
L.
A. LOPEZ
The tabular form of the grammar used by the translator would be rather difficult to develop by hand. Hence a POL called “G” is available for use by POL writers [7]. New POL’s are described by writing a grammar in language “G.” The grammar is then compiled by the POLO subsystem GENERATOR. The resulting tabular form of the grammar is automatically stored in the POLO library and available through a RUN command. Similarly, the tabular form of a file definition is not convenient to create by hand. However, the POL called “F” which corresponds to the POLO subsystem FILES, provides POL developers with a convenient method of describing their data structure to POLO. The resulting file definition is automatically saved in the POLO file definition library for future use and reference. With the above in mind, creating a new subsystem reduces to the following steps: 1. If the subsystem is to use global files, describe the structure of these files to POLO subsystem FILES so that the required file definitions can be created and stored in the library. 2. Write a grammar for the POL in language “G,” and compile it using subsystem GENERATOR. 3. Write the required subprograms in a procedural language such as FORTRAN. The only restrictions are that variables referenced in the grammar must be placed in the communications vector which, in FORTRAN is the labeled COMMON “TGUSER.” Variables at the top of “TGUSER” are static and do not move during subsystem execution. Hence subprograms may access them as arguments in subprogram calling sequences and/or as variables in COMMON. Variables residing in global files must be passed by the grammar to the subprograms as arguments in the subprogram calling sequence. The reason for the latter restriction is that data from global files is stored both on disk and in the dynamic pool shown in Fig. 4. A reference within the grammar to global file data causes that data to be located and transferred to memory if it is not already present. The current location of the data is established by the POLO translator just prior to calling a subsystem subprogram and it is then passed as an argument to the subprogram. When control is passed to the subsystem subprogram, the dynamic pool is “frozen,” i.e., no movement of data is permitted, and variables passed as arguments appear as normal FORTRAN variables to the subprogram. Thus, using global files, provide a subsystem with a virtual memory. 4. Once written, the subprograms must be compiled and attached to POLO. These operations are accomplished using the standard compilers and loaders of the computer being used. Overlays are specified using loader control cards. The entire process is illustrated in Fig. 9. The new POLO program, grammar library, and file definition library shown at the right side of the figure represent the POLO configuration of Fig. 5. The card images at the left of the figure represent the POL. developers input. STATUS
POLO is being implemented in four stages designated POLO I, II, III, IV. POLO I which consists of the system reported herein excluding data management, has been in
571
Problem Oriented Language Orgauizer
I I I
I
I I I I I
I _ I
Complete POLO
I I
Fm. 9. Subsystem generation.
at the University of Illinois on the IBM 360/75 (Batch) at the Department of Computer Science and the Burroughs B5500 in the Department of Civil Engineering (time shared), for approximately one year. The amount of primary memory required is, of course, subsystem dependent. Subsystem GENERATOR currently runs in 150 k bytes on the IBM 360. Overlays could easily reduce this to 100 k or less. The system runs reasonably well on both machines. Conversion of the original 360 version to the B5500 took one man approximately three weeks. operation
Lack of integrated data management restricts POLO I to development of stand alone systems. Experience with the system has shown that the POL language generating facility is relatively easy to use; students with l-l l/2 semesters of programming experience can easily develop POL’s under POLO I. POLO II, which is the version described herein, is in the latter stages of debugging and is expected to be operational on the U. of I. facilities in December, 1971. An interpretive data inquiry, display, and transformation system, which will handle the duties of TRANSFORM in the example, will be developed in the Spring of 1972. Utility subsystems for determining the status of POLO subsystems will be added at that time.
512
L. A. LOPEZ
POLO III and IV are additions to POLO II which will be developed starting in the Fall of 1972. In general they will consist of (a) adding POST [8] to POLO; and (b) adding subsystems which will aid engineers in the processing of design constraints and in the resolution of conflicts which result from the constraints [9]. SUMMARY
A prototype computer system, POLO, has been developed. POLO allows engineers to easily develop and integrate POL driven programs, thus providing engineers with an environment for both developing and using computer-aided design systems. POLO is based on the Translator-Generator and ICES concepts. However, the integration of data management with subsystem development adds a powerful tool for designers to use in developing and integrating new design systems. REFERENCES [l] E. L. MURPHREEand J. W. MELIN, Experience with a POL Environment. J. Structural Div. ASCE, 97, (No. STI), 301-314. January (1971). [2] E. L. MURPHREBand S. J. FENVES,A generator for translating certain problem oriented languages. CESL Series No. 1, University of Illinois, September, (1967). [3] E. L. MURPHREE,J. W. MELIN and S. J. FENVE~, Environment for problem oriented languages. J. Structural Div. ASCE, 92, (ST6) 167-178, December (1966). [4] D. Roos, ICES System Design, MIT Press (1966). [5] F. J. HATFIELD and S. J. FENVES, An Information Organizer for Co-ordinating Modular Programs, CESL Series No. 5, University of Illinois (1970). [6j S. J. FENVFS, Scenario for a third computer revolution in structural engineering. J. Structural Div. AXE, 97, (No. STI) 3-12, January (1971). [7] L. A. LOPEZ, POLO I-User’s manual for subsystem generator. CESL series No. 6. University of Illinois (1970). [8] J. W. MELM, POST: Problem oriented subroutines translator. J. Structural DIV. ASCE, December (1966). [9] R. N. WRIGHT, J. W. MELIN and L. T. BOYER, Constraint processing in design. J. Structural Div. ASCE, 97, No. STl, January (1971). (Received 26 July 1971)