GASP

GASP (General Activity Simulation Program) is one of the earliest discrete-event simulation languages. Philip J. Kiviat began it in 1961 at the United States Steel Applied Research Laboratory to model open-hearth steelmaking plants. GASP was not a new compiler. It was a set of FORTRAN subroutines that gave a modeler an event list, a simulation clock, queues and statistics collection, while the modeler wrote the events themselves as ordinary FORTRAN. Because any machine with a FORTRAN compiler could run it, GASP reached places that dedicated simulation languages could not. Alan Pritsker later extended it into GASP II (1967–69) and GASP IV (1973–74), which added continuous simulation, and GASP IV in turn led to SLAM (1979).

History & Origins

U.S. Steel, 1960–1963

In a 2004 Winter Simulation Conference paper, Kiviat described how GASP began. He had done Monte Carlo work as a student at Cornell University and learned FORTRAN, ALGOL, COBOL and assembly language. In June 1960 he joined U.S. Steel’s Applied Research Laboratory in Monroeville, Pennsylvania, to lead a team of industrial engineers building simulation models of open-hearth steelmaking plants. He visited the plants, watched steel being “cooked” and poured, and looked at what others were doing. “In 1961 there wasn’t much to look at,” he wrote, but conversations about K. D. Tocher’s GSP in Britain and about Geoffrey Gordon’s GPSS and Harry Markowitz’s SIMSCRIPT in the United States “set me thinking in the right track.”

He needed a way to describe a plant that the engineers, who were not programmers, could follow. After weighing activity scanning, event scheduling and transaction flow, he chose event scheduling, partly because it was “easy to understand and completely transparent” and partly because he needed something he could use immediately: U.S. Steel’s interest was in models that would improve plant operations, not in simulation research. So he “decided to build my own simulation programming system using FORTRAN as a base language”, with the discrete-event concepts “implemented through functions and subroutines”, and built it while working through the steelmaking models. The result was GASP, and with it the team “successfully built, demonstrated, and experimented with simulation models of several active US Steel open-hearth steelmaking plants.”

The online History of Programming Languages (HOPL) adds that the work was initially based on ALGOL 60 and moved to FORTRAN II by 1962, and that GASP was meant to run on several makes of computer from the start. A preliminary GASP Programmer’s Manual is dated January 1963; a copy survives in Kiviat’s papers at North Carolina State University.

RAND, 1963–1964

Kiviat moved to the RAND Corporation in 1963 to work with Markowitz on SIMSCRIPT II. (He gives 1963 himself; some secondary sources say 1964.) In February 1964 RAND published GASP — A General Activity Simulation Program (paper P-2864) by Kiviat and A. Colker (given as Alan Colker by HOPL). According to RAND’s summary of the paper, the authors accepted that “GASP cannot compete with SIMSCRIPT” but argued that it “serves well those who have only a small machine or who use several computers with no common language.” That trade-off defined GASP for the rest of its life.

Design Philosophy

GASP’s central choice was to be a library, not a language. A 1980 survey for the U.S. Army put it plainly: “GASP is not so much a language as are GPSS and SIMSCRIPT; rather, it is a Fortran simulation interface.” This had clear benefits and costs:

• Portability. Any computer with a FORTRAN compiler could run GASP. This is the advantage the 1964 RAND paper stressed for users with small machines or a mix of computers.
• Openness. The GASP routines were ordinary FORTRAN source, so users could read, modify and extend them. The NASA Skylab report printed the GASP routines it used alongside its own code.
• Cost to the modeler. The 1980 survey noted that “the modeler cannot possibly create a GASP-based simulation without a sound knowledge of the Fortran language”, and that the underlying data structures “must be apparent to the user”. Kiviat drew a similar lesson himself. A modeling language can be built on FORTRAN, he wrote, but “the clarity of the model was often so obscured by the programming baggage” that a dedicated simulation language would do better. He went on to build one: SIMSCRIPT II.

The name reflects GASP’s world view. In Kiviat’s words, “an activity in GASP is bounded by two events that are the starting and ending points of the activity in simulated time. GASP deals with events explicitly and activities implicitly.” In Tocher’s GSP the activity itself holds the model logic; in GASP the events do.

Key Features

The features below are documented for GASP II and GASP IV, which are the versions with surviving published code. The 1963 original is known mainly from descriptions.

Entities, attributes and files

A GASP model is made of entities (jobs, orders, machines, people) described by numeric attributes. Entities wait in files, GASP’s term for ordered lists, which serve as queues and as the event calendar. In GASP IV, attributes are passed through a common array, ATRIB, and the clock is the variable TNOW, both held in GASP’s labeled COMMON block.

The executive and the event routine

The user’s main program sets parameters and calls GASP, the executive. The executive repeatedly removes the most imminent entry from the event file, advances TNOW to its time, and calls the user-written subroutine EVNTS with the event code. EVNTS usually just branches to the routine for that event. Event routines change the state of the system and schedule future events by filing new entries in the event file.

Library routines

The routine names come from the GASP IV call diagram in the 1980 Army survey and the GASP IIA routine listings in the 1971 NASA Skylab report:

The Army survey counted “some 24 routines” in GASP IV, and listed its capabilities as event control, state-variable updating, initialization, monitoring, data collection, statistics, random deviate generation and report generation.

Combined continuous-discrete simulation (GASP IV)

GASP IV added state variables described by difference or differential equations (STATE) and state events that fire when a variable crosses a threshold (SCOND), alongside the ordinary clock-driven time events. The Army survey called it “the only well-documented language that supports both continuous and discrete simulation.”

Example

The fragment below is abridged from the GASP IV single-server CPU model in the 1980 Army survey. The original survives only as an OCR’d scan, so the spelling has been cleaned up. The main program calls the executive, EVNTS dispatches on the event code, and an arrival is scheduled by setting attributes and filing them in the event file (file 1):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

C     MAIN PROGRAM: SET PARAMETERS, THEN HAND CONTROL TO GASP
      CALL GASP
      STOP
      END

      SUBROUTINE EVNTS(CODE)
      INTEGER CODE
C     ...CARRY OUT USER-DEFINED EVENT...
      GO TO (1,2,3), CODE
    1 CALL ARRIVAL
      RETURN
    2 CALL COMPLTN
      RETURN
    3 CALL STOP
      RETURN
      END

C     IN SUBROUTINE ARRIVAL: SCHEDULE THE NEXT ARRIVAL
      ATRIB(1) = TNOW + INTRVL
      ATRIB(2) = ARRIVE
      CALL FILEM(EVENTS)

ATRIB(1) is the event time and ATRIB(2) the event code. When this entry becomes the most imminent event, the executive sets TNOW to its first attribute and calls EVNTS with the second.

Evolution

According to the 1967 GASP II report, as quoted in Wikipedia’s GASP article, Pritsker and Kiviat “decided not to rewrite GASP in FORTRAN IV” so that it would still run on the smaller machines that had only older compilers. A 2009 Winter Simulation Conference history notes that Pritsker also spent the summer of 1969 at RAND working on a version of GASP based on JOSS.

The 1980 Army survey states that GASP IV was developed at Purdue University in 1970 and was then maintained by Pritsker and Associates of West Lafayette, Indiana. The first journal paper on it appeared in 1973 and the book in 1974.

Current Relevance

GASP is a historical language. Pritsker’s own work moved on to SLAM (1979) and SLAM II (book 1984). No maintained distribution or Docker image is known. The GASP II and GASP IV books, which print the source of the routines, are held by many libraries, and the NASA Skylab report reproduces FORTRAN listings of GASP IIA routines such as GASP, FILEM, RMOVE, SET and COLCT. In principle the language could be revived from those listings with any modern FORTRAN compiler, but no such revival could be found.

Why It Matters

GASP is one of the founding discrete-event simulation systems of the early 1960s, alongside GPSS, SIMSCRIPT and Tocher’s GSP. Its lasting contribution was showing that simulation did not need its own compiler: a disciplined set of subroutines on a widely available language could carry a model from one computer to another. That made it the system of choice for people with small machines or mixed hardware, and the design was simple enough to teach, extend and rewrite.

Its lineage is also unusually traceable. Kiviat took the experience of building GASP to RAND, where he became a major contributor to SIMSCRIPT II. Pritsker carried GASP through GASP II and GASP IV to SLAM, whose co-author C. Dennis Pegden went on to develop SIMAN. Kiviat later called his U.S. Steel work the place where he learned that “the most important feature of a simulation language is that it express and communicate modeling-oriented thoughts and concepts.”

A note on sources. The 1961 start date comes from Kiviat’s own 2004 account and is repeated by HOPL and a 2009 Winter Simulation Conference history. HOPL’s reference list for GASP also includes a 1964 Educational Facilities Laboratories booklet, School scheduling by computer — the story of GASP. Its title suggests a school-timetabling system rather than Kiviat’s industrial simulation package, and it is not used here. The encyclopedia index lists 1980 as GASP’s “last commercial” year; the 1980 Army survey confirms GASP IV was still maintained commercially then, but no source dates the end of that support.