text：小川 誠 ティアンドトラスト
長らくRPGプログラマーを支えてきた
ツールの存在意義とメリット
IBM i のシステム構築に欠かせないツールは長い間、開発者の仕事を支えてきた。代表的なのがPDMとSEU である（図表4）。IBM i の管理者やプログラマーにとって欠かせないツールだが、長く使い続けたことによる弊害も生まれている。
まずその存在意義を明らかにし、次にその弊害について考えてみたい。
PDMとSEU はOS標準機能ではなく、別途購入する必要のあるライセンスではあるが、特殊なIBM i（本稼働システムで開発を一切しない、など）を除き、ほとんどのIBM iに導入されている。
ここでプログラム開発の過程とツールの関連を簡単にまとめてみよう。システム開発をプログラム作成と捉えた場合、以下の作業が必要になる。
・プログラムソースを記述し、しかるべき場所に保存する
・ソースコードをOSが実行できるコードに変換する（コンパイル。必要のない言語もある）
上記は言語の種類を問わず、必要なステップである。IBM iではほとんどの場合、開発言語はRPGかCOBOLであるが、伝統的にプログラムのコードはソース・ファイルというオブジェクトのメンバーにまず保存する。この作業を担うツールが SEU である。
そのためSEUコマンドには、ソース・ファイル名とメンバー名を指定することが必須であり、RPGやCOBOLのプログラマーは例外なくSEUに習熟している。IBM iの世界で人気エディタランキングが存在するなら、間違いなく圧倒的な1位である。
SEU の優れている点は、RPG という言語の特性（定位置記入形式）に合わせた入力補完機能（プロンプト機能）を備えていることである。基幹システムの開発言語としてRPG Ⅲはまだまだ現役であり、既存プログラムの保守がメインであれば、SEUはこれからも現役であり続けるだろう。
SEUで登録したソースコードから実行コードにコンパイルするには、然るべきコマンドを実行する必要がある。このコマンドは言語の種類によって異なり、指定できるパラメータも異なる。もちろん 5250で直接コマンドを入力して実行することが基本だが、これをより効率よく実行できる環境を提供するのが PDM である。
PDMは対象となるソースコードのリストから、処理したいソースに対してオプション（それぞれが特定のコマンドにあらかじめ関連付けられている）を実行することで、コンパイル作業が実行できる。
ライブラリーやオブジェクトも一覧表示して処理の対象にできるので、各ライブラリーやオブジェクトに対して該当のオプション番号を指定することで、いろいろなコマンドを処理できる。
プログラマーの毎日の仕事のルーチンは、5250 画面でサインオンし、プログラムを作成したり、修正したりが中心なので、日々使用するコマンドは番号で指定できれば最も便利である。IBM i の世界でこういった開発ツールの人気ランキングが存在するなら、間違いなく PDM も圧倒的な1位である。
後述するが、プログラミング言語は何がよいかと問われた時、その選択理由として「使用人口が多い」ことがよく挙げられる。その理屈でいくと、SEUやPDM を否定する理由は何もないことになる。
PDMやSEU が便利なのは、ソースコードをソース・ファイルのメンバーに保存する必要がある（コンパイラーがメンバーからコンパイルするようにできている）言語の開発時である。具体的には定位置記入方式のRPG ⅢやRPG IV、COBOL、CLPなどのOPM言語で、かつ現役で稼働するシステムのプログラムである場合だ。
おそらくほとんどのシステムはOPMオブジェクトの占める割合がまだ高いはずなので、結果的にPDMとSEU は現在でも主力ツールである。IBM i というプラットフォームを使う開発者であれば、「知っておいて損はないツール」というより、「知って使いこなす必要のあるツール」である。
5250の表示制約や機能拡張の停止
2つのツールがもたらす弊害
次に、このツールの弊害について考えてみよう。
1つ目の弊害は、SEU が 5250 画面でしか利用できないことである。5250 の画面サイズは横80桁×縦24行（設定によっては横132桁×縦27行）しかない。24行表示といっても画面の上部と下部にコード以外を表示する領域が数行必要なので、一度に視認できるソースコードは20行程度である。
どれだけ技術が進歩して大画面で高解像度のディスプレイが驚くほど安価に入手できたとしても、このサイズ感は変わらない。
2つ目の弊害は、SEUがすでにV6.1の時点（2009年）で機能拡張を停止していることである。10年以上も前のことだ。RPG IVは現役にも関わらず、機能拡張が停止していることはつまり、「SEUはRPG Ⅲ専用で、RPG IVは別のツールを使う」ことを意味する。
これも後述するが、RPG IVを完全に自由構文で記述するフリーフォームRPG（以下、FF RPG）はそのずっと後に登場するので、SEUではFF RPG のソースコードを適切に扱えない。SEU を使っている限り、IBM i の最新開発言語のコードは記述できないことになる。
3つ目の弊害は、プログラムのソースコードがIBM iのソース・ファイルにしか存在せず、ソースの変更履歴を管理する機能を搭載していないことである。
ソースコードがIBM iに存在する必要があるのは基本的にはコンパイル時のみだが、SEU を使っている以上はそこにしかアクセスできないので、ソース・ファイルがコードの唯一の保管場所という働きを兼ねる。
変更履歴を残す機能はOSには搭載されていないので（アイエステクノポートの「i-SM4d」などツールとして提供されている例はある）、コードの修正時には、万一に備えて別メンバーとして変更前にコードをコピーし、それから修正するという手順を踏むことになる。
どこを変更したのかはコード内にコメントとして記述されるが、人によって書き方が異なり、長く使われるプログラムのコードでは変更履歴コメントが増える。その結果、SEU でソースを開いた際に変更コメントが相当の割合を占め、さらに変更点がどこかもよくわからない状態となる。
ただでさえ画面の表示行が少ないのに、長期間使用されるプログラムのコードは、コメントによってコードの見通しが悪くなる（結果的に保守の難易度が高まる）。
またPDMに関しても、5250画面専用であるという足かせは付いて回る。結局、エミュレータを導入したPCでないと使用できない。
そして何より、SEUとPDMはIBM iの世界でしか使用できないツールである。この点をもう少し真剣に考えるべきであろう。どんなにこのツールを使いこなせても、IBM i以外のプラットフォームでは役に立たないのだから。
AS/400が発表された30年以上も前の環境では、AS/400単体ですべての業務が完結していたから問題ないが、今はそうではない。PDMとSEUを使い続ける限り、RPG Ⅲの時代より先に進むことはないし、ましてやDXは実現できない。できるなら、PDMやSEUは今すぐ使用を停止するぐらいの覚悟をもつべきだと思う。
◎ IBM iの開発環境を見直そう
・IBM iとDX｜ IBM iはレガシーを継承しつつ、新しい技術基盤を併せもつ
・PDMとSEU ｜ IBM iの開発に欠かせない2つのツールがもつ強みと考慮点
・IBM iとモダナイゼーション｜ これからのIBM i開発に求められる機能とは
・これからの開発環境｜ ソースコード管理を起点に理想的な開発環境を考える（近日公開）
著者｜小川 誠氏
ティアンドトラスト株式会社
常務取締役
1989年、エス・イー・ラボ入社。その後、1993年にティアンドトラストに入社。システム/38 から IBM i まで、さまざまな開発プロジェクトに参加。またAS/400 、IBM i の機能拡張に伴い、他プラットフォームとの連携機能開発も手掛ける。IBM i 関連の多彩な教育コンテンツの作成や研修、セミナーなども担当。2021年6月から現職。
［i Magazine 2021 Summer（2021年7月）掲載］
