Есть ли на самом деле COBOL в .NET?

Micro Focus создает набор средств разработки на языке COBOL, в значительной степени предназначенный для поддержки устаревших приложений для мейнфреймов. Он говорит примерно на 20 диалектах COBOL с разных платформ и имеет средство эмуляции CICS. С 2004 года они рекомендуют его для замены рабочих нагрузок мэйнфреймов до 400 MIPS или около того. Принимая во внимание, что в начале 1990-х вы все еще могли купить системы мэйнфреймов Amdahl с производительностью 22 MIPS, 400 MIPS на мэйнфрейме — это довольно значительная рабочая нагрузка.

Интеграция устаревших серверных частей COBOL в современные интерфейсы — это большой бизнес. Существует довольно обширная экосистема терминала эмуляция программное обеспечение, очистители экрана, интерфейсные библиотеки и оболочки RPC для различных протоколов, таких как CORBA и SOAP.

Несколько лет назад Micro Focus выпустила компилятор COBOL .NET, который позволяет вам запускать приложения COBOL на сервере CLR. Вы можете скомпилировать любой из поддерживаемых диалектов, и он запустит все устаревшие функции эмуляции. Это позволяет поместить графический интерфейс или веб-интерфейс (или уровень веб-сервисов) в существующее приложение COBOL, сохраняя ваши инвестиции в существующую кодовую базу. Внешний интерфейс можно написать с помощью практически любого инструмента разработки, поддерживающего CLR. Вы хотите использовать C#/Windows Forms, MS Workflow Foundation, SSIS, IronPython, ASP.NET или интеграцию SQL Server CLR с серверной частью COBOL — дайте себе знать.

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

Этот тип работы составляет значительную часть их бизнеса, но все еще есть ниши, в которых COBOL действительно неплохо справляется сам по себе. Для многих больших пакетных заданий открытие ориентированного на запись файла и его процедурная обработка — хорошая парадигма для получения простого, понятного и быстрого приложения. Однажды я прочитал публикацию (на Slashdot IIRC), где кто-то рассказывал о приложении COBOL, которое считывало 35-гигабайтный файл возврата кредитной карты и обрабатывало его каждый час. Это было опубликовано довольно давно, где-то в 1990-х годах — в то время, когда 35 ГБ были значительно больше, чем емкость диска большинства ПК.

Заставить СУБД для массовой загрузки и обработки 35 ГБ данных (приблизительно 100–200 миллионов записей) за час — не обязательно тривиальная задача, даже на современном оборудовании. Часто для получения производительности с помощью SQL требуется несколько косвенный подход к обработке, что может скрыть смысл кода; хорошо настроенный SQL может быть вполне «только для записи».

COBOL используется в приложениях такого типа уже около 50 лет. Это зрелая, хорошо изученная и надежная технология, которая на самом деле делает это достаточно хорошо.

Я действительно набил зубы на кодировании на COBOL - выучил Fortran, Pascal и C, но потратил большую часть мои первые 5 лет профессионального кодирования на COBOL на IBM/390s. Хотя 15 лет не трогал.

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

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

Примечательно, что Lisp по-прежнему занимает такое же положение в кодировании ИИ. Что я нахожу интересным, так это то, что другой член группы из трех «больших» языков 1960-х/70-х годов — Фортран — пришел в упадок больше, чем другие, чего я не ожидал в то время. Однако у нас по-прежнему широко используется BASIC, который фактически является внебрачным ребенком Фортрана, так что, возможно, все трое так же живы и здоровы, как и всегда.

Роб, есть множество мест, где до сих пор используют COBOL, хотя и не обязательно для .NET; мы по-прежнему занимаемся разработкой мейнфреймов, и подавляющее большинство финансовых приложений все еще написано на языке COBOL, взаимодействующем с CICS.

Кроме того, вы по-прежнему можете получить компиляторы COBOL (например, Fujitsu) для платформ Windows.

Я думаю, что более распространенным сценарием является взаимодействие, например, приложения Windows и ASP.NET взаимодействуют с приложениями COBOL/CICS и наоборот.

Я участвовал в таком проекте несколько лет назад для крупного банка в моей стране, и я могу себе представить, что это было бы довольно обычным делом для любого банка, который имеет более чем 40-летний опыт работы с ИТ.

COBOL — это ниша. Хорошая, удобная, прибыльная ниша. Этого, вероятно, (рано или поздно) не станет, но сейчас оно все еще есть. Именно здесь несколько крупных банковских организаций разработали свои основные системы на языке COBOL. Это не только сопровождение, но и развитие!

Он существует уже около 50 лет. Каждые 10 лет кто-то объявляет его мертвым, но он все еще держится.

Меня поразила статья из Википедии:

Программы COBOL используются во всем мире в правительственных и военных учреждениях, на коммерческих предприятиях и в таких операционных системах, как z/OS от IBM, Windows от Microsoft и семейства POSIX (Unix/Linux и т. д.). В 1997 году Gartner Group сообщила, что 80% мирового бизнеса работает на COBOL с более чем 200 миллиардами существующих строк кода и примерно 5 миллиардами строк нового кода ежегодно.

http://en.wikipedia.org/wiki/COBOL

Я думал, что COBOL - это "древесина". Это скорее неправда. Кстати, Fujitsu NetCOBOL для .NET и Micro Focus Net Express® с .NET — довольно комплексные реализации. Может, стоит выучить этот язык, а потом найти хорошую работу с большой зарплатой? :)

Я знаю о Raincode, Fujitsu и Microfocus.

• Microfocus пытается использовать ASP.NET с помощью COBOL Codebehind.

• Fujitsu Я не уверен, предлагают ли они до сих пор собственное веб-решение или пытаются вписаться в ASP.NET.

• Raincode предлагает стандартный компилятор COBOL, ориентированный на .NET, без каких-либо попыток использовать ASP.NET.