다음을 통해 공유


트랜잭션 복구에 영향을 미치는 메인프레임 문제

경우에 따라 TI는 원격 환경으로 새 트랜잭션을 처리할 수 없습니다. 이는 올바른 동작일 수 있습니다. 예를 들어 TI 예외 1227이 클라이언트 애플리케이션에 반환되거나 이벤트에 로그인되고 HRESULT가 8004D110인 경우 통신 실패 후 이전 트랜잭션이 확인되지 않았기 때문에 이 원격 환경의 새 트랜잭션을 수락할 수 없음을 나타냅니다.

2단계 커밋 프로세스가 완료되지 않으면 통신이 다시 설정될 때까지 CICS는 트랜잭션을 In-Doubt 상태로 유지해야 합니다. 그런 다음 TI는 복구 프로토콜을 수행하여 트랜잭션이 모든 노드에서 동일한 상태인지 확인합니다. 이 문제가 발생하려면 CICS를 올바르게 구성해야 합니다.

CICS가 예기치 않게 종료된 다음 콜드 상태에서 다시 시작되는 경우 완료되지 않은 트랜잭션의 로그에 메모리가 없습니다. 따라서 이러한 트랜잭션은 일관된 상태로 자동으로 복구할 수 없습니다. CICS를 중지하기 전에 모든 트랜잭션이 완료되었는지 확인하거나 보류 중인 트랜잭션을 복구할 수 있도록 동일한 로그를 사용하여 웜 다시 시작을 위해 CICS를 구성합니다.

CICS 트랜잭션 서버를 사용하면 관리자가 트랜잭션의 In-Doubt 특성에서 대기 시간을 지정할 수 있습니다. 대부분의 경우 통신을 다시 설정할 수 있도록 적절한 값을 지정해야 합니다. In-Doubt 상태에 남아 있는 모든 트랜잭션이 복구되기 전에 이 시간 제한이 경과하면 CICS는 로컬로 resolve 추론적인 결정을 내릴 것입니다. 이 결정이 Microsoft DTC(분산 트랜잭션 코디네이터)의 트랜잭션에 대한 결정과 충돌하는 경우 이전 트랜잭션의 결과가 수동으로 재정의될 때까지 새 트랜잭션을 시작할 수 없습니다.

CICS 트랜잭션 서버 이전의 CICS 버전에서는 복구 특성에 대기 시간이 없습니다. wait 값을 In-Doubt 특성에 할당해도 복구를 시도할 때 CICS가 TI에서 요청한 상태로 트랜잭션을 배치하지는 않습니다. 이러한 버전의 CICS를 사용하는 경우 In-Doubt 특성을 백아웃 또는 커밋으로 설정합니다. 결과 추론 결정이 올바르지 않고 새 트랜잭션이 시작되지 않도록 하는 경우 DTC를 사용하여 트랜잭션의 결과를 재정의합니다.

트랜잭션이 성공적으로 복구되지 않았음을 나타내는 SNA LU 6.2 Resync TP 서비스의 메시지에 대한 Windows 이벤트 로그를 검사합니다. 제안된 작업을 따릅니다. Microsoft Transaction Server의 트랜잭션 목록 창을 사용하여 보류 중인 트랜잭션을 표시합니다. 트랜잭션을 마우스 오른쪽 단추로 클릭하여 해당 속성을 표시합니다. CICS가 추론적으로 선택하도록 구성된 상태 또는 CICS가 예기치 않게 종료되고 콜드가 시작된 경우 백아웃 또는 중단된 상태에 동의하도록 해결합니다. 로그의 이벤트는 CICS에서 선택한 트랜잭션 및 상태를 식별합니다.

참고

TCP/IP는 ACID(원자성, 일관성, 격리 및 지속성) 트랜잭션을 지원하지 않으므로 TCP/IP에는 적용되지 않습니다.

참고 항목

수동으로 트랜잭션을 확인하는 방법