Модернизируйте [закрытый] Кобол прежней версии

Любой инструмент преобразования будет сопряжен с рисками, и полученный код должен пройти много тестирования.

Учитывая, что многие из этих систем являются в повседневном использовании для ведения бизнеса, многое зависит от непрерывной работы. Так что дело не только в том, «как долго» или «насколько дорого», но и в том, можем ли мы доверять этому на 100% одинаково.

I think some organizations could find it useful, particularly organizations where interfacing with/designing around legacy code has become more costly and problematic than converting the code to Java (or another language)

while ( (CostToPortToJava > CostOfNotPortingOverTime++) && DoesLegacyCodeStillWork() )
{
 StayWithLegacyCode();
}

PortCodeToJava();

Здесь есть несколько факторов :

• Программные файлы Cobol очень длинные и почти всегда находятся на сверхбезопасных мэйнфреймах. Обычно разработчики Java не имеют к ним доступа.
• Приют для колледжей и университетов ' taugh Cobol более 20 лет. В результате все действительно первоклассные разработчики Cobol продвинулись в своих компаниях, и их заменили кучка выпускников технических школ. Эти люди недостаточно любили программирование, чтобы быть хакерами (иначе они бы занимались C, Python, C ++, что угодно и не прошли бы курс) или достаточно, чтобы пойти в школу (и быть Java, .Net, Python, чем угодно) .
• Java-разработчики обычно теряют рассудок, когда смотрят на программы Cobol в их 50 000-строчном великолепии, так что они не помогают.
• На самом деле нет никаких документов, а логика в этих программах очень жесткая. что вам действительно стоит просто прочитать их и преобразовать.
• Большинство этих компаний - финансовые компании, где лучший способ обанкротиться и больше не работать в отрасли - это что-то напортачить. Хороший способ что-то испортить - это заняться чем-то вроде преобразования критической задачи с Cobol на Java.

Это займет много времени - время от времени часть одной из программ перестает работать или не может что-то сделать, и его заменяют. Я не вижу, чтобы у многих старших менеджеров хватило смелости на все FUD в одном из этих проектов, и сроки довольно большие с точки зрения окупаемости потраченных денег.

One will always find tools to convert one language to another - they usually go by the term "compilers".

There is always a shortcoming with compilers that have to perform the task of converting code in language X to language Y, especially when the said code was written by a person. That shortcoming happens to be the fact that readbility is often lost in the process of translation. There is no guarantee that the code compiled from COBOL to Java will be understood by any programmer, so in effect the cost of translation has actually increased. In fact, it is difficult to define readability in such a context.

Lack of readability and understandability translates into lack of knowledge of runtime behavior of the translated code. Besides there is no guarantee that people understand the original code completely; surely they do understand bits and pieces of it.

Probably a little of both. There are companies that provide tools and services for conversion using both automated and manual techniques.

Many companies, however, follow the "ain't broke" philosophy, which is likely as wise as anything. Especially since many conversions result in attempts to "improve" the existing system or try to introduce modern software design/construction philosophies and result in a mess.

Многие системы, написанные на Cobol, содержат множество транзакций. Они хорошо работают на платформах мэйнфреймов, на которых они работают. Было бы рискованно менять их только ради перемены.

COBOL, по сути, является превосходным DSL (предметно-ориентированным языком).

Это домен - бизнес-правила, встроенные (в основном) в серверные приложения.

Найдите другой язык, который. ...

• обладает богатым набором функций в этой конкретной области.
• имеет несколько лет фактического, прикладного опыта, так что все ошибки устранены или устранены открыто.
• имеет TCO (совокупную стоимость владения) ниже, чем существующая унаследованная гора COBOL
• , экономически выгодно преобразовать в

.... и вы получите потрясающее приложение для серверных бизнес-приложений.

Что-то, что нужно понимать в старых приложениях COBOL, помимо языкового различия, заключается в том, что многие структуры данных, построенные в этих приложениях, не соответствуют какой-либо более поздней структуре СУБД, так что вы действительно будете говорить о значительном переосмыслении базовой архитектуры и дизайна, а не просто об изменении синтаксиса языка и замене этого будет иметь большой риск для производительности после того, как он достигнет реальных нагрузок, даже если это можно будет в достаточной степени обеспечить QA.

Суть в том, что выгоднее использовать новые функции в современном языке, чем переписывать его. Пока это так, COBOL будет продолжать жить.

Преимущество Cobol состоит в том, что он быстр для перемещения данных, а именно такие приложения обычно делают МНОГО. Кроме того, машины рассчитаны на ввод-вывод, а не на скорость обработки. Следовательно, любой перевод на другой язык, скорее всего, будет медленнее, чем аналог Cobol на идентичном или аналогичном оборудовании, поэтому нет причин для этого.

Позвольте мне задать встречный вопрос: ПОЧЕМУ конвертировать его, если у вас есть что-то такое, что работает?

(Подобно сносу моста каждые 10 лет только для того, чтобы сразу после этого его заново отстроить - обычно всегда дешевле просто поддерживать то, что у вас есть).