IBM i 7.6およびIBM i 7.5 TR6の Db2 for iとIBM iサービス機能強化

2025年5月1日　スコット・フォースティ、チャーリー・グアリーノ

ご存知のように、2025年4月8日にIBM iの最新の機能、リリース 7.6 が発表されました。また、同時にIBM i 7.5の技術刷新、つまりTR6も発表されました。IBM i 7.6自体もさることながら、IBM i 7.5 TR6にも最重要テクノロジー分野に関する数多くの機能強化が含まれており、決して軽視するべきではありません。

今回の発表ではDb2 for i関連、特にIBM iサービスの機能強化が数多く行われています。IBM iサービスの当初の目的は、ユーザー定義の表関数とビューで何ができるかをお客様に示すこと、つまりデータベース・ファイルに存在しない非伝統的なデータに対する、この技術の潜在的な力を示すことでした。時とともに、それが直接お客様に価値を提供していることが分かりました。そして、こうした最新の技術を利用するためのインターフェースがSQLです。IBMは従来のSQLの定義を拡張し、データベースという枠をはるかに超えた進化を遂げました。SQLはIBM iを利用するすべての人にとってのツールであり、これを活用することで生産性が向上します。

今や、従来のデータベース・プログラミングとはまったく関係のないさまざまな作業のために、SQLを使用してIBM i上のデータにアクセスする方法は何百通りもあります。IBM i 7.6は、その点でさらに進化しており、今回の発表には、Db2 for iについて6つの機能拡張が、IBM iサービスについては10の新機能追加と20の機能拡張が含まれています。それぞれの詳細については、こちら（IBM i 7.6、IBM i 7.5 TR6）をご覧ください。では、これらの機能の中から、Db2 for i関連の主要な新規機能追加や機能拡張についてお話ししましょう。

Db2 for iの新機能および機能拡張

データ変更表参照としてUPDATE文とDELETE文をサポート

データ変更表参照の機能を使用することで、SQLのINSERT文、UPDATE文、またはDELETE文をSELECT文のFROM文節やSELECT INTO文などに埋め込めます。IBM i 7.2以降では、データ変更表参照としてINSERT文だけが使用可能でしたが、IBM i 7.6からはINSERT文に加えUPDATE文とDELETE文が使えるようになりました。

データ変更表参照としてUPDATE文またはDELETE文が使えるという事は、直接、更新または削除されたデータを基にした中間結果表をクエリーで取得できるということです。つまり、UPDATE文またはDELETE文で変更された行を中間結果表とし、そこからデータをSELECT文で抽出できるのです。このとき、変更前の行に関する情報を確認したい場合はOLD TABLEを、変更完了後の行に関する情報を確認したい場合はFINAL TABLEを、UPDATE文またはDELETE文の直前に指定します（注）。

直接ジャーナル情報は取得しませんし、この機能を使うためにジャーナリングは必要ではありません。必要な情報はすべて取得できます。たとえば、100列をもつファイルがあり、そのうち10行を更新したとします。では、その100列のうち、どの列に興味深いデータがあるでしょうか？ 更新されたすべての行の一意の識別子を知りたい場合は、主キー列が興味深いかもしれません。では、主キーがない場合はどうすればよいでしょう？ この場合は、相対レコード番号が取得できます。必要であれば、主キーと相対レコード番号の両方を取得することも可能です。変更前と変更後の列のデータ値を取得できます。たとえば、「ある部署で全員が昇給した場合、昇給前後の給与はいくらか？」、「昇給前後の部署全体の給与総額はいくらか？」といったサマリーレポートを送信する場合、これらの情報が役立ちます。これらすべてを、データ変更表参照としてUPDATE文を使うだけで1つのSQL文で取得できます。

SQL Error Logging Facility（SELF）

SELFはSQLの失敗や警告をログする機能で、IBM i 7.4から備わっていますが、デフォルトでは無効になっています。SELFを有効にするには、データベースにアクセスしてスキーマSYSIBMADM内のSELFCODESというグローバル変数の値を、デフォルト値（NULL値または*NONE）から特定のSQLエラーコードや警告コード、あるいはすべてのエラーを意味する*ERROR、すべての警告を意味する*WARN、そしてそれら両者を意味する*ALLなどの一般的な値に変更します。

また、SQLのSET文を使うことで、SYSIBMADM.SELFCODESグローバル変数の内容を、SET文を発行したジョブ固有の設定値に変更できます。ですから、この手法を使えば、このグローバル変数をジョブごとに固有の値に設定したり、少し工夫すれば特定のユーザー用の値に設定したりできます。このログ情報は、QSYS2.SQL_ERRORTという表に蓄積され、その情報抽出用にQSYS2.SQL_ERROR_LOGというビューが用意されています。

SELFを使うことで、失敗しているSQLステートメントがあるかどうか、もしあるならどのジョブのどのプログラムで失敗しているのか、スタック、発生回数、発生理由などについての洞察が得られますし、そのSQL文も取得できます。これにより、対策を講じるための決定が非常に簡単になります。

警告を調べるのをためらわないでください。警告は、SQLステートメントは完了したものの、完全な成功、絶対的な成功ではなかった部分がある場合に表示されます。警告に注意を払うべきであり、エラーや機能上の問題だけに目を向けていると、簡単に解決できる機会を逃してしまいます。たとえば、選択リストとホスト変数のコーディングを間違え、選択リストには3つの列があるのに、ホスト変数は2つしかないような状況を考えてみましょう。これは正しくないので、警告として表示され、単純なプログラミング・ミスをとても容易に発見、修正できます。

IBM iサービスの新機能および機能拡張

統合ファイルシステム（IFS）の権限収集

お客様のアプリケーションにとって、IFSは今や不可欠な要素であり、IFSとの連携やコラボレーションを向上させるために活用できるものは何であれ重要です。IBM i 7.6では、オブジェクトに関する権限情報を提供するAUTHORITY_COLLECTIONビューに、新たにルート（/）、QOpenSys、およびユーザー定義ファイルシステム内のすべてのファイルシステムオブジェクトに関する権限情報を提供するAUTHORITY_COLLECTION_IFSというビューが加えられました。

権限収集ビューは以前から存在していたのに、なぜこのような機能強化が行われたのでしょうか？ 権限収集ビューのアプローチ全体は、返される列の共通性に重点を置いた戦略でした。権限収集ビューの利用者があらゆる種類のデータに使用できるビューを用意しよう、というものでした。それはそれで良いのですが、うまくいかないこともあります。IFSの場合、セキュリティー・モデルもセキュリティー言語もIFS以外のものとは異なるので、共通のアプローチには当てはまらない場合があります。あるカンファレンスで、IBMのセキュリティー・アドバイザーの一人がこの点を明確に示し、「IFSで、ユーザーが使用しているものやセキュリティー・チームが調整する必要があるものに合わせて、権限収集ビューを利用できればすばらしいと思いませんか？」と言いました。ここでの全体的な考え方は、IFSを扱う際にIFSと無関係な列を削除し、IFSのセキュリティー言語で表現するために必要な列を変換することです。つまり、使用と実行または除外ではなく、RWX（読み込み／書き出し／実行）について話しているということです。IFSのセキュリティー保護という非常に困難な任務を担う人々が、直接利用できるようにしようとしています。

このプロジェクトを始めた時、舞台裏でこのプロジェクトを持ち込んでくれた人たちと会話を続け、3人のIBMチャンピオンにこれを試用した感想をもらうことにしました。これが成功への近道でした。IBMチャンピオンからは、いつものようにすばらしいフィードバックが得られました。このように、社外にも論理的にチームを拡張して視野を広げることで、より良い結果が得られ、その協業のお陰で現実世界でのテストも行え、市場投入も早まりました。

権限収集という概念は、企業にとって非常に重要なテーマでした。適切な量の権限を付与し、過剰にならないようにするにはどうすれば良いのでしょうか。また、システムを損なわずに過剰な権限を削減するにはどうすれば良いのでしょうか。どちらの方向に進むにしても、このすばらしいツールが常に役立つはずです。

古いジャーナルレシーバーの削除

何年も前に、必要に迫られてSYSTOOLSの古いスプールファイルを削除するサービスを作成したことがあります。その後、実際にそれをリリースしてみて、お客様が便利だと感じるか試してみようと考えました。その結果、多くの人からスプールファイルの保存期間に関するルールを設定すれば、管理が自動化できるという肯定的なフィードバックを得ました。

今回追加されたSYSTOOLS.DELETE_OLD_JOURNAL_RECEIVERS()プロシージャ―は、スプールファイルと同じ概念ですが、いままで実現しなかったのは、必要なデータが削除されてしまうのではないかと常に懸念していたからです。データジャーナルには、表の行イメージが含まれています。これはデータであり、削除する準備が整ったと確信できるまで削除するべきではありません。プロジェクトの検討段階で、サンプルデータで作業していてデータは重要ではない場合、SQLスキーマを作成してジャーナルとジャーナルレシーバーを無料で入手し、不要なジャーナルレシーバーでマシンをいっぱいにしてしまうことがあります。これはこのプロシージャ―の完璧な応用例です。テストQA開発環境にアクセスして、「これでもうストレージが不足することはありません」と言えるでしょう。いくつかのルールを設定し、ジョブをスケジュールすれば、これらの汎用レシーバーが検索され、特定の日付より古い場合は削除されます。

もう１つの活用方法は、その汎用レシーバーが保存されているかどうかを具体的に確認することです。つまり、保存されていても一定の日数以上経過している場合は削除対象となり、ストレージの問題を回避できるということです。

いまは、ジャーナルレシーバーを削除しようとすると、バックアップされていないので、その旨を知らせる警告メッセージが表示されます。しかし、それには正当な理由があります。一度消えてしまったら、特に保存していなければ、取り戻すのは難しいからです。

誤って必要なジャーナルレシーバーを削除してしまったときにすぐに対応し、その日の業務をリセットしなければならないスタッフなら、削除するべきものを誤りなく見つけたいと思うはずです。SQLを使ってOSの自動化や管理方法を向上させられるのも興味深い点です。ルールを見つけて、そうした作業を自動化することで、業務をスムーズに進められます。

このツールは、意図的にSYSTOOLSというスキーマに格納されています。使用したい場合は、どのようにコーディングされているかを確認してから直接使用することもできますし、SQLソースを抽出して、独自のパラメーターを持つ別のバージョンを作成することもできます。

グループPTF詳細情報

グループPTFの詳細情報を提供するSYSTOOLS.GROUP_PTF_DETAILSビューは、非常に古いサービスで、長い間存在しています。私たちが最初に作成したサービスの1つで、適用済みのPTFや、ロード済みだけれどまだ適用していないPTFなどの情報を表示します。

IBM i 7.6およびIBM i 7.5 TR6での進歩は、PTFに関する情報を提示するXMLのフィードが調整できたことです。この改善によって、SYSTOOLS.GROUP_PTF_DETAILSビューに対してSELECT文を実行することで、今すぐ適用できるハイパーPTFやセキュリティーPTFが調べられます。つまり、この高度なIBM iサービスを使用すると、今すぐ適用できるのに見逃しているPTFが調べられるのです。

機能強化されたそのほかの既存IBM iサービス

これまでお話した機能の他にも強化された機能が発表されています。たとえば、ジョブ情報を取得するための表関数QSYS2.JOB_INFO（）、システムディスク統計情報を取得するためのQSYS2.SYSDISKSTATビューや表関数QSYS2.SYSDISKSTAT()などの機能が強化されています。監視ソフトウェアを導入している人や管理者にとって、これらの機能が非常に役立つはずです。

こうした機能強化は、あらゆるIBM iサービスの構築に携わってきたチームを擁しているからこそできることで、用語やアプローチ、完全性など、あらゆる点をレビューすることで一貫性を保っています。そしていま、ジョブ情報には新しいパラメーターとしてジョブ名が追加されました。この新しいパラメーターによって、必要な情報をより早く取得できるようになります。これまでは、多くのジョブに関する情報を抽出した後、その中から特定のジョブ名をもつジョブの情報を取得する必要がありました。

IBM i 7.6とIBM i 7.5 TR6の違い

ここまで、IBM i 7.6 とIBM i 7.5 TR6の新機能および拡張機能について述べてきましたが、IBM i 7.6でしかサポートしていない機能もあります。これは、ハードウェアの問題ではなく、特別な理由によるものです。

取り組み中の各項目について、私たちはそれが技術更新の現実的な候補かどうかを検討します。その実現可能性は、以前のリリースに戻すのにかかるコストおよび必要な特定のコードを変更するリスクに左右されます。コストとリスクを検討し、お客様がそれを求めているかどうかも確認します。そして、セキュリティーも考慮するべき要素の１つです。SQLの進化がセキュリティー問題解決の役に立つのであれば、それは十分な検討理由の1つになるからです。

前述のグループPTFの詳細については、IBM i 7.4に戻しました。IBM i 7.4を利用されているお客様を、セキュリティー強化の適用までお待たせしたくなかったのがその理由です。例外は常に少しは許容しています。それに、コスト面もそれほど大きくありませんでしたので、この点に関しては少しルールを曲げることにしました。

通常、IBM i 7.6でしかサポートされないのは、TRでは対応しきれないような非常に巨大な機能です。たとえば、前述のデータ変更表参照におけるFINAL TABLEは、完成させるのが本当に大変な挑戦でした。表面的には「これはすばらしいプログラミング機能強化だ」という印象を受けるでしょう。しかし、実際には水面下で非常に多くの重労働を強いられており、パフォーマンスにも配慮しました。機能の提供を任されている時は、パフォーマンスにそれほど気を遣わないこともあるでしょうが、もちろんお客様はそれを必要としています。お客様はこれを本番環境で使うことを考えているので、パフォーマンスは常に関係しており、コスト面が本当に重要です。

おわりに

今回のIBM i 7.6の発表で一番良かった点の１つは、GA（一般提供）になった早さで、発表からわずか10日ほどで、だれでも利用できるようになりました。ベータ・プログラムは過去最高の出来で、ベータ・プログラムに参加してくださった皆さんから、報告を継続的に受け取っています。トピックごとの評価も頂けるので、何かが足りない、あるいは改善するべき点があればすぐに分かります。メディアの理解や評価も高く、少なくともここで述べた話題や認知度の高い話題について警鐘を鳴らすことはありませんでした。

IBM i 7.6には非常に明確な点が１つあります。それは、「IBM i 7.6は大きく進歩している」ということです。MFAが提供するセキュリティー機能だけがIBM i 7.6の特長ではありません。デフォルトで安全という点でも大きな進歩です。IBM i 7.6に移行しただけでもセキュリティーは向上し、デフォルトで安全です。そして、IBM i 7.6に移行すれば、もっと多くのことができるようになります。ですから、ぜひIBM i 7.6 を導入してください。きっと、だれにとっても要件に適した機能があるはずです。