Barber shop simulation GPSS block diagram from General Purpose Simulation System/360: Introductory Concepts and Case Studies by Thomas J. Schriber, October, 1968.

We'll now look at GPSS, a simulation language included in MTS. Due to the specialized nature of this language I'll only devote a single post to it - but it's a very interesting language, so let's dive in!

General Purpose Simulation System

GPSS, General Purpose Simulation System, is a language to simulate discrete systems to see how they perform over time. Sample uses include modeling a checkout at a supermarket or how a manufacturing assembly line will work. The programmer defines how transactions are created (eg a shopper), what resources are available (eg how many checkouts and how long they take to process) and how transactions move through the system. When run, it simulates a clock and processes these transactions, giving output that shows the performance of the system, eg how long on average a shopper had to queue for and how busy the checkouts where during a simulated day.

GPSS on MTS

GPSS was created by Geoffrey Gordon in around 1961 and was originally implemented on IBM systems. The version we have on MTS, GPSS/360, is available as *GPSS. Later versions of GPSS such as GPSS/H did run on MTS and may be available in future distributions (see this message at the MTS Archive).

Prerequisites

No special installation instructions to get this language running - just do the standard D6.0 setup as described in this guide and then sign on as a regular user such as ST01.

A barber shop simulator

As a sample program, let's look at the Barber Shop: First Model from General Purpose Simulation System/360: Introductory Concepts and Case Studies by Thomas J. Schriber.

We are modeling a barber shop with the following qualities:

  • The shop contains one barber and one barber's chair, open for eight hours in a day.
  • Customers arrive on average every 18 minutes, with the arrival time varying between 12 and 24 minutes.
  • If the barber is busy, the customer will wait in a queue.
  • Once the barber is free, the next customer will have a haircut.
  • Each haircut takes between 12 and 18 minutes, with the average being 15 minutes.
  • Once the haircut is done, the customer will leave the shop.

We want to answer these questions:

  • How utilised is the barber through the day?
  • How long does the queue get?
  • On average, how long does a customer have to wait.

The manual uses a block diagram notation to show how this is simulated - you can see this at the top of this page. The equivalent GPSS program looks like this:

       SIMULATE
       GENERATE   18,6       CREATE CUSTOMERS
       QUEUE      2          CUSTOMERS QUEUE UP IF NECESSARY
       SEIZE      3          ENGAGE THE BARBER WHEN HE BECOMES AVAILABLE
       DEPART     2          CUSTOMER LEAVES THE QUEUE
       ADVANCE    15,3       CUSTOMER GETS HIS HAIR CUT
       RELEASE    3          RELEASE THE BARBER
       TERMINATE  0          LEAVE THE BARBER SHOP
       GENERATE   480        GENERATE A TIMER AFTER 8 HOURS OF SIMULATED TIME
       *
       TERMINATE  1          SHUT OFF THE RUN
       START      1          CARRY OUT THE SIMULATION
       END                   RETURN CONTROL TO THE OPERATING SYSTEM

The text at the end of each line is a comment; starting a line with * means the rest of the line is a comment; we use this just to separate the two parts of the program as explained below.

GPSS works in units rather than absolute time, so we shall say that 1 time unit is equal to 1 minute. Programs can be read from top to bottom: the simulator runs by advancing the clock one time unit and working out where transactions are in the system.

The first line, SIMULATE, denotes the start of the code.

GENERATE 18,6 means generate a transaction - a barber shop customer - every 18 minutes ± 6 minutes.

QUEUE 2 defines a queue with ID 2, denoting the queue where customers will wait.

SEIZE 3 defines a facility with ID 3. The facility is the barber and this line means if the barber is free, the next customer occupies the barber until released.

DEPART 2 says that the customer leaves the queue when occupying the barber.

ADVANCE 15,3 means that transactions in this state only move on after 15 minutes ± 3 minutes - modeling the time taken for a haircut. After that RELEASE 3 shows that the customer no longer occupies the barber and TERMINATE 0 ends the transaction, showing that the customer has left the shop.

That is all that is needed for the basic simulation, but if run like this it would never stop, as we have not modeled the 8 hour period the shop is open.

To do this we generate a new transaction with GENERATE 480, which means generate a transaction after 480 minutes, ie 8 hours. The next line, TERMINATE 1, stops the simulation after this transaction is generated.

With that done, the last two lines start the simulator and returns control to MTS when it is done.

Running the program using *GPSS

*GPSS takes the input file on scards and outputs to *sink* by default. Assuming the simulation defined above is stored in barb1.gpss, this is how it would look:

We start off with the program listing, where GPSS denotes which lines are components of the simulation with a block ID. So GENERATE 18,6 is on line 3 but is block 1.

$run *gpss scards=barb1.gpss
Execution begins   16:07:50


     GPSS/360    VERSION 1  MODIFICATION LEVEL 4    MTS MODEL (AN104)    16:07:50  11-03-17

     LINE# CARD#  BLOCK#  *LOC   OPERATION  A,B,C,D,E,F,G    COMMENTS

     1.000     1                 SIMULATE
     2.000     2          * BARBER SHOP SIMULATOR
     3.000     3  1              GENERATE   18,6       CREATE CUSTOMERS
     4.000     4  2              QUEUE      2          CUSTOMERS QUEUE UP IF NECESSARY
     5.000     5  3              SEIZE      3          ENGAGE THE BARBER WHEN HE BECOMES AVAILABLE
     6.000     6  4              DEPART     2          CUSTOMER LEAVES THE QUEUE
     7.000     7  5              ADVANCE    15,3       CUSTOMER GETS HIS HAIR CUT
     8.000     8  6              RELEASE    3          RELEASE THE BARBER
     9.000     9  7              TERMINATE  0          LEAVE THE BARBER SHOP
    10.000    10          *
    11.000    11  8              GENERATE   480        GENERATE A TIMER AFTER 8 HOURS OF SIMULATED
    12.000    12  9              TERMINATE  1          SHUT OFF THE RUN
    13.000    13                 START      1          CARRY OUT THE SIMULATION
    14.000    14                 END                   RETURN CONTROL TO THE OPERATING SYSTEM

Next, GPSS shows how many transactions were in each block at the end of the simulation and in total.

RELATIVE CLOCK          480  ABSOLUTE CLOCK          480  
 BLOCK COUNTS
 BLOCK CURRENT    TOTAL    BLOCK CURRENT    TOTAL    BLOCK CURRENT    TOTAL    BLOCK CURRENT    TOTAL    BLOCK CURRENT    TOTAL
     1      0        27
     2      0        27
     3      0        27
     4      0        27
     5      1        27
     6      0        26
     7      0        26
     8      0         1
     9      0         1

We can see that 27 transactions were generated in block 1, which means 27 customers entered the shop during the day. Blocks 8 and 9 had 1 transaction, which is expected as this was the timing transaction. Why does block 5 have one current transaction while all others are zero? Block 5 is the ADVANCE statement, representing the haircut, and this means one customer was in the chair at the end of the simulated day.

GPSS then prints out statistics on the facility, or the barber in our simulation:

 FACILITY        AVERAGE         NUMBER        AVERAGE          SEIZING    PREEMPTING
               UTILIZATION      ENTRIES       TIME/TRAN        TRANS. NO.  TRANS. NO.
        3          .816              27          14.518            1

So our barber was used 81.6% of the day, and each haircut took on average 14.518 minutes.

We then see details of the queue:

 QUEUE      MAXIMUM     AVERAGE     TOTAL       ZERO     PERCENT      AVERAGE      $AVERAGE      TABLE     CURRENT
           CONTENTS    CONTENTS    ENTRIES    ENTRIES     ZEROS     TIME/TRANS    TIME/TRANS    NUMBER    CONTENTS
     2            1        .085        27         16       59.2         1.518         3.727
  $AVERAGE TIME/TRANS = AVERAGE TIME/TRANS EXCLUDING ZERO ENTRIES

MAXIMUM CONTENTS means there was never more than one customer in the queue. Although 27 customers entered the queue, 16 were zero entries - this means they entered and immediately left the queue, ie the barber was unoccupied when they entered the shop. For those that did wait in the queue, the average wait was 3.727 minutes; including the zero entries, the average time for all customers to wait was 1.518 minutes.

Finally, GPSS prints usage statistics and exits:

CPU TIME USED (SECONDS)

  ASSEMBLY:      .001

TOTAL BLOCK EXECUTIONS:     189

MSEC/BLOCK AVG CPU TIME:   .003

Execution terminated   16:07:50  T=0.004  RC=0  $0.00  

It's interesting to compare this to the printout in the manual from 1968. Our run took 0.004 seconds of CPU time, compared to 4.5 seconds then. And of course our run had no charge, whereas the run from 1968 would have cost 41¢.

The manual goes on to refine the model further - dealing with the customer left in the chair, and simulating more complex scenarios - but we will leave it at that for now.

Further information

Full source code for the program described above can be found on github.

The original IBM manuals for GPSS/360 don't appear to be available anywhere online. The best reference I've found is, as mentioned above, General Purpose Simulation System/360: Introductory Concepts and Case Studies at Deepblue.

Modern implementations of GPSS on Windows are sold by Wolverine Software and Minuteman Software; both offer a free student version with limited model sizes.

Several other simulation languages have been created, eg Simula; a list of languages for discrete event simulations can be found at Wikipedia.