GPSS IV for the 360 

General Purpose Systems Simulator Version IV for the IBM 360.
Discrete simulations.

Related languages
GPSS III => GPSS/360   Evolution of
GPSS/360 => GPSS V   Evolution of
GPSS/360 => GPSS/360 - Norden   Augmentation of

  • Felder, Harry "The GPSS/360 random number generator" pp21-28 view details Abstract: This study of yet another URNG has been designated with a particular user of URNG in mind: the General Purpose Simulation System/360 user. By eliminating from consideration such uses of the tested generator as large Monte Carlo calculations on nuclear energy problems, and considering only the typical uses of URNG by GPSS/360 problems, a more suitable testing procedure was devised. Appropriately enough, the URNG studied was the one included in GPSS/360.** (Actually, there are eight URNG in GPSS/360, but they use identical generation schemes.) Each of the eight GPSS/360 URNG has one parameter, a ?multiplier?, which the user may alter, causing a new sequence of random numbers to be generated. The goal of this study was to locate multipliers whose sequences would meet a number of criteria desirable if the sequences are to be used in GPSS/360 simulations.

          in Proceedings of the second conference on Applications of simulations, 1968, New York, New York, United States view details
  • I.B.M., "General Purpose Simulation System/360, User's manual", I.B.M. Publication H20-0326, 1968 view details
          in Proceedings of the second conference on Applications of simulations, 1968, New York, New York, United States view details
  • Gould, R. L. "GPSS/360?An improved general purpose simulator" pp16- view details Abstract: Increased adaptability, versatility, and ease of use are significant advantages offered to the user of the General Purpose Simulation System in this latest version as described in this paper. Modeling capability is especially enhanced by such improvements as new entities and block types and extended features. Also discussed are improved input specifications and an output editor. External link: Online Extract: Characteristics
    The General Purpose Simulation System (GPSS) is an IBM computer program for conducting evaluations of systems, methods, processes, and designs. The latest version of the program, GPSS/360, is compatible with ihs predecessor GPSS 111, and offers significant improvements to the user of this modeling tool. The inclusion of new entities, block types, and expanded features in GPSS/36O increases the adaptability, versatility, and ease of use for a wide range of simulation applications. In addition, output statistics obtained from a simulation run may now be presented in a format specified by the user, and selected statistics may be obtained in graphical form. Knowledge of GPSS, and more specifically GPSS III, is assumed throughout the paper. However, we now briefly review some of the basic concept's of GPSS as described by Hcrscovitch and Schneider.
    GPSS features a simple flowhart language for describing the problem or system to be simulated. When this description is fed into a computer, the program automatically carries out the simulation.
    The system elements are logically represented by a set of abstract elements called entities, and the logical rules governing a system flow are reduced to a set of standard operations. There are four classes of entities: dynamic, equipment, statistical, and operational.
    The dynamic entities are called transactions, representing units of traffic. Equipment entities include such items as facilities, storages, and logic switches that are acted upon by transactions. The statistical entities consist of two types: queues and tables. Blocks constitute the operational entities.
    Control and definition cards prepared from a flowchart of the system provide input for the simulation. The cards make up the model in GPSS language. When the system model has been loaded, the GPSS program generates and moves transactions from block to block according to the timing information and logical rules of the individual blocks.
    In the GPSS III version, structural changes mere made to the basic program. Externally, the most significant change was the elimination of delay-time and selection factor operat'ions from all block types. The modeling capability, versatility, and ease of use of the program were expanded by increasing speed, varying the number of parameters, reallocating storage space, allowing construction of user chains, adding the Attribute Valued function, and adding new blocks and modifying others.
    GPSS/360 operates under control of both the SYSTEM/360 Operating System (OS/360) and the SYSTEM/36O Disk Operating System. GPSS/36O allocates entities according to main-storage size, and the REALLOCATE feature enables the analyst to completely tailor the allocation of main storage to fit the needs of his model.
    This paper is devoted to descriptions and possible modeling applications of the extended features of GPSS/360. The significant features incorporated in the GPSS/360 system can be grouped into the following three general categories:
    - New entities, block types, and extended features which enhance modeling capability.
    - Symbolic entities and features which contribute to ease of use.
    - Output editor capabilities which make output statistics more meaningful.
    The features included in the first category are the most important from the point of view of simulator power and capability.
          in IBM Systems Journal 8(1) 1969 view details
  • Pritsker, A. Alan B.; Kiviat, Philip J.; "Simulation with GASP II: a FORTRAN based simulation language" Englewood Cliffs, N. J.: Prentice-Hall 1969. 344 S. (Prentice-Hall Series in Automatic Computation.) view details Extract: PREFACE

    GASP II is a new simulation language and as such requires careful and complete documentation. The intent of this book is to present GASP II and to use it as a basis for understanding the concepts of simulation. As our aim was not to produce a general text, we felt no need to expound on the scientific method, although simulation is a technique which is used within the framework provided by the scientific method. Our approach is specific ? the book deals with modeling and simulation programming using a particular language. Topics which are closely related to simulation but not covered in this book are experimental design and statistical analysis and verification. The omission of these subjects permitted us to concentrate on simulation concepts and modeling using GASP II.

    GASP II is practical and useful. Being FORTRAN based, it is Relatively easy to learn. Its simulation concepts are quickly grasped Because they are presented in the familiar framework of FORTRAN. A FORTRAN listing of each GASP II subprogram is included in the book, along with detailed flow charts.

    Past experience has shown that simulation modeling is an art. We feel it is mandatory that a student perform simulations while learning to be a simulation analyst and programmer. For this reason, we have included eleven complete simulation studies dealing with queueing situations, inventory systems, network analysis, scheduling, and design. A standard format is used for each example, which includes a problem statement, objectives in solving the problem, special GASP II features illustrated by the example, procedures used in modeling and writing the GASP II program, and a discussion of the simulation reports. Since the emphasis in this book is on simulation using GASP II, the procedures section of each example is pre-sented in detail. FORTRAN listings for all system models are presented, along with a listing of input data cards. Flow charts and final output reports are presented where appropriate.

    GASP II has developed over the past five years at Arizona State University from the original GASP developed at U. S. Steel. The versions of GASP presented in this book are written in FORTRAN IV for the IBM 1130 computer. All examples have been implemented within the capabilities of the IBM 1130, including the limitation of 8K words of storage (16 bits per word). GASP II has also been used extensively on the GE 225, GE 415, and CDC 3400 computers at ASU and is being used at other university, industry, and government installations.

    GASP II has been used as the basis for a course in simulation by the Industrial Engineering Faculty at A.S.U. It has been found that the basic prerequisites for the material in this book are a knowledge of FORTRAN and a familiarity with probability and statistics. The book can serve as an introduction to simulation models at the junior/senior level or can be used to present simulation as a problem-solving technique at the senior/graduate level. Both approaches have been used at A.S.U. with success.

    Many individuals have contributed to the development of GASP II. Foremost is Mr. William J. Thompson, who during the past year assisted in the conversion of GASP II to the IBM 1130 and to the running of the example problems presented in this book. An extended version of GASP II, called GASP IIA, and presented in Chapter 8, is an outgrowth of a term paper by Mr. Mark Jarvis for the previously mentioned simulation course. We gratefully acknowledge the assistance of Mr. Thompson and Mr. Jarvis.

          in IBM Systems Journal 8(1) 1969 view details
  • Bidwell, Edwin L. "Simulation in GPSS/360 of a highway paving operation using a mobile central-mix plant with different haul truck speeds and fleet size combinations" pp172-180 view details Abstract: The simulation program was written to describe a concrete highway paving operation using mobile central-mix plant and slip form paver, in combination with different truck haul fleet sizes and truck speeds. The trucks queue at the plant, load, travel to the slip form paver, queue, unload, and then complete the cycle by returning to the plant. Because the distance, plant to paver, first decreases and then increases as the paving strip moves toward the plant, passes in front, then moves away in the other direction, the trucks' mean arrival rate is not constant. The program is completely probabilistic and provides for truck fleet size, truck haul speed and rate of paving progress to be treated as variables.
          in The 5th Winter Simulation Conference 8-10 December 1971 Waldorf-Astoria Hotel, New York, NY view details
  • Greenberg, Stanley: "GPSS primer". New York: Wiley-Interscience 1972 view details
          in The 5th Winter Simulation Conference 8-10 December 1971 Waldorf-Astoria Hotel, New York, NY view details
  • Kay, I. M. "Digital Discrete Simulation Languages. Discussion and Inventory" view details Extract: GPSS
    GPSS (General-Purpose Systems Simulator). GPSS, developed originally by G. Gordon at IBM, is the most popular discrete-event simulation language. GPSS is process-oriented, containing a repertoire of flowchart-like blocks (Gordon, 1969). It also provides a large variety of autonomously generated measurements about the simulated model. Since its original version, it has appeared in subsequent, more powerful versions: GPSS-II, -III, -IV, -V, and -360. Current versions provide limited capability for using Fortran and assembly language subroutines. GPSS-360 Norden is a proprietary version developed by Reitman and associates, which through a CRT display unit, provides conversational features, user-interactive input, and control.

          in Kay Ira M. and John McLeod,(Eds.), Progress in Simulation. New York: Gordon and Breach 1972 view details
  • Gordon, Geoffrey "The development of the General Purpose Simulation System (GPSS)" view details Abstract: The General Purpose Simulation System (GPSS) is a programming system designed for the simulation of discrete systems. These are systems that can be modeled as a series of state changes that occur instantaneously, usually over a period of time. Complexities in their analysis arise because there are many elements in the system, and there is competition for limited system resources. The simulation technique uses numerical computation methods to follow the system elements through their changes of state, and predicts properties of the system from measurements on the model. GPSS came into existence rapidly, with virtually no planning, and surprisingly little effort. It came rapidly because it filled an urgent need that left little time for exploring alternatives. The lack of planning came from a happy coincidence of a solution meeting its problem at the right time. The economy of effort was based on a background of experience in the type of application for which the language was designed, both on the part of the designer and the early users.

          in SIGPLAN Notices 14(04) April 1979 including The first ACM SIGPLAN conference on History of programming languages (HOPL) Los Angeles, CA, June 1-3, 1978 view details
  • Sannella D. and A. Tarlecki. Program specification and development in Standard ML. In Proceedings of the 12th ACM Symposium on Principles of Programming Languages, pages 67-77, 1985 view details
          in SIGPLAN Notices 14(04) April 1979 including The first ACM SIGPLAN conference on History of programming languages (HOPL) Los Angeles, CA, June 1-3, 1978 view details
  • Sannella D. and A. Tarlecki "Extended ML: an institution-independent framework for formal program development" in Proc. Workshop on Category Theory and Computer Programming, pages 364-389. Springer LNCS 240, 1986. view details
          in SIGPLAN Notices 14(04) April 1979 including The first ACM SIGPLAN conference on History of programming languages (HOPL) Los Angeles, CA, June 1-3, 1978 view details
  • Sannella D. T. and A. Tarlecki. Toward formal development of ML programs: foundations and methodology. In Proc. Joint Conf. on Theory and Practice of Software Development, pages 375-389. Springer LNCS 352, 1989. view details
          in SIGPLAN Notices 14(04) April 1979 including The first ACM SIGPLAN conference on History of programming languages (HOPL) Los Angeles, CA, June 1-3, 1978 view details
  • Cerioli, Maura; Gogolla, Martin; Kirchner, Helene; Bruckner, Bernd Krieg; Qian, Zhenyu; Wolf, Markus "Algebraic System Specification and Development - Survey and Annotated Bibliography" Second Edition Compass Group Bremen 1997 view details Abstract: Methods for the algebraic specification of abstract data types were proposed in the early seventies in the USA and Canada and became a major research issue in Europe shortly afterwards. Since then the algebraic approach has come to play a central role in research on formal program specification and development, as its range of applications was extended to the specification of complete software systems, to the formal description of the program development process, and to the uniform definition of syntax and semantics of programming languages. Today this approach extends beyond just software to the development of integrated hardware and software systems. These flourishing activities in the area of algebraic specifications have led to an abundance of approaches, theories and concepts, which have universal algebra, category theory and logic as a common mathematical basis.
    The present volume is an annotated bibliography which attempts to provide an up-to-date overview of past and present work on algebraic specification. No attempt is made to provide a coherent introduction to the topic for beginners the intention is rather to provide a guide to the current literature for researchers in algebraic specification and neighbouring fields. Some indications of how the different approaches are related are included. ps Extract: Extended ML
    As mentioned in Section 2.8, a wide-spectrum language with an institution-independent semantics provides the basis for a program-development framework which accommodates not only different styles of specification but also different target languages. Such a language is Extended ML, an extension to Standard ML whereby axioms are allowed in module interface declarations and in place of code in module definitions. In this framework, programs are viewed as axioms of a special form. Extract: Extended ML
    Extended ML
    The long-term goal of work on Extended ML is to provide a practical framework for formal development of Standard ML programs together with an integrated suite of computer-based specification and development support tools and complete mathematical foundations to substantiate claims of correctness. The complete formal definition of the Extended ML language [533] constitutes an important milestone in this programme, necessary to provide a basis for further research on foundations and tools. One of the key issues that had to be resolved was the design of a logic suitable for describing properties of Standard ML programs, taking into account features like recursive type and function definitions, exceptions, polymorphism, and non-termination. A number of errors in the Standard ML semantics [679] have been discovered in the course of this work [526]. Work has begun on rules for proving theorems about EML specifications, to be used in verifying correctness conditions that arise in the course of formal development. Research has so far concentrated on equality reasoning [530] and quantifier rules.
    The length and requisite formality of the definition of Extended ML renders it rather difficult to penetrate. Accordingly, [532, 534] provides an informal overview of the definition, explaining most of the main issues involved and justifying some of the choices taken.
    The demand for reusability originates from economic considerations and attempts towards standardization. Rather than always starting from scratch, the use of existing components is cheaper and also less error-prone. A central problem for the identification and the correct use of reusable components is the abstract description of such components. A formal specification is the only form of description that can serve as a basis for a correctness proof; it can be processed automatically and it establishes a degree of confidence in the functionality of the component that is particularly important if a component has to be modified before being reused.
    Goguen [404] proposes the algebraic specification language OBJ as well-suited for the design of reusable software systems. A component's interface is specified as an abstract data type and may be parameterized by other components. Combination of components is possible by instantiation using appropriate fitting morphisms. A similar approach is used in Extended ML [836], [848].
    In ACT TWO [315] components are modules, which consist of two interface specifications, i.e. an export specification and an import specification, and a body specification which implements the export specification in terms of the import specification. Similarly, in LARCH [445], a component consists of a pair, an "abstract" interface specification and an implementation. Here the implementation is written in a conventional programming language. A similar distinction between a requirement and a design specification is made in PAnndA-S, the language of the PROSPECTRA project [138], based on the notion of visible and private interface in Ada. Ada bodies are generated semi-automatically by transformation.
    In the approach of [655] a component consists of four parts at four different levels of abstraction: a requirement specification, a design specification, a source program and object code. Components are written in a so-called wide spectrum language which provides facilities for system design and software development at many levels of abstraction. Matsumoto uses Ada, which has as a consequence that the requirement specification is merely an informal description. CIP-L [54] and COLD [341] are two languages which include algebraic specifications as well as predicative and imperative language styles in one coherent framework and therefore are better suited for such an approach.
    In the object-oriented approach of [675] a reusable component is represented by a graph of object-oriented programs, each node of which stands for one level of abstraction in the description of the software. In the approach of the ESPRIT-project DRAGON [945], a reusable component consists of a tree of algebraic specifications, where similarly to [675], each node of the tree is an instance of a certain level of an abstraction of the program with the root being the most "abstract" formal specification and the leaves representing the "concrete" implementations. A methodology for reusing components is described in [947].

          in SIGPLAN Notices 14(04) April 1979 including The first ACM SIGPLAN conference on History of programming languages (HOPL) Los Angeles, CA, June 1-3, 1978 view details