Опыт, перемещающий Cobol/PL1 прежней версии в Java

Я не знаю, как была ситуация, когда этот вопрос был впервые задан и получен ответ, но RxJava в настоящее время содержит вспомогательный метод для этой конкретной цели: Exceptions.propagate(Throwable t)

RxJava Javadoc

Удобный метод для прямого выброса RuntimeException и Error или включения любого другого типа исключения в RuntimeException.

5
задан MadMurf 6 July 2009 в 23:24
поделиться

6 ответов

Обновление от 25 июня: Друг только что наткнулся на NACA конвертер Cobol в Java. Выглядит довольно интересно, с его помощью со 100% точностью транслировались 4-х метровые строки Кобола. Вот страница проекта с открытым исходным кодом NACA . Другие преобразователи, которые я видел, были проприетарными, и в материалах явно не хватало историй успеха и подробных примеров кода. NACA заслуживает пристального внимания.

Обновление 7/4: @Ira Baxter сообщает, что выходные данные Java выглядят очень похожими на Кобола, что совершенно верно. Для меня это естественный результат автоматического перевода. Я сомневаюсь, что мы когда-нибудь найдем намного лучшего переводчика. Это, возможно, является аргументом в пользу постепенного подхода к переписыванию.

Обновление 2/7/11: @spgennard указывает, что на JVM есть некоторые компиляторы Cobol, например, Veryant isCobol Evolve . Их можно было бы использовать для постепенного перехода к базе кода, хотя я думаю, что ОП больше интересовало автоматическое преобразование исходного кода.


Я бы был очень осторожен с этим. (Раньше я работал в компании, которая автоматически исправляла программы Cobol и PL / I для Y2K, а также создавала внешний компилятор, который преобразовывал многие диалекты Cobol в нашу промежуточную аналитическую форму, а также генератор кода. Я считаю, что вы закончите с базой кода Java, которая все еще была бы неэлегантной и неудовлетворительной для работы. Вы можете столкнуться с проблемами производительности, зависимостями от поставляемых поставщиком библиотек, сгенерированным кодом, который содержит ошибки, и так далее. Вы, безусловно, понесете огромный счет за тестирование.

Начинать с нуля с новым объектно-ориентированным дизайном может быть правильным подходом, но вы также должны внимательно учитывать десятилетия накопленных знаний, представленных базой кода. Часто ваш новый код может упустить множество тонкостей. С другой стороны, если вы Если вам сложно найти персонал для обслуживания унаследованной системы, у вас может не быть выбора.

Одним из постепенных подходов может быть первое обновление до Cobol 97. Это добавляет объектно-ориентированность, так что вы можете переписывать и реорганизовывать подсистемы индивидуально, когда вы добавляете новую функциональность. Или вы можете заменить отдельные подсистемы только что написанной Java.

Иногда вы сможете заменить компоненты готовым программным обеспечением: мы помогли одной очень крупной страховой компании, у которой все еще было 2 миллиона строк кода на устаревшем языке, созданном в 1950-х годах. Мы перевели половину из этого на устаревший язык, совместимый с проблемой 2000 года, а они заменили вторую половину современной системой расчета заработной платы, которую купили у внешнего поставщика.

Это добавляет объектно-ориентированность, так что вы можете переписывать и реорганизовывать подсистемы индивидуально при добавлении новых функций. Или вы можете заменить отдельные подсистемы только что написанной Java.

Иногда вы сможете заменить компоненты готовым программным обеспечением: мы помогли одной очень крупной страховой компании, у которой все еще было 2 миллиона строк кода на устаревшем языке, созданном в 1950-х годах. Мы перевели половину из этого на устаревший язык, совместимый с проблемой 2000 года, а они заменили вторую половину современной системой расчета заработной платы, которую купили у внешнего поставщика.

Это добавляет объектно-ориентированность, так что вы можете переписывать и реорганизовывать подсистемы по отдельности при добавлении новых функций. Или вы можете заменить отдельные подсистемы только что написанной Java.

Иногда вы сможете заменить компоненты готовым программным обеспечением: мы помогли одной очень крупной страховой компании, у которой все еще было 2 миллиона строк кода на устаревшем языке, созданном в 1950-х годах. Мы перевели половину из этого на устаревший язык, совместимый с проблемой 2000 года, а они заменили вторую половину современной системой расчета заработной платы, которую купили у внешнего поставщика.

мы помогли одной очень большой страховой компании, у которой все еще было 2 миллиона строк кода на устаревшем языке, созданном в 1950-х годах. Мы перевели половину из этого на устаревший язык, совместимый с проблемой 2000 года, а они заменили вторую половину современной системой расчета заработной платы, которую купили у внешнего поставщика.

мы помогли одной очень большой страховой компании, у которой все еще было 2 миллиона строк кода на устаревшем языке, созданном в 1950-х годах. Мы перевели половину из этого на устаревший язык, совместимый с проблемой 2000 года, а они заменили вторую половину современной системой расчета заработной платы, которую купили у внешнего поставщика.

7
ответ дан 18 December 2019 в 08:30
поделиться

Мой опыт похож, но немного отличается. У нас есть большая и старая кодовая база на Аде (0,5 МБ за 15+ лет), которая недавно была преобразована в Java. Он был передан на аутсорсинг компании, которая обеспечивала комбинацию автоматического / ручного преобразования. Они также провели тестирование, чтобы убедиться, что системы Ada и Java ведут себя одинаково.

Некоторые его части были написаны на Ada 95 (т.е. имели возможность ООП), но большая часть этого не была.

Теперь да, код изначально не соответствует тем же стандартам кода, написанного на Java, но с тех пор мы успешно используем его (уже 18 месяцев) без каких-либо серьезных проблем. Основным преимуществом, которое мы получили, было то, что теперь мы можем найти больше разработчиков для поддержки нашей кодовой базы, обладающих навыками создания поддерживаемого кода. (Любой язык может развиваться на Аде, но, как и любой другой язык, если у вас нет опыта работы с ним, вы можете получить неподдерживаемый код)

2
ответ дан 18 December 2019 в 08:30
поделиться

I just looked at the NACA page and docs. From their documentation:

"The generated java uses a Cobol-like syntax. It's as close as possible from original Cobol syntax, within of course the limits of the Java language. Сгенерированный код не похож на классическую нативную java и не является объектно-ориентированным с точки зрения приложения. Это продуманный выбор, обеспечивающий плавную миграцию разработчиков Cobol в среду Java. Цель состоит в том, чтобы сохранить бизнес-знания в руках людей, которые написали оригинальные программы Cobol ».

Я не видел примера, но цитата дает сильное представление о результате. Его COBOL закодирован на Java.

Вы всегда можете создать «Переводчик» с одного языка на другой, просто кодировать интерпретатор на целевом языке. Это ИМХО абсолютно ужасный способ перевести язык, поскольку вы в конечном итоге худшее из обоих миров: вы не понимаете ценности нового языка, и вам все еще нужно знать старую, чтобы сохранить результат alive. (No wonder this thing is called a "Transcoder"; I'd never heard this term before).

The argument for this stunt is to dump the costs of the mainframe. Where's the evidence that the costs of working on the converted program don't swamp the savings? I suspect the truth is that the operations people lowered their cost by dumping the mainframe, and they couldn't care less that the maintenance tasks got more expensive. While that may be rational for the operations guys, its a stupid choice for the orgnization as a whole.

Heaven help people that are a victim of this tool.

EDIT May 2010: I found an example of NACA's output; one of their testcases. This is absolutely magnificent JOBOL. Its a good thing they are keeping their COBOL programmers and don't want to hire любые Java-программисты. Читая это, обязательно помните это код 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();
  }

Дети: Это делают только профессионалы. Не пытайтесь сделать это дома.

1
ответ дан 18 December 2019 в 08:30
поделиться

Мы явно намеревались получить исходный код Java, который был очень близок к исходному коболу, чтобы облегчить миграцию людей: они находят старое доброе приложение, которое они написали на коболе, точно так же структура.

одной из наших самых важных целей было удержать первоначальных разработчиков на борту: именно так мы нашли способ ее достичь. Когда приложение переходит на Java, эти люди могут начать делать его больше объектно-ориентированного подхода по мере его дальнейшей разработки / рефакторинга.

Если вас не волнует миграция людей, вы можете использовать другую стратегию.

Это 1-к-1 преобразование также сделало 100% автоматическое преобразование более простым и быстрым: хорошим последствием является то, что мы значительно ускорили периодическую экономию (3 миллиона евро в год): по нашим оценкам, 12-18 месяцев. Эти ранние сбережения, несомненно, могут быть реинвестированы в объектно-ориентированный рефакторинг

, не стесняйтесь обращаться ко мне:didier.durand@publicitas.com или mediaandtech@gmail.com

didier

4
ответ дан 18 December 2019 в 08:30
поделиться

С точки зрения предотвращения риска подход NACA абсолютно имеет смысл. Повторное использование их инструментов не может. Они использовали разработку инструментов, чтобы научить своих людей работать с Java и Linux.

Результат преобразования NACA не будет достаточно хорошим, или даже объектно-ориентированным, что затрудняет найм новых людей. Но он поддается тестированию, может быть подвергнут рефакторингу, и вы можете подключить более качественные переводчики.

[править] Ира, похоже, ты не особо опасаешься.

Посылка программистов на коболе на курс java не заставит их писать пригодный для использования объектно-ориентированный код. Это займет несколько лет. В течение этого времени их продуктивность будет очень низкой, и вы можете выбросить весь код, который они написали в первый год. Вдобавок вы потеряете 10-20% ваших программистов, которые не хотят или не могут осуществить переход. Многим людям не нравится возвращаться к статусу новичков, и это повлияет на иерархию, поскольку некоторые программисты осваивают новый язык намного быстрее, чем другие.

Подход NACA позволяет бизнесу продолжать работать, и не оказывает ненужного давления на организацию. График конверсии не зависит. Имея отдельный переводчик на java, написанный специалистами по объектно-ориентированному программированию, позволяет старой команде постепенно знакомиться с java. Написание тестовых примеров расширяет знания в предметной области в новой команде java.

Настоящая система oo - это переводчик, и это место, где можно подключить лучших переводчиков. Сделайте это легко, и вам не нужно прикасаться к сгенерированному коду. Если сгенерированный код достаточно уродлив, это произойдет автоматически:)

  • старые программисты изменят ввод cobol;
  • новые java изменят транслятор.

[запускает переводчик один раз] это плохая стратегия. Не делай этого. И если вам нужно отредактировать сгенерированный код, сохраните отображение обратно. Это можно автоматизировать. Так и должно быть. В образе Smalltalk такие вещи делать намного проще, но вы можете делать это с файлами. Есть люди с большим опытом, поддерживающие разные взгляды на один и тот же артефакт: на ум приходят разработчики микросхем.

Транслятор должен быть оснащен инструментами, чтобы вы могли ежедневно подсчитывать, например,

  • входных компонентов кобола;
  • OO компоненты ввода java;
  • компоненты вывода стиля cobol;
  • компоненты вывода стиля OO.

Возможно, вы захотите прочитать: Питер ван ден Хамер и Кейс Лепоэтер (1996) Управление данными проектирования: пять измерений структур САПР, управление конфигурацией и управление данными, Труды IEEE, Vol. 84, No. 1, январь 1996 г.

[движущиеся платформы Cobol] Переход с Cobol на мэйнфрейме на Cobol на Windows / Linux мог быть жизнеспособной стратегией для команды NACA, но вопрос был о переходе на java. Если долгосрочная цель состоит в том, чтобы иметь современную систему OO и достичь ее с минимально возможным операционным риском, подход NACA является разумным. Однако это только первый шаг. За этим последует большой объем рефакторинга.

2
ответ дан 18 December 2019 в 08:30
поделиться

Вы говорите о реинжиниринге . Хорошо то, что многие люди во всем мире пытаются это сделать. Плохо то, что существует множество проблем, связанных с реинжинирингом унаследованных приложений: начиная с недостающих исходных текстов и заканчивая сложными алгоритмами от построения компилятора и полей теории графов.

Идея автоматического перевода очень популярна, пока вы не попытаетесь преобразовать что-то. Обычно результат ужасен и недостижим. Это труднее поддерживать, чем оригинальное сложное приложение. С моей точки зрения, каждый инструмент, который позволяет выполнять автоматический перевод с устаревшего языка на современный, очень ориентирован на маркетинг: он говорит именно то, что люди хотят услышать: «Переведите свое приложение с ... на Java один раз и забудьте!», Чем вы. покупка контракта, и тогда вы понимаете, что вы очень сильно зависите от инструмента (потому что вы не можете вносить какие-либо изменения в свое приложение без него!).

Альтернативный подход - «понимание»: инструмент, который позволяет вам очень детально понять ваши устаревшее приложение. И вы можете использовать его для обслуживания, или для документирования, или для переосмысления на новой платформе.

Я немного знаю историю Modernization Workbench до того, как Microfocus купила его в прошлом году и перенесла разработку в другую страну. Было большое количество сложных инструментов анализа и количество поддерживаемых целевых языков (включая Java). Но ни один клиент не использовал автоматическую генерацию кода, поэтому разработка части генерации была заморожена. Насколько я знаю, поддержка PL / I в основном была реализована, но так и не была завершена. Но все же вы можете попробовать,

1
ответ дан 18 December 2019 в 08:30
поделиться
Другие вопросы по тегам:

Похожие вопросы: