그냥 그렇고 그런... 염세주의자

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 절을 잘 읽어보시면 되구요.. 기회가 되면 여기에도 한 번 올려보죠

                                   

출처: http://adrian.pe.kr/ 의 adrian님의 글

결혼전 와이프와 주고 받던 편지에서 발췌. 글쓴이는 모름.


이런 아내, 이런 남편이 되겠습니다...


1. 이런 아내가 되겠습니다.


눈이오는 한겨울에 야근을 하고 돌아오는

당신의 퇴근 무렵에 따뜻한 붕어빵 한 봉지 사들고

당신이 내리는 지하철역에서 서 있겠습니다. 당신이 돌아와

육체와 영혼이 쉴수 있도록 향내나는 그런집으로 만들겠습니다.

때로는 구수한 된장찌개 냄새로, 때로는 만개한 소국들의 향기로,

때로는 진한 향수의 향기로..



당신이 늦게까지 불 켜놓고 당신의 방에서 책을 볼 때,

나는 살며시 사랑을 담아 레몬 넣은 홍차를 준비하겠습니다.

당신의 가장 가까운 벗으로서 있어도 없는 듯 없으면 서운한,

맘편히 이야기를 털어놓을수 있는 그런 아내가 되겠습니다.

늘 사랑해서 미칠 것 같은 아내가 아니라,

아주 필요한 사람으로 없어서는 안되는 그런 공기같은 아내가 되겠습니다.

그래서 행여 내가 세상에 당신을 남겨두고멀리 떠나는 일이 있어도

가슴 한구석에 많이 자리잡을수 있는 그런 현명한 아내가 되겠습니다.



지혜와 슬기로 당신의 앞길에 아주 밝은

한줄기의 같은 불빛은 되지 못한다 하더라도 호롱불처럼 아니면

반딧불처럼 당신이 가는 길에 빛을 드리울수 있는 그런 아내가 되겠습니다.

그래서 당신과 내가 흰서리 내린 인생의 마지막 길에서

"당신은 내게 정말 필요한 사람이었소. 당신을 만나 작지만 행복했었소"

라는 말을 듣는 그런 아내가 되겠습니다.



2. 이런 남편이 되겠습니다.


눈부신 벚꽃 흩날리는 노곤한 봄날, 저녁 어스름이 몰려올때쯤,

퇴근길에 안개꽃 한무더기와 수줍게 핀 장미 한송이를 준비하겠습니다.

날 기다려주는 우리들의 집이 웃음이 묻어나는 그런 집으로 만들겠습니다.

때로는 소녀처럼 수줍게 입 가리고 웃는 당신의 호호웃음으로,

때로는 능청스레 바보처럼 웃는 나의 허허 웃음으로,

때로는 세상 그 누구도 흉내낼수 없는 우리사랑의 결실이 웃는 까르륵 웃음으로.



피곤함에 지쳐서 당신이 걷지 못한 빨래가

그대향한 그리움처럼 펄럭대는 오후. 곤히 잠든 당신의 방문을 살며시 닫고

당신의 속옷과 양말을 개켜 두도록 하겠습니다.

때로 구멍난 당신의 양말을 보며 내 가슴 뻥 뚫린 듯한 당신의 사랑에

부끄런 눈물도 한방울 흘리겠습니다.

능력과 재력으로 당신에게 군림하는 남자가 아니라 당신의

가장 든든한 쉼터, 한그루 나무가 되겠습니다.



여름이면 그늘을, 가을이면 과일을,

겨울이면 당신 몸 녹여줄 장작이 되겟습니다.

다시 돌아오는 봄, 나는 당신에게 기꺼이 나의 그루터기를 내어 주겠습니다.

날이 하얗게 새도록 당신을 내품에 묻고, 하나둘 돋아난

시린 당신의 흰 머리카락을 쓰다듬으며,

당신의 머리를 내 팔에 누이고 꼬옥 안아주겠습니다.

휴가를 내서라도 당신의 보모님을 모셔다가

당신의 얼굴에 웃음꽃이 피어나는걸 보렵니다.

그런 남편이 되겠습니다.

인터넷에서 떠도는 글... 원작자 모름. ^^



세상에서 내가 가장 많이 생각했던 열 글자
♡ 항상내곁에있어줬으면...


세상에서 내가 가장 바랬던 아홉 글자
♡ 너와하나가될수있다면...


세상 모든것이 달라진다 해도 달라지지 않는 여덟 글자
♡ 항상너를향한마음...


가장 힘든일이 닦쳤을 때 해줄 일곱 글자
♡ 항상널지켜줄께...


세상에 가장 아른다운 여섯 글자
♡ 너의밝은미소...


무엇이든 가능케하는 다섯 글자
♡ 너를위해서..


나를 가장 기쁘게 하는 네 글자
♡ 너의사랑...


너에게만 들려줄 세 글자
♡ 사랑해...


세상 끝날까지 우리에게 없을 두 글자
♡ 이별...


세상에서 가장 소중한 한 글자
♡ 너...

인터넷에서 떠도는 글... 글쓴이 모름. ^^


I nspire warmth
따뜻함을 불어 넣어 주고

L isten to each other
상대방의 말을 들어 주고☆

O pen your heart
당신의 마음을 열어 주고

V alue your opinion
당신을 가치 있게 평가 하고

E xpress your trust
당신의 신뢰를 표현 하고

Y ield to good sense
좋은 말로 충고해 주고
 
O verlook mistake
실수를 덮어 주고

U nderstand
이해하는 것

거의 3주 가량이 지난후에 올리는 가공할만한 귀챠니즘... ㅠ.ㅠ
지난달 21일에는 우리 딸아이가 다니는 어린이 집에서 운동회를 했다.
애가 하나 뿐이니 나 역시 학부형으로 참석하기는 첨인것 같은데... 나름 설레였다.

그런데 어린이집 운동회가 원래 그런것인지 모르겠으나... 생각했던것과는 달랐다.
좋다고 해야할까? 난 단지... 애들 뛰는거나 보다가 오겠지 했는데... 이건 웬걸 애들이 구경하고 엄마,아빠가 뛰는 코너가 훨씬 많다.  ^^

자! 지금부터 사진이다!

Intro??

우리딸 팀은 백팀 이다.

"캬~캬캬캬캬캬~~" 웃음 소리이 들리는듯 한다

5살 아이들이 만들었다고 한다.

앞서 에이엘테크의 디빅스플레이어 MG-25P 의 두차례 뽑기의 실퍠로 반품후
다른회사의 디빅스 플레이어를 주문하였다. 바로 유니콘 의 MV-2500U 라는 제품이다.

금일(11/8) 도착하였다 하여 서둘러 집에 와서 포장을 벗기는 웬지 상태가 메롱~ 이다.

제품박스의 포장 상태가 영~~ 신품같지 않다. 찢기고, 꾸겨지고... 내부의 프라스틱(?)재질도 마찬가지이다.

찢기고, 꾸겨진 본체박스

그리고 본체포장 상태이다. 긁힘을 방지하고자 테이프를 붙여 놓았을텐데... 영~~ 신품같지가 않다.

뭐~ 여기까지는 이해하고 쓰려고 했다. 이전 주문한 제품이 불량이긴 했어도 나름대로 쇼핑몰에서는 충분히 대응을 잘해줬다는 생각에... 포장 문제라면 웬간하면 써야지 했다.

하여, 일단 숨을 고르고 구성품과 시리얼을 확인하기로 했다.
그런데... 그런데... 시리얼이 틀리다!! (이건 아니잖아!)

적색부분을 비교해보라. 틀리다!

리모콘의 포장상태도 영~ 아니다. 테이프로 붙여놨던 자리로 보이는 비닐은 찢겨져 있다.
사진으로는 알 수 없으나 리모콘의 밧데리 넣는곳을 보니 밧데리가 (이미)장착이 되어 있다. 그럼 포장된 밧데리는 뭔가? 여분??  (제조사에 문의해보니 밧데리는 장착되어 있지않으며 1개만 제공한다고 한다.)

리모콘도 포장이 뜯겨져 있음을 확인할 수 있다.

다음은 구성물중 없는게 있나 확인을 해봤다. (해당 쇼핑몰의 상품 소개에서 가져왔다)

적색박스로 표시한 내용물이 없다.
그리고 구성품에 없는 파우치(맨위에서 두번째 이미지를 보라)는 왜 있는것일까? - 아무래도 내가 제품이상으로 반품한 제품도 다른 사람에게 팔릴것 같은 불길한 예감이 든다.

아! 하나 더 표시는 안했지만 나사도 없다. (특히나 구성물의 나사가 내장하드를 고정하기 위한 나사라면 나사는 더 부족하다. 본체를 조립한 나사의 절반 가량이 없더만... --+)

용산에 있는 (쇼핑몰)업체이기는 하나 몇 번의 거래로 신뢰를 하고 있었다. 그런데... 이번에 (제품불량이라고는 하지만) 2번 연속 같은 불량, 정체불량의 제품 패키지 발송으로 인해... 해당 업체에 대한 신뢰에 의구심이 들기 시작한다.