레거시 Cobol/PL1을 Java로 마이그레이션한 경험

https://stackoverflow.com/questions/1029974

06-07-2019
|

문제

원래 질문:대규모 Cobol/PL1 코드베이스를 Java로 마이그레이션한 경험이 있는 사람이 있는지 궁금합니다.

프로세스가 얼마나 자동화되었으며 출력을 얼마나 유지 관리할 수 있었습니까?

트랜잭션에서 OO로의 전환은 어떻게 이루어졌나요?

이 과정에서 얻은 교훈이나 도움이 될 수 있는 리소스/백서를 높이 평가하겠습니다.

7/7 수정: 확실히 NACA 접근 방식은 흥미롭습니다. JAVA 버전을 출시하는 시점까지 COBOL 코드에 대한 BAU 변경을 계속할 수 있는 능력은 모든 조직에 장점이 있습니다.

Java 언어에 익숙해지면서 코더에게 편안함을 제공하기 위해 COBOL과 동일한 레이아웃의 절차적 Java에 대한 주장은 대규모 코드 기반을 가진 대규모 조직에 유효한 주장입니다.@Didier가 지적했듯이 연간 300만 달러의 절약은 앞으로 코드를 지속적으로 리팩토링하기 위해 BAU 변경 사항에 대한 넉넉한 패딩을 제공합니다.그가 말했듯이, 당신이 사람들을 배려한다면 점차적으로 그들에게 도전하면서 그들을 행복하게 유지할 수 있는 방법을 찾을 수 있을 것입니다.

@duffymo의 제안으로 볼 때 문제는 다음과 같습니다.

뿌리의 문제를 실제로 이해하고 실제로 이해하고 객체 지향 시스템으로 다시 발현하는 것이 가장 좋습니다.

진행 중인 BAU 변경 사항이 있는 경우 새로운 OO 시스템을 코딩하는 긴 프로젝트 수명 동안 두 번의 변경 사항을 코딩 및 테스트하게 된다는 것입니다.이는 NACA 접근 방식의 주요 이점입니다.저는 클라이언트-서버 애플리케이션을 웹 구현으로 마이그레이션한 경험이 있으며 이는 BAU 변경으로 인해 요구 사항이 지속적으로 바뀌면서 우리가 직면한 주요 문제 중 하나였습니다.이로 인해 PM 및 일정 관리가 정말 어려워졌습니다.

경험이 훌륭하게 담긴 @hhafez에게 감사드립니다. "비슷하지만 조금 다르다" Ada에서 Java로의 자동 코드 마이그레이션에 대해 합리적으로 만족스러운 경험을 갖고 있습니다.

기여해 주신 @Didier에게 감사드립니다. 저는 아직 귀하의 접근 방식을 연구하고 있으며 질문이 있으면 연락 드리겠습니다.

해결책

6/25 업데이트: 친구가 방금 가로질러 달려갔어 나카 Cobol-Java 변환기.매우 흥미로워 보입니다. 4m 라인의 Cobol을 100% 정확도로 번역하는 데 사용되었습니다.여기에 NACA 오픈소스 프로젝트 페이지.내가 본 다른 변환기는 독점 제품이었고 자료에는 성공 사례와 자세한 예제 코드가 눈에 띄게 부족했습니다.NACA는 오랫동안 살펴볼 가치가 있습니다.

7/4 업데이트: @Ira Baxter는 Java 출력이 매우 Cobol과 유사하다고 보고합니다.나에게는 이것이 자동번역의 자연스러운 결과이다.우리가 훨씬 더 나은 번역자를 찾을 수 있을지 의문입니다.이는 아마도 점진적인 재작성 접근 방식을 주장할 것입니다.

2011년 2월 7일 업데이트: @spgennard는 JVM에 Veryant와 같은 일부 Cobol 컴파일러가 있음을 지적합니다. isCobol 진화.OP는 자동화된 소스 변환에 더 관심이 있었지만 코드 기반을 점진적으로 전환하는 데 도움이 될 수 있습니다.

나는 이것에 대해 매우 조심할 것입니다.(저는 자동으로 일하는 회사에서 일했어요. 수정됨 Y2K용 Cobol 및 PL/I 프로그램, Cobol의 많은 방언을 중간 분석 형식으로 변환하는 프런트 엔드 컴파일러 및 코드 생성기를 수행했습니다.) 제 생각에는 여전히 Java 코드 기반을 사용하게 될 것입니다. 작업하기에 우아하지 않고 불만족스러울 것입니다.성능 문제, 공급업체가 제공하는 라이브러리에 대한 종속성, 버그가 있는 생성된 코드 등이 발생할 수 있습니다.확실히 엄청난 테스트 비용이 발생하게 될 것입니다.

새로운 객체 지향 디자인으로 처음부터 시작하는 것이 올바른 접근 방식이 될 수 있지만, 코드 베이스에 표현된 수십 년간 저장된 지식도 신중하게 고려해야 합니다.새 코드에서 놓칠 수 있는 미묘한 부분이 많은 경우가 많습니다.반면에 레거시 시스템을 유지 관리할 직원을 찾는 데 어려움을 겪고 있다면 선택의 여지가 없을 수도 있습니다.

점진적인 접근 방식 중 하나는 먼저 Cobol 97로 업그레이드하는 것입니다.이렇게 하면 객체 지향이 추가되므로 새 기능을 추가할 때 하위 시스템을 개별적으로 다시 작성하고 리팩터링할 수 있습니다.또는 개별 하위 시스템을 새로 작성된 Java로 대체할 수도 있습니다.

때로는 구성 요소를 기성 소프트웨어로 교체할 수도 있습니다.우리는 1950년대에 만든 레거시 언어로 된 2백만 줄의 코드를 여전히 보유하고 있는 매우 큰 보험 회사를 도왔습니다.우리는 그 중 절반을 Y2K 호환 레거시 언어로 변환했고 나머지 절반은 외부 공급업체에서 구입한 최신 급여 시스템으로 교체했습니다.

다른 팁

사람들의 마이그레이션을 용이하게하기 위해 원래 COBOL에 매우 가까운 초기 Java 코드를 얻는 것이 분명히 우리의 의도였습니다. 그들은 COBOL에 쓴 좋은 오래된 앱을 정확히 같은 구조로 찾습니다.

우리의 가장 중요한 목표 중 하나는 초기 개발자를 기내에서 유지하는 것이 었습니다. 그것이 우리가 그것을 달성하는 방법입니다. 응용 프로그램이 Java로 마이그레이션되면 해당 사람들은 더 발전 / 리팩토링 할 때 더 많은 OO로 만들 수 있습니다.

사람을 이주하는 것에 신경 쓰지 않으면 다른 전략을 사용할 수 있습니다.

이 1 대 1 전환은 또한 100% 자동화 된 변환을 더 간단하고 빠르게 만들었습니다. 좋은 결과는 반복되는 저축 (3 백만 유로 / 년)을 훨씬 더 빨리 만들었다는 것입니다. 12-18 개월을 추정합니다. 이러한 조기 저축은 oo 리팩토링에서 분명히 재투자 할 수 있습니다.

저에게 연락하십시오 : didier.durand@publicitas.com 또는 mediaandtech@gmail.com

Didier

내 경험은 비슷하지만 약간 다릅니다. 우리는 최근에 Java로 변환 된 ADA (15 년 이상 0.5mloc)에 크고 오래된 코드 기반을 가지고 있습니다. 자동화/수동 변환의 조합을 제공 한 회사에 아웃소싱되었습니다. 또한 ADA 및 Java 시스템이 동일하게 행동했는지 확인하기 위해 테스트를 수행했습니다.

Ada 95 (즉, OOP의 가능성이 있었음)에 쓰여진 부분의 일부는 그렇지 않았습니다.

예, 코드는 처음에 Java로 작성된 동일한 표준 코드 표준이 아니지만 주요 문제없이 성공적으로 (18 개월) 사용해 왔습니다. 우리가 얻은 주요 장점은 이제 우리는 유지 관리 가능한 코드를 생성하는 기술로 코드 기반을 유지할 수있는 더 많은 개발자를 찾을 수 있다는 것입니다. (누구나 ADA에서 발전 할 수는 있지만 경험이 없다면 다른 언어와 마찬가지로 감소 할 수없는 코드로 끝날 수 있습니다).

위험 회피 관점에서 볼 때 NACA 접근 방식은 절대적으로 의미가 있습니다. 도구를 재사용하는 것은 그렇지 않을 수 있습니다. 그들은 도구 개발을 사용하여 자바와 리눅스에서 사람들의 속도를 높였습니다.

NACA 변환의 결과는 충분하지 않거나 심지어 OO가 될 수 없으며 새로운 사람들을 고용하기가 어렵습니다. 그러나 테스트 가능하고 리팩토링 될 수 있으며 더 나은 번역기를 연결할 수 있습니다.

편집] IRA, 당신은 매우 위험한 인식이 아닌 것 같습니다.

COBOL 프로그래머를 Java 코스로 보내는 것은 사용 가능한 객체 지향 코드를 작성하지 않을 것입니다. 몇 년이 걸립니다. 그 기간 동안 생산성은 매우 낮으며 기본적으로 첫해에 쓰는 모든 코드를 버릴 수 있습니다. 또한 프로그래머의 10-20%를 잃게되며, 기꺼이 전환 할 수 없거나 전환 할 수 없습니다. 많은 사람들이 초보자 지위로 돌아가는 것을 좋아하지 않으며, 일부 프로그래머가 다른 프로그래머보다 새로운 언어를 훨씬 빨리 선택하기 때문에 펙킹 순서에 영향을 미칩니다.

NACA 접근 방식을 통해 비즈니스는 계속 일할 수 있으며 조직에 불필요한 압력 을가하지 않습니다. 전환의 시간 예약은 독립적입니다. OO 전문가가 쓴 Java에 별도의 번역가가 있으면 이전 팀의 Java에 점진적으로 노출 될 수 있습니다. 테스트 케이스를 작성하면 새로운 Java 팀의 도메인 지식이 증가합니다.

실제 OO 시스템은 번역기이며, 이것이 더 나은 번역기를 연결하는 곳입니다. 그렇게하기 쉽고 생성 된 코드를 터치 할 필요가 없습니다. 생성 된 코드가 충분히 추악한 경우 자동으로 발생합니다 :)

구 프로그래머는 COBOL 입력을 변경합니다.
새로운 Java는 번역가를 바꿀 것입니다.

번역기를 한 번 실행]은 나쁜 전략입니다. 그렇게하지 마십시오. 생성 된 코드를 편집 해야하는 경우 매핑을 유지하십시오. 자동화 할 수 있습니다. 그리고해야합니다. SmallTalk 이미지에서 이러한 종류의 작업을 수행하는 것이 훨씬 쉽지만 파일로 수행 할 수 있습니다. 같은 아티팩트에 대해 다른 견해를 유지하는 경험이 많은 사람들이 있습니다. 칩 디자이너가 떠 오릅니다.

번역기는 계측되어야하므로 매일의 수를 만들 수 있습니다.

COBOL 입력 구성 요소;
OO Java 입력 구성 요소;
COBOL 스타일 출력 구성 요소;
OO 스타일 출력 구성 요소.

Peter Van Den Hamer & Kees Lepoeter (1996) 설계 데이터 관리 : CAD 프레임 워크, 구성 관리 및 데이터 관리의 5 가지 차원, IEEE의 진행, vol. 84, No. 1, 1996 년 1 월

COBOL 플랫폼 이동] 메인 프레임의 COBOL에서 Windows/Linux의 COBOL로 이동하는 것은 NACA 팀에게는 실행 가능한 전략 이었지만 Java로 이동하는 것이 었습니다. 장기 목표가 현대적인 OO 시스템을 갖추고 가능한 한 운영 위험이 거의없는 경우 NACA 접근 방식이 건전합니다. 그래도 한 단계 일뿐입니다. 많은 리팩토링이 이어질 것입니다.

아무도 Semantic Design의 DMS 소프트웨어 리엔지니어링 툴킷을 언급하지 않았다는 사실에 놀랐습니다.나는 과거에 COBOL 변환을 살펴보았습니다.그 당시 저는 "자동 프로그래밍" 작업을 하고 있었습니다.번역가를 쓰기 전에 나는 그 분야에 대한 이전의 많은 노력과 제품을 찾아보았습니다.Semantic Designs의 GLR 기반 도구는 그 중 최고였습니다.

그것은 수년 전이었습니다.당시 이 도구는 COBOL을 현대 언어로 번역하고 리팩토링하고 예쁘게 인쇄하는 등의 작업을 수행했습니다.지금 여기에 대한 링크가 있습니다.

http://www.semdesigns.com/Products/DMS/DMSToolkit.html

그들은 아직 주변에 있어요.그들은 도구를 확장했습니다.더 일반적입니다.자동 변환을 수행하거나 변환 도구를 사용자 정의하는 사람들에게 도움이 될 수 있습니다.Stephan이 지적한 것과 유사하게 확장 및 조정이 가능하도록 설계되었습니다.SoftwareMining을 언급한 Cyrus에게도 감사드립니다.향후 COBOL 마이그레이션이 발생하면 이에 대해서도 조사하겠습니다.

당신은 말하고 있습니다 리엔지니어링. 좋은 점은 전 세계 많은 사람들이 이것을하려고한다는 것입니다. 나쁜 점은 레거시 애플리케이션 리엔지니어링에 관한 많은 문제가 있다는 것입니다. 누락 된 소스에서 시작하여 컴파일러 구성 및 그래프 이론 필드의 복잡한 알고리즘까지.

자동 번역에 대한 아이디어는 무언가를 변환하려고 할 때까지 매우 인기가 있습니다. 일반적으로 결과는 끔찍하고 인재 할 수 없습니다. 원래 복잡한 응용 프로그램보다 더 인재 할 수 없습니다. 저의 관점에서, 레거시에서 현대 언어로 자동 번역을 할 수있는 모든 도구는 마케팅 지향적입니다. 사람들이 "응용 프로그램을 한 번만 번역하고 Java로 번역하고 잊어 버리십시오!" 계약을 구매 한 다음 도구에 매우 크게 의존한다는 것을 이해합니다 (응용 프로그램 없이는 응용 프로그램을 변경할 수 없기 때문에).

대안적인 접근 방식은 "이해"입니다. 도구는 레거시 응용 프로그램에 대한 자세한 이해를 제공합니다. 유지 보수, 문서화 또는 새로운 플랫폼에서 재창조에 사용할 수 있습니다.

나는 조금 알고있다 현대화 워크 벤치 Microfocus 이전의 역사는 작년에 그것을 사서 개발을 다른 나라로 옮겼습니다. 많은 복잡한 분석 도구와 지원되는 대상 언어 수 (Java 포함)가있었습니다. 그러나 클라이언트는 실제로 자동 코드 생성을 사용한 클라이언트가 없으므로 생성 부분의 개발이 동결되었습니다. 내가 아는 한 PL/I 지원은 대부분 구현되었지만 결코 끝나지 않았습니다. 그러나 여전히 당신은 시도 할 수 있습니다. 이것이 당신이 찾고있는 것일 수 있습니다.

방금 NACA 페이지와 문서를 보았습니다. 그들의 문서에서 :

"생성 된 Java는 COBOL과 같은 구문을 사용합니다. 물론 Java 언어의 한계는 원래 Cobol 구문과 최대한 가깝습니다. 생성 된 코드는 고전적인 기본 Java처럼 보이지 않으며 응용 프로그램 지점에서 객체가 아닙니다. 이것은 디자인으로 강력한 선택으로 COBOL 개발자를 Java 환경으로 원활하게 마이그레이션 할 수 있도록합니다. 목표는 원래 COBOL 프로그램을 작성한 사람들의 손에 비즈니스 지식을 유지하는 것입니다. "

나는 예를 보지 못했지만 인용문은 결과의 강한 맛을줍니다. Cobol은 Java로 코딩되었습니다.

대상 Langauge의 통역사를 단순히 코딩함으로써 언제든지 "번역기"를 한 언어에서 다른 언어로 구축 할 수 있습니다. 그것은 당신이 두 세계의 최악의 상황으로 끝날 때 랑고지를 번역하는 절대적으로 끔찍한 방법입니다. 당신은 새로운 언어의 가치를 얻지 못하며, 결과를 살리기 위해 오래된 사람에 대한 지식이 있어야합니다. (이 점이 "트랜스 코더"라고 불리는 것은 당연합니다. 나는이 용어를 전에 들어 본 적이 없습니다).

이 스턴트에 대한 논쟁은 메인 프레임의 비용을 덤프하는 것입니다. 전환 된 프로그램 작업 비용이 저축을 늪에 빠지지 않는다는 증거는 어디에 있습니까? 진실은 사람들이 메인 프레임을 버림으로써 사람들이 비용을 낮추고 유지 보수 작업이 더 비싸다는 것을 신경 쓰지 못한다고 생각합니다. 그것은 운영자들에게 합리적 일 수 있지만, 전체적으로 orgnization을위한 어리석은 선택입니다.

천국은이 도구의 희생자 인 사람들을 돕습니다.

2010 년 5 월 편집 : NACA의 출력의 예를 찾았습니다. 하나의 그들의테스트 케이스. 이것은 절대적으로 웅장한 Jobol입니다. 그들이 좋은 것입니다 유지 그들의 COBOL 프로그래머는 Java 프로그래머를 고용하고 싶지 않습니다. 이것을 읽었 듯이, 당신이 이것을 기억하십시오 자바 암호.

/*
 * NacaRTTests - Naca Tests for NacaRT support.
 *
 * Copyright (c) 2005, 2006, 2007, 2008 Publicitas SA.
 * Licensed under GPL (GPL-LICENSE.txt) license.
 */

import idea.onlinePrgEnv.OnlineProgram;
import nacaLib.varEx.*;

public class TestLong extends OnlineProgram
{
  DataSection WorkingStorage = declare.workingStorageSection();

  Var W3 = declare.level(1).occurs(10).var();
  Var V9Comp010 = declare.level(5).pic9(10).var();
  Var V9Comp014V4 = declare.level(5).pic9(14, 4).var();
  Var VX10 = declare.level(5).picX(10).var();

  public void procedureDivision()
  {
    setAssertActive(true);

    move("9876543210", VX10);
    assertIfDifferent("9876543210", VX10);

    move(VX10, V9Comp010);
    long l = V9Comp010.getLong();
    assertIfFalse(l == 9876543210L);

    multiply(1000, V9Comp010).to(V9Comp014V4);
    assertIfFalse(9876543210000L == V9Comp014V4.getLong());

    String cs = V9Comp010.toString();
    cs = V9Comp014V4.toString();
    assertIfDifferent("9876543210000.0000", V9Comp014V4);

    inc(V9Comp010);
    assertIfFalse(9876543211L == V9Comp010.getLong());

    CESM.returnTrans();
  }

어린이 : 이것은 전문가들에 의해서만 이루어집니다. 집에서 이것을 시도하지 마십시오.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow