【第１回】PL/Iはオープン化できる

PL/I ってなに？

若い世代の技術者は PL/I の読み方すらご存じないかもしれません。PL/I（ピーエルワン）は Program Language One の略称で、手続き型プログラミング言語で主要な COBOL, FORTRAN, ALGOL などの長所を取り入れ、汎用性が高く、統一的な言語を目指して 1960 年代中期に開発されたプログラミング言語です。現れては消える言語が多い中、1970年代に提唱された「構造化プログラミング」を可能にした PL/I は半世紀以上経った今でも広い分野のメインフレームで動き続けており、その実績から堅牢性と信頼性を窺い知ることができます。

PL/I の特徴ってなに？

PL/I には商用計算と科学技術計算に適した関数や構造体などの複合的なデータ型を記述できるメリットがあり、日本では製造、金融、保険業で多く使用されています。また、変数のスコープ概念、ポインター変数によるデータ参照、動的メモリの確保など、システムプログラミング向けの概念を持ち、かつ幅広い仕様を持つ言語です。

誕生した当時のハードウェア環境では、できるだけメモリを消費せずに効率よくデータ処理を実行するコーディングを要求されており、ここが技術者の腕の見せ所でもありました。近年の環境では厳密なメモリ制限を要求されることは稀ですが、実際に当時のプログラムを読むと BIT データ型属性を利用した判定などの工夫が随所に見受けられ、「細かいところに手が届く」言語とも言えるのではないでしょうか。

PL/I はメインフレームだけ？

冒頭文の通り、「PL/I はメインフレームでのみ稼働する」という印象を持たれている方も多くいらっしゃると思いますが、PL/I コンパイラとランタイムを持つ Micro Focus Enterprise Developer / Server 製品を利用すれば IBM メインフレームで動いている PL/I をオープン環境で稼働させることができます。

（製品機能概要はこちら）

JCL, CICS, IMS はどうするの？

PL/I はプログラミング言語ですから、当然それをキックする JCL や CICS といったミドルウェアと一緒にシステムを構築し、IBM メインフレーム標準のファイルや IMS データベースを使用してデータを運用していることが一般的です。これらのミドルウェアを一緒にオープン環境へ移行できない場合は、JCL をスクリプトなどへ書き換える、CICS, IMS 構文を修正する、IMS DB を RDB に置き換えるなどの作業が発生し、「オープン化で運用コストを削減したいけれど、書き換える予算もないし不安だから現状維持するか」と、システム移行をあきらめる一因になってはいないでしょうか。

Micro Focus Enterprise Developer / Server 製品はこれらのミドルウェアをサポートする機能をご提供しているため、必要最小限の改修でクラウドを含むオープン環境へ JCL, CICS, IMS と共に PL/I を移行することができます。

【リホストへのステップ例】

また、システム移行ではどのようなソリューションを選択するかによりコストに大きく差がでます。良い機会だからと大きくアプリケーションの仕様を変更すると全ての機能においてテストが必要になり、問題が発生しても原因の切り分けが非常に難しくなります。これにより、さらにテスト工数、改修工数が増加するという負のスパイラルに陥り、リリース時期が大幅に遅れる、または断念する要因になり得ます。

安全かつ確実にオープン化を目指すためには、IBM メインフレームとの新旧の結果比較が可能なリホストソリューションを選択し、安定稼働が実現したのちにフェーズを分けてシステムのモダナイゼーションを実施することが、結果的にはリスクを排除した着実なシステム移行につながります。

どうやって PL/I をオープン化するの？

PL/I のオープン化を計画したいけれど、なにをどうすれば良いのか具体的なイメージが湧かないという声をよくお聞きします。

まず、どんな移行ツールであっても必ず共通の課題となるのは「文字コード」でしょうか。IBM メインフレームではソースコードを含む全ての文字は EBCDIC 文字コードで管理されていますが、オープン環境では一般的に ASCII/SJIS 文字コードが使用されます。もちろん PL/I ソースも IBM メインフレームでは EBCDIC 文字コードで保存されていますので、これをASCII/SJIS 文字コードに変換しなければ、例えば Windows 上のテキストエディタでソースを開いても文字化けして読むことができません。日本語の前後にあるシフトコードも ASCII/SJIS 文字コードでは不要になるなど、プラットフォームが変わることにより避けられない事柄がいくつかあり、検討が必要になります。

このようなお悩みや、具体的になにをどのように移行するかについて説明したホワイトペーパーを公開しています。ぜひご一読ください。

【 ホワイトペーパー：COBOL, PL/I アプリケーションのリホスト手順と注意点 】

https://www.amc.rocketsoftware.co.jp/pdf/products/enterprise/whitepaper/enterprise-developer/Enterprise_Rehost_COBOL_PLI_v1.pdf

オープン環境で PL/I の開発はできるの？

具体的な開発環境が不透明なため、システム移行後の生産性低下やテスト工数の増加を懸念している方もいらっしゃるのではないでしょうか。

PL/I の開発作業に使用する Micro Focus Enterprise Developer 製品はテスト用の実行機能を含んでいるので、ミニメインフレームを占有するイメージで JCL や TN3270 エミュレータを利用した CICS オンライン処理を実行しながら PL/I のテストを効率よく実施することができます。

開発環境では Windows OS 上の Eclipse, Visual Studio といった他プログラミング言語の技術者と同じ統合開発環境（IDE）を使用することができ、コンパイルやテスト実行、ステップ実行しながらデバッグを実施することができます。IDE が不要な技術者は、テキストエディタを使用してソースをメンテナンスし、コマンドによってコンパイルする方法を選択することもできます。

開発環境でテストされた PL/I アプリケーションは、本番環境にインストールされたランタイムのみを持つ Micro Focus Enterprise Server 製品を利用し、用途ごとに作成された Enterprise Server インスタンスにディプロイして運用します。

【Enterprise Server インスタンス一覧】

これらの機能を詳しく説明しているホワイトペーパーを公開していますので、開発環境をぜひ疑似体験してみてください。

【ホワイトペーパー：Micro Focus Enterprise Developer を使用した PL/I 開発業務のモダナイゼーション】

https://www.amc.rocketsoftware.co.jp/pdf/products/enterprise/whitepaper/enterprise-developer/Enterprise_PLI_DevModernization_v1.pdf

オープン環境で外部ツールを連携できるの？

メインフレームではベンダーが用意した機能を利用することが多く、これらの機能が OS に依存するものなのか、他製品が提供するものなのか意識することは少ないと思います。このベンダー独自に追加された機能がブラックボックス化し、システム移行の妨げになる例もあることから、まずは OS 以外にどんな製品が追加されているのか、その追加製品のなにをどこで使用しているのかを把握することが大切になります。

大変そうに見える工程ですが、オープン環境で追加機能を補うツールはコストやニーズにマッチしたものを自由に選択でき、かつベンダーロックインされないことから、これによるコスト削減も望めるメリットがあります。

実行機能である Enterprise Server インスタンスは様々なオープン環境の外部ツールと連携することができます。例えば JCL の実行によく利用されるジョブスケジューラでは、スクリプトやシェルに Micro Focus のコマンドを利用して実行させることができます。

【動作検証報告書：Micro Focus 実行環境と A-AUTO 連携】

https://www.amc.rocketsoftware.co.jp/pdf/products/enterprise/verification-report/white_paper_073.pdf

また、セキュリティ要件がある場合には LDAP や Active Directory と連携してセキュアなシステム運用を実現できます。

【動作検証報告書：OpenLDAP と連携した Enterprise Server セキュリティ】

https://www.amc.rocketsoftware.co.jp/pdf/products/enterprise/verification-report/white_paper_081.pdf

【 外部ツールとの連携例 】

リホスト後のモダナイズはどうするの？

リホスト後というと遠い未来の話と思われがちですが、将来のシステム構成図を想定したうえでプラットフォームを決定し、製品の選択をすることが IT 部門の責任者に求められる責務ではないでしょうか。ただ「リホストして終わり」という製品では、次のステップにかかるコストや再選定のための時間がさらに必要になるうえに、リホストのメリットである利用ユーザーに負担をかけない点を「なにも変わっていない」と判断されかねません。

移行ツールは、リホストだけではなくその後になにができるのか、最新技術と連携できるのか、新しい技術を取り入れ進化しているかを吟味して選択することが企業の経営戦略においても重要です。

COBOL が対象ですが、Micro Focus Enterprise Developer / Server 製品は次の機能を含んでいます。

1. JVM や .NET フレームワーク上で稼働する Java クラス、.NET クラス に COBOL ソースをコンパイルすることができます。（マネージ COBOL）
2. REST, SOAP 形式の Web サービスとして展開できる COBOL 専用のアプリケーションサーバー機能を含んでいます。（ネイティブ COBOL）
3. EJB として連携することができ、JCA 標準仕様に基づいたアプリケーションサーバーと連携することができます。（ネイティブ COBOL）

上記のネイティブ COBOL からは PL/I 呼び出すことができるため、モダナイズ後も PL/I を引き続き使用することもできます。PL/I と COBOL 間の呼び出し方法については一定のコーディング規則があり、これについては「Micro Focus Enterprise Developer を使用したPL/I 開発業務のモダナイゼーション」ホワイトペーパーで解説しています。
また、PL/I はコンテナ型仮想化に対応しているため、マイクロサービスを展開する際に利用することもできます。

【 マイグレーションへのステップ例 】

おわりに

PL/I もオープン環境で活躍できることをご理解いただけたでしょうか。

多様性が叫ばれる現代ではシステム構成においても固執せず、例えばオンライン処理が得意なプログラム言語、バッチ処理が得意なプログラム言語、計算モジュールのみに使用するプログラム言語など、適材適所のシステム構成を実現することも選択肢の１つです。

多くのプログラム言語を操ることは困難にも思えますが、企業にとっても技術者本人にとっても大きな意味を持つものです。技術者にとっては、言語間の比較、長所や短所の把握、スキルアップができ、その豊富な知識から、アプリケーションが担う機能に最適な言語の選択ができるようになります。これが結果的に企業の経営戦略に沿った、柔軟かつ迅速に対応できるシステムの構築につながるのではないでしょうか。

最後に、PL/I のオープン化に成功した日本の事例をホームページにて公開していますので、ご参考になさってください。

【 事例 】

https://www.amc.rocketsoftware.co.jp/mfproducts/enterprise/cases/

PL/I の移行に関するご相談やご不明点は次の URL からお気軽にお問合せください。

【 お問い合わせ 】

https://www.amc.rocketsoftware.co.jp/about/contact/