FOSIL(ID:611/fos001)Portable job control languagefor Fredette's Operating System Interface Language. A portable job control language, for IBM OS360, UNIVAC EXEC 8 and Honeywell GCOS. References: INTRODUCTION In the years since the first computer was introduced in 1943, there have been many programming languages developed as well as many different dialects of these languages, used for programming. The proliferation of languages and dialects of languages provided the impetus to control and standardize a few of these languages in an attempt to lower the cost of (1) conversion between systems, (2) programmer training, and (3) compiler development. The results have been acceptable in that there are International Standards for COBOL, FORTRAN, and ALGOL. The implementation of these standard languages has certainly been adequate in that the results have shown that programs written in COBOL, FORTRAN, and ALGOL are easily converted from system to system. This is assuming that only common language elements defined by their appropriate standard are used in programming each system. Although the input to control the operating system is not necessarily a "language" per se, it certainly has a dialect, which in most cases varies significantly from system to system. The efforts in the past to standardize or influence the differing dialects with which we communicate with operating systems has been at best inept compared to the attention given to programming languages. It appears that attempting to influence the development of a specification that effects only a part of the total system (i.e. programming language/compiler) is more easily justified than an attempt that would influence the total system (i.e. operating system). Extract: BACKGROUND BACKGROUND The past several years have been spent by the author in working with what is now known as the U. S. Navy COBOL Compiler Validation System (CCVS). The COBOL compiler validation system consists of audit routines, their related data, and an executive routine (VP-routine) which prepares the audit routines for compilation. Each audit routine is a COBOL program which includes many tests and supporting procedures indicating the result of each of the tests. The audit routines collectively contain the features of American National Standard COBOL (except for the Report Writer module and the ENTER statement of the Nucleus module), as specified in X3.23-1968. An interface routine creates a file containing the audit routines with implementor names inserted in the source code, and the operating system control statements required for compiling and executing each routine. The problems that have been circumvented by the use of an interface program, have been the selecting, updating and editing of programs, as well as the generation of operating system control statements to compile and execute the programs being selected. A broad amount of experience has been gained, as to the similarities between operating systems, based on the implementation of the CCVS on all major computers used in the United States. There is a common subset of functions among the various operating systems but there is no common subset as to the dialect used in defining the functions. For example, in running the CCVS the number of actual operating system control statements required for compiling and executing the 120 programs may vary from 240 to 5,640. This is an average of between 2 and 47 operating system control language statements per program. The functions being requested/accomplished are logically identical however, the method of communication varies radically. The VP-Routine could be considered to be an interface between the user and the operating system with a very limited number of functions. In the case of a system on which the VP-Routine is implemented, one of its commands is, in effect, a request to initiate an independent task which will consist of the compilation and execution of one or more COBOL programs. This particular processor may not be adequate for most requirements for operating systems interface but for what it was designed to do, it not only does quite well, but accomplishes it in a reasonable and simple fashion. For example the two commands: *ENVIRONMENT OS360 +NC101 would request that program NC101 be processed (+NC101) and the operating system control statements should be those required by IBM's Full Operating System for the 360 line of computers. Furthermore the simple fact that the VP-Routine is able to interface with many systems demonstrates the philosophy that a preprocessor could be designed which would provide a much broader level of functional interface. As with high level languages the input to the processor would be the same regardless of the host system and the output would reflect operating system control statements necessary to direct the host operating system. The above conclusions led to the idea of producing a preprocessor to demonstrate the feasibility of an interface between a user and an operating system. As a result we are attempting an experimental implementation of Fredette's Operating System Interface Language (FOSIL). The initial implementation will interface with three systems, IBM OS, UNIVAC EXEC 8, and Honeywell GCOS. Extract: PHILOSOPHY PHILOSOPHY The philosophy of FOSIL is to provide an interface between a knowledgeable user and more than one operating system. (An analogy would be the use of COBOL which permits a user to write programming language statements which could be accepted and compiled on any system supporting COBOL.) This results in a user, who is not necessarily intimately involved with particular operating system intricacies, being able to take full advantage of an operating system through the use of FOSIL. FOSIL is not intended to conquer the world of operating systems nor to solve all the problems of incompatabilities recognized between the different computer's operating systems. The definition of FOSIL results in a functional capability which can be described as a cross-section of functions, common to the three host operating systems on which FOSIL is being implemented. This common function concept may not result in a one for one correspondence between the operating system control statements for the various systems but a functional capability which can be accomplished on each of the host systems. This is to say that, a function may be accomplished by a single operating system control statement on one system while another system may require many operating system control statements. The use of FOSIL therefore, as in the case of compilers, may not permit the user to take advantage of highly innovative functional capabilities which are present in a given operating system due to the lack of a corresponding facility being available on all host systems. The design and implementation of FOSIL is intended to demonstrate the feasibility, usefulness, and need for a high level operating system language. The basic philosophy of FOSIL does not include an attempt to provide a "shorthand" operating system control language. In some cases the FOSIL control statements may be verbose compared to the actual control language being generated, but keep in mind the idea of FOSIL is to provide a machine independent operating system language to accomplish data processing functions. An outgrowth of this implementation experiment should be the demonstration of a need for the controlled development of a standard, or a least a set of guidelines, for both the functions which should be included in an operating system and the syntax by which those functions should be implemented. There are several basic functions supported by FOSIL which enable a user to (1) identify himself to the system, (2) initiate the compilation of a FORTRAN or COBOL source program (this is not to preclude other languages, however, the idea of having a machine independent operating system language would require the use of machine independent languages not assemblers, etc.) (3) execute an object program (most logically the result of a compiled COBOL or FORTRAN program), (4) request facilities for the execution of a compiler or object program (requiring work files, previously created files, files being created; core requirements, etc.) The creating of a FOSIL control unit which contains both the source programs and the necessary FOSIL control statements to accomplish a particular data processing task would enable the user to process this FOSIL control unit on any system on which FOSIL had been implemented. The implementation of FOSIL on the chosen test systems will demonstrate the ability to have a common interface between the outside world and an operating system. This also demonstrates the fact that manufacturers could provide translators for FOSIL or any standardized operating system language just as they have compilers today for standard programming languages. Just as a COBOL or FORTRAN programmer need not understand the architecture or the machine language of the computer he is programming, he would not be required to have knowledge of the operating system control language of the computer for which he is setting up a FOSIL application. in Unger, Claus (Ed.) Command languages: Proceedings of the IFIP Working Conference on Command Languages (Lund, Sweden, August 1974) North-Holland, 1975 Amsterdam, The Netherlands view details |