マイケル・オテ著

最iSeriesの機能の中で最も誤解されている機能の一つが統合ファイル・システム (IFS: Integrated File System) です。IFSはiSeriesのすべてのファイルにアクセスするための基礎を形成しています。IFSはシームレスに実装されているため、IFS自体については何も知識がなくてもIFSを容易に使用することができます。実際、従来のQSYSスタイルのライブラリやファイルへIFSでアクセスしてもIFSを使用していることを意識させません。

IFSはiSeriesの機能の中で最も誤解されている機能の一つですが、また最も重要な機能の一つでもあります。IFSを使用することで、接続されているPCサーバー、Windowsサーバー、NetWareサーバー、Linuxシステム、Unixのホストなどといった他の多くのシステムとiSeriesとの統合を簡素化できます。またIFSの高い柔軟性でプラットフォームを拡張し、構造化されていないデータへのアクセスをアプリケーションがサポートできます。IFSにはどんな機能があってどのように使用するのかについてより良く理解するために、IFSのファイル・システムのアーキテクチャとIFSのファイルにアクセスするためのさまざまな方法について説明します。

IFS仮想ファイル・システム・アーキテクチャ

IBMがIFSを実装したのはV3R1からで、これによりiSeriesではPCやUnixなどのシステムで使用されているストリーム・タイプのファイル・アクセスがサポートされ、PCやUnixなどのシステムからiSeriesへのアプリケーションの移植やデータの統合が大幅に容易になりました。ワープロ文書やストリーム・データ（たとえば画像や音声ファイルなど）といったファイル・タイプのほとんどは構造化されたライブラリ・ファイル・システムにはうまく適合しないため、IFSの機能が必要なのです。

今日ではIFSによりIBMは、新しいファイル・システムを既存のファイル・システムやオペレーティング・システム、ハードウェア設計を変更することなく追加することによって、iSeriesの機能を容易に拡張することができます。IFSのアーキテクチャの概要を図1に示します。この図をご覧になっておわかりいただける通り、IFSはファイル・システムをコマンドやファイル・パス記述子で参照するために各ファイル・システムにユニークな名前を付けています。（各ファイル・システムの概要については後述します。）

多重ファイル・システムをサポートするためにIFSは仮想ファイル・システム（VFS: Virtual File System） アーキテクチャとIBMが呼んでいるテクノロジーを使用しています。VFSはIFSに対するオブジェクト指向のインタフェースで、IFSがサポートしているあらゆるファイル･システムのデータ･ストレージに共通のアクセス機構を提供しています。VFSアーキテクチャの背景にあるIBMの狙いは、IFSファイル・システムの高レベルな部分と低レベルな部分を明確に区別することにより、低レベルのファイル・アクセス機構やハードウェアを変更せずに論理ファイル・システムをより多く追加させるという目標を達成することでした。

VFSは仮想ノード (vnode) で構成されており、各仮想ノードは物理的なファイル・システムに格納されている実際のオブジェクトを表しています。各論理ファイル・システムはvnodeオブジェクトと排他的に動作します。vnodeには、それ自身に対して実行される抽象的な操作の集合 (open、close、read、write、delete、その他のファイルを対象とした操作）が関連付けられています。

アプリケーションはVFSとは間接的に動作します。アプリケーションがファイル・システムの呼び出しを行うとき、適切な論理ファイル・システムに制御が渡されます。たとえば、RPGプログラムがファイルをオープンする操作を実行するとき、その要求はQSYS.LIB論理ファイル・システムによって処理されます。次にQSYS.LIBファイル・システムが、アプリケーションのファイル・システム・オープン呼び出しによって要求されたファイルにマッチする物理的なファイル・システム・オブジェクトを表しているvnodeを探します。RPGアプリケーションとQSYS.LIB論理ファイル・システムはともにその下にある物理的なファイル構造やデータと直接やりとりすることはなく、そのやりとりはすべてVFSが処理します。

IFSのVFSアーキテクチャでは論理ファイル・システムと、そのファイル・システム中に格納されているデータの物理的なロケーションや格納の実装方法とが分離されています。IFSの上半分は論理ファイル・システムであり、データの物理的な格納先については何も知りません。論理ファイル・システムが知っている必要があるのはvnodeにどのようにアクセスするか、です。同様に、IFSの下半分は物理的なデータの格納とそのデータへのアクセスについてのみ関心を持っているので、そのデータへのアクセス要求を出している上位レベルの論理ファイル・システムについてはまったく知りません。

IFSファイル・システム

iSeriesのIFSは現在10種類の異なるファイル・システムと3種類の統合ファイル・サーバーで構成されています。各ファイル・システムには格納されている情報とやりとりするための論理構造と規則があります。この論理構造と規則は各ファイル・システムごとに異なります。ファイル・システムは、論理単位として構成されている格納データの特定のセグメントへのアクセスをサポートしています。たとえば、QSYS.LIBファイル・システムの論理単位はファイル、ディレクトリ、ライブラリ、フォルダ、オブジェクトです。iSeriesの各ファイル・システムはそれぞれ特定のしかもユニークな目的を達成するように設計されています。IFSをユーザーから見たときのビューを図2に示します。

各ファイル・システムがどう異なるのかを理解していただくために、各ファイル・システムの詳細な説明とそれぞれの重要な属性について以下に述べます。

・Root ("/")：IFSと言えばルート ("/") ファイル・システムのことを指しているのが一般的です。ルート・ファイル・システムは他のファイル・システム全体を覆う傘の役割を果たします。ルート・ファイル・システムはWindows、DOS、Unix、Linuxなどにみられる階層的なファイル・システムで、ストリーム・タイプの入出力操作用に最適化されています。

ルート・ファイル・システムは多重ハード・リンク（オブジェクトへの直接参照）とソフト・リンク（シンボリック・リンクとも言い、ファイル中に含まれているパスやオブジェクト名への参照）をサポートしています。また、スレッド・セーフなAPIもサポートしていて、このAPIを使用すると1つのプロセス内の複数のスレッドが互いに干渉することなくファイル・システムにアクセスすることができます。ルート・ファイル・システムは他のオペレーティング・システムのファイル・システムと最も互換性のあるファイル・システムで、iSeriesと他のプラットフォーム間でデータを移動させる際の最良の選択肢と言えます。

・QSYS.LIB：ルート・ファイル・システムがIFSの中核であると考えられることが多い一方で、QSYS.LIBファイル・システムは間違いなくほとんどのiSeriesのユーザーがご存知のファイル・システムでしょう。QSYS.LIBはライブラリ、オブジェクト、ファイル階層を使用しており、ストリーム・タイプのデータ・アクセスではなく、レコード・ベースのアクセスをサポートしています。オペレーティング・システムの実行コードはQSYSライブラリ中に格納されており、アプリケーションのオブジェクトはユーザー・ライブラリに格納されています。QSYS.LIBファイル・システムは、IBMがV3R1以前のiSeriesや、それ以前のSystem/38で実装したオリジナルのファイル・システムと同様に動作します。実際、IBMはIFSアーキテクチャを控えめに実装したために、IFSのことを知らなければQSYS.LIBがiSeries上で利用できる唯一のファイル・システムだと勘違いするかもしれません。

デフォルトでは対話型のユーザーは自動的にQSYS.LIBファイル・システムに置かれます。QSYS.LIB内で作成されたファイルやプログラムなどのオブジェクトはすべて従来のOS/400のインタフェース（DSPOBやWRKLIBなど）で完全にアクセスすることが可能です。既存のCLコマンドやCL、RPG、Cobolをベースにしたアプリケーションは、V3R1でのIFSの導入以前とまったく同様にこれらのオブジェクトに対して動作します。

・ネットワーク･ファイル･システム (NFS: Network File System) ：NFSは、iSeriesのユーザーがリモートのNFSファイル･システムに格納されているデータにアクセスできるようにします。NFSはSun Microsystems社がUnix環境用に開発した分散されたファイルへの透過的なアクセス手法です。以来、NFSプロトコルのV2およびV3は多くのプラットフォームがサポートするインターネット標準として広く普及しました。NFSはステートレスのプロトコルで、クライアント／サーバー間の通信にリモート・プロシージャ呼び出し (RPC: Remote Procedure Call) 機能を取り入れています。OS/400はNFSサーバーではなくNFSクライアントとして動作します。つまり、OS/400はNFS中にあるNFSファイル共有を「マウント」して、そのファイル共有があたかもローカルに格納されているかのように読み書きすることができます。しかしOS/400はNFSから他のシステムに対してファイルを提供することはできません。

・QOpenSys：QOpenSysファイル・システムは、Unixベースのオープン標準であるPOSIXおよびX/Open互換性ガイド (XPG) アプリケーションとの互換性をiSeriesに持たせるために設計されたものです。QOpenSysはルート・ファイル・システムと同様にパスを基本とした階層的なファイル・システムで、ストリーム・ファイル処理を使用します。またファイル名中の大文字と小文字を区別することもできます。

・QOPT：QOPTファイル・システムはCDディスクやDVDディスクなどといった光学式メディア上に格納されたストリーム・データへのアクセスを提供します。QOPTは階層的なファイル・システムで、ストリーム・アクセス用に最適化されています。QOPTはiSeriesでCDメディアにアクセスする際に使用します。

・QDLS：QDLS （ドキュメント・ライブラリ・サービス）ファイル・システムは、ドキュメントや共有フォルダへのアクセスを提供します。さらに、iSeriesのフォルダ、ドキュメント・ライブラリ・オブジェクト（DLO)、ストリーム・データもサポートしています。QDLSファイル・システムはもともとOfficeVisionのドキュメントを格納するために設計されたものです。DLOドキュメント・フォーマットの制限により、このファイル・システムに格納されたオブジェクトは、ルート・ファイル・システムに格納されたオブジェクトに比べてオーバーヘッドが20パーセント程度増加します。

・ユーザー定義ファイル・システム (UDFS) ：UDFSはその名前から推測される通り、iSeriesの論理ファイル・システムの拡張で、ユーザーが独自のファイル・システムを作成することができます。UDFSは自身が作成されたときに定義される補助格納プール (ASP) 上に存在し、マウントしてからでないと使用できません。UDFSはルート・ファイル・システムと同様に、階層的なディレクトリ構造をしており、ストリーミング用に最適化されています。さらに、UDFSは*FIFO (First In First Out) オブジェクトとオブジェクトの変更のジャーナリングをサポートしています。

・QNTC：QNTCは、Windows NTサーバーのファイル・システムとしても知られており、Windows NTまたはそれ以後のWindowsを実行しているローカルまたはリモートのIntegrated xSeries Server for iSeries（旧名称Integrated Netfinity Server) 上に格納されているファイルへアクセスすることができます。QNTCはデータをストリーム・ファイルとして格納し、WindowsクライアントとiSeriesアプリケーションの両方からそのデータへのアクセスが可能です。

・QNetWare：QNetWare (NetWare) ファイル・システムはQNTCと良く似ていて、Novell NetWare 3.12または4.10を実行しているローカルまたはリモートのIntegrated xSeries Server for iSeries上に格納されているファイルへアクセスすることができます。QNetWareはデータをストリーム・ファイルとして格納し、NetWare Directory Services (NDS) オブジェクトへのアクセスを提供します。

・QFileSvr.400：QFileSvr.400はOS/400ファイル・サーバーとも呼ばれ、リモートのiSeries上にあるファイル・システムへの透過的なアクセスを提供します。QFileSvr.400はNFSと同様に、ローカルに格納されているデータへのアクセスは提供せず、ファイルへのアクセスを要求しているユーザーやアプリケーションの代わりにクライアントとして動作してリモートのOS/400ファイル・システムへデータを要求します。

IFSへのアクセス

IFSへの主なアクセスは、CLコマンド、QShellコマンド、API、ネットワーク・クライアントの4通りの方法があります。

CLコマンド。 CLコマンドで5250コマンド・ラインやコンパイルされたCLプログラムからIFSのさまざまな機能にアクセスできます。標準のOS/400 CLコマンドは従来のライブラリ／ファイル／メンバー・オブジェクト指向を使用するように設計されていますが、IFSの他のファイル・システムのオブジェクトにアクセスするときは事情が異なります。IFSの他のファイル・システムはいずれも制限のない階層ディレクトリ指向構造を使用し、パス名は、最上位のディレクトリから任意の子ディレクトリ数を経由して特定のオブジェクトまで、順序付けられて指定されます。

指定されたディレクトリ内のすべてのオブジェクトには、ユニークな名前が付けられます。（ファイル・オブジェクトとコマンド・オブジェクトがともにCUSTという名前であるといったように、異なるタイプのオブジェクトは名前が同じであっても良いというQSYS.LIBファイル・システムと異なります。） パス名の先頭文字にアスタリスク記号「*」は使用できませんが、CLコマンドのほとんどではアスタリスク記号を2つ続けた「**」をワイルドカード文字として使用することができます。パス名は常にスラッシュ記号「/」で分離されています。バックスラッシュ記号「\」は単なる一文字として認識され、パスの分離記号として使用することはできません。パス名の先頭にスラッシュ記号を使用すると、そのパスがIFSのルート・ディレクトリから始まっていることを示します。これを絶対パスとも呼びます。パス名の先頭がスラッシュ記号でない場合は、パスがカレント・ディレクトリから始まることを意味します。これを一般的に相対パスと呼びます。

たとえば、CPYコマンドを使用して/home/mikeoディレクトリにあるorders.csvというファイルを/downloadsディレクトリにコピーする場合は、以下のようなパスになります。

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

QSYS.LIB以外のオブジェクトへアクセスする際のパス名の付け方を理解しておかなければならないのは当然ですが、QSYS.LIBファイル・システムのオブジェクトを識別する際もIFSスタイルのパス名の付け方を使用できるということはあまり知られていません。QSYS.LIBのオブジェクトにアクセスする際にIFSの名前の付け方を採用するときは、以下の構文を使用することができます。

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

ご覧になっておわかりの通り、この例では標準のIFS階層ディレクトリ構造を使用してQSYS.LIBファイル・システムの絶対パスを指定しています。ただしこの場合重要なのは、「オブジェクト名.オブジェクト・タイプ」という記法を使用している点です。ライブラリは常に「.LIB」のオブジェクト・タイプ拡張子を所有しています。同様に、ファイルは「.FILE」拡張子を使用し、メンバー名は「.MBR」というオブジェクト・タイプ拡張子を使用します。

通常QSYS.LIBのオブジェクト名中では大文字と小文字を区別しません。ただし、名前を引用符で囲むと大文字と小文字を区別することができます。一つだけある大きな制限は、IFSの名前の付け方で論理ファイルにアクセスすることはできないということです。プログラムからのアクセスに対してQSYS.LIBはプログラムが記述した物理ファイルやソース・ファイルにアクセスするためのテキスト・モードと、プログラム外で記述されたファイルにアクセスするためのバイナリ・モードをサポートしています。QSYS.LIBはユーザー空間に対してのみストリーム・スタイルのファイル・アクセスをサポートしています。

WRKLINK (Work with Object Links) コマンドはOS/400のコマンド・ラインからIFSの他のファイル・システム内を移動するための中心的なインタフェースを提供します。 （IFSを操作するためのCLコマンドの全一覧は、後述の「IFSに対する命令」を参照してください。）

覚えておいていただきたいのは、標準のOS/400セキュリティ機構はIFSファイル・システム内のオブジェクトすべてに適用されるということです。唯一の制限は、権限の採用がQSYS.LIBファイル・システムでのみサポートされているという点です。

QShellコマンド。 QShellはPOSIX標準に準拠した対話式のコマンド環境で、OS/400ネイティブのCLコマンド環境の代役を果たします。QShellコマンドはPOSIXのUnix風コマンドを使用してIFSを操作するので、他のシステムからUnixコードを移植する際には便利な機能です。ただしUnixコマンドは、OS/400従来のコマンド名の付け方や文法の慣習に従っていません。たとえば、OS/400のコマンドDSPLIB (Display Library) を使用してライブラリの内容を表示させる代わりに、QShellではUnixの「ls」 (list directory) コマンドをサポートしています。またQShellはパイプライン処理、グループ・コマンド、条件文の実行などのPOSIX言語構造もサポートしています。

API 。OS/400はC言語スタイルのAPIも提供していて、自分のアプリケーションに組み込んでIFSのさまざまなファイル・システムにアクセスすることができます。しかしこのプログラミングAPIは膨大な数があるので本稿では一覧しません。（プログラミングAPIの全一覧については、http://publib.boulder.ibm.com/iseries/v5r2/ic2924/index.htm のWebページで、プログラミング、API、APIを使用した操作の実行、を選択してください。）

ネットワーク・クライアント。 IFSにクライアントからアクセスする方法には2種類あります。まず、iSeries Navigatorを使用してIFSのオブジェクトを管理できます。iSeries NavigatorはiSeries Access製品の一部としてオプションでインストールできます。iSeries Navigatorをディレクトリのナビゲーション、ファイルの表示、ドラッグ・アンド・ドロップによるファイルのコピー操作に使用することもできますが、iSeries Navigatorは元々ファイル共有やクライアント・ファイル共有の作成、アクセス権の設定、UDFSのマウント、ファイルのジャーナリングの開始などに使用する管理ツールとして設計されています。

Windows、Linux、Unixなどのクライアント・システムからIFSのファイルにアクセスするための2番目の方法は、iSeries NetServerを使用します。この機能は基本的にiSeriesがネットワーク・クライアントに対してあたかもWindowsベースのファイル・サーバーであるかのように見えるようにするものです。Windowsオペレーティング・システムや、Linuxシステム用およびUnixシステム用にフリーのSambaクライアントに組み込まれているのと同じシステム・メッセージ・ブロック (SMB) プロトコルを使用して、こうしたシステム上のネットワーク・クライアントをiSeriesのIFSにシームレスに接続することができます。
IFSとiSeries NetServerの組み合わせはWindows、Linux、UnixなどのクライアントとiSeriesを統合する最良の方法です。iSeries NetServerはOS/400のベースの一部に含まれています。さらに、iSeries NetServerは設定が容易ですばらしい性能を提供します。

優れた統合への道

IFSはiSeriesの基礎をなすファイル・アクセス・テクノロジーであり、前述でおわかりいただけた通り、QSYS.LIBファイル・システムのライブラリやファイルよりもずっと広範なものです。IFSを理解すると既存のiSeries資源をより有効に活用し、Windows、Linux、Unixなどのプラットフォームとのより良い統合への道が開けます。より良い統合への道への第一歩として、以下の「IFSの5つの便利テクニック」をご覧ください。なお、以下のIFSテクニック集はすぐに使用いただけます。

********************************************************************************

IFSの5つの便利テクニック

以下の5つの便利テクニックでiSeriesの統合ファイル・システム (IFS) を最大限に活用いただけます。

1. IFSへファイルをFTPする
FTP PUTサブコマンドを用いると、FTPを使用してネットワーク・システムからIFSディレクトリへファイルを転送することができます。GETサブコマンドでIFSディレクトリからのファイルの取り出しもできます。下の例はc:\upload400フォルダからIFSの/uploadsフォルダへすべてコピーする方法を示したものです。この例では絶対パスを使用しているので、/uploadsフォルダがIFSのルート・ディレクトリに存在していなければなりません。

ftp > PUT c:\upload400\*.* /uploads

2. 保管ファイルをFTPする
IFSを利用すると、iSeriesシステム間でオブジェクト転送機構の使用がFTPで行えます。ただし、FTPでQSYS.LIBファイル・システムからオブジェクトを直接転送することはできません。FTPは、デフォルトではファイルのデータ部分だけを送信し、ファイルの論理属性部分は送信しないためです。これに対処するには、FTP BINサブコマンドとNAMEFMTサブコマンド、およびファイルの絶対IFSを使用します。下のFTPコマンドは、MySaveiFileという保管ファイルをリモートのiSeriesに送信する例です。

ftp> bin
ftp> namefmt 1
ftp> put /qsys.lib/qgpl.lib/mysavefile.savf
/qsys.lib/qgpl.lib/mysavefile.savf

FTP転送が完了したら、RSTOBJ (Restore Object) コマンドを使用して保管ファイル中のオブジェクトを取り出すことができます。

3. IFSディレクトリのファイルを保存する
OS/400標準のSAVOBJ (Save Object) コマンドでは、QSYS.LIB以外のIFSディレクトリに含まれているオブジェクトを保存しません。IFSディレクトリ中のオブジェクトを保存するには、SAV (Save) コマンドを使用します。下の例は、IFSのルート・ディレクトリにあるQSYS.LIBおよびQDLS中のオブジェクトを除くすべてのオブジェクトを、TAP01という名前の装置に保存する方法を示したものです。

SAV DEV('/QSYS.LIB/TAP01.DEVD')
OBJ(('/*') ('/QSYS.LIB' *OMIT)
('/QDLS' *OMIT))

4. ASCIIコード・ページを使用してIFS内にファイルを作成する
IFSディレクトリにファイルを作成すると、デフォルトではiSeriesのEBCDICコード・ページが使用されます。困ったことに、このページはWindows、Linux、UnixなどといったASCIIベースのシステムから使用することができません。しかし下の例で示すように、CPYTOSTMF (Copy to Stream File) コマンドにSTMFCODPAG (Stream File Code Page) パラメータを指定することでASCIIコード・ページを使用したファイルをIFSディレクトリに作成することができます。FROMMBR (From Member) パラメータで指定するファイルは、ソース・ファイルでもプログラムにより記述されたファイルでも構いません。

CPYTOSTMF FROMMBR
('/qsys.LIB/mikeo.LIB/ASCII.FILE/ASCII.MBR')
TOSTMF('/downloads/MyASCIIfile')
STMFOPT(*Replace) STMFCODPAG(*PCASCII)
ENDLINFMT(*CRLF)

5. 自動ASCII変換機能を用いてデータベース・ファイルをIFSにコピーする
ASCIIコード・ページを採用しているファイルをIFS中に作成した後、CPYTOIMPF (Copy to Import File) コマンドを使用して、データをそのファイルにコピーすることができます。CPYTOIMPFは、カンマ区切り式 (CSV) ファイルなどといったさまざまなタイプの区切り記号を使用したファイルを自動的に作成できるので、プラットフォーム間のデータの転送が容易になります。コピーされたデータはすべてターゲット・ファイルで使用されているASCIIコード・ページに自動的に変換されます。下の例は、CSVを使ってQIWS/QCUSTCDTファイルをMyASCIIfileにコピーする例です。

CPYTOIMPF FROMFILE(QIWS/QCUSTCDT)
TOSTMF('/downloads/MyASCIIfile )
MBROPT( *REPLACE ) RCDDLM( *CRLF )
DTAFMT( *DLM )

********************************************************************************

マイケル・オティ氏は、Penton Media, Inc.の発行誌　iSeries NEWS、Windows & .NET MagazineおよびSQL Server Magazineの上級テクニカル・エディターです。同氏はソフトウェア開発／コンサルティング会社であるTECA, Inc.,の社長でもあります。同氏の近著には、SQL Server 2000 Developer's GuideおよびVisual Basic Answers! Tech Support at Your Fingertips （いずれもOsborne McGraw-Hill Publishing社より出版）があります。