### 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:
• Exponential: ```RVEXPO(randomNumberStream, mean)```
• Normal: ```RVNORM(randomNumberStream, mean, standardDeviation)```
• Triangular: ```RVTRI(randomNumberStream, minimum, mode, maximum)```
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 `VARIABLE`s

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:

• `XH`: Halfword (default: X == XH) (-32,768 < value < 32,767)
• `XF`: Fullword (-2,147,483,648 < value < 2,147,483,647)
• `XB`: Byte (-128 < value < 127)
• `XL`: Floating Point
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)

• A operand: the savevalue name or number. There are three modes of operation: increment, decrement, and replacement. If the A-operand is immediately followed by a + sign, the value of the specified savevalue will be incremented with the value in the B operand. If the A-operand is immediately followed by a - sign, the value of the specified savevalue will be decremented by the value in the B operand. If neither a + or - sign follows the A-operand, the savevalue value is replaced by the value in the B operand.
• B operand: the numerical value (may be a SNA)
• C operand: specifies the savevalue type (XH, XF, XB, or XL)
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

• `XH`: `XH\$nameORnumber` or `XH(nameORnumber)` (X == XH)
• `XF`: `XF\$nameORnumber` or `XF(nameORnumber)`
• `XB`: `XB\$nameORnumber` or `XB(nameORnumber)`
• `XL`: `XL\$nameORnumber` or `XL(nameORnumber)`

#### 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

• `PH`: Halfword (default: P == PH) (-32,768 < value < 32,767)
• `PF`: Fullword (-2,147,483,648 < value < 2,147,483,647)
• `PB`: Byte (-128 < value < 127)
• `PL`: Floating Point
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)

• A operand: the parameter name or number. There are three modes of operation: increment, decrement, and replacement. If the A-operand is immediately followed by a + sign, the value of the specified parameter will be incremented with the value in the B operand. If the A-operand is immediately followed by a - sign, the value of the specified parameter will be decremented by the value in the B operand. If neither a + or - sign follows the A-operand, the parameter value is replaced by the value in the B operand.
• B operand: the numerical value (may be a SNA)
• C operand: specifies the parameter type (PH, PF, PB, or PL)
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

• `PH`: `PH\$nameORnumber` or `PH(nameORnumber)` (P == PH)
• `PF`: `PF\$nameORnumber` or `PF(nameORnumber)`
• `PB`: `PB\$nameORnumber` or `PB(nameORnumber)`
• `PL`: `PL\$nameORnumber` or `PL(nameORnumber)`

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