この質問は、数十年前の CICS トランザクションが、z/OS Connect や類似のミドルウェアを介して最新の REST API として利用できるようにする企業のモダナイゼーションの取り組みに由来します。課題は、ステートレスな HTTP プロトコルとステートフルな CICS トランザクションコンテキストとの間のインピーダンスミスマッチにあります。特に、JSON と COBOL コピーコントロール間のデータのマッピングに関しては非常に複雑です。歴史的に、純粋なメインフレームグリーンスクリーンテストや最新のマイクロサービス向けに設計された手動QAアプローチは、このハイブリッド境界に対して不十分であり、特定の負荷条件やデータエッジケースでのみ現れる製品欠陥を引き起こします。
手動QAはこの環境で独自の課題に直面しています。欠陥は分散システムの挙動とレガシーメインフレームの制約の交差点で現れるためです。COMMAREA バッファは COBOL コピーコントロールで定義された固定長ですが、JSON ペイロードは可変長であり、z/OS Connect がデータマッピングを行うときに明示的なエラーではなく静かな切り捨てが原因となります。さらに、データベースの一貫性のために EXEC CICS SYNCPOINT を使用する CICS トランザクションは、主要なフレームがコミットする前に REST クライアントがタイムアウトした場合、孤立したレコードを残す可能性がありますが、HTTP 応答は誤解を招くように成功を示すかもしれません。最後に、非同期処理に対する TDQ トリガーは、RLS レコードロックの競合中に複数回発火し、重複したワークフローの発生を引き起こします。これは自動APIテストでは検出できません。
体系的方法論は、3つの検証レイヤーが必要です。
まず、境界分析テストでは、コピーコントロールに由来する同等パーティショニングを使用して、正確な COMMAREA 長さの制限でペイロードを注入し、EIBCALEN (実行インターフェースブロック通信エリアの長さ) が COBOL プログラム内の期待値と一致することを確認します。
次に、トランザクション整合性検証では、ネットワークプロキシを設定して、送信中の SYNCPOINT 操作中に意図的なタイムアウトを導入します。次に、CEMT (マスタ端末) コマンドを使用して CICS リージョンの状態を調査し、z/OS システムロガーを使用して UR (回復単位) の結果を監査します。
最後に、同時ストレステストでは、複数の REST クライアントを使用して RLS の競合をシミュレートし、TDQ の冪等性を確認し、CEBR (ブラウザトランザクション) キューの検査と VSAM EXAMINE ユーティリティを使用してファイル整合性を検証します。
ある大手保険会社は、ポリシー照会の CICS トランザクションを顧客向けモバイルアプリに REST API 経由で移行しました。デプロイ後、ポリシーホルダーの住所が途中で切り捨てられるという断続的なデータ破損が発生し、高価値の顧客には重複したポリシー承認書が送付され、規制コンプライアンスリスクと評判の損失を引き起こしました。
COBOL コピーコントロールは住所フィールドを PIC X(30) と定義しましたが、モバイルアプリはマルチバイトのアクセントキャラクターを含む Unicode UTF-8 文字を送信しました。z/OS Connect がこれを EBCDIC にマッピングする際、バイト数がバッファを超えて例外を引き起こすことはなく、静かな切り捨てロジックが原因でました。さらに、運用負荷下では、RLS ロックが最初のトリガーの認識を遅延させると、TDQ トリガーが2回発火し、同一のリクエストが2回処理されることで、コレスポンデンスバッチジョブが実行されました。
解決策 1: スタブメインフレームによる自動APIテスト
チームは、実際のメインフレームにヒットせずに CICS の応答をシミュレートするために WireMock を使用することを検討しました。このアプローチにより、迅速な回帰テストが可能です。
メリット: 高速な実行サイクル、高価なメインフレーム MIPS の消費がなく、メインフレーム接続なしで CI/CD パイプラインを実行できます。
デメリット: COMMAREA の切り捨ての挙動、VSAM ロック競合、または実際の EBCDIC エンコーディング変換エラーを検出できず、テストのカバレッジに対して誤った信頼を提供します。
解決策 2: 直接 CICS リージョンデバッグ
CEDX (実行診断機能) に付加して、すべての EXEC CICS 呼び出しをトレースし、リアルタイムで COMMAREA の内容を検査します。
メリット: 正確なコマンドの失敗を特定し、COBOL 構造の生のメモリレイアウトを表示します。
デメリット: QAチームに不足している専門的なメインフレームの専門知識が必要で、CICS リージョンのパフォーマンスに大きな影響を与え、分散した REST クライアントとメインフレーム間の現実的なネットワーク遅延をシミュレートできません。
解決策 3: CEBR 検査による体系的な手動境界テスト
手動で Postman または cURL を使用して、29、30、31文字のペイロード長で REST リクエストを作成し、次に CEBR を使用して TDQ の内容を検査し、CEMT INQUIRE FILE を使用して VSAM RLS ロック状態を確認します。
メリット: 文字エンコーディング変換、COMMAREA 境界の強制、複数の CICS リージョン間の RLS ロック動作を含む、実際の本番コードパスを検証します。
デメリット: メインフレーム TSO アクセス資格情報と CICS 端末インタラクションスキルを必要とする手間のかかる手動プロセスです。
解決策 3 が選択されました。なぜなら、直接の検証だけが静かな COMMAREA オーバーフローや RLS 競合下での TDQ の重複発火条件を露呈する可能性があるからです。チームは、ペイロードの長さ (境界値)、文字セット (ASCII 対 EBCDIC 対 UTF-8)、および同時ユーザー負荷 (5、10、および20件の同時リクエスト) を変化させる包括的なテストマトリックスを作成しました。
彼らは CEDF を利用して COBOL プログラムの実行をステップスルーし、EIBCALEN の値を確認し、プログラムロジックが処理前に受信バッファ長を検証していないことを確認しました。TDQ の問題については、並行アクセスシナリオの間にトリガー数を監視するために CEMT INQUIRE TDQUEUE を使用しました。
テストでは、30バイトを超える UTF-8 文字 (文字ではなく) によって切り捨てが起こることが明らかになりました。特に、顧客が複数のアクセント文字を持つ住所を入力するときに発生しました。COBOL プログラムは、EIBCALEN を期待される COMMAREA 長と照らし合わせて確認し、特定の HTTP 400 エラーコードで超過ペイロードを拒否するように修正されました。
TDQ の問題に関して、テストにより RLS ロック待機が2秒を超えると、REST ゲートウェイの再試行ロジックが重複した TDQ エントリを作成することが分かりました。アーキテクチャは、重複トリガーがバッチプロセッサによって検出されて破棄されることを保証するために、ユニークな相関IDを DFHCOMMAREA を通じて渡す冪等処理を実装するよう修正されました。デプロイ後のモニタリングでは、切り捨てエラーがゼロになり、重複したコレスポンデンスが排除されました。
REST クライアントがリクエストを送信した後、応答を受信する前に切断された場合、CICS トランザクションのロールバック動作をどのように検証しますか？
ほとんどの候補者は、切断後のデータベースの状態をチェックすることを単に提案します。正しいアプローチは、CEMT INQUIRE TASK を使用してトランザクションが CICS リージョンから削除されたことを確認し、その後 z/OS の System Logger LOGSTREAM を調べて UR (回復単位) がバックアウトされたことを確認することです。さらに、孤立したレコードが存在しないことを確認するために IDCAMS VERIFY を使用して VSAM RBA (相対バイトアドレス) の整合性を確認する必要があります。候補者が見落としがちな微妙なポイントは、CICS がローカルにコミットされている場合でも、REST ゲートウェイが承認を送信していない可能性があることです。HCON (HTTP接続) タイムアウトと CICS 中断コード (例えば AEXZ (タイムアウト)) 用の z/OS Connect エラーログの確認が必要です。
TDQ 処理をテストする場合、同じ CICS リージョン内で処理されるイントラパーティション TDQ トリガーと、z/OS データセットに書き込まれ、バッチジョブによって処理されるエクストラパーティション TDQ トリガーをどのように区別しますか？
候補者は、TDQ の動作が DCT (デスティネーショントランザクションテーブル) 内の DESTID 定義に基づいて根本的に変わることを見落としがちです。イントラパーティション TDQ (メモリベース) の場合、CEBR を使用してキューの深さを検査し、CEMT SET TDQUEUE を使用して手動で処理をトリガーし、即座に CICS トランザクションが開始されることを確認します。エクストラパーティション TDQ の場合、その物理的な z/OS データセットを監視し、トリガーレコードが出現するのを観察し、その後、イニシエータ JOB クラスの実行を確認する必要があります。重要な違いは、イントラパーティション TDQ は SYNCPOINT によって CICS トランザクションの整合性を維持し、エクストラパーティション TDQ は、同じ DESTID にアクセスしている CICS とバッチジョブ間のレコード削除競合条件を防ぐために、別の VSAM RLS ロック戦略が必要です。
OCCURS DEPENDING ON (ODO) 条項を持つコピーコントロールで JSON から COBOL へのマッピングをどのように検証しますか？
多くのテスターは、固定長構造だけをチェックし、ODO の複雑さを見逃します。ODO 条項については、z/OS Connect が COMMAREA 内の配列データの前に依存カウンターフィールドを正しく埋め込んでいることを確認する必要があります。テストケースには、(1) ゼロの出現（空の配列）、(2) 単一の出現、(3) 最大定義出現、(4) 最大出現を超えた場合を含め、拒否処理のハンドリングを検証します。CEBR または CEDF を使用して COMMAREA のレイアウトを16進数で検査し、JSON 数値変換後にバイナリ COMP フィールドが正しい ビッグエンディアン バイト順序を維持していることを確認します。JSON 配列には明示的な長さインジケーターがないため、マッパーは要素カウントから ODO 値を計算しなければならないという複雑さがあります。これにより、JSON ペイロード内に null 値が存在する場合、誤カウントが発生し、COBOL テーブルのオーバーフローや切り捨てを引き起こす可能性があります。