【第6回】　オープンネス – Orion / git

前回は「スタンダート – RDi」と題して、IBM i の開発環境である RDi を紹介しました。クライアントにインストールする RDi は、5250 ベースの SEU + PDM の組み合わせでは実現できないさまざまな利点を開発者に提供してくれます。また、RDi は Eclipse ベースの環境のため、他言語開発者も違和感なく使用できます。さらに、バージョン管理システムとの連携など他言語開発環境では当たり前であった機能を IBM i の開発環境にもたらしてくれます。 これまでの記事で何度となく触れてきましたが、IBM i の開発言語の中心である RPG は定位置記入形式がまだまだ現役であり、特に RPG Ⅲ はフリーでの記述ができません。プログラムのソースコードを編集する際に、何桁目に記入するのかをすべて覚えることはできないので、SEU で提供されているプロンプト機能が必須になってきます。RDi は、このプロンプト機能を RPG Ⅲ および Ⅳ の編集時に提供してくれます。これからの IBM i の開発ツールのスタンダードとしては、この RDi がベストであるということは疑いようのない事実なのです。 そして IBM は、もうひとつの開発環境を用意しました。これが今回ご紹介する Orion と git です。それぞれのツールがどのようなものか、RDi や他の外部ツールとどう違うのかを解説することで、皆さんが最適な開発環境を選択する上でのヒントになればと思います。キーワードは「オープンネス」です。

Orion / git とは何か

Orion とは、Eclipse Foundation が開発する Web ベースの開発環境で、IBM i ではオープン・ソース・プロダクト（5733-OPS）のオプションとして提供されます。Orion の Web ページのトップには「A modern, open source software development environment that runs in the cloud.」と書いてありますが、要するにクライアント側は Web ブラウザを経由してクラウド上で実行されるオープン・ソースのソフトウェア開発環境にアクセスするという仕組みです。 「Web ベース」なので RDi のようにクライアントにインストールするといったセットアップ作業は必要なく、インターネットにアクセスする PC とブラウザがあれば良いことになります。RDi が稼働する OS は Windows と Linux ですが、Orion はインストールする必要がないため、Mac などのクライアントも利用することができる点は見逃せません。また、タブレット端末もアクセス可能となるため、本格的な開発は無理でもちょっとした確認作業などで利用することができるようになります。 もう一つの git はバージョン管理システム（Version Control System）です。もともとは Linux のカーネルの開発プロジェクトで利用するために、リーナス・トーバルズ氏によって開発された VCS です。git も Orion 同様にオープン・ソース・プロダクトのオプションとして提供されています。

参考01：Orion サービスサイト

参考02：Git サービスサイト

Orion の仕組み

Orion は、「クラウド上で稼働する」オープン・ソースのソフトウエア開発環境ですが、IBM i で提供される Orion はもちろん IBM i 上で稼働します。開発者はブラウザ・ソフトを使用して IBM i 上の Orion サーバーにアクセスし、プログラムのソースコードを編集します。SEU や RDi で編集されたソースコードはソース・ファイルという特別なファイルに保管されますが、Orion で編集したコードは IBM i のファイルシステム IFS の指定したディレクトリに、個別のファイルとして保管されます。 IBM i 上で Orion サーバーを開始するためには、正しく導入されていれば以下のシェル・スクリプトを実行するだけで OK です。

• /QOpenSys/QIBM/ProdData/OPS/Orion/orion

通常は、この開始シェル・スクリプトをスケジュール登録しておくと良いでしょう。終了させるには以下のスクリプトを実行します。

• /QOpenSys/QIBM/ProdData/OPS/Orion/stopOrion

稼働した Orion サーバーはポート番号 2025 で待機するので、ブラウザからは http プロトコルでポート番号 2025 にアクセスします。Orion サーバーが正しく稼働していると最初の画面が表示されます。ここでサインインもしくはユーザー登録をすることになります。 ここでひとつ、注意しなくてはならないことがあります。通常 IBM i が提供するライセンス・プロダクトは OS と密接に連携することを前提に IBM によって提供されており、そのプロダクトは IBM i のユーザー・プロファイルを利用します。しかし、Orion はオープン・ソース・プロダクトであり開発は IBM ではないため、IBM i のユーザー・プロファイルは使用しません。そのため、Orion を使用する開発者は初めて Orion サーバーにアクセスする時にユーザー登録（Register）を行う必要があります。登録ユーザーは Orion 専用のユーザーであり、IBM i のユーザー・プロファイルが作成されるわけではない点に注意してください。 ユーザーを登録してサインインすると、そのユーザー用に作成されたソース・コードを保管するディレクトリが表示されます。最初はフォルダが何もないので、必要に応じてプロジェクトおよびフォルダを作成し、その中にソース・コードをファイルとして追加し、コードを記述することになります。 Orion では、エディタでソースを修正する際、変更はその都度自動的に IFS 上に保管されます。そのため、SEU の終了時や RDi のエディタのクローズ時のように保管するかどうかを聞かれることはありません。

git の仕組み

git も Orion 同様のオープン・ソース・プロダクトで、ソース・コードのバージョン管理を行うツールです。Orion と同様、IBM i のネイティブ環境で稼働しますので、別途サーバーを用意する必要はありません。バージョン管理を行うツールには前回の記事でも紹介した Subversion があり、以前は IBM i 上で稼働するものが存在していた時期もありました（IBM 以外の企業が公開していたものです）。現在は公開ページそのものが存在していませんので、ネイティブで稼働する VCS は実質 git のみということになります。 git の詳細な仕組みはここでは解説しませんが、リポジトリを作成し、ソース・コードの修正の都度リポジトリにコミットすることで修正履歴を記録していくという手順は Subversion と同様です。git が異なるのは、通常コミットするリポジトリはユーザー単位のローカル・リポジトリであり、複数ユーザーはさらにその上のリモート・リポジトリを経由してソース・コードを共有することになるということです。リモート・リポジトリは、IBM i 上に構築することもできるし、別サーバーを経由することも可能です。インターネット上には git のホスティング・サービスが有償・無償の違いはありますが幾つか提供されていますので、別途サーバーを構築せずにこれらのサービスを利用することにより、システム開発のプロジェクトのメンバーがどこにいるかにかかわらず、開発を行うことが可能になります。特にオフショア開発には威力を発揮することになるでしょう。 Orion には、ローカルの git リポジトリへのアクセスがあらかじめ用意されているので、特別な設定をすることなく連携することが可能です。これから FFRPG を使い始めるという方には、ぜひこの Orion + git の組み合わせで開発を初めていただきたいと思います。なお、リモート・リポジトリを IBM i に構成するには追加の設定が必要になります。 RDi には git にアクセスするためのプラグインが用意されていますので、それをセットアップすれば IBM i 上の git に RDi からアクセスすることも可能です。開発ツールは RDi を利用し、VCS は IBM i 上の git という組み合わせもありですね。

RDi と Orion の比較

Orion を利用したソース・コードの修正は直接 IBM i に保管されるので、RDi のリモート・システム・エクスプローラー（RSE）経由の場合と同様、クライアントにソースが保管されることはありません。RDi プロジェクトの場合、ソース・コードはクライアントに保管されるため、IBM i でコンパイルするためには、別途プッシュする必要があるのは前回の記事で説明した通りです。 では、コンパイルについてはどういった手順になるのでしょうか。RDi には、RSE 経由でコマンドを実行することができるため、GUI 環境からコンパイル・コマンドを直接実行させることができますが、Orion にはその機能は提供されていません。開発が IBM ではないことを考えると当たり前ですね。このため、Orion のインターフェースを経由してコンパイルすることはできないので、別途 5250 画面か、あるいは Shell インターフェース経由で予め用意したスクリプトなどを実行する必要があります。 開発ツールがなんであれ、RPG のソース・コードをコンパイルするコマンドは共通です。

• RPG Ⅲ：CRTRPGPGM
• RPG Ⅳ（FFRPG）：CRTRPGMOD

RPG IV のコンパイラーは *MODULE オブジェクトを生成するのみなので、CRTPGM コマンドを実行して *PGM オブジェクトを作成する必要があります。１つのモジュール・オブジェクトからプログラムを作成する場合は、CRTBNDRPG と CRTPGM を一度に実行する CRTBNDRPG コマンドを利用することもできます。 ソース・コードという点ではどのツールで作成されても同じですが、Orion を利用した場合はそれが IFS に保管されるため、CRTRPGPGM コマンドを利用してそのソースからコンパイルすることはできません。このコマンドはコンパイル元のソースが IFS 上にあることを想定して作られていないためです。CRTRPGMOD と CRTBNDRPG コマンドは、コンパイル元のソースとしてソース・ファイルと IFS のどちらも指定することが可能です。 Orion は IBM が開発したものではないため、RPG の定位置記入形式の入力をサポートするプロンプト機能も提供されていません。そのため、RPG Ⅲ および 定位置記入形式を含む RPG Ⅳ のソース・コードの修正は不可能とは言いませんが、現実的ではないと思います。 CRTRPGPGM コマンドは IFS 上のソース・コードからコンパイルできないこと、RPG のプロンプト機能をサポートしていないことを踏まえると、Orion は事実上 FFRPG 専用の開発環境ということが言えると思います。

Orion と git を使った開発の実際

Orion と git は、ライセンス・プログラムが正しく導入されていれば、複雑なセットアップ手順を経由することなく使い始めることができます。ただし、コンパイルを行うには注意しなければならない点があるのでここで解説しておきたいと思います。 Orion で作成および修正したソース・コードは IFS にファイルとして保管されることはすでに説明しましたが、このファイルは CCSID が 1208 で保管されます。1208 はUnicode形式なのですが、CRTRPGMOD あるいは CRTBNDRPG コマンドでは、Unicodeで保管されたソース・コードはサポートしません。このため、Orion で作成されたソース・コードをコンパイル前に別の CCSID に変換する必要があります。IFS 上のファイルをコピーする CPY コマンドには CCSID を変換する機能（FROMCCSID と TOCCSID）があるので、このコマンドをコンパイル前に実行し、変換後のファイルを使用してコンパイルする必要があるのです。 しかし、CPY コマンドを使用する場合は、毎回ソースを変更するたびにコンパイル前に実行しなければならないため、あまり現実的ではありません。この問題を解決するために以下の PTF が用意されています。資料を参考にして、この PTF が適用されていなければ導入してください。

• APAR#SE65069：
  http://www-01.ibm.com/support/docview.wss?uid=nas2SE65069
• Compile RPG from Unicode：
  https://ibm.biz/Bdr6K8

PTF が適用されると CRTRPGMOD および CRTBNDRPG コマンドに TGTCCSID パラメータが追加されます。このパラメータは、指定されたソース・コードをコンパイル前にどの CCSID に変換するかを指定するものです。以下を指定することができます。

• 1-65534：変換後の CCSID
• *SRC：ソース・コードのファイルの CCSID（省略値。Orion が生成するファイルは 1208 なので常にエラーとなる。）*JOB：変換後の CCSID は JOB の CCSID を使用

日本で利用されている IBM i は QCCSID システム値が 5035 で運用されていることが多いはずですから、この TGTCCSID には *JOB もしくは 5035 を指定すれば、前出の CPY コマンドを事前に実行しなくても Orion が生成したファイルを直接指定してコンパイルすることができるようになります。 では git の利用について簡単にみていきましょう。git のリポジトリはローカルとリモートの２種類あることはすでに説明しました。ローカルとリモートの2つのリポジトリをどのように運用していくのが適切かは様々な意見がありますので、皆さんもネットなどで検索していただくと良いと思いますが、一般的にはローカル・リポジトリには頻繁にコミットし、リモート・リポジトリにはあるまとまりでプッシュするのが良いと思います。このまとまりとは、例えば前回の記事で触れた BTS のチケット単位などです。VCS をどのように利用するのかも、プロジェクト毎もしくは会社単位でコミットおよびプッシュの頻度やコメントの書き方などの標準化を進められることを推奨します。

おわりに

Orion は他の IBM i ライセンス・プログラムとは異なり、他言語や他プラットフォームの開発者にとって、違和感のない環境です。この開発環境をいち早く用意し、FFRPG を積極的に利用することで、IBM i の開発プロジェクトに多くの技術者が参加する可能性を広げることができるでしょう。IT 技術者の高齢化問題が取りざたされる中、特にこれからの RPG 技術者の育成には、RDi と今回の Orion + git が不可欠だと思います。 これまでの記事で触れてきた IBM i の開発環境をまとめると以下になります。

1. SEU + PDM
2. RDi + オープン・ソースの VCS
3. Orion + git

まだまだ現役で稼働している RPG Ⅲ で構築されたシステムの保守用としては「SEU + PDM」、これからのスタンダードとしては「RDi + オープン・ソースの VCS」、そして FFRPG 限定で利用できる「Orion + git」というこの３つの利用形態全てが、最新の OS でサポートされていることを今一度確認し、技術者の立ち位置やバックグラウンドを考慮して最適な開発環境を選択していきましょう。 東京大学のある研究室が公開している「進化とオープンネス」というページがあります（http://sacral.c.u-tokyo.ac.jp/event/gakusaikagakuka.html）。そこには、「ここでいうオープンネスとは、情報や知識、構造やパターンが固定化されず、つねに変動しながら成長していくという意味である。」と記されています。こじつけになるかもしれませんが、IBM i は「常に変動しながら成長して」いると思いますし、その過程において良いものは積極的に取り入れています。その最たるものがオープン・ソース環境であり、この記事で紹介した Orion や git なのです。常に成長している IBM i をもっともっと深く知って、積極的に「変動しながら成長している」機能を使っていきましょう！

著者プロフィール