VM (hyperviseur)
VM/370, où VM est l'abréviation de Virtual Machine, est la combinaison d'un hyperviseur, CP, dérivé de travaux d'IBM dans les années 1960 pour ses mainframes, et d'un mini-système d'exploitation monoutilisateur, monotâche et conversationnel nommé CMS. Le rôle de l'hyperviseur était de simuler plusieurs machines réelles, soit faisant tourner des systèmes d'exploitation différents (pour faciliter les migrations de l'un à l'autre), soit pour permettre à plusieurs étudiants en informatique de réaliser simultanément leurs travaux pratiques sans se gêner mutuellement. Il permettait aussi de simuler du Bare Metal Restore avant que l'expression n'existe.
Historiquement, VM/370 dérivait de l'hyperviseur CP-67, mis au point en partie à l'université de Grenoble pour créer ces environnements de machines virtuelles sur un IBM 360 modèle 67. Cette machine était un 360/65 muni de registres associatifs rendant très performants les systèmes de pagination. Les résultats étant conformes aux attentes, IBM généralisa ces registres associatifs ainsi que la mémoire virtuelle à toute sa gamme 370 en 1974, y compris sur les modèles déjà installés, qui furent ainsi mis à jour. VM/370 fut annoncé en même temps.
Pour exploiter les machines virtuelles non équipées d'un système d'exploitation classique était fourni CMS, système simplifié mono-utilisateur permettant le développement de programmes dans une machine virtuelle. Le confort de ce système était tel que de nombreux clients qui n'avaient au départ pris VM/370 que pour assurer les tâches de migration le conservèrent ensuite pour la productivité que donnait CMS à leurs équipes. La légèreté de CMS et l'efficacité de CP permettaient d'avoir couramment 400 CMS tournant simultanément sur un IBM 3033, qui n'en aurait pas dépassé beaucoup la centaine sous TSO.
Outre booter CMS (i cms), on pouvait également booter dans une machine virtuelle un système APL qui lui était dédié (i apl). Dans la seconde moitié des années 1970, le système APL dédié fut remplacé par un produit-programme APL tournant sous CMS.
Périphériques virtuels
L'immense majorité des périphériques de la série 370 étaient simulables sur une machine virtuelle, et configurables y compris en cours de fonctionnement : en particulier lecteur(s)/perforateur(s) de carte(s), imprimante(s), bande(s) et minidisques, qui étaient des disques simulés auxquels on affectait juste la taille utile pour les travaux. Il suffisait d'en spécifier à l'hyperviseur le type d'unité, l'adresse canal virtuelle (3 chiffres) et le nombre de cylindres et le mode d'accès (lecture seule ou lecture-écriture), par exemple def t3370 195 5 pour obtenir un mini-3370 temporaire (T) de 5 cylindres à l'adresse canal 195.
Segments partagés
Un ordinateur hébergeant typiquement de 40 à 200 machines virtuelles comportant presque toutes un CMS, il aurait été absurde de répliquer autant de fois le code de CMS. Des plages d'adresses contenant uniquement des sections de code pur (dont CMS, mais aussi les codes de compilateurs, de langages interprétés comme REXX ou d'éditeurs plein écran comme XEDIT) étaient donc chargées dans des segments partagés, que chaque utilisateur voyait comme appartenant à la mémoire de sa propre machine virtuelle.
Nommage et partage des mini disques et fichiers
Les disques étaient nommés par une lettre et accédés par CMS dans l'ordre alphabétique de ces lettres (qui donnaient l'équivalent d'un chemin d'accès bien avant UNIX ou DOS). Les lettres pouvaient être changées au vol à mesure des besoins, un minidisque restant identifié par son adresse canal virtuelle (par exemple 191) pour un utilisateur donné.
Un fichier CMS était désigné par un nom de 8 lettres, d'une extension indiquant le type de fichier (EXEC, FORTRAN, SCRIPT...), de 8 lettres également, et si besoin de la lettre de son minidisque, suivie éventuellement d'un chiffre de 1 à 5 indiquant ses modalités d'accès. Exemple : PNEU KLEBER C1
Le propriétaire d'un disque virtuel pouvait en permettre le partage, en lecture seule ou en lecture-écriture. Une autre machine pouvait alors y accéder en précisant le nom de sa machine virtuelle et son adresse canal virtuelle.
Networking interne, puis externe
La connexion (par une simple instruction au clavier) d'un perforateur de cartes virtuel d'une machine virtuelle à un lecteur de cartes virtuel d'une autre permettait de réaliser si facilement du networking entre machines virtuelles (qu'elles fussent CMS, DOS/VS ou MVS) que tout un écosystème logiciel se développa autour de cette notion, à commencer par des machines virtuelles dédiées à des travaux de compilation en tâche de fond. Lorsque cet écosystème fut rodé et se montra correspondre à des besoins d'entreprises apparut Remote Spooling Communication Sybsystem (RSCS), qui permettait exactement la même opération entre machines virtuelles situées sur des sites différents et connectées par une ligne. C'est sur cette base que fut élaboré en quelques années le VNET (en) qui connecta peu à peu entre elles des machines IBM du monde entier, surtout à partir de 1979, parallèlement aux travaux indépendants d'ARPANET, et de façon distincte. L'une de ses retombées fut le système de communication d'entreprise PROFS (Professional Office System).
Articles liés
Documentation
- (en) [PDF] The Origin of the VM/370 Time-Sharing System, IBM Journal of Research and Development, .
- (en) [PDF] VM and the VM Community, par Melinda Varian
- (en) [PDF] Documentation IBM