オープン系がポピュラーになる以前の汎用機では、開発、バッチ、オンラインなどを一台で処理していました。

それゆえ、違う特性のジョブを「うまく組み合わせる」といったことが重要な技術でした。メインフレームのとても細かいディスパッチのプライオリティなどに、その名残りを見ることができます。しかし、現在のメインフレームにおいて、パフォーマンスチューニングは考え方はオープン系と、そう変わりません。

チューニングのゴール

さてチューニングは、なぜ行うのでしょうか？そこには必ず不満があるはずです。多くの場合「どうも遅い」という感覚的な議論からスタートします。この感覚を数値化することがチューニングの最初にするべきことです。
個人所有のパソコンと比較すると理由がわかると思います。新しいグラフィックボードが出たから、即購入してどれくらいの速度になるか確認する、その速度がパフォーマンス、というようなことは個人だからできることです。企業では必ず「投資と効果」というものを問われます。「早ければいい」と数十億円をつっこんでいいという恵まれた環境は通常は夢だと考えていいでしょう。
そうすると、「どこまで早ければいいのか？」というゴールが必要です。このゴールを設定しない限り、チューニング作業にはかかれない、ということを理解しましょう。具体的にはバッチ群が４時間以内に終わること、とか、IMSトランザクションの端末レスポンスタイムが２秒以内であること、などになるかと思います。

データ収集

これはいきなり、メモリーだ、ＣＰＵだ、というのではなく、作業システム全体から考えることが必須です。例えば他社からのテープが午後５時に到着し、それから６時間で終わればいいジョブなのに、いつも８時にならないと届かない、それゆえジョブスケジュールが狂っている、といったこともあり得ます。担当の人から、ボトルネックが自明のことであっても説明がなされていなければ、後々、予算化の段階で説得力をもたないのです。「システム」とは、作業をふくめたビジネスサイクルのことをいいます。
メインフレームの場合、コンピュータシステムのデータの収集は比較的ラクです。ログ、統計データを出力しないソフトウェアのほうが稀です。基本的には、RMF、Tivoli Decision SupportやOMEGAMONなどを使うことでしょう。

分析

次に原因調査にかかるわけですが、最初に見つけるべきことは「クリティカルなリソースはどこだ？」ということです。通常、ボトルネックの発見といわれています。ボトルネックとは、ハードウェアまたはソフトウェアの一部が能力の限界に近づき、システム全体の「足をひっぱっている」状態です。
たとえばボトルネックは多くの場合、非常に使用率が高いはずです。ただ、注意しなくてはいけないことは、「使用率が高いからボトルネックである」は真ではないことです。当たり前の例ですが、キャッシュのヒット率が高い、ということはボトルネックではありませんね。因果関係を意識しながらデータの収集が必要となります。
それゆえデータ収集したレポートは、OS,IMS,DB2などの専門家が見ないと意味を見誤ることがありますし、話し合いによりシステムの動作を把握できていることを理解することが必要です。

ひとつ注意点があります。オープン系の常識をメインフレームに持ち込まないことです。例えば、オープン系ではページングはあまり起きないように設定します。(ページスペースもせいぜい、リアルメモリの２倍くらいしか用意しないでしょう。)しかし、メインフレームはI/Oが強力であるため、秒100件程度のページングでかまわない場合もあります。

対処

一般的なコンピュータシステムの場合、最終的なボトルネックはCPUとなることが多いです。なぜならば、すべてのスケジュールもI/Oも問題ない場合、最終的には処理能力の問題となるからです。

あいにくCPU処理の大半はOSとDBMS(データベースマネージメントシステム)が消費します。そのため、一般的には 最大CPU使用率：90％以上が限界、といった一般的指標を目安とします。

とはいえ、各サブコンポーネント毎に対処が取られることもあるでしょうし、メモリー不足からリアルメモリーの購入が必要になることもあるかも知れません。
忘れてはいけないのは、リソースを追加することで、ゴールに近づけるか、達成できるか、といった観点からレビューすることです。技術的にはついつい、「こうしたら、もっと早くなるんじゃないの？」と思いがちですが、変更点をいくつも作ってしまうと、後のレビューサイクルがやりにくくなります。
一番わかりやすいのは、構成変更を一度にひとつだけにすることです。これだと評価しやすいです。

テスト/評価

構成を変更した以上、サイドエフェクト（影響）がないか調べること、思ったとおりの効果をあげているか監視することが大事です。
期待したゴールにパフォーマンスが向上すれば、チューニングサイクルは一段落です。しない場合は、次の可能性をテストすることになります。

チューニングサイクルはこれで終わりではありません。「システムは生き物」とよく言います。少しずつ変化していきます。パフォーマンスデータを定期的に集計しておき、トレンドを見ることがもっとも有効なチューニング、キャパシティプランニングに繋がる道です。