Historique des systèmes d'exploitation mainframe IBM - History of IBM mainframe operating systems

L' histoire des systèmes d'exploitation exécutés sur les mainframes IBM est un chapitre notable de l' histoire des systèmes d'exploitation mainframe , en raison de la position de longue date d' IBM en tant que plus grand fournisseur mondial de matériel informatique mainframe .

On peut dire que les systèmes d'exploitation qu'IBM a fournis aux clients pour une utilisation sur ses premiers mainframes ont rarement été très innovants, à l'exception des systèmes de machines virtuelles commençant par CP-67 . Mais la réputation bien connue de l'entreprise de préférer une technologie éprouvée a généralement donné aux utilisateurs potentiels la confiance nécessaire pour adopter assez rapidement les nouveaux systèmes IBM. Les systèmes d'exploitation mainframe actuels d'IBM, z/OS , z/VM , z/VSE et z/TPF , sont les successeurs rétrocompatibles des systèmes d'exploitation introduits dans les années 1960, bien qu'ils aient bien sûr été améliorés à bien des égards.

Les systèmes d'exploitation fournis par IBM et ceux fournis par d'autres sont abordés ici s'ils sont notamment utilisés sur des mainframes IBM.

Avant System/360

IBM a été lent à introduire des systèmes d'exploitation : General Motors a produit le système d'exploitation General Motors en 1955 et l' E/S GM-NAA en 1956 pour une utilisation sur ses propres ordinateurs IBM ; et en 1962, Burroughs Corporation a publié MCP et General Electric a introduit GECOS , dans les deux cas à l'usage de leurs clients.

En fait, les premiers systèmes d'exploitation pour ordinateurs IBM ont été écrits par des clients IBM qui ne souhaitaient pas que leurs machines très coûteuses (2 millions de dollars US au milieu des années 1950) restent inactives pendant que les opérateurs configuraient les tâches manuellement, et ils voulaient donc un mécanisme pour maintenir une file d'attente de travaux.

Les systèmes d'exploitation décrits ci-dessous ne fonctionnaient que sur quelques modèles de processeurs et n'étaient adaptés qu'aux calculs scientifiques et techniques. Les utilisateurs avec d'autres ordinateurs IBM ou d'autres applications devaient gérer sans systèmes d'exploitation. Mais l'un des plus petits ordinateurs d' IBM , l' IBM 650 , a introduit une fonctionnalité qui est ensuite devenue une partie de l' OS/360 : si le traitement était interrompu par une "erreur de traitement aléatoire" (problème matériel), la machine pouvait reprendre automatiquement à partir du dernier point de contrôle au lieu de obligeant les opérateurs à redémarrer le travail manuellement depuis le début.

Des E/S GM-NAA de General Motors à IBSYS

La division de recherche de General Motors a produit des E/S GM-NAA pour son IBM 701 en 1956 (à partir d'un prototype, le système d'exploitation GM, développé en 1955), et l'a mis à jour pour le successeur du 701. En 1960, l'association d'utilisateurs d'IBM SHARE l' a repris et a produit une version mise à jour, SHARE Operating System .

Enfin, IBM a repris le projet et a fourni une version améliorée appelée IBSYS avec les ordinateurs IBM 7090 et IBM 7094 . IBSYS nécessitait 8 lecteurs de bande (moins si le système avait un ou plusieurs lecteurs de disque). Ses principaux composants étaient : un langage de contrôle des tâches basé sur une carte , qui était la principale interface utilisateur ; compilateurs pour FORTRAN et COBOL ; un assembleur ; et divers utilitaires, y compris un programme de tri .

En 1958, l'Executive System de l'Université du Michigan a adapté les E/S GM-NAA pour produire UMES , qui était mieux adapté au grand nombre de petits emplois créés par les étudiants. UMES a été utilisé jusqu'en 1967, date à laquelle il a été remplacé par le système de temps partagé MTS .

BESYS

Bell Labs a produit BESYS (parfois appelé BELLMON) et l'a utilisé jusqu'au milieu des années 1960. Bell l'a également mis à la disposition d'autres personnes sans frais ni soutien technique officiel.

Système de surveillance FORTRAN

Avant IBSYS, IBM produisait pour ses ordinateurs IBM 709 , 7090 et 7094 un système d'exploitation sur bande dont le seul but était de compiler des programmes FORTRAN . En fait, FMS et le compilateur FORTRAN étaient sur la même bande.

Les premiers systèmes de temps partagé et de machines virtuelles

MIT de Fernando Corbato a produit les premiers expérimentaux en temps partagé systèmes, tels que CTSS , de 1957 au début des années 1960, en utilisant légèrement modifiés IBM 709 , IBM 7090 et IBM 7094 ordinateurs centraux; ces systèmes étaient basés sur une proposition de John McCarthy . Dans les années 1960, les propres laboratoires d'IBM ont créé des systèmes expérimentaux de temps partagé, utilisant des ordinateurs centraux standard avec des modifications matérielles et microcodes pour prendre en charge la mémoire virtuelle : IBM M44/44X au début des années 1960 ; CP-40 de 1964 à 1967; CP-67 de 1967 à 1972. La société a même sorti CP-67 sans garantie ni support technique à plusieurs gros clients de 1968 à 1972. CP-40 et CP-67 utilisaient des processeurs System/360 modifiés , mais le M44/44X était basé sur l' IBM 7044 , une génération antérieure de CPU qui était très différente en interne.

Ces systèmes expérimentaux étaient trop tard pour être intégrés à la série System/360 qu'IBM a annoncée en 1964, mais a encouragé la société à ajouter des capacités de mémoire virtuelle et de machine virtuelle à ses mainframes System/370 et à leurs systèmes d'exploitation en 1972 :

• Le M44/44X a montré qu'une approche partielle des machines virtuelles n'était pas suffisante et que le thrashing pouvait réduire considérablement la vitesse des systèmes de mémoire virtuelle. Le thrashing est une condition dans laquelle le système s'exécute très lentement car il passe une grande partie de son temps à mélanger les pages de mémoire virtuelle entre la mémoire physique et les fichiers disque.
• IBM a appris du CP-40 et du CP-67 : comment gérer le problème de l'écrasement ; que ses autres technologies de mémoire virtuelle et de machine virtuelle étaient suffisamment rapides et fiables pour être utilisées dans les systèmes commerciaux à volume élevé qui constituaient son activité principale. En particulier, David Sayre d' IBM a convaincu l'entreprise que la gestion automatisée de la mémoire virtuelle pouvait toujours fonctionner au moins aussi bien que les meilleurs schémas de superposition conçus par un programmeur.

En 1968, une société de conseil appelée Computer Software Systems a utilisé la version commercialisée du CP-67 pour mettre en place un service commercial de partage du temps. L'équipe technique de la société comprenait 2 recrues du MIT (voir CTSS ci-dessus), Dick Orenstein et Harold Feinleib. Au fur et à mesure de sa croissance, l'entreprise s'est rebaptisée National CSS et a modifié le logiciel pour augmenter le nombre d'utilisateurs payants qu'elle pouvait prendre en charge jusqu'à ce que le système soit suffisamment différent pour justifier un nouveau nom, VP/CSS . VP/CSS était le mécanisme de livraison des services de National CSS jusqu'au début des années 1980, lorsqu'il est passé au VM/370 d'IBM (voir ci-dessous).

Les universités ont produit trois autres systèmes d'exploitation en temps partagé S/360 à la fin des années 1960 :

• Le Michigan Terminal System (MTS) a été développé en 1967 par un consortium d'universités dirigé par l' Université du Michigan . Toutes les versions fonctionnaient sur les mainframes d'IBM dotés d'une capacité de mémoire virtuelle, à commencer par le S/360-67 . MTS est resté en service jusqu'en 1999.
• L'Université McGill à Montréal a commencé à développer MUSIC (McGill University System for Interactive Computing) en 1969. MUSIC a été amélioré plusieurs fois et a finalement pris en charge les recherches de texte, la publication Web et le courrier électronique ainsi que le développement de logiciels. MUSIC a été commercialisé par IBM principalement auprès des établissements d'enseignement en tant que système d'exploitation rentable pour son matériel, et est finalement devenu un produit système IBM (MUSIC/SP ou système multi-utilisateurs pour l'informatique interactive / produit système) en 1985. La dernière version officielle est sorti en 1999.
• ORVYL et WYLBUR ont été développés par l'Université de Stanford en 1967-68 pour l'IBM S/360-67. Ils ont fourni certaines des premières capacités de partage de temps sur les ordinateurs IBM S/360.

Systèmes d'exploitation système/360

Jusqu'au début des années 1960, les systèmes bas de gamme et haut de gamme d'IBM étaient incompatibles – les programmes ne pouvaient pas être facilement transférés de l'un à l'autre et les systèmes utilisaient souvent des périphériques complètement différents (par exemple, des lecteurs de disque). IBM a conclu que ces facteurs augmentaient ses coûts de conception et de production pour le matériel et les logiciels à un niveau insoutenable et réduisaient les ventes en dissuadant les clients de procéder à une mise à niveau. Ainsi, en 1964, la société a annoncé System/360 , une nouvelle gamme d'ordinateurs qui utilisaient tous les mêmes périphériques et dont la plupart pouvaient exécuter les mêmes programmes.

IBM avait initialement prévu que System/360 ne devrait avoir qu'un seul système d'exploitation orienté batch , OS/360. Il y a au moins deux raisons pour lesquelles IBM a décidé plus tard qu'il devrait également produire un système d'exploitation orienté batch plus simple, DOS/360 :

• car il a constaté que l'OS/360 ne rentrait pas dans la mémoire limitée disponible sur les modèles System/360 plus petits ;
• ou parce qu'il s'est rendu compte que le développement d'OS/360 prendrait beaucoup plus de temps que prévu, et a introduit DOS/360 comme l'un d'une série de palliatifs pour empêcher les ventes de matériel System/360 de s'effondrer - les autres étaient BOS/360 (Basic Operating System, pour les plus petites machines) et TOS/360 (Tape Operating System, pour les machines avec uniquement des lecteurs de bande).

Les systèmes d'exploitation de System/360 étaient plus complexes que les systèmes d'exploitation IBM précédents pour plusieurs raisons, notamment :

• Ils devaient prendre en charge la multiprogrammation  – basculer pour exécuter une autre application en cours lorsque l'application actuelle était bloquée en attendant la fin des opérations d' E/S (telles que les lectures de disque). Sans la multiprogrammation, les processeurs les plus rapides de la gamme auraient passé la plupart de leur temps inactifs, à attendre des opérations d'E/S lentes. Par conséquent, les systèmes d'exploitation devaient être les véritables maîtres des systèmes, fournir tous les services que les applications demandaient valablement et gérer les plantages ou les mauvais comportements dans une application sans arrêter les autres qui s'exécutaient en même temps.
• Ils devaient prendre en charge une gamme beaucoup plus large de tailles de machines. La mémoire variait de 16 Ko à 1 Mo et les vitesses de processeur de quelques milliers d'instructions par seconde à 500 000.
• Ils devaient prendre en charge un large éventail d'exigences d'application. Par exemple, certaines applications n'avaient besoin que de lire des fichiers séquentiels du début à la fin ; d'autres avaient besoin d'un accès rapide et direct à des enregistrements spécifiques dans des fichiers très volumineux ; et quelques applications passaient presque tout leur temps à faire des calculs, avec très peu de lecture ou d'écriture de fichiers.

Cela a fait du développement d'OS/360 et d'autres logiciels System/360 l'un des plus grands projets logiciels jamais tentés, et IBM a rapidement rencontré des problèmes, avec d'énormes dépassements de temps et de coûts et un grand nombre de bogues . Ces problèmes n'ont été que amplifiés car pour développer et tester les systèmes d'exploitation System/360 sur du matériel réel, IBM a d'abord dû développer Basic Programming Support/360 (BPS/360). BPS a été utilisé pour développer les outils nécessaires au développement de DOS/360 et OS/360, ainsi que les premières versions d'outils qu'il fournirait avec ces systèmes d'exploitation – des compilateurs pour FORTRAN et COBOL , des utilitaires dont Sort , et surtout l' assembleur qu'il nécessaire pour construire tous les autres logiciels.

Les concurrents d'IBM ont profité des retards de l'OS/360 et du System/360 pour annoncer des systèmes destinés à ce qu'ils pensaient être les parties les plus vulnérables du marché d'IBM. Pour éviter que les ventes de System/360 ne s'effondrent, IBM a publié quatre systèmes d'exploitation provisoires :

• Système d'exploitation de base/360 (BOS/360), chargé à partir d'un lecteur de disque ou d'un lecteur de bande et prenant en charge les lecteurs de bande et quelques disques. Ce système a été fourni aux clients de test bêta et peut avoir été une première version de DOS/360.
• TOS/360 , qui a été conçu pour fournir un chemin de mise à niveau aux clients qui disposaient d' ordinateurs IBM 1401 avec des lecteurs de bande et sans disques.
• DOS/360 , qui a été construit par les développeurs de BOS/360 et TOS/360 (la division des ordinateurs des petites entreprises d'IBM) et est devenu un système d'exploitation grand public dont le descendant z/VSE est encore largement utilisé.
• Système d'exploitation/360 (OS/360) avec uniquement l' option Programme de contrôle primaire (PCP), qui ne prenait pas en charge la multiprogrammation.

Quand IBM a annoncé le S/360-67, il a également annoncé un système d'exploitation en temps partagé , TSS/360 , qui utiliserait les nouvelles capacités de mémoire virtuelle du 360/67. TSS/360 était en retard et les premières versions étaient lentes et peu fiables. À cette époque, le système d'exploitation alternatif CP-67 , développé par le Cambridge Scientific Center d' IBM , fonctionnait suffisamment bien pour qu'IBM l'offre « sans garantie » en tant que service de partage de temps pour quelques gros clients. CP-67 allait devenir VM/370 et finalement z/VM . IBM a finalement proposé trois versions d'un PRPQ TSS/370 comme chemin de migration pour ses clients TSS/360, puis l'a abandonné.

Les traumatismes liés à la production des systèmes d'exploitation System/360 ont donné un élan à la discipline émergente du génie logiciel , à la tentative d'appliquer des principes scientifiques au développement de logiciels et à la gestion de projets logiciels . Frederick P. Brooks , qui était chef de projet senior pour l'ensemble du projet System/360 et qui s'est ensuite vu confier la responsabilité spécifique d'OS/360 (qui était déjà attendu depuis longtemps), a écrit un livre acclamé, The Mythical Man-Month , basé sur le problèmes rencontrés et enseignements tirés au cours du projet, dont deux :

• Allouer des ressources supplémentaires (en particulier du personnel) à un projet en difficulté devient rapidement improductif voire contre-productif en raison des difficultés de communication. C'est le syndrome « ​​Homme-Mois Mythique » qui a donné son titre au livre.
• Le successeur d'un système réussi rencontre souvent des difficultés car il est surchargé de toutes les fonctionnalités que les gens auraient souhaité avoir dans le système précédent. Brooks a appelé cela " l'effet du second système ", et a cité OS/360 comme un exemple très complet.

DOS/360

Alors que OS/360 était le système d'exploitation préféré pour les machines System/360 haut de gamme, DOS/360 était le système d'exploitation habituel pour les machines moins puissantes. Il a fourni un ensemble de programmes utilitaires , un assembleur de macros et des compilateurs pour FORTRAN et COBOL . Le support pour RPG est venu plus tard, et finalement un sous-ensemble PL/I . Et il a pris en charge une gamme utile d'organisations de fichiers avec des méthodes d'accès pour aider à les utiliser :

• Les ensembles de données séquentiels étaient normalement lus un enregistrement à la fois du début à la fin.
• Dans les fichiers indexés ( ISAM ), une section spécifiée de chaque enregistrement était définie comme une clé pouvant être utilisée pour rechercher des enregistrements spécifiques.
• Dans les fichiers à accès direct ( BDAM ), le programme d'application devait spécifier l'emplacement physique sur le disque des données auxquelles il voulait accéder. La programmation BDAM n'était pas facile et la plupart des clients ne l'utilisaient jamais eux-mêmes, mais c'était le moyen le plus rapide d'accéder aux données sur les disques et de nombreuses sociétés de logiciels l'utilisaient dans leurs produits, en particulier les systèmes de gestion de bases de données tels que ADABAS , IDMS et IBM DL/I .

Les fichiers séquentiels et ISAM peuvent stocker des enregistrements de longueur fixe ou variable, et tous les types peuvent occuper plusieurs volumes de disque.

DOS/360 offrait également BTAM , une installation de communication de données primitive et difficile à utiliser selon les normes d'aujourd'hui. Mais BTAM pouvait communiquer avec presque tous les types de terminaux, ce qui était un gros avantage à une époque où il n'y avait pratiquement pas de standardisation des protocoles de communication.

Mais DOS/360 présentait des limitations importantes par rapport à OS/360 , qui était utilisé pour contrôler la plupart des machines System/360 plus grandes :

• La première version ne pouvait exécuter qu'un seul programme à la fois. Une amélioration ultérieure en permettait 3 en même temps, dans l'une des 3 "partitions" dont la taille était définie par chaque client lors de l'installation de DOS/360.
• Le JCL utilisé pour soumettre les travaux a été conçu pour être facile à traiter pour les machines bas de gamme, et par conséquent, les programmeurs ne l'ont pas trouvé facile à lire ou à écrire.
• Il n'y avait pas de sous-système de mise en file d'attente pour améliorer l'efficacité de l'utilisation des cartes perforées et des imprimantes. À la fin des années 1960, une société de logiciels indépendante a commencé à vendre un spouleur appelé GRASP.
• DOS/360 n'avait pas de chargeur de déplacement , les utilisateurs devaient donc éditer une version exécutable distincte de chaque programme pour chaque partition dans laquelle le programme était susceptible d'être exécuté.
• Les programmes exécutables étaient stockés dans la bibliothèque d'images de base, qui ne récupérait pas d'espace lorsque les programmes étaient supprimés ou remplacés par des versions plus récentes. Lorsque la bibliothèque d'images principale était pleine, elle devait être compressée par l'un des programmes utilitaires, ce qui pouvait interrompre le travail de développement jusqu'à une demi-journée.
• Son interface de programmation d'applications était différente de celle d'OS/360. Les programmes DOS/360 écrits dans des langages de haut niveau tels que COBOL nécessitaient de petites modifications avant de pouvoir être utilisés avec OS/360 et les programmes en langage assembleur nécessitaient des changements plus importants.

IBM s'attendait à ce que les utilisateurs de DOS/360 passent bientôt à OS/360, mais malgré ses limitations, DOS/360 est devenu le système d'exploitation le plus utilisé au monde car :

• Matériel System/360 très bien vendu
• Plus de 90 % des 360 systèmes vendus étaient des modèles 20, 30 et 40
• La plupart de ces modèles moins chers avaient beaucoup moins de mémoire centrale que celle requise par OS/360.

DOS/360 fonctionnait bien sur les processeurs System/360 que les entreprises de taille moyenne pouvaient se permettre, et c'était mieux que les "systèmes d'exploitation" que ces clients avaient auparavant. En conséquence, son descendant z/VSE est encore largement utilisé aujourd'hui, à partir de 2005.

OS/360

OS/360 incluait plusieurs niveaux de support, une seule API et beaucoup de code partagé. PCP était une version provisoire qui ne pouvait exécuter qu'un seul programme à la fois, mais MFT (" Multiprogramming with a Fixed number of Tasks") et MVT (" Multiprogramming with a Variable number of Tasks") ont été utilisés au moins jusqu'à la fin 1970, soit cinq bonnes années après le lancement de leurs successeurs. On ne sait pas si les divisions entre PCP, MFT et MVT sont dues au fait que MVT nécessitait trop de mémoire pour être utilisable sur des machines de milieu de gamme ou parce qu'IBM avait besoin de publier une version multiprogrammation du système d'exploitation (MFT) dès que possible.

PCP, MFT et MVT avaient des approches différentes de la gestion de la mémoire (voir ci-dessous), mais fournissaient des fonctionnalités très similaires :

• La même interface de programmation d'application (API), de sorte que les programmes d'application peuvent être transférés entre PCP, MFT et MVT sans même avoir besoin d' être recompilés .
• Le même JCL , plus souple et plus simple d'utilisation que celui de DOS/360.
• Les mêmes facilités ( méthodes d'accès ) que DOS/360 pour la lecture et l'écriture de fichiers (séquentiels, indexés et directs) et pour les communications de données ( BTAM ).
• Une structure de fichier supplémentaire, partitionnée et méthode d'accès ( BPAM ), qui était principalement utilisée pour gérer les bibliothèques de programmes. Bien que les fichiers partitionnés aient dû être compressés pour récupérer de l'espace libre, cela a rarement interrompu le travail de développement comme c'était le cas avec la bibliothèque d'images de base de DOS/360, car PCP, MFT et MVT autorisaient un nombre indéfini de fichiers partitionnés, et chaque projet avait généralement au moins un.
• Un système de nommage des fichiers qui permettait de gérer les fichiers en tant que hiérarchies, par exemple PROJECT.USER.FILENAME .
• Une fonction de spoulage (qui manquait à DOS/360).
• Les applications pouvaient créer des sous-tâches, ce qui permettait la multiprogrammation au sein d'un seul travail.

L'expérience a montré qu'il n'était pas conseillé d'installer OS/360 sur des systèmes avec moins de 256 Ko de mémoire, ce qui était une limitation courante dans les années 1960.

MFT

Lors de l'installation de MFT , les clients spécifieraient jusqu'à quatre « partitions », des zones de mémoire avec des limites fixes, dans lesquelles les programmes d'application pourraient être exécutés simultanément. MFT Version II (MFT-II) a augmenté la limite à 52.

MVT

MVT était considérablement plus grand et plus complexe que MFT et était donc utilisé sur les processeurs System/360 les plus puissants. Il traitait toute la mémoire non utilisée par le système d'exploitation comme un pool unique à partir duquel des « régions » contiguës pouvaient être allouées selon les besoins d'un nombre indéfini de programmes d'application simultanés. Ce schéma était plus flexible que celui de MFT et utilisait en principe la mémoire plus efficacement, mais était susceptible de fragmentation  - après un certain temps, on pouvait constater que, bien qu'il y ait suffisamment de mémoire disponible au total pour exécuter un programme, il était divisé en morceaux séparés aucun de qui était assez grand.

En 1971, l' option de partage de temps (TSO) à utiliser avec MVT a été ajoutée. TSO est devenu largement utilisé pour le développement de programmes car il fournissait : un éditeur ; la possibilité de soumettre des travaux par lots, d'être averti de leur achèvement et de visualiser les résultats sans attendre les rapports imprimés ; débogueurs pour certains des langages de programmation utilisés sur System/360. TSO communiquait avec les terminaux en utilisant la TCAM ( Méthode d'accès aux télécommunications ), qui a finalement remplacé la méthode d'accès aux télécommunications en file d'attente (QTAM). Le nom de TCAM suggère qu'IBM espérait qu'il deviendrait la méthode d'accès standard pour les communications de données, mais en fait, TCAM a été utilisé presque entièrement pour TSO et a été largement remplacé par VTAM à partir de la fin des années 1970.

moniteurs TP

Le matériel et les systèmes d'exploitation de System/360 ont été conçus pour traiter des tâches par lots qui, dans des cas extrêmes, peuvent s'exécuter pendant des heures. En conséquence, ils étaient inadaptés au traitement des transactions , dans lequel il y a des milliers d'unités de travail par jour et chacune prend entre 30 secondes et quelques minutes. En 1968, IBM a publié IMS pour gérer le traitement des transactions, et en 1969, il a publié CICS , un système de traitement des transactions plus simple qu'un groupe d'employés d'IBM avait développé pour un client. IMS n'était disponible que pour OS/360 et ses successeurs, mais CICS était également disponible pour DOS/360 et ses successeurs. Pendant de nombreuses années, ce type de produit était connu sous le nom de "moniteur TP (télétraitement)". Les moniteurs TP à proprement parler n'étaient pas des composants de système d'exploitation mais des programmes d'application qui géraient d'autres programmes d'application. Dans les années 1970 et 1980, plusieurs moniteurs TP tiers étaient en concurrence avec CICS (notamment Taskmaster, COM-PLETE, Shadow et Intercomm), mais IBM a progressivement amélioré CICS au point que la plupart des clients ont abandonné les alternatives.

Systèmes spéciaux pour les compagnies aériennes

Dans les années 50, les compagnies aériennes se développaient rapidement, mais cette croissance était freinée par la difficulté de traiter manuellement des milliers de réservations (à l'aide de fichiers de cartes). En 1957, IBM a signé un contrat de développement avec American Airlines pour le développement d'un système de réservation informatisé, connu sous le nom de SABRE . Le premier système expérimental a été mis en service en 1960 et le système a repris toutes les fonctions de réservation en 1964 - dans les deux cas en utilisant des mainframes IBM 7090 . Au début des années 1960, IBM a entrepris des projets similaires pour d'autres compagnies aériennes et a rapidement décidé de produire un système de réservation standard unique, PARS , pour fonctionner sur des ordinateurs System/360 .

Dans SABRE et les premières versions de PARS, il n'y avait pas de séparation entre les composants d'application et de système d'exploitation du logiciel, mais en 1968, IBM l'a divisé en PARS (application) et ACP (système d'exploitation). Les versions ultérieures d'ACP ont été nommées ACP / TPF puis TPF (Transaction Processing Facility) car les entreprises non aériennes ont adopté ce système d'exploitation pour traiter de gros volumes de transactions en ligne. La dernière version est z/TPF .

IBM a développé ACP et ses successeurs parce que : au milieu des années 1960, les systèmes d'exploitation standard d'IBM ( DOS/360 et OS/360 ) étaient orientés batch et ne pouvaient pas gérer assez rapidement un grand nombre de transactions courtes ; même ses moniteurs de transactions IMS et CICS , qui fonctionnent sous le contrôle de systèmes d'exploitation standard à usage général, ne sont pas assez rapides pour traiter les réservations sur des centaines de vols de milliers d'agents de voyages.

La dernière version "domaine public" d'ACP, d'où sa dernière version "gratuite", était ACP 9.2, qui était distribuée sur une seule mini-bobine avec un jeu de manuels d'accompagnement (environ deux douzaines de manuels, qui occupaient peut-être 48 pouces linéaires d'étagère espace) et qui pourraient être restaurés sur des unités de disque IBM 3340 et qui fourniraient ainsi un système ACP entièrement fonctionnel.

ACP 9.2 était principalement destiné aux cartes bancaires (MasterCard, et al.) et à d'autres applications "financières", mais il pouvait également être utilisé pour les systèmes de réservation des compagnies aériennes, car à cette époque, ACP était devenu un système d'exploitation plus général. .

En effet, ACP avait alors incorporé un module "hyperviseur" (CHYR) qui supportait un système d'exploitation virtuel ... généralement VS1 , mais peut-être aussi VS2 ... en tant qu'"invité", avec lequel le développement de programmes ou la maintenance de fichiers pouvaient être accomplis simultanément. avec les fonctions en ligne.

Dans certains cas, le travail de production a été exécuté sous VS2 sous l'hyperviseur, y compris, éventuellement, IMS DB.

Système/360 Modèle 20

Le modèle 20 a été étiqueté comme faisant partie de la gamme System/360 car il pouvait être connecté à certains des mêmes périphériques, mais il s'agissait d'une machine 16 bits et pas entièrement compatible avec les autres membres de la gamme System/360. Trois systèmes d'exploitation ont été développés par les laboratoires d'IBM en Allemagne, pour différentes configurations 360/20 ; DPS — avec disques (mémoire minimale requise : 12 Ko) ; TPS : pas de disque mais avec des bandes (mémoire minimum requise : 8 Ko) ; et CPS, basé sur des cartes perforées (mémoire minimale requise : 4 Ko). Ceux-ci n'avaient pas de successeurs directs depuis qu'IBM a introduit la gamme System/3 d'ordinateurs pour petites entreprises en 1969 et System/3 avait une conception interne différente de celle du 360/20 et différents périphériques des mainframes d'IBM.

Système/360 Modèle 44

Il s'agissait d'un autre processeur qui utilisait les périphériques System/360 mais avait une conception interne différente. Le 360/44 a été conçu pour le calcul scientifique utilisant des nombres à virgule flottante , tels que des analyses géologiques ou météorologiques. En raison des différences internes et du type de travail spécialisé pour lequel il a été conçu, le 360/44 avait son propre système d'exploitation, PS/44. Un émulateur pour les instructions System/360 manquantes a permis au modèle 44 d'exécuter OS/360. Le 360/44 et le PS/44 n'avaient pas de successeurs directs.

Systèmes d'exploitation System/370 et mémoire virtuelle

Lorsque System/370 a été annoncé en 1970, il offrait essentiellement les mêmes fonctionnalités que System/360 mais avec environ 4 fois les vitesses de processeur des processeurs System/360 de prix similaire. Puis, en 1972, IBM a annoncé "System/370 Advanced Functions", dont l'élément principal était que les futures ventes de System/370 incluraient une capacité de mémoire virtuelle et que cela pourrait également être adapté aux processeurs System/370 existants. Par conséquent, IBM s'est également engagé à fournir des systèmes d'exploitation améliorés qui pourraient prendre en charge l'utilisation de la mémoire virtuelle.

La plupart des nouveaux systèmes d'exploitation se distinguaient de leurs prédécesseurs par la présence de "/VS" dans leurs noms. "VS" signifie "Virtual Storage" - IBM a évité le terme "mémoire virtuelle", prétendument parce que le mot "mémoire" pourrait être interprété comme impliquant que les ordinateurs IBM pourraient oublier des choses.

Tous les systèmes d'exploitation mainframe IBM aujourd'hui , sauf z / TPF sont les descendants de ceux qui figurent dans l'annonce « Système / 370 Fonctions avancées » - z / TPF est un descendant de ACP , le système qui IBM initialement développé pour soutenir réservations aériennes à volume élevé des applications .

DOS/VS

DOS/VS était le successeur de DOS/360 et offrait des fonctionnalités similaires, avec l'ajout d'une mémoire virtuelle. En plus de la mémoire virtuelle, DOS/VS a fourni d'autres améliorations :

• Cinq partitions de mémoire au lieu de trois. Les versions ultérieures ont augmenté ce nombre à sept.
• Un chargeur de relocalisation, de sorte qu'il n'était plus nécessaire d'éditer par lien une copie distincte de chaque programme pour chaque partition dans laquelle il devait s'exécuter.
• Un composant de spoulage amélioré , POWER/VS.

DOS/VS a été suivi de mises à niveau importantes : DOS/VSE et VSE/SP (années 1980), VSE/ESA (1991) et z/VSE (2005).

OS/VS1

OS/VS1 était le successeur de MFT et offrait des fonctionnalités similaires, avec l'ajout de mémoire virtuelle. IBM a publié des améliorations assez mineures d'OS/VS1 jusqu'en 1983, et en 1984 a annoncé qu'il n'y en aurait plus. OS/VS1 et TSS/370 sont les seuls systèmes d'exploitation IBM System/370 qui n'ont pas de descendants modernes.

Le système d'exploitation spécial en temps réel (SRTOS), Programming RPQ Z06751, était une variante d'OS/VS1 étendue pour prendre en charge l'informatique en temps réel . Il visait des industries telles que la gestion de l'énergie des services publics d'électricité et les applications des raffineries de pétrole.

OS/VS2 et MVS

OS/VS2 Release 1 ( SVS ) remplaçait MVT avec mémoire virtuelle ; bien qu'il y ait eu de nombreux changements, il a conservé la structure globale. Mais en 1974, IBM a publié ce qu'il a décrit comme OS/VS2 Release 2 mais qui était une réécriture majeure qui était compatible avec le précédent OS/VS2 SVS. La caractéristique la plus notable du nouveau système était qu'il prenait en charge plusieurs espaces d'adressage virtuels - différentes applications pensaient qu'elles utilisaient la même plage d'adresses virtuelles, mais les installations de mémoire virtuelle du nouveau système les ont mappées à différentes plages d'adresses de mémoire réelles. En conséquence, le nouveau système est rapidement devenu connu sous le nom de « MVS » (Multiple Virtual Storages), l'OS/VS2 d'origine est devenu connu sous le nom de « SVS » (Single Virtual Storage). IBM lui-même a accepté cette terminologie et a étiqueté les successeurs de MVS "MVS/...".

Les autres caractéristiques distinctives de MVS étaient : son catalogue principal devait être un catalogue VSAM ; il prenait en charge le "multitraitement étroitement couplé" (2 processeurs ou plus partagent la même mémoire et la même copie du système d'exploitation) ; il comprenait un gestionnaire de ressources système (rebaptisé Workload Manager dans les versions ultérieures) qui permettait aux utilisateurs de charger des travaux supplémentaires sur le système sans réduire les performances des travaux hautement prioritaires.

IBM a publié plusieurs mises à niveau de MVS : MVS/SE , MVS/SP Version 1, MVS/XA (1981), MVS/ESA (1985), OS/390 (1996) et actuellement z/OS (2001).

VM/370

VM/370 combinait une installation de machine virtuelle avec un système mono-utilisateur appelé Conversational Monitor System (CMS) ; cette combinaison offrait un partage du temps en permettant à chaque utilisateur d'exécuter une copie du CMS sur sa propre machine virtuelle. Cette combinaison était un descendant direct de CP/CMS . L'installation de machine virtuelle était souvent utilisée pour tester de nouveaux logiciels tandis que le travail de production normal se poursuivait sur une autre machine virtuelle, et le système de partage de temps CMS était largement utilisé pour le développement de programmes.

VM/370 a été suivi d'une série de mises à niveau : VM/SEPP ("Systems Extensions Program Product"), VM/BSEPP ("Basic Systems Extensions Program Product"), VM/SP (System Product), VM/SP HPO (" High Performance Option"), VM/XA MA ("Extended Architecture Migration Aid"), VM/XA SF ("Extended Architecture System Facility"), VM/XA SP ("Extended Architecture System Product"), VM/ESA (" Architecture des systèmes d'entreprise"), et z/VM . IBM a également produit des assistants de microcode en option pour les machines virtuelles et les successeurs, afin d'accélérer l' émulation par l' hyperviseur des instructions privilégiées (celles que seuls les systèmes d'exploitation peuvent utiliser) au nom des systèmes d'exploitation « invités ». Dans le cadre de l'architecture 370/Extended, IBM a ajouté l'instruction Start Interpretive Execution (SIE) pour permettre une accélération supplémentaire de l'hyperviseur CP.

Notes techniques

Partage de temps

Le temps partagé (ou temps partagé) est basé sur l'idée que les ordinateurs sont beaucoup plus rapides que les humains, donc pendant qu'un utilisateur humain lit ce qu'un ordinateur vient d'afficher sur un écran, l'ordinateur peut effectuer un travail utile pour un autre utilisateur. Les grands systèmes à temps partagé peuvent avoir des centaines, voire des milliers d'utilisateurs simultanés, et la mémoire requise par leurs programmes et données représente généralement bien plus que la mémoire physique connectée à l'ordinateur. Les systèmes à temps partagé résolvent ce problème par diverses combinaisons de :

• mémoire virtuelle, décrite ci-dessous.
• échange : lorsque le système d'exploitation attend une réponse d'un utilisateur, qu'une tranche de temps est terminée ou que le système d'exploitation essaie de libérer de l'espace de stockage réel, il peut enregistrer les programmes et les données d'un utilisateur sur un disque ou un tambour et les relire en mémoire lorsque l'utilisateur envoie une réponse, des ressources se libèrent ou un autre utilisateur est échangé en raison de la fin de la tranche de temps . L'échange ne nécessite pas de mémoire virtuelle ; il a été implémenté sur OS/360 sans mémoire virtuelle. Il transfère tous les programmes et données d'un utilisateur entre la mémoire et le disque/tambour et est principalement piloté par les réponses de l'utilisateur aux informations affichées par le système.

Mémoire virtuelle

La mémoire virtuelle est une technique de gestion de la mémoire par laquelle les programmes fonctionnent comme s'ils disposaient de plus de mémoire que ce qui est réellement connecté à l'ordinateur. Le code et les données des programmes en cours d'exécution peuvent être dispersés sur plusieurs zones de la mémoire physique ou même placés sur un disque/tambour jusqu'à ce qu'ils soient nécessaires.

Les principaux composants d'un système de mémoire virtuelle IBM sont :

• Mémoire virtuelle , constituée de toutes les adresses mémoire accessibles par le matériel CPU. La mémoire virtuelle est une abstraction, les systèmes peuvent donc facilement avoir plus de mémoire virtuelle que réelle.
• Pages , blocs de taille fixe dans lesquels toute la mémoire virtuelle est divisée. La plupart des systèmes d'exploitation IBM utilisent des pages de 4 Ko (4 096 octets), bien que certains systèmes plus anciens fonctionnaient assez bien avec des pages de 2 Ko (2 048 octets). Les systèmes IBM System z plus récents prennent également en charge les grandes pages de 1 Mo en plus des pages normales de 4 Ko.
• Mémoire réelle , mémoire vive (RAM) attachée au système informatique.
• Cadres de page , réalisés en divisant toute la mémoire réelle en morceaux égaux à la taille de la page du système. Les pages de mémoire virtuelle doivent être placées dans des cadres de page de mémoire réelle avant de pouvoir être utilisées par l'UC et les canaux d'E/S.
• Les tables de pages suivent l'emplacement de chaque page de mémoire virtuelle, que ce soit dans un cadre de page en mémoire réelle ou sur un disque/tambour, dans un fichier d'échange . Critiques pour la gestion de la mémoire, les entrées de la table des pages enregistrent également la dernière fois que chaque page a été consultée.
• Le matériel de traduction d'adresse dynamique (parfois appelé « boîtier DAT » dans les premiers systèmes en raison de son boîtier séparé) est intégré dans le processeur lui-même et participe à chaque référence de mémoire. Si la table des pages affiche la page dans un cadre de page en mémoire réelle, DAT traduit l'adresse virtuelle en une adresse réelle et permet à l'accès à la mémoire de se terminer. Si, par contre, la page référencée n'est pas en mémoire réelle, le matériel DAT génère une interruption (signal interne) qui appelle le Paging Supervisor à l'action.
• Le superviseur de pagination (partie du système d'exploitation) gère toute la mémoire, à la fois réelle et virtuelle, déplaçant les pages entre la mémoire réelle et le disque/tambour selon les besoins, gardant la table des pages à jour, répondant aux demandes d'allocation de mémoire et nettoyant après lui. À mesure que la charge sur le système augmente, une page peut être référencée lorsque tous les cadres de page sont utilisés. Lorsque cela se produit, le superviseur de la pagination identifie généralement la page qui n'a pas été lue ou écrite pendant le plus long intervalle de temps (la moins récemment utilisée), copie la page dans le fichier de pagination (sur disque ou tambour), met à jour la table des pages , et utilise le cadre de page nouvellement disponible pour satisfaire la demande de mémoire.

Lorsqu'il fonctionne correctement, le système de mémoire virtuelle conserve les pages actives dans la mémoire réelle, les pages inactives sur le disque/tambour, et permet une exécution plus efficace de la charge de travail du système.

Machine virtuelle

Les techniques de machine virtuelle permettent à plusieurs systèmes d'exploitation (systèmes d'exploitation "invités") ou à d'autres logiciels de s'exécuter sur le même ordinateur de sorte que chacun pense avoir un ordinateur entier pour lui-même, et chacun de ces ordinateurs entiers simulés est appelé une "machine virtuelle". Le système d'exploitation qui contrôle réellement l'ordinateur est généralement appelé hyperviseur . Deux des principaux composants de l'hyperviseur sont :

• Gestion de la mémoire virtuelle. Chaque machine virtuelle semble avoir une plage complète d'adresses de 0 à un grand nombre, et les techniques de mémoire virtuelle empêchent différentes machines virtuelles de se confondre.
• Simuler des fonctions « privilégiées » pour le compte des systèmes d'exploitation « invités ». Les fonctions « privilégiées » sont celles qui permettent aux programmes de s'emparer de tout ou au moins de grandes parties de l'ordinateur, et généralement les systèmes d'exploitation mettent immédiatement fin à tout autre programme qui essaie de les utiliser. Mais les systèmes d'exploitation "invités" pensent qu'ils ont le droit d'utiliser ces fonctions, donc l'hyperviseur détecte leurs tentatives de le faire et exécute les fonctions privilégiées en leur nom, en utilisant des techniques de mémoire virtuelle pour les empêcher de corrompre les zones de mémoire utilisées par d'autres "invités" systèmes d'exploitation.

Voir également

• ordinateur central IBM
• Histoire des systèmes d'exploitation
• Chronologie des systèmes d'exploitation

Les références

Lectures complémentaires

• Brooks, Jr., Frederick P. (1975). " L'Homme-Mois Mythique : Essais sur le Génie Logiciel ", Addison-Wesley. ISBN  0-201-00650-2 . (Réimprimé avec des corrections, janvier 1982)
• Systèmes d'exploitation mainframe IBM : chronologie et brève explication pour le système IBM/360 et au-delà , Dave Morton.
• Un wiki dédié aux ordinateurs mainframe IBM