FLAIR(ID:72/fla003)Autocode for 650for Full LAnguage for the Instruction of Rockets? Assembler for IBM 650 developed by Bemer and Bosak at Lockheed Missile Systems Division in Georgia, operational 1955 from Bemer 2001 "In the summer of 1955 I was working at the Missile Systems Division of Lockheed Aircraft Corporation, where I had started their computing section from scratch. We had first a CPC, then 650's. And were looking forward to a 704. In fact, I was the Lockheed MSD representative to the first meeting of SHARE, in 1955 August. But then a new research division was formed under a Dr. Ernst Krause. He had hired his own computer chief, Dr. Werner Leutert (it may be strange fate that, when I became Director of Systems Programming for UNIVAC some 6-plus years later, I replaced that same Dr. Werner Leutert). [...] Charlie DeCarlo, then Director of Applied Science, knew of the work that Bob Bosak and I had done on FLAIR for the 650. It seemed to match his needs. So I went to New York to talk." Bemer 59 has it as ported to the 704 by Convair People: Hardware: Related languages
References: 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 in "Proceedings of the Fourth Annual Computer Applications Symposium" , Armour Research Foundation, Illinois Institute of Technology, Chicago, Illinois 1957 view details in [ACM] CACM 1(11) (October 1958) view details Bob Bemer states that this table (which appeared sporadically in CACM) was partly used as a space filler. The last version was enshrined in Sammet (1969) and the attribution there is normally misquoted. in [ACM] CACM 2(05) May 1959 view details in E. M. Crabbe, S. Ramo, and D. E. Wooldridge (eds.) "Handbook of Automation, Computation, and Control," John Wiley & Sons, Inc., New York, 1959. view details in [ACM] CACM 6(03) (Mar 1963) view details 650 Usage at Lockheed MSD Our work in producing FLAIR (called FACS at Lockheed, Georgia) paid off because we got applications running quickly. Many started in February 1955 on that first machine. A second 650 system (Serial No. 37) was accepted in May, and a third in July. The local paper reported that it was up and running in 96 minutes, where the first two had taken three and a half hours each. The 650 was reliable, beyond the expectations of IBM, as we viewed it. (I had a self-checking board on the very first CPC, at the Rand Corporation; I could see a bug growing by the increasing number of times the same computation was performed to get a correct answer.) We often ran 650s unattended (had IBM known it they might have taken them away, or at least raised a fuss). We had to. Some trajectory calculations ran for very long times, and we did not have a three- shift operation. We also ran them over weekends, after preparing the guards to inspect them on their rounds, with instructions on how to stop them if certain lights turned on. IBM used the Lockheed MSD installation as a showcase for prospects. We received thanks from IBM Applied Science, under Don Pendery; Collins Radio; General Electric in Idaho; Fred Brown, IBM branch manager; and many others. Extract: PRINT I Intermission In December 1955, I left the 650 world by joining IBM to write a processor for doing scientific work on the IBM 705, which was a decimal and alphanumeric machine designed originally for commercial work. PRINT I was a considerable step up from the system we had done for the 650. Although PRINT I was interpretive in execution, an initial process removed as much redundancy as possible from the executing program. PRINT was also the first load-and-go system. PRINT I was designed and built in the same office complex as FORTRAN, and I watched that work with interest. Design started in December 1955. I gave a talk to the Western JCC in February 1956. PRINT I was field operational by August. Obviously it was time for new work! in Annals of the History of Computing, 08(1) January 1986 (IBM 650 Issue) view details Resources
|