ガイ・ヴィグ著

本記事の執筆を依頼されたとき「CLは＊クールだけれど」と思いましたが、「待てよ、クールと思うかどうかは、記事を読む人によって違うのでは」と思い直しました。私はCLが約四半世紀前に「誕生」してからCLに取り組んできました。少なくとも本記事をお読みになるITプロフェッショナルの一部の方よりは、CLの経験が長いでしょうし、そうした方々が考える「クールな」プログラミング機能は、私が考えているものとは異なるかもしれません（＊クール：原文で著者はcoolと記して、素晴らしい、すごい、かっこいい、の意味を表現しようとしていますが、日本語の一語では表現しつくせないので敢えてクールとカナで表記しました）。

CLやiSeriesについて読むのは初めてで、CLが何であるかわからない読者がいらっしゃるかもしれないのでご説明すると、CLはControl Languageの略語です。CLという用語はiSeriesアプリケーションの開発者が、CLコマンド定義、CLコマンド文字列、CLバッチ・ファイル、コンパイル済みCLプログラムなどを参照する際などに広く使用します。実際、iSeriesアプリケーションの開発者の中にはCLを名詞として使用し、「私はCLが書けます」のように言う人が少なくありません。

第三者の評価

お客様がCLのどんな点を気に入っているのか、あるいはどこに惚れ込んでいるのかを理解するには、私はCLの開発関係者としてあまりに内部の立場でありすぎるのではということも心配でした。1970年代に科学電卓のメーカーが行った市場研究を思い出しました。このメーカーは、自社の電卓について顧客が一番気に入っている機能は何かを調べようとしていました。このメーカーのエンジニアは、平方根の計算速度や浮動小数点の計算精度が下位桁でどれだけ維持されるのか、などといった回答を期待していたのでした。

ところが調査結果で実際にわかったのは、顧客が気に入っている機能の上位二つは、数値の表示の色がクールな青であることと、電卓の裏側にすっきりとした小型のゴムの足がついていることでした。同社のマーケティング担当とエンジニアがさらに調べてみると、ユーザーに気に入られたこれらの特徴が、最初に思っていたほど突飛でもなければ、取るに足らないものでもないということがわかりました。

顧客は、他社製の科学電卓が採用していた通常の緑色の数値表示に比べ、同社の青色の数値表示のほうがずっと見やすいと思っていることがわかったのです。ゴムの足も、角が少し丸められていて、電卓が机の上で滑らないように、かつ折れてしまうこともないように、程よく突き出ているのです。こうした実用的で現実的な利点には、開発関係者よりも顧客の方が気づきやすかったのです。

専門家の意見

そこで私は、CLの専門家の何人かに意見を聞くことにしました。いずれも、私と同じかそれ以上の長きにわたってCLを使っており、しかも実用CLアプリケーションを記述するのにCLを使っているという意味では私よりもずっと経験豊富な方ばかりです。まず、アル・バルサ氏に聞いてみました。バルサ氏はBarsa Consulting Group, LLC社の社長であり、AS/400およびiSeriesの可用性と障害回復の分野では有名な専門家で、CLユーザー歴も長い方です。

最近のCLのもっともクールな点についてのバルサ氏の最初のコメントは、V5R3で「IBMがついに目覚めて」長い間要望されていた言語の強化が行われたことについてでした。もう少し詳しく伺ってみると、「あのね、ガイさん。CLにはすばらしい機能がたくさんあるけれど、どれも、使っていてかなり退屈なんですよ。」というコメントが返ってきました。おっしゃりたいことはわかるのですが、iSeries NEWS誌の編集スタッフが、この記事の題名を「CLの退屈な点」に変えたがるとは思えませんでした。

バルサ氏はさらにこう続けました。「なんといってもクールなのは、V5R3で新しく機能強化されたCLコンパイラの機能を私がどれだけ使いこなしてプログラムをコンパイルし、V5R2システム上で実行させるかなんですよ。ちょっとした手品でしょ。文字変数や整数変数などのパラメータも拡張された点は本当に嬉しいのですが、でも先ほども申し上げた通り、退屈なのです。」

ここでくじけずに、私はジム・スローン氏に話を伺いました。スローン氏はIBMを退社し、Jim Sloan's CL Tips & Techniquesという著書をもつ、Jim Sloan社の社長です。スローン氏はIBMでの長いキャリアの中で、オペレーティング・システムの中のCLに関連した部分のコードを記述、保守していた開発者と一緒に働き、TAATOOLSというiSeriesおよびAS/400のユーザーなら誰でも知っているツール用のCLコマンドを自らCLを使って記述したこともあって、多くのお客様から「ミスターCL」と呼ばれていました。スローン氏は、気に入っているCLの特徴のリストを送ってくれました。そのほとんどはこれから私が本記事で説明するものです。しかし、このリストの中には「数字の青色表示」や「ゴムの足」のタイプの特徴もあるだろうか、と私は思いました。

最後にお話を伺ったのはCL Programming for the AS/400という本の著者でもあるグレッグ・ヴィール氏です。ヴィール氏は、「ここだけの話ですが、S/34やS/36用のOCL言語の方が、CLよりはるかにクールな組み込み機能を備えています。しかし、CLには真の実力があるのです。特にCLプログラムやCLプロシージャをコンパイルしてILEプログラムにバインドできる点などがそうです。」と書いてくれました。また同氏は、メッセージ処理関数やシンプルで強力な例外処理機能も「一種の」クールな機能であると述べています。

私の知っている外部のCLの専門家たちは、ユニークで強力なCLの特徴を「クール」と形容するのはちょっと難しいだろうと口を揃えました。本記事で説明する機能が「クール」か「退屈」かは、読者の方がCLの初心者か経験豊富なCLアプリケーションの開発者かによっても異なるでしょう。CLを「特別な」存在にしている特徴とそれぞれの特徴のバックグラウンド情報について、これから説明します。それがCLの知識を広げる手助けとなれば幸いです。

1. やりすぎのコマンド至上？

CLのソース言語はそのすべてがコマンドであるという意味でユニークです。コマンド文字列を生成してCLプログラムから実行できるということはコマンド・シェル・スクリプトでは当たり前のことですが、DCL(Declare Variable: 宣言変数) コマンドを使ってローカル変数を宣言したり、IFコマンドを使って条件チェックを行ったりできるコマンド・シェル・スクリプトが他にあるでしょうか。宣言文から制御フロー文や代入文に至るまですべてのCLソース文が実際にはコマンド文字列になっているため、CLの元々の設計者がこのコマンドにこだわりすぎたと思う人もいるかもしれません。

ちょっとやり過ぎでしょうか。多少はそうかも知れませんが、CLは他のいろいろなプログラミング言語でコードを記述したことがないような人にとっても、非常に習得しやすく使いやすいように設計されたものであるということを思い出してください。たとえばDCLコマンドを例にすると、経験豊富なCLのプログラマは変数の宣言文を目をつぶっても書けるでしょうが、初心者のCLプログラマは、条件プロンプトやオンラインのコマンド・ヘルプでDCLコマンドに入力を促してガイドしてもらって変数の宣言文の構文の誤りを直してほしいと思っているかもしれません。

2. 視覚的補強の喜び

CLのユーザーはCLのプロンプタをなぜ気に入っているのでしょう。その理由を数え上げてみましょう。CL以外のコマンド・シェルをお使いのユーザーを、私は気の毒に思っています。MS-DOSのコマンド・プロンプト・ウィンドウにコマンドを入力しようとも、Kornシェルやqshシェルなどといった数あるUnixベースのコマンド・シェルの一つを使っていようとも、コマンド文字列を生成する際には、ヘルプはないも同然だからです。CLのユーザーは、1981年のS/38のR2以来、コマンド・プロンプトのサポートを利用しています。これは、CLコマンド・プロンプトのサポートが20年以上も変わっていない、という意味ではありません。ただ、CL以外のコマンド・シェルは、CLが20年前にサポートしていたコマンド・プロンプト・サポートの水準にすら、いまだに達していないということを指摘したいのです。

CLのプロンプタ・サポートが登場した頃でさえ、プロンプト・テキストと呼ばれる、コマンドと各コマンドのパラメータ・フィールドの短いタイトルを表示していました。またユーザーはパラメータ・キーワード名を見ることもできましたが、キーワードを指定する必要はありませんでした。パラメータ値を入力すれば、実行するコマンド文字列を生成するときにプロンプタがキーワード名を付けてくれたのです。

また、プロンプタは入力を促されているコマンドのコマンド定義に指定されているデフォルトのパラメータ値を表示してくれるので、実行しようとしている動作を行わせるにはパラメータを指定しなければならないのかどうかなどということに関して、勘に頼った作業が不要でした。パラメータのデフォルト値が、指定したいと思っていた値と同じ場合は、そのパラメータを指定する必要はないので、コマンド文字列が短くなります。

またプロンプタは、必要なコマンド・パラメータに値が指定されていることを保証し、指定された値がすべて、関連したコマンド定義(*CMD)オブジェクトに格納されているパラメータ構文情報に適合していること(たとえば、十進数と定義されたパラメータに文字「A」は指定できないなど)を保証していました。

1988年にOS/400のR1の一部としてコマンド・プロンプタが機能強化されました。AS/400の「ミッション文」がS/36とS/38の両方の利点を取り入れる際に、S/36ユーザーがオペレータ制御言語(OCL: Operator Control Language)文用の条件プロンプトを使っていたため、CLプロンプタも機能強化されて階層プロンプトと条件プロンプトの両方を提供するようになりました。階層プロンプトを使用することにより、あまり頻繁には使用されないパラメータやコマンド･インタフェースの高度なユーザーしか使用しないパラメータを、CLコマンドの設計者が分離することができました。このようなめったに使用されないパラメータは、プロンプタを使用している人がそれを見るためにファンクション・キー(この場合F10)を押さない限り、表示させないようにすることができました。
条件プロンプトを使用することにより、コマンドの設計者は実行しようとしている特定の関数に適用できるパラメータだけを表示することで、プロンプタのユーザーをガイドすることができました。コマンド定義中で新しいPMTCTL(Prompt Control)文を使用すると、コマンドの設計者はパラメータが表示される場合と表示されない場合を定義することができました。

コマンド・プロンプトに対する大幅な機能強化の最後は、リリースV5R1のグラフィック・ユーザー・インタフェース(GUI)コマンド・プロンプタで、5250ワークステーション・セッションの画面上でしかコマンド・プロンプトを行えないという制限を取り除きました。最初のGUI CLコマンド・プロンプタはiSeries Access for Windows製品のiSeries Navigatorの一部として開発されました。二番目のGUIプロンプタはiSeries NavigatorプロンプタのJavaコードの大半を再利用し、iSeries Access for Web製品の一部として出荷されました。iSeries Access for Webはブラウザ・ベースのユーザー・インタフェースを採用しているため、プロンプタもHTML形式で提供されています。JavaやXMLといった最新のプログラミング・テクノロジの一部がCLのような古くからあるテクノロジに対するコマンド・プロンプト・サポートの実装に使用されているのは興味深いことですが、これについてはまた別の機会に述べましょう。

3. *DFTの意味を知る - お金では買えないもの

CLコマンド・プロンプタは5250のセッションであれGUIウィンドウやHTMLブラウザであれ、CLコマンド・インタフェースを使いやすくするのに大変役立っています。しかし、直感的なコマンド名やパラメータ・キーワード名、パラメータの特殊値、プロンプト・テキストを選択させようとすればもっと情報が必要になる場合もあります。このようなときはオンラインのコマンド・ヘルプが有効です。

OS/400 R1でのCLプロンプタに対する機能強化の一つとして、オンライン・コマンド・ヘルプのサポートが追加されました。S/36のユーザーの方々に大変好評な「どこでもヘルプ」に相当する機能をAS/400をご利用のお客様にも提供しようという努力の一環です。ヘルプはOS/400およびその他のIBM AS/400ソフトウェア製品が表示するすべてのパネル表示に追加されました。

コマンド・プロンプタには「カーソル・センシティブ」のコマンド・ヘルプの表示のサポートが追加されました。カーソル・センシティブ・ヘルプの考え方は、情報の提示を今までよりはるかにフォーカスした形で行うため、重要な改良と言えます。プロンプタの場合、カーソル位置にあるパラメータのヘルプを表示します。コマンドとそのコマンドの全パラメータに関するヘルプを表示すると、表示されたヘルプ・テキスト中から探したいパラメータに関する情報をユーザーが探し出さなければならないからです。

RCDLEN (Record length) パラメータの入力フィールド上にカーソルを置いた状態でF1(ヘルプ)キーを押した後のCRTPF (Create Physical File)コマンドのプロンプト画面を図1に示します。ポップアップ・コマンド・ヘルプ・ウィンドウにはRCDLENパラメータのパラメータ・ヘルプ・テキストの最初の部分が表示されています。

パラメータ・レベルのヘルプを表示させながらF2 (拡張ヘルプ)キーを押すと、コマンド・レベルのヘルプやコマンドのすべてのパラメータのヘルプを表示させることができます。CRTPFコマンドとそのすべてのパラメータの拡張ヘルプの冒頭部分を図2に示します。コマンド・プロンプト機能によりCLが他のコマンド・シェル以外のクラスに分類されるのであれば、プロンプト表示とオンライン・コマンド・ヘルプを組み合わせるとCLはまったく別のリーグに分類されることになるでしょう。

GUI CLコマンド・プロンプタもオンライン・ヘルプ機能を提供しますが、5250ベースの画面ではなくGUI画面管理ベースであるという意味で多少異なっています。5250のセッションではプロンプト・セッションに戻る際にヘルプ・ウィンドウを閉じなければなりません。ヘルプ・ウィンドウを開いたままコントロールをプロンプト・セッションに戻すことはできません。GUI環境では、アプリケーション・ウィンドウとそれに関連するヘルプ・ウィンドウを両方開いたままにできるということが期待されます。オンライン・ヘルプ・サポートでは、ヘルプの一部だけを取り出し、ユーザーが拡張ヘルプを表示させたときに閉じてしまったりサイズが変わってしまったりするパラメータ・レベルのヘルプ・ウィンドウを表示するのではなく、すべてのコマンド・ヘルプを同時に取り出すことができ、コマンド・ヘルプすべてをヘルプ・ウィンドウ中に表示させることができます。

5250のプロンプタ・セッションのカーソル・センシティブ機能にできるだけ近い機能とするため、GUIのコマンド・ヘルプ・ウィンドウはカーソル位置にあるパラメータのヘルプがヘルプ・ウィンドウの一番上部に表示されるようになっています。IBMはV5R3でGUI CLプロンプタ用のオンライン・ヘルプ・ウィンドウをさらに機能拡張し、iSeries Information Centerに同梱されているのと同じフォーマットのコマンド・ヘルプHTML文書を動的に生成し、生成された文書をヘルプ・ウィンドウ中に表示しながら、もちろんカーソル・センシティブなヘルプを提供しています。

CRTPFコマンドのグラフィックなコマンド・プロンプタ・ウィンドウと、SRCMBRパラメータのパラメータ・レベルのヘルプを別のコマンド・ヘルプ・ウィンドウに表示している様子を図3に示します。

4. コマンドが足りませんか?

i5/OS V5R3には1,500個以上のCLコマンドが入っています。V5R3上で稼動するその他の20あまりのIBMソフトウェア製品にはこの他に約700個のCLコマンドがあります。しかしもっと便利なコマンドが欲しいという要望は常にあります。ユーザーはCLコマンドを使い始めたその日から、自分自身でCLコマンドを定義することができ、それらの自分で定義したCLコマンドは、IBMが提供しているCLコマンドと同じように動作します。一つのCLプロンプタを使用してすべてのコマンド・オブジェクトの入力指示を出すことができますし、コマンドのオンライン・ヘルプがヘルプ・パネル・グループ・オブジェクト中に格納されていれば、そのオンライン・コマンド・ヘルプのサポートもIBMが提供しているものと同様に動作します。全体として、他のオペレーティング・システム・プラットフォームと比べて、お客様およびiSeries製品を取り扱っているビジネス・パートナー様が利用可能なコマンド・セットを、よりシームレスに拡張できるという効果があります。他のプラットフォームでは、オペレーティング・システムに付随しているコマンドは、ユーザーが記述したコマンドでは利用できない機能を使用しています。

しかし、自分でコマンドを作るのは大変では、と心配されるかもしれません。既にお聞きになっているか、あるいはお試しになっているかもしれませんが、オンライン・コマンド・ヘルプを作るのは公園の中を散歩するのと同じというわけにはいきません。「便利な」コマンドやコマンド・セットを設計するのは確かに結構大変ですが、「便利な」呼び出し可能なAPIや「便利な」GUIパネルを設計するのに比べれば、それほど大変ではありません。自分自身で作ったCLコマンドを提供することで、IBMが提供するコマンドと同じ恩恵が得られます。すなわち、入力パラメータの構文の大部分はオペレーティング・システムのCLコマンド・サポートでチェックでき、コマンド情報を入力するためのパネルはコマンド・プロンプタ・サポートで構築でき、コマンドを使用しているユーザーが要求すればカーソル・センシティブのオンライン・コマンド・ヘルプを表示することもできます。

CLプログラム中のすべての文がいずれか一つのCLコマンド(PGM (Program)コマンドから始まり、最後のENDPGM (End Program)コマンドに至るまで)で定義されているという考え方に慣れてしまえば、CLコマンドが特殊な目的のコマンドである文を使用して定義されているということを知っても、さほど驚かないでしょう。したがって、CL言語文に使用するCLコマンドの場合と同様で、コマンド定義文も他のコマンドと同様に入力を促すようにできるのです。

コマンド定義のソースコードは一つのCMD (Command)文で始まり、コマンド処理プログラムに渡される各パラメータに対して一つずつPARM (Parameter)文がその後に続きます。単純なスカラー型パラメータと単純なリスト型パラメータを一つのPARM文中に完全に記述することができる一方、もっと複雑な構造体のようなパラメータではPARMから複数のELEM (Element)文を参照する必要があります。修飾オブジェクト名パラメータやジョブ名パラメータでは二つまたは三つのQUAL (Qualifier)文が必要となります。

DEP (Dependency)文を使用すると複数のパラメータ間の構文チェックを定義することができ、条件プロンプトを使った方がコマンドが使いやすくなるとお考えであればPMTCTL (Prompt Control)文を使うこともできます。DSPOBJL (Display Object List)という名前のコマンドを作成するのに使用できるコマンド定義のソースコードの例を図4に示します。
コマンドとそのコマンドのオンライン・ヘルプの間のリンクはパネル・グループ(*PNLGRP)オブジェクト内に格納されていますが、これを作成するプロセスは二つのステップからなります。まず、そのコマンドにはオンライン・ヘルプがあることが示されていなければなりません。これにはCRTCMDコマンドでHLPID(*CMD)を指定し、そのCLプロンプタがコマンド・ヘルプを探す先となるヘルプ・パネル・グループ(HLPPNLGRPパラメータ)名を指定します。コマンドを作成する際にはそのパネル・グループは存在している必要はありません。HLPPNLGRPパラメータとHLPIDパラメータを表示したCRTCMDコマンド・プロンプト・パネルを図5に示します。

二番目のステップはオンライン・ヘルプの作成ですが、これにはUser Interface Manager (UTM)タグ言語を使用してオンライン・ヘルプのソースコードを記述する必要があります。この作業は今までかなり手間のかかる作業でしたが、V5R3からはコマンド定義(*CMD)オブジェクトに基づいてコマンド・オンライン・ヘルプのアウトラインを含んだUIMコマンド・ソースファイルを生成できる機能をオペレーティング・システムがサポートしたことで大幅に簡素化されました。詳細についてはiSeries Information CenterのV5R3 CL Programmingマニュアル(SC41-5721)の第10章をご覧いただくか、GENCMDDOC (Generate Command Documentation)コマンドのオンライン・ヘルプを参照してください。

5. コマンド、コマンド、コマンド

CMDコマンドやPARMコマンドのような特殊なコマンドを使用して新しいコマンドを作成する方法と、PGM、DCL、IFなどの特殊なコマンドを使用してCLアプリケーション・プログラムを作成する方法について説明しました。ここではこれ以外のすべてのCLコマンドについて述べます。

CLの大きな特徴の一つは、オペレーティング・システム全般と他のプログラム製品との間の統合レベルの高さです。これではなんだか曖昧なマーケティングの誇大宣伝に聞こえてしまいますので具体的な例で説明しましょう。IBMが提供するコマンドの大部分は以下のようなさまざまな環境で実行することができるように作られています。

コマンド・ラインから。オペレーティング・システムの多くのパネルやメニューでは画面の一番下にコマンド・ラインがあるか、または押すとコマンド・ラインが表示されるファンクション・キーが用意されています。ユーザーが記述したパネルやメニューもオペレーティング・システムのサポートを利用してQCMDプログラムまたはIBM提供のQUSCMDLN ((Display Command Line Window) APIを呼び出してコマンド・ラインを提供することができます。

ソースファイル･メンバーに格納されていてSTRDBRDR (Start Database Reader)コマンドまたはSBMDBJOB (Submit Database Job)コマンドを起動することでバッチ･ジョブ中で順番に実行されるコマンドの文字列の一つとして。

コンパイルされたCLプログラムまたはILE CLプロシージャ中で対話型のジョブまたはバッチ･ジョブ中で実行されます。

インタープリタで実行されるREXXプロシージャ中でSTRREXPRC (Start REXX Procedure)コマンドを起動することでバッチ･ジョブまたは対話型のジョブで起動できます。

QCMD EXC (Execute Command)コマンドやQCAPCMD (Process Commands)コマンドなどのオペレーティング･システムのAPIに対してコマンド名や必要となるパラメータ値をすべて指定したCLコマンド文字列を渡すことで。S/38コマンドの構文を修飾名に使用したCLコマンド文字列を実行するためにQCAEXEC APIを利用することもできます。

ここでクールなのは、コマンドがどのように実行されるかに関係なくコマンド文字列のフォーマットが基本的には同じであり、コマンドがどこでどのように起動されても、同じ構文チェック機能が働くということです。
CLコマンドの統合サポートはオペレーティング･システムを超えて拡張されています。すべてのコンパイラは、(QCAPCMDなどの)コマンドAPIの一つをどのように使用するかを文書化するか、または(CやC++中のシステムとして)特別な関数を提供するなどして、CLコマンドを実行する何らかの方法を提供しています。また、iSeries Access製品ファミリに組み込まれたリモート･コマンド･サポートを介してコマンドを実行することもできます。

iSeries TCP/IP FTPクライアント･アプリケーションを実行している場合は、SYSCMDサブコマンドを使うとCLコマンド文字列を実行できるだけではなく、コマンド名の前に疑問符が指定されている場合にはコマンド･プロンプト機能も利用できます。たとえば、syscmd ?crtpfはCRTPFコマンドをプロンプトし、その結果として得られるコマンド文字列を実行します。その他のプラットフォーム上のFTPクライアントTCP/IPアプリケーションはRCMDサブコマンドをサポートしていてCLコマンド文字列を実行することができますが、コマンドに対してプロンプトすることはできません。

6. 変更

「有能な場合と運が良い場合があるが、運が良い方が良い」という言い回しを聞いたことがありますか。CLコマンドを拡張可能なように設計した人はきっとその両方だったのでしょう。コンパイルされたCLプログラム中の既存のCLコマンドを壊すことなくCLコマンドを強化/拡張できたのは驚くべきことです。CL Programmingマニュアルの第9章には既存のCLプログラムやCLプロシージャに影響を与えることなくコマンドの定義を変更するいろいろな方法が一覧になっています。中でも面白いものを以下に挙げます。

・ パラメータをスカラー値からリスト(配列)値に変更します。上位互換を保ったまま、呼び出し可能なAPIに対してこうした変更を行ってみると、「CLのパワー」のありがたさに気づくでしょう。

・ パラメータをスカラー値から要素リスト値に変えたり、n個の要素からn+m個の要素に変えます。

・ コマンド定義中に定義されている位置パラメータ限界の後の任意の場所に、新しいオプションのパラメータを追加します。ここでも、APIにパラメータを追加することとどちらが「容易」であるかを比較してみてください。APIにパラメータを追加する場合、新しいパラメータはオプションのパラメータ・グループとしてパラメータ・リストの一番最後に追加しなければなりません。

CLコマンドを段階的に強化できるという機能は、iSeries、AS/400、S/38を使用しているお客様が享受しているレベルのソフトウェア投資保護を提供するのに重要なものです。自分が雇われた会社の継承物がAS/400やS/38まで遡るというようなプログラマは、ビジネス上重要なアプリケーションの一部がCLプログラムで、それらが最後にコンパイルされたのは5年、10年、20年前だという事実に気づいたとき、大変驚くに違いありません。

CLがこれをどのように実現したかの生々しい技術的詳細については触れませんが、コンパイル時に外部のコマンド定義に照らし合わせて構文をチェックされたコマンド文字列は、CLコマンドが実行されるときにももう一度、CLプログラム中にトークン化された形で格納されているコマンド文字列を使用して、構文がチェックされます。コマンドが実行されるときだけオペレーティング･システムのCommand Analyzerコンポーネントが実際のパラメータ･リストを構築し、コマンド処理プログラムを起動します。コマンド定義はユーザーとコマンド処理プログラムとの間の抽象レイヤーを提供します。CLユーザーはこの単純でエレガントな設計の恩恵を20年以上にわたって受けているのです。

7. 何が起こったのか?!

本当の告白タイムです。私はPCプログラマではありません。学生時代にメインフレーム機用のコードを書き、IBM勤務中はiSeries、AS/400、S/38システムのプログラミング経験があるだけです。それなりにしか動かないか突然動かなくなってしまうように見えるPCアプリケーションに対してなぜ私がこれほど苛立つのかがおわかりいただけるかもしれません。「青色の死の画面」が思い浮かぶのです。

i5/OSオペレーティング･システムとOS/400およびCPFの祖先には、広く普及していた強力なメッセージ処理機能があり、CLはそのメッセージ処理・サポートと緊密に連携しています。たとえば、CLプログラムがCLコマンドを実行する場合、エラー・メッセージがもしあれば、どのエラー・メッセージをMONMSG (Monitor Message)コマンドを使って「処理」させたいのかを指定することができます。エラー処理をするということは、エラーを無視してプログラムの実行を続けること、回復のアクションを実行して続行すること、あるいはRCVMSG (Receive Message)コマンドを使ってエラー・メッセージを問い合わせ、SNDPGMMSG (Send Program Message)コマンドを使ってもっと意味のあるエラー・メッセージをCLプログラムの呼び出し側に返すことかもしれません。

このようにエラー・メッセージを処理することで、CLプログラムは、ロールバック、保留していた変更のコミット、オープン中のファイルのクローズ処理、作業スペースや作業ファイルの削除などといった後始末の処理をエレガントに行うことができます。

8. すべてをRPGにコードすることはできない

あらゆるタイプのアプリケーション・プログラムにとって最良のプログラミング言語であるようなハイレベル言語(HLL)を、まだ私は見つけていません。たとえそのような言語が考案されたとしても、既存のアプリケーションに対して既に莫大なお金を投資してしまっている会社は惰性で動くため、プログラマは古いHLLを使いつづけようとするでしょう。

iSeries用のアプリケーションの開発がいくらかユニークあるいはクールとさえいえるのは、アプリケーションの設計者がアプリケーション全体に対して一つのHLLを選択する必要がない点です。その代わりに、アプリケーションの設計者は複数のプログラミング言語を選択でき、アプリケーション全体のうちの特定の部分だけにHLLのパワーを活用できるのです。CL、RPG、Cobol、C、C++間のプログラム同士、ILEアプリケーションの場合プロシージャ同士、プロシージャとプログラムの相互運用性は大変めざましいものがあります。

IBMはV5R3でCLに対していくつかの機能強化を施し、他のHLLで記述されたプログラムやプロシージャを呼び出したり、他のHLLで記述されたプログラムやプロシージャから呼び出されるCLの機能を改良しました。以下はその一部です。

・ 2バイトおよび4バイトの符号付きおよび符号なしバイナリ整数変数のサポート
・ 文字変数の最大長を9,999バイトから32,767バイトに拡張
・ PGMコマンド、CALLコマンド、TFRCTLコマンドの最大パラメータ数を255個に拡張
・ CALLPRC（Call Procedure)コマンドのパラメータに値渡しの機能を追加

9. 皆にセキュリティ?

CLのソース・プログラムの特徴の多くは、qshはKornなどといったコマンド・シェル用に記述されたシェル・スクリプトの特徴と似ています。いずれのシェルも何らかの制御フロー機能、文字列操作関数、文字列との変換、ローカル変数割り当てなどの機能を備えています。CLのクールな機能の一つに、CLのソース・プログラムをコンパイルして*PGMタイプのオブジェクトを生成したり、ILE CLの場合、*MODULEタイプのオブジェクトを生成したりすることができることが挙げられます。この機能には、通常のインタープリタ型コマンド・スクリプトに比べて、以下のような利点があります。

不変である。つまり、オブジェクトが一度生成されるとそれを変更することはできないということです。オペレーティング・システム中のコードとライセンスされた内部コード(LIC: Licensed Internal Code)のおかげで*PGMオブジェクトや*MODULEオブジェクトの実行可能部分に無闇に手を入れることができなくなっています。もちろん、だからといってハッカーがあきらめるというわけではありませんが、オブジェクトの実行可能部分が変更されたということをLICが検知すると、そのオブジェクトには印が付けられます。CHKOBJITG (Check Object Integrity)コマンドを実行して、改竄されたと印のついているプログラム・オブジェクトやモジュール・オブジェクトのリストを作成することができます。

カプセル化が可能。つまり、*PGMや*MODULEを作成するのに使用したCLコマンドのソースは、そのオブジェクトを表示したりダンプしたりしても見ることができないということです。CRT CLPGM (Create CL Program)コマンドを使用して作成されたCLプログラムに対しては、*PGMオブジェクトをダンプしたときにCLのソースが取り出されたり表示されたりしないようにRTVCLSRC(*NO)を指定しておかなければなりません。

安全性を確保できる。つまり、*PGMオブジェクトや*MODULEオブジェクトはオペレーティング･システムが提供するすべての強力なセキュリティ機能や認証機能の恩恵にあずかっているということです。たとえば、CL *PGMのデフォルトの権限は一人以上のユーザーに許可された*USEプライベート権限つきの*EXCLUDEとすることができます。CLプログラムもプログラムの実行中に権限を取り入れるという強力な機能を共有しています。これは他のすべてのiSeriesコンパイラにも共通して広く用いられているプログラム機能です。

10. 正しいコマンド名を推測するのはESPの証?

CLのもっともクールな特徴の一つで、しかもおそらく「すっきりとした小型のゴムの足」タイプにもっとも近い特徴とは、もっとも技術とは関係がないものでもあります。すなわち、コマンド、パラメータ・キーワード、パラメータ値の名前の付け方に一貫性があるためユーザーはCLを「話す」ことができる、という特徴です。

確かに、iSeriesの初心者はコマンドの数が多いというだけで圧倒され、コマンド名は寄せ集めの長い文字列に見えるかもしれません。しかし、iSeriesのユーザーがそれを「理解する」ようになるのに、そんなに時間はかかりません。オブジェクトを作成するコマンドはすべてCRTで始まるとか、オブジェクトを削除するコマンドはオブジェクトのタイプの前にDLTをつけるといったようなパターンに、すぐに気づくでしょう。たとえば、CRTCMDは*CMDオブジェクトを作成し、DLTCMDは*CMDオブジェクトを削除します。

この一貫性は偶然の一致でも幸運な一致でもありません。そうなるように意図されたものです。ハワード・ボターリル氏やウェイン・エヴァンス氏などのCL言語の初期の設計者は、動詞(動作)のあとに名詞句(その動作の受け手)を続けるというコマンド名の形状を選択しました。この単純でしかも強力な名前の付け方により、CLコマンドのユーザーは、よく知っているCLコマンドも新しいCLコマンドも視覚的に認識でき、頭の中で組織化できるのです。

たとえばADDMSGD (Add Message Description)コマンドを使用してメッセージ・ファイルにメッセージの記述を追加したら、メッセージの記述を削除するコマンドはRemove + MSGDといった形かな、と推測できるかもしれませんし、RMVという文字で始まるほかの削除アクションのコマンドを見たことがあれば、このコマンドはRMVMSGD だろうとうまく推測できるかもしれません。

汎用的なコマンド・プロンプト機能とIBMが提供しているコマンド・メニューにより、ユーザーはコマンドをさらにすばやく容易に探し出すことができます。汎用的なコマンド・プロンプト機能の例として、Rという文字の後にアスタリスクをタイプしてEnterキーを押してみてください。Rという文字で始まるコマンドの一覧が表示されます。たとえば使いたいコマンドがメッセージの記述の削除であるのに、削除の略がRMVだったかREMだったか忘れた場合には、この機能を使えばよいでしょう。

コマンド・グループ化メニューは、IBMが提供するコマンドを探すもう一つの手段で、オペレーティング・システムが提供しています。このメニュー・オブジェクトの名前はCMDという接頭辞で始まり、CMDの後ろにコマンド・グループを識別する文字列が続きます。たとえばCMDMSGD (Message Description Commands)には、ADDMSGD (Add Message Description)、CHG MSGD (Change Message Description)、DSPMSGD (Display Message Description)、RMVMSGD (Remove Message Description)などといったメッセージ記述を扱うためのIBM提供のコマンド用のメニュー・オプションが含まれます。

またこのメニューには、関連するコマンド・グループ化メニューへのリンクも含まれています。たとえば、メッセージの記述はメッセージ・ファイル(*MSGF)オブジェクト中に格納されているため、CMDMSGDメニューにはCMDMSGF (Message File Commands)メニューへのリンクがあります。図6にCMDMSGDメニューを示します。

さてCLコマンドの名前を、たとえそれを今まで一度も使ったことがなくても「推測する」ことができたら、それはあなたの頭がCLの名前構文を理解した証拠であり、あなたが「特殊な能力」を備えていることの証拠ではありません。

クールでしたか?

さてアル・バルサ氏の言ったことは正しかったでしょうか。ここで説明したCLの「クールな」点は、退屈でしたか？CLにはユニークで強力な機能がたくさんありますので、私のお気に入りの機能のいくつかについて、読者がそれらを「クール」とは思わないまでも、それらについての有用で啓発的で、ひょっとしたら楽しい情報を、本記事から読み取っていただければと思います。

ガイ・ヴィグ氏は、IBMシステム・グループのシニア・ソフトウェア・エンジニアで、1978年にIBMに入社以来、ミネソタ州ロチェスター市、オンタリオ州トロント市のIBMの事業所に勤務し、S/38、AS/400、iSeries用のオペレーティング・システムやコンパイラのさまざまな部分を開発してきました。1992年以降はAS/400およびiSeriesのソフトウェア設計コントロール・グループ（DCG）のメンバーとなっています。DCGのメンバー、そして後にリーダーとして、同氏は新しいCLコマンドやソフトウェア、変更になったCLコマンドやソフトウェアのリリース間の互換性維持を任務としています。V5R1ではiSeries NavigatorとiSeries Access for Webの2つのGUIのCLコマンド・プロンプタ機能の追加を取り仕切りました。同氏は「CLアーキテクト」としてiSeries上でのCL言語の活性化に取り組んでいます。