【第11回】フェイス – IBM i におけるインターフェースの選択肢

 はじめに

第9回と第10回では、IBM i のデータベースである DB2 for i の機能とインターフェースについて解説しましたがいかがだったでしょうか。OS の標準機能としてデータベースを採用した System/38 からその DNA を引き継ぎ、「枯れた DBMS」としてこれまで基幹システムを支えてきたのが DB2 for i です。 IBM i がなぜ 30年近くに渡って使われ続けてきたのか、その最大の功労者がこの DB2 for i であることは皆さん異論がないところでしょう。 しかし、安定して使われているからこそ、日々そのありがたさを実感せず当たり前と思ってしまうのはライフラインと同じだと思います。前二回の記事が、そんな DBMS に思いをはせ、新たな機能を再発見するきっかけになってくれることを願うばかりです。 さて、今回はその DBMS にアクセスするためのインターフェースについて考えたいと思います。System/38 の頃から使われている CUI と、2000年前後のクライアント・サーバー・システムで普及した GUI が、IBM i ではどのような位置付けになっているのか、またどのようにサポートされているのかを解説していきます。キーワードは「フェイス」です。

CUI インターフェース（5250）

System/38 および AS/400 のころから、基幹システムのインターフェースの主役は 5250 でした。もともとは System/34 の専用端末で情報を表示するための規格であり、AS/400 のころまでは専用の 5250 端末が存在していました。コンピュータからの情報（5250データストリーム）を表示する機能だけを持った端末で、端末側では具体的な処理は何も行わなかったため、この専用端末はダム端末（Dumb Terminal）と呼ばれていました。 その後 Windows 95 が普及すると、専用端末の機能をソフトウェア的に実現するエミュレータ・ソフトによってその地位を奪われていきます。代表的なソフトは SNA および TCP/IP プロトコルをサポートした PC5250 や TCP/IP のみの Client Access 5250 エミュレーターです。TCP/IP が社内 LAN でも当たり前になってくると Client Access for windows およびその後継である IBM i Access for windows に含まれる 5250 エミュレーターがスタンダードになりました。そのサポートも Windows 7.1 までとなり、Windows 8.1（8 はサービスパックで対応）以降のバージョンではサポートされなくなり、これに変わる製品として IBM i Access Client Solutions が提供されていますが、この製品でも 5250 エミュレーターは健在です。 専用の端末からソフトウェアでエミュレートするようにクライアント側は変わり、サーバーとクライアントを接続する通信プロトコルも SNA から TCP/IP に変わりましたが、AS/400 からみれば 5250 データストリームを扱うという点で何ら変わらないので、このインターフェースを使用するプログラムの作成方法は何も変えることなく行うことができました。ハードウェアの変化やソフトウェアの機能に左右されないというこの点が、IBM i がこれだけ長期間に渡って使われてきた大きなポイントなのです。そして最新の IBM i Access Client Solutions は、Windows だけでなく Mac もサポートしますので、より多くの技術者が使い慣れた OS で IBM i にアクセスできるようになります。 5250 アプリケーションを作成する際に、よく使われているのが表示装置ファイルです。ユーザーが業務において目にするメニューや照会、入力画面の多くは DDS を使用して作成されるこの表示装置ファイルで定義されています。プログラムは、このファイルに対するレコード単位の読み書きを実行するだけで、5250 データストリームとしてエミュレーターに送信されたり、ユーザーが画面で入力した情報をプログラム変数に取り込んだりすることができます。 もうひとつ、5250 インターフェースを実現する機能としてパネルグループ（オブジェクト・タイプは *PNLGRP）があります。システムのメニューや画面の多くは、このパネルグループによって作成されています。あまり知られていませんが、このパネルグループはユーザーが作成することもできます。対話型プログラムを表示装置ファイルを使用せずに作成可能なのです。 表示装置ファイルは、画面上の何行目の何桁目に何を表示するのかを明示します。それに対してパネルグループは、タイトルやオプション番号、指示行のテキストやリストの構成などは定義しますが、それをどこに表示するのかは指定しません。これはどの要素をどこに表示するべきかという規格があり、それにのっとってシステムが自動的に配置するようになっているためで、これにより OS が提供する画面に一貫性があるのです。この規格のことを CUA（Common User Access） といいます。表示装置ファイルで画面を定義する際、例えば F1 はヘルプキーとか F3 は終了キーなど統一して設計されると思います。ファンクション・キーに割り当てる機能を OS が提供する画面と同じにすることで、ユーザーの使用感を同じにできるということでそうしているのですが、結果的に CUA に準拠した画面を表示装置ファイルで実現しているのですね。 5250 ではシステムが予め提供しているメニューの他に、ユーザーの入力するコマンドを解釈してシステムに実行を依頼する QCMD というプログラムも提供されています。コマンドはシステム提供のメニュー下部にあるコマンド入力行でも実行できますが、以前入力したコマンドの一覧が表示されたり、コピーが簡単にできたりと便利なので QCMD を使われている方は多いのではないでしょうか。Linux システムを運用されている方は telnet でログインしてコマンドベースでシステム管理をされている方が多いと思いますが、IBM i でも、5250 インターフェースで QCMD を使用してコマンドを入力することでシステム管理を行う方法はまだまだ一般的です。従来からのプログラムをサポートする他に、管理型のコマンドを実行するためのインターフェースとしてこれからも利用されていくと思います。

「古い」のはだめなのか

AS/400 および IBM i の一般的な印象として良く言われているのが「インターフェースが古い」というものだと思います。これは主に 5250 エミュレーターのいわゆるグリーン・スクリーンのことを指しているのだと思います。Windows のデスクトップ上で、他のソフトはマウスを使って操作しているのに、5250 画面だけはいつまでたってもキーボードで行っていますからそう思われてしまうのも致し方ないかもしれません。 確かに 5250 アプリケーションは「過去の資産の継承」の最たるものですから、古いのは確かにそうだと思います。ただ、5250 画面はあくまでもダム端末をソフトウェア的にエミュレーションしているものであり、IBM i のたくさんあるインターフェースの一つにすぎません。何度も言っていることですが、GUI が一般的になる前から企業を支えた基幹システムが、現在も変更なく動くことが大事なことであり、5250 はそれを実現している一要素でしかありません。実際、私は1997年に AS/400 をサーバーとしたクライアント・サーバー・システムをフロントエンド（Windows 側）は VB で構築しています。今から 20 年前のことです。IBM i は 5250 専用サーバーではないのです。 大事なことは「古い」のが悪いのではなく、「新しい」ものが無条件に良いのでもなく、良いものは長期間、古くなっても使えること、新しいものは柔軟に取り込んで、流行りではない本当の技術がまた長期間使えることだと思います。30 年以上使われている 5250 アプリケーションと、20 年前は新参ものだった VB をフロントエンドとするクライアント・サーバーがあたり前の技術として共存している IBM i はそういうコンピュータなのです。

GUI インターフェース

それではもうひとつのインターフェースである GUI を考えてみましょう。DB2 for i にアクセスするプログラムを考えた場合、基幹業務として GUI を利用するには、その多くを外部デバイスに依存することになります。基本的には Windows や 携帯デバイスなど、それぞれに CPU があって OS があり、その機能を使いつつ、データベース・サーバーである IBM i にアクセスするのが一般的ですね。 では、クライアント・サーバー環境におけるサーバー側インターフェースとして IBM i は何を提供しているのでしょうか？大きくは以下の２つになると思います。

• ODBC
• JDBC

皆さんご存知のように、ODBC はマイクロソフトが提供する、プログラムと DBMS の間を取り持つインターフェースです。マイクロソフト製なので使用するプログラムは主に Windows プログラムになります。ODBC はアクセスする DBMS の違いを吸収するので、プログラムはアクセスしている DBMS が何なのかをほとんど意識することなく作成することが可能です。同じようなものとして JDBC がありますが、これは ODBC の Java 版です。Java プログラムが主に使用しますが、IBM i の RPG も JDBC ドライバーを利用可能なので、例えば、外部 DBMS の Oracle に RPG からアクセスしたりすることも可能です。 各 DBMS がそれぞれ専用の ODBC / JDBC ドライバーを提供していますが、IBM i も DB2 for i 用の ODBC / JDBC を提供していますので、それを使用して SQL ベースで外部プログラムが DB2 for i にアクセス可能です。IBM i での SQL サポートについては前回の記事「第10回　ステップアップ – データベース：DDL」も参考にしてください。 ODBC / JDBC ともにそれをサポートするプログラム言語はたくさんありますので、様々な言語の特性を生かして IBM i のインターフェースとして多くのプログラムが作られてきましたし、これからも作られていくことでしょう。 それでは次に、すでに主流になって久しいインターフェースで、皆さんも最も馴染みがあると思われる Web について考えてみましょう。 このインターフェースは、TCP/IP プロトコルをベースに作られており、代表的なものとしては HTTP プロトコルが挙げられるでしょう。ご存知のように HTTP プロトコルは、クライアント側ソフトウェア（主にブラウザ）が Web サーバーに対して要求を出し、その要求に応じて Web サーバー側が情報をクライアントに返します。初期の頃は、データの検索から加工までサーバーが一括して行い、クライアント側は結果を決められたフォーマット（HTML）に従って表示するという単純なものでした。現在では、クライアント側でも処理可能な JavaScript により、それぞれが分散して処理が可能となっています。動的な Web ページなどあたり前ですよね。 IBM i では、当初 Web サーバーとしてオリジナルなものを提供していましたが、現在では他のプラットフォームでも利用されている apache が標準 Web サーバーです。apache サーバーを中心に、PHP や CGI （もちろん RPG で記述することも可能）プログラムが実行可能ですので、クライアントがブラウザもしくは独自プログラムを使って Web サーバーにアクセスする業務もだんだん増えてきていると思います。 プロトコルインターフェースの共通化だけではなく、データ交換のインターフェースとして、XML や json などもありますが、これらももちろん IBM i で利用可能です。サーバー側のコードを JavaScript で記述可能な Node.js も第8回で解説をしました。 最近では、オープンソース製品として Nginx（エンジンエックス）もサポートされていますので、より大量ユーザー、パフォーマンスを意識したシステム作りが可能になっていますね。 このように、IBM i における GUI インターフェースのサポートは多岐に渡って実現されていることがわかると思います。これらは主にアプリケーション実行のためのインターフェースですが、それではシステムを管理するインターフェースはどうなっているのでしょうか？ システム管理としては、コマンドベースで実行しているものをどのように GUI で実現するかが鍵になります。主にオブジェクトの作成や機密保護の設定、保管や復元、データベースの作成および保守、TCP/IP の各サーバーの構成および管理などがあげられるでしょう。そのほとんどが Client Access for windows / IBM i Access for windows では System i ナビゲーターという Windows アプリケーションとして提供されていました。現在では、IBM i の 管理 Web サーバーにブラウザからアクセスして管理していくものが主流になってきています。DB2 for i データベース管理に関しては、Schemas 機能も提供されていますので、GUI インターフェースを使用したテーブルの作成や管理などを含む多様なタスクを GUI で実行することができるようになっています。 実は IBM i における GUI 環境はこれだけ充実しているわけです。場合によっては、IBM i を利用しているにも関わらず、一回も 5250 画面を見ることなく、管理およびアプリケーションの開発および実行なども可能であることを今一度認識していただければと思います。

IBM i Access Client Solutions について

すでに紹介したとおり、Windows 8.1 以降では IBM i Access for windows はサポートされなくなり、かわりに IBM i Access Client Solutions が提供されています。プラットフォームに依存しない Java ベースの製品であり、これまでの Windows だけでなく、Linux や Mac などでも利用可能になりました。とくに Mac において IBM i へのアクセス・インターフェースが提供されることは、他プラットフォームの技術者の IBM i に対する大きなハードルを取り除くことにもなるでしょう。 IBM i Access Client Solutions で提供される主な機能は以下のとおりです。

• 5250 エミュレーター
• データ転送（*.xlsx、*.xls、*.csv、*.ods などに対応）
• 統合ファイルシステム（IFS へのインターフェース）
• Navigator for i（管理インターフェース）
• Run SQL Scripts（DB2 for i に対する SQL 実行インターフェース）
• Schemas（データベース管理機能）
• 5250 コンソール
• 仮想制御パネル
• ・・・・

これらの機能がどのプラットフォームからも同様に利用できるのです。私はこの実力がどれほどのものかを知りたくて、普段使う PC を Windows マシンから  MacBook Air（MBA）に変更してしまいました。RPG プログラムも FFRPG であればエディタは Orion が利用できるので、システム開発から管理にいたるまで、Mac で完結してしまうというのはとてもすごいことだと思います。 先日仕事で使用している IBM i の LAN カードの不調により、IBM i へのアクセスができなくなってしまったことがあったのですが、その時も MBA に導入した ACS の 5250 コンソール機能を使って IBM i にアクセスし、原因究明とその後の対応を行うことができました。 今までと異なるインターフェースになると、どうしても小さな違いや使い勝手が気になってしまい、「使えない」という評価をしてしまいがちですが、それらも慣れてしまうのにそんなに時間はかからないはずです。ACS をまだ使ったことの無い方はぜひ今お使いのプラットフォームで体験してください。そして一日も早くそちらに移行していただければと思います。

サーバーはGUIもCUIも備えて当然

IBM i はサーバーです。しかもデータベース・マシンであり、DB2 for i は信頼できる DBMS です。もちろん、機能の豊富さで言えば、Oracle や SQL Server の方に軍配があがるかもしれません。しかし、SoR の中核を支える機能は必要十分なものを提供しています。何より安定して運用できるというこの一点だけでも十分なのではないでしょうか。普段は意識しないレベルで仕事をしてくれているこの DBMS こそが IBM i の最も重要な機能なのです。   System/38 の頃から考えれば、30 年以上に渡って SoR システムとして使われてきたこのコンピュータは、長い間この DBMS へアクセスするプログラムの実行インターフェースは 5250 でした。この資産が今後も使われる限り、5250 インターフェースも使われていきます。その見た目の印象が古いなどということとはまったく関係ないのです。 そして、現在は様々な GUI インターフェースが「あたり前のように」IBM i で提供されています。そしてこの GUI インターフェースでのアクセスを可能にする様々な技術も同様に提供されており、今後はクラウドや AI、IoT といったシステムや技術ともあたり前のように繋がっていくことになると思います。今までがそうであったように、気がついたら IBM i の世界でもそれがあたり前になっているのではないでしょうか。 サーバーには CUI インターフェースも GUI インターフェースも必要です。用途に応じて使い分けていくことが大事なのです。それでもサーバー系の管理は、例えば Linux などもそうですが telnet でアクセスして CUI で行うことがまだまだ多いと思います。5250 でコマンドを実行するのもそれと同じことです。何も古いとか新しいとかそういった次元のことではないのです。皆さんも普段の使い方によって CUI インターフェースが多かったり GUI が多かったりすると思います。それは使い方の話であってそれ以上でも以下でもありません。ただ、IBM i はその両方とも提供しています。

おわりに

時代は刻一刻と変化していきます。そして新しい技術はどんどん生まれていきます。この技術をどのようにして取り組んでいけば良いのか、我々は常に真剣に向き合って行かなければなりません。そして取捨選択をしていきます。もう使うことのない技術、新しいことに取り組む上で障壁になることに関しては躊躇なく捨て去ることが必要かもしれません。しかし、その判断に「古いから」という基準は存在しないはずです。古いというのはただ単に作られたのがかなり前であるとか、使われている技術が発表されてから年数がたっているからとか言うだけの話で、その技術なりプログラムが今も現役で使われているのであればそれは「古い」のではないのです。捨て去るべき古いものは使われなくなって久しいプログラムや技術だけだということを念頭において、これからの技術革新に望んでいきたいと思います。 ピーター・ドラッガーは、「知識労働で生産性を高めるカギは、この仕事で求められる結果は何かと考え、それを明確にすることである。それにはリスクを伴う決断を下さなければならないが、ほとんどの場合、正しい答えなどありはしない。ただ、選択肢があるだけである。」と言っています。選択肢はあっても普遍的な選択の条件はないということだと思います。 IBM i が「古い」という評価は単なるイメージでしかありません。どうか選択肢はたくさん持ちながら冷静な判断で、将来のシステムをどうすべきなのかじっくりと考えることが大事だと思います。そして、その選択する答えは IBM i で必ず見つかるのではないでしょうか。