GEMS(ID:5499/gem003)GE Manufacturing Simulatorfor GE Manuafacturing Smulator System designed by Markowitz with Mort Allen at GE for the US Airforce. PRoved to disappointing to Markowitz, who left to develop his ideas at RAND. Related languages
References: Some time after LP1 was finished I got an offer I couldn’t refuse from the General Electric Company, eventually moving to its Manufacturing Services at GE Headquarters in New York City. Alan Rowe was already there and had just supervised the programming of a large, detailed job shop simulator programmed in assembly language. Alan designed this simulator with a particular GE shop as an initial application, but with many input parameters whose specification were to tailor the model to other shops. But when Alan went to apply the model to a next GE shop it turned out not to be as general purpose as hoped. Upon reviewing Alan’s experience my own theory at the time was to reduce programming time and increase flexibility by building the next big shop simulator in FORTRAN II, constructing it as a system of reusable subroutines. I soon had the opportunity to test this theory. Together with a team of GE Transformer Department manufacturing engineers, and Mort Allen who programmed the model, I participated in the development of GEMS, the General Electric Manufacturing Simulator. GEMS was well received within General Electric. Manufacturing Services conducted internal GE seminars on MSS (Manufacturing Systems Simulation) with GEMS as a principal topic, and we soon got a request to simulate another GE shop. In the process of building a simulator for this next GE shop it became apparent that GEMS was not as flexible as I had hoped. As to GEMS’ reusable subroutines, the routines which proved most reusable performed basic actions like linking jobs into queues, or events into the calendar of coming events. My next hypothesis was that such facilities could be placed at the disposal of the simulation programmer more conveniently as part of a simulation language rather than as subroutines. I didn’t want to write this simulation language at General Electric, since it seemed (given my situation within GE at the time) that it might be deemed proprietary, for internal GE use only, and I wanted to see the ideas disseminated. I went into the job market seeking a new home for me and my nascent simulation language and ended up returning to RAND. Yes. Anyway, I had read [the manual] and I thought FORTRAN I was wonderful. You didn’t have to talk to programmers; you could program yourself. Those were the days when programming manuals were less than one hundred pages. I had a theory that what we could do is make reusable modules, putting them in FORTRAN. A GE department presented itself and wanted simulation. Mort Allen did the programming. We thought about the program and built this General Electric manufacturing simulator. That worked just fine for the first department. We gave lessons; we’d have seminars within General Electric about how you should use manufacturing simulators. We called this particular manufacturing program GEMS (General Electric Manufacturing Simulator), and we thought GEMS could have a lot of applicability. I heard years later, after I left General Electric, that there were at least a few die-hards in there using GEMS. But it turned out that it didn’t have all that much flexibility, and these reusable packages weren’t all that reusable, except for a few that did things (like in SIMSCRIPT later), created entities, filed things into sets, kept an event timer and so on. So a new theory evolved. What we needed basically was a language that would do this: put at the programmers disposal the ability to create and destroy entities, et cetera. I decided that if I built that within General Electric, at least within Manufacturing Services, it would be likely to just be used internally. |