DBIO는 각 DBMS 벤더의 Embedded SQL에서 지원하는 모든 SQL을 지원한다.오라클 DB를 사용중이라면 Pro*C precompiler 가 지원하는 모든 SQL 구문을 지원한다. Dynamic SQL dbio 는 컴파일이 되는데 다른 dbio 타입으로 컴파일시 에러나는 경우를 알기 위해서는두가지 SQL 형식의 차이점을 알아야 한다. SQL 형식은 Embedded SQL과 Dynamic SQL으로 나뉜다.Embdedded SQL - SQL 쿼리가 실행되는 시점에 지정된 변수 값을 제외하고는 SQL 구문의 변화가 없는 형식 (PERSIST, VIEW, EXEC)Dynamic SQL - SQL 쿼리가 실행되는 시점에 쿼리 문장이 달라지는 SQL 형식 (DYNAMIC) 같은 SQL 구문이더라도 PE..
프로프레임 연동된 DB의 계정정보가 바뀔경우 다음과 같은 설정을 함께 바꿔줘야 한다. 환경변수변경DB의 IP도 변경되었다면 $TNS_ADMIN/tnsnames.ora 파일을 수정해야한다. (DBA 에게 요청하여 sid 의 ip,port 수정)$ENVHOME/profile.oracle 파일의 CONNECTON_INFO를 수정하여 준다. (SID가 변경되었다면 SID도 수정) profile.oracle 수정 후 terminal 재접속 하여 환경변수가 변경된 것을 확인한다. DBIO connect 프로그램 및 스튜디오 접속정보 수정 $PFMDEVDIR/pfmDbioConnectDB/pfmDbioConnectDB.c 파일 안의 runtime, compile, srcgen의 db connection 정보를 변경한..
피연동에서 주연동으로 combuff 전달은 default 셋팅에서는 막혀있다.주연동에서 피연동으로 넘어갈때 주연동의 Customize 헤더 combuff 항목에 대한 포인터는 PFM_HDR_EXT_CB이고 (복사된 combuff의 포인터) 피연동의 combuff 포인터가 PFM_HDR_EXT 가 된다.연동 연산이 끝나고 다시 프로세스 주연동으로 돌아올때 PFM_HDR_EXT_CB 포인터에 있는 주연동의 combuff 값을 recover 하게 되므로 피연동의 combuff 값은 사라지게 된다. 피연동의 combuff 값을 주연동으로 전달하려면 다음과 같이 combuff가 주연동의 combuff 버젼으로 recover 되기전에 PFM_HDR_EXT_CB에 PFM_HDR_EXT 값을 memcpy 해주는 로직이..
외부 라이브러리 api 추가등의 이유로 따로 환경변수를 추가하기 위해 profile을 수정하거나 추가하였다고 가정하자.해당 라이브러리의 inc 폴더와 lib 폴더를 경로를 make 파일에 추가하여야 되는데 새로 추가한 환경변수로 경로를 잡으려고 해도 스튜디오 컴파일시 make 파일에서 추가된 환경변수를 못읽어와 컴파일 오류가 발생한다. EX> 추가된 환경변수: export EXTLIBDIR = /home/extlibmake 파일에 추가된 경로: -I$(EXTLIBDIR) 스튜디오 컴파일시 make 파일 실행될때 -I$(EXTLIBDIR)을 못읽어와서 에러 발생. 이 경우 log서버와 build 서버를 재기동 해준다.log서버와 build서버는 기동 시점의 환경변수를 물고있기 때문에 profile 변경시 ..
간혹 프로젝트 중간에 테이블 컬럼정보가 부득이하게 변경되어해당 테이블 관련 DBIO를 모두 재빌드 해줘야하는 상황이 있다. 이때 다음과 같은 주의사항이 있다. 컬럼의 length가 바뀌었다면 해당 column에 대한 메타 정보도 수정해당 테이블에 대한 모든 dbio 에서 메타정보동기화 버튼 누른후 재빌드 메타정보동기화 버튼 ==> DBIO 생성시 pmap쪽에 dbio의 입출력 구조체도 생성되는데 이미 서버에 떨어진 소스이기 때문에 동기화가 안됨. dbio 별로 건건이 메타정보동기화 버튼을 눌러서 새로 pmap 소스를 생성하고 재빌드를 해줘야함. 재빌드된 dbio의 caller 모듈을 모두 검색해서 EMB창에서 모듈정보재구성을 해준뒤 해당 모듈들을 모두 재빌드 (caller 모듈에 dbio의 입출력 구조체..
Proframe C (4.0, 5.0)스튜디오는 리소스에 대해 자동 check out / check in 기능을 제공한다.예를들어, 유저가 스튜디오를 통해 서비스모듈을 열 경우 자동으로 check out 상태가되어다른 유저들은 그 모듈을 수정하지 못하게 된다. (check out - 해당 리소스에 대해 lock 이 걸림) 모듈을 check out 한 유저가 해당 모듈 창을 닫을 경우 자동으로 check in 되면서 lock 이 해제된다. 프레임워크 인프라 담당자는 DEV_LOCK_STATUS 테이블에 해당 리소스 정보가 존재하는지에 따라 check out, lock 상태를 구별할 수 있다. 스튜디오를 사용하는 개발자는 리소스풀 창에서 해당 리소스 검색으로 check in, out 상태를 확인 할 수 있다..
업무개발자들이 사용할 Header 를 직접 스튜디오 내비게이터에서 오른쪽 마우스클릭, New -> Header 를 통해 만들수 있다.이렇게 만들어진 Header 파일을 모듈의 특성창 include header에 추가하여 사용할 수 있는데 해당 header를 추가하고 컴파일 하기 위해서는 make_common_proframe 파일에 해당 header 파일이 저장된 경로를 추가해줘야 한다. 스튜디오에서 만들어진 Header 파일의 저장 경로는 DEV_CONFIG 테이블의 CONFIGNAME = 'HEADER_HOME' row의 CONTENT 값으로 지정되어 있는데 Default 값은 보통 /compile/${resourceGroup}/inc/ 으로 업무그룹별로 파일이 저장된다. 보통 프레임워크 담당자는 업무..
Proframe studio를 이용해서 개발할 때 리소스가 오랜기간 많이 쌓이게 되면 리소스 저장, 리소스 히스토리 검색 속도가 느려진다. 해당 기능과 연관된 테이블에 데이터가 많이 쌓여서 생기는 현상인데 해당 테이블은 DEV_HISTORY, DEV_HISTORY_CONTENTS 이다.날짜가 많이 지난 DEV_HISTORY의 데이터는 삭제해주고 DEV_HISTORY_CONTENTS의 경우 HISTORY_ID를 이용해 정리를 해줘야한다. 수동이 아닌 자동으로 리소스 정리를 하기 위해서는 통합서버 설정파일에서 RESOURCE_HISTORY_MANAGEMENT, HISTORY_DAY_RANGE, HISTORY_ROW_NUM_RANGE 값을 조정하여 설정할 수 있다. ex>==> 자원 History 관리를 사용..
Proframe 4c, 5c 에서 제공하는 기능중 File IO를 사용할 때 주의할 점이 있다. File IO 의 Read Buffer는 최대길이가 10240 (10kb) 로 고정되어 있다. 때문에 File IO 구조체를 만들때 총 길이가 10240을 이상일 경우 한번에 데이터를 못읽는 경우가 생긴다.그리고 그 다음번 데이터를 읽을때 다음 전문의 시작부분이 아니라 소실된 데이터 부분부터 시작하기 때문에 담기는 데이터가 꼬이게 된다. File IO의 Read Buffer 의 최대길이는 엔진소스에서 설정되기 때문에 해당 부분 변경을 위해서는 패치가 필요하기 때문에부득이한 케이스를 제외하고는 AP 개발시에 사용하는 File IO 구조체의 총길이를 10240 미만으로 가져가야 한다. 왜 이렇게 만들어놨을까 궁금..
Proframe 가이드 상으로는 일반배치 작성시 하나의 배치모듈에 하나의 일반배치서버를 사용하도록 가이드 한다. 하지만 배치 모듈이 만개가 넘어가는 상황에서 각 모듈마다 일반배치서버를 생성하면 너무 큰 리소스 낭비이기 때문에 많은 프로젝트에서 하나의 일반배치 서버에서 여러 배치 모듈을 호출하는 방식을 채택하고 있다. 이 경우에 문제점 중 하나는 모든 배치모듈들의 로그가 하나의 로그파일에 생성되기 때문에 수천개의 로그가 뒤죽박죽 섞일 수 있다. 이를 해결하기 위해 스튜디오에서 일반배치서버 소스를 자동 생성하지 않고 약간의 커스터마이징을 추가하여 직접 서버를 만들어야 한다. 다음 소스는 Proframe 스튜디오 상에서 일반배치서버를 생성할 경우 자동 생성되는 서버 소스의 pfmBatchInit method ..
- Total
- Today
- Yesterday
- TECH U ASA
- AWS 면접
- SA란
- dbio
- oracle
- AWS 신입
- Terraform
- 프로프레임
- 아마존 입사
- ProFrame
- AWS 이직
- AWS Associate Solution Architect
- expect 스크립트
- AWS 취업 후기
- AWS TECH U
- 뱅크샐러드 면접
- AWS 인터뷰
- 구글 이직
- gcp 자격증
- AWS 입사
- AWS 문화
- GCP 이직
- 구글 입사 후기
- Terraform GCP
- 2022 회고
- 아마존 이직
- AWS 신입 채용
- 오라클
- GCP 자격증 후기
- AWS 후기
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |