이 질문은 수십 년 된 CICS 트랜잭션이 핵심 은행 또는 보험 시스템을 현대적인 REST API 형태로 z/OS Connect와 같은 미들웨어를 통해 노출하는 기업 현대화 이니셔티브에서 유래하였습니다. 여기서 복잡성은 Stateless HTTP 프로토콜과 Stateful CICS 트랜잭션 컨텍스트 간의 임피던스 불일치로 인해 발생하며, 특히 JSON과 COBOL 복사본 간의 데이터 마샬링과 관련이 있습니다. 역사적으로 순수 메인프레임 녹색 화면 테스트 또는 현대 마이크로서비스를 위해 설계된 수동 품질 보증 접근 방식은 이 혼합 경계에 대해 불충분하여 특정 부하 조건이나 데이터 엣지 케이스에서만 생산 결함을 유발하게 됩니다.
이 환경에서 수동 품질 보증은 분산 시스템 동작과 레거시 메인프레임 제약 간의 교차점에서 결함이 나타나기 때문에 독특한 도전에 직면합니다. COMMAREA 버퍼는 COBOL 복사본에서 정의된 고정 길이를 가지지만, JSON 페이로드는 가변 길이로 되어 재시도 오류 없이 조용히 잘라내지며, z/OS Connect가 데이터 매핑을 수행할 때 명시적인 오류가 발생하지 않습니다. 또한 EXEC CICS SYNCPOINT를 사용하는 CICS 트랜잭션은 클라이언트의 타임아웃 전까지 데이터베이스 일관성을 유지할 수 있지만, HTTP 응답이 성공으로 잘못 표시될 수 있어 고아 레코드가 남을 수 있습니다. 마지막으로, TDQ 트리거는 여러 CICS 영역 간의 RLS 레코드 잠금 경합 중에 여러 번 발동할 수 있어, 자동화된 API 테스트로는 감지할 수 없는 중복 작업 흐름이 시작될 수 있습니다.
체계적인 방법론은 세 가지 검증 레이어를 요구합니다.
첫째, 경계 값 분석 테스트는 복사본으로 파생된 동등 클래스 분할을 사용하여 정확한 COMMAREA 길이 한계에서 페이로드를 삽입하고 EIBCALEN(Execute Interface Block Communication Area Length)이 COBOL 프로그램에서 기대하는 값과 일치하는지 확인합니다.
둘째, 트랜잭셔널 무결성 검증에서는 네트워크 프록시를 구성하여 운영 중 SYNCPOINT 작업 중 의도적으로 타임아웃을 유도한 후, CEMT(Master Terminal) 명령어를 사용하여 CICS 영역 상태를 검사하고 z/OS System Logger를 이용하여 UR(Unit of Recovery) 결과를 감사합니다.
셋째, 동시성 스트레스 테스트는 여러 REST 클라이언트를 사용하여 RLS 경합을 시뮬레이션하고, CEBR(Browse Transaction) 큐 검사와 VSAM EXAMINE 유틸리티를 통해 TDQ의 아이도포턴스를 확인합니다.
한 대형 보험 회사는 고객 대면 모바일 앱을 통해 문의 CICS 트랜잭션을 재배포하였습니다. 배포 후, 특정 고객 주소가 거리 이름의 중간에서 잘리는 데이터 손상 문제와 고부가가치 고객에게 중복으로 정책 보증서가 발송되는 문제가 발생하여 규제 준수 위험 및 평판 손상을 초래했습니다.
COBOL 복사본은 주소 필드를 **PIC X(30)**으로 정의했지만, 모바일 앱은 다중 바이트 악센트 문자를 포함한 유니코드 UTF-8 문자를 전송했습니다. 이로 인해 z/OS Connect가 이를 EBCDIC로 매핑할 때 바이트 수가 버퍼를 초과하게 되며, 조용한 잘림 논리 때문에 예외가 발생하지 않았습니다. 한편, 생산 부하 아래에서 TDQ 트리거는 RLS 잠금이 첫 번째 트리거 인정을 지연하게 되어 두 번 발동되었습니다.
해결책 1: 스텁된 메인프레임을 사용하는 자동화된 API 테스트
팀은 실제 메인프레임을 통하지 않고 CICS 응답을 시뮬레이트하기 위해 WireMock을 사용하는 것을 고려했습니다.
장점: 빠른 실행 주기, 비싼 메인프레임 MIPS 소비 없음, 메인프레임 연결 없이 CI/CD 파이프라인에서 실행 가능.
단점: COMMAREA 잘림 동작, VSAM 잠금 경합 또는 실제 EBCDIC 인코딩 변환 오류를 감지할 수 없으며, 테스트 커버리지에 대한 잘못된 확신을 제공합니다.
해결책 2: 직접 CICS 지역 디버깅
CEDX(Execution Diagnostic Facility)를 연결해 각 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 오버플로우 및 TDQ 중복 발화 조건을 드러낼 수 있기 때문입니다. 팀은 페이로드 길이(경계 값), 문자 세트(ASCII vs EBCDIC vs UTF-8) 및 동시 사용자 부하(5, 10 및 20개의 동시 요청)를 다양하게 하는 포괄적인 테스트 매트릭스를 작성하였습니다.
그들은 CEDF를 활용해 COBOL 프로그램 실행을 단계별로 검사하고 EIBCALEN 값을 확인하여 프로그램 논리가 수신 버퍼 길이를 검증하기 전에 작동하지 않음을 확인했습니다. TDQ 문제에 대해, 그들은 동시 접근 시나리오 동안 트리거 카운트를 모니터링하기 위해 CEMT INQUIRE TDQUEUE를 사용했습니다.
테스트 결과 UTF-8 문자가 30바이트(문자가 아님)를 초과하면 잘림 현상이 발생했음을 발견했습니다. 특히 고객이 여러 개의 악센트 문자가 포함된 주소를 입력했을 때 그런 현상이 나타났습니다. COBOL 프로그램은 EIBCALEN을 기대하는 COMMAREA 길이와 비교하고, 과도한 페이로드를 특정 HTTP 400 오류 코드로 거부하도록 수정되었습니다.
TDQ 문제의 경우, 테스트에서 RLS 잠금 대기 시간이 2초를 초과하면 REST 게이트웨이의 재시도 논리에 의해 중복 TDQ 항목이 생성된 사실을 발견했습니다. 아키텍처는 DFHCOMMAREA를 통해 전달되는 고유한 상관 ID를 사용해 아이도포턴트 처리를 구현하도록 수정되어, 중복 트리거가 배치 프로세서에 의해 감지되고 폐쇄되도록 하였습니다. 배포 후 모니터링에서 잘림 오류가 없고 중복 서신이 삭제되었습니다.
REST 클라이언트가 요청을 보낸 후 응답을 받기 전에 연결이 끊어졌을 때 CICS 트랜잭션 롤백 동작을 어떻게 검증하는가?
대부분의 후보자는 단순히 연결 해제 후 데이터베이스 상태를 확인하라고 제안합니다. 그러나 올바른 접근 방식은 CEMT INQUIRE TASK를 사용하여 트랜잭션이 CICS 지역에서 제거되었는지 확인하고, z/OS System Logger의 LOGSTREAM을 조사하여 UR(Unit of Recovery)가 롤백되었음을 확인하는 것입니다. 또한 vsam RBA(Relative Byte Address) 일관성을 확인하기 위해 IDCAMS VERIFY를 사용하여 고아 레코드가 없음을 확인해야 합니다. 후보자들이 간과하는 미묘한 점은 CICS가 로컬에서 커밋되었을 수 있지만, REST 게이트웨이가 확인 응답을 보내지 않았을 수도 있다는 점이며, 이를 위해 z/OS Connect 오류 로그에서 HCON(HTTP Connection) 타임아웃과 CICS 중단 코드인 AEXZ(타임아웃)를 비교해야 한다는 점입니다.
TDQ 처리를 테스트할 때 동일한 CICS 지역 내에서 처리된 TDQ 트리거와 z/OS 데이터 집합에 기록되어 배치 작업에 의해 처리되는 외부 파티션 TDQ 트리거를 어떻게 구별합니까?
후보자들은 종종 DESTID 정의가 DCT(Destination Control Table)에서 TDQ 동작을 근본적으로 변화시킨다는 점을 간과합니다. 동일한 파티션 TDQ(메모리 기반)의 경우, CEBR을 사용하여 큐 깊이를 검사하고 CEMT SET TDQUEUE를 사용하여 처리하도록 수동으로 트리거하여 즉각적으로 CICS 트랜잭션이 시작되고 있는지 확인합니다. 외부 파티션 TDQ의 경우, ISPF 3.4 또는 SDSF를 사용하여 물리적 z/OS 데이터 집합을 모니터링하고 트리거 레코드가 나타나는 것을 확인한 후, 실행 중인 시작자 JOB 클래스를 검증해야 합니다. 중요한 차이점은 동일한 파티션의 TDQ는 SYNCPOINT를 통해 CICS 트랜잭션 무결성을 유지하는 반면, 외부 파티션의 TDQ는 CICS와 배치 작업 간의 기록 삭제 경합 조건을 방지하기 위해 별도의 VSAM RLS 잠금 전략이 필요합니다.
OCCURS DEPENDING ON(ODO) 클라우스가 있는 JSON과 COBOL 복사본 매핑을 어떻게 검증합니까?
많은 테스터가 고정 길이 구조만 점검하고 ODO 복잡성을 간과합니다. ODO 클라우스의 경우, z/OS Connect가 배열 데이터 이전에 의존성 카운터 필드를 올바르게 채우는지 확인해야 합니다. 테스트 사례에는 (1) 발생 0회(빈 배열), (2) 발생 1회, (3) 정의된 최대 발생 수, 및 (4) 최대 발생 수 초과하여 거부 처리 확인을 포함해야 합니다. CEBR 또는 CEDF를 사용하여 16진수에서 COMMAREA 레이아웃을 검사하여, 바이너리 COMP 필드가 JSON 숫자 변환 후 올바른 Big-Endian 바이트 순서를 유지하는지 확인해야 합니다. 복잡성은 JSON 배열이 명시적 길이 지표를 갖고 있지 않기 때문에 발생하며, 매퍼는 요소 수에서 ODO 값을 계산해야 하며, 이는 JSON 페이로드에 null 값이 존재할 경우 잘못 계산되어 COBOL 테이블 오버플로우 또는 잘림을 초래할 수 있습니다.