グローバル企業はどのようにメインフレームのキャパシティ危機を解決しているのか：3つの実例 

私たちは日々、多くのメインフレーム利用企業と対話する中で、高ボリューム環境を効率的かつ低コストで運用する難しさを伺っています。そして、キャパシティの課題は 必ずしも処理量が多いことだけが原因ではないことを理解しています。同じ時間帯・同じリソースに ワークロードが集中しすぎることこそが、本質的な問題となるケースが多いのです。 

リソース競合が発生するのは、次のような場合です。 

• 多数のバッチジョブが同時にGP CPUへ集中する場合
• 制約のある同一リソースを複数の処理が奪い合う場合 
• 遅延やSLA未達、オンライン処理との重複を引き起こす場合 

JOPAZ は、アプリケーションに一切手を加えることなく、負荷の大きい COBOL バッチ処理をより効率的なエンジンへ再配置することで、ピーク時の挙動を最適化し、システム全体のバランスを整えます。 

何が変わるのか？ 実行パス、CPUの動作、および実行時環境（JVM） 

変わらないもの： COBOLソースコード、データ、スケジューリングフレームワーク、および出力 

以下では、異なる業界に属する3つの大手企業が、深刻なリソース競合の課題を根本的に解決しながら、どのように驚異的なCPU削減を実現したのかをご紹介します。 

1. 会員サービス企業：R4HAピークの解消 

北米の大手会員サービス企業（自動車、旅行、金融サービスを提供）にとって、予測可能な運用を実現することは最優先事項でした。しかし、バッチ処理が 4時間移動平均 (R4HA：Rolling 4-Hour Average）のコストを押し上げており、ワークロードをより適切に分散させることが急務となっていました。 

戦略：

この組織は、ワークロード競合の根本原因に対処するために JOPAZ を採用しました。 

• COBOLバッチソースコードをJavaバイトコードにコンパイルしました 
• そのコードは Unix System Services 上の JVM で実行されました 

これにより IBM zIIP エンジンを活用できるようになり、実行処理を再分配することで GP（汎用プロセッサ）へのピーク負荷を大幅に軽減できました。 

セットアップ： 

• COBOL Db2 環境  
• 結果は、順次ファイル（シーケンシャルファイル）を用いたテストでも検証されました 

結果：

効果は即座で、しかも圧倒的でした 

JOPAZなし 

• CPU時間 47.96秒 

JOPAZ 使用時 

• CPU 時間 2.47 秒（95% 削減） 
• バッチ COBOL の CPU 使用量を 94.84% 削減 
• 新たなワークロード向けに MSU を再確保 
• 元のソースコードへの変更は一切不要でした 

2. 小売エネルギー事業者：効率化への投資

大規模な Db2 基盤を抱える北米の大手エネルギー供給事業者は、既存の処理リソースをより戦略的に活用する方法を必要としていました。

戦略

最初の事例と同様に、この顧客もバッチ COBOL を zIIP エンジンで実行可能にするため、JOPAZ を採用しました。今回のケースでは、当初 JOPAZ が利用できる zIIP の空き容量が限られていたため、初期結果が成功を収めた後、2 台目の zIIP が追加されました。

セットアップ：

• COBOL Db2 環境
• 3 つのバッチ処理を使用しました。これらの各バッチ処理には Db2 にアクセスする COBOL プログラムが含まれており、さらにそれぞれ複数のステップで構成されていました。

結果

JOPAZなし

• CPU時間 2分26秒27
• 処理時間 14 分 10 秒

JOPAZ 利用時：zIIP エンジン １基

• CPU 時間 14.4 秒（90% 削減）
• 処理時間 5分44秒（60%削減）
• バッチ COBOL の CPU 使用量を 76% 削減

JOPAZ 利用時：zIIP エンジン 2基

• CPU 時間 6.97 秒（95% 削減）
• 処理時間 8分40秒（39% 減）
• バッチ COBOL の CPU 使用量を 96.7% 削減

初期テストの結果が非常に有望だったため、顧客はプロジェクト完遂に向けて即座に専任リソースを投入することを決定しました。何よりも重要なのは、コードやビジネスロジックを一切変更することなく、この成果を実現できた点です。

3. 決済テクノロジー企業：複雑性と VSAM への挑戦

南米に拠点を置く大手決済テクノロジー企業は、年間数十億件のトランザクションを処理しています。他の事例とは異なり、この企業は従来型データベースを一切使用しない純粋な VSAM ベースで、非常に大規模かつ複雑なアプリケーション群が稼働していました。

戦略

ラック内には十分に活用されていない zIIP プロセッサが 4 基も搭載されていたことから、同社は JOPAZ を GP キャパシティ回復の最適解と捉えました。まずは 5万4千行に及ぶ複雑なプログラムを再コンパイルするところから着手しました。顧客の言葉を借りれば、『このアプリケーションを JOPAZ が処理できるなら、どんなアプリケーションでも処理できる』ということです。

セットアップ：

• 全体のワークロードの 35% を COBOL バッチが占めています
• 従来型データベースを一切使用しない、純粋な VSAM 環境
• 十分に活用されていない zIIP プロセッサが 4 基存在

結果

• バッチ COBOL の CPU 使用量を 97% 削減
• 既存のメインフレーム環境からより多くのキャパシティを引き出し、ROI を最大化
• 業務に一切の中断を発生させることなく、通常どおりの運用を維持

結論

お客様が証言しているように、モダナイゼーションは必ずしもリスクの高い、数年がかりのクラウド移行を意味するものではありません。課題は COBOL が動くかどうかではなく、ごく一部のジョブが重要な時間帯に過度な負荷を生み出しているかどうかです。多くの企業は、ワークロードを変更する（書き換え、再スケジューリング、削除）代わりに、実行場所を変えるだけで、バッチ COBOL の CPU 使用量のほぼすべてを取り戻しています。

Db2、VSAM、Adabas、あるいはシーケンシャルファイルを扱っている場合でも、結果は常に 80% 超の CPU 削減を示しており、多いときには 97% に達します。しかも、実績あるビジネスロジックは一切変更する必要がありません。

こちらもご覧ください

ページ

JOPAZ デモ

JOPAZ デモによる モダナイゼーションが、ビジネスリスクを伴うことなく COBOL ワークロードを変革し、貴重なリソースを解放する方法をご覧ください。

ページ

JOPAZでメインフレームのCOBOLワークロードを削減

JOPAZは、COBOLコードをJavaバイトコードにコンパイルし、zIIPプロセッサ上でワークロードを実行することで、コードを変更することなくメインフレームのCPU使用率を低減し、処理能力を解放します。

ブログ schedule 4分で読めます

メインフレームを最適化：IBM Z を安全かつ最大限に活用

JOPAZ は COBOL ワークロードを zIIP 対応の Java にコンパイルすることで IBM Z 上で最適化し、ビジネスへの影響ゼロで AI・分析・イノベーション向けの GP キャパシティを取り戻します。