1 : TPEABORT - transaction cannot commit
> 트랜젝션이 commit 될 수 없는 상태입니다. 서비스가 timeout 이 난 경우가 해당되구요.. 만일 서비스가 정상 수행을 했는데 이런 메시지가 나왔다면 tpbegin 에서 주는 timeout 수치가 너무 짧은 것은 아닌지 검토해 보실 필요도 있으며, 일단은 Query tuning이 우선이지요.. ^^ (TPED_SVCTIMEOUT)
2 : TPEBADDESC - bad communication descriptor
> async mode 또는 conversation mode의 communication model에서 발생할 수 있는 에러입니다. async나 conversation은 communication handle 을 사용하지요? 동기적으로 호출이 이루어지는 것이 아니므로, client와 서비스를 이어줄 수 있는 handle이 필요한데, 그것이 expire 된 경우입니다. 대표적으로, communication이 이미 tpgetrply나 tpdiscon 등으로 종료가 된 후에 해당 cd (communication descriptor) 변수를 쓰려고 했을 때에 발생합니다.
3. TPEBLOCK - blocking condition found
> 이 에러는 보통 service call의 결과로 떨어집니다. 이를테면 call 하려는 서비스의 모든 queue가 몽땅 다 full이다.. 이런 경우, 우리는 "blocking condition이 존재(exist)한다"고 얘기 합니다. blocking condition이 존재할 때, 원래는 disk로 queue를 내려서 file transfer를 시도하게 되지만, 만일 call 옵션이 TPNOBLOCK 이었다면, 이러한 blocking condition을 만났을 경우, 막바로 error로 빠지게 됩니다. 이때 나오는 에러가 TPEBLOCK 입니다. reply queue도 마찬가지여셔, tpgetrply 함수를 call 할 때에도 이 에러 메시지를 만날 수 있습니다.
4. TPEINVAL - invalid arguments given
> atmi 함수에 input 값을 잘못 넣었을때 발생합니다. 예를들면, tpinit을 해야 하는데, WSNADDR 환경변수 값을, //192.168.1.10:3333 으로 해야 할 것을 "//192.168.1.10:3333" 처럼.. (quotation mark 문제입니다 -_-;) 좀 엄하게 잘못 했을 경우 이런 에러가 발생하기도 합니다. 혹은, tpcall에서 서비스명에 null 이 들어갔다거나.. ^^; 갖가지 atmi 함수에서 input 값이 이상한 경우에 발생합니다.
5. TPELIMIT - a system limit has been reached
> 가장 많이 발생하는 경우는 license binary user count를 넘어설 경우겠지요.. 그래서 tpinit 이 실패하는 경우인데, 그것 말고도 쉽게 reach될 system limit가 더 있습니다.
먼저, MAXACCESSORS 입니다. 해당 node에서 BB에 붙을 수 있는 프로세스 수를 몽땅 합한게 MAXACCESSORS 값인데, 이걸 초과 할 경우.. 즉, 서버 프로세스가 많이 떠 있고, tmadmin도 몇개씩 떠 있는 와중에 native client로 돌아가는 batch program까지 다수 붙어서 돌고 있는 상황이면, 새로운 client가 붙지를 못하는 현상이 벌어집니다.
또 있습니다. conversation mode는 MAXCONV 값 이내에서 이루어질 수 있지요? MAXCONV 값 제한에 걸려서 conversation mode의 connection을 맺을 수 없는 경우에도 이 에러가 떨어집니다.
좌우간 시스템 제한에 걸려서 뭘 못하는 경우에, 이 에러가 발생합니다. ^^
6. TPENOENT - no entry found
> 대표적으로 서비스가 없을때 발생합니다. call 하려는 서비스의 이름으로 열심히 찾아봤는데, 그 서비스 이름이 잘못된건지, 아니면 서비스가 내려가 있는 건지, 좌우간 찾을 수가 없을 때 이 에러가 떨어집니다.
그런데, 꼭 서비스가 아니라도 이 에러는 떨어집니다. 즉, '찾으려는 무언가가 없을 때' 무조건 떨어집니다. 심지어는 FML의 field table을 못찾을 때에도 발생합니다.
유형별로 보시면... tpalloc 에서는, alloc하려는 buffer type이 정의되어있지 않을 때..
tpinit 에서는 BB에 더이상 공간이 없어서 connection을 맺을 수 없을 때,
tpcall/tpacall/tpconnect 에서는 call 하려는 service가 없을 때,
(또는 tpconnect 로 call한 서비스가 conversation 서비스가 아닐 때..)
tpenqueue / tpdequeue 에서 queue space에 접근을 못할 때... 등등의 조건에서 일어납니다.
7. TPEOS - operating system error
> OS error라고 되어있습니다. 자기가 판단하기에 OS에서 벌어진 에러 같으면 무조건 이놈으로 떨어집니다.
8. TPEPERM - bad permissions
> permission 관련 에러는 모두 이걸로 나옵니다. 대부분은 TUXEDO 자체의 보안기능을 잘 이용하지 않으므로, 만날 일이 별로 없으리라고 봅니다. ^^;
9. TPEPROTO - protocol error
> protocol 문제로 발생합니다. 대표적인 경우가.. XA transaction을 이용하고 있는데, 감히 무엄하게도 transaction의 participant가 tpcommit을 call 한 경우입니다. 쉽게 말해서 tpbegin을 걸지도 않은 놈이 tpcommit을 날렸을 때라고 보면 되겠군요. ^^ 혹은, transaction이 진행중이어서 XA mode의 일부로 아직 진행중인 상황인데, tpterm을 날려버린 경우, tpterm 호출이 실패하면서 발생하는 에러가 이겁니다. 그 외에도 protocol 문제는 전부 이걸로 나옵니다. -_-
10. TPSVCERR - server error while handling request
> 글자 그대로 해석하시면 됩니다. 서버가 돌다가 에러가 났다... 이 얘기지요. 그런데 여기서 나오는 에러는 application level의 에러가 아닙니다. 즉, 서버가 죽는다거나 뭐 이런 류의 에러입니다. (십중 팔구, 서버가 죽었을 겁니다.. -_-) 따라서, 이 경우라면 반드시 디버깅을 하셔야 하겠습니다.
11. TPESVCFAIL - application level service failure
> 에러지만 에러같지 않은 에러입니다. 어떤 관점에서 볼 때엔 에러가 아니라고 간주해도 무방하지요. 이건 application이 정상적으로 수행되고 tpreturn이 TPFAIL로 넘어온 경우가 여기에 해당됩니다. 뭐가 죽거나 한건 아니고, 단지 return 값이 TPFAIL 이었다는 소리입니다. 에러라고 보지 않으셔도 무방하겠죠?
12. TPESYSTEM - internal system error
> TPEOS가 OS 에러를 통칭한다면 TPESYSTEM은 'tuxedo error'를 통칭합니다. -_-; TUXEDO 시스템 자체 에러 메시지인데, 뭐 매우 단순한 경우에도 발생합니다. 이를테면 tpinit을 않고, 막바로 tpcall을 시도했을 때에도 발생합니다. 일단은 시스템 에러로 간주하고 admin 부터 불러와야 할 경우이기는 합니다. 흔히 이 에러가 발생할 경우에는 log file 등에 부가적인 정보가 남습니다.
13. TPETIME - timeout occurred
> 간단하죠? 타임아웃이래요.. ^^;;
14. TPETRAN - error starting transaction
> transaction이 issue되지 않는 경우입니다. XA transaction을 하나 issue 하려면 Global Transaction Table (GTT) 에 공간이 최소한 하나 있어야 하겠지요? 만일, 그 시스템의 MAXGTT로 정해놓은 수치만큼.. 이를테면 MAXGTT=100 인데, 현재 100개의 XA transaction이 진행중인 경우, 새로운 transaction을 start 하려고 하면 이 에러가 나옵니다. 또는 이와 비슷한 여러가지 경우로 transaction starting이 죽어도 될 수 없는 경우가 있는지를 찾아보세요. 이를테면 TMS가 없다거나 (이건 TPENOENT와 함께 발생하겠군요) DB가 죽었다거나 (ulog를 보면, XAER_RMERR 이 함께 발생할겁니다.).... ^^
15. TPGOTSIG - signal received and TPSIGRSTRT not specified
> 보기 힘든 error 입니다. 사실상 거의 쓰지 않는 tpcall / tpenqueue flag 값 중에서 TPSIGRSTRT 라는 옵션이 있습니다. 이것은 뭐냐 하면, 실행중인 system call이 signal을 맞아서 interrupt가 걸렸을 때, 그 system call을 'restart' 시킨다.. 즉, 다시 실행한다.. 뭐 이런 소리입니다. 즉, TPSIGRSTRT flag가 on 상태이면, 이 에러는 안납니다.
16. TPERMERR - resource manager error
> DB에 error가 발생했다고 여겨지는 경우입니다. 대표적으로, tpopen 이나 tpclose를 써서 RM(=DB 입니다.)을 open 하려고 시도했을 경우에 DB에 에러가 나서 접근이 안되거나 정상처리가 안될 경우에 이 에러가 발생하죠.. 그러나 tpopen/tpclose는 쓸 일이 거의 없죠? 거의 non-XA에서는 EXEC SQL CONNECT 를 직접 써서 연결하니까요...
XA transaction 모드의 서버를 구성할 때, tpsvrinit / done 함수에 사용하는 tx_open / tx_close의 경우에는 TPERMERR 이 발생하는게 아니라, (당연하죠.. TP계열이 아니라 TX 계열 함수이므로..) TX_ERROR / TX_FAIL 등의 에러가 발생합니다.
17. TPEITYPE - type and/or subtype do not match service's
> 이것이 무엇이냐.... tpcall 로 call 한 communication buffer 가 service에서 처리를 할 수 없는 type인 경우입니다. 이를테면, client에서 FML로 보냈는데, server 쪽에는 아예 field table도 없고 FML을 쓸 준비가 전혀 안되어있다거나 하는 경우가 여기에 해당됩니다.
18. TPEOTYPE - type and/or subtype do not match buffer's or unknown
> 이것도 비슷합니다. type이 안맞는건데요.. 예를 들면, view type buffer를 쓸 때, 전송에 사용할 view type을 정해놓지 않습니까? 그런데.. 같은 view type은 맞는데 (그래서 TPEITYPE은 피했는데..) 넘어온 data의 view가, 원래 예정되어있던 그 view가 아닌 엉뚱한 view일 경우에 발생합니다.
19. TPERELEASE - invalid release
> 말그대로입니다.
20. TPEHAZARD - hazard exists that transaction heuristically completed
21. TPEHEURISTIC - transaction heuristically completed
> 두 놈 다 무서운 (또, 맘에 안드는) 에러입니다. -_-; 이것들을 설명하기 전에 transaction control 설정을 먼저 거론해야 하겠군요..
XA transaction을 control 하는 변수 중, TP_COMMIT_CONTROL 이라는 변수가 있습니다. 이 속성은 ubbconfig 파일에서 CMTRET 라는 parameter를 뭘로 주느냐를 갖고 default setting을 하구요.. 나중에 transaction coordinator (흔히 client) 측에서 tpscmt 라는 함수를 호출하여 재설정 할 수 있습니다.
TP_COMMIT_CONTROL의 값.. 즉, ubb에서의 CMTRET 값은 두 가지가 있습니다.
하나는 LOGGED 이고, 또 하나는 COMPLETE 입니다. default는 COMPLETE 입니다.
LOGGED : tpcommit 을 호출하면, 각 transaction participant가 "precommit"이 확실히 되면 그때 return 됩니다.
COMPLETE : 모든 participant가 "commit"이 다 되어야 tpcommit이 return 됩니다.
LOGGED가 퍼포먼스는 더 좋지만, transaction 처리의 신뢰도는 COMPLETE가 당연히 뛰어나겠지요?
이 속성이 LOGGED로 되어있을 때는, one-phase commit이 되면 곧바로 AP로 제어권이 넘어갑니다. 즉, two-phase commit 이 모두 일어날때까지 기다리는 것이 아니란 소린데, 그렇다면 첫번째 phase commit이 되고 나서도, 두번째 phase를 만날때까지 TM은 RM과 작업을 할게 더 남아있습니다만, 어쨌거나 AP에서는 one-phase 정보만을 얻을 수 있을 뿐이지요. 그래서 LOGGED일때 이 에러메시지는 one-phase commit에 관한 얘기입니다. 첫번째 phase에서 에러가 났다는 얘기구요... one-phase 이므로, 당연히 관여된 RM이 하나뿐일때만 알 수 있습니다. (복수 node에 걸친 transaction인 경우엔 LOGGED 옵션에서는 에러 여부가 나오지 않습니다.)
COMPLETE 일 경우에는 two-phase commit이 모두 일어난 후에 AP로 제어가 넘어오므로, one-phase 뿐만 아니라 two-phase commit 에서도 heuristic decision이 발생했거나 hazard condition이 발생한 경우에 이 에러 메시지를 볼 수 있습니다. 물론 복수 RM이 관여된 경우에도 마찬가지겠죠.. ^^
TPEHAZARD는, hazard condition이 발생하여.. 즉, 뭔가 알 수 없는 종류의 에러 또는 실패가 발생해서, transaction을 heuristic 하게 처리할 수 밖에 없게 되었다는 의미입니다. 말이 좀 어렵죠? -_-; heuristic 이라는 말이 '발견적인, 우연히 발견한, 스스로 발견한' 뭐 이따위의 뜻이 있습니다. -_- 매우 황당한 경우가 아닐 수가 없습니다.
"일단은 hazard 가 발생을 해서 heuritstic 하게 transaction을 처리해야 할텐데, 잘 되기를 빌어달라.." 뭐 이런 메시지라고 보시면 되겠습니다.
TPEHEURISTIC은 heuristic decision을 내려야 할 경우에 빠져들었는데, 하필 또 그것마저도 이상하게 꼬이는 바람에, transaction이 일부는 commit 되고 또 일부는 rollback이 되는 엽기적인 상황이 발생했다는 에러 코드입니다. -_-;
"heuristic 하게 잘 해 보려고 최선은 다했는데, 어라? 이게 뭐꼬?" 하는 메시지입니다;;
엽기적인 에러죠? -_-; 이 에러 겪어본 사람들은 환장합니다.. -_-; 저도 겪어봤거든요..
22. TPEEVENT - event occurred
> EVENT가 발생했답니다. 어떤 event 인지는 revent 변수에 남구요.. conversation mode인 경우 tprecv / tpsend 를 사용하는데 event가 발생해버리면 conversation 처리가 불가능하게 되고 이 에러가 발생합니다.
23. TPEMATCH - service name cannot be advertised due to matching conflict
> tpadvertise를 써서, 서비스를 advertise 하려고 할 때, 이미 advertise 된 서비스를 또 하려고 하면 이 에러가 발생합니다.
24. TPEDIAGNOSTIC - function failed - check diagnostic value
> tpenqueue/tpdequeue 등에서 function call이 실패한 경우, 이 에러가 뜨면 diagnostic 이라는 long 형태의 변수 값을 참고하면 되겠습니다.
25. TPEMIB - Management Information Base access error
> TUXEDO에서 admin 기능을 구현하기 위해서는, MIB 라는 것에 붙어서 작업하는 tool등을 만들게 되는데, MIB access에 문제가 생긴 경우입니다. tpadmcall 호출시, outbuf 값에 FML32 버퍼 타입으로 에러 정보가 기록됩니다. MIB에 대해 알려면 매뉴얼에서 TM_MIB, MIB 절을 잘 읽어보시면 되구요..
출처 :
* 어차피 TUXEDO나 TMAX나 OSI-TP 표준에 맞추어 개발된 M/W 이므로, TMAX에서도 이 내용은 거의 그대로 쓸 수 있을 것입니다. ^^ 그럼 시작하옵니다..
1 : TPEABORT - transaction cannot commit
> 트랜젝션이 commit 될 수 없는 상태입니다. 서비스가 timeout 이 난 경우가 해당되구요.. 만일 서비스가 정상 수행을 했는데 이런 메시지가 나왔다면 tpbegin 에서 주는 timeout 수치가 너무 짧은 것은 아닌지 검토해 보실 필요도 있으며, 일단은 Query tuning이 우선이지요.. ^^ (TPED_SVCTIMEOUT)
2 : TPEBADDESC - bad communication descriptor
> async mode 또는 conversation mode의 communication model에서 발생할 수 있는 에러입니다. async나 conversation은 communication handle 을 사용하지요? 동기적으로 호출이 이루어지는 것이 아니므로, client와 서비스를 이어줄 수 있는 handle이 필요한데, 그것이 expire 된 경우입니다. 대표적으로, communication이 이미 tpgetrply나 tpdiscon 등으로 종료가 된 후에 해당 cd (communication descriptor) 변수를 쓰려고 했을 때에 발생합니다.
3. TPEBLOCK - blocking condition found
> 이 에러는 보통 service call의 결과로 떨어집니다. 이를테면 call 하려는 서비스의 모든 queue가 몽땅 다 full이다.. 이런 경우, 우리는 "blocking condition이 존재(exist)한다"고 얘기 합니다. blocking condition이 존재할 때, 원래는 disk로 queue를 내려서 file transfer를 시도하게 되지만, 만일 call 옵션이 TPNOBLOCK 이었다면, 이러한 blocking condition을 만났을 경우, 막바로 error로 빠지게 됩니다. 이때 나오는 에러가 TPEBLOCK 입니다. reply queue도 마찬가지여셔, tpgetrply 함수를 call 할 때에도 이 에러 메시지를 만날 수 있습니다.
4. TPEINVAL - invalid arguments given
> atmi 함수에 input 값을 잘못 넣었을때 발생합니다. 예를들면, tpinit을 해야 하는데, WSNADDR 환경변수 값을, //192.168.1.10:3333 으로 해야 할 것을 "//192.168.1.10:3333" 처럼.. (quotation mark 문제입니다 -_-;) 좀 엄하게 잘못 했을 경우 이런 에러가 발생하기도 합니다. 혹은, tpcall에서 서비스명에 null 이 들어갔다거나.. ^^; 갖가지 atmi 함수에서 input 값이 이상한 경우에 발생합니다.
5. TPELIMIT - a system limit has been reached
> 가장 많이 발생하는 경우는 license binary user count를 넘어설 경우겠지요.. 그래서 tpinit 이 실패하는 경우인데, 그것 말고도 쉽게 reach될 system limit가 더 있습니다.
먼저, MAXACCESSORS 입니다. 해당 node에서 BB에 붙을 수 있는 프로세스 수를 몽땅 합한게 MAXACCESSORS 값인데, 이걸 초과 할 경우.. 즉, 서버 프로세스가 많이 떠 있고, tmadmin도 몇개씩 떠 있는 와중에 native client로 돌아가는 batch program까지 다수 붙어서 돌고 있는 상황이면, 새로운 client가 붙지를 못하는 현상이 벌어집니다.
또 있습니다. conversation mode는 MAXCONV 값 이내에서 이루어질 수 있지요? MAXCONV 값 제한에 걸려서 conversation mode의 connection을 맺을 수 없는 경우에도 이 에러가 떨어집니다.
좌우간 시스템 제한에 걸려서 뭘 못하는 경우에, 이 에러가 발생합니다. ^^
6. TPENOENT - no entry found
> 대표적으로 서비스가 없을때 발생합니다. call 하려는 서비스의 이름으로 열심히 찾아봤는데, 그 서비스 이름이 잘못된건지, 아니면 서비스가 내려가 있는 건지, 좌우간 찾을 수가 없을 때 이 에러가 떨어집니다.
그런데, 꼭 서비스가 아니라도 이 에러는 떨어집니다. 즉, '찾으려는 무언가가 없을 때' 무조건 떨어집니다. 심지어는 FML의 field table을 못찾을 때에도 발생합니다.
유형별로 보시면... tpalloc 에서는, alloc하려는 buffer type이 정의되어있지 않을 때..
tpinit 에서는 BB에 더이상 공간이 없어서 connection을 맺을 수 없을 때,
tpcall/tpacall/tpconnect 에서는 call 하려는 service가 없을 때,
(또는 tpconnect 로 call한 서비스가 conversation 서비스가 아닐 때..)
tpenqueue / tpdequeue 에서 queue space에 접근을 못할 때... 등등의 조건에서 일어납니다.
7. TPEOS - operating system error
> OS error라고 되어있습니다. 자기가 판단하기에 OS에서 벌어진 에러 같으면 무조건 이놈으로 떨어집니다.
8. TPEPERM - bad permissions
> permission 관련 에러는 모두 이걸로 나옵니다. 대부분은 TUXEDO 자체의 보안기능을 잘 이용하지 않으므로, 만날 일이 별로 없으리라고 봅니다. ^^;
9. TPEPROTO - protocol error
> protocol 문제로 발생합니다. 대표적인 경우가.. XA transaction을 이용하고 있는데, 감히 무엄하게도 transaction의 participant가 tpcommit을 call 한 경우입니다. 쉽게 말해서 tpbegin을 걸지도 않은 놈이 tpcommit을 날렸을 때라고 보면 되겠군요. ^^ 혹은, transaction이 진행중이어서 XA mode의 일부로 아직 진행중인 상황인데, tpterm을 날려버린 경우, tpterm 호출이 실패하면서 발생하는 에러가 이겁니다. 그 외에도 protocol 문제는 전부 이걸로 나옵니다. -_-
10. TPSVCERR - server error while handling request
> 글자 그대로 해석하시면 됩니다. 서버가 돌다가 에러가 났다... 이 얘기지요. 그런데 여기서 나오는 에러는 application level의 에러가 아닙니다. 즉, 서버가 죽는다거나 뭐 이런 류의 에러입니다. (십중 팔구, 서버가 죽었을 겁니다.. -_-) 따라서, 이 경우라면 반드시 디버깅을 하셔야 하겠습니다.
11. TPESVCFAIL - application level service failure
> 에러지만 에러같지 않은 에러입니다. 어떤 관점에서 볼 때엔 에러가 아니라고 간주해도 무방하지요. 이건 application이 정상적으로 수행되고 tpreturn이 TPFAIL로 넘어온 경우가 여기에 해당됩니다. 뭐가 죽거나 한건 아니고, 단지 return 값이 TPFAIL 이었다는 소리입니다. 에러라고 보지 않으셔도 무방하겠죠?
12. TPESYSTEM - internal system error
> TPEOS가 OS 에러를 통칭한다면 TPESYSTEM은 'tuxedo error'를 통칭합니다. -_-; TUXEDO 시스템 자체 에러 메시지인데, 뭐 매우 단순한 경우에도 발생합니다. 이를테면 tpinit을 않고, 막바로 tpcall을 시도했을 때에도 발생합니다. 일단은 시스템 에러로 간주하고 admin 부터 불러와야 할 경우이기는 합니다. 흔히 이 에러가 발생할 경우에는 log file 등에 부가적인 정보가 남습니다.
13. TPETIME - timeout occurred
> 간단하죠? 타임아웃이래요.. ^^;;
14. TPETRAN - error starting transaction
> transaction이 issue되지 않는 경우입니다. XA transaction을 하나 issue 하려면 Global Transaction Table (GTT) 에 공간이 최소한 하나 있어야 하겠지요? 만일, 그 시스템의 MAXGTT로 정해놓은 수치만큼.. 이를테면 MAXGTT=100 인데, 현재 100개의 XA transaction이 진행중인 경우, 새로운 transaction을 start 하려고 하면 이 에러가 나옵니다. 또는 이와 비슷한 여러가지 경우로 transaction starting이 죽어도 될 수 없는 경우가 있는지를 찾아보세요. 이를테면 TMS가 없다거나 (이건 TPENOENT와 함께 발생하겠군요) DB가 죽었다거나 (ulog를 보면, XAER_RMERR 이 함께 발생할겁니다.).... ^^
15. TPGOTSIG - signal received and TPSIGRSTRT not specified
> 보기 힘든 error 입니다. 사실상 거의 쓰지 않는 tpcall / tpenqueue flag 값 중에서 TPSIGRSTRT 라는 옵션이 있습니다. 이것은 뭐냐 하면, 실행중인 system call이 signal을 맞아서 interrupt가 걸렸을 때, 그 system call을 'restart' 시킨다.. 즉, 다시 실행한다.. 뭐 이런 소리입니다. 즉, TPSIGRSTRT flag가 on 상태이면, 이 에러는 안납니다.
16. TPERMERR - resource manager error
> DB에 error가 발생했다고 여겨지는 경우입니다. 대표적으로, tpopen 이나 tpclose를 써서 RM(=DB 입니다.)을 open 하려고 시도했을 경우에 DB에 에러가 나서 접근이 안되거나 정상처리가 안될 경우에 이 에러가 발생하죠.. 그러나 tpopen/tpclose는 쓸 일이 거의 없죠? 거의 non-XA에서는 EXEC SQL CONNECT 를 직접 써서 연결하니까요...
XA transaction 모드의 서버를 구성할 때, tpsvrinit / done 함수에 사용하는 tx_open / tx_close의 경우에는 TPERMERR 이 발생하는게 아니라, (당연하죠.. TP계열이 아니라 TX 계열 함수이므로..) TX_ERROR / TX_FAIL 등의 에러가 발생합니다.
17. TPEITYPE - type and/or subtype do not match service's
> 이것이 무엇이냐.... tpcall 로 call 한 communication buffer 가 service에서 처리를 할 수 없는 type인 경우입니다. 이를테면, client에서 FML로 보냈는데, server 쪽에는 아예 field table도 없고 FML을 쓸 준비가 전혀 안되어있다거나 하는 경우가 여기에 해당됩니다.
18. TPEOTYPE - type and/or subtype do not match buffer's or unknown
> 이것도 비슷합니다. type이 안맞는건데요.. 예를 들면, view type buffer를 쓸 때, 전송에 사용할 view type을 정해놓지 않습니까? 그런데.. 같은 view type은 맞는데 (그래서 TPEITYPE은 피했는데..) 넘어온 data의 view가, 원래 예정되어있던 그 view가 아닌 엉뚱한 view일 경우에 발생합니다.
19. TPERELEASE - invalid release
> 말그대로입니다.
20. TPEHAZARD - hazard exists that transaction heuristically completed
21. TPEHEURISTIC - transaction heuristically completed
> 두 놈 다 무서운 (또, 맘에 안드는) 에러입니다. -_-; 이것들을 설명하기 전에 transaction control 설정을 먼저 거론해야 하겠군요..
XA transaction을 control 하는 변수 중, TP_COMMIT_CONTROL 이라는 변수가 있습니다. 이 속성은 ubbconfig 파일에서 CMTRET 라는 parameter를 뭘로 주느냐를 갖고 default setting을 하구요.. 나중에 transaction coordinator (흔히 client) 측에서 tpscmt 라는 함수를 호출하여 재설정 할 수 있습니다.
TP_COMMIT_CONTROL의 값.. 즉, ubb에서의 CMTRET 값은 두 가지가 있습니다.
하나는 LOGGED 이고, 또 하나는 COMPLETE 입니다. default는 COMPLETE 입니다.
LOGGED : tpcommit 을 호출하면, 각 transaction participant가 "precommit"이 확실히 되면 그때 return 됩니다.
COMPLETE : 모든 participant가 "commit"이 다 되어야 tpcommit이 return 됩니다.
LOGGED가 퍼포먼스는 더 좋지만, transaction 처리의 신뢰도는 COMPLETE가 당연히 뛰어나겠지요?
이 속성이 LOGGED로 되어있을 때는, one-phase commit이 되면 곧바로 AP로 제어권이 넘어갑니다. 즉, two-phase commit 이 모두 일어날때까지 기다리는 것이 아니란 소린데, 그렇다면 첫번째 phase commit이 되고 나서도, 두번째 phase를 만날때까지 TM은 RM과 작업을 할게 더 남아있습니다만, 어쨌거나 AP에서는 one-phase 정보만을 얻을 수 있을 뿐이지요. 그래서 LOGGED일때 이 에러메시지는 one-phase commit에 관한 얘기입니다. 첫번째 phase에서 에러가 났다는 얘기구요... one-phase 이므로, 당연히 관여된 RM이 하나뿐일때만 알 수 있습니다. (복수 node에 걸친 transaction인 경우엔 LOGGED 옵션에서는 에러 여부가 나오지 않습니다.)
COMPLETE 일 경우에는 two-phase commit이 모두 일어난 후에 AP로 제어가 넘어오므로, one-phase 뿐만 아니라 two-phase commit 에서도 heuristic decision이 발생했거나 hazard condition이 발생한 경우에 이 에러 메시지를 볼 수 있습니다. 물론 복수 RM이 관여된 경우에도 마찬가지겠죠.. ^^
TPEHAZARD는, hazard condition이 발생하여.. 즉, 뭔가 알 수 없는 종류의 에러 또는 실패가 발생해서, transaction을 heuristic 하게 처리할 수 밖에 없게 되었다는 의미입니다. 말이 좀 어렵죠? -_-; heuristic 이라는 말이 '발견적인, 우연히 발견한, 스스로 발견한' 뭐 이따위의 뜻이 있습니다. -_- 매우 황당한 경우가 아닐 수가 없습니다.
"일단은 hazard 가 발생을 해서 heuritstic 하게 transaction을 처리해야 할텐데, 잘 되기를 빌어달라.." 뭐 이런 메시지라고 보시면 되겠습니다.
TPEHEURISTIC은 heuristic decision을 내려야 할 경우에 빠져들었는데, 하필 또 그것마저도 이상하게 꼬이는 바람에, transaction이 일부는 commit 되고 또 일부는 rollback이 되는 엽기적인 상황이 발생했다는 에러 코드입니다. -_-;
"heuristic 하게 잘 해 보려고 최선은 다했는데, 어라? 이게 뭐꼬?" 하는 메시지입니다;;
엽기적인 에러죠? -_-; 이 에러 겪어본 사람들은 환장합니다.. -_-; 저도 겪어봤거든요..
22. TPEEVENT - event occurred
> EVENT가 발생했답니다. 어떤 event 인지는 revent 변수에 남구요.. conversation mode인 경우 tprecv / tpsend 를 사용하는데 event가 발생해버리면 conversation 처리가 불가능하게 되고 이 에러가 발생합니다.
23. TPEMATCH - service name cannot be advertised due to matching conflict
> tpadvertise를 써서, 서비스를 advertise 하려고 할 때, 이미 advertise 된 서비스를 또 하려고 하면 이 에러가 발생합니다.
24. TPEDIAGNOSTIC - function failed - check diagnostic value
> tpenqueue/tpdequeue 등에서 function call이 실패한 경우, 이 에러가 뜨면 diagnostic 이라는 long 형태의 변수 값을 참고하면 되겠습니다.
25. TPEMIB - Management Information Base access error
> TUXEDO에서 admin 기능을 구현하기 위해서는, MIB 라는 것에 붙어서 작업하는 tool등을 만들게 되는데, MIB access에 문제가 생긴 경우입니다. tpadmcall 호출시, outbuf 값에 FML32 버퍼 타입으로 에러 정보가 기록됩니다. MIB에 대해 알려면 매뉴얼에서 TM_MIB, MIB 절을 잘 읽어보시면 되구요..
출처
https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=bluesky3s&logNo=50001634153
