GPSS resources

GPSS/H specifics

The GPSS/H PC implementation is largely compatible with GPSS as described in the Gordon notes. Many "modern" features have been added, some of which are described below.

Random Number Generation

As in the Gordon notes, it is possible to use a uniform PseudoRandom number stream (RN1) and have it modified by a function (i.e., the inverse cumulative distribution of the desired distribution).

  POISS FUNCTION  RN1,C24 (Poisson Process)
  0.0,0.0/0.1,0.104/0.2,0.222/0.3,0.355/0.4,0.509/0.5,0.69/
  0.6,0.915/0.7,1.2/0.75,1.38/0.8,1.6/0.84,1.83/0.88,7.12/
  0.9,2.3/0.92,2.52/0.94,2.81/0.95,2.99/0.96,3.2/0.97,3.5/
  0.98,3.9/0.99,4.6/0.995,5.3/0.998,6.2/0.999,7/0.9997,8

        GENERATE  12,FN$POISS

GPSS/H has builtin functions which return numbers sampled from a nonuniform distribution: Thus, the above Poisson example could be replaced by

        GENERATE  RVEXPO(1,12.0)

Note that the mean of an exponential distribution is always positive. Negative values may be sampled from normal and triangular distributions. Hence, care must be taken in case these functions are used to generate time values (which need to be positive).

Simulated Time

In GPSS/H, simulated time is stored as a floating point number. The Absolute Clock (referenced by SNA AC1) keeps track of the total simulated time since the start of the simulation. The Relative Clock (referenced by SNA C1) keeps track of the elapsed simulated time since the last RESET control statement. If no RESET was executed, C1 and AC1 are identical. If we wish to store a time value, such needs to be done in a floating point parameter or savevalue (see below).

Arithmetic VARIABLEs

An arithmetic variable is an entity which provides a means of specifying an expression in one place which can be used in many places in a model. Integer arithmetic variables are defined by
  nameORnumber   VARIABLE  intExpression
 All intermediate values in the expression calculation are truncated to integer values before computation proceeds.
Floating point arithmetic variables are defined by
  nameORnumber   FVARIABLE  floatExpression

A variable is referenced by the SNA
  V$nameORnumber or V(nameORnumber)

Variables are seldom needed as GPSS/H allows expressions to be entered directly as operands. Also, variables are considerably slower (due to indirection) than expressions in operands. However, if the same expression is used in many places in the model, it is meaningful to use a variable.

SAVEVALUEs

A SAVEVALUE is a global, scalar variable of one of four types:

The initial value of a savevalue can be assigned using the INITIAL control statement (NOT a block).
  INITIAL  XB3,12
  INITIAL  XB(3),12
  INITIAL  XB(COUNTER),12
  INITIAL  XB$COUNTER,12
 all give the savevalue COUNTER (assuming it has number 3) an initial value of 12.

The SAVEVALUE block assigns a numerical value to a savevalue. The SAVEVALUE block has three operands (the C operand is specific to GPSS/H)

Some examples:
   SAVEVALUE    COLOURX,2,XB
   SAVEVALUE    NUMITEMSX+,10,XF
   SAVEVALUE    VALUEX-,10.+Q$WAIT*5.,XL

The value of a savevalue is referenced by the SNAs

Transaction Parameters

When modelling the life-cycle of a real-world entity as a GPSS process (coded as a sequence of GPSS blocks), all transactions (the GPSS counterparts of the real-world entities) are considered equal. Apart from a priority, the user can associate with each transaction, a number of parameters. By means of those parameters, individual transactions can be distinguished, i.e., parameters are the GPSS way of coding transaction attributes. They are carried by each transaction as it moves from block to block.

There are four types of transaction parameters

A transaction may carry any number of parameters in any combination of types (only memory restrictions apply). The purpose of separating transaction parameters into four types is to conserve computer memory, and to allow integer as well as floating types. Note how, if we have multiple types of parameters, we now no longer refer to e.g., P1, but rather to PH1, or to PF1, or to PB1, or to PL1, depending on the particular type of parameter.

Transaction parameters may be referenced by name or by number (as opposed to the original GPSS where only numbers could be used). So, a transaction parameter carrying the number of items a shopper has bought can be stored in halfword parameter ITMSBOUGHT and referred to by PH$ITMSBOUGHT or by PH(ITMSBOUGHT).

GENERATE and Transaction Parameters

The operands of the GENERATE block allow for the specification of the number and types of parameters a transaction will carry. By default, memory is reserved for 12 halfword parameters. Thus,
  GENERATE    5
  GENERATE    5,,,,,12PH
 are equivalent. To only reserve memory for 3 byte parameters,
  GENERATE    5,,,,,3PB
 To reserve memory for 4 fullword parameters and 9 floating point parameters,
  GENERATE    5,,,,,4PF,9PL
 When a transaction is first created, all its parameters are initialised to 0 (of the right type).

Note how transactions can only carry numerical values. In particular, they can not store character values. It is thus up to the user to "code" ENUMerated types such as {Red, Green, Blue}, {Male, Female}, or {Food, Drinks, NonFood} using integer values. Obviously, a parameter can also be used to store genuine values such as the number of items bought.

ASSIGN and Transaction Parameters

The ASSIGN block assigns a numerical value to a specified transaction parameter. The ASSIGN block has three operands (the C operand is specific to GPSS/H)

Some examples:
   ASSIGN    COLOURP,2,PB
   ASSIGN    NUMITEMSP+,10,PF
   ASSIGN    VALUEP-,10.+Q$WAIT*5.,PL

The value of a parameter is referenced by the SNAs

hv@cs.mcgill.ca --- March, 2000