IBM i : Architecture et Organisation Système

 IBM i : Architecture et Organisation Système

Vue d'Ensemble

IBM i (anciennement OS/400, puis i5/OS) est un système d'exploitation unique conçu pour les serveurs IBM Power Systems. Son architecture repose sur une abstraction matérielle totale et une orientation objet native qui le distingue radicalement des systèmes Unix/Linux ou Windows.

1. L'Orientation Objet : Le Cœur du Système

Architecture en Couches

┌─────────────────────────────────────────────┐

│   Applications & Interfaces Utilisateur     │

│        (5250, SQL, APIs, etc.)              │

├─────────────────────────────────────────────┤

│         Machine Interface (MI)              │

│     (Instructions indépendantes du HW)      │

├─────────────────────────────────────────────┤

│    Technology Independent MI (TIMI)         │

│        (Objets persistants)                 │

├─────────────────────────────────────────────┤

│    Licensed Internal Code (LIC/SLIC)        │

│         (Microcode système)                 │

├─────────────────────────────────────────────┤

│         Matériel (Power Systems)            │

└─────────────────────────────────────────────┘

Tout est Objet

Conséquence fondamentale : Sur IBM i, absolument tout est un objet stocké dans la base de données intégrée. Pas de "fichiers" au sens Unix/Windows.

OBJET (*OBJ) ├── Type (*TYPE) ├── Attribut (*ATTR) ├── Bibliothèque (*LIB) ├── Propriétaire (*OWNER) ├── Autorités (*AUT) └── Description (*TEXT) Exemples de types d'objets : - *PGM     : Programme - *FILE    : Fichier de données - *DTAARA  : Zone de données - *MSGQ    : File de messages - *JOBD    : Description de travail - *JOBQ    : File d'attente de travaux - *USRPRF  : Profil utilisateur - *OUTQ    : File d'attente d'impression - *SBSD    : Description de sous-système

Différence majeure avec les autres OS :

• Unix/Linux : fichiers + inodes, système de fichiers hiérarchique

• Windows : fichiers + registre, NTFS

• IBM i : objets dans une base de données relationnelle intégrée (DB2)

Avantages :

• Intégrité totale des données (transactions ACID natives)

• Sécurité granulaire au niveau objet

• Pas de corruption filesystem

• Sauvegardes cohérentes sans arrêt système

• Migration matérielle transparente (la MI s'occupe de tout)

2. Les Sous-Systèmes (SBSD)

Un sous-système est un environnement d'exécution prédéfini qui gère un ensemble de travaux.

Architecture des Sous-Systèmes

┌──────────────────────────────────────────────────────┐ │              SYSTÈME IBM i                           │ │  ┌────────────────────────────────────────────┐      │ │  │    Contrôleur de Sous-système              │      │ │  └────────────────────────────────────────────┘      │ │                                                      │ │  ┌──────────────┐  ┌──────────────┐  ┌──────────┐    │ │  │ QBASE (SBS)  │  │ QINTER (SBS) │  │ QBATCH   │    │ │  │              │  │              │  │ (SBS)    │    │ │  │ - Jobs       │  │ - Sessions   │  │          │    │ │  │   système    │  │  interactives│  │ - Jobs   │    │ │  │              │  │              │  │   batch  │    │ │  │ Pool: *BASE  │  │ Pool: *INTER │  │ Pool:    │    │ │  │              │  │              │  │ *BASE    │    │ │  └──────────────┘  └──────────────┘  └──────────┘    │ │                                                      │ │  ┌──────────────┐  ┌──────────────┐                  │ │  │ QCMN (SBS)   │  │ Custom SBS   │                  │ │  │              │  │ (créés par   │                  │ │  │ - Comm       │  │  utilisateur)│                  │ │  │   jobs       │  │              │                  │ │  └──────────────┘  └──────────────┘                  │ └──────────────────────────────────────────────────────┘

Sous-systèmes Standards

Sous-système	Rôle	Pool mémoire
QBASE	Travaux système, jobs non routés	*BASE
QINTER	Sessions interactives (5250)	*INTERACT
QBATCH	Travaux batch	*BASE
QCMN	Communications (telnet, FTP, etc.)	*BASE
QCTL	Contrôleur système (IPL, etc.)	*BASE
QSYSWRK	Travaux systèmes internes	*BASE

Composants d'un Sous-système

Description de Sous-système (SBSD) ├── Entrées de File d'Attente (*JOBQ) │   └── QBATCH : MAXACT(5) → max 5 jobs simultanés ├── Entrées de Routage (*RTGE) │   ├── SEQNBR : ordre de comparaison │   ├── CMPVAL : valeur de comparaison │   └── PGM : programme de routage ├── Entrées de Workstation (*WSE) │   └── WRKSTN(*ALL) → toutes les workstations ├── Entrées d'Autostart (*AJE) │   └── Jobs lancés au démarrage du SBS └── Allocation de Pools     └── Associe le SBS à un pool mémoire

Exemple de configuration :

CRTSBSD SBSD(MONLIB/MYSBS)          POOLS((2 *BASE))           TEXT('Mon sous-système custom') ADDRTGE SBSD(MONLIB/MYSBS)          SEQNBR(10)          CMPVAL(QCMDI)          PGM(QCMD) ADDJOBQE SBSD(MONLIB/MYSBS)           JOBQ(MONLIB/MYJOBQ)           MAXACT(3)

3. Les Pools Mémoire

IBM i utilise une gestion de mémoire par pools, concept unique qui optimise l'allocation des ressources.

Architecture des Pools

┌─────────────────────────────────────────────────────┐ │         MÉMOIRE PHYSIQUE TOTALE (RAM)               │ │                                                     │ │  ┌──────────────────────────────────────────────┐   │ │  │  *MACHINE (Pool 1) - Système d'exploitation  │   │ │  │  Taille fixe, non configurable               │   │ │  └──────────────────────────────────────────────┘   │ │                                                     │ │  ┌──────────────────────────────────────────────┐   │ │  │  *BASE (Pool 2) - Pool système par défaut    │   │ │  │  - Travaux système                           │   │ │  │  - Batch                                     │   │ │  │  - Jobs non routés                           │   │ │  │  Taille: XXX MB | Activité: YYY              │   │ │  └──────────────────────────────────────────────┘   │ │                                                     │ │  ┌──────────────────────────────────────────────┐   │ │  │  *INTERACT (Pool configuré) - Interactif     │   │ │  │  - Sessions utilisateurs 5250                │   │ │  │  Taille: XXX MB | Activité: YYY              │   │ │  └──────────────────────────────────────────────┘   │ │                                                     │ │  ┌──────────────────────────────────────────────┐   │ │  │  *SPOOL (Pool 3-4...) - Spooling             │   │ │  │  Taille: XXX MB | Activité: YYY              │   │ │  └──────────────────────────────────────────────┘   │ │                                                     │ │  ┌──────────────────────────────────────────────┐   │ │  │  Pools Partagés (3-15) - Custom              │   │ │  │  Configurables selon besoins                 │   │ │  └──────────────────────────────────────────────┘   │ └─────────────────────────────────────────────────────┘

Paramètres Clés d'un Pool

1. Taille : Quantité de RAM allouée (en MB/GB)

2. Niveau d'activité : Nombre maximum de threads actifs simultanément

3. Priorité de pagination : Importance lors du swapping

Exemple de visualisation :

WRKSYSSTS (Work with System Status) Pool      Size (M)    %Used    Act Lvl    DB Fault    Non-DB Fault *MACHINE   4096.00    45.2       ---         ---          --- *BASE      8192.00    67.8       40         0.5          2.1 *INTERACT  4096.00    52.3       25         0.2          1.5 *SPOOL     1024.00    23.1       10         0.1          0.3

Optimisation des Pools

Le niveau d'activité est crucial :

• Trop bas : jobs en attente, sous-utilisation CPU

• Trop haut : thrashing, pagination excessive

Règle empirique :

DB Fault < 5-10 par seconde = OK

Non-DB Fault < 10-20 par seconde = OK

4. Gestion Mémoire : L'Adressage Unique

Single Level Storage (SLS)

Concept révolutionnaire : IBM i utilise un espace d'adressage virtuel unique de 2^64 octets (18 exaoctets théoriques).

┌───────────────────────────────────────────────────┐ │     ESPACE D'ADRESSAGE VIRTUEL UNIQUE (64 bits)   │ │                                                   │ │  Chaque objet a une adresse PERMANENTE            │ │                                                   │ │  ┌──────────────────────────────────────────┐     │ │  │  Objet A (*PGM)                          │     │ │  │  Adresse: 0x0000 1234 5678 9ABC          │     │ │  │  ┌────────────────────────────────┐      │     │ │  │  │ Code compilé                   │      │     │ │  │  │ Pointeurs vers autres objets   │      │     │ │  │  └────────────────────────────────┘      │     │ │  └──────────────────────────────────────────┘     │ │                                                   │ │  ┌──────────────────────────────────────────┐     │ │  │  Objet B (*FILE)                         │     │ │  │  Adresse: 0x0000 ABCD EF12 3456          │     │ │  │  ┌────────────────────────────────┐      │     │ │  │  │ Enregistrements                │      │     │ │  │  │ Index                          │      │     │ │  │  └────────────────────────────────┘      │     │ │  └──────────────────────────────────────────┘     │ │                                                   │ │         Mapping automatique RAM ↔ Disque          │ │         par le LIC (transparent)                  │ └───────────────────────────────────────────────────┘

Conséquences du SLS

1. Pas de distinction RAM/Disque au niveau applicatif

• Le programmeur voit un seul espace mémoire

• Le LIC gère le placement physique (RAM ou disque)

• Pagination totalement transparente

2. Pointeurs permanents

// En RPG/CL, un pointeur reste valide indéfiniment DCL &PTR *PTR   // Même après reboot, le pointeur pointe toujours au bon endroit ! ``` **3. Pas de malloc/free** - Pas d'allocation/libération manuelle - Garbage collection automatique - Pas de fuites mémoire classiques **4. Protection matérielle** ``` Chaque référence mémoire est vérifiée : - Type d'objet correct ? - Autorisation d'accès ? - Adresse valide ? → Plantage impossible (ou quasi) par dépassement mémoire ``` ### Comparaison avec les autres OS | Aspect              | IBM i             | Unix/Linux              | Windows                 | |---------------------|-------------------|-------------------------|-------------------------| | **Adressage**       | Unique 64 bits    | Par processus           | Par processus           | | **Persistance**     | Objets permanents | Fichiers + RAM volatile | Fichiers + RAM volatile | | **Protection**      | Matérielle (MI)   | MMU + logicielle        | MMU + logicielle        | | **Gestion mémoire** | Automatique       | malloc/free             | HeapAlloc/Free          | ## 5. Les Travaux (JOB) Un **job** est l'unité d'exécution de base sur IBM i. Tout ce qui s'exécute est un job. ### Types de Jobs ```                     JOBS                      │         ─────────────┼─────────────────         │            │                │     INTERACTIF    BATCH           SYSTÈME         │            │                │    ┌────┴────┐  ┌────┴────┐     ┌────┴─────┐    │         │  │         │     │          │  Sessions  Display Submitted  SCPF  Subsystem   5250    Stations  (SBMJOB)  Jobs   Jobs ``` ### Anatomie d'un Job ``` JOB: USER/JOBNAME/NUMBER      └─┬─┘ └──┬───┘ └──┬──┘        │      │        └── Numéro unique (000001-999999)        │      └── Nom du job (10 car max)        └── Utilisateur propriétaire Exemple: PIERRE/QPADEV0001/123456 ``` **Attributs d'un Job** : ``` ┌─────────────────────────────────────┐ │  JOB PIERRE/QPADEV0001/123456       │ ├─────────────────────────────────────┤ │ Type: INTER                         │ │ Sous-système: QINTER                │ │ Pool: *INTERACT                     │ │ JOBD: PIERRE/MYJOBD                 │ │ JOBQ: QBATCH (si batch)             │ │ Priorité: 5 (0=haute, 9=basse)      │ │ User Profile: PIERRE                │ │ Bibliothèque courante: MYLIB        │ │ Liste biblio (*LIBL): ...           │ │ Message Queue: PIERRE               │ │ Output Queue: PIERRE                │ │ Date/Heure démarrage: ...           │ │ CPU utilisé: XXX ms                 │ │ Transactions DB: YYY                │ └─────────────────────────────────────┘ ``` ### Cycle de Vie d'un Job ```  ┌──────────┐  │  SBMJOB  │ Soumission  └────┬─────┘       │       v  ┌──────────┐  │  JOBQ    │ En attente dans file  └────┬─────┘       │       v  ┌──────────┐  │  ACTIVE  │ En exécution  └────┬─────┘       │       v  ┌──────────┐  │ OUTQ     │ Job terminé, spool en attente  └────┬─────┘       │       v  ┌──────────┐  │ JOBLOG   │ Historique conservé (QHST)  └──────────┘

Commandes de Gestion

// Voir jobs actifs WRKACTJOB // Voir un job spécifique WRKJOB JOB(123456/PIERRE/QPADEV0001) // Soumettre un job batch SBMJOB CMD(CALL PGM(MYLIB/MYPGM))         JOB(MYJOB)         JOBD(MYJOBD)        JOBQ(QBATCH) // Terminer un job ENDJOB JOB(123456/PIERRE/QPADEV0001) OPTION(*IMMED) // Retarder un job DLYJOB DLY(5)  // Attendre 5 secondes ``` ## 6. Descriptions de Travaux (JOBD) Une **JOBD** est un template qui définit les caractéristiques par défaut d'un job. ### Structure d'une JOBD ``` ┌─────────────────────────────────────────────┐ │  JOBD: MYLIB/MYJOBD                         │ ├─────────────────────────────────────────────┤ │ JOBQ: QBATCH          // File par défaut    │ │ JOBPTY: 5             // Priorité           │ │ OUTPTY: 5             // Priorité spool     │ │ PRTDEV: *USRPRF       // Imprimante         │ │ OUTQ: *USRPRF         // File sortie        │ │ RTGDTA: QCMDI         // Données routage    │ │ RQSDTA: CALL MYPGM    // Commande initiale  │ │ INLLIBL: MYLIB QTEMP  // Librairies         │ │ CURLIB: MYLIB         // Biblio courante    │ │ INLASPGRP: *NONE      // Groupe ASP         │ │ LOG: (4 00 *SECLVL)   // Niveau de log      │ │ LOGCLPGM: *YES        // Logger CL          │ │ ACGCDE: *USRPRF       // Code accounting    │ │ SYSLIBL: *SYSVAL      // Biblio système     │ └─────────────────────────────────────────────┘

Création d'une JOBD

CRTJOBD JOBD(MYLIB/BATCHJOBD)         JOBQ(QBATCH)         JOBPTY(5)         OUTQ(*USRPRF)         RTGDTA(QCMDI)         INLLIBL(MYLIB PRODLIB UTILLIB)         CURLIB(MYLIB)         LOG(4 00 *SECLVL)         LOGCLPGM(*YES)         TEXT('JOBD pour traitements batch') ``` ### Hiérarchie de Priorités Quand un job démarre, ses attributs proviennent de (par ordre de priorité) : ``` 1. Paramètres SBMJOB (si spécifiés)        ↓ 2. JOBD spécifiée        ↓ 3. USRPRF de l'utilisateur        ↓ 4. Valeurs système (QSYSVAL)

Exemple pratique :

// Le user PIERRE a JOBD(QBATCH) dans son profil // Mais on soumet avec une JOBD spécifique : SBMJOB CMD(CALL MYPGM)         JOBD(MYLIB/CUSTOMJOBD)  // ← Cette JOBD l'emporte        USER(PIERRE) → Le job utilisera CUSTOMJOBD, pas QBATCH ## 7. Profils Utilisateurs (USRPRF) Un **USRPRF** définit l'identité, les droits et l'environnement par défaut d'un utilisateur. ### Structure d'un USRPRF ``` ┌────────────────────────────────────────────────┐ │  USRPRF: PIERRE                                │ ├────────────────────────────────────────────────┤ │ IDENTIFICATION                                 │ │  ├─ Password: **** (crypté)                    │ │  ├─ Status: *ENABLED / *DISABLED               │ │  ├─ User Class: *USER / *SECOFR / *PGMR        │ │  └─ Text: 'Pierre - Développeur'               │ ├────────────────────────────────────────────────┤ │ ENVIRONNEMENT PAR DÉFAUT                       │ │  ├─ CURLIB: PIERRE                             │ │  ├─ INLLIBL: PIERRE DEVLIB TESTLIB             │ │  ├─ JOBD: PIERRE/MYJOBD                        │ │  ├─ INLMNU: *SIGNOFF (menu initial)            │ │  └─ INLPGM: *NONE (programme initial)          │ ├────────────────────────────────────────────────┤ │ AUTORISATIONS                                  │ │  ├─ Special Authority:                         │ │  │   *ALLOBJ, *SAVSYS, *JOBCTL, etc.           │ │  ├─ Owner: *USRPRF (propriétaire objets créés) │ │  └─ Group Profile: DEVGROUP                    │ ├────────────────────────────────────────────────┤ │ MESSAGERIE                                     │ │  ├─ Message Queue: PIERRE                      │ │  ├─ Delivery: *NOTIFY / *HOLD / *BREAK         │ │  └─ Severity: 00-99                            │ ├────────────────────────────────────────────────┤ │ IMPRESSION                                     │ │  ├─ OUTQ: PIERRE                               │ │  └─ PRTDEV: PRT01                              │ └────────────────────────────────────────────────┘ ``` ### Classes d'Utilisateurs | Classe       | Pouvoir          | Usage typique           | |--------------|------------------|-------------------------| | **\*SECOFR** | Security Officer | Administrateur sécurité | | **\*SECADM** | Security Admin   | Admin délégué           | | **\*PGMR**   | Programmer       | Développeurs            | | **\*SYSOPR** | System Operator  | Opérateurs              | | **\*USER**   | User             | Utilisateurs finaux     | ### Autorisations Spéciales ``` *ALLOBJ    : Accès à TOUS les objets *SAVSYS    : Sauvegarder le système *JOBCTL    : Contrôler tous les jobs *SPLCTL    : Contrôler tous les spools *SECADM    : Administrer la sécurité *IOSYSCFG  : Configuration I/O *SERVICE   : Mode service *AUDIT     : Modifier audit système

Création d'un USRPRF

CRTUSRPRF USRPRF(DEVUSER)           PASSWORD(Welcome123)           USRCLS(*PGMR)           CURLIB(DEVUSER)           INLLIBL(DEVUSER DEVLIB)           JOBD(DEVUSER/DEVJOBD)           SPCAUT(*NONE)           TEXT('Développeur junior')           STATUS(*ENABLED)           PWDEXP(*YES)          // Mot de passe expire           PWDEXPITV(90)         // Tous les 90 jours           LMTDEVSSN(*YES)       // Limiter sessions           MAXSTG(*NOMAX)        // Pas de limite stockage           OWNER(*USRPRF)        // Propriétaire objets créés           GRPAUT(*NONE)         // Pas autorité par groupe ## 8. Concepts Complémentaires Essentiels ### 8.1. La Liste de Bibliothèques (*LIBL) La *LIBL est l'équivalent du PATH Unix, mais pour les objets. ┌────────────────────────────────────┐ │  LISTE DE BIBLIOTHÈQUES            │ ├────────────────────────────────────┤ │  SYSTEM PORTION (non modifiable)   │ │  ├─ QSYS                           │ │  ├─ QSYS2                          │ │  └─ QHLPSYS                        │ ├────────────────────────────────────┤ │  PRODUCT PORTION                   │ │  └─ (bibliothèques produits)       │ ├────────────────────────────────────┤ │  CURRENT LIBRARY                   │ │  └─ MYLIB    ← Bibliothèque courante ├────────────────────────────────────┤ │  USER PORTION (modifiable)         │ │  ├─ DEVLIB                         │ │  ├─ TESTLIB                        │ │  └─ PRODLIB                        │ └────────────────────────────────────┘ Recherche d'objet: 1. CURRENT LIBRARY d'abord 2. Puis USER PORTION (ordre de la liste) 3. Puis PRODUCT PORTION 4. Enfin SYSTEM PORTION

Commandes :

DSPLIBL                       // Afficher la *LIBL CHGLIBL LIBL(LIB1 LIB2 LIB3)  // Changer ADDLIBLE LIB(NEWLIB)          // Ajouter RMVLIBLE LIB(OLDLIB)          // Retirer CHGCURLIB CURLIB(MYLIB)       // Changer biblio courante ``` ### 8.2. Files de Messages (MSGQ) Tout sur IBM i passe par des messages structurés. ``` ┌─────────────────────────────────────┐ │  FILE DE MESSAGES: PIERRE           │ ├─────────────────────────────────────┤ │ MSG ID    Severity  Text            │ ├─────────────────────────────────────┤ │ CPF2105     40     Object not found │ │ CPI091C     00     Backup completed │ │ CPF1124     50     Job ended abnorm │ └─────────────────────────────────────┘ Commandes: DSPMSG MSGQ(PIERRE)      // Afficher messages SNDMSG MSG('Texte') TOMSGQ(USER)  // Envoyer ``` ### 8.3. Niveaux de Sécurité IBM i a 5 niveaux de sécurité (paramètre QSECURITY) : | Niveau | Protection                | Usage                  | |--------|---------------------------|------------------------| | **10** | Aucune                    | Jamais en production ! | | **20** | Mots de passe uniquement  | Développement          | | **30** | + Autorités objets        | Minimum production     | | **40** | + Intégrité référentielle | Standard production    | | **50** | + Audit complet           | Haute sécurité         | ### 8.4. ASP (Auxiliary Storage Pool) Les ASP sont des groupes de disques indépendants. ``` ┌──────────────────────────────────────┐ │  SYSTEM ASP (ASP 1)                  │ │  ├─ QSYS                             │ │  ├─ Objets système                   │ │  └─ Configuration                    │ ├──────────────────────────────────────┤ │  USER ASP (ASP 2-32)                 │ │  └─ Données utilisateurs             │ ├──────────────────────────────────────┤ │  INDEPENDENT ASP (IASP)              │ │  ├─ Isolés du reste                  │ │  ├─ Déplaçables entre machines       │ │  └─ High Availability                │ └──────────────────────────────────────┘ ``` ### 8.5. Work Management - Vue Globale ```                UTILISATEUR                     │                     ▼             ┌────────────────┐             │  SIGNON (5250) │             └───────┬────────┘                     │                     ▼             ┌────────────────┐             │   USRPRF       │──→ Définit environnement             └───────┬────────┘                     │                     ▼             ┌────────────────┐             │   JOBD         │──→ Template du job             └───────┬────────┘                     │                     ▼             ┌────────────────┐             │   JOB créé     │             └───────┬────────┘                     │                     ▼             ┌────────────────┐             │  SOUS-SYSTÈME  │──→ Environnement exécution             └───────┬────────┘                     │                     ▼             ┌────────────────┐             │  POOL MÉMOIRE  │──→ Ressources allouées             └───────┬────────┘                     │                     ▼             ┌────────────────┐             │  EXÉCUTION     │             └───────┬────────┘                     │                     ▼             ┌────────────────┐             │  SPOOLED FILES │──→ Output             └────────────────┘

9. Avantages Architecturaux d'IBM i

1. Stabilité légendaire : Uptimes de plusieurs années courants

2. Sécurité intégrée : Architecture par objets + vérifications matérielles

3. Intégrité des données : Base de données intégrée avec transactions ACID natives

4. Pas de fragmentation : Le SLS élimine ce problème

5. Sauvegardes cohérentes : Pas besoin d'arrêter le système

6. Indépendance matérielle : Migration Power6 → Power10 transparente

7. Gestion automatique : Peu de tuning nécessaire par rapport à Unix/Windows

10. Commandes de Diagnostic Essentielles

// Monitoring système WRKSYSSTS     // Status général (pools, CPU) WRKSYSACT     // Activité temps réel WRKACTJOB     // Jobs actifs WRKSBS        // Sous-systèmes WRKSBSJOB     // Jobs d'un sous-système // Gestion objets WRKOBJ OBJ(MYLIB/*ALL)  // Tous objets d'une lib DSPOBJD OBJ(MYLIB/MYPGM) OBJTYPE(*PGM)  // Détails objet // Performance WRKMSMSE      // Niveaux de service (pool tuning) WRKDSKSTS     // Status disques // Jobs WRKJOB JOB(*/JOBNAME/*)     // Analyser un job WRKJOBQ JOBQ(QBATCH)        // File d'attente WRKOUTQ OUTQ(QPRINT)        // Spool // Sécurité WRKUSRPRF USRPRF(*ALL)      // Tous les profils WRKAUT OBJ(MYLIB/MYPGM)     // Autorisations DSPAUTUSR USRPRF(PIERRE)    // Autorités d'un user