COBOLプログラムを適切にテストおよびデバッグする方法

COBOLバージョン5.2または6.1に移行する際には、必ず課題に直面することになります。それらは移行の利点を妨げるものではありませんが、存在します。IBMによると、これらの移行問題の大部分はデータに関連しているため、徹底的なテストが重要です。今行うテストは、無駄なデバッグ作業を避け、潜在的な収益損失や顧客の失望を防ぐために役立ちます。COBOLバージョン5.2および6.1には、デバッガの動作に影響を与える変更がありますので、ツールセットはそれらの変更をサポートする必要があります。COBOLプログラマーが日々対処する5.2および6.1の言語にはいくつかの小さな外部の変更がありますが、内部の変更はより広範です。COBOLバージョン5.2および6.1の「バックエンド」は根本的に変わっており、日々変化し続けています。これらの新しいバージョンに対する頻繁な変更を継続的にサポートできるツールセットを使用することが不可欠です。以下は、移行するCOBOLプログラムを適切にテストおよびデバッグするためのベストプラクティスです：

1. テスト環境を準備する

テストスイートを見直し、厳格なテストの規律を導入します。アプリケーションを進めるにつれて、より経験が積まれ、馴染みのある再現可能な問題に遭遇することになります。見つけた問題を分類し、データや不適切なコーディングプラクティスに関連する一般的な問題を見つけるテストスイートを構築します。同様に、最新のIBMコンパイラーおよびLanguage Environmentのメンテナンスが最新であることを確認して、テストを最適化します。この情報についてはIBM COBOL修正リストを参照してください。コンパイラーとLanguage Environmentを最新の月次修正で更新するための体系的な計画を採用する必要があります。古いメンテナンスでテストを行うことは、無駄な時間と労力になります。

2. COBOLプログラムを修正する

COBOLプログラムを無造作に移行し始める前に、それぞれを分析し、修正が必要な箇所を特定する必要があります。私たちの同僚グレン・エヴェリットがこの重要性について以前書いていました。彼の結論は、早期にCOBOLプログラムの修正を怠ると、移行作業が想像以上に困難になるというものでした。私たちも同意します。移行のためにラインアップされた各アプリケーションをテストする際は、各アプリケーションが正しい結果を提供し、仕様どおりに機能し、期待される基準にスケールしていることを確認します。すべての例外やアボート条件も取り除きます。

3. 単体テストを開始する

メインフレームアプリケーションの単体テストも重要です。このプロセスにより、開発者はアプリケーションの小さな部分をテストして、より大きな部分に関与するテストプロセスに移行する前に低レベルのバグを見つけて修正できます。ただし、単体テストはメインフレーム開発ライフサイクルにおける最も弱い部分の1つです。手動プロセスが煩雑で、他の開発タスクから時間とエネルギーを奪うため、単体テストはしばしば無視されたり、未完の状態にされます。幸いなことに、メインフレーム環境における単体テストの不足は、自動化された単体テストツールの登場により徐々に変わりつつあります。これにより開発者は：

• コードの変更を即座に検証する
• 専門的なメインフレーム知識への依存を排除する
• Compuwareなどのツールを使用して単体テストでテストデータを自動的に収集し保持する
• 単体テストとテスト資産を自動的に生成する

自動化された単体テストにより、品質を迅速に提供することが容易になります。自動化とテストのアイデアは、COBOLバージョン5.2または6.1へのプログラム移行にも適用されます。単体テストは、プログラムの品質を早期に確保し、将来の移行問題を防ぎ、自動化はすでに時間のかかる移行プロセスでそのテストを加速します。

4. ソースデバッガに投資する

前述のように、COBOLバージョン5.2および6.1への変更は、デバッガの動作に影響を与えるため、これらの新しいバージョンをサポートするソースデバッガに投資する必要があります。最新のデバッガは、COBOLプログラマーの視点からデータへの最高の体験と直接のアクセスを提供します。5.2および6.1に意図されていないソースツールを使用することは避けてください。それは機械コードをステップ実行するようなもので、デバッグを著しく妨げることになります。私たちは、多くの顧客と協力して、Compuwareのアプリケーションデバッグ、障害管理、およびパフォーマンス分析ツールを使用して、COBOLバージョン5.2および6.1へのアプリケーションの移行を成功させました。これには以下が含まれます：

• 視覚的かつ対話的なデバッグのためのXpediter、プログラムがOPT(2)でコンパイルされている場合でも
• 5.2および6.1プログラム（最適化されたプログラムを含む）のアボート分析のためのAbend-AID
• 5.2および6.1プログラム（最適化されたプログラムを含む）のプロファイリングのためのStrobe

5. コンパイルオプションを活用する

コンパイルオプションを活用することで、プログラムを本番環境に移行する前にテストの問題を特定するのに役立ちます。テストで問題を特定するのに役立ついくつかのコンパイルオプションがありますが、以下は注目すべきコアオプションです：

• • SSRANGEは、テーブルの範囲外の問題を特定し、インデックスまたはサブスクリプトがテーブルの境界を超えてストレージを指すときにIGZ006Sメッセージを生成します。SSRANGEの使用はテストに制限すべきです。IBMによると、平均でCPU時間が18％増加する可能性があるとされています。

• • ZONECHECKは、ゾーンビットが数値でない場合に警告を生成するか、プログラムをアボートさせます。送信フィールドとして機能するゾーン付き10進変数の前にIF NUMERICクラスのテストを挿入します。

• • DIAGTRUNCは、コンパイル中に警告メッセージを生成し、移動文中に受信する数値変数が送信フィールドよりも少ない整数を含むことをプログラマーに警告します。これにより、切り捨てが問題を引き起こさないことを確認できます。

• • RULES(NOEVENPACK)は、パックデータが偶数の桁数を含む場合に警告メッセージを生成します。Enterprise COBOL for z/OS Programmer Guide V5.2 (またはV6.1)によると、パックデータは常に奇数の桁数を持つべきであり、切り捨てられたデータを防ぐために必要です。ただし、システムプログラマーは警告メッセージをエラーに変更し、コーディングの変更を強制することができます。

• RULES(NOLAXPERF)は、非効率的なコーディングプラクティスやパフォーマンスに影響を与えるコンパイラーオプションに対して警告を発行します。

プロセスの初期にCOBOLプログラムを適切にテストおよびデバッグすることで、移行の次のステップを妨げる大きな問題を防ぐことができます。そのメリットは、計画の次の段階であるアプリケーションの最適化において顕著に現れます。

これらの投稿は私自身のものであり、BMCの立場、戦略、または意見を必ずしも表しているわけではありません。