L'objet et le membre : ce que contient vraiment un fichier

L'objet et ses membres

IBM définit les membres comme des ensembles de données différents, tous au même format, à l'intérieur d'un même fichier. Voici le Pokédex de notre démonstration : un fichier, deux membres, un par génération.

• L'objet porte ce qui vaut pour tout le fichier : le format d'enregistrement (la liste des zones), les attributs (taille, réutilisation des supprimés, nombre maximal de membres…), le propriétaire et les droits.
• Le membre porte les enregistrements, et le chemin d'accès qui les ordonne quand le fichier a une clé. Tous les membres d'un fichier partagent le même format.
• Un membre n'existe pas seul : supprimer le fichier supprime tous ses membres.
• IBM le rappelle : en règle générale, un fichier n'a qu'un membre, celui créé avec lui, qui porte le même nom que le fichier (CRTPF a ajouté le membre CLIENT au fichier CLIENT, le membre POKEMON au fichier POKEMON).

Des commandes pour l'objet, d'autres pour le membre

Les droits se donnent sur l'objet : GRTOBJAUT … OBJTYPE(*FILE) ouvre ou ferme tous les membres du fichier d'un coup. En SQL, le catalogue QSYS2.SYSPARTITIONSTAT liste les membres (une « partition » par membre) :

SELECT SYSTEM_TABLE_MEMBER, NUMBER_ROWS, PARTITION_TEXT
  FROM QSYS2.SYSPARTITIONSTAT
 WHERE TABLE_SCHEMA = 'JOBIPOK' AND TABLE_NAME = 'POKEDEX'

SYSTEM_TABLE_MEMBER  NUMBER_ROWS  PARTITION_TEXT
GEN1                           5  Generation 1
GEN2                           5  Generation 2

Un fichier peut vivre sans membre

Puisque la description est dans l'objet, rien n'oblige un fichier à avoir des données. Le paramètre MBR(*NONE) de CRTPF crée l'objet seul. Notre Pokédex, décrit ainsi :

*...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
     A* Pokedex multi-membre : un membre par generation
     A          R POKEDEXR                  TEXT('Pokedex d''une generation')
     A            NUMPOK         4S 0       COLHDG('No' 'Pokedex')
     A            NOM           12A         COLHDG('Nom')
     A            TYPE1         10A         COLHDG('Type')
     A          K NUMPOK

CRTPF  FILE(JOBIPOK/POKEDEX) SRCFILE(JOBIPOK/QDDSSRC) MBR(*NONE) MAXMBRS(*NOMAX)
CPC7301  Fichier POKEDEX créé dans la bibliothèque JOBIPOK.

Un seul message : l'objet est créé, mais pas de CPC7305 Membre … ajouté. Le fichier existe, on peut afficher sa description, lui donner des droits, le sauvegarder… mais pas le lire : IBM précise qu'il faut au moins un membre avant toute entrée-sortie. En SQL :

SELECT * FROM JOBIPOK.POKEDEX
SQL0204  *FIRST de type *MEM dans *N non trouvé.

SQL cherche le premier membre (*FIRST) et n'en trouve aucun. Il suffit d'en ajouter un :

ADDPFM  FILE(JOBIPOK/POKEDEX) MBR(GEN1) TEXT('Generation 1')
CPC7305  Membre GEN1 ajouté au fichier POKEDEX de JOBIPOK.

À quoi sert un fichier sans membre ?

• Le fichier de référence de zones. C'est l'exemple d'IBM : un PF qui ne contient jamais de données et ne sert qu'à décrire des zones, que les autres fichiers reprennent par les mots-clés REF et REFFLD. IBM le crée avec MBR(*NONE) « parce qu'il ne contient jamais de données ».
• Le changement de format. Autre exemple d'IBM : pour ajouter une zone, on crée le nouveau fichier avec MBR(*NONE), puis on y copie le membre de l'ancien.
• Le fichier source neuf. CRTSRCPF crée le fichier sans membre par défaut : chaque source sera un membre, ajouté plus tard (voir les fichiers source).
• Le fichier dont les membres arrivent plus tard, un par génération, un par mois : c'est le multi-membre, objet de la page suivante.

Questions fréquentes