기술 저장소

프로프레임에서 서비스 - 서비스간 연동방식은 크게 Local/Remote, Sync/Async, 1-tx/n-tx 로 나뉜다. Local call은 tdl 공유 메모리의 shared library를 호출하는 Dlcall 방식, Remote call은 TMAX 미들웨어에 등록된 tcs 서비스를 호출하는 tpcall 방식이다. Local call 의 경우 Sync, 1-tx 방식만 가능하고 Remote call의 경우 XA방식이 아닌 Non-XA 방식으로 TP서버가 구성되어 있다면 n-tx 방식만 가능하다. 위의 설정들은 call property만 수정하는것으로 간단하게 설정 가능하지만 Async Reply 방식으로 서비스연동을 할 경우 추후에 reply 를 받아오기 위해서 추가적인 개발 과정이 필요하다. ..

스튜디오나 통합서버 기능을 디버깅 하는데 JeusServerLog (jlog)를 주로 사용한다. 그런데 문제는 스튜디오는 개발자 수만큼 여러개인데 통합서버는 하나이다 보니 jlog 가 뒤죽박죽 섞여있어서 내 스튜디오서 발생한 action의 로그를 찾기가 힘들다. 이럴때 다음의 설정으로 간단하게 내 스튜디오만의 jlog를 확인할 수 있다. 통합서버 설정파일인 PfmDevSvr.xml 의 내용중 다음부분을 수정하여 준다. PRIVATE_LOG 의 value는 YES로 변경PRIVATE_LOG_IP의 value에 로그 확인을 원하는 스튜디오 pc의 IP를 입력한다. , 를 구분자로 여러개 IP를 넣는 것도 가능PRIVATE_LOG_DIR의 value 폴더는 생성해줘야한다. 설정 수정 후 JEUS를 재기동하면 ..

Proframe 4는 스튜디오 실행시 Local PC의 java path를 물고 올라간다. Proframe 4는 자바 version 1.6 을 사용해야는데 내 로컬 PC의 자바 version 이 1.8 이라면 다음과 같이 스튜디오 실행전에 임시로 java_path를 변경하고 실행하는 bat 파일을 만들어 사용하면 편리하다. (시스템 변수의 java_path를 변경할 필요 없음) ex> start_proframe.batset path="C:\Program Files\Java\jdk1.6.0_45\bin";%path% java -versionproframe.exe -clean -debug bat 파일은 proframe.exe 실행파일이 있는곳에 만들어 준다. Proframe 5부터는 스튜디오 폴더의 내장 j..

ProFrame 제품이 B2B (Business to Business) 제품이다보니 기업환경에서 프로젝트를 경험해보지 않는 이상 일반유저 입장에서 제품을 사용해볼 수 있는 기회가 거의 없다. ProFrame 스튜디오가 보기에는 그냥 이클립스 기반의 로컬 IDE 처럼 보이지만 클라이언트 PC 외에도 서버, DB서버가 구성되어야 한다. 실제 개발환경이 구축되기 위해서는 WAS(JEUS), 미들웨어(TMAX), DB가 설치 되어야 하고 여러 설정들이 복잡하게 얽혀있기 때문에 티맥스소프트 엔지니어의 도움없이는 개발/테스트 환경 구축이 쉽지 않다. 이런 상황이다 보니 실제 제품을 사용하는 개발자 입장에서도 직접 프로젝트에 투입 되기전에는 제품을 접하기가 힘들고 인터넷에 프로프레임 메뉴얼이 존재하긴 하나 테크넷(h..

상주배치란? 상주 배치는 일반 배치의 일회성 특성에 스케줄 관리 기능을 포함하여 설계된 배치이다.일반 배치는 일회성 프로그램으로서 "수행 → 실행 → 종료"의 과정을 거치는 반면 상주 배치는 "수행 → {실행 반복} → 종료"의 과정으로 수행한다. 다시 말해 상주 배치는 특정 주기와 간격으로 배치를 수행할수 있도록 설계된 배치이다. 이러한 상주 배치의 요건을 구현하기 위해서 Tmax의 UCS 서버의 기능을 이용하고 있다.(ProFrame 배치 프로그래밍 안내서 발췌) 상주배치모듈 작성전에 상주배치서버(UCS서버)를 만들어야 한다.UCS서버 작성 방법은 두가지가 있는데 스튜디오에서 만드는 방법과 인프라 운영자가 기존 UCS 서버를 copy해서 만드는 방법이 있다.대부분의 사이트에서는 시스템에 치명적 영향을..

IPPR은 전문을 수신하는 프로프레임 서비스이고 OPPR은 전문을 송신하는 서비스 이다.IPPR을 통해 프로프레임 서비스를 호출하게 되면 OPPR을 통해 출력전문을 생성하는데 프로젝트 초기 설계된 표준전문설계에 맞게 전문을 조립하도록 pfmOpprExternalProcess.c 소스를 커스터마이징 한다. 기본 default는 system 헤더 + customize 헤더 + error message 헤더 + message 헤더 + output Data 이다. 여기서 문제가 되는 10byte는 정상일때 error message 헤더 + message 헤더 의 길이이다. 두 메세지 해더는 가변으로 error 발생시나 message 셋팅시 길이가 늘어나고 보통 정상 처리 될경우 00000, 00000 각각 5b..

ipcs -ma 명령어로 shared memory 주소를 사용하는 프로세스의 정상 기동 여부 확인이 가능하다. TCacheTDL shared memoryTMAX 운영기의 경우 위 3가지 체크로 기동여부 확인 가능하고개발기의 경우 추가적으로 제우스와 로그서버, 뷜드서버의 기동 여부를 확인해야 한다.(ps -ef | egrep 'jeus|LogServedr|PfmBuildServer') ipcs -ma | grep 유저명 | grep -v D- m 20972398 0x00070015 --rw-rw-rw- proframe tmax proframe tmax 0 402685000 13697404 13697404 13:22:29 13:22:30 13:22:29m 11535241 0x0002888b --rw-----..

dbx는 Unix 소스 레벨 debugger다. 프로프레임에서 발생하는 core는 dbx를 이용하여 분석이 가능하다. dbx로 core 분석법을 알아보기 위해 일단 core를 발생시킬 소스를 만들어서 컴파일 한다. dbx를 사용하기 위해서는 컴파일 옵션으로 -g를 넣어줘야 하는데 프로프레임 make 파일에 기본적으로 -g 옵션을 사용하고 있다. 다음은 프로프레임 서비스 모듈에 코어를 발생시킬 소스를 추가한 것이다. 일단 core를 분석하기 위해서 core가 어떤 프로그램에서 발생했는지 알아본다. 일반적으로 core 파일은 core를 발생시킨 바이너리와 동일한 폴더에 생성되지만 프로프레임은 보통 $PFM_CORE_DIR/{코어발생날짜}/{코어발생모듈} 폴더에 core 파일을 생성한다. file 명령어를 사..

프로프레임의 DBIO는 DML문만 생성 가능하다. CREATE, DROP, TRUNCATE, ANALYZE 등의 DDL문은 DBIO로 생성이 불가능하다.그렇다면 DDL문을 프로프레임에서 사용하기 위해서는 어떻게 해야될까?방법은 두가지가 있다. DBA에게 function으로 해당 DDL문을 만들어달라고 하여 그 function을 호출하는 select DBIO를 만든 후해당 DBIO를 사용하는 비즈모듈을 만들어서 제공한다. 이 방법의 문제점은 oracle function이 DDL문을 지원하지 않는다는 점이다. 이 경우 function을 만들때 dynamicSQL을 사용하여 DDL을 excute 하도록 만들면 된다. DDL문을 function으로 만들수 없음create or replace function f ..

pfmTCacheInvalidate API는 TCache가 관리하는 cache_name 테이블에서 입력된 key에 해당하는 레코드 데이터를 초기화 한다. 사용법은 다음과 같다. long pfmTCacheInvalidate( const char* cache_name, const char* key, long flags ); 구성설명cache_namepfmtcache.cfg의 “CACHE_NAME”에 정의한 캐쉬 이름key입력 데이터의 앞 부분부터 pfmtcache.cfg 파일에 기록된 “SIZE_KEY”의 길이 만큼의 데이타flagsinvalidate를 할 때 내부적으로 사용하는 flag기본적으로 “0”의 값으로 세팅return 값성공시 : 0실패시 : negative pfmTCacheInvalidate 함..