L'ère de l'information a radicalement changé la manière dont nous interagissons avec les systèmes informatiques. À mesure que la quantité de données disponibles augmente, le concept de surcharge informationnelle prend une nouvelle dimension. Face à ce flot d'informations incessant, les serveurs du futur devront intégrer une capacité de filtrage intelligent, permettant de ne présenter à l'utilisateur que l'information nécessaire et pertinente. Cette évolution est d'autant plus importante dans un contexte où l'accès à l'information est de plus en plus universel et instantané, rendant obsolète le modèle traditionnel de travail centré sur les fichiers locaux.

Le réseau, de plus en plus omniprésent, deviendra l'épine dorsale des systèmes. Les systèmes informatiques locaux, limités à un LAN sans connexion à un réseau plus large, risquent de suivre le destin du télétype. Le réseau devient ainsi le système par excellence, et des serveurs de haute performance tels que l'AS/400 joueront un rôle essentiel dans cette nouvelle configuration.

Dans le domaine du développement applicatif, la technologie orientée objet (OO) semble promise à un avenir radieux. Cette technologie a déjà démontré sa capacité à accroître considérablement la productivité des développeurs, et à terme, la majorité des nouvelles applications seront conçues en utilisant des langages orientés objet tels que C++, même si le passage à ces nouvelles méthodes prendra plusieurs années. Le principal défi réside dans la complexité des compétences nécessaires pour maîtriser ces technologies, ce qui engendre un développement à plusieurs niveaux, allant des professionnels spécialisés aux utilisateurs occasionnels utilisant des interfaces intuitives et des outils d'apprentissage autonome.

Les frameworks et composants réutilisables deviendront de plus en plus courants, permettant à des solutions plus petites et plus accessibles de voir le jour. L'adoption des technologies OO s'accélère déjà, et selon les prévisions de l'Object Management Group (OMG), la moitié des entreprises auront intégré ces technologies d'ici 1998, et 80 % d'ici 2000. Bien que le rythme exact de cette adoption soit encore incertain, il semble évident que la direction est tracée pour la majorité du secteur.

Il est crucial de comprendre que cette évolution rapide des technologies modifie profondément les entreprises. Les systèmes informatiques, tout comme les technologies elles-mêmes, sont éphémères. Ce qui est innovant aujourd'hui sera obsolète demain, et l'histoire a montré à maintes reprises à quel point les systèmes informatiques et les entreprises peuvent rapidement devenir dépassés lorsqu'ils s'appuient sur des technologies qui ne répondent plus aux besoins des utilisateurs ou deviennent courantes dans le marché.

Prenons l'exemple des années 1980, où un commerçant choisit d'acheter un système informatique pour son entreprise. À l'époque, les systèmes de bureautique étaient en plein essor, et des entreprises comme Wang, qui ont intégré ces technologies dans leurs solutions, ont rapidement gagné en popularité. Cependant, cette technologie, bien qu'innovante, a été vite surpassée par d'autres systèmes comme les minicomputers, qui se sont adaptés aux besoins commerciaux.

À la fin des années 1980 et au début des années 1990, les entreprises ont commencé à se préoccuper de l'intégration et de la compatibilité de leurs systèmes. L'Unix est devenu le système "ouvert" par excellence, offrant la promesse d'une grande flexibilité et d'une interopérabilité entre différents fournisseurs. Toutefois, à mesure que l'expérience a montré les limitations d'Unix et l'augmentation de ses coûts, des solutions comme le client/serveur, et notamment les serveurs multiprocesseurs PC sous Windows NT, ont gagné en popularité.

Dans les années 1990, le coût et la complexité des systèmes PC ont posé de nouveaux défis. Les entreprises ont alors cherché des solutions plus intégrées, mais à chaque nouvelle évolution technologique, elles ont été confrontées à des coûts imprévus et à la nécessité de renouveler fréquemment leurs équipements pour rester compétitives. Cette situation a conduit au développement de nouvelles solutions, comme les systèmes VR2000, qui, malgré leurs promesses alléchantes, n'ont pas résolu tous les problèmes.

L'histoire des évolutions technologiques montre que, bien que les entreprises cherchent constamment à adopter les dernières innovations, il existe un cycle ininterrompu de changements, souvent coûteux et perturbateurs, qui, à long terme, ne permettent pas de résoudre tous les défis commerciaux. En effet, chaque nouvelle technologie, aussi brillante soit-elle, finit par se heurter à ses propres limites. Les entreprises doivent comprendre que cette quête incessante de la nouveauté, bien qu'essentielle pour rester compétitives, engendre des coûts et des perturbations qui ne sont jamais entièrement compensés par les gains attendus.

Comment la gestion des objets a évolué avec le système OS/400 et MI

Les premières réponses aux demandes d'interaction avec le système ont pris la forme d'API, extrayant des informations sur les objets et les systèmes dans un espace d'utilisateur, un concept qui permettait une lecture plus rapide des programmes que les fichiers de bases de données. Cette approche visait à améliorer l'efficacité de l'accès aux données et à optimiser l'interaction avec le système d'exploitation.

La nomenclature des objets dans les systèmes d'exploitation

Le System/38 a introduit une distinction entre les objets dans le système d'exploitation et ceux dans l'Instruction Set Machine (MI). Deux groupes distincts de personnes au sein de l'organisation de développement étaient responsables de la définition et de la nomination de ces objets. L’un de ces groupes a défini les objets CPF, qui ont été renommés objets OS/400 lors de l'introduction de l'AS/400. L’autre groupe a créé l'ensemble des objets système MI. Une des caractéristiques fascinantes du processus de nomination était la philosophie derrière ces dénominations.

Certains des objets de l'OS/400 ont des correspondances directes avec des objets dans le système MI, mais les noms peuvent différer. Par exemple, dans l'OS/400, il existe un objet appelé « bibliothèque », tandis que dans le système MI, le même objet est appelé « contexte ». Cette différence dans la dénomination découle des pratiques historiques et de la philosophie de chaque groupe de développement. Un groupe, dirigé par Glenn Henry, préconisait une approche de nomination radicale, où chaque nouvel élément du système devait avoir un nom entièrement nouveau, afin d'éviter toute confusion avec les systèmes existants. L'autre groupe, responsable de la dénomination des objets du système d’exploitation, a opté pour une approche plus pragmatique : conserver des noms familiers, même si cela signifiait de petites différences avec les systèmes précédents.

Objets OS/400 et objets système MI : Relations et correspondances

Les objets dans le système OS/400 peuvent avoir une correspondance directe avec ceux du système MI, mais cette relation est loin d’être toujours évidente. Certains objets de l'OS/400 ont une relation un-à-un avec les objets système MI, tandis que d'autres possèdent une correspondance un-à-plusieurs. Par exemple, un fichier de base de données OS/400 peut se composer de plusieurs objets systèmes MI, comprenant des espaces et des indices qui permettent de structurer les données de manière logique et physique.

Les espaces de données dans l'OS/400 sont utilisés pour stocker des informations physiques, accompagnées d'une définition des champs dans les enregistrements. Un indice d'espace de données permet de définir la manière dont les données doivent être vues, tandis qu'un curseur est utilisé pour accéder à ces enregistrements et exploiter ces indices. D’autres objets, comme des buffers d'entrée/sortie ou des espaces dédiés aux fichiers, facilitent les opérations d'entrée et de sortie des données.

La gestion des objets dans le système OS/400 : Bibliothèques et hiérarchies

La gestion des objets dans OS/400 repose largement sur le concept de bibliothèques, qui permettent d’organiser ces objets en groupes. Contrairement aux systèmes à hiérarchie multilevel tels que Unix ou les systèmes PC, les bibliothèques OS/400 suivent une structure hiérarchique simple, à un seul niveau. Cette approche simplifie la recherche des objets, qui se fait en spécifiant à la fois le nom de la bibliothèque et celui de l'objet, complété par le type d'objet. Ainsi, bien que plusieurs objets puissent partager le même nom, leur type d'objet distinct permet de les différencier.

Importance de la cohérence des objets dans la gestion des systèmes complexes

Dans le contexte de systèmes aussi sophistiqués que l'OS/400, il est crucial de comprendre que bien que les noms des objets puissent varier d'un environnement à un autre, chaque objet a un rôle spécifique et souvent plusieurs objets sous-jacents qui interagissent pour maintenir la fonctionnalité du système. Il est important de ne pas se laisser induire en erreur par les noms familiers ou les similitudes apparentes entre les objets de l'OS/400 et les objets système MI. Ce système de dénomination, bien que parfois déroutant, permet en réalité d’éviter les préjugés liés à des noms trop familiers, garantissant ainsi une plus grande flexibilité et une meilleure adaptabilité du système.

Les structures sous-jacentes des objets, notamment les espaces de données et les index, jouent un rôle fondamental dans la gestion des bases de données et la manière dont les informations sont organisées et accessibles. Une compréhension approfondie de cette organisation permet non seulement de mieux gérer les objets mais aussi d’optimiser les processus liés à leur manipulation et leur mise à jour.

En somme, bien que la gestion des objets dans OS/400 et MI puisse sembler complexe à première vue, une fois cette architecture comprise, elle offre une puissante flexibilité dans le traitement et l'organisation des données au sein du système. Le défi consiste à saisir comment ces objets interagissent et comment leur hiérarchisation permet de maintenir l'intégrité et l'efficacité du système.

Comment les fichiers logiques assurent-ils l’indépendance des données et la sécurité dans le système AS/400 ?

Le système AS/400 repose sur une architecture sophistiquée qui sépare les données physiques de leur présentation aux programmes, assurant ainsi une indépendance cruciale entre les données et les applications. Cette indépendance est permise par l’usage conjoint des fichiers physiques et des fichiers logiques. Le fichier physique contient non seulement les données mais aussi leur description, appelée description externe, ce qui permet de stocker les données dans un format défini indépendamment des programmes qui les manipulent. Cette caractéristique, héritée du System/38, permet à un même programme d’opérer sur des fichiers dont les formats physiques diffèrent, évitant ainsi toute rigidité dans la gestion des données.

Le fichier logique, quant à lui, agit comme une vue personnalisée et externe sur les données stockées dans le fichier physique. Il contient essentiellement les numéros relatifs des enregistrements du fichier physique sous-jacent et propose une structure alternative, permettant de masquer certains champs, réordonner les données, ou même modifier le format des champs sans altérer les données originales. Cette abstraction facilite la création de vues spécialisées adaptées aux besoins spécifiques des programmes, tout en maintenant la cohérence et l’intégrité des données. Par exemple, un champ stocké sous forme décimale empaquetée dans le fichier physique peut être présenté au programme comme un champ décimal zoné avec un format différent, grâce à la conversion gérée par le fichier logique.

L’un des avantages majeurs de cette approche est la gestion fine de la sécurité au niveau des champs et des enregistrements. En excluant certains champs du fichier logique, le système impose un contrôle d’accès granulaire : seuls les utilisateurs et programmes autorisés voient les données pertinentes. De plus, la sélection des enregistrements via des critères « select » ou « omit » dans les fichiers logiques permet de limiter l’accès aux sous-ensembles pertinents des données, renforçant ainsi la confidentialité et la protection des informations sensibles.

Dans l’environnement natif, la création d’un fichier logique s’effectue via la commande CRTLF, qui utilise les définitions DDS comme modèle, tandis qu’en SQL, les vues (views) représentent des fichiers logiques définis par la commande CREATE VIEW. Toutefois, les capacités de SQL sont plus limitées : une vue SQL peut réaliser soit un formatage (projection, jointure, dérivation), soit un ordre (index), mais pas les deux simultanément, ni la sélection d’un sous-ensemble d’enregistrements. Cela souligne une différence importante entre les interfaces natives DDS et SQL, qui doit être prise en compte lors du développement d’applications.

Le système AS/400 centralise également toutes les descriptions de fichiers physiques et logiques dans un dictionnaire de données ou catalogue, accessible et mis à jour automatiquement par le gestionnaire de base de données. Cet outil offre une vision exhaustive de la structure et de l’utilisation des données, facilitant ainsi la gestion, la maintenance et l’audit du système.

La coexistence de multiples fichiers logiques sur un même fichier physique permet de proposer différentes vues des mêmes données pour divers programmes, assurant ainsi un partage efficace et sécurisé des informations. Les programmes accèdent toujours aux données actuelles, sans recourir à des copies, ce qui garantit la synchronisation instantanée des mises à jour et évite les conflits d’incohérence. Cette capacité est une pierre angulaire de la conception AS/400 depuis plus de quinze ans.

Il est important de comprendre que la sécurité des données dans l’AS/400 repose non seulement sur la définition des fichiers logiques, mais aussi sur un système d’autorisations rigoureux intégré à l’OS. Seuls les utilisateurs disposant des droits appropriés peuvent accéder aux fichiers physiques ou logiques, ainsi qu’aux chemins d’accès qui en exposent certains champs. La combinaison des fichiers logiques et de la gestion des autorisations forme un mécanisme robuste garantissant la confidentialité, l’intégrité et la disponibilité des données.

La maîtrise de ces concepts est essentielle pour appréhender pleinement la puissance et la flexibilité du modèle de données AS/400, notamment pour concevoir des applications évolutives, sécurisées et performantes. La séparation entre données et programmes, incarnée par les fichiers physiques et logiques, favorise l’adaptabilité et la pérennité des systèmes, tout en simplifiant la gestion des accès et des formats.

Quel rôle stratégique l'AS/400 a-t-il joué dans l’évolution d'IBM et de l'informatique commerciale ?

Rochester, Minnesota, berceau de l'Application System/400 (AS/400) d'IBM, incarne une histoire unique de développement technologique et d'innovation dans le domaine des systèmes informatiques. Lors de son lancement en 1988, l'AS/400 n'était pas simplement un ordinateur, mais une révolution dans le domaine des systèmes multi-utilisateurs. Avec une interface conviviale et une robustesse inégalée, il a rapidement conquis les entreprises et est devenu un pilier de l'informatique commerciale mondiale.

Le chemin qui a mené à la création de ce système remonte à bien avant son introduction. Dans les années 1960, Rochester était encore un centre émergent d'innovation technologique, mais son impact n'était pas encore mondialement reconnu. Ce n'est qu'à la fin des années 1960 que des chercheurs et ingénieurs de l'entreprise commencèrent à formuler des idées radicales qui allaient un jour transformer la façon dont les ordinateurs étaient perçus dans le monde des affaires. L'un de ces projets initiaux fut la création du système IBM System/3, qui allait poser les bases du développement de l'AS/400.

Le passage du System/3 au système plus avancé qu'allait devenir l'AS/400 ne fut pas immédiat. En 1970, un projet révolutionnaire fut présenté : une architecture de machine qui promettait de protéger les investissements des clients en logiciels d'applications en les rendant indépendants des technologies matérielles sous-jacentes. Ce projet marqua un tournant dans la manière dont les architectures informatiques étaient conçues, et amorça un chemin qui allait conduire à la création du System/38, puis de l'AS/400.

Le System/38, bien que novateur, rencontra des difficultés en raison de ses performances et de son coût. Nombre de ses utilisateurs potentiels ne comprenaient pas pleinement son potentiel, et les premiers retours furent mitigés. Cependant, une base fidèle d’utilisateurs reconnut la puissance et la flexibilité de ce système, le qualifiant d’innovant malgré ses faiblesses initiales. Il fallut attendre le début des années 1980 pour que l'idée de converger les différents systèmes d'IBM en un seul produit, l’AS/400, devienne une priorité stratégique.

Le développement de l'AS/400 ne se fit pas sans défis. La tentative d'IBM dans les années 1980 de créer un "système convergé", connu sous le nom de Fort Knox, échoua, malgré des investissements massifs dans plusieurs laboratoires. Ce projet visait à remplacer cinq systèmes incompatibles par un système unique. Cependant, la complexité du projet, sa gestion à travers plusieurs laboratoires et son approche trop centrée sur les besoins internes d'IBM, plutôt que sur ceux des clients, en firent un échec.

Malgré ces obstacles, l’AS/400 continua d’évoluer et de gagner en importance, non seulement en tant que système robuste pour les entreprises, mais aussi en tant que symbole de la capacité d’IBM à innover et à s’adapter aux besoins croissants du marché. L'AS/400, dans sa version finale, devint plus qu’un simple produit informatique ; il incarna une plateforme stratégique qui permettait aux entreprises de transformer leurs opérations informatiques et de se projeter vers l'avenir. Ce système, qui devait assurer la pérennité des investissements en logiciels des entreprises, se retrouva au cœur de nombreuses stratégies d'entreprise, faisant d'IBM un acteur incontournable de l'informatique commerciale.

Le véritable succès de l'AS/400 réside non seulement dans sa conception technique, mais aussi dans sa capacité à répondre aux besoins des utilisateurs tout en évoluant au fil des années. Son adoption massive par des entreprises de toutes tailles témoigne de la pertinence de la vision d'IBM pour l'avenir de l'informatique. Cette réussite est également un exemple frappant de la manière dont un projet ambitieux peut s’imposer même après des débuts difficiles, si l'on parvient à s’adapter aux besoins réels des utilisateurs tout en restant fidèle à une vision stratégique.

Au-delà de l’aspect technique, l’AS/400 doit être compris comme un témoignage de la culture de l’innovation chez IBM et de son impact sur l’évolution du secteur informatique. Chaque étape de son développement, de l’échec du Fort Knox à la réussite de l’AS/400, reflète les défis et les triomphes inhérents à toute grande révolution technologique. Il est essentiel pour les professionnels de comprendre que, derrière cette réussite, se cachent des années de recherche, de tests et d’adaptation aux exigences du marché.

Comment gérer les espaces mémoire et les adresses virtuelles dans les systèmes informatiques : une exploration des pointeurs et des secteurs

Dans le processus de gestion de la mémoire, l’un des défis majeurs consiste à optimiser l’utilisation de l’espace de stockage tout en garantissant une récupération efficace des données. Prenons l’exemple des systèmes comme le System/38 et l'AS/400, où chaque disque est constitué de plateaux magnétique, chaque plateau ayant deux surfaces enregistrables. Chaque surface est ensuite divisée en cercles concentriques appelés pistes, chaque piste étant elle-même divisée en secteurs. Ces secteurs contiennent les informations nécessaires à la gestion de la mémoire.

Le System/38 a été conçu avec un secteur de disque de 520 octets. Ce secteur se compose d’un en-tête de 8 octets et d’une zone de données de 512 octets. La taille du secteur a été choisie pour correspondre à la taille de la page mémoire de 512 octets du System/38, de sorte qu’une page complète pouvait être stockée dans un seul secteur. Ce choix n'était pas anodin, car il facilitait la gestion des données en mémoire et sur disque. Lorsque des données étaient écrites sur disque, elles étaient accompagnées de « tags » (étiquettes), des bits d'information cruciaux pour la gestion des adresses virtuelles des pages mémoire.

Les "tags" étaient gérés grâce à des instructions spécifiques (IMPI), telles que "Extract Tags" et "Insert Tags". Ces instructions permettaient de manipuler les étiquettes directement en mémoire, en les extrayant lors de l'écriture d'une page en disque et en les réintégrant lors de la lecture de la page depuis le disque. Cependant, une fausse hypothèse répandue parmi les utilisateurs et les développeurs était que ces tags étaient stockés dans l’en-tête des secteurs, ce qui n’était pas le cas. Les informations relatives à la page étaient stockées dans la zone de données de 512 octets du secteur, tandis que l'en-tête contenait principalement l'adresse virtuelle de la page. Cette adresse virtuelle était essentielle pour la récupération en cas de perte de la table en mémoire qui associait les adresses virtuelles aux positions des données sur disque. La connaissance de l’adresse virtuelle dans l’en-tête du secteur permettait ainsi de reconstruire cette table.

En raison de la limitation de l’espace dans l’en-tête (64 bits par secteur), il n'était pas possible de stocker directement les 32 bits d'étiquette par page dans cet espace. Il devenait donc nécessaire de trouver d’autres solutions. L’une de ces solutions a été l’utilisation de l’espace inutilisé dans les pointeurs, ces unités de données de 16 octets servant à accéder aux objets dans le système. Un pointeur résolu était divisé en deux parties : la première contenant des informations de statut (par exemple, si le pointeur correspond à un objet système ou utilisateur) et la deuxième contenant l’adresse virtuelle de l’objet dans le système de stockage à un seul niveau (Single-Level Store). La première partie du pointeur n’utilisait que 4 octets, laissant ainsi 4 octets non utilisés, espace que l’on a pu allouer pour stocker les tags. Ce détail a permis une utilisation plus efficace de l’espace mémoire, en particulier pour les pages qui contiennent au moins un pointeur, car ces pages ont un espace inutilisé suffisant pour stocker les bits d’étiquette.

L’évolution des systèmes, notamment avec l’introduction de l’AS/400 et des processeurs RISC, a permis de repenser la taille des pages. Au lieu de maintenir la taille de page de 512 octets, jugée trop petite pour les nouvelles architectures de mémoire plus grandes, la taille des pages a été augmentée à 4 Ko, soit 4096 octets. Cela a entraîné un besoin de repenser la gestion des secteurs, mais l'idée de stocker les tags dans des endroits stratégiques du système est restée valable. Dans cette nouvelle configuration, une page de 4 Ko est répartie sur huit secteurs, offrant ainsi suffisamment de place pour gérer les bits d'étiquette associés à cette page.

Avec l’augmentation des tailles de mémoire, l’AS/400 a évolué pour intégrer des registres spéciaux dans les processeurs PowerPC, permettant d'extraire les tags directement depuis la mémoire. Cette nouvelle fonctionnalité, qui repose sur des instructions spécifiques comme "Load Multiple Doubleword" (Imd), permet de charger jusqu'à 16 double-mots dans les registres, facilitant ainsi la gestion des tags dans les pages mémoire plus grandes.

Un autre aspect important à noter est l’évolution des pointeurs dans le système. Un pointeur résolu décrit à la fois l’objet auquel il fait référence, le type de l’objet (système, données, instruction, etc.) et les droits d’accès de l’utilisateur à cet objet. Ces pointeurs ont une structure bien définie, avec la possibilité d'étendre l’espace d'adresse à 96 bits, grâce aux espaces non utilisés dans la première partie du pointeur. Cette flexibilité permet au système de gérer une plus grande quantité de mémoire sans nécessiter de modifications majeures dans les programmes, ce qui est crucial pour l’évolution des systèmes sur le long terme.

Ainsi, l'optimisation de l'espace mémoire et la gestion des adresses virtuelles, qu'elles soient en 48 ou 64 bits, sont des éléments centraux dans l’architecture des systèmes comme le System/38 et l’AS/400. La gestion efficace des pointeurs, des tags et des secteurs est primordiale pour garantir une utilisation optimale des ressources du système et un accès rapide et fiable aux données.