RPG プログラム全体をフリー・フォームで作成する！
RPG の新しいフリー・フォーム構文でプログラムのコーディングがはるかに簡単になる
そうです、正しく読めたでしょうか。IBM i バージョン 7.1 の Technology Refresh 7 (TR7) の一部として入手できる ILE RPG コンパイラーの機能拡張によって、RPG プログラム全体をフリー・フォームで作成できます！
新しいフリー・フォーム構文を定義する際に、私を含め、私のチームは既存の RPG プログラマーと RPG 以外のプログラマーの両方が新しいフリー・フォーム構文を簡単に学ぶという、 2 つの目標を掲げました。この記事では、H、F、D および P 仕様に関する新しいフリー・フォーム構文と、RPG プログラムをより簡単にコーディングできるようにする既存のキーワードのいくつかの変更についてお話しします。
学習曲線を簡単にする
図 1 はフリー・フォーム RPG プログラムの例を示しています。このコードをソース・ファイルにコピー・アンド・ペーストすれば、列 8 以降からコードは起動します。RPG プログラマーとして経験豊富なあなたなら、そのプログラムのすべてのステートメントとキーワードを理解できると思います。この記事の後半で、ちょっとやっかいと思われる新しい構文の側面をいくつか指摘しますが、この新しい構文を簡単に採用できることがわかるでしょう。しかし、ここは一歩下がって、RPG に慣れていないプログラマーのふりをしましょう。ご想像のように、DFTACTGRP、DCL-F、CHAIN、EXFMT など図 1 の項目のいくつかは意味を成しません。
では、その同じプログラマーが図 2 にあるコードに直面した場面を想像してみてください。このコードは、図 1 のフリー・フォーム・プログラムのスニペットの固定フォーム版です。図 2 の customers ファイルと dspMsg ファイルの定義は、 fcustomers と fdspMsg と表示されています。さらに、e、pi、D、cf、id、10a などの値は、 RPG 以外のプログラマーにはランダムに見えるかもしれません。さらに悪いことに、customers ファイルの if のせいで、まるでそのステートメントが条件付きのように見えています。
RPG 以外のプログラマーに RPG のコーディング方法を教えたことがありますか？彼らがこのコードを扱って、従業員全員に支払う総賃金を保持する変数を定義したい、と考えてみてください。
次のように totalWages 変数を追加することで、RPG 以外のプログラマーには、コードの新しい行について 3 つのエラー・メッセージが表示されます。
エディターまたはコンパイラーで表示されるエラー・メッセージ「entry not valid for a field (エントリーがフィールドに有効でない)」、「data type not valid (データ型が有効でない)」、「decimal positions not valid (小数点以下の桁が有効でない)」は、RPG 以外のプログラマーには非常にわかりにくいかもしれません。プログラマーに、長さではなくデータ型のラインナップ方法を教えれば、エラー・メッセージは消えてなくなります。ただし、プログラマーの不平不満の声は簡単にはなくならないでしょう。
新しいフリー・フォーム構文を使用すれば、初心者 RPG プログラマーは、最初に列指向言語の扱い方を学習するより、RPG の使用方法を学習することにすぐに集中することができます。
フリー・フォーム H 仕様
Control Option (CTL-OPT) ステートメントは、フリー・フォーム版の制御ステートメントです。各 CTL-OPT ステートメントは、ゼロ以上のキーワードに、セミコロンが続いています。
CTL-OPT ステートメントは好きな数だけコーディングできます。このステートメントを固定フォーム制御ステートメントと混合させることもできます (H 仕様)。このアプローチは、ターゲット・リリース・コンパイルにも使用される固定フォーム H 仕様のコピー・ファイルがあるときに便利かもしれません。
制御ステートメントが 1 つ以上ある状況では、あらゆるステートメントに対して、キーワードを繰り返さないというルールが適用されます。したがって、例えば、あるステートメントに OPTION キーワードをコーディングする場合、別のステートメントでは OPTION キーワードはコーディングできません。図 3 に CTL-OPT の例をいくつか示します。
フリー・フォーム F 仕様
DCL-F (Declare File) ステートメントのフォームは以下のとおりです。
新しいキーワードのいくつかは、F 仕様の固定フォーム項目でコーディングする同じ情報を指定します。
装置タイプ・キーワード DISK、PRINTER、SEQ、SPECIAL、WORKSTN です。
フリー・フォーム・ファイル宣言の最初のキーワードは、 LIKEFILE またはいずれかの装置タイプ・キーワードです。装置タイプ・キーワードを 1 つでもコーディングしないと、デフォルトで DISK が指定されます。以下のファイルは外部記述 DISK ファイルです。
装置タイプ・キーワードのパラメーターを、外部記述ファイルの場合は *EXT、プログラム記述ファイルの場合はレコード長として指定できます。*EXT はデフォルト値です。そのため、外部記述ファイルを定義している場合は、パラメーターをコーディングする必要はありません。図 4 に装置タイプ・キーワードの例をいくつか示します。
USAGE キーワード。
USAGE キーワードは、固定フォーム F 仕様の File-Type エントリー (I、U、O、C) および File-Addition エントリーと同じ情報を指定しています。*INPUT、*OUTPUT、*UPDATE、*DELETE のいずれか 1 つのパラメーターを示す必要があります。図 5 の各装置タイプには USAGE キーワードのデフォルト値があるため、必要な場合はこのキーワードは省略できます。
ファイルに意図しているあらゆる使用法を必ずしも指定する必要はありません。使用法の値の中には他の値を意味しているものがあります。*UPDATE は *INPUT、*DELETE は *UPDATE と *INPUT 両方を意味しています。固定フォームでは、更新可能として定義されたファイルは自動的に削除可能になる点に注意してください。フリー・フォームでは、レコードを削除できるようにするには *DELETE を明示的にコーディングする必要があります。
図 6 は DISK ファイルの USAGE キーワードの例を示しています。装置キーワードがないため、DISK キーワードが示されています。
KEYED キーワード。
このキーワードは、ファイルがキー順に開いており、キー順操作が有効であることを示します。外部記述ファイルの場合、パラメーターを指定せずにキーワードをコーディングします。プログラム記述ファイルの場合は、文字キーのみがサポートされているため、2 つのパラメーター *CHAR およびキー長を指定して、キーワードをコーディングします。以下に KEYED キーワードの例を 2 つ示します。
プログラム記述ファイルに他の型のキーを指定するには、ファイルを文字キーで定義し、キー順操作については、必要なキー型を備えたサブフィールドのあるデータ構造を採用します。
フリー・フォーム D 仕様
以下のリストはフリー・フォーム定義の命令コードです。
- DCL-C: 名前の付いた固定情報を定義します
- DCL-S: スタンドアロン・フィールドを定義します
- DCL-DS: データ構造を定義します
- END-DS: データ構造サブフィールドの終わり
- DCL-SUBF: サブフィールドを定義します
- DCL-PR: プロトタイプを定義します
- END-PR: プロトタイプ・パラメーターの終わり
- DCL-PI: プロシージャー・インターフェースを定義します
- END-PI: インターフェース・パラメーターの終わり
- DCL-PARM: パラメーターを定義します
DCL-x 命令コードのフォームはすべて同じです。
END-x 命令コードのフォームもすべて同じです。名前のコーディングは任意ですが、名前を指定する場合、定義中の項目の名前と一致する必要があります。
図 7 のコード・スニペットは DCL-x 命令コードと END-x 命令コードの例をいくつか示しています。
データ型
データ型が必要な定義については、データ型キーワードを最初に指定する必要があります。固定フォームでコーディングする場合、一部のデータ型はデータ型エントリーとキーワードで示します。DATFMT、TIMFMT、CLASS、PROCPTR、VARYING の各キーワードはフリー・フォームでは使用されていません。これらのキーワードが指定する情報はデータ型キーワードの一部です。例えば、可変文字フィールドをコーディングするには、固定フォームで VARYING キーワードで 10A をコーディングしますが、フリー・フォームでは VARCHAR データ型キーワードを使用します。
文字列データ型は、英数字、グラフィック、UCS-2 の 3 種類しかありませんが、文字列データ型キーワードは 6 種類あります。図 8 の図にこれらのキーワードを一覧しています。
しかし 図 9 では数値データ型キーワードが見られます。BINARY キーワードがリストの「B」データ型と一致すると思うでしょう。しかし、RPG で「バイナリー」と呼ばれるこのデータ型は実際は、バイナリー・フォームで保存されている 10 進データ型です。別の言語では、「バイナリー」という言葉は、 RPG 用語で言う「整数」と同じ意味です。これによりしばしば 2 つの問題が発生します。API 資料を読むときに RPG プログラマーが混乱し、その他の言語に慣れたプログラマーに誤解を与えます。整数型を適用しなければならない場合に RPG バイナリー形式の使用を制限するため、このデータ型のフリー・フォーム・キーワード BINDEC (「2 進 10 進」の短縮形) に名前を付けることにしました。
図 9 を注意して見てほしいのですが、小数点以下の桁数をゼロにする場合は小数点位パラメーターを省略でき、整数データ型と符号なしデータ型のキーワードでは小数点以下の桁数を指定できません。また、固定フォームの場合と同様、整数データ型と符号なしデータ型の長さはバイトではなく桁数で測られている点に注目してください。
図 10 の図は、DATE、TIME、TIMESTAMP など残りのデータ型のフリー・フォーム・キーワードを示しています。
定義の特殊ルール
プロシージャーの外部名が、RPG 名を宣言したときに使用した大文字または小文字を使用した RPG 名と同じであることを示すには、EXTPROC キーワードに *DCLCASE を指定することができます。プロトタイプ用に RPG 名を変更したものの EXTPROC 名を変更できなかった場合は、この機能が役立つでしょう。図 11 の例では、外部プロシージャーまたはメソッドの名前は、open、close、Qp0zGetEnvCCSID、getBytes です。
EXPORT または IMPORT キーワードの外部名として *DCLCASE を指定することもできます。以下の変数の外部名は G_DefaultCity です。
サブフィールド、プロトタイプ化・パラメーター、プロシージャー・インターフェース、またはデータ構造については、プレースホルダーに *N を使用することで、名前を指定しているのではないことを示すことができます。
フリー・フォーム命令コード EVAL や CALLP のように、DCL-SUBF と DCL-PARM は名前が READ や SELECT のようなフリー・フォーム計算命令コードと同じでない場合は任意です。以下に、パラメーター名が SELECT であるために、パラメーターの 1 つに DCL-PARM が必要なプロトタイプの例を示します。
データ構造にサブフィールドがない場合、END-DS を別のステートメントとしてコーディングするのではなく、DCL-DS の最終キーワードとしてコーディングできます。
同様に、プロトタイプにパラメーターがない場合、END-PR を DCL-PR の最終キーワードとしてコーディングできます。同様のことがプロシージャー・インターフェースに当てはまります。
フリー・フォーム P 仕様
プロシージャーは DCL-PROC ステートメントで始まり、END-PROC ステートメントで終わります。
END-PROC ステートメントのプロシージャーの名前は任意です。ただし、名前を指定する場合、定義されているプロシージャーと同じ名前でなければなりません。以下にプロシージャーの例を示します。
このプロシージャー例について、以下の 2 つのポイントに注意してください。
- プロシージャー・インターフェースが名前にプレースホルダー *N を使用している。
- プロシージャーにはパラメーターがないため、END-PI が別のステートメントではなく、DCL-PI ステートメントの終わりにキーワードとして指定されている。
フリー・フォーム構文の油断ならない面
ファイルを更新可能に定義しても、固定フォームの場合のように、フリー・フォームでは自動的に削除可能にはなりません。レコードを削除できるようにするためには、USAGE キーワードに *DELETE を明示的にコーディングする必要があります。LIKEREC または LIKEDS キーワードで定義されていない限り、END-DS をデータ構造の終わりにコーディングすることを忘れないでください。さらに、必ずすべてのプロトタイプに END-PR、すべてのプロシージャー・インターフェースに END-PI をコーディングしてください。
固定フォームを使用すると、一部のキーワード (DTAARA、EXTNAME、EXTFLD など) について引用符なしで外部名をコーディングすることができます。しかし、フリー・フォームではこれはできません。引用符なしで名前をコーディングすると、コンパイラーはそれを名前の付いた固定情報と見なします。図 12 では、固定フォームでキーワード EXTNAME(CUSTMAST) を使用していた場合、コンパイラーは、ファイル DEVLIB/Z4CSTMSTR ではなく、ファイル *LIBL/CUSTMAST から外部サブフィールドを取得しようとしていたでしょう。
すべての D および P 定義について名前の終わりに省略符号をコーディングすることに慣れているユーザーにとっては、それがフリー・フォーム宣言では不可能であることがすぐにわかるでしょう。例えば図 13 のステートメントをコーディングする場合、コンパイラーは名前を ACTUAL_FILE_NAMECHAR と見なし、「(10)」を検出するキーワードを探そうとします。
ボーナス機能
フリー・フォーム RPG が提供するボーナス機能をいくつか見てみましょう。
F 仕様と D 仕様の混合。
図 1 で気付いたかもしれませんが、私はファイル宣言の前にプロシージャー・インターフェースをコーディングしました。これは誤りではありません。固定フォームでコーディングしていても、ファイル宣言を他の宣言と混ぜることができるようになりました。つまり、フリー・フォームで一部のファイル定義キーワードについて名前の付いた固定情報を使用できるということです。図 12 の例をご覧ください。ここでは、ファイル宣言の EXTDESC キーワードとデータ構造宣言の EXTNAME キーワードに同じ名前の付いた固定情報を使用しています。
/FREE または /END-FREE がない。
フリー・フォーム ・コードの始めに /FREE ディレクティブをコーディングする必要はありません。列 6 と 7 が空白で、列 8 から 80 が空白でない場合、フリー・フォーム・ステートメントと見なされます。固定フォーム・ステートメントをいくつかコーディングする必要がある場合、見苦しい /FREE や /END-FREE をコーディングせずに済むようになりました。
/FREE ステートメントや /END-FREE ステートメントを引き続きコーディングできますが、コンパイラーはそれらを無視します。
データ構造内にフィールドを位置付ける方が簡単である。
データ構造の特定の位置にフリー・フォーム・サブフィールドを定義している場合、OVERLAY (ds-name) ではなく POS キーワードを使用できるようになりました。実際、フリー・フォーム・サブフィールド定義をコーディングする場合、データ構造名をパラメーターにして OVERLAY キーワードをコーディングすることはできません。
内部ファイル名は 10 文字を超えることができる。
フリー・フォームでは、EXTFILE キーワードを使用してファイルの外部名を指定している限り、ファイルの内部名は任意の文字長を使用できます。外部記述ファイルには EXTDESC キーワードも使用する必要があります。
パラメーターのない EXTPGM キーワード。
固定フォームでも、パラメーターを指定せずに EXTPGM をコーディングできるようになりました。パラメーターをコーディングしない場合、プログラム名は RPG プロトタイプ名を大文字にした形式になります。以下のプロトタイプをコールで使用すると、QCMDEXC プログラムが呼び出されます。
SQL プリコンパイラ―・サポート。
SQL プリコンパイラ―も TR7 でフリー・フォーム RPG をサポートしているため、RPGLE と SQLRPGLE ソース両方で新しいフリー・フォーム構文を使用することができます。
フリー・フォーム RPG の制限
フリー・フォーム RPG は、まだ完全にはフリー (自由) ではありません。最新の状態でのフリー・フォーム RPG の制限を以下に示します。
- フリー・フォーム・ステートメントは、まだ列 8 から 80 に制限されている。
- I 仕様と O 仕様は、まだ固定フォームでコーディングしなければならない。
- 新しいフリー・フォーム・サポートは、 TGTRLS(*CURRENT) のみに使用できる。
フリー・フォーマットの自由度を楽しむ
RPG プログラムをコーディングする際に、フリー・フォーマットによりアップされた自由度を楽しんでいただきたいと思います。継続文字を使用しなくてもよいように、私は、固定フォームの D 仕様と P 仕様で、どのくらいの頻度で短い名前を使用するようにしたか認識していませんでした。現在は、名前を記述する余裕がたっぷりあるので、固定フォーム・コードを作成する場合に、以前よりわずかに長めの名前を使用している自分に気付くことが多いです。
また、フリー・フォームを使用すると、他のプログラマーに RPG の使用方法をより簡単に教えることができるようになる点もわかるでしょう。そうすれば、RPG のシンプルで強力な入出力モデル、使いやすい 10 進数演算機構、ミステリアスな *INLR など、RPG の機能面にほぼ完全に集中できます。
必要な PTFの詳細 や新しい構文の資料一式を見つけるには、RPG Cafe ウィキをご覧ください。
