導入: なぜ今、リトライ処理が重要なのか
業務システムにおいて、ファイル操作やデータベースアクセスは避けて通れません。しかし、複数のジョブが同時に同じファイルにアクセスすると、一時的な「共有違反」や「デッドロック」が発生することがあります。かつては、このエラーを検知するたびに煩雑なIF文やGOTO文を駆使してリトライ処理を書いていたものです。しかし、モダンCOBOL（COBOL 2002以降）では、言語仕様としてスマートに再試行を制御できるようになりました。これにより、コードの可読性が格段に向上し、障害に強い堅牢なプログラムが書けるようになります。
基礎知識: エラー時再試行の仕組み
リトライ処理とは、簡単に言えば「操作が失敗したときに、すぐ諦めるのではなく、少し時間を置いてからもう一度試す」という仕組みです。従来はアプリケーション層で細かく制御していましたが、モダンCOBOLでは例外処理やI/O制御の拡張により、エラーの種類に応じて自動的に再試行を繰り返すロジックが組み込みやすくなっています。特に「排他制御（レコードロック）」による競合を、プログラム側でいかにエレガントに捌くかが、ベテランエンジニアの腕の見せ所です。
実装/解決策: ロジックの組み立て方
リトライを実装する際は、「リトライ回数の上限」と「待機時間（インターバル）」を必ず設定してください。無限ループに陥ることを防ぐためです。今回は、ファイル操作時の例外を補足し、再試行を行う基本的なパターンを紹介します。
サンプルプログラム
以下のコードは、ファイル読み込みが排他エラーとなった場合に、最大3回まで再試行する論理モデルです。
IDENTIFICATION DIVISION.
PROGRAM-ID. RETRY-SAMPLE.
WORKING-STORAGE SECTION.
01 WS-RETRY-COUNT PIC 9(01) VALUE 0.
01 WS-MAX-RETRY PIC 9(01) VALUE 3.
01 WS-STATUS PIC X(02).
PROCEDURE DIVISION.
PERFORM UNTIL WS-RETRY-COUNT >= WS-MAX-RETRY
- ファイルの読み込み試行
READ FILE-NAME
- 正常終了時(STATUS:00)はループを抜ける
IF FS = ’00’
EXIT PERFORM
- 排他エラー(STATUS:99など※環境依存)の場合リトライ
ELSE IF FS = ’99’
ADD 1 TO WS-RETRY-COUNT
DISPLAY “競合発生: ” WS-RETRY-COUNT “回目の再試行待機中…”
- 実際にはここでシステム待機関数などを呼び出す
PERFORM WAIT-PROCESS
ELSE
- その他の致命的エラー
DISPLAY “致命的エラー発生: ” FS
STOP RUN
END-IF
END-PERFORM.
IF WS-RETRY-COUNT >= WS-MAX-RETRY
DISPLAY “最大リトライ回数に達したため異常終了します。”
STOP RUN.
END-IF.
STOP RUN.
WAIT-PROCESS.
- 待機処理（実装依存のSLEEP処理などを配置）
CONTINUE.
応用・注意点: 現場で陥りやすい罠
リトライ処理を実装する際の最大の注意点は「待機時間の設計」です。短すぎるとリソースを消費し続け、長すぎると全体の処理時間が圧迫されます。また、「リトライすべきエラー」と「リトライしても無駄なエラー（ファイルが存在しない、権限がない等）」を明確に区別することが重要です。すべてのエラーに対してリトライをかけてしまうと、バグの発見が遅れる原因になります。必ずファイルステータスコードを確認し、再試行が有効なエラーのみを対象にするよう心がけましょう。
コメント