MENU

08 IBM iとファイル・システム ~ライブラリーにオブジェクトを格納するという2階層を基本とするシンプルで強力な構造 | 新・IBM i入門ガイド[基礎知識編]

LinuxやWindowsにおけるファイル管理は、フォルダ(ディレクトリ)とファイルによる多階層のツリー構造である。IBM iではどのようにファイル(オブジェクト)は管理されるのだろうか? 

IBM iにおけるオブジェクト管理は、ライブラリーと呼ばれる論理的な入れ物の中にオブジェクトを格納するという、2階層を基本とした単純なものだ(正確には、ライブラリーQSYSというシステム提供の特殊なライブラリー・オブジェクト内に、その他のライブラリー・オブジェクトが配置され、これらのライブラリー・オブジェクトに各種オブジェクトが格納されるという3階層になる)。そのため、IBM iのなかでオブジェクトを特定する場合には、どのライブラリーにどの名前の、どのタイプのオブジェクトかがわかれば一意に特定できる(図表1)。

図表1 ライブラリー/オブジェクトという2階層構造

この2階層によるオブジェクト管理のファイル・システムをQSYS.LIBファイル・システム、ライブラリー・ファイル・システムなどと呼ぶことがある。このようにLinuxやWindowsとはまったく異なる概念のオブジェクト管理手法がとられているが、IBM iではQSYSファイル・システム以外にも、他プラットフォームとのシームレスな連携を図る目的で、さまざまなファイル・システムを透過的に取り扱う統合ファイル・システム(IFS: Integrated File System)という考え方が導入されている。IFSでは/(ルート)配下に図表2のように、利用目的に応じてシステムとして複数用意されているファイル・システムが統合されている。

図表2 さまざまなファイル・システムが統合されたIFS

なお、IFSは1ファイルあたりの最大サイズ(ファイル・システムによって異なり、後述の/QOpenSysであれば、Type1ファイルは128GBでType2ファイルは1TB)や含められるサブ・ディレクトリ数といった論理的な数的制限はもちろん存在するものの、各ディレクトリの物理容量制限はなく、他プラットフォームでは運用管理項目として一般的に行われているログ・ディレクトリに対する容量管理、ディレクトリ・フルによるアプリケーション停止の防止のためのクォータ管理は必要ない。あくまでIBM iのOS全体としてのストレージ容量を把握しておけばよい形だ。

ここからは代表的で使われる頻度が多いであろうファイル・システムを挙げてみよう。/QOPTなど、ここで挙げたもの以外のファイル・システムについてはぜひIBM Documentationで確認されたい。

ルート・ファイル・システム

IFSの基本となるファイル・システムでWindowsなどと同じ多階層のディレクトリ構造となっており、また論理的には「/」配下にその他のファイル・システムが配置される形態をとっており、「/」からディレクトリをたどることで各ファイル・システムにアクセスできる。

Db2 for iのテーブルに格納されているデータをエクスポートしたいといった場合には、CPYTOIMPFコマンドを使用して、ルート・ファイル・システムにCSVファイルとしてエクスポートしたりする。また、他プラットフォームとのデータ授受で、通常のファイルを介した連携を行うような場合にも、IBM i側にはこのルート・ファイル・システムにファイルとして配置し、その後IBM i側でデータを取り込んだり、加工したりという使い方も一般的だ。

ライブラリー・ファイル・システム

ライブラリー/オブジェクト形式で管理するファイル・システムだ。「/QSYS.LIB/ライブラリー名.LIB/オブジェクト名.オブジェクトタイプ」と指定することでオブジェクトを一意に識別できる。ちなみにFTPでも対象ファイルを上記のパスで指定することでデータの転送を行うことができる。

保管ファイル・イメージ(*FILE SAVFオブジェクト)をFTP転送する場合、転送先のIBM i上には通常SAVFオブジェクトを転送に先立ち作成しておき、上書き転送する必要がある(作成しておかなければ通常の物理ファイル・オブジェクトとして転送されてしまう)が、上記パス指定で転送することで事前作成することなく直接SAVFオブジェクトを配置することができる(図表3)。

図表3 FTPで保管ファイルをWindowsから直接転送

また、このパス指定方式では総称指定も容易だ。たとえば、あるライブラリー内の複数のオブジェクトの所有者を一括して変更したい場合、ネイティブ・コマンドであるCHGOBJOWNコマンドでは各オブジェクトに対して設定変更を行う必要がある。そこで、IFSの所有者変更コマンドであるCHGOWNコマンドを用い、対象オブジェクトを総称指定することで簡単に設定ができたりもする(図表4)。

図表4 ライブラリーLIBAのプログラムPGM1,PGM2,PGM3の所有者を変更

QOpenSysファイル・システム

UNIXベースのオープン・システムとの互換性の目的で用意されているファイル・システムだ。IBM iのなかにはPASE(Portable Application Solutions Environment)と呼ばれるAIX実行環境が用意されている。IBM i上ではJavaやPHP、Node.jsなどはこのPASEと呼ばれる実行環境上で動く仕組みだ。このPASEが利用しているファイル・システムがQOpenSysファイル・システムになる。

Windowsではディレクトリやファイル名の大文字小文字は区別されないがLinuxのext3やUNIXでは厳密に区別され、たとえば「FILE」「File」「file」は別のファイルとして同一ディレクトリに配置できる。/QOpenSys配下ではUNIX同様大文字小文字を区別するので、特にLinuxやUNIXとのファイル授受などには/QOpenSys配下にディレクトリを作成、利用するとよいだろう。

また、ls、rm、chmodなどUNIXで使用されるファイルの操作・管理系のコマンドもPASE実行環境から利用できるので、権限管理などUNIXでのファイル管理になじみのある方がIBM iに携わる際にはPASEは取り付きやすいインターフェースと言える(もちろんIFS上のオブジェクトに対する権限管理はCHGAUTというCLコマンドでも実行できる)(図表5)

図表5 大文字小文字を区別する/QOpenSys

QFileSvr.400ファイル・システム

リモートのIBM i上のファイル・システムに透過的にアクセスするためのファイル・システムとなり、IBM iホスト・サーバー機能で実現されているものだ。TCP/IPが登場・普及する以前より実装されているファイル・システムで歴史のあるIFS上のファイル共有の仕組みといえる。

なおサインオンしているユーザーおよびパスワードでリモートのIBM iに接続するので、ユーザー、パスワードおよびシステム値のパスワード・レベル QPWD
LVLがお互いのIBM iで一致している必要があるが、/QFileSvr.400直下に名前解決可能なホスト名もしくはIPアドレスでディレクトリを作成するだけでよいので、IBM i間の接続に簡単に使える機能だ(図表6)。

図表6 /QFileSvr.400でIBM i間のディレクトリを共有

QNTCファイル・システム

/QFileSvr.400がIBM i間のディレクトリ共有の仕組みだったのに対して、/QNTCはWindows上のフォルダ共有やLinuxのSMB/CIFSサーバーに対してIBM iからクライアントとして接続するためのファイル・システムだ。

IBM iを基幹として周辺にWindows、Linuxサーバーを配置、互いに連携させて社内システムを構築しているケースは多いと思うが、そのような構成においてIBM iがクライアントとして周辺のサーバーのディレクトリをマウント、IBM iからファイルとしてデータを提供する際などに利用できる。

またこの逆、すなわちIBM iがSMB/CIFSサーバーとして機能するものがNetServerと呼ばれる機能だ。NetServerの場合にはIBM i上のディレクトリを周辺がマウントする形式でファイル共有を行う仕組みとなる(図表7)。

図表7 /QNTCでWindowsのフォルダ共有にアクセス

なお、NetServerによるファイル共用の設定はNavigator for i のファイル・システム機能から行えるが、5250インターフェースは標準では用意されていない。5250インターフェースから設定を行いたい場合にはGO NETSと呼ばれる、QUSRTOOLで提供されているツールをセットアップすることで利用できるようになる。GO NETSを使用することで、OSが制限状態下であっても設定確認などが行えるのでNetServerを利用している環境ではぜひ活用していただくとよいだろう。セットアップ方法はリンク先に掲載されているので参考にしていただきたい(図表8)。

図表8 GO NETSメニュー

 

著者
中村 陽一氏

株式会社MONO-X
テクノロジー事業本部 クラウド事業部

[i Magazine 2025 Spring号掲載]

新着