호주 멜번스토리

프로프레임에서 dbio를 호출하였는데 오류가 발생하였다. 오류 번호로 리턴된 값은 -90001002 이고 오류메시지는 [DBIO] Conditions can't call the right function 이다. 어떤 경우에 이런 오류가 나오는 것일까? 처음 프로프레임 dbio 를 array fetch 로 작성하였을 때 관련한 배열처리 내부 함수들이 만들어 진다. 이런 array fetch dbio를 프로그램에 끌어다 사용하였을 것이다. 그 후에 개발자가 dbio 를 단건 fetch 로 변경하였다. 그리고 dbio를 컴파일 했다. 그러나 정작 이 dbio를 사용하고 있는 프로그램은 다시 컴파일을 하거나 재구성을 하지 않았다. 이런 경우에 프로그램이 실행될 때는 이전의 array fetch 함수를 계속 호출..

| 개요 프로프레임에서 수식 계산에 사용하는 pfmNumCalc 라는 함수가 있다. 계산식을 자유롭게 기술할 수 있기 때문에 참 유용한 함수이고 많이들 사용한다. 그런데 문제는 파라미터 포매팅 개수와 아규먼트 인자의 개수가 다를 경우에 문제가 발생될 수 있다. 개수가 다를 경우에 어떤 예기치 않은 문제가 발생될 수 있기 때문에 꼼꼼하게 체크해야 하지만 워낙에 개발자들이 바쁘시다 보니 많이들 놓칠 수 있다. 쉘 프로그램을 이용해서 일괄적으로 한꺼번에 모든 프로그램의 인자 개수를 체크하는 로직을 만들어 봤다. 프로프레임 엔지니어나 일반 개발자들도 잘 응용해서 사용하면 유용할 거 같아서 공개한다. 필요한 부분을 수정해서 본인의 용도에 맞게 사용하면 좋을 것이다. | 아이디어pfmNumCalc 함수 뒤에는 포매..

개발자들이 거래를 하고 바로 로그를 보기 위해서 로그파일을 tail 걸곤 한다. 좀 더 쉽게 해당 거래 로그만 추출하여 볼 수 있다면 편할 수 있다. 아래 스크립트를 응용하여 자기에게 맞게 편집하여 사용하면 편하게 볼 수 있지 않을까 싶다. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 # 서비스명을 입력하지 않으면 입력요청 if [ $# -lt 1 ];then echo "Which Service ?? \c" read SVC else SVC=$1 fi CHK=`echo $SVC | cut -..

프로프레임에서 사용하는 DBIO의 경우 select 하거나 fetch 할 때 pdb_lock 옵션을 이용할 수 있다. DBIO 스튜디오에서 Lock Query 생성을 체크하고 소스생성, 컴파일 할 때 생성된 SQL을 보면 WAIT 옵션이 뒤에 붙어 있는 것을 볼 수 있다. dbio 내부에서 sql을 실행하기 전에 input 의 pdb_lock 변수에 PDB_LOCK 값이 세트되어 온 경우에 SQL에 WAIT 절이 있는 지 체크하게 되고 SQL 에 WAIT 절이 없는데 LOCK option을 사용하겠다고 했을 때 "Lock option has no effect for the map" 메시지가 나오게 된다. 하지만 개발자가 dbio_in.pdb_lock = PDB_LOCK; 와 같이 코딩한 적도 없는데도 D..

프로프레임 환경에서 프로그램 실행시 [dlopen error Permission denied] 함수 [mxx_dacom_msg_deco]에 대한 dlcall이 실패하였습니다 [seq_no:14984545] 라는 메세시지를 만날 때가 있다. mxx_dacom_msg_deco.c 를 컴파일하여 libmxx_dacom_msg_deco.so 를 만들고 이 libmxx_dacom_msg_deco.so 를 dlupdate 한 후에 실행했을 때 나온 메시지 이다. libmxx_dacom_msg_deco.so 는야 dlupdate 될 때 $TDLDIR/run/ 아래에 복사되어 지므로 접근 권한이 없지 않겠지만libmxx_dacom_msg_deco.so 를 만들때 링크된 libclntsh.a, liblicense.a 라..

오라클에서 제공하는 proc 샘플을 이용하여 작성하였다. 프로프레임 3.0 에서는 거래를 할 때 마다 이미지로그 테이블에 거래 전문을 보관한다. 이것을 조회하여 text 파일로 떨어트린다. 그런 후에 이 전문 정보를 이용하여 재거래를 해 볼 수 있다. 재거래를 하기 위해서는 pfmtcl 이라는 명령을 이용한다. 이미지로그파일은 일자별로 나누어져 있기 때문에 일자를 입력값으로 받아야 한다. 프로그램내에서 Dynamic SQL을 이용하기 위하여 Prepared Statement 방식을 이용하였다. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43..

Tmax에서 기본 제공하는 tdlinit 명령은 $TDLDIR/mod/ 에 생성되어 있는 symbolic link 정보대로 .so 라이브러리를 복사하여 $TDLDIR/run/ 에 복사를 한 후에 메모리에 적재까지 하게 된다. tdlinit 명령을 실행하기 전에 반드시 Tmax를 내려야 한다. Tmax가 기동 중에 tdlinit 명령을 실행하게 되면 메모리에 올려져 사용되고 있을 라이브러리들은 삭제가 되지 않기 때문에 교체하는 과정에서 문제가 발생될 수 있다. tdlinit 은모듈 속 global function명과 run 하위의 실제 물리파일간의 hash 매핑정보를 Shared Memory에 적재하는 과정으로 제법 시간이 걸린다. 따라서 tdlinit -b 명령을 실행할 경우 $TMAXDIR/tdlcal..

C 프로그램에서 늘 마주치는 것이 코어덤프인데 어떤 코드 때문에 발생했는 지 찾을 때 사용하는 것이 gdb 와 dbx 명령이다. AIX 에서는 dbx명령을 주로 사용한다. 이렇게 dbx 를 사용하여 추적하기 위하여서는 컴파일 할 때 -g 옵션을 줘서 컴파일을 해 줘야 한다.| 샘플프로그램 작성 샘플 프로그램인 sfw0023.c 에 아래와 같이 코어덤프가 발생할 코드를 기술한다. ( 324 라인 ) bug 라는 포인터에는 메모리가 할당되지 않았기 때문에 값을 write 하면 core 덤프가 발생하게된다. 12345678910111213 318 static long 319 a000_validation(sfw0023_ctx_t *ctx) 320 { 321 long rc = RC_NRM; 322 char *bu..

프로프레임 3.0 에서 티맥스 서버를 일괄 컴파일하는 쉘을 작성하였다. 서버는 두가지 종류로 나눌 수 있는데 표준적인 서버가 있다. 이런 서버는 표준 템플릿서버소스로 동일한 모양의 소스로 생성이 되고 각 서비스는 dlcall 방식으로 호출하게 된다. 서버에 서비스는 하나씩만 구성할 수도 있고 하나의 서버에 여러 서비스를 묶을 수도 있는데 이것은 프로젝트 상황에 맞게 구성하면 된다. 작업하기 전에 쉘들이 존재하는 디렉토리 하위에 src, log, appbin 이 만들어져 있어야 한다. | 직접 컴파일 서버 목록 파일 작성 직접 컴파일 하는 목록을 먼저 작성한다. 전체 업무별 디렉토리를 뒤지면 직접 컴파일하는 서버 목록은 구할 수 있다. 이 작업은 약간의 수작업이 요구된다. [compile.svr.list]..

유닉스 쉘에서 파일을 읽어서 처리하는 프로그램이 필요하였다. 솔직히 말하면 프로프레임에는 pfmtcl 이라는 테스트거래하는 프로그램이 있는데 이미지로그의 전문을 읽어서 연속으로 거래를 날리고자 했다. 그런데 전문 끝에는 스페이스가 있는데 쉘에서 이것을 읽으면 모두 날라가버리고 Trim되어 읽힌다는 것이다. 인터넷을 찾아보면 따옴표(") 로 감싸면 된다지만 이게 또 잘 안된다. 끝에 있는 스페이는 이미 읽을 때 지워버리고 읽어버리기 때문에 소용없는 일이었다. 123while read line; do echo "$line"done