ポイント: IBMのzIIP（System Z Integrated Information Processor）は、特定のワークロードが低いソフトウェアコストで動作し、処理効率を向上させることを可能にします。主な制限には、SRB内での実行を必要とするコードの制限があり、特定のz/OSサービスへのアクセスが制限されます。
- zIIPプロセッサーは、ソフトウェア料金なしで処理に大幅なコスト削減を提供します。
- 特定の基準を満たすコードのみがzIIPで実行できるため、広範な適用性が制限されます。
Phil GraingerのzIIPオフロードに関する投稿のフォローアップとして、zIIP上で実行できるコードの特性や、一般的なプロセッサー（GP）ではなくzIIPで実行するように書き直した場合に最小限のパフォーマンス損失を被る可能性のあるコードに焦点を当てる価値があると思いました。IBMは2006年にzIIP（System Z Integrated Information Processor）を導入しました。IBMはGPの対応する料金のごく一部でzIIPハードウェアをライセンス供与しています。あなたにとってより重要なのは、zIIPプロセッサーはソフトウェア料金の基準にカウントされないため、GPからzIIPにワークロードをシフトすることで大幅なコスト削減が見込めることです。さらに、zIIPプロセッサーは「フルスピード」で動作するため、GPのキャパシティモデルがフルではない場合、より短時間でより多くの処理が実行できます。では、なぜすべてのGPをzIIPに置き換えて、ハードウェアとソフトウェアの両方でお金を節約しないのでしょうか？まず、IBMはzIIPの使用に制限を設けています。元々、CEC内のGPごとに1つのzIIPしか存在できませんでしたが、現在のモデルの中にはGPごとに2つのzIIPを許可するものもあります。次に、IBMのライセンス契約はzIIPで実行可能なコードの種類に制限を設けています。コードはSRB（サービスリクエストブロック）の制御下でz/OSエンクレーブ内で実行される必要があります。エンクレーブの使用は、z/OSワークロードマネージャー（WLM）によって作業が配信されることを意味します。エンクレーブから実行されるコードは、共通の特徴セットを持つため、共通のWLM制御とポリシーによって処理されることができます。SRBをスケジューリングする代わりにタスク制御ブロック（TCB）をアタッチすることは、さらに制限を意味します。これらの中で最も重要なのは、SVC（ABENDを除く）を発行できないことです。これにより、アプリケーションプログラムが一般的に呼び出す多くのz/OSサービスの使用が妨げられます。これは「zIIPでI/Oを行うことはできない」という誤解を招いていますが、これは真実ではありません。ただし、QSAMやBSAMは、多くのアプリケーションプログラムが順次ファイルI/Oを行うために使用するため、SRBコードから呼び出すことができません。完全性のために、IBMがzAAPがない環境でzIIPで実行されることを許可する「zAAP on zIIP」を言及するべきです。このプロファイルに合うレガシーコードは非常に少ないですが、レガシーCOBOLアプリケーションをJavaに変換しているDb2インストールが増えています。プログラマーを見つけるのがCOBOLスキルを持つ者よりも簡単だからです。この移行の副産物は、レガシーアプリケーションがJavaに書き直された後にzIIP適格となることです。では、なぜあなたのメインフレームベンダーはすべての製品のすべてのコードをzIIP有効化しないのでしょうか？その答えは、前述の2番目の制限に戻ります—zIIP適格であるためには、コードはSRB内で実行されなければならず、したがって多くのz/OSサービスを呼び出すことができません。ほとんどの既存の製品コードはTCBモードで実行されるように書かれています。歴史的に、SRBモードのコードはクロスメモリ処理を行うコスト効率の良い方法と見なされた場所でのみ使用されました。では、今日TCBの下で実行され、SVC呼び出しを行わないソフトウェア製品の一部である仮想的なコードを見てみましょう。コードをzIIP適格にするためには、コードを実行するたびに以下のようなことを行う必要があります：
- 実行されるコードを指すメモリ内のSRBをセットアップします。
- SRBの実行をスケジュールするためにIEAMSCHEDマクロを発行します。
- 元々実行中のTCBコードはSRBコードが実行されるのを待たなければなりません。
- SRBコードが完了すると、TCBコードが再開するように信号を送る必要があります。
あるいは、SRBを一度開始し、SRBコード内でループして待機することもできます。その場合、機能を実行するたびに新しいSRBをスケジュールする必要はありません。TCBモードからSRBモードに移行したり、その逆に戻ったりする際にかかるオーバーヘッドはCPUコストを引き起こします。ベンダーは、どのコードがユーザーにとって最も効率的であるかを判断するために、コードをzIIP適格にすることの利点とCPUコストを天秤にかけます。ベンダーは、可能な範囲で自社製品をzIIP適格にすべきです。CPU集約的であるプログラム、SRBから呼び出せないz/OSサービスの呼び出しを含まないプログラム、あまり多くのI/Oを必要としないプログラムに焦点を当てるべきです。プログラムは、GPでのCPUコスト削減が大幅になるほど頻繁に実行されなければなりません。すべてのz/OSソフトウェア製品のすべてのコードをGPの代わりにzIIPで実行できるようにするのは理想的ですが、それは現実的ではありません。最後に、第三者ベンダーが自社のコードをzIIP有効化することを許可するライセンスは、他のコードをzIIPで実行するために有効化するためにライセンスを使用することを特に禁止しています。したがって、ベンダーは自分たちが書いたコードをzIIP有効化することはできますが、顧客のコードをzIIP有効化するためのツールを書くことはできません。この情報が、ベンダーとのzIIP利用可能性を議論するのに必要な情報を提供することを願っています。
これらの投稿は私自身の意見であり、必ずしもBMCの立場、戦略、または意見を表すものではありません。