Transaction-Flow World-View: GPSS/H's transaction-flow world-view provides a very natural and powerful way of describing systems.

- Allows the user to construct models of computer systems, communication networks, transportation and distribution systems and manufacturing and material handling systems.

- Has a debugger for model verification.

- Employs control statements that allow the user to write small programs for experimental control.

- A macro capability lets the user express systems that contain many similar elements in more compact form.

- Needs only that the user describe the inputs, logic and constraints of a system to run the model for a simulated time period.

- Can use symbolic names for almost any simulation construct and logic switches that help the user track state changes.

- Gives a set of built in math functions and random variate generators. - Has general purpose global information variables and arrays for storing and manipulating numeric and character string data.

- 2D matrixes allow for manipulation of complex input data.

High Performance: GPSS/H provides lightning fast compilation and execution of large models.

Language Flexibility: You can use math formulas, expressions, indexed resources, or constants in your Block or Control Statements for maximum modeling flexibility.

Easy queue control: GPSS/H makes it easy to model complex queueing methods. You won't have to do laborious programming in Fortran or C to get the flexibility you want.

Models easily driven by real-world data: You can read data directly into GPSS/H from an external file or from the keyboard. GPSS/H's built-in ASCII file I/O lets you change your data and perform experiments without altering the basic model.

Can read ASCII information from a file or the keyboard and write custom formatted text and information to a file or the screen.

Sophisticated internal tools: You can rely on GPSS/H's built-in algorithms to enhance the statistical integrity of your model during execution.

Standard or custom output: GPSS/H automatically provides basic simulation output data such as utilization and queueing statistics. You can also write custom-formatted text and data to a file or to the screen so you get exactly the information you want.

Versatile scripting language for conducting experiments

GPSS/H Control statements are so versatile that you can write small "programs" to perform an experiment. This method of experimental control is far more flexible than the rigid "experiment frame" approach used by other languages.

GPSS introduced the transaction-flow modeling paradigm. Under this paradigm, active "consumer" objects, called transactions, travel through a block diagram representing a system, competing for the use of passive "server" objects. This modeling paradigm is extremely general and has been adopted in a large number of simulation languages. Terminology differs from language to language. Transactions may be called items, entities, tokens, etc., but the basic architecture is the same: active objects compete for passive resources while traveling through a diagram representing a system.

GPSS was designed by Geoffrey Gordon as a tool for use by non-programmers. It is interesting to note that over 40 years later, “no programming required” is still featured as a virtue in advertisements for simulation software. Historically, GPSS models were developed by drawing block diagrams and manually typing character-based representations of blocks. Over time, the sizes of GPSS models grew well beyond what Geoffrey Gordon had ever anticipated. While drawing a 100-block diagram is relatively easy, drawing a 5000-block diagram is difficult. As users began developing larger and larger models, and as they became more comfortable with typing in blocks without first having drawn them, GPSS came to be viewed as a true programming language.

GPSS/H was first placed into commercial service in November, 1977. Over the ensuing years, it has become well known for its speed and dependability. In GPSS/H, the transaction flow world view has been extended with many advanced features to make an extremely powerful and flexible tool capable of handling large, complicated models with ease, yet still providing exceptionally high performance.

GPSS/H has been a very successful product. Its success is the result of both the superiority of its original design and subsequent years of improvement and enhancement. Most of the enhancements developed for GPSS/H have been improvements to it as a programming language. The landmark modeling concepts developed by Geoffrey Gordon remain largely intact, although improvements and additions have been made to them, as well.

Since it is a simulation language, GPSS/H requires some programming-style effort, but it does so within the intuitive modeling framework Gordon designed to be readily used without extensive programming experience. It is well suited for modeling both simple systems and large, complex systems.

Although many new simulation tools have been introduced over the past decade, they have often been designed for specific classes of applications. In strong contrast, GPSS/H continues to be one of the most general, flexible, and powerful simulation environments currently available. GPSS/H is in use around the globe modeling manufacturing, transportation, distribution, telecommunications, hospitals, computers, logistics, mining, and many other types of queuing systems.

Representing a System in GPSS/H

In a GPSS/H model a transaction can represent a patient, a telephone call, a truck, a data packet, or any other type of individually identifiable entity that has a behavior. As a model executes, many transactions can flow through the model simultaneously—just as many “objects” would move through the real-world system being modeled. In addition, while flowing through the model, multiple transactions can execute the same GPSS/H model statements at the same instant in simulated time without any intervention by the modeler. The execution of a process-interaction simulation model is thus similar to a multi-threaded computer program. This differs greatly from the single-threaded, sequential execution of most general-purpose programming languages, and is a good reason why such languages are usually poor tools for writing simulation models.

Many simulation projects focus on the optimal use of system resources such as people, machines, conveyors, computers, physical space, and so on. In a GPSS/H simulation model, transactions compete for the use of these system resources. As transactions flow through the process representation, they automatically queue up when they can’t gain control of a necessary resource. The modeler does not have to specify the transaction’s waiting time or its queuing behavior for this to occur. Hence, the passage of time in a GPSS/H model can be represented implicitly, as in the case of a part waiting for a machine to become free, or explicitly, as in the case of a part being processed by a machine.

A GPSS/H model, like most real-world systems, may consist of multiple processes operating at the same time. Furthermore, each such process may affect the other processes in the system. For example, two parallel manufacturing processes may converge to a single inspection point where they are competing for a single resource, e.g., an inspector. GPSS/H provides the capability for multiple parallel processes to interact with each other automatically. Transactions (“objects”) may be sent between processes; they may control or share common resources; or they may influence the (global) operation of

Ease-of-Use

The presence or absence of a single characteristic—such as a “visual” interface for building models—is insufficient to determine a tool’s ease-of-use. Whether a tool is “easy to use” depends upon the combination of general characteristics and specific features that are heavily used when real-world models are built.

Moreover, the ease-of-use that is claimed for almost all simulation tools can mean many things—that the tool is easy to learn, easy to use once learned, easy to use when modifying models, easy to use when building simple models, or easy to use when building large, complex models. Rarely is a product equally good at all of these, but equally rarely is the prospective user informed about which “ease-of-use” is being claimed.

Another meaning, which is often overlooked yet very important when modeling complex, real-world systems, is that of ease in verifying that the tool’s inner workings, when running the model, are accurately mimicking the operation of the actual system. If such verification is difficult, it may not be done. The risks of not doing it have been pointed out by Schriber and Brunner (1997).

A simulation language’s ease-of-use is rarely constant over the duration of a simulation project. The ease-of-use of a tool that is optimized for developing small models may diminish as a model gets larger and larger, and more details of system operation have to be incorporated into a model. Conversely, a tool that requires a bit more study to master may be harder to use in the early stages of a project, but offer downstream rewards when it is able to meet modeling requirements for a large, complex system. Scalability of technology is an important contributor to ease-of-use. GPSS/H has excellent scalability. It is able to handle very large models (10’s of thousands of blocks) and

Model Validation & Debugging

The GPSS/H Interactive Debugger provides invaluable assistance for rapid model development and verification. Prior to the advent of GPSS/H in 1977, most simulation tools featured batch-oriented, non-interactive debugging. To debug a model, one typically generated a large trace file and very carefully proofread the trace file to verify model correctness.

In GPSS/H, simple debugger commands are used to control a model’s execution and to examine its status. Functions are provided to “step” through the model, to set breakpoints and traps that interrupt model execution based on multiple criteria, and to return to a previously saved state of the model. Almost all data values can be examined, including local data, global data, transaction attributes, entity statistics, and array data values.

The debugger provides a “windowing” mode that displays source code, model status, and interactive user input as the model runs.

A modeler can interrupt a long-running model at any time and use the debugging features to make sure that everything is running correctly before resuming execution.

The GPSS/H debugger has almost no effect on execution speed. Because of this, many modelers use the debugger as their everyday run-time environment for GPSS/H. As you build your model, you want to feel confident that it's right. Our sophisticated debugger is a quick and efficient tool for verifying your model. Unlike many debuggers, GPSS/H gives you access to virtually all of your data, and it doesn't slow down model execution.