Google
 

Trailing-Edge - PDP-10 Archives - decuslib20-03 - decus/20-0078/doc/gpsss.rnm
There is 1 other file named gpsss.rnm in the archive. Click here to see a list.
.paper size 55,67
.title GPSSS USER NOTES
.nofill
.lm 0
                 
.b 16
.lm 5
               GGG   PPPP    SSS    SSS    SSS
              G   G  P   P  S   S  S   S  S   S
              G      P   P  S      S      S
              G      PPPP    SSS    SSS    SSS
              G GGG  P          S      S      S
              G  G   P      S   S  S   S  S   S
              GGGG   P       SSS    SSS    SSS 
.skip 4
U   U   SSS   EEEEE  RRRR       N   N   OOO   TTTTT  EEEEE   SSS
U   U  S   S  E      R   R      NN  N  O   O    T    E      S   S
U   U  S      E      R   R      N N N  O   O    T    E      S
U   U   SSS   EEE    RRRR       N N N  O   O    T    EEE     SSS
U   U      S  E      R R        N N N  O   O    T    E          S
U   U  S   S  E      R  R       N  NN  O   O    T    E      S   S
 UUU    SSS   EEEEE  R   R      N   N   OOO     T    EEEEE   SSS
.page
.skip 3
.nofill
.lm 0
1_.   INTRODUCTION
     ------------
.lm 5
.subtitle Introduction
.skip 1
.fill
.indent 5
.flag capitalize
.LC
         <GPSSS  IS A <SIMULA CLASS WHICH ADDS TO <SIMULA SOME 
 OF THE USEFUL OBJECTS AND PROCEDURES OF <G<ORDON'S
<GPSS.
<I<T INCLUDES DECLARATIONS FOR THE FOLLOWING OBJECTS:
.NF .LS
.LE;<T<RANSACTIONS
.LE;<F<ACILITIES (HERE REFERRED TO AS STATIONS)
.LE;<S<TORAGES
.LE;<Q<UEUES
.ELS
.b1
.FILL
.i 5
<T<HE PROCEDURES ENABLE THE TRANSACTIONS TO OCCOPY AND RELEASE
THE RESOURCES.
<S<TATISTICS ON RESOURCE UTILISATION ARE AUTOMATICALLY
COLLECTED AND PRINTED AT THE END OF THE SIMULATION.

.b 2
.i 5
<T<HE <ADVANCE STATEMENT OF <GPSS HAS BEEN REPLACED BY THE MORE
FLEXIBLE <SIMULA SCHEDULING STATEMENTS SUCH AS <HOLD (...),
<ACTIVATE AND <REACTIVATE. <I<N ADDITION, A <WAIT <UNTIL 
PROCEDURE IS AVAILABLE TO ALLOW CONDITIONAL SCHEDULING.
<T<HE TRANSACTIONS CAN BE ASSIGNED PRIORITIES TO PROVIDE <FIFO, <LIFO
 AND OTHER SCHEDULING POLICIES.  

.b 2
.i 5
<O<THER PROCEDURES PERMIT ENQUIRIES AS TO THE STATUS OF THE RESOURCES
 <T<HE USER CAN ALSO ASK FOR THE PRINTING OF STATISTICS DURING 
A RUN AND CAN RESET THE SIMULATION TO TRY ALTERNATE POLICIES. 
<C<OMPLETELY DIFFERENT MODELS CAN ALSO BE DONE IN ONE RUN. 

.b 2
.i 5
<W<ITH <GPSSS, A USER CAN WRITE SIMULATION PROGRAMS WITH THE 
SAME FACILITY AND BREVITY AS WITH <GPSS. <I<N ADDITION 
,  THE USE OF <SIMULA AS A BASE LANGUAGE RETAINS THE PROGRAMMING 
FEATURES OF CURRENT HIGH LEVEL LANGUAGES SUCH AS  BLOCK STRUCTURE,
 PROCEDURES, ARITHMETIC, STRING HANDLING AND <I</<O<.

.b 2
.i 5
<I<N THIS BRIEF NOTE, WE SHALL ASSUME THAT THE READER HAS
 KNOWLEDGE OF BOTH <GPSS [1] AND <SIMULA [2].
.SKIP 1
.test page 5
.NF .LS
.LE; <GPSS/360, <U<SER'S <M<ANUAL, <IBM <C<ORP., <F<ORM <N<O. <H<20-0360 
.LE; <O<LE-<J<OHAN <D<AHL, <K<. <N<YGARD, <SIMULA 67 <C<OMMON <B<ASE 
<D<EFINITION, <N<ORVEGIAN <C<OMPUTING <C<ENTER, <O<SLO, <N<ORWAY. 
.ELS
.b 3
.skip 3
.nofill
.upper case
.no subtitle
.lm 0
.test page 10
2_.   STRUCTURE OF THE PROGRAM
     ------------------------
.lm 5
.subtitle Structure of the program
.skip 1
.fill
.i 5
GPSSS can be used as a block prefix or as a prefix to another CLASS
at one an only one block level in a program. It is to be used like 
the standard system classes SIMSET and SIMULATION.
.b 2
.p 5,1,6
.i 5
The user program can be considered as made up of two parts :
.ls
.le;definition of the transaction attributes and actions
.le;the main program which initialises and controls  the
    simulation. In particular, the main program must create
the first transaction.
.els
.b 2
.i 5
The following trivial example shows a model where customers
arrive at random in a system and leave after spending 10 minutes.
.nf .ls
.page
.le;begin
.le;   external class GPSSS ;
.le;   GPSSS(1,1,1) begin
.le;      TRANSACTION class customer;
.le;      begin
.le;            activate new customer
            delay uniform(0,15,U);
.le;            HOLD(10);
.le;      end;
.le;      comment now the main program;
.le;      activate new customer delay 0;
.le;      HOLD(100);
.le;   end   GPSSS example;
.le;end   of  program
.els
.skip 1
.fill
.p 5,1,5
.i 5
In this example, the upper case words are procedures or objects
already defined either in GPSSS or in SIMULATION.
The main program starts the first customer with an activate
statement and then waits for 100 time units:
the simulation will therefore last 100 minutes (simulated time).
.b 2
.p 5,1,5
.i 5
The transactions in GPSSS are defined as classes prefixed
by TRANSACTION. The TRANSACTION class, defined in GPSSS, is
itself prefixed by PROCESS and can be scheduled with the 
usual SIMULA statements. In the example, each customer
generates its successor and waits 10 units before leaving
the system.
.b 2
.p 5,1,5
.i 5
The familiar facilities, storage and queues of GPSS are
provided in GPSSS along with the procedures needed to
use them as well as some other features.
Here is a list of procedures and variables defined
in GPSSS along with indications as to where they
should be used :
.b 2
.nf
.p 5,1,7
A)  PROCEDURES FOR TRANSACTIONS
         ---------------------------
.b 1
.lm 12
- ENTER__STATION  (N)
- LEAVE__STATION  (N)
- ENTER__STORAGE  (N, SIZE)
- LEAVE__STORAGE  (N, SIZE)
- ENTER__QUEUE    (N)
- LEAVE__QUEUE    (N)
.lm 5
.b 2
.p 5,1,3
B)  MAIN PROGRAM PROCEDURES
         -----------------------
.b 1
.lm 12
- SET__STORAGE  (N, MAX__CONTENTS)
- RESTART
.b 2
.lm 5
.p 5,1,10
C)  GENERAL USE PROCEDURES
         ----------------------
.b 1
.lm 12
- GPSSS__TIME
- WAIT__UNTIL  ( _< BOOL EXPR > )
- STANDARD__REPORT
- CONTENTS__STATION  (N)
- CONTENTS__STORAGE  (N)
- CONTENTS__QUEUE    (N)
- WAITING__STATION   (N)
- WAITING__STORAGE   (N)
- WAITING__QUEUE     (N)
.b 1
.b 2
.lm 5
.p 5,1,5
D)  TRANSACTION ATTRIBUTES
         ----------------------
.b 1
.lm 12
- PRIORITY
- TIME MARK
- ID
.b 2
.lm 5
.p 5,1,2
E)  GLOBAL VARIABLES
         ----------------
.b 1
.lm 12
- U
.b 2
.lm 5
.p 5,1,9
F)  PROCEDURES IN VERSION GPSSST
         ----------------------------
.b 1
.lm 12
- TRACE__OBJECTS
- STATION__NAME      (N,new__name)
- STORAGE__NAME      (N,new__name)
- QUEUE__NAME        (N,new__name)
- TRANS__NAME        ( new__name )
- HOLD__UNTIL__READY
- OUTTIME            ( TIME )
- BEGIN__TIME        ( TIME )
.b 2
.lm 5
.p 5,1,3
.fill
.i 5
Now we shall consider these in more detail, treating
first what can be used in transactions, then the main
program,
the global features, and finally the version GPSSST.
.b 3
.nf
.no subtitle
.lm 0
.test page 10
3_.  TRANSACTIONS
    ------------
.lm 5
.subtitle Transaction
.b 2
.i 5
Each transaction has three variables predifined :
.b 2
      integer  ID;
      real     TIME__MARK,PRIORITY;
.b 2
.fill
.p 5,1,3
.i 5
When a transaction is created, PRIORITY is set to 
zero, TIME__MARK is set to current time and a unique
identification integer is placed in ID.
.b 2
.i 5
PRIORITY is used by the system procedures when a transaction
is placed in a queue or does a WAIT__UNTIL.
The order is by increasing value of PRIORITY.
For transactions with equal priorities, the ordering
is FIFO (first in first out) if PRIORITY is positive
and LIFO (last in first out) if negative.
The user can therefore effect different scheduling
policies by changing PRIORITY during execution.
For example :
.b 2
.lm 10
.nf
.p 0,1,6
FIFO    - PRIORITY :=   GPSSS__TIME
        - PRIORITY := _< positive constant >
LIFO    - PRIORITY := - GPSSS__TIME
        - PRIORITY := _< negative constant >
OTHERS  - PRIORITY := _< priority value >
        - PRIORITY := _< deadline for completion >
.b 2
.p 5,1,5
.fill
.lm 5
.i 5
Although priority sheduling is allowed, preemptive
scheduling is not implemented. It should be noted
that time scheduling with the HOLD, ACTIVATE and
REACTIVATE statements of SIMULA do not order
event notices by PRIORITY.
.b 2
.p 5,1,2
.i 5
TIME__MARK is not used by GPSSS but the user could 
employ it to get statistics on transit times through
a system.
.b 2
.p 5,1,3
.i 5
It is not recommended that ID be altered. It is used
by GPSSS error messages and has been found quite 
valuable as a means of tracing transactions.
.b 2
.p 5,1,2
.i 5
The procedures affecting resources and their GPSS equivalent
are shown below :
.b 2
.lm 10
.p 5,1,7
.nf
       GPSSS                         GPSS
            -----                         ----
.b 1
- ENTER__STATION  (N)               SEIZE   N
- LEAVE__STATION  (N)               RELEASE N
- ENTER__STORAGE  (N, SIZE)         ENTER   N, SIZE
- LEAVE__STORAGE  (N, SIZE)         LEAVE   N, SIZE
- ENTER__QUEUE    (N)               QUEUE   N
- LEAVE__QUEUE    (N)               DEPART  N
.fill
.b 2
.lm 5
.p 5,1,14
.i 5
The parameter N is an integer identifying a resource.
The limits are set 
as parameters to GPSSS : 
.break
GPSSS(max__stations, max__storages, max__queues)
.break
The data structure for each resource is only
allocated when it is required and statistics
are printed only for the resource utilised
so that the numbering need not be consecutive.
Although the procedures are equivalent to the 
GPSS ones we have changed the nomenclature 
to facilitate their use.
In this system the term FACILITY has been
replaced by STATION.
.b 2
.nosubtitle
.nf
.lm 0
.test page 10
4_.     MAIN PROGRAM
       ------------
.lm 5
.subtitle Main program
.b 2
.i 5
.fill
The main program serves to initialise the simulation,
print out statistics and terminate.
It will probaply make use of some of the general
procedures described later. Here we mention
only the two procedures peculier to the main
program. They are :
.b 2
.lm 10
.nofill
- RESTART
- SET__STORAGE (N, MAX__CONTENTS)
.fill
.lm 5
.b 2
.i5
RESTART flushes the model so that a new run can be
tried with different parameters or a different
model can be run. It calls STANDARD__REPORT to print
statistics, gets rid of all transactions and resources,
resets GPSSS__TIME to zero and U to 987654321.
.b 2
.p 5,1,4
.i 5
SET__STORAGE creates storages and their maximum
capacity. If a storage is used before having
been created in this way, it will be assigned
on arbitrary very large capacity.
.b 2
.p 5,1,5
.i 5
Although the main program looks in many ways
like a transaction, it is in fact a different
sort of entity.
It cannot therefore use the ENTER and LEAVE
procedures. Moreover,
it does not have the attributes ( ID, PRIORITY,
and TIME__MARK) of a transaction.
.b 2
.nf
.no subtitle
.lm 0
.test page 10
5_.  GLOBAL PROCEDURES AND VARIABELS
    -------------------------------
.lm 5
.subtitle Global procedures and variabels
.b 2
.fill
.p 5,1,4
These are global and may be referred to anywhere in the
program. They include enquiry procedures, reporting,
conditional scheduling and a random number seed.
.b 1
.p 5,1,7
The enquiry procedures are 
concerned with simulated time and the state of resources.
There is first:
.br
.i 5
real procedure  GPSSS__TIME; - - - - - -;
.br
which returns the elapsed time since the start of the 
simulation or the last use of RESTART. This procedure
replaces the SIMULA standard procedure TIME which should
not be used.
.b 1
.p 5,1,4
The other enquire procedures return integer values for the 
number of transactions waiting for a resource or the space
utilised in a resource (CONTENTS__). These have the form
:
.br
.nf
.p 5,1,5
.lm 5
                --         --   --         --
                [ CONTENTS__ ]   [ STATION   ]
                [           ]   [           ]
_<enq. proc_>::=  [           ]   [ STORAGE   ] (N).
                [           ]   [           ]
                [ WAITING__  ]   [ QUEUE     ]
                --         --   --         --
.fill
.lm 5
.p 5,1,3
when "["  ,  "]" indicate selection of one alternative.
WAITING__QUEUE, though allowed, will of course always
return zero.
.b 1
.p 5,1,4
STANDARD REPORT has been modelled on the GPSS report.
It does not give cumulative statistics, rather it gives
results since the last report.
.b 1
.p 5,1,12
WAIT__UNTIL ( _< bool. expr _> ) is a very powerful
procedure. It can be used either by a transaction
or the main program.
It causes the caller to suspend its activity until
the expression becomes true. The complexity
of the expression is only limited by the syntax
of SIMULA. This feature is axpensive as the expressions
are tested after every event but, if it not used, no overhead
is encurred. The transactions stopped on a WAIT__UNTIL
are kept in priority order as in any other queue.
The main program which does not have a priority attribute
is always tested last.
.b 1
.p 5,1,3
Finally, there is a global integer "U" initialised to 
987654321 which may be used as a seed for random number
generators.
.nofill
.no subtitle
.p -5,2,15
6_.  VERSION GPSSST
.i -5
    --------------
.subtitle Version gpssst
.lm 5
.b 2
.fill
.p 5,1,1
This is added in version GPSSST :
.b 1
.p 5,1,6
TRACE__OBJECTS will print out the transactions in
order of appearence. Each transaction will be 
followed by its occurrences. This procedure
should be called 
at the and of the simulation.
  Data for the trace is only collected if
the Boolean variable OBJECT__TRACE__ON is true.
.p 0,1,13
Example :
.nofill
  
   OBJECT     2
   ======    ==
   
Entered queue     1   at time        9:15
Leaved  queue     1   at time        9:20
Entered station   1   at time        9:20
Leaved  station   1   at time        9:37
   
   
Time spent in queue         :        0:05
Time spent in station       :        0:17
    
.fill
.b 1
.p 5,1,4
The texts in the listing above can be
made more readable by the procedures
STATION__NAME(N,new__name), STORAGE__NAME(N,new__name)
 QUEUE__NAME(N,new__name)  and 
TRANS__NAME( new__name ) .
.b 1
.no justify
.p 5,1,4
The statements
STATION__NAME(1,"waiting room");
QUEUE__NAME(1,"Doctor's office"); and
TRANS__NAME( "Patient"); will 
make the example above look like this :
.p 0,1,12
.nofill
        Patient    2
        =======   ==
   
   
Entered waiting room     at time         9:15
Leaved  waiting room     at time         9:20
Entered doctor's office  at time         9:20
Leaved  doctor's office  at time         9:37
   
   
Time spent in waiting room     :         0:05
Time spent in doctor's office  :         0:17
   
.justify
.fill
.b 1
.p 5,1,5
TRACE is a procedure which will print out
the occurrences in order of appearence.
This will be done at the  time 
a transaction enters or leaves a facility.
Trace will be done when  the Boolean variable TRACE__ON is true.
TRACE need not  be called in users program.
You need only set "TRACE__ON:=TRUE;" and TRACE
will automatically be called in  GPSSST.
.break 
.p 0,1,6
Example :
.nofill
   
object   1 entering  queue     1    at time        9:00
object   1 leaving   queue     1    at time        9:00
object   1 entering  station   1    at time        9:00
object   2 entering  queue     1    at time        9:15
   
.b 1
Or if the texts is changed as mentioned above :
.b 1
.p 5,1,5
   
Patient 1 entering  waiting room    at time        9:00
Patient 1 leaving   waiting room    at time        9:00
Patient 1 entering  doctor's office at time        9:00
Patient 2 entering  waiting room    at time        9:15
     
.b 1
.fill
.p 5,1,2
HOLD__UNTIL__READY  can be called in the main program between the
simulation and the call on TRACE__OBJECTS.
.b 1
.p 5,1,3
     The time value, given by the SIMULA procedure TIME, is
changed by the procedure
		
.nofill
.p 5,1,3
PUTTIME( _<time> ) :
Puttime edits a REAL variable representing a TIME value
left justified into the text FIELD in
seconds	if UNIT = 'S'
minutes	if UNIT = 'M'	(default)
hours	if UNIT = 'H'
days	if UNIT = 'D'
    
The FIELD must have a minimum length of
12	if secdec < 0
15	if secdec = 0
16+secdec	if secdec > 0
    
Format:
    
[-]dddD  hh:mm[.ss[.xxx...]]
    
where
ddd	is number of days	(Blanked if day < 1)
hh	is number of hours
mm	is number of minutes
ss	is number of seconds (only if SECDEC >= 0)
xxx	is fraction of second with SECDEC digits
    
Unit and secdec is to be given as parameters to GPSSST  :
GPSSST( max_queues, max_station, max_storages, unit, secdec );
   
If you have a certain time of day when the simulation
starts, you set it as: i.e BEGIN__TIME( 9.00 ) ; in
the begining of your program.

If you want to print the time of day yourself, you only 
need to call the procedure OUTTIME( TIME ) ;
 i.e.  OUTTIME( GPSSS__TIME + BEGIN__TIME( 9.00 ) ) ;
.p 0,1,2
"NOREPORT:= TRUE;" will supress the STANDARD__REPORT message.
.p -5,2,15
.nofill
.no subtitle
.test page 10
7_.  SAMPLE PROGRAMS
.i -5
    ---------------
.lm 5
.b 2
.subtitle Sample programs
.fill
.p 5,1,4
Here follows two sample user programs.
The first is a crude cumputer simulation and the second
shows the combined effect of "wait__until" and priorities.
.b 1
.i 5
Program 1
.nf
.i 5
---------
.fill
.p 5,1,6
Here jobs arrive at random at a computer center where they
are placed in an input queue.
When storage is available, a job is brought into
core and proceeds to run alternating between
requests for CPU time and IO. After 10 such loops
it leaves the system.
.b 1
.p 5,1,6
The program (Fig 1) shows the use of enter__ and leave__
procedures. Storage 1 represents core, station 1
represents the CPU and the queues 1 and 4 gather 
statistics on the time through the system and the 
waits for the CPU respectively.
.b 1
.p 5,1,4
The main program uses RESTART to do two passes
with different sizes of main storage. 
STANDARD__REPORT serves to get statistics on the
warm-up period for one of the runs.
.page
.nofill
.lm 0
BEGIN
    EXTERNAL CLASS GPSSS;
    GPSSS(4,1,1)  BEGIN
    COMMENT
    *********************************
    ***                           ***
    ***  USER  PGM  STARTS  HERE  ***
    ***                           ***
    *********************************
    COMMENT **************  TEST PROBLEM 1 **************;
	transaction  CLASS  job ;
	BEGIN
	    INTEGER  i,size,u1;
	    ACTIVATE   NEW  job  DELAY  Negexp(1/20,u);
	    size := Randint(1,10,u);
	    u1 := u;
	    enter__queue(1);
	    enter__storage (1,size);
	    FOR  i := 1  STEP  1  UNTIL  10  DO   BEGIN
		enter__queue (4);
		enter__station (1);
		leave__queue(4);
		hold(Negexp(1,u1));
		leave__station(1);
		hold(Uniform(0,5,u1));
	    END ;
	    leave__storage(1,size);
	    leave__queue(1);
	END ;
        Outtext(
	"TEST  PROBLEM 1 - CRUDE COMPUTER SIMULATION");
        Outimage;
	Outtext(
	"-2 PASSES WITH DIFFERENT MEMORY SIZE,10K AND 15K");
	Outimage;
	COMMENT          PASS 1 WITH 10K  ;
	set__storage(1,10);
	ACTIVATE   NEW  job;
	hold(300);
	COMMENT        REPORT ON WARM UP PERIOD    ;
	standard__report;
	hold(300);
	COMMENT      PASS 2;
	restart;
	set__storage(1,15);
	ACTIVATE   NEW  job;
	hold(300);
    END  OF FIRST TEST PROBLEM;
END
.b 2
		FIGURE  1  -  CRUDE COMPUTER SIMULATION
                ---------------------------------------
.page
.skip 5
.lm 5
          Program 2
          ---------
.fill 
.p 5,1,12
Here several X transactions as well
as the main program wait for a Boolean
condition, GO__SIGNAL, to become true.
This condition is set by transaction Y.
Each transaction then prints out its ID
and its PRIORITY. This shows the queue ordering
by increasing value of PRIORITY with FIFO
or LIFO for equal values depending wether
PRIORITY is positive (or zero) or negative.
The main program is always reactivated last.

.skip 2
.nofill
.lm 0
BEGIN
External class GPSSS;
    COMMENT *********  TEST PROBLEM 2  *********************
    TEST OF _<WAIT__UNTIL> STATEMENT AND PRIORITY QUEUEING
    - IF PRIORITY OF 1 (P1) _< PRIORITY OF 2 (P2) THEN
    P1 IS PLACED BEFORE P2
    - IF P1=P2 THEN THE ORDER IS FIFO FOR POSITIVE P1
    AND LIFO FOR P1_<0
    - NON TRANSACTION OBJECTS SUCH AS MAIN PROGRAM ARE 
    PLACED AFTER ALL OTHERS.
            ********************************************************;
    GPSSS(1,1,1)   BEGIN
	transaction  CLASS  x (param);  REAL  param;
	BEGIN
	    priority := param;
	    wait__until ( go__signal );
	    Outint(id,5); Outfix(param,2,6); Outimage;
	END ;
	transaction  CLASS  y;
	BEGIN   go__signal :=  TRUE   END ;
	INTEGER  i;  Boolean  go__signal;
	Eject(1); Outtext(
	"PROBLEM  2 - TEST OF PRIORITIES AND WAIT__UNTIL");
	Outimage;
	FOR  i := -1  STEP  1  UNTIL  1  DO   BEGIN
	    ACTIVATE   NEW  x(i)  DELAY  1 ;
	    ACTIVATE   NEW  x(i);
	END ;
	ACTIVATE   NEW  y  AT   5 ;
	wait__until( go__signal);
	Outtext("MAIN  PROG");  Outimage;
	hold(1);
    END  TEST PROGRAM 2;
END USER PGM
.b 2
		FIGURE  2  -  USE OF WAIT__UNTIL
                -------------------------------
.page
.paper size 58,70


***************************    -VERSION 4.1-
***   MONTREAL  GPSSS   ***
***  SIMULATION REPORT  ***
***************************
.skip 2

PASSE  =  1
.skip 1
START  TIME=       0.00
END    TIME=     300.00
.skip 2

* STATIONS *
************
.skip 1
              AVERAGE                AVERAGE
   STATION   UTILISATION  ENTRIES   TRANSIT TIME   STATUS
.skip 1
      1             0.43        90           1.42      BUSY
.skip 3


* STORAGES *
************
.skip 1
                      AVG.     AVG.            THRU  TIME    CONTENTS
STORAGE   CAPACITY  CONTENTS   UTIL.  ENTRIES    / UNIT      MAX  NOW
.skip 1
    1        10        5.18   0.5178      10       35.30     10     5
.skip 3


* QUEUES *
**********
.skip 1
                  MAX.     CURRENT     AVG.      AVG.
QUEUE   ENTRIES  CONTENTS  CONTENTS  CONTENTS  TIME/TRANS
.skip 1
   1      11         5         3       1.61      43.95
   4      90         2         0       0.16       0.54

.b -4
          FIGURE  - 3 -  TYPICAL OUTPUT PROBLEM # 1.
          -----------------------------------------
.page
.lm 10
PROBLEM  2 - TEST OF PRIORITIES AND WAIT__UNTIL
.b 1
    4 -1.00
    1 -1.00
    2  0.00
    5  0.00
    3  1.00
    6  1.00
   MAIN  PROG
.skip 2

***************************    -VERSION 4.1-
***   MONTREAL  GPSSS   ***
***  SIMULATION REPORT  ***
***************************
.skip 2

PASSE  =  1
.skip 1
START  TIME=      0.00
END    TIME=      6.00
.skip 2

* NO STATIONS *
.skip 2

* NO STORAGES *
.skip 2

* NO QUEUES *
.b -4
          FIGURE  - 4 - OUTPUT PROBLEM # 2.
          --------------------------------