<figure><img src="image_1.png" /></figure>

HAL
open science

# Le processeur COSU sous siris-7/8, un interpréteur de processus de test des entrées-sorties

Alain Jorry

<figure><img src="image_2.png" /></figure>

## To cite this version:

Alain Jorry. Le processeur COSU sous siris-7/8, un interpréteur de processus de test des entrées-sorties. [Rapport de recherche] IRIA-RR-094, IRIA. 1975, pp.63. hal-04716125

HAL Id: hal-04716125

https://inria.hal.science/hal-04716125v1

Submitted on 1 Oct 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_3.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
RIA
laboria

laboratoire de recherche
en informatique
et automatique

Le processeur COSU sous SIRIS-7/8,
un interpréteur de processus
de test des entrées-sorties

<figure><img src="image_4.png" /></figure>

Institut de Recherche
d'Informatique
et d'Automatique

Domaine de Voluceau
Rocquencourt
78150 - Le Chesnay
Tél. 954.90.20

Rapport de Recherche n° 94

Janvier 1975
<figure><img src="image_5.png" /></figure>
LE PROCESSEUR COSU sous SIRIS-7/8,
UN INTERPÉTEUR DE PROCESSUS DE TEST DES ENTRÉES-SORTIES

A. Jorry

(présenté par M. Depeyrot)

## Sommaire.

Le processeur COSU (Conversationnel Sous Utilisateur) est un processeur qui autorise le test "sous usager" des périphériques des calculateurs CII 10070 et IRIS 80 sous SIRIS-7/8.

Ce projet, lancé à l'ENSIMAG (Ecole Nationale Supérieure d'Informatique et de Mathématiques Appliquées de Grenoble) en octobre 1972 pour apporter la preuve de la faisabilité d'un tel système, a été terminé et mis au point à l'IRIA (Institut de Recherche en Informatique et en Automatique).

Ses buts, les méthodes utilisées pour les atteindre, et les conséquences à en tirer sont décrits et analysés.

## Abstract.

The COSU THROUGH-LINE-TEST-PROCESS-GENERATOR has been designed as a package that would allow through-line test of the CII 10070 and IRIS-80 computers peripheral devices under the SIRIS-7/8 operating system.

This project started in October 1972 at the ENSIMAG (Ecole Nationale Supérieure d'Informatique et de Mathématiques Appliquées de Grenoble) to prove the feasibility of such a package, has been completed at the IRIA (Institut de Recherche en Informatique et en Automatique) (July 1974).

Its aims, the ways used to reach them, its consequences are described and analysed.
<figure><img src="image_6.png" /></figure>
Avertissement.

=============

COSU est la première réalisation de l'équipe travaillant sur le test
des systèmes informatiques dans le cadre du projet Conception Exploitation
et Test Automatisés des Systèmes Industriels.

C'est à dessein que sa présentation a été retardée de juin à octobre,
pour que paraisse tout d'abord un rapport de Recherche [G.18], définissant
le problème du test, et la philosophie des travaux entrepris.

Nous ne traiterons donc pas de ces sujets, pour nous consacrer à la
description d'un outil opérationnel, et de ses retombées, c'est pourquoi nous
invitons le lecteur à se référer à l'article sus mentionné pour situer COSU
par rapport au problème du test en général.

Un travail de l'ampleur de COSU ne peut être effectué qu'avec l'aide
de très nombreuses personnes.

En tout premier lieu, nous devons remercier les instigateurs du projet
Messieurs Decitre et Roux ainsi que toute l'équipe d'exploitation du CS -CII-Greno-
ble et tout spécialement Monsieur André.

Nous sommes particulièrement reconnaissants envers Monsieur le Professeur
Bolliet, Madame G. Saucier, Messieurs Decitre, Roux et Veillon qui ont eu à juger
ce travail en juin 1973 pour leur appréciation favorable.

Que Monsieur Depeyrot qui nous a permis de poursuivre ce travail trouve
ici l'expression de notre gratitude.

Nous tenons à remercier l'équipe d'exploitation du centre de calcul
de l'IRIA, et en particulier, Monsieur Bonneau pour l'aide apportée lors de
la mise au point.

Ce document a été réalisé par Mme Barny. Qu'elle en soient sincèrement
remerciée.

A. JORRY
(Octobre 1974).
Sommaire.

Avertissement.

Introduction.

I. Historique du projet.

II. Spécifications des objectifs.

1) Présentation d'ensemble.

2) Spécification du matériel alloué pour la réalisation.

3) Environnement Matériel-Logiciel à l'exécution.

4) Dialogue Opérateur.

5) Méthodologie de test.

6) Paramétrisation.

7) Système de diagnostic.

III. Historique du développement de COSU, ou description incrémentale du système.

1) Résumé des objectifs.

2) Le langage TL2A.

3) Création et conservation des programmes de test.

4) Mode d'exécution des programmes de test.

5) Le langage TL2C et la mise en oeuvre de COSU.

6) Le langage TL2I et le test conversationnel.

7) Le superviseur et le parallélisme asynchrone.

IV. Description des diverses parties de COSU.

1) Description globale de COSU.

2) Le langage de programmation TL2A.

3) Le langage intermédiaire TL20 et le module chargeable.

4) L'éditeur et le langage TL2E.

5) Le système de gestion des fichiers.

6) Le système de gestion mémoire.

7) La gestion de la multiprogrammation.

8) Le langage de commande (TL2C, TL2I).
V. Possibilités d'extension.

VI. Conclusions sur la technique des "Tests-sous-Usager" (Through-Line Tests).

1) Coût de COSU.

2) Coût comparé des systèmes de test.

3) Difficultés rencontrées.

4) Performances.

Conclusion

Annexe A : Organigramme des états de la console.

Annexe B : Le langage TL2.

Bibliographie.
<figure><img src="image_7.png" /></figure>
## Introduction.

Les problèmes de reconfiguration des systèmes informatiques, le principe de leur fonctionnement en mode dégradé, ont trouvé depuis quelques temps un certain nombre de solutions. Ceci a créé un nouvel état d'esprit face à ces systèmes, qui permet d'envisager le test des périphériques sous un jour différent ; qu'il s'agisse du test préventif, exécuté lors des visites systématiques de maintenance, ou du test de dépannage exécuté lorsqu'une anomalie est détectée.

L'idée qui s'est fait jour est la suivante, partager le système informatique en deux sous-configurations, l'une d'exploitation en dégradé, l'autre de test. Il est à noter que cette idée n'est qu'une extension de l'idée de multiprogrammation; en effet, dans un système multiprogrammé, chaque utilisateur travaille sur une sous configuration qu'il définit au lancement de son programme, grâce au langage de commande. Pour ce qui est du test, cela ne pose aucun problème si le processeur de test est externe à la configuration (testeur-matériel, inspecteur). Les problèmes apparaissent quand les deux sous-configurations doivent partager le même processeur, dans la plupart des cas l'unité-centrale d'un système monoprocesseur, les programmes de test refusant de se plier aux contraintes d'un partage (adressage absolu, absence d'overlay, attentes actives). Jusqu'à présent donc, ces principes de sous configurations non distinctes qui sont ceux de la multiprogrammation n'étaient pas appliqués aux programmes de test en exploitation normale.

Le problème posé est donc de savoir s'il est possible de n'utiliser que le système de sous-configuration offert par le langage de commande pour faire exécuter des programmes de test en parallèle avec l'exploitation. La réponse est oui, pourvu que l'utilisateur dispose de pouvoirs suffisants sur la sous-configuration qui lui est allouée.

Deux optiques apparaissent alors : créer un système qui admette des utilisateurs aussi privilégiés que les programmes de test AUTONOMES (STAND-ALONE) existant à l'heure actuelle ; ou bien, écrire des programmes de test qui se satisfascent des possibilités offertes par les systèmes existants.
La première optique est celle d'un produit comme OLTEP [A.9] et des tests sous système, la seconde, est celle de COSU et des tests sous utilisateur. Il est de bon augure de constater que ces deux optiques se rejoignent quant à leurs conclusions, et que seule la récupération des programmes existants dans leur forme actuelle soit un obstacle pour le test sous utilisateur; l'obstacle tient principalement au fait que tout l'adressage est en binaire absolu non translatable.

Rappelons la classification des tests selon leur mode d'exploitation telle que définie dans le Rapport de Recherche LABORIA n° 80 [G.18] :

AUTONOME ou STAND-ALONE pour un protest travaillant sur une machine nue.

SOUS-MONITEUR ou OFF-LINE pour un protest géré par un moniteur de test en dehors de l'exploitation.

SOUS-USAGER ou THROUGH-LINE pour un protest multiprogrammé avec les usagers.

SUR-OUTIL ou OUT-LINE pour un test externe sur outil.

SOUS-SYSTEME ou ON-LINE pour un protest multiprogrammé avec le système.

MICRO-DIAGNOSTIC ou IN-LINE pour un microtest multiplexé.

COSU est avant tout le noyau commun à tous les tests SOUS-USAGER (THROUGH-LINE). Ce noyau a été conçu comme un ensemble de procédures et de services accessibles à l'aide d'un langage (THROUGH-LINE-TEST-LANGAGE ou TL2) et vus par le système d'exploitation comme un usager standard.

COSU est un prototype qui visait à offrir le maximum des services tolérables par SIRIS-7/8, et à définir les modifications minimales à apporter à SIRIS-7/8 ou à tout autre système, pour rendre le test SOUS-USAGER aussi puissant que le test SOUS-SYSTEME.

L'évolution des systèmes de test depuis l'apparition des périphériques microprogrammés tend à séparer microtests localisateurs exécutés par l'unité de commande et protests ON-LINE écrits dans un langage de haut niveau et exécutés sur l'unité centrale en parallèle avec l'exploitation. COSU cherche à utiliser au mieux ce distinguo en intégrant de plus, grâce au dispositif de conversation les possibilités de la télémaintenance.

<footnote>* Protest : programme de test.</footnote>

<footnote>** Microtest : microprogramme de test.</footnote>
# I. Historique du projet.

Le projet COSU a été mis à l'étude en octobre 1972 à la demande du Centre Scientifique de la Compagnie Internationale pour l'Informatique (CS-CII) de Grenoble. (Monsieur P. DECITRE) et de la Direction Après Vente de cette même compagnie (DAV-CII) (Monsieur V. ROUX).

Placée sous la responsabilité de Monsieur le Professeur L. BOLLIET, cette étude a été entreprise par deux étudiants de l'ENSIMAG, Messieurs A. JORRY et M. MOALLA dans le cadre de leur projet de troisième année. Ceux-ci ont éffectué la phase de définition et de réalisation, mais les problèmes posés par SIRIS-7 à l'époque ont empêché que se termine la phase de Mise Au Point (MAP) avant juin 1973.

Le projet a alors été confié à Monsieur M. DEPEYROT, conseiller scientifique du projet CETASI (IRIA-LABORIA), qui a alors demandé à Monsieur A. JORRY (IRIA-LABORIA) de bien vouloir en assurer la Mise Au Point et la documentation, dans le cadre des travaux sur le test entrepris dans ce projet.

La Mise au point s'est donc effectuée en Mai et Juin 1974 avec l'aide de deux stagiaires de l'Ecole Nationale Supérieure des Mines de Paris (ENSMP), Messieurs J. THIBAULT et G. VIGREUX.

La documentation a été réalisée en juillet et août 1974, afin de faire de COSU un package opérationnel et utilisable, tandis que depuis septembre 1974, un certain nombre d'articles regroupant tous ceux qui ont participé à ce projet ont été soumis pour publication [G.12, G.19].

Les machines CII-10070 et IRIS-80 sont compatibles avec celles de la gamme Σ de XDS (anciennement SDS). C'est pourquoi certaines terminologies des programmes de test s'y retrouvent. Ainsi on parle de mode DPM ("Diagnostic Program Monitor") pour les programmes autonomes et préassemblés de test d'une unité périphérique; et de mode DCP ("Diagnostic Control Program") pour les programmes autonomes générateurs de test d'une unité périphérique ; les premiers sont écrits en langage d'assemblage SYMBOL (ou METASYMBOL), les seconds dans un langage de DIRECTIVES spéciales à chaque type de périphériques.
## II. Spécifications techniques.

### II.1. Présentation d'ensemble.

Comme nous l'avons mentionné dans l'introduction, l'évolution des systèmes de test vise à une séparation des programmes de test en protests et microtests, les protests n'étant qu'un ensemble de programmes d'échange, judicieusement choisis et coordonnés pour mettre à jour les anomalies, et permettant de décider quelle gamme de microtests mettre en jeu (DIAGNOSTIC REFERENTIEL), ces microtests servant alors à circonscrire la panne (DIAGNOSTIC LOCALISATEUR).

COSU se situe au niveau protest, c'est-à-dire que son rôle se borne à faire exécuter en vue de test des programmes d'échange sur des périphériques donnés. Néanmoins, un certain nombre de contraintes supplémentaires et de services complémentaires ont été prescrits.

Les programmes pourront être préexistants et répertoriés, ou crées sur le site (lieu du test) pour les besoins de la maintenance ou de toute autre personne désirant effectuer un test.

Ils pourront être exécutés en mode automatique (DPM) ou en mode conversationnel, guidés par l'Opérateur-COSU (DCP) ; cet opérateur-COSU pouvant être un inspecteur de maintenance de niveau 1, ou de niveau 2, un pupitreur, un spécialiste opérant à distance (TELE-MAINTENANCE) ou toute autre personne apte à orienter le test de manière fructueuse.

COSU doit mettre au service de l'Opérateur-COSU un langage de programmation des tests simple et pratique, tout en étant le plus puissant possible, ainsi qu'un ensemble de directives propres à guider le test.

COSU doit de plus, ce qui le différencie des autres moniteurs de test, travailler sous usager, c'est-à-dire, n'utiliser que ce que le système met à sa disposition en mode esclave.

Notons dès maintenant les deux astuces qui permettent de satisfaire à la contrainte précédente : 1) COSU s'exécute dans une classe qui lui autorise le mode
maître. Il ne s'en sert pas, mais il acquiert cependant avec ce droit une très forte priorité.

2) SIRIS-7 permet pour les périphériques non-standards une programmation au niveau programme canal; c'est-à-dire que pour les périphériques pour lesquels il n'est pas prévu de routines dans le système (macro-instructions, appels superviseur) l'utilisateur peut (puisqu'il le doit) programmer au niveau canal. COSU laisse croire à SIRIS-7 que les périphériques qu'il met en oeuvre sont non-standards, et ainsi s'arroge le droit de les programmer au niveau canal.

COSU doit de surcroît pouvoir assurer le pseudo-parallélisme asynchrone entre divers programmes de test s'exécutant concurement.

Il faudra envisager la possibilité de pseudo-parallélisme synchrone, soit au moyen des routines-système existantes, soit en en créant de nouvelles (voir la partie consacrée aux extensions).

Dans un premier temps, la gamme visée est celle des périphériques des calculateurs 10070 et IRIS-80 sous système SIRIS-7/8. Néanmoins, du fait de son écriture en mode esclave et en langage d'assemblage, COSU est portable sur tous les systèmes compatibles, en particulier, la gamme UNIDATA sous système SIRIS-8X. La compatibilité vers les bas de gamme est conceptuellement simple, bien que pratiquement fastidieuse, il suffit de simuler les services SIRIS-7/8 utilisés par COSU, et traduire le code METASYMBOL en ASSIRIS.

Dans un premier temps, également, les options "DIAGNOSTIC AUTOMATIQUE" (par dictionnaire d'erreur), "JOURNAL D'ERREURS", "AUTO-APPRENTISSAGE" (auto-remplissage du dictionnaire), ne seront pas intégrées, néanmoins, elles figurent parmi les objectifs du projet.

## II.2. Spécification du matériel alloué pour la réalisation.

Les moyens octroyés pour la réalisation sont ceux tant matériels que logiciels mis à la disposition de tout utilisateur dans les centres de calcul de l'IMAG et de l'IRIA.
TL2I t, directives d'interrogation sur l'état des programmes dont
COSU a la charge (t pour test de l'état).

TL2I o, ordres permettant d'orienter le test.

3) **TL2E** langage d'édition des programmes permettant la création ou la modification des programmes de test.

4) **TL2C** langage de commande de COSU permettant de lancer les programmes, d'appeler l'éditeur, de demander un assemblage, de dialoguer avec le pupitreur du site.

Un ensemble de messages doit de même être défini, qui permette de tenir l'opérateur-COSU informé du bon ou du mauvais déroulement des opérations lancées. Ces messages devront permettre de connaître toutes les anomalies rencontrées dans quelque phase que ce soit, de signaler toutes les erreurs, d'indiquer toutes les actions effectuées pour y remédier et de tenir l'utilisateur informé de toutes les modifications intervenant dans l'état d'un programme.

Il est admis qu'à chaque exécution d'un programme, à chaque processus de test soit associé un nom interne (le numéro de l'activation modulo 1000) afin de distinguer les divers processus bâtis sur le même programme. C'est ce nom interne qui sera invoqué dans le dialogue.

Une description plus détaillée de ce dialogue est donnée en [G.4].

## II.5. Méthodologie de test.

Les tests se font par exécution de programmes canaux judicieusement choisis et agencés. Le choix entre les divers programmes peut se faire soit statiquement, lancement d'une suite de programmes unité d'échange, soit dynamiquement automatiquement, à l'aide d'instructions conditionnelles, soit dynamiquement en conversationnel, à l'aide du sous langage TL2I.

Les programmes de test existants ne sont récupérables qu'au prix d'une traduction en TL2A, cette traduction pouvant être automatique ou manuelle.
Les programmes de test sont mis en forme au clavier de la machine à
écrire, si cela s'avérait nécessaire, une entrée via un lecteur de cartes serait
envisagée.

## II.6. Paramétrisation.

La paramétrisation du système se fait à trois niveaux :

1) **À la génération** (Assemblage), grâce aux paramètres de génération, pour ce qui est du degré de multiprogrammation, de la taille maximale des programmes de test,...

2) **À la génération** (Assemblage) par substitution pour ce qui est du libellé des messages, de l'orthographe des commandes,... puisque ces éléments sont définis par l'initialisation de zones mémoire.

3) **Au lancement** de COSU pour ce qui est de la configuration de test : taille mémoire (limite CORE), espace alloué sur l'unité à accès direct (limite SPDISC), périphériques réservés (cartes !ASSIGN).

**Nota** : la configuration maximale de test est définie à la génération (configuration du site), mais au lancement, on dispose de deux degrés de liberté; on peut réduire la dite configuration en ne demandant que les périphériques nécessaires, et on peut intervertir les noms des périphériques.

## II.7. Système de diagnostic.

Les diagnostics sont dans un premier temps donnés sous la forme des bits d'état tels que retournés après l'exécution des instructions AIO, TIO, TDV, c'est-à-dire deux octets imprimés en hexadécimal.

Dans un deuxième temps, ils seront analysés via un dictionnaire auto-
remplissable, qui doit avoir le format et les propriétés suivants.

Il se présente comme un tableau d'arbres à quatre entrées, (Programme, périphérique, UE, UL). La sélection d'un arbre étant faite par la spécification de ces quatre paramètres, la descente dans l'arbre se fera par l'analyse des bits rendus par les instructions AIO, TIO, TDV.

Ayant associé à chaque noeud la réponse type fournie par un périphérique étalon (sain), noeud à noeud, les réponses sont comparées aux réponses type, si une différence est constatée, on liste tous les cas de panne où un tel profil de ré-
ponse a été obtenu et les moyens de les distinguer (diagnostic référentiel).
Si après exécution des séquences de discernement la panne réelle correspond à
celle diagnostiquée, on se contente de la mémoriser sur le journal d'erreur ;
sinon, le dictionnaire doit enregistrer cette nouvelle panne, et la méthode
utilisée pour la diagnostiquer.

Ce dictionnaire doit donc être modifiable par adjonction de nouveaux diagnostics,
et par adjonction ou suppression d'un élément (programme, périphérique, unité
d'échange, unité de liaison), et du ou des arbres correspondants.
### III. Historique du développement de COSU, en forme de description incrémentale du système.

#### III.1. Résumé des objectifs.

COSU est un processeur travaillant en mode asservi, destiné à faciliter l'emploi de la routine système de lancement de programmes canaux (M:EXCP) afin de pouvoir l'utiliser pour tester les périphériques des calculateurs CII10070 et IRIS-80.

Cette facilité d'emploi a été définie comme la réunion de quatre objectifs :

- simplicité d'écriture des programmes de test (en particulier des programmes'unité d'échange).

- simplicité du système de réservation mémoire.

- possibilité de travail en conversationnel.

- possibilité d'exécution en multiprogrammation des programmes de test.

#### III.2. Le langage TL2A.

Pour réaliser les deux premiers objectifs, il a été décidé d'organiser le processeur COSU autour d'un langage simple permettant d'écrire facilement des programmes de test, et prenant en charge le maximum du travail annexe, à l'aide des trois ensembles d'instructions.

1) TL2A a, instructions d'action, au nombre de deux :

TRANSF, mouvement de données d'une zone dans une autre,

SIO, lancement d'un programme d'échange; cette instruction demande l'exécution de l'entrée sortie, tout comme M:EXCP, mais de plus, COSU se charge de la génération du bloc de contrôle (IOB) et de la traduction réel-virtuel des adresses.

2) TL2A m, directives de réservation et/ou initialisation mémoire, au nombre de quatre:

RES et RESC réservation et/ou initialisation mémoire,

PATTERN, PATTERNC, réservation et initialisation à une valeur calculée par l'assemblée.
3) TL2A c, six instructions de contrôle et test;

SI, instruction de commande d'une phase conditionnée.

DØ - FDØ, instructions de commande d'une phase itérative.

B, pour brancher, instruction de branchement inconditionnel.

COMPARE, instruction conditionnant une phase du programme, qui n'est exécutée qu'en cas d'égalité des éléments comparés.

### III.3. Création et conservation des programmes de test.

Ce langage nous a semblé suffisant, du moins dans un premier temps, pour permettre toutes les opérations requises lors d'un test ; par conséquent, il a été décidé que les programmes de test seraient écrits au moyen de ce langage.

Pour répondre au critère de simplicité, un éditeur conversationnel a été mis au point, (conversationnel a ici aussi son sens plein de dialogue et non celui réduit d'éditeur à entrée par machine à écrire). La plus grande partie des problèmes de stockage étant confiée au système de gestion des fichiers de SIRIS-7.

### III.4. Mode d'exécution des programmes de test.

Ce langage, le mode d'entrée et de stockage des programmes de test étant définis, nous avons alors dû choisir entre deux solutions pour l'exécution, soit l'assemblage direct en code machine (10070, IRIS-80), soit l'interprétation.

L'assemblage présente le désavantage de ne laisser au système aucun contrôle sur le programme durant son exécution, à moins d'insérer après chaque instruction une routine de détection d'erreurs, puisqu'il n'existe pas de structure de protection hiérarchisée sur les calculateurs visés. De plus, le multitasking de SIRIS-7 n'étant pas opérationnel, il était impossible de se désolidariser des programmes de test, et en cas d'erreur de l'un d'eux, tout le système COSU risquait d'être avorté.

L'interprétation présente le désavantage de la lenteur d'exécution, la difficulté de résolution des références, et la lourdeur de la détection d'erreurs de programmation en temps réel. De plus, le problème de la réservation mémoire devenait quasi insurmontable.
C'est pourquoi nous avons opté pour une solution hybride, consistant en
un assemblage dans un code intermédiaire, présentant les caractéristiques d'un
code machine, mais qui serait interprété par un sous programme de COSU spécialement
conçu. Ce code est généré à partir du programme source par un sous-programme d'as-
semblage qui résoud les références, corrige ou signale les erreurs, et traduit
les demandes de réservation de mémoire en termes d'occupation-mémoire de divers
types. C'est l'ASSEMBLEUR, qui dans la version actuelle est résident ; tandis que
l'EXECUTEUR, est chargé d'effectuer les actions requises par le code généré.
Ainsi donc, le premier noyau de COSU se résume ainsi :

<figure><img src="image_8.png" /><figcaption>Figure 1 : Le noyau de COSU.</figcaption></figure>

L'Editeur sert à bâtir les fichiers-source des programmes de test.

Le problème des réservations mémoire introduit un quatrième élément :

<figure><img src="image_9.png" /><figcaption>Figure 2 : COSU muni de son système de gestion de la mémoire.</figcaption></figure>
### III.5. Le langage TL2C et la mise en œuvre de COSU.

Il est évident que COSU doit de plus disposer d'un langage de commande, destiné à mettre en jeu chacun de ces éléments.

Ce langage ne nécessite pour l'instant que quatre commandes :

- Editer un fichier,

- Assembler un fichier,

- Exécuter un fichier,

- Terminer la session ;

mais il nécessite néanmoins un décodeur.

Il a été décidé deux choses :

1. Ces commandes seraient entrées via une Machine A Ecrire (MAE).

2. Cette MAE serait gérée par le Système de Gestion des Transmissions de SIRIS-7/8, (SGT-S7/8) du moins dans un premier temps.

Il est néanmoins très simple de revoir ces options pour utiliser soit la console-opérateur (pupitre), soit les consoles de visualisation adjointes au pupitre, soit le frontal de télémaintenance, à la condition de pouvoir utiliser de nouvelles routines de lecture écriture sur ces appareils, (M:TYPE, M:KEYIN)* avec mise en attente différée, comme pour celles fournies par le SGT (M:READ, M:WRITE).*

Nous en arrivons donc au schéma donné en figure 3.

A cet instant, nous disposons du sous-ensemble de COSU nécessaire et suffisant pour faire exécuter en monoprogrammation et en mode automatique (DPM) les programmes de test :

Un logicien de test créé un programme et le fait assembler.

Un opérateur de test lance l'exécution de ce programme.

Un inspecteur de maintenance peut assumer les deux fonctions.

<footnote>* M : signifie qu'il s'agit d'une routine système. Pour les MAE gérées par le SGT il existe deux routines M:READ (lecture) ; M:WRITE (écriture) pour demander l'entrée-sortie, et une routine M:WAIT pour le cas échéant se mettre en attente sur l'événement fin d'entrée-sortie. Pour les MAE non gérées par le SGT, la mise en attente est intégrée au lancement de l'E/S (M:TYPE, M:KEYIN).</footnote>
<figure><img src="image_10.png" /><figcaption>Figure 3 : COSU muni de son système d'E/S.</figcaption></figure>
### III.6. Le langage TL2I et le test conversationnel.

Nous avons vu que le schéma précédent représente la configuration minmale satisfaisant aux deux premiers objectifs. Reste à satisfaire les deux suivants et tout d'abord introduire la possibilité de dialogue.

Pour ce faire, nous introduisons dans le langage de programmation des tes une instruction de conversation : WCONS (Wait on CONSOLE, mise en attente d'ordres extérieurs). L'exécution de cette instruction met la tâche dans l'état attente d'un ordre de l'opérateur-COSU.

Nous augmentons de plus le langage TL2 du sous langage TL2I, que nous divisons en :

1) **TL2I t**, instructions servant à s'informer sur l'état de la tâche (tester).

T (pour Test), qui permet de connaître la valeur du mot d'état de la tâche (cf. diagramme des états).

RT (pour Résultat des Tests), qui permet de connaître la réponse du périphérique aux sollicitations.

2) **TL2I o**, instructions servant à transmettre des ordres à la tâche:

WAIT, qui permet d'arrêter la tâche pour un temps.

PEX (Poursuite EXécution), qui permet de la relancer en séquence.

B (pour Brancher), qui permet un déroutement de la tâche.

STOP qui permet un arrêt définitif de la tâche.

Nous ajoutons également au langage TL2A une pseudo instruction ETIQ:, qui sert à définir des étiquettes dont la valeur est conservée jusqu'à l'exécution pour permettre les déroutements depuis la console.

Ces nouvelles options définissent maintenant l'utilisation de COSU en mode mixte, exécution automatique (DPM)/exécution conversationnelle (DCP). Comme précédemment, le mode DPM pur est possible, mais l'introduction du dialogue permet un déroulement au gré de l'opérateur COSU.
<figure><img src="image_11.png" /><figcaption>Figure 4 : Graph des états des tâches protest.</figcaption></figure>

Les transitions *xx* correspondent à un ordre externe (*IT* interruption).

Les transitions xx correspondent à l'exécution d'une instruction assemblée.
### III.7. Le superviseur et le parallélisme asynchrone.

Pour ce qui est de satisfaire au quatrième objectif prescrit, la multi-programmation, ou pseudo parallélisme asynchrone, (par opposition au contrôle de simultanéité dans les tests de canaux ou parallélisme synchrone), cela se fait grâce à un superviseur destiné à gérer l'exécution simultanée de plusieurs programmes de test.

C'est-à-dire, entre autres, intercepter toute demande de service destinée à SIRIS-7, risquant d'influencer l'exécution des programmes de test coexistants, en particulier, toute demande d'attente sur événement, qui si elle était transmise directement, mettrait en attente tout le système COSU et les travaux en dépendant.

Ces demandes de mise en attente, celles d'espace mémoire,..., sont donc interceptées par le superviseur, et retransmises en temps opportun, après examen.

Ce superviseur se charge de plus de coordonner l'exécution de ces programmes de test avec celle des divers modules de COSU déjà énumérés.

Nous introduisons également un chargeur destiné à libérer l'exécuteur de la tâche de chargement (figure 5).

Dans la version actuelle, décodeur, assembleur, éditeur et gestion de fichiers sont regroupés dans un même module, EDI ; le superviseur, l'exécuteur le chargeur, la gestion mémoire dans un second, SYS. Ce qui donne le schéma suivant (figure 6) ; valable uniquement pour cette version.
<figure><img src="image_12.png" /><figcaption>Figure 5 : COSU, schéma de principe.</figcaption></figure>
<figure><img src="image_13.png" /><figcaption>Figure 6 : COSU, schéma de la version actuelle.</figcaption></figure>
# IV. Description des diverses parties de COSU.

## IV.1. Description globale de COSU.

COSU est un package de 7000 instructions METASYMBOL, soit 40000 octets de code. A l'heure actuelle, il fonctionne sans overlay, soit une imputation mémoire de 60000 octets ($20\text{Kb}^*$ sont imputables à SIRIS-7). En version avec overlay, l'imputation tombe à 10Kb, (3Kb résident, 5Kb SIRIS-7, 2Kb swapping).

Il fonctionne en mode asservi, n'utilisant de ses privilèges que la forte priorité et le droit de programmer les E/S au niveau canal (toujours en mode asservi, grâce à la routine système M:EXCP).

Il gère un nombre variable limité de tâches, (limite paramétrée fixée à 10 pour l'instant), de tailles variables limitées (limite paramétrée valant à 1'l'heure actuelle 128Kb), d'implantation mémoire aléatoire, les programmes étant partagés en pages de 2Kb, (512 mots de 4 octets) chaque page correspondant à un registre de base (à l'heure actuelle 128 : 2 = 64 registres), on utilise un système base/déplacement géré par logiciel, et chaque page est placée aléatoirement dans la mémoire physique, sauf pour les pages spécifiées comme devant avoir une implantation contigüe en mémoire physique, et qui sont alors placées aléatoirement en bloc.

Il gère une bibliothèque de programmes de taille paramétrée (pour l'instant 30 fichiers source + 30 fichiers assemblés).

L'usager dispose à son pupitre du langage TL2C (commande) de dialogue avec COSU, comportant 18 commandes qui lui permettent d'appeler les divers modules.

Le langage TL2I d'intervention est limité à six commandes jugées suffisantes pour pouvoir orienter fructueusement le test.

Le langage TL2E d'édition des fichiers supports des programmes source est celui classique d'un éditeur, augmenté du langage de conversation avec la routine d'aide à la rédaction des programmes canaux.

<footnote>* 1Kb ou Kilobyte $\triangleq 1024$ octets ($2^{10}$ octets).</footnote>
Le langage TL2A, d'écriture des programmes de test a été limité à
16 instructions ou pseudo-instructions.

Tous ces langages sont très aisément extensibles.

## IV.1. Le langage de programmation TL2A.

Ce langage est un langage de type langage d'assemblage, avec cependant
quelques possibilités d'un niveau plus élevé, en particulier pour les instructions
de contrôle. Il s'écrit à raison d'une instruction par ligne, avec des contraintes
syntaxiques assez sévères, mais qui sont simplifiées pour la partie la plus dif-
ficile (écriture des programmes canaux) par la procédure d'aide à la rédaction
(cf. §. IV.4. Editeur).

Nous n'avons pas développé pour ce prototype un grand nombre d'instruc-
tions, puisque la simplicité de sa grammaire le rend aisément extensible.

### - Instructions d'action.

TRANSF,<longueur>,<adresse 1>,<adresse 2>

Transfert de données d'un point à un autre.

SIØ: A <paramètres>

Lancement d'une entrée/sortie.

### - Instructions de contrôle.

B,<adresse>

Branchement inconditionnel.

DO-FDO

Instructions d'itération.

SI,<expression logique>,<instruction conditionnée>

Si l'expression logique a la valeur "vraie", l'instruction conditionnée est exécutée.

COMPARE,<longueur>,<adresse 1>,<adresse 2>,<instruction conditionnée>

Si les deux zones sont identiques, l'instruction conditionnée est exécutée.
WCONS

Au passage sur cette instruction, il y a émission d'un message et
mise en attente d'ordres.

STOP

Instruction d'arrêt définitif de l'exécution.

- *Pseudo instructions d'assemblage.*

ETIQ: <nom>

Déclaration d'une étiquette qui restera connue au moment de l'exécution
pour permettre les déroutements conversationnels.

FINPC

Indique la fin d'un programme canal.

FIN,<adresse de début>

Indique la fin physique du code, 'adresse de début' étant l'adresse de début logique du programme, qui est prise par défaut identique à l'adresse de début physique.

- *Pseudo instructions de réservation mémoire.*

RES,<paramètres>

Réservation avec ou sans initialisation d'une zone mémoire.

RESC,<paramètres>

Réservation avec ou sans initialisation d'une zone mémoire dans des
pages physiquement contigües à l'exécution.

PATTERN,<paramètres>

Construction d'un profil d'E/S(*), dans une zone mémoire réservée à
cet effet.

PATTERNC,<paramètres>

Construction d'un profil d'E/S (*), dans une zone mémoire réservée à
cet effet dans des pages physiquement contigües à l'exécution.

<footnote>(*) "Profil" signifie ensemble d'octets ayant certaines caractéristiques dont la transmission permet le test d'une partie du périphérique (déterminée par les caractéristiques) de tels ensembles peuvent être générés automatiquement par COSU qui initialise la zone mémoire avec cet ensemble ainsi généré("pattern").</footnote>
Grammaire du langage TL2A.

<Programme> ::= <suite d'instructions>L<instruction fin>

<instruction fin> ::= FIN <Λ><adresse de début><Λ><commentaire>

<adresse de début>::= <adresse>

L : changement de ligne.

<Λ>::= '∫' | ',' (séparateurs, '∫' caractère 'blanc')

<suite d'instructions>::= <instruction commentée>

<instruction commentée> L <suite d'instructions>

<instruction commentée>::= <instruction><Λ><commentaire>

<instruction>::= <instruction TRANSF> | <instruction E/S> | <instruction B>

<instruction DØ> | <instruction SI> | <instruction COMP>

<instruction STOP> | <instruction WAIT> | <instruction Memoire>

<instruction ETIQ> | <instruction commentaire>

<instruction TRANSF>::= TRANSF<Λ><longueur><Λ><émetteur><Λ><récepteur>

<longueur>::= <nombre 4>

<émetteur>::= <adresse>

<récepteur>::= <adresse>

<instruction E/S>::= SIO: <identificateur>L<suite CUE>L FINPC<Λ><commentaire>

<suite CUE>*::= <CUE> | <CUE> L <suite CUE>

<CUE>::= <identificateur><Λ><type périphérique - étiquette logique>Λ<ordre>

<Λ><données><Λ><compte d'octets><Λ><indicateurs><Λ><commentaire>

<données>::= <adresse> | <pattern>

<type périphérique - étiquette logique> ::= défini à la génération voir liste.

<ordre> ::= voir liste.

<indicateurs> ::= voir liste.

<instruction B> ::= B<Λ><adresse>

<instruction DØ> ::= DØ <nombre 4> L <suite d'instructions> L FDØ

<instruction SI> ::= SI<Λ><expression logique><Λ><instruction conditionnée>

<instruction conditionnée> ::= <instruction B> | <instruction STOP>

| <instruction WAIT>

<expression logique> ::= <etat><LL><état><LL><état> | <état><LL><état> | <état>

<footnote>* Plus généralement appelée PUE pour Programme d'Unité d'Echange.</footnote>
`<état> ::= <nom état> = <valeur>`

`<nom état> ::= TIO | AIO | TDV`

`<valeur> ::= 2 codes hexadécimaux.`

`<LL> ::= ' & ' | ' | ' (' & ' EF logique ; ' | ' OU logique)`

`<instruction CMP> ::= COMP<Λ><longueur><Λ><adresse><Λ><adresse><Λ><instruction conditionnée>`

`<instruction STØP> ::= STØP`

`<instruction WAIT> ::= WAITCONS`

`<instruction mémoire> ::= <instruction RES> | <instruction RESC> | <instruction PATTERN> | <instruction PATTERNC>`

`<instruction RES> ::= RES <paramètres>`

`<paramètres> ::= <facteur de cadrage><Λ><nom><Λ><facteur de répétition><Λ><code caractère><chaine de caractères>`

`<facteur de cadrage> ::= 0|2|4|8`

`<nom> ::= ' , ' | <identificateur>`

`<facteur de répétition> ::= <nombre>`

`<code caractère> ::= C | X`

`<instruction RESC> ::= RESC <paramètres>`

`<instruction PATTERN> ::= PATTERN <paramètres 2>`

`<instruction PATTERNC> ::= PATTERNC <paramètres 2>`

`<paramètres 2> ::= <facteur de cadrage><Λ><nom><Λ><pattern>`

`<pattern> ::= <CH><Λ><IH><Λ><LS> * <NS>`

`<CH> ::= <valeur>`

`<IH> ::= <valeur>`

`<LS> ::= <nombre 4>`

`<NS> ::= <nombre 3>`

`<instruction ETIQ> ::= ETIQ:<identificateur>`

`<instruction commentaire> ::= * <chaine de caractères>`

`<adresse> ::= <identificateur déclaré>`

`<nombre 3> ::= 3 codes décimaux`

`<nombre 4> ::= 4 codes décimaux.`

`<identificateur> ::= 9 codes alpha-numériques.`

`<identificateur déclaré> ::= indéfinissable.`
Liste des types de périphériques qui ont été programmés :

MAE machine à écrire.

SYSPAP lecteur perforateur de rubans.

CR lecteur de cartes.

CP perforateur de cartes.

DIAM unité support de disques amovibles.

DIAD unité disque à accès rapide.

IMPRIM imprimante.

URM9T dérouleur de bandes magnétiques 9 pistes.
## Ordres des périphériques :

* **MAE** : Machine A Ecrire (Télescriptrice)

00 → Arrêt

01 → Impression

02 → Scrutation

05 → Impression - Fin/EOM

06 → Scrutation - Fin/EOM

86 → Scrutation - Fin/caractère de contrôle

* **SYSPAP** : Lecteur-perforateur de rubans.

00 → Arrêt

01 → Perforation

02 → Lecture sans cadrage

82 → Lecture totale

* **CR/CP** : Lecteur-perforateur de cartes.

00 → Arrêt (CP seulement)

01 → Perforation binaire, case normale

02 → Lecture binaire, case normale

05 → Perforation EBCDIC, case normale

06 → Lecture EBCDIC, case normale

0D → Perforation EBCDIC, erreur → case 1

0E → Lecture EBCDIC, erreur → case 1

11 → Perforation binaire, case 1

12 → Lecture binaire, case 1

15 → Perforation EBCDIC, case 1

16 → Lecture EBCDIC, case 1

80 → Arrêt + Interruption (CP seulement)

09 → Perforation binaire, erreur case 1

0A → Lecture binaire, erreur case 1

* **IMPRIM** : Imprimante.

01 → Impression d'une ligne (132 caractères)

03 → Format

05 → Impression + Format (133 caractères)
41 -> Impression + Interruption fin de transfert

43 -> Format + IT fin de transfert

45 -> Impression + Format + IT fin de transfert

* URM9T : Dérouleur de bandes magnétiques 9 pistes.

01 -> Ecriture

02 -> Lecture avant

03 -> Correction

04 -> Sense

0C -> Lecture arrière

13 -> Rebobinage + Interruption

23 -> Rebobinage + OFF Line

33 -> Rebobinage + ON Line

43 -> Saut bloc avant

4B -> Saut bloc arrière

53 -> Saut fichier avant

5B -> Saut fichier arrière

63 -> Effacement

73 -> Ecriture tape mark

* DIAD/DIAM : Unités support disques.

01 -> Ecriture

02 -> Lecture + erreur fin de transfert

03 -> Recherche

04 -> Position

05 -> Contrôle écriture

12 -> Lecture + erreur fin de secteur

83 -> Recherche + IT (DIAM seulement)
## Liste des Indicateurs :

Un indicateur est une suite de huit bits, ayant chacun un sens, et conditionnant une action, selon qu'ils valent 0 ou 1.

Ces huit bits ont la signification suivante [F.12] :

1 DC (Données Chaînées), chaînage de données (si égal à 1).

2 IZC (Interrupt Zero byte Count), interruption X'5C' quand le nombre d'octets restant à transmettre passe à zéro (si égal à 1).

3 CC (Commandes Chaînées), chaînage de commandes (si égal à 1).

4 ICE (Interrupt Channel End), interruption X'5C' à la fin de la commande (si égal à 1).

5 HTE (Halte Transmission Erronée), arrêt sur erreur de transmission (si égal à 1).

6 IUE (Interrupt Unexpected End), interruption sur arrêt anormal (si égal à 1).

7 SIL (Supprimer Incorrections Longueur), les longueurs incorrectes (enregistrement plus court que le compte d'octets) ne sont pas considérées comme erreurs (si égal à 1).

8 S (Sauts) la lecture est effectuée sans rangement en mémoire. (si égal à 1).
IV. Le langage intermédiaire TL20 et le module chargeable.

Le langage TI2A est traduit au moyen d'un assembleur à un seul passage en un code intermédiaire où les erreurs de syntaxe et les non-définitions sont exclues, où les références sont résolues et traduites en base/déplacement, où la table des étiquettes destinées au travail conversationnel est établie, où la génération des zones de données est effectuée.

L'instruction type de ce langage intermédiaire à la forme :

<n° de la ligne du source correspondant> <Code opération> <Opérandes en B/D>
4 bytes 1 byte n fois (1+2) bytes

Le système employé est le système base/déplacement, sans édition de liens, géré par logiciel.

Une page correspond à un registre de base (il peu y en avoir jusqu'à $2^8 = 256$) et contient 2048 octets ($2^{11}$) pour les calculateurs visés.

Le 'load-module' assemblé est un ensemble de N pages se décomposant comme suit :

* N1 pages de données devant être physiquement contigües en mémoire,
* N2 pages de données pouvant être placées aléatoirement en mémoire,
* N3 pages de code TL20.

Ces pages sont rangées sur disque dans cet ordre, tandis que le catalogue mémorise ces quatre nombres en face du nom du fichier.

Sur la première page de code, on trouve une table de correspondance entre la position d'une page sur le disque, et le numéro du registre de base qui lui est affecté, plus la table des étiquettes pour le déroulement conversationnel.
IV.4. L'éditeur et le langage TL2E.

Un éditeur, dont le but principal est la génération conversationnelle de programmes de test a donc été inclus dans COSU.

Cet éditeur, pour des raisons de simplicité de la gestion des fichiers a été partagé en deux modules.

Un module de création des fichiers (Entrée de Données).

Un module de modification des fichiers (Edit).

Ces deux modules correspondent à deux modes de fonctionnement de la partie EDI, (voir graphe des états de la console), et ont en commun une racine, le mode CREAT, qui sert à effectuer le travail de gestion du fichier (système de recopie, de changement d'organisation, etc.).

En mode CREAT on ne peut obtenir qu'un listage du fichier.

En mode Entrée de Données, on peut soit créer, soit compléter le fichier avec ou sans aide.

En mode EDIT, on agit au niveau ligne pour Lister, Remplacer, Détruire, Insérer.

Une aide que nous espérons précieuse est fournie pour l'écriture des programmes canaux par le sous programme GEN-PC, génération de programmes canaux, qui met au service de l'utilisateur un système de questionnaires et de contrôles qui lui permettent d'écrire des programmes canaux corrects (syntaxiquement au niveau COSU, syntaxiquement au niveau périphérique et sémantiquement au niveau périphérique), mais que l'utilisateur peut modifier pour les rendre incorrects au niveau périphérique, l'utilisateur pouvant en outre déconnecter ce sous programme simplement.
Cette procédure est en sommeil dans le mode Entrée de Données, et s'active dès la frappe d'un commencement de programme canal (SIO: <étiquette>), dès lors, des questions en clair sont posées, auxquelles l'utilisateur répond en clair, et ces réponses sont traduites en TL2A. En cas de réponse incorrecte un message est émis et la question est reposée. La procédure se rendort à la fin du programme canal (absence de chaînage).

L'utilisateur peut prévenir tout réveil grâce à l'option !NO-GENPC, ou redemander cette aide grâce à la commande !GEN-PC.

Le questionnaire comporte les interrogations suivantes :

PERIPH : ?

ORDRE : ?

PATTERN : ?

AD.DISQUE : ?

AD.MEMOIRE : ?

INDICATEUR : ?

CPT.D'OCTETS : ?

CPT.MAX : ?

LONGUEUR : ?

FORMAT : ?

## IV.5. Le système de gestion des fichiers.

En régime normal il n'existe qu'un catalogue du contenu de deux fichiers partitionnés gérés par le Système de Gestion des Fichiers de SIRIS-7, où sont stockés à raison d'une partition par fichier utilisateur, les fichiers supports du code source (TL2A) et objet (TL2Ø).

Ces deux fichiers sont IPGCTRL pour le code source et IPGASM pour le code objet. Le catalogue mémorise le contenu de ces deux fichiers, la taille de chacune des partitions, et les renseignements pré-cités sur les modules chargeables (N, N1, N2, N3).

Quant la partie EDI est dans les modes CREAT, EDIT, Entrée de Données, il existe de plus une copie sous forme indexée du fichier utilisateur en cours de traitement, c'est cette copie temporaire crée dans le fichier temporaire IPGTEMP qui est modifiée, puis recopiée dans IPGCTRL, avec utilisation d'un
système d'alternance sur les noms des fichiers utilisateur pour prévenir toute perte (On concatène au nom externe une fois la lettre A une fois la lettre B pour obtenir le nom interne de la dernière version, ce qui permet en cas d'accident en cours de recopie de toujours avoir une version du fichier, sans que pour cela l'utilisateur ait besoin de s'en préoccuper).

## IV.6. Le système de Gestion mémoire.

Lorsque l'utilisateur désire faire exécuter un programme, il en avertit COSU par une commande du sous langage TL2C. COSU se charge par son module de gestion mémoire de fournir l'espace nécessaire. En particulier, il faut noter que l'UC des calculateurs visés travaille en adressage virtuel, alors que les canaux travaillent en adressage réel (UC = Unité Centrale).

COSU doit donc travailler à la fois dans les deux modes d'adressage, il doit en particulier transformer les zones mémoire virtuelles qui lui sont octroyées en zones mémoire réelles pour faire travailler les canaux.

Ex : Soit l'ordre de transfert, écrire sur imprimante les deux mots 'AAAA' et 'BBBB' en une rafale 'AAAABBBB'.

Si COSU demande deux mots de mémoire virtuelle pour placer les données, leurs adresses virtuelles seront x et x + 1 alors que leurs adresses réelles seront totalement aléatoires (y,z). Cependant pour passer de l'un à l'autre, le canal considérera que z = y + 1 ce qui n'est que très peu probable.

Il y a deux possibilités : transformer l'ordre en deux sous ordres. (méthode normale sous S7) ou assurer que si y = f(x) alors z = f(x + 1) = y + 1. (solution adoptée pour COSU). Dans la première solution l'accent est mis sur le transfert uniquement, dans la seconde sur le transfert et sur le mode de transfert. Seule la seconde est acceptable pour le test.

Le problème est résolu pour partie à l'assemblage (Etablissement de la liste des endroits du programme où se posent ces problèmes) pour partie au
chargement (placer les données et les ordres destinés aux canaux dans des zones mémoire d'adresses réelles contigües), pour partie à l'exécution, traduction des adresses TL20 en adresses réelles.

Nous avons donc posé le problème de l'implantation de certaines parties des programmes utilisateur (les programmes canaux et leurs données) dans des pages physiquement contigües en mémoire centrale.

Un autre problème se pose, c'est celui de la gestion dynamique de la mémoire, sous SIRIS-7, la libération de pages se fait en LIFO, la première page libérée doit être la dernière acquise.

Or, rien n'indique que les programmes utilisateur consentiront à se plier à cette discipline, qui voudrait que le dernier lancé soit le premier à se terminer !!!!

Si de plus plusieurs modules agissent alternativement sur l'espace mémoire, le cafouillage devient extrême, l'un libérant les pages de l'autre...

C'est pourquoi nous avons décidé du système suivant :
Un bloc de mémoire de taille paramétrée est réservé au lancement du système, et une routine de gestion de ce bloc est chargée de satisfaire les demandes.

Ce bloc est partagé en deux sous blocs distincts, le premier est cons-
titué de m1 pages physiquement contigües en mémoire centrale ; le second de m2
pages d'implantation aléatoire.

Ces pages sont attribuées aux tâches utilisateur au moment de leur
chargement en fonction des paramètres mémorisés au catalogue.

La réservation de ce bloc est faite par un utilitaire, PCINIT, qui se
charge de vérifier qu'il existe un ensemble de m1 pages contigües parmi les
m1+m2 demandées et obtenues.
La gestion du second sous bloc se fait par trois routines, ASK, GETP, FREE, la gestion du premier par un utilitaire et une routine (PCONT et FREE).

Les trois routines servent à interroger sur la présence d'une page libre, à l'obtenir, à la relâcher.

L'utilitaire sert à trouver un ensemble de pages physiquement contigües libres, assez important pour charger une tâche.

La volonté de ne pas gérer une file d'attente des tâches en cours de chargement ou en attente de chargement, a entraîné un refus de chargement si la zone mémoire nécessaire n'est pas libre.

Néanmoins, pour ne pas imposer à l'utilisateur de réitérer sa demande de chargement à tout instant, l'utilitaire PCONT est totalement déconnecté du chargeur, et directement accessible à l'utilisateur, celui-ci charge l'utilitaire de lui trouver l'ensemble de pages nécessaire, et c'est l'utilitaire qui périodiquement va s'activer dans ce but. Ceci est particulièrement destiné à permettre un passage simple à une recherche directe dans les tables de SIRIS-7 et non plus dans le premier sous bloc.

## IV.7. La gestion de la multiprogrammation.

Le but du superviseur de multiprogrammation est d'assurer le pseudo-parallélisme asynchrone entre les tâches utilisateur et les modules de COSU.

Il s'agit en particulier de gérer les mises en attente sur évènement, (E/S pour les tâches utilisateur, suspension du dialogue avec l'utilisateur), de gérer l'allocation des deux unités centrales (la pseudo-UC EXECUTEUR, et la véritable UC) aux divers éléments, et de converser avec SIRIS-7, de sorte que les autres utilisateurs de SIRIS-7 ne soient pas gênés par l'activité de test.

C'est pourquoi ont été créées deux routines de mise en attente MWAIT et MCHECK (attente, attente avec analyse) qui servent aux éléments contrôlés à signaler leurs désirs au superviseur.
Un 'dispatchер' à deux niveaux pour allouer les deux UC.

Un utilitaire SPCWAIT, chargé d'analyser les événements pour au besoin
réveiller les éléments contrôlés et leur transmettre les éléments désirés ; et
chargé si tous les éléments contrôlés sont en attente de rendre la main à SIRIS-7,
pour que puissent travailler les autres utilisateurs, mais en lui transmettant
toutes les demandes, afin d'être réactivé dès l'arrivée d'un événement.

De plus, le superviseur est chargé de l'activation, de l'arrêt, de
l'orientation des modules. Cela se fait par des routines SVC, correspondant à
chacun des ordres TL2C ou TL2I.

IV.8. Le langage de commande (TL2C-TL2I).

Ce langage sert à activer, arrêter, orienter les divers modules contrô-
lés par le superviseur.

Après une phase de décodage, ces commandes sont traitées par des rou-
tines SVC, qui correspondent à la gestion mémoire, à la gestion des tâches uti-
lisateur, à la gestion du module de dialogue, à la gestion des fichiers, ou au
système d'aide à l'utilisateur.

Huit d'entre elles sont dans la version actuelle traitées par le module EDI

Celles relatives à la gestion des fichiers :

Supprimer un fichier.

ASM. assembler un fichier.

Ouvrir un fichier.

Celles relatives au système d'aide :

LFC listage du catalogue.

MESS envoi d'un message au pupitreur.

HELP } listage des commandes
HELPEX } admissibles.
REQUETE }
Les quinze autres sont gérées par le module SYS.

Celles relatives à la mémoire :

CPC chercher des pages contigües.

MPC modifier le nombre de pages contigües cherchées.

DPC arrêter la recherche de pages contigües.

TPC tester l'état de la recherche de pages contigües.

Celles relatives à la gestion des tâches utilisateur :

LØAD charger une tâche.

EX lancer son exécution.

WAIT arrêter momentanément une tâche.

PEX relancer l'exécution en séquence.

B dérouter une tâche.

STØP arrêter définitivement une tâche.

T s'informer de l'état d'une tâche.

RT s'informer du résultat du test.

Celles relatives à la gestion du module de dialogue :

SLEEP suspendre le dialogue.

BREAK ou ATT1 ou ATT2, reprendre le dialogue.

LØGØUT arrêter le dialogue.
V. Possibilités d'extension.

L'extension première, est d'offrir un contact plus intime entre COSU et le périphérique, en particulier pour le contrôle du temps et de l'unité de liaison.

Cette extension est réalisable en augmentant le nombre des paramètres transmis à SIRIS-7 avec le programme canal à exécuter. Elle permettrait alors les tests de simultanéité [A.14].

La seconde extension, est l'allocation-désallocation dynamique de périphériques sous SIRIS-7. Pour protéger le système contre les étreintes fatales, cette possibilité n'est offerte qu'au pupitreur (LOCK-UNLOCK) et dans le seul but de déconnecter les périphériques en panne. Il serait bon d'octroyer à COSU ce même droit.

La troisième extension est l'autorisation d'utiliser le pupitre comme organe conversationnel.

La quatrième extension souhaitée, est la possibilité de déclanchement de microtests [A.13].

Il serait bon également d'offrir plus de souplesse quant au mode d'entrée des programmes (en particulier entrée au lecteur de cartes) et au mode d'entrée des commandes (entrées au lecteur, au pupitre, par procédure cataloguée, par fichier...)

Il est évident qu'un élargissement de tous les langages est nécessaire.

Enfin, il est indispensable de réaliser le système de diagnostic automatique avec possibilité d'auto-apprentissage.
VI. Conclusions sur la technique des "Tests Sous Usagers" (Through-line).

VI.1. Le coût de COSU.

Les moyens mis en service à Grenoble pour le développement de COSU ont
été de

14 élèves-mois (2 élèves ENSIMAG × 7 mois)

20 heures UC-10070.

100 quanta espace disque permanent.

l'utilisation quasi permanente d'une MAE et du lecteur perforateur de
rubans.

Les frais annexes, bandes, documentation, papier, personnel d'exploita-
tion ont été évalués à 20 H UC, selon le mode de facturation en vigueur.

Les moyens mis en oeuvre à l'IRIA sont de :

3 élèves-mois (2 élèves ENSMP * 1,5 mois)

3,5 chercheurs-mois (1 chercheur * 3,5 mois)

10 heures UC-10070

100 quanta espace disque permanent

La répartition des charges entre les diverses phases du développement
s'effectue comme suit :

Etude : 6 hommes-mois 3 H.UC
(1/12/72, 28/2/73).

Réalisation : 7 hommes-mois 17 H.UC,

il est à noter que ces 17 H.UC correspondent à 10 heures sur
machine par jour durant 3,5 mois, mais grâce à l'absence de
portes ouvertes, la facture n'est que de 17 H.
(1/3/73, 15/6/73)

Mise au point : 4,5 hommes-mois, 10 H.UC,

ces 10 H correspondent à 5 heures par jour pendant 1,5 mois.
(15/5/74, 30/6/74)

Documentation : 3 hommes-mois.
(15/6/73, 30/6/73 - 1/7/74, 31/8/74).
## VI.2. Coûts comparés des systèmes de test.

Nous ne pouvons exposer ici toutes les bases d'évaluation du coût des systèmes de test exposées dans [G.18].

Néanmoins, quatre graphiques, approximations des courbes de [G.18] permettent d'en donner une idée.

Le premier évoque le coût de mise au point des programmes de test écrits en langage machine selon qu'ils sont exécutés seuls, multiprogrammés avec le système, multiprogrammés avec les tâches utilisateur.

Le second montre la position de COSU, muni de son langage de haut niveau.

Le troisième, est un assemblage des deux premiers, complété. On y trouve les six courbes relatives aux deux niveaux d'écriture pour les trois degrés de multiprogrammation.

Le quatrième graphique évoque le coût d'un diagnostic, selon le mode d'exploitation du programme de test, et selon la difficulté du diagnostic, évaluée en nombre d'éléments à tester (ce nombre est fonction du degré de finesse souhaité pour le diagnostic, et du nombre de pannes à détecter).

On note quatre points d'effondrement. Celui où le microdiagnostic devient nécessaire (trop de pannes pour qu'un élément du niveau considéré puisse être considéré comme sûr, ou volonté d'un diagnostic plus précis).

Celui où le STAND ALONE devient nécessaire (le temps perdu à cause de la multiprogrammation est trop important, en particulier, si l'on veut mitrailler le périphérique d'ordres contradictoires).

Celui où l'objet n'est plus testable par programme.

Celui où l'objet n'est plus testable par microprogramme.
<figure><img src="image_14.png" /><figcaption>Figure 7. : Coût de réalisation des programmes de test selon le système employé.</figcaption></figure>
<figure><img src="image_15.png" /><figcaption>Figure 8. : Position de COSU dans la figure précédente.</figcaption></figure>
<figure><img src="image_16.png" /><figcaption>Figure 9. : Les six ensembles de réactifs et
temps d'arrêt en amas.</figcaption></figure>
<figure><img src="image_17.png" /><figcaption>Figure 10. : Coûts comparés d'un test en fonction du degré de dégradation de la machine.</figcaption></figure>
<figure><img src="image_18.png" /></figure>
GRAPHE DES ETATS
DE LA
CONSOLE (FIGURE 11)

DEBUT DE
SESSION

LOGOUT

WAIT:STOP

T:RT

B:PEX

REQUETE:HELP:HELPEX

LFC:MESS

ASM:S

LOAD:EX

ETAT

INACTIF

SLEEP

BREAK

SLEEP

<figure><img src="image_19.png" /></figure>
ANNEXE B. Le langage TL2.

1. Commandes de soumission de tâches. TL2C (SYS).

CPC <Nombre> <--- Recherche de pages contigües.

TPC <Pxxx> <--- Test tâche pages-contigües.

MPC <Pxxx> / <Nombre> <--- Modification du nombre de pages contigües cherchées.

DPC <Pxxx> <--- Arrêt de la tâche PCONT.

LØAD <FICH> [,<Pxxx> [A KEEP]] <--- Chargement du fichier.

EX <Tccc> <--- Exécution d'une tâche.

2. Commande de transition sur EDI. TL2C (EDI).

S <FICH> [APASSE] <--- Suppression du fichier.

Ø <FICH> A NOV [APASSE] <--- Création d'un nouveau fichier.

Ø <FICH> A ANC [APASSE] <--- Ouverture d'un ancien fichier.

ASM <FICH> <--- Assemblage du fichier.

SLEEP <--- Mise en sommeil de la session en cours.

BREAK <--- Reprise de la main après SLEEP, ou interruption du listage des noms de fichiers (cmd LFC).

LØGOUT <--- Suspension de la session en cours.

3. Commandes d'aide à l'utilisateur. TL2C (EDI HELP).

LFC <--- Rappel des noms des fichiers créés.

MESS, <Message> <--- Envoi de messages à l'opérateur.

HELP <--- Rappel des commandes permises.

HELPEX <--- Rappel des commandes de soumission de tâches.

REQUETE <--- Rappel des commandes de conversation avec les tâches.

"~" : Caractère ET (AND) pour l'intersection logique.

"V" : Caractère (ØU) pour l'union logique (ØR).

<Pxxx> = Nom de la tâche d'allocation de pages contigües.

<Tccc> = Nom de la tâche.

A peut être soit une virgule, soit un caractère blanc.

Toutes les commandes peuvent être suivies de commentaires qui ne seront pas pris en compte par le système.
## 4. Commandes de conversation. TL2I.

WAIT <Tccc> <--- Arrêt provisoire de l'exécution d'une tâche.

PEX <Tccc> <--- Reprise de l'exécution d'une tâche.

STØP <Tccc> <--- Arrêt définitif de l'exécution d'une tâche.

B <Tccc> Λ <ETIQ> <--- Reprise de l'exécution d'une tâche à partir d'un point de reprise.

RT <Tccc> [TTE] <--- Retour des bits d'état de TIØ, AIØ, et TDV.

T <Tccc> <--- Test de l'état d'une tâche.

## 5. Commandes de création de fichiers. TL2E (creat).

E D <--- Entrée du programme.

! GENPC <--- Mise en service de la procédure GENPC.

! NOGENPC <--- Mise hors service de la procédure GENPC.

RC <--- (Retour Chariot) Fin d'entrée du programme.

L <--- Listage du fichier.

EDIT <--- Passage en mode EDIT (Edition).

C <--- Fermeture du fichier courant et retour en mode INIT.

## 6. Les commandes de modification de fichiers. TL2E (edit).

L <--- Listage complet du fichier.

L <Numéro de ligne> <--- Listage de la ligne portant ce numéro.

D <Numéro de ligne> <--- Suppression de la ligne portant ce numéro.

I <Numéro de ligne>/<Nouvelle ligne à insérer> <--- Insertion d'une nouvelle ligne.

R <Numéro de ligne>/<chaine 1>/<chaine 2>/<--- Substitution de la première occurence de "Chaine 1" par "Chaine 2".

RC <--- Retour au mode CREATION.
Caractères de service :

SHIFT \ <-- Annule le dernier caractère émis.

CTRL C <-- Pour interrompre la sortie d'une ligne sur l'imprimante de la console.

CTRL X <-- Annule la ligne en entrée.

## 7. Le langage d'écriture des programmes canaux. TL2A.

ETIQ:<Etagette><--- déclaration d'une étiquette, point de reprise en exécution conversationnelle.

D¢A <Nombre><--- Instruction de boucle.

FD¢ <-- Fin de boucle D¢.

B <Etagette> <-- Instruction de branchement à une étiquette.

C¢MPARE <Nombre>/<AD.mem1>/<AD.mem2>, <Instruction conditionnée>.

<--- Instruction de comparaison.

TRANSF <Nombre>, <AD.mem1>/<AD.mem2> <-- Instruction de transfert

$$ \text{SI} \begin{cases} \text{TDV} \\ \text{TI}\phi \\ \text{AI}\phi \end{cases} = \langle \text{Code Hexa} \rangle [\{\&\} [ \begin{cases} \text{TDV} \\ \text{TI}\phi \\ \text{AI}\phi \end{cases} = \langle \text{Code Hexa} \rangle ] [\{\&\} \begin{cases} \text{TDV} \\ \text{TI}\phi \\ \text{AI}\phi \end{cases} = \langle \text{Code Hexa} \rangle ] , $$

<Instruction conditionnée>

<--- Instruction conditionnelle basée sur les bits d'état des E/S.

SI¢:<Etagette> A <Type de périph, Etiq. logique> A <¢ordre> [A <Compte d'octets>] [A<adresse>] A <Indicateur>

<--- Instruction de début d'un programme canal.

Les instructions suivantes d'un programme canal sont identiques mais sans "SI¢:".

FINPC <-- Fin de programme canal.

RES { 0 \ 2 \ 4 \ 8 } [A<Etagette]/<Nombre> A {C} "Chaine de caractères ou de codes"

<--- Réservation de mémoire

Idem pour "RESC" mais la réservation se fait dans des pages contigües.
PATTERN { 0 2 4 8 } [A<Etiquette>], XX,YY,CCCC*CCC

<--- Génération de buffers.

Idem pour "PATTERNC" mais le buffer est pris sur des pages contigues.

WCNS <--- Instruction d'arrêt momentané de l'exécution d'une tâche.

STOP <--- Instruction d'arrêt définitif de l'exécution d'une tâche.

FIN [A<Etiquette>] <--- Instruction de fin physique du programme.
A. SYSTEMES DE TEST.

[1] R. SUDA. "An application-oriented multiprocessing system. PART V. The Diagnostic Monitor". IBM Systems Journal. Vol. 6. N° 2.pp. 116-123. (1967).

[2] G.W. NELSON. "OPTS-600 — On-line Peripheral Test System", AFIPS. FJCC.33. pp. 45-50. (1968).

[3] M.S. HOROVITZ. "Automatic Check-out of small computers". AFIPS. SJCC. 34. pp. 359-365. (1969).

[4] N. BARTOW, R. MCGUIRE. "System/360 model 85 microdiagnostics". AFIPS.SJCC.36. pp. 191-197.a. (1970).

[5] A.M. JOHNSON. "The microdiagnostics for the IBM System/360 model 30". IEEE-C-20. N° 7. pp. 798-803. (July 1971).

[6] J.W. IRWIN, J.V. CASSIE, H.C. OPPEBOEN. "The IBM 3803/3420 Magnetic Tape subsystem". IBM J. of R. and D. Vol. 15. pp. 391-400. (September 1971).

[7] P.J. SCOLA. "On-line computer-Testing system". Second workshop on "Fault-detection and diagnosis in Digital Systems". LEHIGH University. pp. 103-114. (December 1971).

[8] G.R. AHEARN, Y. DISHON, R.N. SNIVELY. "Design innovations of the IBM 3830 and 2835 Storage Control Units". IBM. J. of R. and D. pp. 11-18. (January 1972)

[9] IBM Systems. "OS/VS OLTEP : On-line Test Executive Program". GC 28-0636-1. (1972).

[10] M.A. CALHOUN. "SYMBOL hardware debugging facilities". AFIPS.SJCC. 40. pp. 359-368. (1972).
[11] G. EDGE. "System 250-Diagnostics", pp. 201-212. in Conference on Computers : Systems and Technology. LONDON. IERE Conference Proceedings, n° 25. Middlesex Hospital Medical School. (October 1972).

[12] H.Y. CHANG, R.C. DORR, D.J. SENESE, T.L. SMITH. "Maintenance Techniques of a microprogrammed self-checking Control Complex for an electronic Switching System". IEEE-C-22. N° 5. pp. 501-512. (May 1973).

[13] J.P. RIGAULT. "Utilisation des registres à décalage pour le test et diagnostic des systèmes digitaux. Séminaire, Grenoble, ENSIMAG. (Juin 1974). Et communications personnelles.

[14] M. MQALLA. "Organisation des tests sous système QLT sur les machines IBM/360, Modèles 65 et 67 et IBM/370, Modèles 135/145-155 et 165, IRIA. CETASI. IE/408. (Juillet 1974). Et communications personnelles.

[15] D.R. FREESE. "Streamlining insertion of components in printed-circuit boards". ELECTRONICS. Vol. 47. N° 18. pp. 117-122. (September 5, 1974).
B. VISIBILITE.

[1] D.M. BRADLEY. "The Systems Approach to Test Evaluation". IEEE-SSC-5. N° 3. pp. 223-230. (July 1969).

[2] J.E. STUEHLER. "An integrated Manufacturing Process Control System : Implementation in IBM Manufacturing". IBM J. of R. and D. Vol. 14. N° 4. pp. 605-613. (November 1970).

[3] D.L. DROULETTE. "Recovery through programming System/360-System/370". AFIPS. SJCC. 38. pp. 467-476. (1971).

[4] A.N. HIGGINS. "Error recovery through programming". AFIPS. FJCC. 33. pp. 39-43. (1968).

[5] A.S. KAMP, J.J. LYDON. "System for Utilization of Remote Equipment for Failure Investigation and Reliability Evaluation (SUREFIRE)". Annals of Reliability and Maintainability. pp. 279-289. (1970).

[6] F. BANCILHON et al. "Principes de Conception Automatique dans le Système SPECTRE". RAIRO. 7ème Année. B-3. pp. 31-62. (Octobre 1973).

[7] D.A. ENTREKIN. "Factory Automation and Data Collection". AFIPS. NCC. 42. pp. M.83-M.87. (1973).

[8] J.S. LAMB. "Computer-Aided Manufacturing : Today and Tomorrow". AFIPS. NCC. 42. pp. M.88-M.91. (1973).

[9] L.R. KNEPPELT. "A simple distributed systems approach to Manufacturing information systems". AFIPS. NCC. 43. pp. 485-490. (1974).

[10] S.J. OH, J.L. HAMMOND. "Computer Control in manufacturing — An annotated survey of the state of the art—". Joint Automatic Computer Conference. pp. 44-46. (1972).
[1] R.E. BARLOW, F. PROSCHAN, L.C. HUNTER. "Mathematical Theory of Reliability".
The SIAM Series in Applied Mathematics. WILEY. (1965).

[2] W.H. PIERCE. "Failure-Tolerant Computer Design". ACADEMIC PRESS. (1965).

[3] C.V. RAMAMOORTHY. "A structural Theory of machine diagnosis". AFIPS.SJCC. 31.
pp. 743-756. (1967).

[4] J.M. SMITH. "A review and comparison of certain methods of computer perfor-
mance evaluation". The Computer Bulletin. pp. 13-18. (May 1968).

[5] J.J. DENT. "Diagnostic Engineering Requirements". AFIPS. SJCC. 32.
pp. 503-507. (1968).

[6] M.E. DRUMMOND. "A perspective on system performance evaluation". IBM System Journal. Vol. 8. N° 4. pp. 252-263. (1969).

[7] H.Y. CHANG, E.G. MANNING, G. METZE. "Fault Diagnosis of Digital Systems".
N.Y. WILEY. (1970).

[8] A.D. FRIEDMAN, P.R. MENON. "Fault-Detection in Digital Circuits". PRENTICE
HALL / Electrical Engineering Series. (1971).

[9] H.T. McALEER. "A look at automatic testing". IEEE. SPECTRUM. pp. 63-78.
(May 1971).

[10] R.G. BENNETTS, D.W. LEWIN. "Fault Diagnosis of Digital systems - a review".
The British Computer Journal. Vol. 14. N° 2. pp. 199-206. (May 1971).

[11] F. VAN VEEN. "An introduction to IC Testing". IEEE.SPECTRUM.
pp. 28-37. (December 1971).
[12] R.J. PREISS. "Fault Test Generation". Chap. 7 in "Design Automation of digital systems". Vol. I. Edited by M.A. BREUER. PRENTICE HALL. (1972).

[13] W.C. CARTER, W.G. BOURICIUS. "A survey of fault-tolerant Computer Architecture and its evaluation". IEEE.COMPUTER. pp. 9-16 (January-February 1972).

[14] J.J. HORNING, B. RANDELL. "Process Structuring". ACM Computing Surveys. Vol. 5. N° 1. pp. 5-30. (March 1973).

[15] M. DEPEYROT. "Sur la synchronisation et la fiabilité des automates". RAIRO. 5e Année, B-2. pp. 87-110. (Décembre 1971).
[1] E.F. MOORE. "Gedanken-Experiments on Sequential Machines". pp. 129-156. in "Automata Studies". Ed. by C.E. SHANNON, J. Mc CARTHY. Annals of Mathematics Studies. N° 34. PRINCETON UNIVERSITY PRESS. (1956).

[2] C.V. RAVI. "Fault-location in memory systems by program". AFIPS. SJCC. 34. pp. 393-401. (1969).

[3] M. COHN, G. OTT. "Design of Adaptive Procedures for Fault-Detection and Isolation". IEEE-R-20. N° 1. pp. 7-10 (February 1971).

[4] B.E. COWART, R. RICE, S.F. LUNDSTROM. "The physical attributes and Testing Aspects of the SYMBOL system". AFIPS. SJCC. 38. pp. 589-600. (1971).

[5] C.W. HEMMING, S.A. SZYGENDA. "Modular requirements for digital logic Simulation at a predefined functional level". Proceedings of the National ACM Conference. pp. 380-389. (August 1972).

[6] M.A. BREUER. "Testing for intermittent faults in Digital Circuits". IEEE-C-22. N° 3. pp. 241-246. (March 1973).

[7] S.A. SZYGENDA, M.J. FLYNN. "Self-diagnosis and self-repair in memory : an Integrated System approach". IEEE-R-22. N° 1. pp. 2-12. (April 1973).

[8] J.D. RUSSELL, C.R. KIME. "On the diagnosability of digital Systems". in Proceedings of the "Fault-Tolerant Computing Conference". pp. 139-144. (June 1973).

[9] M. DEPEYROT. "Design of interfaces as stochastic channels with memory". GRENOBLE International Workshop on Computer Architecture. (June 1973).

[10] C. KUBIAK, J. LE SAINT-MILON, M. PIGNAL. "Méthode de simulation de transition dans les réseaux logiques". AUTOMATISME. Tome XVIII. N° 11. pp. 399-409. (Novembre 1973).

[11] A. TOTH, C. HOLT. "Automated Data-Base driven Digital Testing". IEEE. COMPUTER. pp. 13-19. (January 1974).
[12] U.W. POOCH. "Translation of Decision Tables". ACM Computing Surveys.
Vol. 6. N° 2. pp. 125-151. (June 1974).

[13] F. BANCILHON, M. DEPEYROT. "Identification des automates non-fiables".
RAIRO.8e Année, B-2. pp. 127-153 (Juin 1974).
[1] MIL-STD-105D. "Military Standard : Sampling procedures and tables for inspection by attributes". Department of Defense - USA. (July 29, 1963).

[2] W.B. JOYCE. "Organizations of Unsuccessful R. and D. Projects IEEE-EM-18. N° 2. pp. 57-65. (May 1971).

[3] L.A. BELADY, M.M. LEHMAN. "An introduction to Growth Dynamics". Brown University Conference on Statistical Methods for the evaluation of Computer System Performance. (1971).

[4] L.A. BELADY, M.M. LEHMAN. "Programming System Dynamics or the metadynamics of Systems in Maintenance and Growth". IBM. Research Report. RC.3546. (September 17, 1971).

[5] R.E. MERWIN. "Estimating Software Development Schedules and Costs". IXth DESIGN AUTOMATION WORKSHOP. IEEE pp. 1-4. (July 1972).

[6] B.P. DZIELINSKI. "A guide to financial planning tools and Techniques. IBM Systems Journal. Vol. 12, N° 2. pp. 126-144. (1973).

[7] M. AISO. "Forecasting Techniques". IBM Systems Journal. Vol. 12. N° 2. pp. 187-209. (1973).

[8] A. JORRY. "Introduction to ORDON". Proceedings of the 4th International Workshop on Real-time Programming. IFAC-IFIP. BUDAPEST. (May 1974).

[9] A.R. PIERCE. "Bibliography on algorithms for shortest path, shortest spanning tree and related circuit routing problems, (1957-1973)". ACM-SIGDA-Newsletter. Vol. 4. N° 2. pp. 29-37. (June 1974).

[10] Significant Developments in Technology and Business : "Test and Measurement service concept developing". ELECTRONICS. Vol. 47. N° 14. pp. 3E-4E. (July 11, 1974).

[11] B. CHEW. "Scheduling an IC tester for maximum throughput". ELECTRONICS. Vol. 47. N° 17. pp. 96-99. (August 22, 1974).
[12] S.E. GROSSMAN. "Automated testing pays-off for electronic system makers". ELECTRONICS. Vol. 47. N° 19. pp. 95-109. (September 19, 1974).

[13] M. DEPEYROT. "Approche barycentrique par transformation de Fourier d'une classe de problèmes de placement et de transport". Com. Acad. des Sc. - à paraître. (Octobre 1974).

[14] V.K. HANDA, S.K. GHOSH. "Forecasting and controlling progress payments" in "Project Management in the Seventies". Fourth INTERNET Congress. PARIS. (October 1974).
F. BIBLIOGRAPHIE SUR SIRIS-7.

[1] C. BOULLE. "Certains aspects de réalisation de SIRIS-8" in Congrès AFCET d'Informatique. PARIS. pp.1.1.59 à 73. (September 1970).

[2] B. CHUET, S. SELETZKY. "Système de fichiers à structure hiérarchisée pour les ordinateurs IRIS dans un contexte "on-line" et multi-utilisateur" in Congrès AFCET d'Informatique. PARIS. pp.3.2.151 à 159. (September 1970).

Référence CII :

[3] Procédures système sous S7/S8. 3642

[4] Moniteur S8 temps partagé. 4015

[5] Métasymbol sous S7/S8. 3753

[6] Moniteur de multiprogrammation S7 : Manuel Opérateur 3586

[7] Langage de commande sous S7/S8. 3619

[8] Editeur de liens sous S7/S8. 3629

[9] Processeurs associés au SGF sous S7/S8. 3759

[10] SGF sous S7/S8. 3704

[11] Normes de programmation S7. 3851

[12] Ordinateur 10070 : Manuel de présentation C 900950 H

[13] Système de gestion des transmissions (SGT) sous S7/S8. 3850

[14] Ordinateur IRIS 80 : Manuel d'utilisation. 4152

[15] Moniteur de multiprogrammation S8 : Manuel Opérateur. 3843
[1] A. JORRY, M. MOALLA. "Programme conversationnel de test hardware . Rapport de Projet" ENSIMAG. Non répertorié. (Juin 1973).

[2] A. JORRY, M. MOALLA. "Programme conversationnel de test hardware . Extrait du Rapport de Projet" ENSIMAG. Non répertorié. (Juin 1973).

[3] A. JORRY, M. MOALLA. "Programme conversationnel de test hardware . Extrait du Rapport de Projet, Seconde version" IRIA. CETASI. IP/217. (Juillet 1974).

[4] A. JORRY. "COSU : Programme conversationnel de test sous utilisateur . Manuel Opérateur" IRIA. CETASI. IP/220. (Juillet 1974).

[5] A. JORRY. "COSU : Programme conversationnel de test sous utilisateur . Présentation technique des modules existants" IRIA. Non répertorié. (Septembre 1973).

[6] A. JORRY. "COSU : Programme conversationnel de test sous utilisateur . Travaux à faire" IRIA. Non répertorié. (Septembre 1973).

[7] A. JORRY. "COSU : Programme conversationnel de test sous utilisateur . Travaux proposés aux stagiaires" IRIA. Non répertorié. (Septembre 1973).

[8] A. JORRY. "COSU : Programme conversationnel de test sous utilisateur . Spécifications fonctionnelles" IRIA. CETASI. IP/219. (Juillet 1974).

[9] A. JORRY. "COSU : Programme conversationnel de test sous utilisateur . Spécifications de réalisation" IRIA. CETASI. IP/221. (Juillet 1974).

[10] M. DEPEYROT, A. JORRY. "COSU : Programme conversationnel de test sous utilisateur . Présentation" IRIA. CETASI. IE/50. (Juillet 1974).
[11] A. JORRY. "COSU : Programme conversationnel de test sous utilisateur .
Manuel de Mise en Oeuvre." IRIA. CETASI. IP/222. (Juillet 1974).

[12] P. DECITRE, M. DEPEYROT, M. MOALLA, A. JORRY. "COSU : Un système conversationnel de test sous usager". IRIA. CETASI. IA/117. (Octobre 1974).

[13] M. DEPEYROT. "COSU : Programme conversationnel de test sous utilisateur .
Spécifications de Produit." CII. CII/DOI/FQ/TP-MD/SPP/26. (Juillet 1974).

[14] A. JORRY. "COSU : Programme conversationnel de test sous utilisateur .
Descriptif Post Mortem." IRIA. CETASI. IP/218. (Juillet 1974).

[15] A. JORRY, J. THIBAULT, G. VIGREUX. "COSU : Programme conversationnel de test sous utilisateur . Listings commentés." ENSIMAG-IRIA. Non répertorié. (Juin 1973, Juillet 1974).

[16] A. JORRY, M. MOALLA, J. THIBAULT, G. VIGREUX. " COSU : Programme conversationnel de test sous utilisateur . Rapport de Projet, seconde version."
IRIA. CETASI. IE/51. (Juillet 1974).

[17] J. THIBAULT, G. VIGREUX. "COSU : Programme conversationnel de test sous
utilisateur . Mise au point de COSU." IRIA. CETASI. IE/49. (Juillet 1974).

[18] M. DEPEYROT. "Computer Component and system testing as a part of computer-aided production and maintenance. IRIA. Rapport de Recherche LABORIA n° 83. (Octobre 1974).

[19] P. DECITRE, M. DEPEYROT, A. JORRY, M. MOALLA. "The COSU Through-line Test-Process-Interpreter". IRIA. CETASI. IA/119. (November 1974).

<footnote>Les paragraphes A à E de cette bibliographie sont extraits du Rapport de
Recherche [G.18] qui en explique la classification et le vocabulaire de base.
L'auteur tient à remercier Monsieur M. DEPEYROT d'autoriser sa reproduction.</footnote>