На какой язык вы бы портировали программы на COBOL и почему?

Question

При выборе языка для переноса программ COBOL с какого языка вы бы выбрали и почему? Я не ищу ответа «потому что я знаком с языком X».

Я ищу функции на языке, которые хорошо соответствуют дизайну COBOL.

Обновление: Программы будут запускать gammit для утилит, обработки данных, экранов и т. Д.

Answer 1

Я бы перенес их на ... гм ... Кобол. Да это оно. COBOL.

Извините, не удержался.

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

Является ли платформа, на которой он работает, устаревшей? Неужели руководство просто стремится к более «современному» решению? Вам нужно перенести материал из System z в Windows (тьфу!)?

COBOL (в чистом виде, не то, что мусор OO-COBOL) - это в основном простой процедурный язык (несмотря на ReportWriter), поэтому он вполне удовлетворительно переводится на любой другой процедурный язык:

• С
• C ++ без классов
• Java, хотя вы не можете избежать классов, если у вас нет одного большого синглтона.
• Паскаль (замена одного «мертвого» языка на другой).
• даже Python, Perl и др. Можно заставить работать.

Answer 2

Хорошо, вы должны рассмотреть, какие входные данные обычно получают программы на языке COBOL.

COBOL был разработан для обработки большого количества отформатированного текста фиксированной ширины в качестве входных данных, чтобы выводить практически таким же образом. Для меня это больше похоже на процесс ETL, чем все остальное.

Так что я бы не стал переносить программы на COBOL просто на другой язык; Я бы перенес его на подходящие технологии ETL, такие как службы интеграции SQL Server (SSIS) или, по крайней мере, его предшественник DTS - службы преобразования данных SQL. SSIS подразумевает использование VB.NET (по крайней мере, в SQL Server 2005), но это не должно быть проблемой.

Answer 3

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

1. Встроенная поддержка десятичной арифметики - это исключает любой современный язык без перегрузки операторов.

2. Лучшая поддержка структурированных записей - можно использовать комбо struct / union, как в C, но я думаю, что иногда это делает идентификаторы очень длинными (по крайней мере для программ, которые я видел).

3. Операторы Goto - без него пришлось бы полностью анализировать логику программы при ее переписывании.

Могут быть и другие функции, которые нелегко отобразить.

Answer 4

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

Наименее болезненным портом был бы Synergy DBL. Это очень портативное обновление в стиле виртуальной машины DIBOL (Digital Business Oriented Language).

http://www.synergex.com/synergy-dbl/

DIBOL использовал все хорошие вещи от BASIC, FORTRAN и COBOL, исключая большинство плохих.

Если вы перейдете по вышеуказанной ссылке, вы увидите, что у них есть GUI, .NET и другие инструменты улучшения. Просто убедитесь, что есть виртуальная машина для любой целевой ОС, на которой вы будете работать.

IBM Mainframe COBOL, интенсивно использующий CICS, TCAM, IDMS и т. Д., Станет действительно трудным портом для всего остального.

OpenVMS COBOL, использующий DECForms или, возможно, даже FMS, будет непростым портом без пакета обработки экрана. Очень старый COBOL из этих магазинов широко использует системные службы и подпрограммы библиотеки времени выполнения, предоставляемые ОС, которые не будут доступны на большинстве других платформ. Вам также придется прочитать логику и выяснить, как реализовать что-то вроде своего рода достаточно близкого к вашей цели.

То, что вы найдете в большинстве COBOL для мэйнфреймов и среднего уровня, это то, что вы не переносите только COBOL. Там будут тонны системных сервисов, которыми пользовался более старый COBOL.

Answer 5

• Я должен сказать, что вы не должны переносить COBOL.
  • Если вы имеете в виду переписать , тогда да, выберите язык. Я хотел бы предложить веб-интерфейс, Java или .Net, чтобы переписать в.
  • Если код должен запускаться в точности , как он выполняется сейчас, любое преобразование "переноса" принесет только вред.
• Если вам по какой-то причине необходимо сменить платформу, вы можете использовать COBOL на другой платформе.
• Что мне больше всего помогло, так это попытаться отделить компоненты или сервисы друг от друга и либо конвертировать небольшие фрагменты по отдельности, либо просто писать новый код на предпочитаемом языке, поддерживая работу COBOL в бэкэнде.

Answer 6

Я бы оставил ядро ​​КОБОЛ, но расширился бы по краям.

Микрофокус предоставляет инструмент Enterprise Server, который позволяет COBOL взаимодействовать с веб-сервисами.

Если у вас есть программа A на языке COBOL, а другая программа B и A на языке COBOL вызывает B через раздел интерфейса, инструмент позволяет вам представить раздел интерфейса B. как веб-сервис.

Для программы A вы затем создаете клиентский прокси, и теперь A может вызывать B через веб-сервис.

Конечно, поскольку у B теперь есть веб-служба, любой другой тип программы (командная строка, приложение Windows, Java, ASP и т. Д.) Теперь также может вызывать ее.

Кроме того, у них есть продукт под названием COBOL.NET, который работает внутри Visual Studio и переводит COBOL в MSIL. Это означает, что вы можете ссылаться на любые компоненты .NET.

Таким образом, подход состоит в том, чтобы сохранить ядро ​​COBOL, но взаимодействовать через веб-сервисы, и делать новые разработки на любом языке, совместимом с CLR (C #, VB и т. Д.)

Answer 7

Когда-то я занимался портированием некоторого материала на языке COBOL на C (1989 или около того). Речь шла о коде COBOL, предназначенном для мониторинга сигналов о взломе, пожаре и т. Д. Это была та программа, которая подходит для более реального времени. вид среды. Опрашивайте эти полевые пользовательские устройства gazillion столько раз в минуту и ​​т. Д. Поиск «функций на языке, который соответствует дизайну COBOL», игнорирует тот факт, что существует множество программ на COBOL, которые игнорируют дизайн COBOL.

Answer 8

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

Существует несколько компиляторов Cobol для .NET, таких как Fujitsu NetCOBOL .

Answer 9

Я бы лично принял это решение, основываясь на предполагаемом дизайне программы, а не на ее текущей реализации. Если вам нужен прямой линейный порт, я бы сказал, что c / c ++.