Accéder à  l’IFS

pour utiliser
l’orientation objet bibliothèque/fichier/
membre classique, ce n’est pas le
cas quand on accède aux objets dans
d’autres systèmes de fichiers dans
l’IFS. Tous les autres systèmes de fichiers
IFS utilisent une structure orientée
répertoire hiérarchisée illimitée,
où les noms de chemins sont spécifiés
dans l’ordre, en commençant par le niveau
le plus haut du répertoire, en passant
par un nombre quelconque de répertoires
subsidiaires, pour aboutir à 
l’objet spécifique.
Chaque objet dans un répertoire
donné doit avoir un nom unique
(contrairement au système de fichiers
QSYS.LIB, où des objets de différents
types peuvent porter le même nom,
comme un fichier et une commande
appelés tous deux CUST). Les noms de
chemins ne peuvent pas commencer
par un astérisque (*) mais beaucoup
des commandes CL acceptent un
double astérisque (**) comme caractère
joker. Les noms de chemins sont
toujours séparés par la barre oblique
(/). La barre oblique inverse (\) est perçue
comme un caractère ordinaire et
ne peut pas servir de séparateur de
chemin. Quand un nom de chemin
commence par la barre oblique (/),
c’est que le chemin commence dans le
répertoire racine IFS. On l’appelle
aussi chemin absolu. Quand le chemin
ne commence pas par la barre oblique,
c’est qu’il commence dans le répertoire
courant. On appelle cela généralement
un chemin relatif.
Par exemple, pour utiliser la commande
CPY pour copier le fichier
orders.csv du répertoire /home/mikeo
dans le répertoire /downloads, on
utilisera le chemin suivant :

CPY OBJ(‘/home/mikeo/orders.csv’)
TODIR (‘/downloads’)

Il est évident qu’il faut comprendre
le nommage des chemins pour accéder à  des objets à  l’extérieur de QSYS.LIB.
En revanche, il n’est pas si évident que
l’on puisse utiliser le nommage des
chemins de style IFS pour identifier des
objets dans le système de fichiers
QSYS.LIB. Quand on emploie le nommage
IFS pour accéder à  des objets
dans QSYS.LIB, on utilise la syntaxe suivante
:

/QSYS.LIB/Mylibrary.LIB
/MyFile.FILE/MyMember.MBR

Cet exemple utilise la structure de
répertoires hiérarchisée IFS standard
pour pointer sur un chemin absolu
avec le système de fichiers QSYS.LIB.
Toutefois, dans ce cas, il est important
de noter l’utilisation de la notation de
type nom.objet de l’objet. Les bibliothèques
possèdent toujours l’extension
de type objet .LIB. De même, les fichiers
utilisent l’extension .FILE, et les
noms de membres utilisent l’extension
de type objet .MBR.
Normalement, les objets de
QSYS.LIB n’acceptent pas les noms qui
distinguent les majuscules des minuscules.
Mais on peut maintenir la casse
pour chaque caractère en mettant le
nom entre guillemets. Autre limitation
importante : on ne peut pas accéder
aux fichiers logiques en utilisant le
nommage IFS. Pour l’accès au programme,
QSYS.LIB supporte le mode
texte pour accéder aux fichiers physiques
et fichiers source décrits par le
programme et le mode binaire pour accéder
aux fichiers décrits en externe. Il
ne supporte l’accès aux fichiers de style
stream que pour les espaces utilisateur.
La commande WRKLINK (Work
with Object Links) fournit l’interface
primaire à  partir de la ligne de
commande OS/400 pour naviguer au
travers des autres systèmes de fichiers
de l’IFS.
Il faut savoir que les mécanismes de
sécurité OS/400 standard s’appliquent à 
tous les objets présents dans le système
de fichiers IFS. Seule limitation : l’adoption
d’autorité n’est supportée que
dans le système de fichiers QSYS.LIB.
(Pour plus de détails sur la manière
d’implémenter la sécurité dans
l’IFS, voir l’article « Cinq trucs
importants pour IFS ».
Commandes QShell. QShell est un
environnement de commandes interactif
conforme au standard POSIX et
pouvant se substituer à  l’environnement
de commandes CL natif de
l’OS/400. Les commandes QShell manipulent
IFS en utilisant les commandes
de type Unix de POSIX – un moyen
bien commode pour porter du code
Unix à  partir d’autres systèmes. En revanche,
les commandes de style Unix
ne suivent pas la tradition de l’OS/400
en matière de noms de commandes et
de syntaxe. Ainsi, au lieu d’utiliser la
commande OS/400 DSPLIB (Display
Library) pour afficher le contenu d’une
bibliothèque, QShell supporte la commande
Unix « ls » (list directory). QShell
supporte aussi des structures de langage
POSIX comme le pipelining, les
commandes de groupe, et l’exécution
d’instructions conditionnelles.

API. L’OS/400 offre également un
ensemble d’API de style langage C que
l’on peut incorporer dans les applications
pour accéder aux divers systèmes
de fichiers de l’IFS. Ces API de programmation
sont trop nombreuses
pour être recensées dans cet article.
(Pour obtenir la liste complète des API
de programmation, allez à  http://publib.
boulder.ibm.com/iseries/v5r2/ic29
24/index.htm et sélectionnez Programming,
APIs et Perform Operations using
APIs.)

Clients réseau. On peut accéder à 
l’IFS à  partir des systèmes client, de
deux manières. La première consiste à 
gérer les objets dans l’IFS en utilisant
l’iSeries Navigator qui est installé en option
en même temps que le produit
iSeries Access. Bien que l’on puisse employer
l’iSeries Navigator pour la navigation
dans les répertoires, la consultation
de fichiers et les opérations de copie
de fichiers par glisser/déposer, il est
réellement conçu comme un outil de
gestion servant à  créer des dossiers et
des shares de fichiers client, à  établir
des permissions, à  monter des UDFS et
à  démarrer la journalisation de fichiers.
Le deuxième moyen d’accès aux fichiers
dans l’IFS à  partir de systèmes
client Windows, Linux et Unix, consiste
à  utiliser l’iSeries NetServer. Dans ce
cas, l’iSeries apparaît aux clients du réseau
exactement comme un serveur de
fichiers de type Windows. Vous pouvez
utiliser le même protocole SMB
(Systems Message Block) qui est intégré
dans tous les systèmes d’exploitation
Windows et offert dans le client
Samba disponible gratuitement pour
des systèmes Linux et Unix, afin de
connecter directement ces clients réseau
à  l’iSeries IFS.
La combinaison de l’IFS et d’iSeries
NetServer est l’un des meilleurs
moyens d’intégrer des clients Windows,
Linux et Unix à  l’iSeries. L’iSeries
NetServer fait partie de l’OS/400 de
base. Qui plus est, il est facile à  mettre
en oeuvre et performant.