Qu'est-ce qui rend l'AS/400 unique ? Un examen approfondi de son architecture et de son histoire

L'AS/400, aujourd'hui connu sous le nom d'IBM iSeries, a été une révolution technologique dans le domaine des systèmes informatiques depuis son introduction en 1988. Conçu pour répondre aux besoins des entreprises, il a réussi à allier simplicité et puissance, devenant un incontournable pour de nombreuses entreprises du monde entier. Mais qu'est-ce qui rend ce système vraiment unique, et pourquoi a-t-il connu un tel succès ? Cet article explore les aspects clés de son design, de son architecture et de son évolution à travers les années.

Le cœur de l'AS/400 réside dans sa capacité à intégrer différents systèmes et technologies dans une seule machine. Ce système n'est pas simplement un serveur : c'est une plateforme tout-en-un qui combine un environnement d'exécution, un système de gestion de bases de données, une interface utilisateur, et bien plus encore. Le système repose sur une architecture unifiée où tout est conçu pour fonctionner ensemble de manière transparente. L'AS/400 est ainsi une machine "technologiquement indépendante", capable de supporter différentes applications et langages sans nécessiter une refonte totale de l'infrastructure.

La base de données intégrée, l'Object Database (ou DB2/400), est un autre pilier central de l'AS/400. Contrairement aux autres systèmes de l'époque, où la gestion des bases de données était souvent une tâche complexe nécessitant une solution séparée, l'AS/400 a intégré directement un puissant système de gestion de bases de données. Cela a simplifié la gestion des données et a permis de garantir l'intégrité et la sécurité des informations, ce qui est crucial dans un environnement commercial.

En matière de sécurité, l'AS/400 a toujours été un modèle de fiabilité. Son système d'autorisation très détaillé et flexible permet aux administrateurs de contrôler l'accès à chaque aspect du système, du niveau le plus bas au plus élevé. Ce contrôle granulaire est essentiel dans les environnements d'entreprise où la protection des données et des ressources est primordiale.

Dans un monde où le travail en réseau est devenu la norme, l'AS/400 a également su se réinventer avec l'essor du client-serveur. Il a permis aux entreprises d'intégrer des solutions de type client-serveur tout en conservant sa robustesse et sa simplicité d'utilisation. Cette transition vers le client-serveur a été facilitée par l'architecture ouverte de l'AS/400, qui offrait des options de communication avec d'autres systèmes.

L'un des plus grands défis rencontrés par l'AS/400 a été sa transition vers des processeurs PowerPC RISC dans les années 1990. Cette évolution a permis à la machine de conserver sa compétitivité en matière de performance tout en maintenant son caractère unique. Les modifications apportées à l'architecture interne du système, tout en intégrant ces nouveaux processeurs, ont nécessité une grande révision du code et une mise à jour majeure des compétences des développeurs.

Le système a toujours été soutenu par une équipe dévouée d'ingénieurs et de créateurs, dont certains ont été les architectes mêmes de l'AS/400, comme Frank G. Soltis, l'un des pionniers du projet. Le livre "Inside the AS/400" écrit par Soltis offre un regard détaillé sur l'évolution de ce système et les défis qui ont été relevés par l'équipe de Rochester. Ce n'est pas simplement un

Comment assurer l'intégrité et la disponibilité des bases de données sur AS/400 : Le rôle des déclencheurs et de l'intégrité référentielle

L'intégrité des données dans un système de gestion de base de données est essentielle pour garantir leur exactitude, leur cohérence et leur fiabilité. Dans un environnement comme celui de l'AS/400, des mécanismes puissants et sophistiqués permettent de gérer ces aspects de manière transparente. L'un des éléments clés pour assurer cette intégrité est l'utilisation des déclencheurs (triggers), de l'intégrité référentielle et des systèmes de disques à haute disponibilité. Ces outils permettent de maintenir un fonctionnement fluide même en cas de pannes matérielles ou d’erreurs humaines. Examinons ces concepts plus en détail.

Les déclencheurs (ou triggers) sont des mécanismes permettant d'exécuter automatiquement des actions en réponse à des changements dans une base de données. Chaque fois qu'une modification est apportée à un fichier physique — comme l'ajout, la mise à jour ou la suppression d'un enregistrement — un déclencheur peut être activé. Cela permet d'assurer que les actions nécessaires soient prises sans intervention manuelle, garantissant ainsi une intégrité dynamique des données.

Un autre mécanisme essentiel pour garantir la qualité des données dans les bases de données est l'intégrité référentielle. Celle-ci fait référence à la capacité du système à maintenir des relations logiques entre les données présentes dans différentes tables ou fichiers. Si une modification dans un fichier est effectuée sans prendre en compte l'impact sur les autres fichiers liés, cela pourrait entraîner une incohérence des données. C’est ici qu’intervient l’intégrité référentielle : elle empêche, par exemple, l’ajout d’une référence dans un fichier secondaire si celle-ci ne correspond pas à une entrée existante dans le fichier maître.

Prenons l'exemple d'un fichier de clients où chaque enregistrement contient un identifiant unique. Si ce client est référencé dans d'autres fichiers, il est important qu'aucun programme ne puisse ajouter un identifiant de client dans un fichier secondaire sans que celui-ci existe d'abord dans le fichier principal. Cela garantit que toutes les relations entre les fichiers sont valides, prévenant ainsi les incohérences.

Une alternative moins coûteuse mais efficace est l’utilisation des matrices de disques, ou RAID. Dans cette configuration, les données sont réparties sur plusieurs disques, et un disque supplémentaire peut être ajouté pour offrir une redondance. Si un disque tombe en panne, les données peuvent être récupérées à l'aide d'une opération XOR (ou "exclusive OR"), qui permet de reconstruire les données manquantes à partir des autres disques du groupe. Cette méthode, bien qu’efficace, repose sur des calculs complexes et nécessite une gestion soignée des disques pour éviter une surcharge sur un disque unique.

En résumé, la combinaison des déclencheurs, de l'intégrité référentielle et des systèmes de stockage à haute disponibilité garantit que les bases de données sur AS/400 peuvent maintenir leur fiabilité, leur cohérence et leur performance, même en cas de défaillance matérielle ou de modifications complexes des données.

Il est essentiel de comprendre que ces technologies ne sont pas simplement des solutions ponctuelles, mais font partie d'un écosystème global qui doit être régulièrement surveillé et maintenu. Les stratégies de sauvegarde et de récupération, la gestion proactive des disques et la surveillance des déclencheurs doivent faire partie intégrante de la gestion quotidienne d’une base de données. Ces éléments interagissent pour offrir une résilience maximale face aux divers défis que peuvent rencontrer les systèmes d'information.

Comment la gestion des autorisations dans un système multi-utilisateur assure-t-elle la sécurité et la flexibilité dans un environnement informatique ?

Dans les systèmes multi-utilisateurs, la gestion des autorisations et de la sécurité est essentielle pour garantir l'intégrité et la confidentialité des données, ainsi que pour assurer que seuls les utilisateurs autorisés puissent accéder à certaines ressources ou effectuer des actions spécifiques. L'une des approches utilisées pour faciliter cette gestion est l’utilisation des listes d'autorisations et des profils de groupe, permettant d’assigner des autorisations à plusieurs utilisateurs ou objets en même temps.

Les profils de groupe permettent, eux aussi, de simplifier la gestion des autorisations. Un groupe, tel qu’un département dans une entreprise, peut se voir attribuer des droits communs, tout en permettant à chaque utilisateur individuel de posséder un profil personnel. Ce profil personnel peut alors prévaloir sur les droits généraux accordés au groupe, offrant une flexibilité supplémentaire pour gérer des cas particuliers au sein de l'organisation. Par exemple, si un membre du groupe nécessite un accès plus limité ou plus étendu qu'un autre, ces ajustements peuvent être facilement réalisés sans affecter les autres membres du groupe.

L'environnement System/36, en particulier, a introduit des concepts innovants, comme la possibilité de donner une autorisation à un fichier inexistant. Cela permet à une application de System/36 de garantir l'accès à des fichiers même avant leur création effective, ce qui est particulièrement utile dans des systèmes où les fichiers sont créés dynamiquement. En revanche, dans le système System/38, une telle approche n’était pas possible, ce qui limitait la flexibilité des processus d’autorisation. Une fois qu'un fichier était supprimé dans le System/38, toutes les traces d'autorisations étaient également effacées, ce qui n'était pas le cas dans l'environnement System/36 où l’autorisation pouvait perdurer au-delà de la suppression du fichier.

L'algorithme de recherche des autorisations commence par vérifier les droits du profil utilisateur individuel. Si aucune autorisation n'est trouvée à ce niveau, le système passe alors à la recherche dans le profil du groupe de l'utilisateur. Si aucune autorisation n'est trouvée dans ce profil non plus, c'est l'autorisation publique qui est alors recherchée. Ce processus est essentiel pour que l'accès à l'objet soit sécurisé et pour s'assurer que les droits d'un utilisateur sont respectés tout en permettant une flexibilité dans la gestion des accès.

Ce système de gestion des autorisations repose sur une hiérarchie rigide et permet d'établir des droits d’accès personnalisés pour chaque utilisateur ou groupe. Il assure que l'accès aux objets se fait de manière cohérente, tout en offrant suffisamment de flexibilité pour répondre à des besoins spécifiques, tels que les ajustements de sécurité à un niveau granulaire. Cette approche joue un rôle crucial dans la sécurité des systèmes complexes, comme l’AS/400, et répond aux besoins croissants de gestion des autorisations dans un monde de plus en plus connecté.

Il est également important de comprendre que ces systèmes de gestion des autorisations ne sont pas statiques. À mesure que les exigences de sécurité évoluent, de nouvelles fonctionnalités peuvent être ajoutées pour répondre à des besoins spécifiques, sans perturber l'intégrité du système existant. La sécurité d'un système multi-utilisateur ne réside pas uniquement dans les mécanismes d’autorisation en place, mais aussi dans la capacité à adapter et à renforcer ces mécanismes en fonction des nouvelles menaces et exigences.

Ainsi, bien que l'on parle souvent de sécurité en termes d'accès aux données et aux objets, la flexibilité du système de gestion des autorisations doit être prise en compte pour assurer que les ressources du système soient protégées tout en permettant des ajustements faciles et non disruptifs. Les autorisations doivent être gérées de manière dynamique pour répondre aux besoins des utilisateurs, des groupes et des applications, tout en maintenant la sécurité globale du système.

Comment les interruptions, exceptions et événements sont gérés au niveau du MI ?

Les programmes et processus exécutés au niveau du MI (Machine Interface) ne connaissent pas les interruptions au niveau matériel. Cependant, lorsqu'une interruption se produit en raison de l'exécution d'un programme MI, elle doit être signalée au niveau du MI. C'est le rôle du SLIC (System-Level Interrupt Controller) de détecter, traiter et signaler ces interruptions au MI.

Prenons quelques exemples pour mieux comprendre ces concepts. Supposons qu'un programme tente de diviser un nombre par zéro, ce qui est une erreur évidente. Cette erreur sera signalée comme une exception lorsqu'elle sera détectée lors de l'exécution de l'instruction de division. Elle est synchrone, car la même erreur se produira au même endroit du programme chaque fois qu'il sera exécuté, sous réserve que les valeurs des données restent constantes. En revanche, si une opération d'E/S, telle que la lecture d'un enregistrement depuis un disque, est en cours d'exécution pendant l'exécution de notre programme, un événement se produira lorsque cette opération d'E/S sera terminée. L'achèvement de l'opération d'E/S est un événement asynchrone, car il n'est pas lié à l'exécution du programme en cours, et peut se produire à tout moment.

Les exceptions peuvent être de deux types au MI : erreurs et conditions définies par l'utilisateur. De la même manière, les événements sont divisés en deux catégories : les événements liés à l'objet, comme le fait d'atteindre une limite de messages dans une file d'attente, et les événements liés à la machine, comme l'écoulement d'un intervalle de temps spécifié. Un processus MI peut surveiller un ensemble d'événements et prendre des mesures en fonction de certains ou de tous ces événements.

L'introduction des modèles de programmes et de processus ILE (Integrated Language Environment) a entraîné certains changements dans la gestion des exceptions. Dorénavant, une exception au niveau du MI est un message de processus formellement structuré. Tous les messages de processus sont conservés dans l'espace de la file d'attente de processus, qui fait partie de la structure du processus ILE. En raison de cette gestion par message, un délai est possible entre la signalisation et le traitement de l'exception. Cependant, la gestion des exceptions dans les modèles ILE reste semblable à celle des modèles originaux.

Le SLIC prend en charge à la fois la surveillance et la gestion des événements et des exceptions. Nous avons vu dans le chapitre précédent que l'accès aux objets système est surveillé par la machine. Cette fonctionnalité, couplée à certaines instructions spéciales insérées dans le flux d'instructions PowerPC, permet d'accomplir la plupart des fonctions de surveillance des événements. La gestion des exceptions, quant à elle, est en grande partie assurée par le matériel et signalée aux routines de gestion des exceptions du SLIC via le mécanisme d'interruptions PowerPC.

Le SLIC prend en charge un grand nombre d'interruptions, dont certaines sont causées par l'exécution d'une instruction et d'autres par des événements système. L'architecture PowerPC définit un total de 15 types d'interruptions. Cinq d'entre elles sont causées par le système :

1. Réinitialisation système — cette interruption se produit à chaque fois que le système est réinitialisé ou mis sous tension.

2. Contrôle machine — cette interruption signale un dysfonctionnement matériel.

3. Interruption externe — cette interruption avertit le processeur qu'un événement externe (par exemple, une opération d'E/S) nécessite son attention.

4. Moniteur de performance — cette interruption signale qu'un événement surveillé s'est produit, si la fonction de surveillance de la performance est activée.

5. Décrémenter — utilisée pour les fonctions de minuterie, cette interruption signale l'écoulement d'un intervalle de temps.

Les interruptions causées par l'exécution d'instructions incluent :

1. Stockage de données — cette interruption signale que l'instruction tente un accès à la mémoire qui ne peut être effectué.

2. Stockage d'instructions — similaire à l'interruption de stockage de données, mais elle se produit lorsqu'une tentative est faite pour récupérer la prochaine instruction.

3. Erreur de stockage direct — cette interruption se produit lors d'un accès à une adresse de stockage direct.

4. Alignement — cette interruption se déclenche lorsqu'une tentative d'accès à un opérande mal aligné sur une frontière mémoire a lieu.

5. Programme — utilisée pour signaler des tentatives d'exécution d'instructions privilégiées sans autorisation ou des tentatives d'exécution d'un op-code invalide.

La gestion des exceptions au niveau du SLIC repose principalement sur des fonctions de routage. Le mécanisme d'interruptions PowerPC initie cette fonction de routage chaque fois qu'une interruption matérielle est détectée. Une fois l'exception survenue, tous les gestionnaires d'exception du SLIC reçoivent l'opportunité de traiter l'exception. Si l'exception est prise en charge, le processus continue comme si rien ne s'était passé. Si elle n'est pas traitée dans le SLIC, le processus est terminé et l'exception est transmise au gestionnaire d'exception approprié dans le modèle ILE.

La gestion des interruptions est cruciale pour assurer la stabilité et la performance des systèmes informatiques modernes, particulièrement dans un environnement complexe où les événements externes et internes peuvent interférer avec les processus en cours d'exécution. Le contrôle précis de ces événements permet aux systèmes d'être plus réactifs et résistants aux erreurs, garantissant ainsi une expérience utilisateur optimale.

Comment le processeur gère-t-il les interruptions et les changements de contexte ?

Lorsqu'un matériel détecte une interruption, le contrôle est transféré à l'un des premiers gestionnaires d'exceptions de niveau (FLEH). Ces gestionnaires prennent en charge la majorité des exceptions courantes. Si une de ces routines prend en charge l'exception, le contrôle est retourné au traitement normal des instructions. Si l'exception est causée par une instruction et n'a pas été gérée, le FLEH transmet le contrôle au gestionnaire d'exceptions de niveau supérieur (SLEH).

Le SLEH peut gérer certaines exceptions moins fréquentes mais néanmoins attendues, telles qu'une exception de verrouillage d'un objet système. Il est également responsable du tri des exceptions qui ne peuvent pas être gérées dans le SLIC. Si l'exception non traitée s'est produite lors de l'exécution d'une instruction traduite depuis le MI, le SLEH passe le contrôle au générateur d'exception MI. Si l'exception s'est produite lors de l'exécution d'une instruction SLIC, le contrôle est transféré au gestionnaire d'exceptions de troisième niveau (TLEH).

Les CSEH, définis par les composants du SLIC, sont responsables de libérer les ressources acquises pendant une opération, de nettoyer les résultats partiels d'une opération échouée ou de tolérer une défaillance dans une séquence de code particulière. Les CSEH sont activés par le TLEH. Les blocs CSEH à exécuter pour une tâche particulière sont déterminés par les blocs CSEH liés au TDE de la tâche. Chaque bloc CSEH contient l'adresse de la routine CSEH, le pointeur de pile du définisseur et toutes les données nécessaires à l'exécution de la routine. Une fois tous les CSEH exécutés, le contrôle est restitué au TLEH.

Le générateur d'exception MI prépare les données pour le message du processus, effectue certaines opérations de nettoyage, puis envoie le message à l'espace de file d'attente du processus MI approprié.

Changement de contexte matériel

Étant donné que les routines d'exception décrites peuvent avoir besoin d'accéder à des instructions privilégiées au niveau du PowerPC, le mécanisme d'interruption doit être capable de changer l'état du processeur lorsque le contrôle est transféré à l'une de ces routines. Ce processus est généralement décrit comme un changement de contexte du processeur. Le contexte est défini comme l'état du processeur en ce qui concerne les privilèges, la relocalisation, la protection de la mémoire, le mode 64 bits, la sécurité C2, etc.

En plus du simple changement de contexte, le mécanisme d'interruption doit effectuer une synchronisation du contexte. Cela signifie que le matériel du processeur doit garantir que toutes les instructions lancées avant l'interruption seront exécutées dans le contexte dans lequel elles ont été initiées. Ensuite, le matériel s'assure que les instructions suivantes seront récupérées et exécutées dans le contexte établi par l'opération.

Dans le chapitre précédent, nous avons étudié le registre d'état de la machine (MSR) et la signification de certains des bits de ce registre. L'architecture PowerPC du MSR définit plusieurs autres bits, dont certains ont été décrits dans la section précédente. Ce qui est important à comprendre, c'est que les réglages de tous les bits du MSR déterminent le contexte du processeur. L'état de ces bits peut être modifié lorsqu'une interruption du processeur se produit.

L'instruction d'appel système (sc) peut être utilisée pour appeler une routine SLIC lorsqu'il est nécessaire de changer le contexte du processeur. Cette instruction peut être utilisée dans des programmes MI traduits pour invoquer la partie SLIC du système d'exploitation et effectuer un service. Comme nous l'avons vu, lorsque l'instruction sc est exécutée par le processeur, une interruption d'appel système est générée. Les lecteurs familiers avec l'architecture S/370 reconnaîtront probablement que l'instruction sc dans l'architecture PowerPC ressemble beaucoup à l'instruction Supervisor Call (SVC) de l'architecture S/370. L'exécution de l'une ou l'autre de ces instructions provoque une interruption.

Processus d'interruption dans PowerPC

Lorsque n'importe quelle interruption se produit, le matériel du processeur PowerPC effectue d'abord une synchronisation du contexte pour s'assurer que l'opération de traitement de l'interruption ne commence que lorsque toutes les instructions en cours d'exécution auront été exécutées et auront signalé toutes les exceptions qu'elles causeraient. Il est à noter que chaque interruption a une priorité, de sorte que si plusieurs interruptions sont en attente, la plus haute priorité est sélectionnée en premier.

L'adresse effective de l'instruction qui était en cours d'exécution lorsque l'interruption s'est produite est ensuite enregistrée dans un registre spécial de 64 bits, appelé le registre Machine Status Save/Restore Register 0 (SRR 0). Dans le cas d'une interruption d'appel système, l'adresse effective de l'instruction suivant l'instruction sc est stockée dans SRR 0. Ensuite, certains bits du MSR actuel sont enregistrés dans un autre registre spécial de 64 bits, appelé le registre Machine Status Save/Restore Register 1 (SRR 1). Enfin, d'autres bits dans SRR 1 sont chargés avec des informations spécifiques au type d'interruption survenue.

Le résultat du traitement matériel des interruptions décrit ci-dessus est de transférer le contrôle vers la première instruction de l'une des routines de gestion des interruptions SLIC. Le contexte du processeur a également été changé avant que cette routine prenne le contrôle, ce qui permet, par exemple, d'exécuter des instructions privilégiées dans cette routine.