RPG IV にはデータ構造に対するさまざまな機能拡張が施されており、コンパイラーによる自動処理を利用して、時間と労力を節約できます。ここでは、既に多くの方々がご存じの機能拡張を 1 つご紹介しましょう。データ構造の開始 位置と終了 位置を定義する必要がなくなり、コンパイラーが自動的に定義するようになりました。

従来は、次のようにする必要がありました。

D oldWay　　　 ds
D Name　　　　　　　　　　　 1 　　　30A
D Street　　　　　　　　 31　　　 60A
D City　　　　　　　　　　61 　　　75A
D State 　　　　　　　　 76 　　　77A
D Zip　　　　　　　　　　 78　　　 87A

各フィールドのフィールド・サイズを数え、開始位置と終了位置をリストする作業は時間がかかり、面倒でした。また、特に大きなデータ構造では、誤りが起こりやすい作業です。構造の中にフィールドを追加したり、フィールドを長くしたりする必要があるときは最悪です。このときには、変更を行った場所から後の開始位置と終了位置をすべて計算し直さなければなりません。前の例のような単純なケースでも、Street フィールドを 5 文字分長くしたい場合、City、State、および Zip の各フィールドの開始位置と終了位置を指定し直さなければならず、フラストレーションが溜まります。

RPG IV では、データ構造を次のように定義でき、コンパイラーが開始位置と終了位置を自動的に計算します。

D newWay 　　 ds
D Name　　　　　　　　　 　30A
D Street　　　　　　　　 30A
D City 　　　　　　　　　 15A
D State 　　　　　　　　　 2A
D Zip 　　　　　　　　　　10A

Street フィールドのサイズを変更するには、長さを 30 から 35 に変更するだけです。

D newWay　　　 ds
D Name　　　　　　　　　　　　 30A
D Street 　　　　　　　　　　35A
D City 　　　　　　　　　　　 15A
D State　　　　　　　　　　　　2A
D Zip 　　　　　　　　　　　　10A

もちろん、開始位置と終了位置は存在するのですが、ユーザー自身で計算しなくても、コンパイラーがユーザーに代わってこれらを計算します。コンパイラーに作業を任せることで、時間の節約になります。

データ構造の便利な機能の 1 つは、フィールドのオーバーラップが可能であることです。例えば、従来は、郵便番号を 5 桁と 4 桁の部分に分割したい場合に、次のようにコーディングする必要がありました。

D oldWay 　　　 　ds
D 　　Name　　　　　　　　　 　　1 　　　　30A
D 　　Street　　　　　　　　　31 　 　　60A
D 　　City 　　　　　　　　 　 61 　　　75A
D 　　State 　　　　　　　 　 76 　 　 77A
D 　　Zip 　　　　　　　　 　　78 　　　87A
D 　　 Zip5 　　　　　　　　　78 　　　82A
D 　　 Dash 　　　　　　　　　83 　　　83A
D 　　 Zip4 　　　　　　　　　84 　　 87A

Zip5 フィールドの位置が Zip フィールドの位置とオーバーラップするので、これらのフィールドは同じデータを共有します。一方のフィールドへの変更が、他方にも反映されます。

この機能を利用しながら、新しい構文の利点を生かすには、図 1 に示すような OVERLAY キーワードを使用できます。この方式では、新しい構文を最大限に活用できます。前述のとおり、Street フィールドのサイズを変更したい場合は簡単にできます。重ね合わさったフィールドはすべて Zip フィールドの位置に基づいているので、これらのフィールドを変更する必要はありません。

ただし、Zip フィールド内の開始位置は従来どおりハードコーディングされており、手動で計算する必要があります。これらの位置も、コンパイラーが自動的に計算できます。これを指示するには、開始位置に *NEXT 特殊値を使用します (図 2)。

コンパイラーは、重ね合わさったフィールドの長さを計算することもできます。図 2 では、Zip フィールドの長さは 10 バイトにハードコーディングされています。10A を省略すれば、重ね合わさったフィールドに基づいて、コンパイラーが長さを自動的に計算します (図 3)。この例では、コンパイラーは Zip5、Dash、および Zip4 の各フィールドのサイズを加算して、合計 10 バイトと判定します。重ね合わさったフィールドが 10 バイトの長さなので、Zip は 10A フィールドになります。

ここでも、コンパイラーが作業を行うので、重ね合わさったフィールドの大きさをユーザーが計算する必要はありません。確かに、郵便番号の場合は大した時間の節約にはなりませんが、図 4 の例を考えてみましょう。

この場合は、Address という名前のフィールドに、住所のフィールドすべてが重ね合わさっています。このため、住所全体を別のデータ構造に移動したければ、Address フィールドを移動するだけで済みます。コンパイラーがこの Address フィールドのサイズを計算します。長さは 57 バイトですが、この長さを計算したり、プログラムにコーディングしたりする必要はありません。ここでも、コンパイラーが作業を自動的に行います。 住所に別のフィールドを追加したければ (例えば、部屋番号)、図 5 に示すように、データ構造にそのフィールドを追加するだけです。コンパイラーが開始位置と終了位置を計算し、Address フィールドの長さも自動的に計算するので、データ構造内で他のフィールドを再計算したり、Address フィールドの長さを再計算したりしなくて済みます。

この手法では、スペーシングが正しく行われるように、フィラー・フィールドが必要になることがあります。次のような従来形式のコードを考えてみましょう。

D oldWay 　　ds
D field1 　　　　　　1 　　　10A
D field2 　　　　　　20 　　 25A
D field3 　　　　　　27 　　 39A

データ構造の位置 11 から 19、または位置 26 にサブフィールドが定義されていないことに注意してください。そのスペースは、将来の拡張に備えたものかもしれません。あるいは、かつて存在していたフィールドで、現在では使用されていないことも考えられます。

開始位置と終了位置をハードコーディングせずに同じ内容をコーディングするには、フィラー・フィールドが必要です。例を次に示します。

D newWay 　　　ds
D field1 　　　　　　　　　　10A
D filler　　　　　　　　　 　　9A
D field2　　　　　　　　　　　6A
D filler2 　　　　　　　　　　1A
D field3 　　　　　　　　　　13A

これらのフィラー・フィールドにより、他のフィールドが従来形式のデータ構造と一致するようになります。また、フィラー・フィールドに名前を付ける必要はありません。例えば、次のコードもまったく同様に機能します。

D newWay　　　 ds
D field1 　　　　　　　　　10A
D 　　　　　　　　　　　　　 9A
D field2 　　　　　　　 　 6A
D 　　　　　　　　　 　　 　 1A
D field3 　　　　　 　　　13A

この構文を使用すれば、フィラー・フィールドに固有の名前を考えたり、これらのフィールドには何か用途があるのではないかと気にしたりする必要がなくなります。

必要に応じて、これらのフィラー・フィールドに値を指定することもできます。例えば、「予約済み」フィールドをブランクや 16 進ゼロ (フィールドによって異なる) で充てんすることを要求する API がよくあります。図 6 のコードは、名前のないフィラー・フィールドを使用してこれを実現する方法を示しています。

コンパイラーに作業を任せることで、保守が容易になります。また、開始位置、終了位置、フィールド長の計算を省くことができ、「フィラー」フィールド名を考える必要がないので、プログラムを変更する必要があるときに時間を節約できます。

「シングル・サインオンを 1 日で」インプリメントした、という話をお聞きになったことがあるでしょう。いえ、これはまやかしではありません。ここ数カ月にわたってシングル・サインオンをセットアップしてきましたが、これは本当に素晴らしい機能です。システム管理者も得をし、エンド・ユーザーも得をし、企業全体としても得をします。そして、1 日よりはるかに短い時間でインプリメントできます。最近の経験では、始めから終わりまで 2 時間で、100 人以上のユーザーを対象とする SSO を立ち上げることができました。

さて、シングル・サインオンとは一体何でしょうか。朝のコーヒーを飲みながらボイス・メールをチェックした後、会社の MS Windows ドメインに自分の Windows ユーザー ID とパスワードでサインオンする。これが、シングル・サインオンの本質です。その日はそれ以降、再びサインオンする必要はありません。デスクトップ・アイコンをクリックして 4 つの別々の System i にアクセスできますが、ユーザー ID とパスワードを求められることは二度とありません。iSeries NetServer を使用してネットワーク・ドライブをマップしても、ユーザー ID とパスワードを求められることはありません。これはとても便利です。

System i アイコンをクリックしてサインオン・サーバーのボックスにサインオンし、それからまたそれぞれの Telnet グリーン・スクリーン・セッションにサインオンするのは、実にイライラするものです。こんな作業、管理者は愚かなことだと思い、エンド・ユーザーもばかげたことだと思っています。皆の感想はもっともで、こんなことは愚かでばかげています。

ユーザー ID とパスワードはいくつお持ちですか?数えるのはやめましょう。その数はあまりにも多すぎます。このように多数のパスワードがあると、私たちは最も楽な道に逃げて、すべてのパスワードを同じにしてしまいます。あるいは、それと大して変わりませんが、すべてのシステムで同じパスワードを使用し、使用しているシステムを示す文字を末尾に付け足します。この方式では、BIGBOY1A、BIGBOY1S、BIGBOY1P などのパスワードを使用します。

パスワードの数が多くなるほど、パスワードは推測しやすくなりがちです。人は、自分のイニシャル、子供、ペット、配偶者、ひいきのスポーツ・チームの名前、誕生日といった、覚えやすい言葉を使う傾向にあります。しかし、パスワードが覚えやすいということは、推測しやすいということでもあります。

シングル・サインオンの主な目標と効用の 1 つは、パスワードの削減です。覚えておくべきパスワードがたった 1 つならば、そのパスワードを強力にして、定期的な間隔で期限切れにすることができ、パスワードの再設定に関する問い合わせの電話がヘルプ・デスクに殺到することもなくなります。

Gartner Group の 2005 年の調査では、ヘルプ・デスクへの問い合わせ件数全体の 15 から 35 パーセントがパスワード再設定の件で、問い合わせ 1 回当たり最大 31 ドルのコストがかかっています。ユーザー数 300 人の場合、パスワード再設定についての問い合わせを各ユーザーが年に 2 回行っただけでも、約 19,000 ドルの出費に相当します。1 週間で同じ回数の問い合わせをするユーザーも、会社には必ずいるものです。

System i と Windows のシングル・サインオンは、認証には Kerberos、許可には IBM の EIM (エンタープライズ識別マッピング) という業界標準を使用します。現在 Windows Server 2000/2003 を Active Directory とともにお使いならば、ほぼ確実に Kerberos を既に使用しているはずです。これは、Active Directory を実行する場合に Microsoft が使用するデフォルトの認証メカニズムです。Kerberos は MIT で開発され、MIT はこの名前の使用を厳密に管理しています。このため、IBM は Kerberos のことをネットワーク認証サービス (NAS) と呼んでいます。

iSeries Access V5R2 と V5R3 には、NAS と EIM を構成するためのウィザードが備わっています。これらのウィザードを正常に実行し、ほかにいくつかの簡単なステップを行えば、シングル・サインオンが稼働するようになります。組織へのシングル・サインオンのロールアウトは、1 ユーザーずつ、1 部門ずつ、あるいは一度に全員に対して行うことができます。都合に応じて決めてください。

ある会社のために初めて実施したシングル・サインオンのインプリメンテーションには、ほぼ 2 日かかりました。たくさんの資料を読んで、Pat Botz のシングル・サインオン・セッションと、COMMON のラボに数回出席した後でもこうでした。それでも、SSO のセットアップを数回こなした後、ユーザーのシングル・サインオンを可能にするためにかかる時間はたいてい半日だと分かりました。3、4 台の System i が関係する場合は、およそ 1 日、場合によっては 1 日半かかります。

法令順守については、覚えておくべきパスワード数が減り、Windows ドメインで実施できるパスワード・ポリシーがより堅固になる、というシングル・サインオンの利点を監査員が納得した後で、シングル・サインオンが問題視されたことはまだありません。現在では、Windows AD でユーザーを無効にして、System i へのアクセスを実質的にすべて遮断できます。