DPS-7 Unit Record Processor

Une partie importante de l'architecture du Level 64/DPS-7 est dissimulée dans un mini-ordinateur auxiliaire officiellement connu sous le nom de processeur de périphériques Unit record. On emploiera ici le nom engineering, moins promotionnel, mais bien plus utilisé d'URC (Unit Record Processor).

Lorsque des systèmes possédant plus d'une URC ont été commercialisés, l'URC principale -celle connectée au canal de maintenance du processeur a reçu le nom de SURP System Unit Record Processor. Les différences opérationnelles entre le SURP et les URC ordinaires sont décrites dans les paragraphes initialisation et maintenance ci-dessous.

Origine de l'URC

A une revue du programme Charlie à la fin de 1967, John Haanstra suggéra l'adoption d'un mini-ordinateur pour effectuer le contrôle des entrées sorties. A cette époque, ni BGE, ni General Electric ne disposaient de matériel semblable - le Datanet-30 était construit en une technologie obsolète et son successeur le Datanet 355 était plus puissant, mais trop cher pour être utilisé à plusieurs exemplaires sur un système moyen. L'équipe de Georges Lepicard avait déjà commencé à faire les spécifications d'un contrôleur de lignes de télécommunications micro-programmable qui évolua au cours de l'année 1968 en ce qui devint plus tard connu sous le nom de URC (Unit Record Controller).
La raison pour laquelle ce mini-ordinateur s'appelle Unit Record, est que Bull-General Electric avait obtenu la "mission" des appareils Unit Records (appareils à cartes et imprimantes) pour le groupe, les appareils étant confiés à Belfort, les sous-systèmes NPL devant être conçus à Paris dans la Medium Systems Division. Cet URC ,essentiellement optimisé pour le système moyen -futur Level 64- devait servir aussi de sous-système unit record pour le haut de gamme et l'établissement parisien ne faisait pas trop mystère de son souhait de voir utiliser cette plate-forme comme un processeur de bas de gamme, réglant ainsi un vieux compte avec leurs amis transalpins. Le système en cours de conception n'était pas -en principe un système transactionnel- mais il semblait désirable de le doter d'une configuration minimale de ligne de communications (support de Teletypes et de ligne haute vitesse 4800 bps pour le remote batch). Un système doté d'un processeur 16-bits   fonctionnant à une fréquence de 6 MHz -celle du CPU- devait être capable de multiplexer un ensemble d'appareils à cartes, une imprimante et 16 lignes à 110 bps en plus d'une ou deux lignes remote batch, moyennant la dotation de mémoires tampon adaptées.
L'idée d'un processeur de maintenance faisant les diagnostics off-line de la logique du processeur principal et capable de suppléer aux procédures manuelles d'initialisation du système se fit jour en 1969-1970 et comme ce processeur était susceptible d'utiliser off-line les périphériques unit record, il apparut judicieux de combiner ces fonctions avec celles de l'URC. Le seul appareil manquant était une mémoire de masse permanente pour laquelle l'utilisation des cassettes de ruban magnétique était -en 1970- une solution acceptable, qui devint encore plus attrayante lorsque les augures annoncèrent que ce media pouvait remplacer avantageusement la carte perforée comme véhicule de saisie de données.

Projet URC

La conception et la réalisation de l'URC a été réalisée dans la division Périphériques de la direction hardware des Systèmes Moyens de Honeywell-Bull sous l'autorité de Henri Verdier.

La technologie était identique à celle du processeur principal Level 64 (mémoire MOS 4Kbits, technologie TTL 74N, packaging SP-10.

Les outils logiciels étaient développés dans la division Software de la Direction hardware, initialement dirigée ar Michel Rocher, puis par Jean-Jacques Pairault.

Les "device adapters" de périphériques étaient conçus par l'équipe de Henri Verdier et réalisés par les constructeurs des périphériques -ils se trouvaient dans l'armoire du périphérique et packagés avec l'électronique analogique spécifique de celui-ci, à l'exception des adaptateurs de communication (MLA) , intégrés dans un tiroir voisin de l'URC, réalisés par l'équipe de Jean Akriche chez Henri Verdier.

Architecture de l'URC

Bien que l'URC ait été conçu comme un mini-ordinateur à usage général, on n'avait jamais envisagé que sa base architecturale soit directement programmable par l'utilisateur final. Lorsqu'on a envisagé son utilisation comme processeur de bas de gamme, l'"interior decor" considéré devait être un code d'instructions compatible avec celui du 64 (aligné octet, instructions de longueur variable...) interprété par du "firmware" et non le décor natif offert par le matériel (machine mot de 16-bits, adressage limité à 64KB, 2  registres de base - un pour le code, l'autre pour les données-). On a donc appelé "firmware de l'URC" le logiciel en mode natif, dont une partie, celle du "bootstrap", et les pilotes des périphériques de base  était réalisé en PROM.

L'URC comprenait un processeur, une mémoire DRAM et des adaptateurs (1 ou 2 adaptateurs de canal PSI -liaison avec le processeur central, adaptateurs de canaux DAI -liaison avec l'électronique des périphériques).
Les canaux DAI étaient un standard Honeywell et identiques pour tous les périphériques (parallèle sur 8-bits).
Le canal PSI de liaison avec le central était voisin de celui du Level-66 (deux versions avaient été prévues, l'une sur 8-bits, l'autre sur 16-bits. Seule la première sera réalisée par Honeywell-Bull, NEC ayant réalisé d'abord une version 16-bits, avant de développer une version PSI-streaming adopté aussi par Bull.

Les "device adapters" de communication étaient de types différents: un adaptateur de lignes asynchrones regroupant 8 lignes à basse vitesse avec un double tampon d'un caractère par ligne, un adaptateur de ligne asynchrone à "grande vitesse" , un adaptateur de lignes synchrones BSC puis plus tard un adaptateur de ligne synchrone HDLC. Ces adaptateurs étaient échantillonnés par le programme de gestion de lignes aussi appelé "MLA firmware".

Micro-Logiciel

Inspiré de la conception du processeur du Level 64, un "microprogrammed-OS" (MIOS) servait de système d'exploitation de l'URC. Il s'agissait d'un micro-noyau qui, non seulement gérait les interruptions, mais aussi assurait le dispatching des tâches de leur synchronisation au sein de l'URC. Ce MIOS faisait partie de la partie réalisée en PROM et était par conséquent chargé au début de l'initialisation de l'URC.

Les micro-tâches étaient les suivantes:
le pilote du lecteur de cartes (code en ROM)
le pilote du perforateur de cartes
le pilote de bande perforée
le pilote d'imprimante (PR71 et PR54)
le pilote du canal PSI de liaison avec le processeur central (code en ROM)
le pilote de cassettes de bandes magnétiques  (code en ROM)
le pilote de la console (modèle pour le haut de gamme développé à Billerica)
le pilote de lignes asynchrone TTY (console bas de gamme GE Terminet 300 compatible TTY35)
le pilote de la trieuse de chèques
le programme de gestion des lignes de communication (MLA firmware)
l'interpréteur du programme de maintenance
l'attachement de diskettes (seulement introduit sur l'URC-E sur 64-DPS)
l'attachement d'adapteur canal à canal

La structure de ces micro-tâches était rigoureuse, la partie procédure était réentrante de façon à pouvoir supporter le multi-tasking (ex: support de plusieurs imprimantes) et se dérouler simultanément sous contrôle du MIOS multiplexant le matériel entre ces micro-tâches (appelées micro-process). C'est ainsi que le fonctionnement des lignes de communication pouvait être complètement indépendant et ces lignes allouées à des "logiciels" différents dans le central ou l'URC.

A propos des pilotes, il faut noter que la lourdeur de la distribution des "releases" du micro-logiciel (Basic System Release BSR) conduisit le Département de Conception de Périphériques Unit Record de Belfort à réaliser des matériels rigoureusement compatibles avec des matériels antérieurs, même si le coût et la fonction de ces appareils en différaient sensiblement (ex: lecteur de cartes CR300 et lecteur de cartes Honeywell CR 1000).

Pour la liaison avec le processeur central, l'URC disposait du canal PSI et d'un canal spécial de maintenance. Ce dernier servait à lancer la réinitialisation du central, à accéder au contrôleur de mémoire centrale et à extraire le contenu des registres de l'unité centrale. Le pilote de canal PSI avait comme fonction d'assurer la communication entre le logiciel du central (via le contrôleur d'entrées-sorties du central et son firmware associé) avec les pilotes de contrôle de périphériques. Il maintenait un ensemble de "subchannels" entités logiques définissant des chemins de données (macroscopiquement asynchrones) entre les "processes" du central et des fonctions logiques sur les périphériques.
Cet asynchronisme avait des limites dues aux fonctions "temps réel" du sous-système d'entrées sorties. Ces fonctions pouvaient être réalisées, comme sur le IBM S/360, en synchronisant les "programmes canaux" du central avec les "interruptions" des entrées-sorties. Pour les opérations plus contraignantes, l'URC permettait au programmeur du central de prédéfinir des actions se déroulant dans l'URC  (actions sur caractères spéciaux de communications, actions sur les trieuses de chèques). Ces actions étaient soit définies par des déclarations transmises au programme de gestion de lignes de communication, soit par la génération d'un programme compilé pour la lecture et le tri de chèques.

Attachement de Peripheriques

La spécification de l'URC, faite à un moment où la logique des devices adapters était coûteuse, n'avait pas prévu que ces devices adapters enregistraient le type d'appareil qu'ils reliaient à l'URC. Ainsi, il n'y avait pas de possibilité de reconnaissance automatique des appareils au moment de l'initialisation (Fonction Plug and Play).

Les "Device Adapters" spécifiques de chaque appareil étaient connectés à l'URC par une interface standard DAI (également utilisée sur Level 62 et Level 66). Cette interface parallèle sur un octet était directement contrôlée par les micro-programmes de l'URC.

lecteur de cartes

lecteur-perforateur de cartes

imprimante

La définition de l'attachement imprimante posa des problèmes particuliers dus à l'existence d'une phase off-line sur la PR71 qui était l'avance du papier. Cette avance était lancée par le micro-programme à la fin du transfert de données dans le tampon ligne de l'imprimante, mais la fin du saut de papier n'était détecté que lorsque le microprogramme se préoccupait de l'envoi de la ligne suivante. Un incident mécanique d'avance papier était donc détecté après que le logiciel du central ait reçu le signal de transfert de données. Dans le cas où le logiciel n'avait pas prévu de point de reprise au niveau de la page, ce problème risquait de provoquer un message d'erreur sur l'état d'impression "LINE MAY BE LOST"

trieuse de cheques

La connexion du lecteur-trieuse de chèques (modèle MICR ou OCR) posait des problèmes que la plupart des autres appareils unit-record. Les critères de sélection (champ des données, codage, type...) de la case de réception normale des chèques étaient sous-la dépendance du programmeur d'application. De plus, la trieuse de chèques rencontrait des cas d'impossibilité de lecture devait provoquer la sélection en case rebut sans ralentir le rythme de la machine. La lecture des chèques ne devait s'arrêter que dans le cas de case d'alimentation vide, de case sortie pleine ou de bourrage.

bande perforée

Multi-Line adapter (MLA)

Le MLA est composé de deux composants: un composant matériel l'UCLA (Universal Communication Lines Adapter) panier (card cage) recevant une carte de liaison avec l'URC (Common Board) via l'interface DAI et jusqu'à 15 adapteurs de ligne, et un composant micrologiciel l'"attachement MLA". Plusieurs modèles d'adapteurs de ligne ont été offerts (l'adapteur de ligne asynchrone possédant une horloge bit programmable, l'adapteur de lignes synchrones et l'adapteur HDLC , ces derniers étant synchronisés par le modem). L'interface entre adapteur et UCLA est parallèle sur un caractère, l'interface entre adapteur et modem est du type série. Les adapteurs pouvaient indifféremment être utilisés via modem ou en connexion locale à courte disatnce.

L'attachement MLA reconnaît chaque caractères de contrôle, vériifie leur parité -s'il ya lieu-, interprète les caractères de contrôle de bloc et vérifie les contrôles d'intégrité (CRC) selon les protocoles de transmission, effectue -éventuellement- une traduction (ex: ASCII<>EBCDIC), et regroupe le contenu pour une transmission par blocs à l'unité centrale. En outre, l'attachement MLA interprète les caractère de Break qui interrompent la transmission et informe le central par une "attention" spécifique, pouvant interrompre le déroulement du programme canal. A chaque ligne est associée 1 ou 2 logical channels (selon half-duplex ou full-duplex).
Les options du MLA sont le mode TTY (avec support de bande perforée) , le mode Honeywell VIP (avec option de multi-point), le mode IBM BSC utilisé essentiellement en "remote batch", le mode HDLC X25 (compatible IBM SDLC). Un mode Télex 5 moments, code Baudot a été offert mais n'a guère eu d'applications. Essentiellemnt pour les pays nordiques un support de l'interface de commutation automatiques de circuits X21 a également été offert sur URC.

Presque tous les systèmes avec URC ont eu la console système connectée via le MLA. Seuls font exception des systèmes de haut de gamme ayant reçu un adpateur spécial pour une console conçu à Boston à base de CRT. La console la plus répandue avant 1981 fut le General Electric Terminet 300 (compatible TTY). Il a été ensuite remplacé par un écran du type VIP, utilisé par GCOS d'abord en mode TTY, puis en mode plein écran.

Attachement de Canaux

Canal PSI

L'interface avec le canal PSI était une interface parallèle sur un octet. L'URC pouvait recevoir un second canal PSI permettant de la partager entre deux unités centrales. Les sous-canaux correspondant aux périphériques étaient partagés statiquement (à la génération du firmware) entre les deux appareils ce qui limitait l'intérêt de la double connexion. Elle ne fut guère utilisée que pour connecter  l'ensemble des péripgériques à l'une ou l'autre unité centrale, jouant un rôle identique à celui d'un switch de canaux PSI utilisé sur les autres sous-systèmes périphérques.

Canal de maintenance

Le CPU du central (et les autres contrôleurs de périphériques) était connecté via une interface série MCSI.

Initialisation

La mise au point initiale du système Level 64 commença à Paris Gambetta en avril 1972. Les controleurs de bandes magnétiques et de disques étaient développés à Billerica et n'étaient pas encore disponibles. Aussi, le système central et sa mémoire devaient être initialisés à partir d'un deck de cartes perforées lues dans l'URC. Cette fonction de durée assez longue (de l'ordre de 15 minutes) fut utilisée seulement avant la connexion du MSC et du MTC. En fait, le lecteur de cassette et son "device adapter" (produit par Honeywell Italia) n'étaient pas non plus disponible, ce qui fait que le paquet de cartes -en mode binaire- émulait la future cassette du point de vue fonctionnalité d'utilisation. la cassette inversement émulera le lecteur de cartes en adoptant des blocs de 120 octets (960 bits) .
A noter que le système prototype du Level 64 possédait une mémoire à tores magnétiques comme aussi le prototype de l'URC, bien qu'il soit prévu d'utiliser des mémoires DRAM dès le début (seul le premier prototype était équipé de mémoire à tores).

On décrira ici, l'initialisation des prototypes complets à partir de la cassette.
A la mise sous tension du matériel, l' URC initialisait sa mémoire et effectuait des auto-tests (les POST d'aujourd'hui) de son processeur et de sa mémoire depuis ses "microprogrammes" en PROM. Le MIOS commençait le chargement et l'initialisation des micro-processes dont le code était résident en ROM et la mémoire de travail (dans la mémoire vive de l'URC) auto-initialisée. Après cela, il chargeait le "firmware" d'initialisation depuis la cassette située dans le lecteur, puis sur le contrôle de cet "attachement d'initialisation", il lisait depuis le cassette le "firmware"  du processeur principal destiné à s'exécuter depuis la mémoire centrale vive. Ensuite, le processeur principal exécute un chargement du premier "logiciel" normalement le System Initialisation Program SIP. Une alternative au SIP -chargée le plus souvent depuis bande magnétique- est le logiciel de tests fonctionnels élémentaires du processeur principal (OPELs).
Le rôle du SIP consiste à examiner la configuration du système contenu dans des tables logiciel (SRT System Resource Table), de charger le "firmware" correspondant à ces tables dans le sous-systèmes périphériques et en particulier dans l'URC et de lancer définitivement la configuration opérationnelle. Il constitue aussi la table de ressources effectivement disponible au système d'exploitation GCOS (SRST) terminant ainsi le processus d'initialisation.

En fonctionnement normal opérationnel, l'initialisation a lieu depuis disque; le "boot-record" est logé sur ces média au lieu d'être sur cassette. Mais le lancement des tests (POST) des contrôleurs et le choix du périphérique d'initialisation reste commandé par l'URC -via l'interface de maintenance des MSC ou MTC.   Le SIP se charge dans la mémoire principale à partir du "boot-record" et les autres contrôleurs de périphériques sont initialisés. "L'image" de la mémoire URC comprenant le support des périphériques spécifiés dans la SRT est descendue ("downloadée" ) dans la mémoire URC depuis la mémoire centrale via le canal PSI. Les micro-tâches de l'URC sont lancées et les périphériques qui le doivent sont placés dans leur état initial par ces micro-tâches.

Dans le cas où le sous-systèmes disques -s'il n'y en a qu'un- doit faire l'objet de vérifications (Tests et Diagnostics du sous-système et d'un appareil), l'initialisation a lieu comme depuis disques, le système d'exploitation chargé étant le SCP

Maintenance

Un arrêt inopiné du processeur central (interruption au niveau 0 -déclenchée par l'interpréteur d'instructions 64 ou par le superviseur GCOS ou par un time-out sur la durée d'une instruction)  se traduisait par l'envoi d'une interruption à l'URC sur le canal de maintenance, interrompant les microprocessus en cours.
Le bootstrap résident de l'attachement de maintenance interprétait cette interruption et lançait l'attachement de maintenance complet écrasant d'autres attachements de l'URC, à l'exception de la cassette, de la console et de l'imprimante. Cet attachement comprenait l'interpréteur du décor processeur de maintenance et l'ensemble de drivers disponibles à l'initialisation.

Dans ce décor -un sous-ensemble réduit du décor GCOS62- étaient écrits un mini-système d'exploitation MPOS 'maintenance panel operating system" et un certain nombre de commandes interprétant les données entrées par l'opérateur à la console du système, telles que DUMP sur l'imprimante, DUMP registres du CPU sur la console, etc...MPOS peut accéder à plusieurs "devices" de l'URC, notamment la console, la cassette et l'imprimante. L'accès à la cassette permettra de créer des commandes non résidentes.

Génération

La programmation de tous les produits liés à l'URC fut faite jusqu'aux années 1980 sur des outils tournant sous GCOSIII sur GE-635, puis sur H-6000 dans les locaux de Bull. Il était, à l'époque, considéré comme stratégique que ni les filiales, ni à fortiori les clients eussent une quelconque de connecter des appareils non-Bull au système 64. La modularité de l'architecture permettait cette exclusion au prix d'une complexité logistique non négligeable  La distribution des Basic System Release (ensemble des micro-logiciels et des outils logiciels appropriés) était distribuée comme du "hardware" par l'usine d'Angers.

Le langage d'écriture du firmware de l'URC était un macro-assembleur. Lorsque le processeur de l'URC devint un 68000, le langage C  remplaça l'assembleur.

Evolution du projet

Version Diskette de l'URC (URC-E)

Le choix de la cassette pour le support des fonctions de service du Level64 n'était pas complètement satisfaisant. Il présentait des risques de mauvaise fiabilité dus aux rebobinages fréquents. La cassette ne répondait pas non plus aux espérances comme media de saisie de données. Aussi, la nouvelle version de l'URC développée en 1976-1978 dans le cadre du Levl64-DPS s'orienta vers le remplacement de la cassette par une diskette 8 pouces, le standard émergent de la micro-informatique à l'époque, qui avait été choisi par IBM comme media de maintenance pour le S/370 au début de la décennie 1970. L'URC-E différait du modèle précédent par un l'évolution de la technologie en TTL 74S (le 74N souffrant déjà d'un problème d'approvisionnement de circuits) et le remplacement des chips DRAM par le modèle 16Kbits, ce qui permettait à la fois de réduire l'encombrement du tiroir URC et d'étendre la mémoire à 64K octets.

Système P7G (DPS/7-x0)

L'URC de P7G restait du point de vue matériel et micro-logiciel de base, celle du 64DPS. Par contre les fonctions de maintenance en différaient sensiblement. Bien que tous les systèmes Leo (P7G) furent dotés du frontal Level 6, le MLA devait être conservé pour les systèmes Taurus de bas de gamme, beaucoup de ces derniers étant des évolutions de Level64 sur parc.

Le système P7G différait essentiellement de celui du Level 64 du fait que le processeur central ne disposait d'aucun firmware en ROM. La procédure d'initialisation du processeur central était différente: les tests du central et les valeurs d'intialisation des registres devaient être alimentés par le SURP.

D'autre part, le système P7G étant un multiprocesseur capable d'un partitionnement en deux systèmes indépendants, il était nécessaire de disposer de deux SURP pour l'utilisation en bi-système qui par ailleurs pouvaient être basculer l'un sur l'autre en cas de panne.

URC vs Front-End Processor

Datanet-2000

Le Datanet-2000 était un processeur frontal de communications développé par Honeywell pour la série H-200/2000 à base du mini-ordinateur H-516. Pour reprendre la base de clientèle H-200 par le Level 64, il fut décidé de connecter ce frontal sur un canal PSI. L'existence de ce produit contribua à diminuer la pression pour le développement de l'URC6MLA vers le haut.

Frontal DSA

Après la fusion de CII et de Honeywell-Bull, CII-HB obtint de Honeywell la mission de réaliser "le frontal commun" de l'architecture DSA (Distributed System Architecture) pour les systèmes DPS-7 et DPS-8. Cette décision posa des problèmes à toutes les lignes de produits (GCOS4 qui s'en abstint, GCOS8 qui traîna des pieds et GCOS7 qui dut s'y contraindre mais devait assurer à la fois une coexistence et une évolution avec les systèmes URC.

Système Aquila (DPS/7-10x7)

En 1987, fut introduit par Bull, un système de haut de gamme DPS/1007 dont le processeur était celui du S/750 développé par NEC.

NEC avait dérivé son propre URP à partir du design initial Bull et il fut décidé de conserver le produit NEC pour l'initialisation et la maintenance du central. Le SIP fut adapté pour reconnaître l'existence de ce SURP, mais ce SURP ne fut pas rendu visible au logiciel GCOS et ne servait qu'aux interventions des techniciens Bull ainsi qu'au partitionnement éventuel d'une configuration multi-processeurs. Le support des imprimantes et de la console GCOS7 restèrent sur l'URC de fabrication Bull.

Eclatement du système de maintenance

Avec le système Auriga, l'architecture de maintenance du central fut sensiblement modifiée. Un microprocesseur Intel 386 sur une plaque montée dans le coffret de l'unité centrale effectuait les fonctions spécialisées de ce modèle de processeur

La console proprement dite était un micro-ordinateur PC 386 sous Windows 3.1 dont on utilisait l'écran, le clavier, l'imprimante et la diskette au lieu des appareils directement contrôlés par l'URC

Remplacement du Microprocesseur

En 1969-1974, il était prévu que le design du matériel du processeur URC soit "VLSIfié" lorsque la technologie deviendrait disponible. Cependant, une des limitations de l'URC restait la capacité d'adressage limitée que le dispositif d'extension introduit par l'URC-E ne résolvait qu'imparfaitement. Le coût de "VLSIfication" d'un mini-ordinateur vendu à quelques milliers d'exemplaires était relativement prohibitif et l'évaluation de microprocesseurs fournis à l'extérieur s'imposa naturellement comme alternative.

En pratique, l'architecture micro-logiciel de l'URC fut conservée et le processeur Motorola était sous le contrôle d'une version du MIOS recodée sur MC68000.

Notes

PROM ou ROM.
les premières réalisations furent faites en utilisant des PROM dont il était nécessaire au fabriquant de semi-conducteurs de fournir le masque de métallisation externe. Cette procédure -outre son prix élevé avait l'inconvénient d'un temps très long entre la correction d'un bug et le remplacement du chip défectueux en clientèle. Elle entraîna la création d'une "zone de patches" situés ne mémoire vive dans laquelle étaient placés le contournement du problème au prix d'un certain ralentissement.
A l'époque des années 1970, les PROM étaient plus rapides que les DRAM dans un rapport de 3. La DRAM posait de plus des contraintes de rafraichissemnt qui interrompaient le déroulement des micro-processus temps réel. L'architecture du "firmware" URC devait être très rigoureuse pour minimiser l'impact des corrections sur les performances.
Plus tard -sur l'URC-E-, des EPROM modifiables en usine par CII-HB et plus rarement en clientèle remplaceront avantageusement les PROM.

Attachement de URC.
Mot utilisé par développeurs et commerciaux pour désigner les "programmes se déroulant" sur l'URC sous-contrôle du MIOS. Ces programmes occupent une certaine place mémoire, sont normalement relocatables et peuvent dans quelques cas comporter des "overlays". Selon la configuration, ils peuvent être multi-tâches (multi-thread)..

Attachement canal à canal
L'architecture de l'URC fut utilisée pour réaliser un "channel to channel adapter" permettant l'interconnexion de deux systèmes Level 64DPS. Cette réalisation fut faite à la fin des années 1970 à une époque où CII-HB s'apprêtait à annoncer son architecture distribuée DSA dans laquelle le rôle essentiel était déplacé de l'URC vers le frontal Datanet. Aussi le CTC adapter npn supporté an standard par GCOS64 ne fut pas utilisé en clientèle
L'URC servant de liaison CTC (mais pouvant aussi recevoir d'autres appareils et même servir de SURP était connecté à chaque unité centrale par un canal PSI. Le CTC ne comprenait aucun matériel spécifique, les sous-canaux affectés au CTC étaient multiplexés sur le canal PSI et la mémoire tampon de l'échange était de la mémoire de travail de l'attachement dans la mémoire centrale de l'URC.

SCP et SIP
Le Suport Control Program (SCP) est un système d'exploitation primitif permettant l'exécution de travaux individuellement lancés par l'opérateur, soit un enchaînement séquentiels de travaux. Il n'offre pas de support de multi-programmation, permet le multi-tâches (défini statiquement). Il fut utilisé comme support de la première version de l'émulateur GE-100 sur Level 64 et resta utilisé comme support des tests et diagnostics "stand-alone" permettant les diagnostics de sous-systèmes disques et de discriminer pannes du central et problèmes logiciels de GCOS.
A l'origine conçu comme un travail (job step) séparé sous SCP, l'initialisation du système fut ensuite combinée avec le code de SCP, l'ensemble fut renommé System Initialization Program (SIP). cette intégration réduisait de manière significativela durée de la phase de lancement de GCOS.

Jean Bellec

Retour