C ++에서 IBM 어셈블러 + COBOL 재 작성

저는 1972 년에 작성된 렌탈 시스템에서 운영되는 렌터카 회사의 렌탈 에이전트 / 관리자로 일하고 있습니다. 업데이트가 필요한 시점이라고 생각했습니다. 약간의 배경 지식을 위해 다음은이 프로그램에서 매일 처리해야하는 광기의 예입니다.

임대 대행사는 한 화면에 인쇄 할 때 ACT 필드에서 "MXC"(모든 것이 짧은 코드를 기반으로 함)를 사용한다는 것을 기억해야합니다.이 코드는 "계약의 MaXimum 표시"를 의미하며, 다른 화면에서는 PR (프린트)이 필요합니다. ACTION 필드이지만 PT (PrinT의 경우) 필드에서 Y를 사용하는 화면이 있지만 PRT (PrinT의 경우) 필드에서 Y를 사용하는 화면이 있지만 다른 화면에서는 사용자가 Enter 키를 눌러야합니다. 문자는 줄 바꿈 문자이므로 숫자 패드에 입력해야합니다.) F8은 다르지만 관련 화면에는 단순히 F8이 필요합니다. 일부 화면에는 PRT라는 필드가 있으며 일부 필드에는 PRinT에 대한 필드이지만 실제로는 필드입니다 여러 프롬프트를 수행 한 후 아무 것도 수행하지 않고 인쇄가 자동으로 수행되며 더 많은 화면에 PRINT Y / N이라는 레이블이 지정된 필드가 있습니다.다른 위치에서 이미 서류 작업을 수행하는 작업의 경우 기본적으로 Y로 기본 설정되고 다른 딜러가 서류 작업이 필요한 작업의 경우 N으로 기본 설정됩니다.

나는 이것보다 더 나은 일을 할 수 있다고 결정했기 때문에 이것을 업데이트하기로 결정한 회사의 담당자에게 연락하기 시작했습니다. 결국이 프로그램을 담당하는 IT 부사장을 만나게됩니다. 나는 그에게서 약간의 정보를 얻었고, 내 렌터카 회사는 약간의 COBOL이 혼합 된 IBM 메인 프레임 어셈블러로 작성된 렌탈 프로그램을 가지고 있음을 알게되었습니다. 그는 현재 포지션이 없지만 오픈해야한다고 말합니다 어쨌든 내 이력서를 이메일로 보내십시오.

이것은 내 질문으로 이어집니다.

첫 번째는 기술입니다. 앞으로 유지 관리 성을 향상시키려는 생각으로 어셈블리 언어보다 더 높은 수준의 언어로 다시 작성하는 것이 좋습니다. 내 경험 영역은 C ++에 있으므로 분명한 선택입니다. 내가 최근에 내가 말한 사람이 팀이 열심히 일했다고 말한 기사를 읽었으므로 회사는 프로그램을 쉽게 업데이트 할 수있는 더 쉬운 방법이 절실히 필요합니다. 그들은 프로그램이 현재 5를 지원한다고 발표하게 된 것을 자랑스럽게 생각합니다 -4 자리가 아닌 숫자 위치 코드와 7 자리가 아닌 8 자리 차량 번호. 심지어 상황이 긴박한에서 업데이트에 대한 나의 철학은, 조엘의 라인에 있습니다 : http://www.joelonsoftware.com/articles/fog0000000069.html 즉, 다시 쓰기 전에이 있었다 오히려 모든 것을 던지는보다 증가해야한다 그리고 신선한 시작.

IBM 어셈블리를 C ++와 쉽게 통합 할 수있는 방법이 있습니까? 그렇다면 어떻게해야합니까? 나는 asm 키워드를 모호하게 알고 있지만 그것을 사용하거나 다른 것을하는 것이 최선인지는 모르겠습니다. 그러한 계획은 잘못된 조언입니까? 나는 g ++과 GNU make를 사용하여 Linux에서 대부분의 작업을 수행하므로 특정 답변을 환영하지만 반드시 필요한 것은 아닙니다 (어떤 종류의 빌드 시스템이 없는지 전혀 모르지만 거의 아무것도 의심하지 않기 때문에).

두 번째 질문은 더 정치적입니다. 이 회사가 전환을해야한다고 설득하려면 어떻게해야합니까? 이론적 인 비용 절감은 엄청납니다 (제 추정에 따르면 회사는 매년 백만 달러 정도를 낭비하고 프로그램과 상호 작용하는 방법을 배우기 위해 교육 비용이 증가했기 때문에). 현행 프로그래머들이 제정되어야한다면, 변화에 대한 구조적 저항이 크다.

편집 : 왜 회사가 이미 가지고있는 것을 수정하는 것이 나에게 가장 좋은 해결책처럼 보이는지 설명해야합니다. 그러나 이것은 여전히 ​​다른 제안에 열려 있습니다. 왜냐하면 이것이 프로그램의 괴물이기 때문입니다. 이전에 프로그래밍 작업을 한 번도 해 본 적이 없으므로 잘못된 분석을 수행하여 수정 해주세요.

먼저, 상용 솔루션이 있습니다.

이런 종류의 일에 대해 몇 가지 중간급 관리자와의 대화에서 새로운 시스템으로 전환하는 데 대한 주요 관심사 중 하나는 수십 년 동안 회사에 있었으며 지금까지 시스템에 익숙한 많은 충성스러운 직원입니다. . 우리가 가진 것을 수정할 수 있다면 현재의 인터페이스를 일종의 '호환성 모드'로 유지할 수 있습니다. 사용자는 현재 시스템을 사용하기 위해 이미 로그인해야하므로 사용자가 '변경'후 처음으로 로그인 할 때 설정을 활성화하는 기능을 추가 할 수 있습니다. '클래식'인터페이스 또는 '새'인터페이스 이를 가능하게하는 상용 솔루션을 찾을 수있는 방법은 없습니다.

우리 회사는 또한 우리가 사용하는 소프트웨어를 소유합니다. 우리는 그것을 라이센스하지 않습니다. 이것은 내가 현재 말하고있는 경영진이 실제로 변경을 승인 할 수있는 사람들과 동일하다는 것을 의미합니다. 타사 솔루션을 사용하면 회사에서 제품을 개발 한 회사에서 필요한 모든 권리를 확보하는 것 외에도 회사의 승인을 얻어야합니다. 이것은 또한 회사가 "그들의"제품을 포기하고 다른 제품을 가져 가도록 설득해야 할 것인데, 이는 우리가 가진 것을 업데이트하려고 시도하는 것보다 더 큰 장애물처럼 보이지만이 문제에 대해서는 틀릴 수 있습니다.

마지막으로 미래를 살펴보면 사용자 인터페이스를 개선하고 몇 가지 버그를 수정하고 싶지 않습니다. 이러한 '긴급한'문제를 업데이트 한 후 기술과 관련하여 회사가 운영하는 기본 방식을 업데이트하기를 희망했습니다. 이러한 종류의 문제에 1-2 년을 소비 한 후 저의 계획은 경영진으로 돌아가 더 극적인 변화를 제안하는 것이 었습니다. 회사가 운영하는 많은 방법들이 현재 사용하지 않는 기술에 의해 근본적으로 개선 될 수 있습니다. 예를 들어, 각 지역은 거의 같은 방식으로 작동합니다. 지역의 주요 공항은 자동차를 배포하는 중앙 허브입니다. 그들은 주로 필요에 따라 보내집니다. 그러나 공항은 모든 운영의 본거지로 사용됩니다. 차 한 대에 두 사람을 내 위치로 보내서 필요없는 차 한 대를 가져옵니다. 그런 다음 그들이 들어온 차와 함께 공항으로 돌아갑니다 (우리는 공항에서 32 마일 거리). 그런 다음 두 대의 차에서 5 마일 떨어진 위치로 와서 그 중 하나를 내린 다음 다른 차를 공항으로 반환합니다. 우리가 돌려 보낸 차가 우리 근처에 필요한 것과 같은 종류의 차인 경우에도 이렇게합니다. 나는 약 2 년 동안 회사와 함께 일해 왔으며, 자동차 부족이 가장 극심한 상황 (그러므로 3 배 정도)에서만이 상황에서 벗어나는 것 같습니다. 나는 모든 지역에서 일하는 4 명의 사람들을 자동차가 어디로 갈지 결정하고 자동으로 예약 시스템을 사용하여 가장 필요한 시간 + 마일 + 드라이버가 필요한 경로를 찾아서 더 높은 수준의 수정의 예 언젠가 추가하고 싶습니다.

그러나이 모든 것을 제안하는 것이 편안해지기 전에 인터페이스 업데이트와 같은 작은 작업을 수행하여 회사와 코드베이스에서 발판을 얻는 것이 도움이 될 것이라고 생각합니다. 아웃소싱과 같은 솔루션은 이러한 가능성을 제거합니다.

자신을 기술적 인면에 국한시키는 것 ...

응용 프로그램이 실행되는 환경을 결정하는 것으로 시작하는 것이 좋습니다. "메인 프레임"은 응용 프로그램의 연령에 따라 CICS 또는 IMS 일 수있는 몇 가지 다른 것을 의미 할 수 있습니다 . 원저자가 자신의 시작된 작업을 썼을 수도 있습니다.

애플리케이션이 실행되는 위치에 따라 해당 환경에서 API를 사용할 가능성이 높으므로 CICS는 이제 초기와 현저하게 다른 인터페이스를 사용하므로 IMS를 말할 수 없습니다. 응용 프로그램이 자체 시작된 작업 인 경우 자체 내부 API가있을 수 있습니다. 같은 시대에 작성된 이러한 짐승을 지원하는 데 약 7 년이 걸렸습니다.

응용 프로그램의 수명을 고려할 때 고려해야 할 다른 사항은 C ++을 통합하려는 어셈블러가 언어 환경 (LE) 의 존재보다 앞서 있다는 것입니다 . 따라서 어셈블러가 LE를 준수하도록 업데이트되지 않은 경우 C 및 C ++가 LE를 준수하고 발신자와 수신자도 준수해야하기 때문에 약간의 어려움이 있습니다.

고려해야 할 또 다른 요점은이 응용 프로그램이 기록적인 메인 프레임에서 실행중인 경우 지원되지 않는 하드웨어 및 소프트웨어에서 실행되는 응용 프로그램과 통합하려고 할 수 있습니다. 이것은 원래 하드웨어의 DOS 4.01에서 실행되는 1989 년에 작성된 응용 프로그램과 통합하려는 것과는 다릅니다.

당신은 총을 뛰고 있습니다. 설명에서 현재 기술 환경을 정확히 이해하지 못한 것 같습니다 (OS가 정확히, 어디에, 어떻게 데이터가 저장되어 있는지, 다른 시스템에 대한 인터페이스가 있는지 등). 그러나 더 중요한 것은 진지한 계획은 소프트웨어의 부분 또는 전체 사내 재 작성에 대한 대안, 즉 상용 소프트웨어, 재 작성 아웃소싱, 서비스로서의 소프트웨어 등을 고려해야합니다.

회사가 어떤 방식으로 진행하든 먼저 오늘날 소프트웨어의 기능과 새로운 솔루션에 대한 요구 사항에 대한 확실한 분석이 필요합니다.

그렇다면 왜이 분석을 제안하지 않습니까?

정중 한 반응을 보니 놀랍습니다!

그들의 관점에서 이것을 보자.

그들은 아마도 수십만 줄의 코드로 30 년 된 시스템을 성공적으로 관리하고 40 년 동안 발전한 비즈니스 프로세스를 구현하는 20 개의 다른 시스템과 인터페이스 할 수 있습니다.

이들은 아마도 해당 분야의 전문가 일 것이므로 C ++을 IBM의 "High Level Assembler Language"에서 단계적으로 내리는 것으로 간주합니다. IBM의 어셈블러 언어는 매우 강력하며 "MACRO"언어는 전처리 / 템플릿 언어 중 최고의 구현입니다.

시스템이 처음 구현 된 후 약 5 년마다 시스템을 교체하라는 제안이있을 것입니다. 일부는 타당성 조사 후 거부되었을 수도 있고, 일부는 예산을 잃기 전에 설계 단계까지 도달했을 수도 있고, 일부는 성능 문제를 겪고 통조림을 얻기 전에 코드 및 테스트 단계에 도달했을 수도 있습니다.

C ++은 단순히 도움이되지 않습니다. 응용 프로그램이 실행되는 환경에는 그래픽 라이브러리가 없습니다. (3270 그래픽 라이브러리가 있지만 아무도 사용하지 않으므로 C ++에서 지원되지 않을 것입니다. 전체 "X"클라이언트 라이브러리가 있지만 사용하려면 다른 환경에 있어야합니다.

그것들은 완벽하지는 않지만 잘 알려져 있고 빠른 사용자 인터페이스를 가지고 있습니다. 숙련 된 운영자는 동등한 GUI가 아닌 녹색 화면을 사용하여 약 3 배 더 빠르게 양식을 작성합니다. 또한 그들은 접촉하는 동안 고객에게주의를 기울일 수 있습니다.

스크린 운영자는 어떤 인터페이스를 사용하든 교육이 필요합니다. 직원이 새롭고 익숙하지 않은 GUI를 사용하도록 재교육하면 구식 시스템에서 새 직원을 교육하는 것보다 막대한 예산 항목이 될 것입니다.

몇 년 전 BellSouth에서도 비슷한 문제가있었습니다. COBOL 코드를 작성하여 어셈블러 언어 프로그램을 바이트 단위로 스캔하고 opcode와 피연산자를 분리하고 분기 명령어를 to로 변환하고 비교 명령어를 IF로 변환하는 COBOL 코드를 작성했습니다. 이 프로그램은 DC 명령어를 동등한 COBOL Data Division 코드로 변환하고 적절하게 이동, zaps 등을 변환했습니다.

이 작업이 완료되면 IF와 GOTO를 IF-THEN으로 변환하는 두 번째 프로그램을 작성했습니다. 이러한 클러스터 사이의 행과 같은 행으로 이동했습니다. 1 단계 "pidgin"코볼을 처음부터 끝까지 다시 읽을 때 ELSE).

IF-THEN-ELSER는 레이블에 근접하여 GOTO 참조를 찾은 상황을 찾아서 안전하게 삭제할 수 있습니다 (참조 수를 1 씩 줄임). 이 IF-THEN-ELSER 프로그램을 반복적으로 실행합니다 (즉, 마지막 패스가 더 이상 변경 방법을 찾을 수 없을 때만 중지하고 반복해서 실행 함). 대부분의 중요한 작업은이 if-then-elser가 수행합니다.이 if-then-elser는 숙련되고 유능한 어셈블러 언어 프로그래머 (즉, 저)가 COBOL 제품을 신중하게 검토하고 조사해야합니다. 내 경험상 "if-then-elser"는 원래 지점 명령으로 인한 GO TO의 90 % 이상을 제거 할 수있었습니다.

나는이 시점에서 C (또는 C ++)로 직접 변환하여 나아갈 수 있다고 생각합니다. 그러나 BellSouth의 목표 언어는 COBOL / II였습니다. 남은 레이블에 여러 개의 GO TO 참조가있는 상황에서 항상 약간의 복잡성이 발생합니다 (많은 경우 이러한 상황은 COBOL PERFORM에 의해 처리되지만 때로는 OR 및 AND 구문으로 간단히 표시 될 수 있음).

EVALUATE (Case constructs)와 88 레벨 조건 이름을 사용하여 우아하게 블록 구조의 COBOL / II로 코드를 생성하는 것이 좋습니다. 이러한 마무리 터치를 추가하면 또 다른 프로그램 쌍이 생겨 어셈블러에서 변환 된 프로그램에서 생성되지 않은 COBOL 프로그램에 유용합니다.

이것이 도움이되는지 모르겠습니다.

위의 다른 사람들이 언급했듯이이 프로세스는주의해서 수행해야합니다. 의사 결정 프로세스를 알리는 10-12 년의 어셈블러 코딩 경험을 보유하는 데 도움이됩니다. 그 경험을 가진 우리는 더 이상 찾기가 어렵습니다.

마지막으로 우리는 고급 언어의 컴파일러가 번거롭고 비효율적 인 객체 코드를 생성했기 때문에 어셈블러로만 작성했습니다. 오늘날의 "최적화"COBOL 컴파일러에는 그와 같은 나쁜 습관이 없습니다. ----------

Joel의 조언은 일반적으로 건전하지만이 경우 완전한 재 작성은 기한이 지났습니다. 이상적으로, 여기서 다루는 것은 괴물이기 때문에 전장으로 다시 작성하십시오.

이미 추가 할 내용이 확실하지 않습니다. 이미 다시 작성에 대한 꽤 좋은 주장을 했으므로. 내 유일한 권장 사항은 C ++을 완전히 건너 뛰고 임대 시스템의 웹 인터페이스로 바로 이동하는 것입니다. 아마도 작업자를 훈련시키는 것이 더 쉬울 것이므로 UI에 대한 많은 작업을 줄일 수 있습니다. 프로젝트에서 새로운 피를 얻거나 심지어 모든 것을 아웃소싱하는 것이 훨씬 쉽습니다).

기존 COBOL 프로그래머는 기존 시스템을 문서화하고 마이그레이션 프로세스를 도와 줄 수 있습니다.

기술적 인 측면에서 많은 부분은 어셈블러 코드의 품질 (모듈화)에 달려 있습니다. 일부 프로그래머는 표준 IBM 서브 루틴 링크 규칙을 사용하여 특정의 제한된 기능과 명확하고 간단한 매개 변수화 된 인터페이스로 모듈을 작성하는 것이 중요하다는 것을 이해했습니다. 그러나 대다수는 모 놀리 식 괴물을 만드는 경향이 있었다.

전자를 사용하면 재사용이 가능하며 어셈블러 모듈이 표준 (또는 적어도 일관된) 호출 시퀀스를 사용한다고 가정하면 C ++과 어셈블러 사이의 "접착제"를 해결하는 것이 어렵지 않아야합니다. 그러나 어쩌면 어셈블러 코드는 혼란 스러울 것입니다. 그것이 비록 가능 쓰기 구성 어셈블러에, 아주 소수의 사람들이 한, 어떤에서 다시 쓰기 시작하는 어떤 "디자인"을 분별하는 것은 거의 불가능하다.

반면에, 360/370 어셈블러는 오늘날의 마이크로 프로세서에 비해 상당히 높은 수준이며 훨씬 더 단순하며 C는 때때로 "고수준 어셈블러"로 간주됩니다. 나는 제품이 완전히 370 개의 어셈블러 인 DBMS 회사에서 일했고, 우리의 주요 설계자는 어셈블러 코드를 C로 기계 번역 할 수 있다고 믿었습니다 (향후 이식성을 위해). 나는 회의적이지만 요점은 당신이 생각하는 것만 큼 거리가 크지 않다는 것입니다.

이 중 어떤 것이 도움이되는지 모르겠습니다. 내가 말했듯이 원래 코드의 품질과 크기에 크게 의존한다고 생각합니다.

이것이 장난인지 아닌지는 알 수 없습니다. 귀사는 원래 39 년 전에 작성된 코드를 심각하게 실행하고 있습니까? System / 360에서 실행중인 경우 소스에서 g ++를 컴파일해야합니다.

솔직히, 나는 이전 코드를 사용하는 것에 대해 생각조차하지 않을 것입니다. 새로운 접근 방식을 취하고 앉아 디자인에 필요한 것을 생각하고 처음부터 끝까지 수행해야합니다. 그렇습니다. 계획에는 약간의 계획이 필요하지만 Joel조차도 이것이 점진적인 변화의 경우라고 생각하지 않습니다.

전환해야하는 회사를 설득하려면 효율성을 개선하고 비용을 낮추며 현재 사용중인 제품이 지금 수익에 약간의 해를 끼치고 있다는 구체적인 이유 를 지적해야합니다 .

또 다른 의견-다른 렌터카 회사가 21 세기에 우리와 함께했다고 생각합니다. 나는 그들이 어떻게하고 있는지 (웹 기반, 상상), 약간의 정찰을 수행하고 아마도 그 시스템 중 하나를 따라 모델을 모델링 할 것입니다 (즉, 바퀴를 재발 명하지 마십시오).

행운을 빕니다!

이론적으로 이전 시스템을 교체하도록 상위 경영진에게 설득시키는 것이 어렵지 않아야합니다. 그리고 그렇습니다. 이 시스템을 유지할 프로그래머를 찾는 것이 점점 더 어려워 질 것이며, 그 프로그래머는 점점 더 비싸 질 것입니다. "if"의 문제가 아니라 "when"의 문제입니다. 실제로 업데이트해야합니다.

그러나 문제는 업데이트가 필요하다는 것뿐만 아니라 사내 프로젝트 여야한다는 것을 납득시킬 수 있는지 여부입니다. 특히 팀이 당신이라면. 종종 이러한 주요 대체품이 아웃소싱됩니다. 고려할만한 기성품 소프트웨어가있을 수도 있습니다. 이러한 옵션을 조사해야하며 관리자가 합리적인 경우 이러한 상황이 발생한다고 주장합니다.

작업에 관해서는 실제로이 경우 불도 즈 다시 쓰기가 적합하다고 생각합니다. Joel의 주장은 모든 경우에 적용되는 것은 아닙니다. 그러나 나는 그것을 보지 않고는 정말로 알 수 없었다.

1. 점진적인 변화는 의문의 여지가 없습니다.

2. 사용 가능한 상용 솔루션이있을 수 있습니다. 많은 렌터카 업체가 있습니다.

3. 마지막 수단으로 다시 작성해야하는 경우 먼저 새 시스템의 작동 방식에 대해 생각하십시오.
   기능과 인터페이스를 식별 한 후에는 필요 (및 기술)에 가장 적합한 개발 도구를 선택할 수 있습니다.

최종 사용자의 스트레스를 최소화하기위한 한 가지 전략은 추악한 니모닉에 대한 드롭 다운 목록과 같은 몇 가지 기능을 통해 사용자가 알고있는 오래된 추악한 인터페이스를 모방 한 다음 점차 UI 기능을 추가하여 현대적인 UI에 추가하는 것입니다.

동일한 데이터 파일 형식을 유지하고 싶지 않으므로 전환 한 후에는 되돌아 갈 수 없습니다.