Hanford Mark I(ID:2792/han003)Report generating languagefor the town with the Nuclear facility Report generating language from GE Fry and Sibley: "The patriarch of today's RPG system was developed at the Hanford (Washington) operations of the Atomic Energy Commission, which was then managed by the General Electric Company. In 1956 Poland, Thompson, and Wright developed a generalized report generator (MARK I) and a generalized sort routine for the IBM 702." Places Related languages
References: Internal computational methods are fairly well handled at this t.ime. The emphasis at the moment is on getting much better coding for handling input and output, the preparation of reports, and file maintenance. I have concluded that people now engaged in scientific programming have a very complacent attitude, perhaps by virtue of being prior in the field. I was recently accused of being "futuristic" for recommending that an output-report generator be constructed for the 709 by the SHARE group. Fortunately, this had been demonstrated by the General Electric Hanford Report Generator for the 702, a couple of machines back. The next step for scientific users is to get adjusted and learn the many techniques developed by the business and data-processing people. Input editing, file maintenance, and report generation remain relatively unknown techniques to the scientific user, and, although he will decry this with specious arguments, he nevertheless needs them badly. He can learn much from existing business systems about basic assembly features, generators, diagnostic back-talk, macroinstructions, etc. Extract: Summary Let me elaborate these points with examples. UNICODE is expected to require about fifteen man-years. Most modern assembly systems must take from six to ten man-years. SCAT expects to absorb twelve people for most of a year. The initial writing of the 704 FORTRAN required about twenty-five man-years. Split among many different machines, IBM's Applied Programming Department has over a hundred and twenty programmers. Sperry Rand probably has more than this, and for utility and automatic coding systems only! Add to these the number of customer programmers also engaged in writing similar systems, and you will see that the total is overwhelming. Perhaps five to six man-years are being expended to write the Alodel 2 FORTRAN for the 704, trimming bugs and getting better documentation for incorporation into the even larger supervisory systems of various installations. If available, more could undoubtedly be expended to bring the original system up to the limit of what we can now conceive. Maintenance is a very sizable portion of the entire effort going into a system. Certainly, all of us have a few skeletons in the closet when it comes to adapting old systems to new machines. Hardly anything more than the flow charts is reusable in writing 709 FORTRAN; changes in the characteristics of instructions, and tricky coding, have done for the rest. This is true of every effort I am familiar with, not just IBM's. What am I leading up to? Simply that the day of diverse development of automatic coding systems is either out or, if not, should be. The list of systems collected here illustrates a vast amount of duplication and incomplete conception. A computer manufacturer should produce both the product and the means to use the product, but this should be done with the full co-operation of responsible users. There is a gratifying trend toward such unification in such organizations as SHARE, USE, GUIDE, DUO, etc. The PACT group was a shining example in its day. Many other coding systems, such as FLAIR, PRINT, FORTRAN, and USE, have been done as the result of partial co-operation. FORTRAN for the 705 seems to me to be an ideally balanced project, the burden being carried equally by IBM and its customers. Finally, let me make a recommendation to all computer installations. There seems to be a reasonably sharp distinction between people who program and use computers as a tool and those who are programmers and live to make things easy for the other people. If you have the latter at your installation, do not waste them on production and do not waste them on a private effort in automatic coding in a day when that type of project is so complex. Offer them in a cooperative venture with your manufacturer (they still remain your employees) and give him the benefit of the practical experience in your problems. You will get your investment back many times over in ease of programming and the guarantee that your problems have been considered. Extract: IT, FORTRANSIT, SAP, SOAP, SOHIO The IT language is also showing up in future plans for many different computers. Case Institute, having just completed an intermediate symbolic assembly to accept IT output, is starting to write an IT processor for UNIVAC. This is expected to be working by late summer of 1958. One of the original programmers at Carnegie Tech spent the last summer at Ramo-Wooldridge to write IT for the 1103A. This project is complete except for input-output and may be expected to be operational by December, 1957. IT is also being done for the IBM 705-1, 2 by Standard Oil of Ohio, with no expected completion date known yet. It is interesting to note that Sohio is also participating in the 705 FORTRAN effort and will undoubtedly serve as the basic source of FORTRAN-to- IT-to-FORTRAN translational information. A graduate student at the University of Michigan is producing SAP output for IT (rather than SOAP) so that IT will run on the 704; this, however, is only for experience; it would be much more profitable to write a pre-processor from IT to FORTRAN (the reverse of FOR TRANSIT) and utilize the power of FORTRAN for free. in "Proceedings of the Fourth Annual Computer Applications Symposium" , Armour Research Foundation, Illinois Institute of Technology, Chicago, Illinois 1957 view details Historically, the whole area goes back to the General Electric Hanford system of Report and File Maintenance Generators for the IBM 702. This led to the development by SHARE of 9Pac for the IBM 709 and SURGE for the 704. These were nonprocedural languages with implied file maintenance and report generation func- tions. There were neither read nor write commands in these languages; they were completely declarative. The assumption was that if you ran the report generator you would get reports; if you ran the file maintenance generator you expected to maintain the file. The Honeywell FACT compiler successfully extracted many of the file disciplines from SURGE and imbedded them in a procedural language with declarative statements defining record structures. These ideas, that were used on a one-dimensional scale (for operating on magnetic tapes) in the 702 Report Generator, SURGE, 9PAc and FACT, were expanded to handle an n-dimensional or graph type structure on a random access device in the GE Integrated Data Store. Today's discussion is concerned with a back-fitting of the Integrated Data Store's concepts of data declarations and record processing commands to serially stored files, to create a unified generalized approach for all classes of data devices. in [ACM] CACM 9(03) March 1966 includes proceedings of the ACM Programming Languages and Pragmatics Conference, San Dimas, California, August 1965 view details in [ACM] ACM Computing Surveys (CSUR) 8(1) March 1976 view details |