NEWS
できるIBM i 7.4解剖 できるIBM i 7.4解剖
2022.05.20

【できるIBM i 7.4解剖】第14回「IBM i 7.4最近の開発環境動向」

【できるIBM i 7.4解剖】第14回「IBM i 7.4最近の開発環境動向」
できるIBM_i_7.4第14回 IBM i 7.4最近の開発環境動向

今回はいろいろな最近のIBM i 開発環境トピックについてご紹介いたします。

近年のIBM i 開発環境拡張の方向性

一言でいえばレガシーな5250開発環境は現行維持し、オープン系やクラウド開発基盤での標準を積極的に取り込んでいく、という事になると思います。別な言い方ですとDevOps対応をはじめとした開発環境モダナイゼーションと言えるでしょう。従来の(5250ベース、SRCPFにソース保存する)IBM i 開発環境は熟練者には非常に効率のいい環境であると(今でも)言う事ができます。一方でDevOps対応など特にオープン系に開発サイクルや方法、ツール等環境を共通化していきたいという面においては阻害要素になってしまう事があります。

IBM i の開発環境を今後どうしていくか、は開発者の趣向(5250ベースが好きかオープン系が好きか等)やIBM i とその他開発環境を共通化するか・しないか、DevOpsを推進するか・しないかといった視点で考えるのがわかりやすいと思います。

今回はベースラインとして5250とRPGⅢなどOPM言語での開発が中心のユーザーを設定してみます。そのうえで昨今のIBMで利用可能な様々な開発環境の機能拡張をご紹介したいと思います。

1.エディター、IDE

IBM i 開発環境としてエディター、IDE(統合開発環境)として最も歴史があるのは5250ベースのSEU/PDM等です。ですがSEUはIBM i 6.1で機能拡張が終了しており、IBM i 7.1以降のILE RPGなどの追加ステートメント等には対応していません。IBM i 7.1以降でもSEU/PDM等でソースコード編集、コンパイル等一連の開発はできますがIBM i 7.1以降で拡張されたステートメントチェックが働かないなど制限があります。IBM純正として登場したGUIベースのIDEがRational Developer for i(以下RDi)です。

RDiはオープンソースのeclipseベースです。(余談ですがeclipseも元はIBMがVisualAge新バージョンとして開発した資産をそっくりオープンソースに寄贈したものが最初のバージョンです)。Microsoft社製の標準的なエディターであるVisual Studio Code(以下VSCode)等と比較したRDiの一番のメリットは5250環境のSEUと同様なステートメントチェックが可能なこと、アウトライン機能でソース内の変数、標識、サブルーチンなどの構造を俯瞰できる事、コンパイルリストをソースに組込表示可能だったり、ヘルプメニューからIBM i の各種マニュアルにリンクしておりRDi内から検索可能なこと(図1)、標準状態でも右クリックで様々なIBM i開発機能が呼び出せる等、豊富な拡張機能がある点です。RDiの弱点は多機能ゆえに必要となるPCのスペックが比較的高いこと、動作がVSCode比ではやや重たく感じる点でしょう。

▲図1. RDiの例

VSCodeのメリットはRDiに比べ非常に軽量な操作感だと思います。また多くはユーザーサイドでの自己責任になると思いますが無数の拡張機能を組み込み自分好みにカスタマイズできる点です。反対にデメリットはRDiやSEU/PDMで提供される標準的な機能が提供されず、生産性に影響するかもしれない点でしょう。VSCodeは本来テキストでのソース開発が基本ですが、拡張機能をインストールすることでIBM i ライブラリー上のSRCPFの編集も可能になります(図2)

▲図2. VSCodeのRPG編集画面例

*図2で使用したVSCodeにはIBM i 拡張機能として以下を追加しています。Code for IBM i, Code Coverage for IBM i , IBM i Development Pack, IBM i Languages, RPG, RPGLE Free, RPGLE language tools

VSCodeの拡張機能を導入するには、VSCodeを起動して、画面左端の拡張機能アイコンをクリックします。図2-2のようにキーワード入力欄に RPG 等を入力すると拡張機能が検索できますので、必要なものを選択してインストールボタンをクリックします。

▲図2-2. VSCodeの拡張機能の導入画面

オープン系のエディター等はVSCode以外にも多数存在していますので、ご自身の開発スタイルにあったツールを選択することも可能です。その場合、エディターから直接コンパイルやデバッグはできないケースが大半だと思われますのでそれらを補う方法を考える必要があります。図3はコンパイルをACSから実行する、またはsshクライアントからshell実行する例です。

▲図3

2.RPGⅢを固定長のILE RPGソースに変換する CVTRPGSRCコマンド

RPGⅢソースをILR RPG(固定長フォーム)に変換するコマンドです。
事前準備操作は以下の通りです。

  • 準備1. 変換後のILE RPGを格納するソースファイルを作成する  CRTSRCPF FILE(DEMOLIB/QRPGLESRC) RCDLEN(112) IGCDTA(*YES)
  • 準備2. ILE RPG変換コマンド実行時のログファイルを作成する。テンプレートであるQRPGLEライブラリーのQARNCVTLGファイルをCRTDUPOBJコマンドで任意のライブラリーにQRNCVTLGという名前でコピーする。

CRTDUPOBJ OBJ(QARNCVTLG) FROMLIB(QRPGLE) OBJTYPE(*FILE) TOLIB(DEMOLIB) NEWOBJ(QRNCVTLG)

変換したいRPGⅢソースファイル(とメンバー名)を指定して変換コマンドを実行します。以下の例ではソースファイルの全メンバーを変換していますが、総称名や個別ソース名も指定できます。

CVTRPGSRC FROMFILE(DEMOLIB/QRPGSRC) FROMMBR(*ALL) TOFILE(DEMOLIB/QRPGLESRC) LOGFILE(DEMOLIB/QRNCVTLG)

変換が完了すると、図4のようにILE RPGソースが生成されます。

▲図4. 変換前RPGⅢ(左)と変換後ILE RPG(右)のソース例

3.ILE RPG固定フォームをフリーフォームRPGに変換する

ILE RPGには固定フォームとフリーフォームの二種類のコーディングスタイルがあります。私的には固定フォームとフリーフォームに機能的な差異・優劣はないと考えます。あくまでプログラマーの方の趣向や開発スタイルに合わせて選択していいものです。企業視点では、長期的な保守容易性の観点が重要なポイントになると思われます。あくまで筆者の経験上ですが、RPGⅢ開発に素養のある開発者は固定フォームを、VB, Java,phpなどオープン系言語に習熟した方はフリーフォームを好む傾向があるように思います。

固定フォームのILE RPGはRDiでフリーフォームに変換することが可能です。手順は固定フォームのソースを開いて、変換したいソース範囲を選択し、「選択をフリーフォームに変換」を実行します。(図5, 図6)

RDi以外でもARCAD CONVERTERなどのツールでもフリーフォーム変換できるツールがあります。

▲図5. RDiで固定フォームILE RPGをフリーフォームに変換する(BEFOR)

▲図6.RDiで固定フォームILE RPGをフリーフォームに変換する(AFTER)

4.ILE RPG, ILE COBOL等のソースをIFSテキスト化

IBM i はその前身S/38、S/36と共通でプログラムソースをソース物理ファイル(SRCPF)に格納します。SRCPFを編集する場合、5250ベースのエディタかRDi(Rational Developer for i)など専用のエディタ、環境が必要となります。またSRCPFのソースコードをバージョン管理する場合、オープン系のツールでは操作できずツールの組合せ等工夫が必要でした。昨今のILE言語はソースコードをIFS上にテキストファイルで作成できます。IFSテキストのソースファイルはRDi以外でも、VSCodeやOrionなどオープン系メジャーエディタに加え、メモ帳などWindows他クライアントの標準エディタでも編集可能です。テキストベースのソースファイルはそのままGitなどのリポジトリと連動して運用も容易となりますので導入検討の価値が高い方法でしょう。

ILEプログラムのソースはそのままテキストファイルをネットサーバーに新規作成する、Windowsなどクライアントで作成したテキストをftp, ネットサーバー等でIBM i IFSにPUTする等様々な方法が考えられます。RDiを使う方法が最も単純かもしれません。手順としてはRDi上で任意のIFSパスで、右クリック→新規作成→ファイル を選択し、IFS上にソーステキストファイルを作成します。

もし、SRCPFのソースをテキストソースにコピーしたいのなら、ソーステキストを右クリックしRDiに搭載されているLPEXエディターで開きます。同様にコピー元となるSRCPFのILE RPGソースをLPEXエディターで開いてすべてを選択してコピーし、ソーステキストに張り付けるだけです。RDiではそのままテキストソースを右クリックしてコンパイルが可能です。図7ではコンパイルせずに構文チェックする機能である、確認 をテキストソースに対して実行しています。

▲図7. RDiでテキストソースを確認(コンパイルチェック)する

▲図8.コンパイルチェックの結果表示

ソースにエラーがなければ同様にRDiのメニューからコンパイルコマンドを実行できます。図9は5250と同様なコンパイルプロンプト画面を表示してコンパイルする例です。ソースがIFSテキストになっている点がポイントです。RDiを使わずに5250画面からソースのIFSパスを指定してコンパイルもできます。

▲図9. テキストソールからコンパイル実行

ILEのコンパイルコマンドはソースファイルとしてIFSテキストを指定可能です。残念ながらRPGⅢ、OPM COBOLなどは対応していません。

5.RDiは2つの開発パターンがある

さて、これまで説明してきたRDiは基本的にはRPG, COBOL等のソースコードがIBM i 上にある前提をご説明しました。RDiではこの開発方式を リモートシステムエクスプローラー(RSE)と読んでいます。図1, 図5等のウィンドウの名称を見ると、RSE と表記されているのがわかります。RSEを一言でいうと、「5250環境で稼働するSEU, PDM, SDA等の機能をRDiのGUI開発環境(IDE)に置き換えたもの、と言えます。ユーザーが操作する画面が5250キャラクタかRDi GUIかの差異はありますが、IBM i 上では基本的に同じコマンド(ソース編集、コンパイル、デバッグ等)が実行されています。
RDiにはもう一つの開発パターンがあります。それをiプロジェクト と呼びます。iプロジェクトは、ソースコードをいったん、開発者のPC(またはソースコードサーバー(IBM i 上でも外部でも可)にコピーして開発し、ある程度完成したものを再びIBM i 上にコピー(プッシュ)してコンパイル、プログラムオブジェクトを作成する、というスタイルになります。つまり、iプロジェクトは複数人数(や複数社)での共同開発を前提としている、といういい方もできます。iプロジェクトで開発するには、RSEとは別な開発画面(パースペクティブ)である、iプロジェクト・パースペクティブを開く必要があります(図10)。詳細はRDi V9.6 操作ガイド をご参照ください。

RDi V9.6操作ガイド
https://iworldweb.info/library/rdi-v9-6_guide_dl

▲図10.RDiの2つの開発パターン

以上、IBM iの新しい開発環境について、いくつかのトピックスをご紹介しました。これで皆様が従来のSEU/PDMだけでなく、開発環境のモダナイゼーションをご検討いただく一助になれば幸いです。

筆者

日本アイ・ビー・エム株式会社
IBM Power Technical Sales 佐々木 幹雄

多数の執筆記事を、iWorldに寄稿中。

いいねと思ったらシェア
twitter
facebook
hatena
linkedin
できるIBM i 7.4解剖 目次を見る

この連載は…

できるIBM i 7.4解剖
あなたにオススメの連載
できるIBM i 温故知新編
9記事
できるIBM i 温故知新編
IBM i の”新”必須言語 〜FFRPG入門〜
14記事
IBM i の”新”必須言語 〜FFRPG入門〜
IBM i アプリの第二の柱 OSS
15記事
IBM i アプリの第二の柱 OSS
PAGE TOP