CLの最新版は最高
V6R1で加わった多数の改善点
15年前、私は、シカゴのとある大手銀行で、メインフレームのテープ操作係兼主端末のオペレーター(MTO: Master Terminal Operator)として働いていました。あるとき、IBMのメインフレームでCobolのプログラミングの仕事をしてみないかと打診を受けました。「実運用向けの」Cobolプログラミングは担当したことがなかったので、誰かに多少助けてもらう必要がありました。そこで、地元カレッジの社会人向け講座のCobol上級コースに参加しました。そのコースのインストラクターは、最近そのカレッジに導入されたAS/400という新しいマシン上で私たちにCobol 85を教えようといういたずらを思いたったのですが、これが、私のAS/400との出会いでした。Create Cobol Program (CRTCBLPGM) CLコマンドを使用して初めて自分のプログラムをコンパイルした途端、私は一目惚れしてしまいました。その後AS/400上での作業負荷を自動化するためのあらゆるコツや秘訣を学びましたが、その多くは今でも使えるものです。これは、IBMが下位互換性と簡素性を維持しつづけてくれたおかげです。
CLは非常に強力なユーティリティ言語であり続けていますが、そうであるがゆえに、そのプログラミングという観点から大きな機能強化が何年もなされてこなかったのだと思います。IBMは、コマンド処理用の強力なオブジェクト・インタフェースを構築することによりすばらしい成果を上げ、単に新しいコマンドを追加することで言語に対して改善を行ってきました。しかし、GOTOコマンドへの依存や単一ファイル処理の制限などといった、古いスタイルの制限には悩まされた人もいます。ところが、オペレーティング・システムのV5R3では、CLコンパイラの開発者たちは、IBMロチェスター事業所の i5/OSのリリース開発サイクルに合わせると決定しました。V5R3で提供される新しい機能が明らかになり、R5R4ではさらに新しい機能が増えるでしょう。V6R1も遅れをとりません。本稿では、最新リリースにおけるCLに関する主要な改善点について説明します。
コピーブック
最近ロチェスターに出張した際、CLコンパイラに関して IBMのトップ2である、ガイ･ヴィグ氏とフェルナンド・フータド氏に会う機会に恵まれました。今回の出張の目的は、新しいV6R1 CL機能のレビューでした。IBMは約10の新しい機能を追加し、100個以上の新しいCLコマンドも追加しました。こうした新しい機能のうち、構造化プログラミングの概念を引き継いでいる最もすばらしい機能の1つが、INCLUDEコマンドです。IBMは、CLコードの「コピーブック」を保存しておいて、CLプロシージャの中にインクルードできる機能を初めて提供しました。API プログラム呼び出し用に定義された構造フォーマット、VFYN0100をフォーマットするのに使用するDCLコマンド群を、図1に示します。そのAPI がどんなことをしてくれるのかについては、また後で説明します。メイン・プロシージャ内で使用しているINCLUDEコマンドの例を、図2に示します。INCLUDEコマンドのパラメータは、SRCMBRとSRCFILEです( IBMは、CLのソースをディレクトリのストリーム・ファイル中に保存する計画は直近にはないと示唆しています)。拡張ソース・ファイルをコンパイラに入力したときにどのようになるかを、図3に示します。こうすることで、頻繁に使用されるコード用のCLプログラム・オブジェクトを別に作る代わりに、プログラマは必要なコードを単にインクルードして、複数のCLプログラム全体に渡ってロジックの一貫性を維持することができます。
デフォルト値の*INCFILEは、適切な作成コマンド上に示されたソース・ファイルにコンパイラを指定します。作成コマンドのデフォルトが*SRCFILEであるので、標準値へ簡単にアクセスできます。標準のコピーブックを作成しておくと、あらゆるSystem i ショップのCLプログラミング環境にとって有用な資産となります。次に説明する機能は、その標準ファイルなどをオーバーライドする機能をサポートします。
コンパイル時オプション
図3には、Declare Processing Options (DCLPRCOPT)コマンドを組み入れるのに使用されている INCLUDEコマンドも示されています。DCLPRCOPTコマンドはV6R1で機能強化され、コンパイル時オプションが追加されました。これは、メインフレームの仕事から離れたために使わなくなって寂しい思いをしていた機能の1つで、ずいぶん待たされたような気分です。またこの機能は、COMMON Americas Advisory Council (CAAC)から送られた要望が一助となって追加された機能である、ということを特記しておきます。このCAACグループは、SMBやCOMMONのメンバーからの要望を集め、優先順位をつけてIBMの開発部門に提示する責任を担っています。CAACの詳細については、https://www.common.org/caac/を参照ください。
CLプログラムに必要な奇妙なコンパイラ・オプションをサポートするために、コマンドのデフォルトを変更したり、拡張コメントやドキュメントを記述したりしたことが何度あるでしょうか。DCLPRCOPT CLコマンドを使用すると、コンパイラ・コマンドの多数のパラメータをソース・メンバー中に(または、プログラム例に示す通り、INCLUDEコマンドを介して別のソース・メンバー中に)保存することができます。これは、RPGプログラムのH仕様のように動作します。DCLPRCOPTコマンドがサポートしている13個のパラメータを、図4に示します。コンパイラを使用すると、DCLPRCOPTのインスタンスは1つしか使えませんので、INCLUDEの使い方には注意してください。
DCLPRCOPTコマンドが、コンパイラに対してLOGとALWRTVSRCというパラメータ値を渡して、ソース・メンバーDCLPRC01中にどのように保存されているかを、図5に示します。選択されたオプションは、CRTCLPGMコマンドで入力された値を上書きします(DCLPRCOPTコマンドの方が優先権を持っています)。INCLUDEコマンドはコンパイル時に評価されるので、DCLPRCOPTコマンドはCLプログラムに対して、あたかも元々のソース・メンバーの一部であるかのように、追加されます(図3)。
またこの機能は、CLコマンドでも利用できます。最後に、CLコマンド・ソース中のCMDコマンドは、1つ以上のパラメータを持ちます。LOGの値とALWRTVSRCの値は、CRTCMDコマンドのコンパイル時オプションでしか利用できませんでしたが、CLコマンドの定義ソースに含めることもできるようになりました。コマンド・オブジェクトのソース・ファイル中にあるプロンプトされたCMDコマンド用の現在のパラメータを、図6に示します。
錯覚
もう1つの機能強化により、多言語のCLコマンド開発者は影響を受けます。IBMロチェスター事業所の開発者は、長年にわたって、各CLコマンドの各国語(NL: National Language)サポート用のコピーを、別々のNLライブラリとして複数個作成していました。プライマリ言語版CLコマンドは、製品ライブラリ(たとえば、ほとんどのi5/OSコマンドはQSYSライブラリ)に格納されていますが、セカンダリ言語版CLコマンドは、他のNLライブラリ(たとえば、イタリア語版のコマンドはQSYS2932ライブラリ)に格納されています。ライブラリ・リストを切り替えるだけで、System i が他の言語版のCLコマンドを提供してくれます。これはとてもすばらしい機能ではあるのですが、ロチェスター事業所の開発チームにとっては大変な労力を課しているのです。各コマンドのコピーを言語ライブラリごとに作成しなければならないからです。コマンドに何か変更があると、開発と品質保証作業を60以上の言語ライブラリに対して繰り返し行わなければなりません。このオーバーヘッドのことを考えると、新しいCLコマンドを得たということ自体驚きです。
この長くて複雑な品質保証サイクルを改善するため、ロチェスター事業所の開発者たちはメッセージ・ファイルの助けを借りて、CLコマンドのプロンプト・テキストを取り出しました。その結果、新しい*CMDオブジェクトは、これらのメッセージ・ファイルからプロンプト・メッセージを動的に取り出す機能をサポートできるようになりました。
プロンプト・テキストのメッセージ・ファイルは、製品ライブラリとセカンダリ言語ライブラリ中に収められて出荷されますが、IBMコマンド(*CMD)オブジェクトは製品ライブラリ中にのみ収められて出荷されるため、コマンドの保守と開発が容易に、しかも効率的にできるようになりました。これは開発者が膨大かつ余分なテストをせずに新しい機能改良に集中できるようになるという意味で、大きな改善だと言えます。
CHKOBJNMEコマンドのコマンド・オブジェクトのソースを、図7に示します。CMDコマンドのPMTFILEパラメータは、指定されたメッセージ・ファイルの中でプロンプト・メッセージを探すように、コマンド・コンパイラに伝えます。ここで紹介している例では、CHKMSGFという名前のファイル中でプロンプト・テキストのメッセージの記述を探すように指定されています。IBMは親切にもこの贅沢さをCLの開発者に対しても提供し、ユーザーが多言語環境におけるCLコマンドを使用したプログラミングの恩恵を受けられるようにしています。
オブジェクトとは何か
数年前、私がAS/400の操作を教えていたとき、生徒にオブジェクトの概念を紹介しました。生徒たちは、タイプ、属性、カプセル化などの概念を学ぶ際に、驚きと困惑の表情を浮かべてじっと聴き入っていました。そして最後に目玉として、オブジェクトを識別するために使用する、10文字のオブジェクト名と文字ライブラリの名前の付け方の約束事を紹介しました。V6R1の新しいAPI のおかげで、オブジェクト名やライブラリ名を検証するのがとても容易になりました。QCAVFYNMというAPI は、オブジェクト名を検証するという1つのミッションを考慮して作られました。例2に示したプログラム例は、このAPI を呼び出して、PGMコマンドが渡してきた値を調べるために特別に作成しました。API は3つの必須パラメータを受け取りますが、1番目のパラメータに必要なもののほとんどが含まれています(1番目のパラメータの構造を図8に示します)。
2番目のINCLUDEにあるソース・メンバー(図2)は、APIプログラムを呼び出すのに必要な構造の概要を示しています。ソース・メンバーを提供し、指定通りにパラメータ値をセットしてAPIを呼び出すだけです。CHKOBJコマンドと同様に、名前が正しいものであれば何も起こりません。名前が正しいものでないと、プログラムがCPF019Dエラーを生成します。このエラー用のMONMSGは、この「不正な名前」という事態の発生をトラップすることができます。
ここで示した例は、1回コンパイルすれば IBMが提供するAPIを完結するアプリケーションで構成されています。私はCHKOBJコマンドの大ファンです。オブジェクト名を検証するために IBMが開発したAPI を見たとき、CHKOBJと全く同様の動作をする独自のCLプログラムに組み込むコマンドを用意しなければならないと考えました。IBMが作ってくれなかったので、自分で作りました。このコマンドはCHKOBJコマンドとほとんど同じ動作をしますが、1つだけ違う点があります。SUPPESCパラメータを使用すると、コマンドラインから不正な名前でコマンドを呼び出してもエスケープ・メッセージを出力させないようにできます。2番目のパラメータを*YESに変更すると、不正なオブジェクト名が指定されたことを示す簡単なメッセージが、画面の最下部に表示されます。
IBMがなぜこのようなAPIを開発したのかは、推測することしかできません。ひょっとしたら、これが10文字のオブジェクト名を終焉させる第一歩なのでしょうか。データベース・オブジェクトがもっと長い名前を付けられるという特権をもっているので、システムの他の部分もそれに倣う時期がきたのです。ただしこれは私の憶測に過ぎず、IBMはこれを認めたわけでも否定したわけでもありません。
あのファイルを読む・・・もう一度
V5R4で、ロチェスター事業所の開発者たちは親切にも、CLプロシージャ中で複数のファイルを処理する機能を提供してくれました。今回のさらなる機能強化は、その柔軟性の上に、CLプロシージャ中でデータベース・ファイルを複数回読めるようにしたのです。CLの中でポジションを探し直して再度読むという操作をするためだけに、何度ファイルを読み直していましたか。新しいCLOSEコマンドは、オープンされたデータベース・ファイルをクローズすることで、もう一度オープンできるようにします。CLOSEコマンドは、RPGのcloseコマンドと同様に動作します。そしてもちろん、クローズ状態にあるファイルに対してCLOSEコマンドが実行されても、プロシージャが異常終了するようなエスケープ・メッセージは発行されません。
プログラム例のDIVPROCESS(図9)は、複数の部門からなる組織の1日の業務終了処理を行うものです。この仮想の組織では、全ての業務は、部門間の処理が実行される前に処理されていなければなりません。部門間の処理が完了すると、各部門の報告書が作成されますので、部門間の全ての収支報告が提示されます。この情報に基づいて、各部門に対して1つずつのレコードを含んだDIVMASTERというマスター・ファイルが作成されます。このファイルは業務終了処理のために読み込まれ、各部門用の業務トランザクションを1度に1つずつ実行します。次に、部門間業務が処理されます。最後に、DIVMASTERファイルがクローズされ、報告書作成処理用のサブルーチンが実行されるときに、マスター・ファイルが再び最初からオープンされます。V6R1以前のリリースでは、この処理には2つの別々のCLプログラムが必要でした。
将来に向けて
ガイ氏、フェルナンド氏の両氏は、CLプログラムの機能強化の道はこれで終わりではないことを私に約束してくれました。ナッシュビルで開催されたCOMMONでは、グレッグ・ヴィール氏が「CLの機能強化－過去、現在、未来」という題名のセッションを開いて、今後の機能強化の可能性について語り、フィードバックをIBMに直接送るように出席者にお願いしていました。フェルナンド氏へのご質問やコメントは、hurtado@mx1.ibm.comへお送りください。
ソフトウェアを開発したことのある人なら誰でも、複数のリリースはいつでもあることだと言うでしょう。これは、i5/OSのリリース・サイクルについても同様です。いまやCLコンパイラの開発者たちはリリース開発のサイクルに確実に乗るようになったので、そこから外れるつもりはないでしょう。CLの熱狂的なファンとして、私はこれからも同乗するつもりです。あなたもいかがでしょうか。
謝辞: i5/OSに関する変更について私とのディスカッションに多大な時間を割いてくださった、ガイ・ヴィグ氏とフェルナンド・フータド氏に感謝します。彼らの不断の努力はCLの開発の道筋を確実にするものであり、将来のリリースについてもより多くの機能強化をしていくことを彼らは約束してくれました。ロチェスター事業所の開発ライフ・サイクルに乗ることで、世界中のCLプログラマに対して継続的な機能強化を保証してくれたのです。また、ここで紹介した例などは、フランケン博士と彼のチーム(frankeni.com)が提供してくれたV6R1のベータ・マシン上で開発されたものです。また、この紳士たちは米国中を周って、COMMONで賞を獲得した「Pimp my i (私のかっこいい i)」というセッションを開き、ロチェスター事業所のエンジニアが赤面するような、いくつかの実験的なマシンのめまぐるしい旅に誘ってくれます。スペア部品があたりに転がっているような状態では自分たちの活動に責任を負えないと言っている彼らですから、是非ご覧になってください。
