| 설명 | cd가 유효하지 않은 구별자이다. 함수를 사용할 때 반환된 구별자가 유효하지 않은 경우이다. |
| 대응 방법 | tpcall()을 통해 할당된 cd를 확인하거나 tpstart()를 다시 호출한다. |
| 설명 | 요청한 서비스가 블로킹된 상태이다. TPNOBLOCK 설정된 상태에서 블로킹이 발생하였다. 서비스를 다시 요청하거나 블로킹이 해제된 후 다시 시도해야 한다. tpgetrply나 tpgetunsol를 NonBlock Mode로 호출했을 때 발생되었다면 호출한 시점에 소켓에 데이커가 없는 상태이므로 해당 에러를 무시하고 일정시간 sleep후 재시도 하는 Logic 추가가 필요하다. |
| 대응 방법 | 서비스를 다시 요청하거나 블로킹이 해제된 후 다시 시도한다. |
| 설명 | 시스템 자원 또는 Tmax에서 제공하는 자원의 부족한 경우이다. |
| 대응 방법 | Tmax에서는 자원이 충분하지 않은 경우, 운영체제에서 제공하는 자원을 할당받아 이를 이용한다. |
| 설명 | 서비스 테이블에 서비스가 존재하지 않는 경우이거나 Tmax 엔진에서 서비스를 인식하지 못하는 경우이다. |
| 대응 방법 | 환경파일이 수정되었다면 gst로 서비스 테이블을 새로 만들어 서버 애플리케이션 컴파일할 때 함께 컴파일한다. |
| 설명 | 운영체제 오류이다. |
| 대응 방법 | 운영체제를 비롯하여 네트워크 및 기존 운영되던 환경이 변경되었는지 제반환경을 점검한다. |
| 설명 | 부적절한 상황에서 함수가 호출된 경우이다. |
| 대응 방법 | 단계별 함수 호출이 잘못 사용된 경우로 버퍼를 설정하고 서비스를 요청하거나 대화형 통신하는 경우 send와 recv 등의 단계를 준수한다. |
| 설명 | 서비스 수행 중 서버 프로세스에서 에러가 발생한 경우이다. |
| 대응 방법 | 서버 프로세스를 확인해야 한다. |
| 설명 | 서비스 수행 중 애플리케이션 레벨에서 에러가 발생한 경우이다. 서비스 요청에 대한 응답을 송신하는 서비스 루틴이 애플리케이션에서 에러가 발생한 경우이다. |
| 대응 방법 | 애플리케이션을 확인해야 한다. |
| 설명 | Tmax 시스템에 이상이 발견된 경우이다. |
| 대응 방법 | 일반적인 모든 에러를 포함하므로 여러가지를 점검한다. 네트워크에 대한 장애 및 서버 프로세스등 관련 제반 환경을 점검한다. |
| 설명 | 블로킹되어 있거나 어떤 원인에 의해 지정된 시간을 초과한 경우에 발생한다. |
| 대응 방법 | 애플리케이션 레벨에서 시간 초과의 원인을 파악하고 정상적인 경우라면 타임아웃 시간을 조정한다. 애플리케이션에서 타임아웃 시간을 지정할 수 있다. 기본적으로는 환경파일의 BLOCKTIME 값을 적용한다. |
| 설명 | 트랜잭션을 지원하지 않는 서비스인 경우 발생한다. |
| 대응 방법 | tpcall를 호출할 때 flags를 TPNOTRAN으로 설정한다. |
| 설명 | TPSIGRSTRT가 설정되지 않은 상태에서 시그널이 수신된 경우에 발생한다. COUSIN 항목을 이용하여 DDR을 하는 경우 CLH가 어느 노드에 있는 서비스를 요청해야 될지 모르는 경우에도 발생한다. |
| 설명 | 입력된 버퍼의 유형을 알 수 없는 경우에 발생한다. COUSIN 항목을 이용하여 DDR을 하는 경우 CLH가 어느 노드에 있는 서비스를 요청해야 될지 모르는 경우에도 발생한다. |
| 대응 방법 | 데이터 값을 검사한다. 필드키 버퍼를 사용하는 경우에는 해당 필드키의 정의 여부를 확인하고, 구조체 버퍼를 사용하는 경우에는 구조체의 선언 여부를 확인한다. |
| 설명 | 입력된 버퍼의 유형을 호출자가 알지 못하는 것으로 데이터의 유형 및 하위 유형과 입력된 버퍼의 유형이 일치하지 않은 경우에 발생한다. |
| 대응 방법 | 데이터 값을 검사한다. |
| 설명 | 대화형 모드에서 발생하는 에러이다. 이벤트가 발생하였고 데이터는 전달되지 않은 경우로 이벤트는 revent 값에 반환된다. |
| 대응 방법 | 이벤트 (revent) 값을 확인한다. |
| 설명 | 해당 조건을 만족하는 제거할 데이터를 찾지 못한 경우에 발생한다. |
| 대응 방법 | 조건이 올바른지 검토한다. |
| 설명 | 서비스가 준비되지 않은 것이거나 구동은 되어있으나 활성화가 안 된 경우에 발생한다. 예를 들어 tpcall()할 때 이미 서비스가 NRDY 상태인 경우에 발생한다. |
| 대응 방법 | tmadmin에서 st –s로 서비스에 대한 상태를 확인하고 NRDY로 나타난다면 제대로 구동되어 있지 않은 것이다. 서버 프로세스를 재확인하고 다시 구동해야 하고 tpstart()를 다시 호출한다. |
| 설명 | 보안설정을 사용하는 경우 허용되지 않은 사용자의 접근한 경우 발생한다. |
| 대응 방법 | 사용자에 대한 권한을 확인한다. |
| 설명 | 요청된 서비스가 지정한 Max 큐에 도달한 경우에 발생한다. |
| 대응 방법 | Tmax 환경파일에서 또는 동적으로 tmadmin 툴에서 Max 큐값을 조절할 수 있다. |
| 설명 | 관리자가 강제로 큐를 Purge한 경우에 발생한다. 요청된 서비스가 큐에 대기 중 관리자에 의해 Purge된 경우에 발생한다. |
| 설명 | Tmax가 구동되지 않았거나 접속을 할 수 없는 경우에 발생한다. |
| 대응 방법 | Tmax의 정상 구동 여부를 확인한 후 tpstart()를 다시 호출한다. |
| 설명 | tpcall()한 서비스 때문에 서버가 다운된 상황이다. |
| 대응 방법 | 서버 프로세스가 정상 작동 중인지를 확인한다. 또는 애플리케이션 로직의 문제로서 프로그램이 수행 중에 비정상적으로 종료될 수도 있으므로 애플리케이션을 확인한다. |
| 설명 | RQ 절에 등록하여 사용한 PRESVC에 대한 에러로서 현재는 사용하지 않으므로 발생하지 않는 에러이다. |
| 설명 | Rolling Down이 발생한 경우, 기존 서버큐에 쌓여 있는 요청들에 대하여 tpgetrply를 호출할 때 TPERDOWN 에러가 설정되며 tpacall를 사용할 때 송신되었던 데이터가 tpgetrply의 수신 버퍼에 다시 담겨진다. Rolling Down이 발생한 이후에 호출되는 tpacall에 대해서도 TPERDOWN 에러가 설정된다. |
| 대응 방법 | 릴리즈 노트를 참조한다. |
| 설명 | 더이상 서버큐에 적체된 요청이 없는 상황에서 tpgetrply가 호출된 경우 TPERDCLOSE 에러가 셋팅 된다 |
| 대응 방법 | 릴리즈 노트를 참조한다. |
| 설명 | 동시에 접속할 수 있는 유저가 한정되어 있는데 사용자 수가 최대 사용자 수에 도달한 경우 발생하는 에러이다. |
| 대응 방법 | tmadmin에서 ci(client Information)로 확인한다. |