L’univers des serveurs professionnels peut sembler complexe, notamment lorsqu’il s’agit de technologies ayant évolué sur plusieurs décennies. Le serveur iSeries, désormais connu sous l’appellation IBM i, représente une plateforme robuste qui a su traverser les époques en s’adaptant aux besoins changeants des entreprises. Héritier direct de l’AS/400, ce système combine puissance, fiabilité et une architecture unique qui continue de surprendre ceux qui s’y aventurent pour la première fois.
Démarrer avec un serveur iSeries nécessite de comprendre une philosophie différente des environnements Windows ou Linux traditionnels. La gestion par objets, les librairies, les sous-systèmes et l’absence de système de fichiers classique déroutent souvent les nouveaux venus. Pourtant, une fois les concepts de base assimilés, cette plateforme révèle une cohérence remarquable et une stabilité à toute épreuve. Les entreprises qui maintiennent ces systèmes en production apprécient particulièrement leur capacité à gérer des charges critiques sans défaillance.
La courbe d’apprentissage peut paraître intimidante, surtout pour ceux habitués aux interfaces graphiques modernes. L’écran vert 5250, les commandes cryptiques et la navigation par menus spécifiques constituent autant de barrières initiales. Mais derrière cette apparence austère se cache un système d’exploitation extrêmement structuré, où chaque élément répond à une logique précise. Comprendre cette logique transforme rapidement l’appréhension en maîtrise.
En bref :
- Le serveur iSeries (IBM i) descend directement de l’AS/400 et maintient une compatibilité exceptionnelle avec les anciennes versions
- La connexion initiale nécessite soit un terminal Twinax soit une configuration réseau via émulateur 5250
- Le système repose sur une architecture par objets et librairies, radicalement différente des systèmes de fichiers traditionnels
- L’administration passe par des commandes CL spécifiques et des outils comme SST ou Navigator for i
- La sécurité s’articule autour de profils utilisateurs distincts entre le système et les outils de service
Comprendre l’architecture et les concepts fondamentaux du serveur iSeries
L’architecture du serveur iSeries repose sur une approche orientée objet qui se distingue fondamentalement des systèmes Unix ou Windows. Chaque élément du système, qu’il s’agisse d’un programme, d’un fichier de données ou d’une configuration, est traité comme un objet possédant des attributs spécifiques.
Un objet dans l’environnement IBM i combine toujours deux dimensions : ses attributs (nom, type, taille, date de création) et ses données proprement dites.
Les librairies constituent le niveau d’organisation primaire. Une librairie (*LIB) fonctionne comme un conteneur référençant les objets et leurs métadonnées. Contrairement à un répertoire classique, elle impose une règle stricte : deux objets de même type ne peuvent porter un nom identique au sein d’une même librairie. Cette contrainte garantit une identification sans ambiguïté.
Toutes les librairies sont elles-mêmes rattachées à la librairie système QSYS, qui forme la racine de l’arborescence. Les fichiers de données s’organisent en membres, permettant de regrouper plusieurs ensembles de données sous un même nom de fichier. Par exemple, le fichier TEMPLATE peut contenir plusieurs membres comme UANTEUPROC, chacun représentant une variation ou version spécifique.
| Concept | Description | Équivalent approximatif |
|---|---|---|
| Librairie (*LIB) | Conteneur d’objets avec référencement strict | Répertoire (mais avec typage) |
| Objet | Entité système avec type et attributs | Fichier ou programme |
| Membre | Sous-ensemble de données dans un fichier | Partition de table |
| Sous-système | Environnement d’exécution isolé | Processus ou service |
Les sous-systèmes représentent un autre pilier de l’architecture. Ils fonctionnent comme des environnements d’exécution indépendants, comparables à des processus Unix, mais avec une gestion plus structurée. Un sous-système père peut contrôler plusieurs sous-systèmes fils, créant une hiérarchie permettant un arrêt ou démarrage en cascade.
Navigation dans l’environnement par librairies en ligne
Le concept de librairies en ligne équivaut à la variable PATH des systèmes Unix. Seules les librairies déclarées « en ligne » permettent l’exécution directe de programmes sans spécifier explicitement leur emplacement. Par défaut, QGPL et QTEMP figurent dans cette liste restreinte.
L’ordre des librairies en ligne revêt une importance capitale. Lorsque plusieurs programmes portent le même nom dans différentes librairies, le système exécute systématiquement la première occurrence rencontrée dans la liste. Cette logique peut causer des comportements inattendus si l’ordre n’est pas maîtrisé.
La commande WRKLIBL permet de visualiser et modifier la liste des librairies en ligne, assurant que les bons programmes sont appelés dans le bon ordre.
L’ajout d’une librairie en ligne s’effectue via ADDLIBLE, avec possibilité de spécifier sa position dans la séquence. Cette manipulation reste temporaire pour la session en cours, à moins d’être intégrée dans les profils de démarrage ou les programmes d’initialisation.
Établir la première connexion au serveur iSeries
La connexion initiale à un serveur iSeries représente souvent le premier obstacle technique. Les modèles anciens comme le 9406-170 nécessitaient historiquement une console Twinax, interface propriétaire IBM utilisant des terminaux dédiés. Cette technologie spécifique impliquait un contrôleur Twinax, un câble coaxial particulier et un terminal compatible.
Le code erreur A6005004 signale précisément l’absence de console Twinax lors d’un démarrage en mode manuel. Ce message bloque le processus d’IPL tant qu’une console valide n’est pas détectée. Deux solutions s’offrent alors : obtenir le matériel Twinax d’origine ou configurer une console réseau via émulation 5250.
La configuration réseau moderne s’appuie sur l’émulation de terminal 5250 via TCP/IP. Cette approche élimine le besoin de matériel propriétaire en exploitant les capacités réseau standard du serveur. Les émulateurs comme TN400, IBM Client Access ou iAccess Client Solution permettent d’établir une session interactive depuis n’importe quel PC connecté.
La configuration réseau exige de connaître l’adresse IP attribuée au serveur. Dans certains cas, notamment après acquisition d’occasion, cette information n’est pas immédiatement disponible. Un test ping depuis un PC connecté au même réseau permet de vérifier la présence et l’accessibilité du serveur.
- Vérifier le câblage réseau entre le serveur et le réseau local (switch ou routeur)
- Confirmer que les voyants réseau du serveur indiquent une connexion active
- S’assurer que le masque de sous-réseau du PC correspond au réseau du serveur
- Tester la connectivité avec une commande ping vers l’IP du serveur
- Configurer l’émulateur 5250 avec l’IP identifiée et le port approprié
Les connecteurs Ethernet des serveurs iSeries détectent automatiquement le type de câble (droit ou croisé) et s’y adaptent. Cette fonction Auto-MDIX simplifie le câblage, même pour une connexion directe PC-serveur, bien qu’un switch intermédiaire reste recommandé pour plus de stabilité.
Le conseil d’Alexandre : Avant de chercher à résoudre des problèmes complexes de connexion, testez toujours un simple ping. Ce diagnostic basique révèle immédiatement si le problème est réseau ou système.
Gérer les différents modes d’IPL pour contrôler le démarrage
L’IPL (Initial Program Load) constitue la séquence de démarrage du système. Le panneau de contrôle physique du serveur permet de sélectionner différents modes et sources d’IPL, chacun répondant à des besoins spécifiques de maintenance ou d’exploitation.
Le mode IPL se définit par deux paramètres : la source (A, B, C ou D) et le type (N pour Normal ou M pour Manuel).
La source A charge les programmes système sans les correctifs temporaires (PTF), utile en cas de dysfonctionnement lié à une mise à jour récente. La source B, la plus courante en production, charge le système complet avec tous les correctifs appliqués. La source D permet un démarrage depuis une unité optique, typiquement pour une installation ou restauration système.
Le type Normal (N) effectue un démarrage complet automatisé sans intervention. Le type Manuel (M) interrompt la séquence pour permettre à l’opérateur de sélectionner des options spécifiques, comme la désactivation de certains sous-systèmes ou l’ajustement de paramètres de récupération.
Le panneau de contrôle affiche différentes fonctions accessibles par codes numériques : 01 pour afficher les options d’IPL, 02 pour les modifier, 03 pour lancer l’IPL, 08 pour arrêter le système. La maîtrise de ces fonctions permet une gestion autonome même sans accès réseau.
Maîtriser les commandes essentielles pour l’administration système
Le langage CL (Control Language) structure toutes les opérations d’administration du serveur iSeries. Ces commandes, bien que cryptiques au premier abord, suivent une logique cohérente facilitant leur mémorisation. La plupart commencent par un verbe d’action suivi de l’objet concerné.
WRKSBS (Work with Subsystems) affiche l’ensemble des sous-systèmes actifs ou configurés. Cette commande centrale permet de visualiser l’état opérationnel du système et d’identifier les environnements d’exécution disponibles. Chaque sous-système peut être démarré, arrêté ou configuré individuellement.
STRSBS démarre un sous-système spécifique, activant l’environnement d’exécution associé. Le démarrage d’un sous-système père peut automatiquement activer ses fils s’ils étaient précédemment arrêtés ensemble. Cette cascade facilite la gestion des ensembles fonctionnels interdépendants.
ENDSBS arrête un sous-système de manière contrôlée. L’option *IMMED force un arrêt immédiat, tandis que d’autres paramètres permettent d’attendre la fin des travaux en cours. L’arrêt d’un sous-système père entraîne celui de tous ses fils, créant une cascade descendante.
| Commande | Fonction principale | Cas d’usage typique |
|---|---|---|
| WRKSBS | Gérer les sous-systèmes | Vérifier l’état opérationnel |
| WRKJOB | Analyser les travaux actifs | Diagnostiquer les blocages |
| WRKSPLF | Gérer les fichiers spool | Consulter les logs d’exécution |
| WRKTCPTBL | Table d’allocation TCP/IP | Vérifier les ports utilisés |
| DSPJOB | Détails d’un travail | Analyser les performances |
WRKSPLF (Work with Spool Files) accède aux fichiers spool contenant les sorties standard et logs système. Ces fichiers représentent une ressource précieuse pour le diagnostic, conservant les traces d’exécution des programmes et les messages système. Chaque travail génère potentiellement plusieurs fichiers spool selon sa configuration.
Les fichiers spool constituent la mémoire vivante du système, enregistrant chaque opération significative pour analyse ultérieure.
WRKTCPTBL affiche la table d’allocation des ports TCP/IP, indispensable pour identifier les conflits de ports ou vérifier les services réseau actifs. Cette commande révèle quels processus écoutent sur quels ports, facilitant la configuration de nouveaux services.
Le conseil d’Alexandre : Utilisez systématiquement F4 après avoir tapé une commande pour afficher ses paramètres. Cette touche fonction transforme l’apprentissage en explorant les options disponibles sans consulter la documentation.
Gérer les utilisateurs et la sécurité serveur avec rigueur
La gestion utilisateurs sur IBM i distingue deux univers parallèles : les profils système standard et les profils SST (System Service Tools). Cette dualité surprend souvent, mais répond à une logique de séparation des privilèges entre exploitation courante et maintenance système profonde.
WRKUSRPRF (Work with User Profiles) centralise la gestion des comptes utilisateurs système. Cette interface permet de créer (option 1), modifier (option 2) ou supprimer (option 3) des profils. La touche F10 révèle des paramètres avancés généralement masqués, offrant un contrôle granulaire sur les autorisations.
Les profils SST disposent de leur propre espace d’authentification, accessible uniquement via STRSST. QSECOFR existe dans les deux mondes, mais avec des mots de passe distincts. Les profils 11111111 et 22222222, présents par défaut dans SST, n’ont aucune contrepartie dans les utilisateurs système.
La configuration de la console de service via SST nécessite plusieurs étapes précises. Après STRSST, l’option 8 (Work with service tools user IDs and Devices) donne accès aux paramètres de console. L’option 3 (Select console) permet de définir le type de console, d’autoriser son remplacement dynamique et d’activer la console réseau.
L’option 4 (Configure service tools LAN adapter) définit les paramètres réseau spécifiques à la console de service. Cette IP doit différer de l’IP système principale. L’adresse du routeur primaire peut pointer vers le PC console, garantissant qu’il reste le seul autorisé à converser en mode console avec le serveur.
- Séparer strictement les mots de passe QSECOFR système et SST
- Limiter le nombre d’utilisateurs ayant accès aux outils SST
- Documenter précisément les IP attribuées à la console de service
- Configurer des profils utilisateurs avec des autorisations minimales nécessaires
- Activer l’audit des connexions pour tracer les accès administratifs
Exploiter Navigator for i pour simplifier l’administration
Navigator for i représente l’interface graphique moderne d’administration d’IBM i. Intégrée à l’OS de base depuis plusieurs versions, elle s’accède simplement via un navigateur web à l’URL http://votre-serveur:2001. Cette approche web élimine le besoin d’installer des clients lourds sur chaque poste administrateur.
L’interface organise les fonctions d’administration par domaines logiques : gestion des utilisateurs, configuration réseau, surveillance des performances, gestion du stockage. Cette structuration intuitive contraste agréablement avec la navigation par menus textuels de l’interface 5250 traditionnelle.
Navigator for i transforme des tâches complexes en opérations visuelles guidées, réduisant significativement la courbe d’apprentissage pour les nouveaux administrateurs.
La gestion des travaux actifs devient particulièrement claire dans Navigator. Les graphiques de performance, l’arborescence des sous-systèmes et les statistiques en temps réel offrent une vision globale impossible à obtenir via les commandes textuelles seules. Le filtrage et la recherche permettent d’isoler rapidement les éléments problématiques.
La configuration réseau bénéficie également de cette approche graphique. Les interfaces réseau, routes, services TCP/IP et configurations SSL s’administrent via des formulaires structurés validant les entrées en temps réel. Cette assistance prévient de nombreuses erreurs de syntaxe courantes avec les commandes CL.
Travailler avec les fichiers et compiler des programmes CL
La compilation de programmes CL (Control Language) s’effectue via CRTCLPGM, commande centrale du développement système. Elle transforme un fichier source texte en objet exécutable stocké dans une librairie spécifiée. La syntaxe complète inclut le nom du programme cible, sa librairie de destination, le fichier source et son membre.
CPYF (Copy File) manipule les fichiers de données avec une flexibilité remarquable. Le paramètre CRTFILE(*YES) crée automatiquement le fichier cible s’il n’existe pas, tandis que FMTOPT(*CVTSRC) adapte le format lors de la copie. Cette commande sert aussi bien à la sauvegarde qu’à la transformation de données.
EDTF (Edit File) ouvre un éditeur de membres de fichiers source. Pour modifier UANTEUPROC dans le fichier TEMPLATE de la librairie SOCIETE, la syntaxe complète serait : EDTF FILE(SOCIETE/TEMPLATE) MBR(UANTEUPROC). Cet éditeur basique mais fonctionnel permet des modifications directes sans nécessiter d’outils externes.
CRTSAVF crée un fichier de sauvegarde (*SAVF), équivalent IBM i d’une archive. Ces fichiers servent au transfert d’objets entre systèmes ou à l’archivage. RSTOBJ restitue ensuite les objets depuis un SAVF, comparable à une extraction d’archive ZIP dans le monde Windows.
| Commande | Action | Paramètres clés |
|---|---|---|
| CRTCLPGM | Compiler programme CL | PGM, SRCFILE, SRCMBR |
| CPYF | Copier fichier | FROMFILE, TOFILE, CRTFILE |
| EDTF | Éditer membre source | FILE, MBR |
| CRTSAVF | Créer archive système | FILE, SAVF |
| RSTOBJ | Restaurer objets archivés | OBJ, SAVLIB, DEV |
Les membres source utilisent l’extension *.SRC par convention. Un fichier source peut contenir plusieurs membres, chacun représentant un programme ou une version différente. Cette organisation facilite la gestion de versions avant l’adoption d’outils modernes de contrôle de source.
Optimiser les performances et assurer la maintenance préventive
La surveillance des performances d’un serveur iSeries repose sur plusieurs indicateurs clés accessibles via diverses commandes. WRKDSKSTS (Work with Disk Status) révèle l’utilisation de l’espace disque par ASP (Auxiliary Storage Pool), information critique pour anticiper les saturations.
Les pools de mémoire déterminent l’allocation des ressources entre sous-systèmes et travaux. WRKSYSSTS (Work with System Status) affiche la répartition mémoire et l’activité CPU. Une surveillance régulière identifie les déséquilibres nécessitant un réajustement des allocations pour optimiser les temps de réponse.
Un système bien équilibré maintient des temps de réponse inférieurs à une seconde pour les transactions interactives, objectif atteignable même sur du matériel ancien.
La gestion des journaux système (QHST) et des logs applicatifs nécessite une politique de rotation claire. Ces fichiers croissent continuellement et peuvent consommer des ressources significatives. Des procédures automatisées de sauvegarde et purge préservent les informations essentielles tout en libérant l’espace.
Les sauvegardes régulières constituent l’assurance de la continuité opérationnelle. IBM i propose plusieurs stratégies : sauvegarde complète (GO SAVE option 21), sauvegardes incrémentielles (GO SAVE option 22), ou sauvegardes de librairies spécifiques via SAVLIB. La restauration s’effectue symétriquement avec RSTLIB ou les options du menu GO RESTORE.
- Planifier des sauvegardes complètes hebdomadaires hors heures de production
- Effectuer des sauvegardes incrémentielles quotidiennes automatisées
- Tester régulièrement les procédures de restauration sur un environnement de test
- Surveiller l’espace disque et anticiper les extensions avant saturation
- Analyser les fichiers spool pour détecter les messages d’erreur récurrents
- Vérifier la température et les logs matériels via les outils SST
Les PTF (Program Temporary Fix) représentent les correctifs IBM appliqués au système. Une gestion rigoureuse des PTF maintient la sécurité et la stabilité. WRKPTFGRP (Work with PTF Groups) affiche les groupes de correctifs disponibles et installés, facilitant la planification des mises à jour.
Le conseil d’Alexandre : Ne négligez jamais les messages système dans QHST. Ils annoncent souvent des problèmes émergents plusieurs jours avant qu’ils ne deviennent critiques.
Intégrer l’IFS dans votre stratégie de gestion système
L’IFS (Integrated File System) introduit un système de fichiers hiérarchique similaire à Unix dans l’environnement IBM i. Cette couche coexiste avec l’organisation traditionnelle par librairies, offrant flexibilité et compatibilité avec les standards ouverts.
Les répertoires IFS supportent une profondeur illimitée, contrairement aux librairies limitées à deux niveaux (QSYS et librairie). Cette structure accueille naturellement les applications Java, les fichiers XML, les documents PDF et tout contenu nécessitant une arborescence complexe.
Les commandes QSHELL deviennent disponibles dans l’IFS, permettant des scripts shell classiques. Cette capacité rapproche IBM i des environnements Unix/Linux, facilitant l’intégration d’outils modernes et le transfert de compétences entre plateformes.
L’installation de Dollar Universe et applications similaires exploite simultanément librairies et IFS. Les objets système résidents dans les librairies, tandis que les fichiers de configuration, logs et scripts s’organisent dans l’IFS. Cette dualité optimise les performances tout en maintenant la compatibilité applicative.
Quelle est la différence entre un serveur iSeries et un AS/400 ?
L’AS/400 est le nom historique de la plateforme lancée en 1988. iSeries désigne la même architecture rebaptisée en 2000. Depuis 2008, IBM utilise l’appellation IBM i pour le système d’exploitation. Il s’agit donc de la même lignée technologique avec une compatibilité ascendante remarquable.
Peut-on administrer un serveur iSeries sans connaissances préalables d’AS/400 ?
C’est techniquement possible grâce à Navigator for i qui offre une interface graphique intuitive. Cependant, la maîtrise des concepts fondamentaux (librairies, objets, sous-systèmes) et des commandes CL reste indispensable pour diagnostiquer les problèmes complexes et optimiser les performances.
Comment récupérer l’accès à un serveur iSeries sans mot de passe QSECOFR ?
La procédure nécessite un accès physique au serveur et le passage par le mode de service DST (Dedicated Service Tools). Après un IPL en mode manuel, les outils SST permettent de réinitialiser le mot de passe QSECOFR. Cette opération critique doit être documentée et sécurisée.
Quelle version minimale d’IBM i est recommandée en 2025 ?
IBM supporte officiellement les trois dernières versions majeures. En 2025, privilégiez IBM i 7.4 ou 7.5 pour bénéficier des correctifs de sécurité et fonctionnalités modernes. Les versions antérieures à 7.2 ne reçoivent plus de support étendu et présentent des risques de sécurité.
Un serveur iSeries ancien type 9406-170 reste-t-il utilisable pour l’apprentissage ?
Absolument, pour acquérir les fondamentaux et pratiquer les commandes essentielles. Cependant, les performances limitées et l’impossibilité d’installer les versions récentes d’IBM i restreignent son utilité professionnelle. L’émulation via IBM i Cloud ou une partition LPAR moderne offre une alternative plus pertinente.
