ConQAT의 의사 claims COBOL 코드에서 복제 검색을 수행 할 수 있지만 list of Included blocks에서 적절한 블록을 찾을 수 없습니다. 간주 될 수ConQAT로 COBOL 클론을 탐지합니까?
유일한 사람은 StatementCloneAnalysis이지만 각 라인 앞에 줄 번호 혼란을받을 것이다 :
016300******************************************************************0058
재미있는 도구입니다. 빠른 견해를 보았고 COBOL 원본을 공백으로 겹쳐 쓰고 COBOL 원본을 전처리하여 72 열 다음에 모든 것을 다듬는 것이 간단한 해결책이라고 생각합니다.
잠시 동안 파고 들자 마자 NextToken scanner definition file for COBOL. "행복하게"연속열 번호 영역과 72 번째 열의 토큰을 가져 오는 것 같습니다. 토큰 라이저는 컴파일 과정에서 라이브러리 처리 단계를 거친 후 COBOL 소스 코드만을 처리하는 것처럼 보입니다 (예 : 컴파일러 이후). COPY/REPLACE와 같은 지시문이 처리되었습니다). COPY/REPLACE가 키워드로 지정되었지만이 토크 나이저가 어떻게 적절하게 처리되는지는 알지 못합니다. 특히 의사 텍스트가 관련되어있는 경우 특히 그렇습니다.
IBM COBOL 컴파일러에 대해 작업하는 경우 컴파일시 MDECK 옵션을 지정하여 분석에 적합한 소스 파일을 생성 할 수 있습니다. 필자는 다른 공급 업체에 익숙하지 않아서 포스트 텍스트 조작 소스 데크를 생성하는 방법에 대해서는 더 이상의 설명을 할 수 없습니다.
COBOL을 제공하는 복제 탐지 conquat의 수준은 다른 언어 (예 : java)에 비해 매우 제한적으로 보입니다. COBOL 프로그램을 위해 사소한 복제 탐지 이상의 것을 얻으려면 많은 시간을 투자해야 할 것입니다. 그러나 이것은 일반적인 COBOL 프로그램에서 잘라 내기/붙여 넣기 코딩을 많이 사용하여 매우 유용한 프로젝트가 될 수 있습니다 (COBOL 프로그래머는 종종 농담을합니다 : 한 개의 COBOL 프로그램 만 작성되었으며 나머지는 수정 된 사본입니다) . 나는 네가 잘되기를 바란다.
ConQat이 COBOL을 잘못 처리한다고 가정하면 CloneDR 도구를 볼 수 있습니다.
정확한 파서 (parser)를 사용하여 IBM Enterprise COBOL에서 명시 적으로 작동하는 버전을 가지고 있으며, 그 모든 일련 번호의 난센스를 올바르게 처리합니다. (네이티브 ECBDIC에서 COBOL 코드를 읽을 수도 있습니다. 즉, ASCII 개행 문자가 들어있는 리터럴 문자열은 파서를 손상시키지 않습니다.) [COBOL이 IBM COBOL이 아닌 경우, 이는 도움이되지 않지만, 그렇지 않으면 "아무것도 얻으려면 많은 시간을 투자해야합니다"].
우리는 AST 기반 탐지 기술이 ConQat의 토큰 기반 탐지보다 더 정확하게 더 나은 클론을 탐지한다고 생각합니다. 이 사이트는 이유를 자세히 설명하고 CloneDR에 의해 탐지 된 샘플 COBOL 복제본을 보여줍니다.
일본에서 근무중인 것으로 보이는 OP와 관련하여 보너스로, 유니 코드 및 Shift-JIS가 활성화 된 an underlying tool infrastructure 위에 구현되어 있기 때문에 CloneDR은 일본어 문자 집합을 처리합니다. 우리는 일본어 COBOL에 대한 많은 경험이 없으므로 남아있는 결함이있을 수 있습니다. G literals with Japanese characters을 참조하십시오.