Les objets IBM i, tout est objet

C'est quoi, un objet ?

Sous Windows ou Linux, on dit souvent que « tout est fichier » : un programme, une image, une configuration sont des suites d'octets que l'on peut ouvrir, lire et réécrire. Sur IBM i, c'est l'inverse : tout est objet, et un objet n'est pas une simple suite d'octets.

Un objet, c'est des données et un type. Le type est fixé à la création et décide des opérations possibles. On appelle un programme, on lit et on écrit dans un fichier, on dépose un message dans une file d'attente de données. Mais on ne peut pas ouvrir un programme pour le réécrire comme un fichier texte : pour le changer, on le recompile, ce qui crée un nouvel objet.

Le système vérifie le type à chaque commande. Sur notre bibliothèque d'exemple, la commande CPYF FROMFILE(JOBIOBJ/COMPTEUR), qui copie un fichier, échoue : « Fichier origine COMPTEUR de JOBIOBJ non trouvé » (CPF2802), puis CPF2817, « Commande de copie interrompue à la suite d'une erreur ». COMPTEUR existe bien, mais c'est une zone de données (*DTAARA), pas un fichier : le système ne cherche que des objets du type attendu.

Cette conception vient du System/38, annoncé par IBM en 1978. L'AS/400 en a hérité en 1988, et IBM i aujourd'hui. Les programmes ne parlent pas directement au matériel mais à une interface machine indépendante de la technologie (TIMI), et chaque objet a un type fixe qui définit les opérations applicables.

Avantage pour vous : un seul jeu de commandes. Lister, copier, déplacer, renommer, supprimer, donner des droits ou sauvegarder se fait de la même façon pour un programme, un fichier ou une file d'attente.

Ce qui identifie et décrit un objet

Un objet est identifié par trois choses : son nom, son type et sa bibliothèque. Deux objets peuvent donc porter le même nom s'ils sont de types différents. Dans notre bibliothèque d'exemple, BONJOUR est à la fois un programme, la commande qui l'appelle, et une zone de données :

En revanche, deux objets de même nom et de même type dans la même bibliothèque, c'est impossible. Créer une deuxième zone de données COMPTEUR dans JOBIOBJ échoue : CPF1023, « La zone de données COMPTEUR existe déjà dans JOBIOBJ ».

Les bibliothèques : où les objets sont rangés

Une bibliothèque (*LIB) est un objet qui en contient d'autres. Les bibliothèques ne s'imbriquent pas : il n'y a qu'un niveau. Toutes sont rangées dans une seule bibliothèque, QSYS, la seule qui puisse contenir des bibliothèques. On crée une bibliothèque par CRTLIB.

Certains objets n'ont pas leur place dans une bibliothèque applicative : les profils utilisateurs (*USRPRF), les listes d'autorisation (*AUTL) et les descriptions d'unités (*DEVD) vivent tous dans QSYS.

Une bibliothèque n'est pas un dossier de l'IFS. L'IFS, le système de fichiers hiérarchique d'IBM i (/home, /QOpenSys…), a ses propres types d'objets, comme les fichiers stream (*STMF) et les répertoires (*DIR). Les bibliothèques y apparaissent sous /QSYS.LIB : notre programme BONJOUR y est /QSYS.LIB/JOBIOBJ.LIB/BONJOUR.PGM.

La liste de bibliothèques (*LIBL)

Un programme cite rarement la bibliothèque de ses fichiers : il écrit ARTICLE, pas JOBIOBJ/ARTICLE. Le système cherche alors l'objet dans la liste de bibliothèques du travail, dans l'ordre, et prend le premier objet du bon nom et du bon type. Cette liste comprend :

1. La partie système : les bibliothèques du système d'exploitation, toujours présentes (valeur système QSYSLIBL).
2. Les bibliothèques de produits, deux au plus, ajoutées par le système quand une commande en a besoin (QRPG pour le compilateur RPG, par exemple).
3. La bibliothèque en cours (*CURLIB) : c'est là que la plupart des commandes de création, celles des programmes par exemple, rangent l'objet quand on ne précise pas de bibliothèque. Sans bibliothèque en cours, c'est QGPL.
4. La partie utilisateur : les bibliothèques de l'application, que l'on règle par ADDLIBLE ou CHGLIBL, et que l'on affiche par DSPLIBL.

C'est un mécanisme puissant : en plaçant une bibliothèque de test devant celle de production, le même programme travaille sur d'autres fichiers sans être modifié. C'est aussi la première cause des erreurs « objet non trouvé ». Nous l'avons vérifié : appelé par son nom complet CALL JOBIOBJ/LISTART depuis un travail dont la liste ne contient pas JOBIOBJ, le programme démarre, puis s'arrête sur CPF4101, « Fichier ARTICLE de *LIBL non trouvé ou fichier spoule en entrée manquant ». Le programme a été trouvé parce qu'il était qualifié ; son fichier, lui, a été cherché dans la liste de bibliothèques.

Les types d'objets les plus utilisés

IBM i 7.5 connaît 92 types d'objets rangés en bibliothèque, et 9 de plus pour l'IFS. Seul IBM peut en créer de nouveaux. Au quotidien, une vingtaine suffisent. Pour chacun, nous avons créé un exemple dans la bibliothèque JOBIOBJ :

Données

Ce que les programmes lisent et écrivent. Le type *FILE regroupe des objets très différents : c'est l'attribut (PF, LF, DSPF…) qui dit de quel fichier il s'agit.

Programmes

Ce qui s'exécute. En ILE, le code compilé passe par un module, puis devient un programme ou un programme de service.

Travaux et impressions

Ce qui organise l'exécution des travaux et la sortie des états.

Système et sécurité

Des objets que l'on ne range pas soi-même : ils vivent tous dans la bibliothèque QSYS.

Un fichier physique se décrit en DDS ou en SQL. Voici la description DDS du fichier ARTICLE :

     A* Fichier physique decrit en DDS : les articles
     A                                      UNIQUE
     A          R ARTICLER                  TEXT('Article')
     A            ARTCOD         6A         COLHDG('Code')
     A            ARTLIB        30A         COLHDG('Libelle')
     A            ARTPRX         7P 2       COLHDG('Prix')
     A          K ARTCOD

Et les objets SQL ?

SQL ne crée pas d'objets d'un autre monde : une table, une vue, un index ou une procédure SQL sont des objets IBM i comme les autres. Voici ce que le système a créé dans JOBIOBJ pour nos ordres SQL, relevé par QSYS2.OBJECT_STATISTICS :

• Une table est un fichier physique (PF), une vue et un index sont des fichiers logiques (LF). Un programme RPG peut les lire comme des fichiers DDS.
• Une procédure SQL est un programme *PGM d'attribut CLE : le système génère un programme ILE C avec du SQL intégré, puis le compile.
• Un nom SQL peut dépasser 10 caractères, pas un nom d'objet. CLIENTS_PAR_NOM est donc aussi l'objet CLINOMIX, le nom système donné par la clause FOR SYSTEM NAME. Sans elle, le système prend les cinq premiers caractères et ajoute un numéro : nos tables d'essai CLIENTS_PAR_VILLE et CLIENTS_PAR_REGION sont devenues CLIEN00001 et CLIEN00002.
• Un schéma SQL est une bibliothèque. Créé par CREATE SCHEMA, il contient en plus un journal, un récepteur et le catalogue SQL.

Notre bibliothèque d'exemple, en entier

La bibliothèque JOBIOBJ contient 30 objets de 16 types différents. Voici le premier écran de WRKOBJ, puis la liste complète :

/* Bibliothèque et fichiers source */
CRTLIB     LIB(JOBIOBJ) TEXT('JOB-i : un exemple de chaque type d''objet')
CRTSRCPF   FILE(JOBIOBJ/QDDSSRC) RCDLEN(112)
CRTSRCPF   FILE(JOBIOBJ/QRPGLESRC) RCDLEN(112)
CRTSRCPF   FILE(JOBIOBJ/QCLSRC) RCDLEN(112)
CRTSRCPF   FILE(JOBIOBJ/QCMDSRC) RCDLEN(112)

/* Fichiers décrits en DDS : physique, logique, écran, impression */
CRTPF      FILE(JOBIOBJ/ARTICLE) SRCFILE(JOBIOBJ/QDDSSRC)
CRTLF      FILE(JOBIOBJ/ARTICLE1) SRCFILE(JOBIOBJ/QDDSSRC)
CRTDSPF    FILE(JOBIOBJ/ECRAN) SRCFILE(JOBIOBJ/QDDSSRC)
CRTPRTF    FILE(JOBIOBJ/ETAT) SRCFILE(JOBIOBJ/QDDSSRC)

/* Programmes ILE : module, programme de service, répertoire de liage, programmes */
CRTRPGMOD  MODULE(JOBIOBJ/OUTILS) SRCFILE(JOBIOBJ/QRPGLESRC)
CRTSRVPGM  SRVPGM(JOBIOBJ/OUTILS) MODULE(JOBIOBJ/OUTILS) EXPORT(*ALL)
CRTBNDDIR  BNDDIR(JOBIOBJ/OUTILS)
ADDBNDDIRE BNDDIR(JOBIOBJ/OUTILS) OBJ((JOBIOBJ/OUTILS *SRVPGM))
CRTBNDRPG  PGM(JOBIOBJ/LISTART) SRCFILE(JOBIOBJ/QRPGLESRC)
CRTBNDCL   PGM(JOBIOBJ/BONJOUR) SRCFILE(JOBIOBJ/QCLSRC)
CRTCMD     CMD(JOBIOBJ/BONJOUR) PGM(JOBIOBJ/BONJOUR) SRCFILE(JOBIOBJ/QCMDSRC)

/* Échanges entre programmes et messages */
CRTDTAARA  DTAARA(JOBIOBJ/COMPTEUR) TYPE(*DEC) LEN(7 0) VALUE(0)
CRTDTAQ    DTAQ(JOBIOBJ/DEMANDES) MAXLEN(100)
CRTMSGF    MSGF(JOBIOBJ/MESSAGES)
ADDMSGD    MSGID(ART0001) MSGF(JOBIOBJ/MESSAGES) MSG('Article &1 inconnu.') FMT((*CHAR 6))

/* Travaux et impression */
CRTOUTQ    OUTQ(JOBIOBJ/IMPRESSION)
CRTJOBQ    JOBQ(JOBIOBJ/TRAVAUX)
CRTJOBD    JOBD(JOBIOBJ/DESCTRAV) JOBQ(JOBIOBJ/TRAVAUX) INLLIBL(JOBIOBJ QGPL QTEMP)
CRTCLS     CLS(JOBIOBJ/CLASSE)
CRTSBSD    SBSD(JOBIOBJ/SOUSSYST) POOLS((1 *BASE))

/* Sauvegarde et journalisation */
CRTSAVF    FILE(JOBIOBJ/SAUVEGARDE)
CRTJRNRCV  JRNRCV(JOBIOBJ/JRNRCV0001)
CRTJRN     JRN(JOBIOBJ/JOURNAL) JRNRCV(JOBIOBJ/JRNRCV0001)
STRJRNPF   FILE(JOBIOBJ/ARTICLE) JRN(JOBIOBJ/JOURNAL) IMAGES(*BOTH)

-- Objets créés en SQL
CREATE TABLE JOBIOBJ.CLIENTS (CLICOD CHAR(6) NOT NULL PRIMARY KEY,
                              CLINOM VARCHAR(40) NOT NULL);
CREATE INDEX JOBIOBJ.CLIENTS_PAR_NOM FOR SYSTEM NAME CLINOMIX
       ON JOBIOBJ.CLIENTS (CLINOM);
CREATE VIEW JOBIOBJ.CLIENTS_NORD FOR SYSTEM NAME CLINORD
       AS SELECT * FROM JOBIOBJ.CLIENTS WHERE CLICOD LIKE 'N%';
CREATE PROCEDURE JOBIOBJ.COMPTER_CLIENTS (OUT NB INTEGER)
       LANGUAGE SQL SPECIFIC JOBIOBJ.CPTCLI
       BEGIN SELECT COUNT(*) INTO NB FROM JOBIOBJ.CLIENTS; END;

Les commandes pour travailler avec les objets

Comme tout est objet, une poignée de commandes s'applique à tous les types :

Et en SQL, avec les services IBM i :

Tous les types d'objets d'IBM i 7.5

La liste complète, lue dans le catalogue QSYS2.SYSTEM_OBJECT_TYPES d'un IBM i 7.5. Les libellés sont ceux d'IBM, en anglais.

Sources

Les exemples ont été créés et vérifiés sur un IBM i 7.5 (voir la méthode). Les règles et les faits historiques viennent de ces sources, consultées le 13 octobre 2026 :

1. Objects, IBM, documentation IBM i 7.5. Tout ce que l'on manipule est un objet ; les commandes se ressemblent d'un type à l'autre ; seule QSYS contient des bibliothèques.
2. Object naming rules, IBM, documentation CL (IBM i 7.5). Noms de 10 caractères au plus ; les objets IBM (sauf les commandes) commencent par Q. Les caractères admis ont été vérifiés par CRTDTAARA sur notre IBM i 7.5 (message CPD0078 : « Un nom doit commencer par un caractère alphabétique »).
3. Library lists, IBM, documentation CL (IBM i 7.5). Un objet non qualifié est cherché dans la liste ; deux bibliothèques de produits au plus (QRPG…) ; les programmes créés sans bibliothèque vont dans *CURLIB, QGPL à défaut.
4. A job's library list, IBM, documentation CL (IBM i 7.5). Partie système (valeur système QSYSLIBL), partie utilisateur, bibliothèque en cours et bibliothèques de produits. L'ordre de recherche (système, produits, en cours, utilisateur) a été relevé par QSYS2.LIBRARY_LIST_INFO sur notre IBM i 7.5.
5. Change Library List (CHGLIBL), IBM, documentation CL (IBM i 7.5). L'ordre des bibliothèques dans la liste est l'ordre de recherche.
6. SQL relational database and system terminology, IBM, Db2 for i SQL (IBM i 7.5). Correspondance table / fichier physique, vue / fichier logique ; un schéma est une bibliothèque avec un journal, un récepteur et un catalogue SQL.
7. Debugging SQL procedures, triggers and UDFs, IBM Support. Une procédure SQL est un programme ILE C avec du SQL intégré, généré puis compilé.
8. IBM i, Wikipédia (en anglais). OS/400 sorti en 1988 avec l'AS/400, héritier du CPF du System/38 ; interface machine (TIMI) ; type fixe qui définit les opérations applicables.
9. Object (IBM i), Wikipédia (en anglais). « Tout est objet » ; l'ensemble des types est fixe et seul IBM peut en créer.
10. IBM System/38, Wikipédia (en anglais). Annonce du System/38 le 24 octobre 1978.

Questions fréquentes