4. The Execution Supervisor#

This paragraph needs to be thoroughly revised. It’s been a long time since the supervisor was rewritten in Python. In the process, its functionalities have been greatly extended.

4.1. Generalities#

What we call « Supervisor » is the set of FORTRAN routines that belong to the SUPERVIS library.

It can be divided in two logically:

SUP1:

which is used to chain the various commands together; that is, everything that is (in the call tree) between the main program and the OP000i routines (including the main program). The supervisor includes the content of 3 specific commands: DEBUT, POURSUITE and FIN,

SUP2:

which allows the communication of information with OP000i: routines GETXXX (D6.03.01 - Communication with the Execution Supervisor: routines GETXXX)

4.2. General functioning of the Supervisor#

  • opening of the 3 databases JEVEUX (D6.02.01 Memory management: JEVEUX) (in fact 3 direct access files).

  • « LOCALE » base is a work base reserved for the Supervisor, this database is not saved at the end of execution

  • « VOLATILE » database is the database reserved for work objects (except Supervisor), this database is not saved at the end of execution,

  • base « GLOBALE » it is the user base. At the end of execution, it will contain the concepts corresponding to the orders executed

  • reading catalogs

  • order catalogs

  • item catalogs

  • reading the user’s command file

  • reading in free format; elimination of comments,

  • syntactic checks (using command catalogs),

  • spelling of keywords,

  • types of arguments,

  • exclusion of keywords,…

  • assigning the values by default,

  • creation of concepts corresponding to values (DEFI_VALEUR [U4.21.10]) and to interpreted functions (FORMULE [U4.21.11]),

  • evaluation of numerical expressions (keyword EVAL [U4.21.11 §4.1]),

  • storing command file information in JEVEUX objects (local base).

  • request for the execution of user orders (Request for the execution of orders),

  • printing of the execution time of each order,

  • validation (as and when) of the concepts created by the orders: this makes it possible to « resume » a calculation that ended incorrectly,

  • closing the databases at the end of execution,

  • stopping the program.

4.3. Order Fulfilment Request#

The Supervisor « loops » twice over the commands read from the user’s command file:

1st pass:

additional verification phase: we check the user data (which could not be verified by the supervisor),

2nd pass:

execution phase: we actually execute the command.

If the user requested:

DEBUT (PAR_LOT: “OUI”,…) (this is the default value)

The Supervisor executes the 1st pass on all orders before starting the 2nd pass. This allows you to check the entire command file before starting execution.

Otherwise: DEBUT (PAR_LOT: “NON”,…)

The Supervisor executes the 2 passes one after the other for each order.

Note:

The Supervisor makes a series of orders one after the other. The « phrases of the language » (the commands) follow each other without control instructions: IF THEN ELSE , loops DO ,…

4.4. « Supervisor » commands#

Note:

This paragraph can be skipped at first reading.

The previous paragraph (Order Fulfilment Request) concerned the execution of « ordinary » orders.

Regular orders are those whose number is between 1 and 9998.

The commands that are not ordinary are:

  • orders DEBUTet POURSUITEqui do not have an external catalog,

  • the command FINassociée at number 9999which is responsible (among other things) for unloading the memory and closing the databases,

  • the so-called « supervisor » commands.

Supervisor orders have a catalog (like regular orders), but their number is a negative number (keyword NUMERO_SUPERVIS__ instead of NUMERO__). The associated FORTRAN routines are called OPS00i.

Today (01/10/94) there are 7 Supervisor orders.

The difference in behavior between a Supervisor command and an ordinary order is that the Supervisor makes a preliminary pass on the Supervisor orders. The idea is that after this preliminary pass, everything happens as if the command file only contains ordinary commands. This preliminary pass can be considered as pre-processing the command file. The « echo » of the command file (found in file MESSAGE) represents the status of the command file after this preliminary phase.

The 7 current Supervisor commands are divided into two: those that are destroyed at the end of the preliminary pass: INCLUDE, PROC, RETURN, and MACRO_MATR_ASSE and those that are not destroyed: DEFI_VALEUR, FORMULE, and DETRUIRE. For these last 3, we will therefore go through the associated routine OPS00i three times: preliminary pass, additional check pass and execution pass.

The main purpose of Supervisor commands (in addition to allowing « include », the use of interpreted functions and named constants) is to allow the development of « macro » commands; MACRO_MATR_ASSE is an example. During the preliminary pass, the MACRO_MATR_ASSE command dynamically generates the text of several ordinary commands and is then destroyed. The development of such macro commands is documented in [D5.01.02].

Let’s say the command file:

C_O1

C_S1

C_O2

C_S2

C_O3

where:

C_Oi

are ordinary commands

C_Si

are Supervisor commands

C_S1

is a macro-command Supervisor command that generates the ordinary C_O4 and C_O5 commands. C_S1 is destroyed at the end of the preliminary pass

C_S2

is a Supervisor command that cannot be destroyed

  • Pass sequence if DEBUT (PAR_LOT: “OUI”)

  • preliminary pass (for supervisor orders only): (pp)

  • C_S1

pp

  • C_S2

pp

  • pass additional checks: (pv)

  • C_O1

pv

  • C_O4

pv

  • C_O5

pv

  • C_O2

pv

  • C_S2

pv

  • C_O3

pv

  • execution pass: (pe)

  • C_O1

pe

  • C_O4

pe

  • C_O5

pe

  • C_O2

pe

  • C_S2

pe

  • C_O3

pe

  • Pass sequence if DEBUT (PAR_LOT: “NON”)

- C_O1 pc

- C_O1 pe


- C_S1 pp


- C_O4 PV

- C_O4 pe


- C_O5 pc

- C_O5 pe


- C_O2 pv

- C_O2 pe


- C_S2 pp

- C_S2 VP

- C_S2 by


- C_O3 PV

- C_O3 pe