Comments 94
11 лет проработал с банковской сфере со страшным легаси. Cobol встречал только в статьях по истории языков программирования...
Я правильно понимаю, что это задача для ИИ которую он пока не тянет?
Потянет еще как, переезд на новый язык с сохранением логики это хорошее применение llm
Видел трансляторы из одного языка в другой без всяких LLM, по итогам работы которых код может был некрасивый, но надёжно рабочий. С LLM будет наоборот скорее всего, красивей, но менее предсказуемо.
Скорее всего нет. Потому что его придется не только двум языкам обучить, но еще и особенностям платформы с которой идет перенос. А там все может быть ну очень специфично.
Мне было интересно посмотреть как оно справится с ситуацией, когда один и тот же модуль в рамках одного задания вызывается (из другого модуля) несколько раз. И для экономии времени с прошлого вызова кешируются какие-то данные. Да-да-да. На AS/400 есть понятие "группы активации" как подмножества задания и все статические и глобальные данные сохраняются пока жива группа активации (пока живет задание или пока ГА принудительно не закрыли).
Тут с переходом на "современные языки" на другой платформе можно немало веселья отхватить пока придумаешь как все это обойти.
Ну или работа со специфическими системными объектами типа USER SPACE/USER QUEUE/USER INDEX...
Не говорю уже про тонкости реализации, связанные с производительностью. Или с точностью промежуточных вычислений для типов данных с фиксированной точкой... На таких "мелочах" тоже можно неслабо огрести. Даже если он заработает, но раза в полтора-два медленнее исходного...
в классических программах нет встроенной проверки границ буфера
Потому что они есть на уровне самой ОС. А еще там есть проверка на переполнение. Из соседней ветки
Так и случилось в один прекрасный момент несколько лет назад, когда путешествия на Бали (смотри курс индонезийской рупии IDR) стали внезапно стоить сущие центы из-за переполнения.
РаспродажуЛавочку прикрыли только к утру, когда заметили невероятную популярность клиента Agoda и отелей на Бали, и до исправления просто прекратили (на полгода) принимать платежи в валюте IDR. Убытки, как водится, просто списали, никого не наказали.
Тогда как в нормальной системе в такой ситуации переполнение вызывает системное исключение "Receiver value too small to hold result"
Теперь фронтенд и микросервисы общаются с мэйнфреймом по привычному HTTP, а не копаются в суровом COBOL‑монолите.
Вообще-то центральный сервер в банке изолирован от внешнего мира достаточно серьезно. Получить какие-то данные от него можно лишь оправив запрос через MQ или вызвав вебсервис на ESB шине. Причем, сам вебсервис тоже внутрь не полезет - он вызовет связанный с ним сервис-модуль, передав ему набор параметров. А потом получит ответ (например, в виде resultset'а). Через MQ примерно также - послылается сообщение с определенным типом и набором данных. Это сообщение будет подхвачено на сервере, далее вызван соответствующий этому типу сообщений обработчик, который выполнит нужные действия и при необходимости отправит в MQ ответное сообщение.
Никакого http там и близко не лежало. И слабо себе представляю как можно реализовать SQL инъекцию в таком раскладе (SQL там может вообще не быть - есть и другие способы работы с БД, в т.ч. и в COBOL). Да и голый SQL там не используется. Он весь спрятан внутри COBOL кода.
А если говорить о защите, то та же IBM i (AS/400) имеет несколько уровней защиты самой системы. В том числе и "50" уровень, сертифицированный в США для государственных и военных организаций. И даже на более низком, "40"-м уровне, уже достаточно много ограничений для разработчика (например, запрет низкоуровневой работы через MI инструкции c объектами в домене *SYSTEM - даже если получишь системный указатель на объект, что-то сделать с ним уже не сможешь - только через системные API и никак иначе).
использование transpiler-решений, которые автоматически переводят критичные фрагменты COBOL-кода в современные языки, такие как Java или C#
А что там с поддержкой в "современных языках" типов данных, которые лежат в БД? Те же форматы с фиксированной точкой? Читаем запись, потом создаем из ее полей нужные объекты с которыми можно работать? Но, извините, это лишнее время и лишние ресурсы процессора...
А что там с работой с БД? Только SQL, причем только динамический? Без возможности подготовки запроса на этапе компиляции? И даже по одной таблице по индексированным полям доступ к БД все равно только скулем? Задач, где нужно из одной таблицы прочитать десяток записей по известному значению ключа в реальной жизни достаточно много. И гонять ради этого динамический скуль очень расточительно.
COBOL (или тот же RPG) создавались специально для максимально эффективного решения конкретного класса задач. И имеют для этого все встроенные средства, являясь по сути специализированными языками.
Безопасность лежит не только в области самой системы. Можно иметь сколько угодно безопасную систему, а потом поставить пароль для qsecofr - qwerty, и толку от этой безопасности? Или все через mq, но только никто не подумал, что надо проверять источники сообщений. И все, кто угодно могут отправлять в это mq любые пакеты
А вы уверены, что "любой" пакет будет обработан? :-)
Вот пример реального сообщения
// Формат сообщения для HMQ-обработчика
dcl-ds t_HMQFINNRSP template qualified;
messageType char(10);
requestUID char(32);
INN char(12);
end-ds;messageType - тип сообщения. Он должен быть прописан в таблице настроек движка, который эти сообщения читает из очереди, находит в таблице обработчик и вызывает его, передавая ему сообщение для обработки
requestUID - это ID запроса в ответ на который получено это сообщение (из внешней системы). На этот ID должна быть запись в таблице отправленных запросов. Если ее нет - сразу на выход.
Ну и дальше данные.
И практически все сообщения выглядят примерно так - структура с данными. И все данные на входе обработчика будут валидироваться. Если что-то не так - ошибка и на выход.
Просунуть туда что-то левое крайне сложно, если вообще возможно.
С вебсервисами примерно аналогичная история. Т.е. там нет RPC. Каждый вебсервис (связанный с ним сервис-модуль) или обработчик сообщения выполняет строго определенную функцию и ничего более. И им передаются только параметры. Которые валидируются.
Физический доступ к серверу - только из внутреннего контура (даже к тестовому) и для очень ограниченного круга лиц. Пароль - не менее 12-ти символов, "3 группы из 4-х", смена не реже чем раз в три месяца.
Знание requestid - защита такая себе. Вряд ли это что-то секретное. Ну смысл моей мысли в том, что защита определяется самым слабым компонентом системы. Нет атак на операционку iseries- не значит, что система в целом безопасна
Как вы представляете себе атаку через MQ в данном случае? Передать заведомо некорректные данные? Или что? В чем цель атаки?
Напрямую получить доступ к серверу не получится (т.е. невозможно слить всю БД). Операций типа "положи вот эти данные вот в эту таблицу" там не предусмотрено. Есть выполнение конкретных операций тип "добавление клиента", но это сложна операция - там очень много проверок и валидаций прежде чем клиент будет заведен. Любой платеж тоже проходит кучу проверок.
Больше скажу - в продуктовые таблицы никакие данные никогда не вводятся скулем напрямую. Для этого на каждую таблицу есть т.н. "опция ведения" - модуль для интерактивного ввода, модуль для внешнего ввода, модуль физической записи и модуль валидации. И любые данные из интерактива или внешнего ввода сначала проходят валидацию а только потом уже пишутся в таблицу. И там нет скуля, используютися операции прямого доступа к БД. И любая операция журналируется - кто, когда и что изменил.
Для этого на каждую таблицу есть т.н. "опция ведения" - модуль для интерактивного ввода, модуль для внешнего ввода, модуль физической записи и модуль валидации
Это вы так ORM описали? Или я неправильно понял суть?
АБС. Это структура ядра АБС MiSys Equation. Мы ее поддерживаем и дорабатываем. Ну и вокруг нее много логики.
Фактически это не монолит ни разу. Ближе к модели акторов - много модулей, каждый реализует свою логику. В RPG программа имеет человеческие аргументы (не arc/argv как в С, а нормальные типизированные аргументы). И любая процедура может быть или внутренней (в том же модуле бинарника) или внешней (в другом модуле того же бинарника или в "сервисной программе" - аналог динамической библиотеки) или внешней программой (т.е. описывается как процедура, но на самом деле вызывается программа). Просто для внешней процедуры в объявлении прототипа указывается extproc('имя процедуры') а для внешней программы - extpgm('имя программы'). Но вызывается как обычная процедура.
Тот же "внешний ввод" это прототип нужной функции внешнего ввода [данных в таблицу]
Dcl-Pr FRR EXTPGM('FSTFRR');
$ZWSID char(4);
$ZDIM packed(2 : 0);
$ZTIM packed(6 : 0);
$ZSEQ packed(7 : 0);
$ZJTT char(1);
$Lib char(10);
$Vald char(1);
$Pgm char(10);
$AIM char(9999);
$ZREC char(1);
$ZMES7 char(37);
$AOW char(740);
$EM char(740);
$AExt char(1);
$ARec char(1);
END-PR;плюс ее вызов с нужными аргументами
FRR(ZWSID: ZDIM: ZTIM: ZSEQ: JTT: Lib: Vald:
Pgm: dsGZFSTRec: ZREC: ZMES7: AOW: EM: AExt: ARec);Все легко и просто.
А внутри оно сначала вызовет модуль валидации и если ошибок нет, то вызовет модуль записи в таблицу.
Это если совсем просто. Но на самом деле там все сложнее. Журналирование, накат изменений по журналам и т.п.
Но суть в том, что не пройдя процедуру валидации данные в таблицу не попадут. А валидация может быть достаточно сложной и объемной - там много чего проверяется, в т.ч. и интеграционная целостность и непротиворечивость.
Да и сама запись в таблицу тоже может быть достаточно сложной процедурой. Это может быть запись в несколько таблиц, может быть "откидывание" старого варианта записи в архивную таблицу, может быть поддержка какой-то "витрины" (скажем, если таблица где хранятся записи с историей изменений, и есть для нее витрина где хранятся только актуальные записи, или витрина может содержать какие-то данные, подготовленные для определенных процессов...).
Тут долго можно рассказывать...
Это у вас таки не про Кобол.
Таки да. Но они ровесники - RPG тоже 1959-го "года рождения". Правда, изначально это был "эмулятор табуляторов" (чтобы не выбрасывать все нажитое тяжким трудом) для IBM 1401.
Потом уже стал более-менее языком, но с позиционным синтаксисом ("FIXED"), специфическим cycle mode выполнением программы, primary file (основная таблица) и т.п. Т.е. там хватало заморочек.
Нормальным процедурным языком оно уже стало в конце 90-х - начале 00-х.
Но как и COBOL, это все равно специализированный язык для работы с БД и финансовых вычислений. Пытаться использовать его как ЯВУ общего назначения неудобно (даже несмотря на то, что концепция ILE позволяет использовать любую функцию из C RTL в RPG программах фактически напрямую).
Зато с БД работать легко и просто. И со всем что в БД лежит - даты, время, строки, форматы с фиксированной точкой. Все в языке для этого есть. И при этом очень простой синтаксис (где-то на уровне классического паскаля).
COBOL в этом плане достаточно похож. Ну только синтаксис непривычный. В этом плане по самому языку порог входа несравнимо ниже прочих. Там больше сложностей будет с особенностями самой платформы на которой все это работает.
В данном примере как-то валидация не видна - вон, INN такой же char, а не PIC 9 хотя бы.
Ну я же не буду вам весь код раскрывать :-)
FSTFRR - модуль внешнего ввода. Он определит в каком режиме работает (их несколько - внешний ввод переданных данных, накат из журнала в указанной библиотеке, восстановление по журналу...) потом вызовет FSTFVR - собственно валидатор, а потом, если не будет ошибки в валидаторе, уже FSTFUR - собственно изменение данных в таблице.
И ИНН будет проверяться по многим параметрам - соответствие формата типу клиента (у ЮЛ и ФЛ разные форматы), совпадение значения со значением в карточке клиента, валидность ИНН (там есть алгоритм проверки с контрольными цифрами и т.п.)...
Я конечно не настоящий сварщик, но вроде бы MQ поддерживает 2х стороннюю проверку SSL сертификатов. Т.е. клиент и сервер предоставляют свои и проверяют чужие сертификаты при каждом запросе. Вопрос в том что на старых серверах вся эта криптография может существенно отбирать проц, но это не проблема а расходы...
Без возможности подготовки запроса на этапе компиляции?
Компиляции на каком из стендов? То есть я скомпилировал продакшен версию сборки, она с каким из стендов должна компилироваться?
Только SQL, причем только динамический?
Есть Prepared Statement есть Stored Functions.
COBOL (или тот же RPG) создавались специально для максимально эффективного решения конкретного класса задач.
Эффективного для кого? А то вариант с использованием нормального серверного железа общего назначения видится мне сильно эффективнее. И пофиг что оно будет вдвое менее эффективны из-за необходимости нескольких конвертаций. Зато процессоры будут вдесятеро быстрее из-за больших масштабов производства, а за одно колличество ОЗУ, IOPS-ы на системах хранения данных. И горизонтальное масштабирование проще. И виртуализация при разработке. И поиск разработчиков.
Компиляции на каком из стендов? То есть я скомпилировал продакшен версию сборки, она с каким из стендов должна компилироваться?
На прод поставки разворачиваются из исходников. Ну и у АСки есть такая особенность - в бинарнике кроме исполняемого хранится еще TIMI код (код в машинных инструкциях). Если при запуске бинарника система видит что исходный код собран для другого процессора, он будет автоматически перегенерирован из TIMI под тот процессор, на котором его запускают. Это работает при переносе бинарников на новый сервер.
Есть Prepared Statement есть Stored Functions.
Тут все проще. Непосредственно в RPG (для COBOL примерно также) пишем
exec sql declare curProcNames cursor for
select NMC.NMCCUS,
NMC.NMCCLC,
GF.GFCRF,
NMC.NMCTP
from NMCPF NMC
join GFPF GF
on (GF.GFCUS, GF.GFCLC) = (NMC.NMCCUS, NMC.NMCCLC)
where NMC.NMCDT = :dte
and NMC.NMCNTP = 'BGFNM'
and NMC.NMCTP in ('F', 'G')
and GF.GFCOD <> :dte;Это статический SQL. Это не выполнение, это декларация. dte тут - переменная используемая в коде. Запрос этот будет на этапе компиляции подготовлен.
А дальше
exec sql open curProcNames;и потом
exec sql fetch curProcNames for :C_MAX_SQL_ROWS rows into :dsData;Блочное чтение в массив структур
dcl-ds t_dsData qualified template;
CUS char(6);
CLC char(3);
CRF char(20) inz(cNoCRF); // нужно там, где ИНН не подтягивается причтении из БД
TYP char(1);
end-ds;
dcl-c C_MAX_SQL_ROWS const(1000);
dcl-ds dsData likeds(t_dsData) dim(C_MAX_SQL_ROWS);А дальше мы уже сразу можем работать с элементами массива.
Впрочем, все это я описывал тут.
На каком-нибудь C# все это будет сложнее и потребует внешних зависимостей. А здесь все это средства языка.
вариант с использованием нормального серверного железа общего назначения видится мне сильно эффективнее
На каком основании такой вывод? Вот лежит у вас в БД какой-нибудь decimal(15, 0) или numeric(7, 0). Вот прочитали вы его из БД - что дальше будете с ним делать? Создавать из него объект чтобы с ним работать? Это время и такты процессора...
Насчет "нормального серверного железа" - тут большой вопрос. Я не хочу углубляться в тонкости того, что есть на АСке. Сейчас у нас не самый свежий сервер, но это 120 SMT8 ядер Power9, 12Тб оперативки и 400Тб SSD массивы.
Последнее поколение - Power10. Среди прочего позволяет объединять серверы по интерфейсу PowerAXON так, что процессоры, память и диски становятся общими для всех. Т.е. фактически вы из нескольких малых серверов получаете один большой. И все это поддерживается на уровне ОС. Это про простоту масштабирования.
Про все остальное - https://programmers.io/blog/everything-to-know-about-ibmi-as400-i-series/ Там и интеграция и масштабирование и все остальное.
Я разработкой занимаюсь с 91-го года (последние 8 лет на АСке). И на разных системах работал (даже немного зацепил такую экзотику как QNX). Так вот возможности, предоставляемые "из коробки" на АСке ни в какое сравнение с остальными не идут. Одно ILE чего стоит.
Ну а с поиском разработчиков как-то нет проблем. Недостатка у нас нет. Берем, обучаем.
В общем, чтобы предметно разговаривать нужно с этой системой поработать плотно. Тогда можно сравнивать. А так...
Ну такие же фетчи из курсоров в Oracle Pro*C, только работать это может уже (в нашем случае) на Solaris на SPARC, которое хоть и железо дорогое и ось старая, но всё-таки Unix и достаточно современное. В отличие от вендорлока на мейнфреймы...
Да, вот только все это вы не вставите напрямую в код на шарпе или джаве... Вам придется все это запихивать в какой-то объект.
И получив из БД какой-нибудь decimal (или дату, или время) вы не сможете сразу с ними работать, не потратив время на создание какого-нибудь объекта на их основе...
Здесь же вы напрямую объявляете SQL запрос, который будет еще на этапе компиляции подготовлен (и компилятор может выдать ошибку если в синтаксисе запроса что-то не так). А получив данные вы сразу сможете работать с ними - decimal, numeric, date, time, timestamp - все эти типы поддерживаются языком (включая всю арифметику, в т.ч. и операции с округлением для форматов с фиксированной точкой).
А для несложных операций (типа прочитать десяток записей по значению ключа из одной таблицы или прочитать запись по ключу, изменить значение полей и записать обратно) можно вообще напрямую, без SQL с таблицами работать. И это будет быстрее, особенно когда это сильно нагруженный модуль с большой плотностью вызовов одновременно из многих заданий.
В этом и разница между специальным языком и языком общего назначения - в первом у вас в самом языке есть все для решения специфических задач предметной области наиболее эффективным образом, а во втором вам приходится привлекать дополнительные зависимости и тратить время на согласование форматов и типов данных языка и предметной области.
Если что - есть очень большой опыт писания на С/С++ В т.ч. и приложений для работы с БД (на других платформах). И С/С++ тут тоже есть. Но для работы с БД и банковской логики однозначный выбор в пользу RPG потому что на нем это делается в разы проще и быстрее. И вот что-то системное - тут да. Уже С/С++ удобнее.
Да, вот только все это вы не вставите напрямую в код на шарпе или джаве... Вам придется все это запихивать в какой-то объект.
Ну почему? Вставлю, он будет работать немного иначе, и под капотом там будут выполняться преобразования, допустим, LINQ-запроса в SQL, а потом трансформация типов БД в типы моего языка программирования. Но для меня это будет выглядеть абсолютно прозрачно, и я могу прямо в коде работать с тем, что я получил из базы данных. Да, это будет медленнее с точки зрения производительности, чем когда у вас среда программирования, СУБД и само хранилище тесно интегрированы. Но в моей среде это в порядке вещей, потому что в этой нашей "РСшной" среде испокон веков СУБД с хранилищем может находиться где угодно физически, и это могут быть разные СУБД.
Ну я знаю как это работает. Я с разными БД работал под ДОС, Вин и Линукс.
Там это для вас прозрачно, а когда начинаешь профайлить, то видишь сколько времени и ресурсов процессора уходит "под капотом".
У меня реально был случай, когда на доработку пришел модуль с динамическим скулем и заключением от сопровождения о том, что "33% времени и 36% ресурсов CPU тратится на подготовку SQL запроса". Треть времени и ресурсов программы!!! В наших реалиях это непозволительная роскошь.
Фактически это означает что бизнесу нужны серверные мощности на треть больше чем можно было бы. А это и деньги на оборудование и деньги на электропитание, охлаждении лишних железок. Вполне реальные такие деньги.
Специализированные решения (и по железу и по софту) тем и хороши что они оптимизированы для использования вычислительных мощностей под конкретный задачи.
Поэтому уход от того же COBOL в сторону языков общего назначения не выглядит разумным решением.
Другое дело, что там, наверняка, можно много чего вынести наружу. Того, что не завязано жестко на специфику. У нас таких "внешних систем", решающих business (но не mission) critical задачи несколько десятков. И там самые разнообразные решения используются - и RHEL и SLES и еще черт знает что... И та же MQ прекрасно работает - на нашей стороне MQ API для AS/400, на той стороне - JMS (Java Messaging System). Да и на самой ASке у нас есть Java интерфейсы (JT400) - на них система сборки, например, гредловая построена (в статье достаточно старая версия описана, сейчас там много чего накручено уже).
Так что если ядро системы написано на COBOL и работает, то совершенно не обязательно всю инфраструктуру строить на нем. Все это отлично интегрируется в современные решения. И это нормально (с точки зрения эффективности) - для каждой части большой системы выбирать наиболее подходящее для нее решение.
Я даже на АСке на двух языках пишу - RPG и C/C++. В зависимости от того, на чем мне удобнее реализовать данный конкретный кусок.
Как пример - https://habr.com/ru/articles/812605/ USRQ API написана на С (я могу и на RPG все это же написать, но неудобно). Скулевые UDF/UDTF - на RPG. Используется все это на 90% из RPG кода.
Я, собственно, к тому, что любой инструмент хорош в том, для чего он в первую очередь предназначен. А попытки все делать одним инструментом не очень хорошая практика. И если вас есть исправно работающий код на COBOL - не трогайте его. Пусть работает. Будто заняться больше нечем...
И чтобы его переписать вам потребуется человек, который свободно владеет COBOL, хорошо знает тонкости платформы на которой все это работает и еще в предметной области ориентируется. Но если у вас есть такой человек, то и переписывать ничего не надо...
очень расточительно
этим система 50+ лет, за это время железо настолько далеко ушло, но не думаю, что это вообще проблема
А уверены, что все это не было перенесено на более новое железо?
У нас вот можно еще встретить модули начала нулевых, которые когда-то работали на Power7 (если не младше), а сейчас работают на Power9 (а если будет Power10 - будут работать на нем).
При этом, уже писал, бинарник содержит в себе кроме исполняемого, еще TIMI код и метку под какой проц собран исполняемый - если при запуске система обнаружит несоответствие, автоматически перегенерит новый исполняемый из TIMI. Под новый проц.
Т.е. перенос бинарника на более современный сервер не несет в себе проблем что исполняемый код не оптимизирован под старый процессор - система сама это поправит.
уверены, что все это не было перенесено на более новое железо?
не уверен, но на интуитивном уровне не думаю, что это не те задачи, где надо обязательно выжать все до последнего такта из железа
Ну как вам сказать... Вот в 20-м году у нас в таблице клиентов было 36млн записей. Сейчас - более 50-ти. А общий объем данных растет сильно кратно количеству клиентов.
АБС - это навскидку полтора-два десятка тысяч таблиц. Десятка три программных модулей. Сотни миллионов операций в сутки. Достаточно нагруженная система. И это только mission critical часть. Котора находится под неусыпным контролем регулятора. И где допустимое время недоступности исчисляется минутами.
А задачки приходится всякие решать... И практически все что идет в бой, проходит этап обязательного нагрузочного тестирования.
Ну как вам сказать... Вот в 20-м году у нас в таблице клиентов было 36млн записей. Сейчас - более 50-ти. А общий объем данных растет сильно кратно количеству клиентов.
Это по современным меркам немного. Ваш мессенджер миллиардными таблицами ворочает. Особенность большинства АБСок в том, что это легаси-системы, которые исторически были сильно централизованы, и такими и остаются, пытаясь выжать максимум из одной центральной железяки, будучи также критически зависимыми от её работоспособности. В то время как в окружающем мире у многих систем объемы данных давно превысили возможности одной пусть и убермощной железяки, и там вынуждены были искать решения, которые полагаются на децентрализованные системы. Сто маломощных, но взаимозаменяемых узлов - это надёжнее, чем один мощный. И при этом дешевле, гибче, более масштабируемо.
Ну так-то у нас еще около 60-ти "внешних систем" вокруг АБСки.
Кто идет по пути децентрализации обычно сталкиваются с другими проблемами - огромное количество тесно связанных между собой данных. А дальше - или реплицировать их все по всем узлам и иметь лаги репликации, или распределять, но тогда лаги начинаются на уровне связывания.
Поэтому да. То, что не критично по времени - выносится на внешние системы с репликацией туда нужных данных. А что критично - то работает на АБС.
Ну и смотрите. 50млн клиентов. У каждого клиента 5-6 адресов (разных типов). Несколько ДУЛ (документ удостоверяющий личность). Счетов - 5-6 это мизер. Есть клиенты с несколькими десятками и даже сотнями счетов.
Дальше идут "субъекты клиентов" - всякие доверенные лица и т.п. Там же - доверенности. и уполномоченные лица.
Дальше - держатели карт (скажем, корпоративных или семейных)...
Итого на одного клиента может быть полторы-две сотни всяких связанных с ним записей только по клиентским данным.
Плюс всякие риски клиентов (страновые, репутационные, санкционные и т.п.)
Плюс всякие данные по актуализации.
Дальше - платежи. Проводки, полупроводки, платежные документы... Одних платежей за сутки проходит около сотни миллионов.
И бог знает что еще. Так что смело можно 50млн клиентов умножать на 100 а то и более. Так что там объемы приличные. И очень разнородные.
Ну и железяка там таки не одна. Их несколько, включая горячий резерв.
Тут еще такое дело - если у вас условно три железяки с равномерно распределенной нагрузкой, и в период пиковой нагрузки из них встанет одна, то две остальные не вывезут. И все встанет колом. Так что тут три слабых вместо одной мощной не спасет. Спасает горячий резерв с переключением в пару минут (время недоступности системы).
Про масштабируемость писал уже - PowerAXON на машинах Power10. Вот там реально можно наращивать мощность масштабированием кластера из мелких машин. И при этом все это работает как она большая с точки зрения конечного пользователя.
И бог знает что еще. Так что смело можно 50млн клиентов умножать на 100 а то и более. Так что там объемы приличные. И очень разнородные.
Приличные, но тут есть нюанс: база данных клиентов со всеми связанными вещами очень неплохо шардируется.
Там проблема в том, что многие процессы используют большое количество разнородных данных. И если начать все это разносить по серверам, начнутся лаги при сборе нужной информации.
А есть достаточное количество мест, где такие лаги просто недопустимы. Условно говоря - длительность некоего процесса в пять минут недопустима т.к. он начинает тормозить следующие за ним процессы и так по цепочке. И все вместо это начинает вылазить за рамки отведенного временного окна (работа банка в течении суток имеет несколько фаз и каждая из них привязана по времени).
Тот же контроль платежей (ориентировочно 100млн платежей в сутки, может и больше) - там все очень критично по времени и при этом проводится много проверок с использованием большого количество разнородных данных. Если там начнутся лаги связанные с запросами данных с других серверов - будет большая просадка, а это недопустимо.
Тут и так все что можно вынести во внешние системы - вынесено и обрабатывается там. На АБС остается только то, что критично по времени и быстродействию.
И в целом, система справляется. Даже в пиковых нагрузках. И да, приходится оптимизировать многие старые модули - за этим следит сопровождение. Много из того, что написано 5 и более лет назад и на тот момент устраивало по скорости, сейчас не устраивает и переписывается с учетом большого накопленного опыта (в плане оптимальности кода).
И тут, опять, помогает то, что с БД можно работать не только скулем (который не является безусловно оптимальным в плене производительнности). Используется комбинированный подход. Скажем, получить десяток записей из одной таблицы по заданному значению ключа прямым доступом всегда быстрее, чем скулем. Еще быстрее - проврека наличия записи по значению ключа (без ее чтения, просто есть/нет - оно не требует обращаения к таблице).
Также помогает кеширование между вызовами программы (опять особенность АСки - пока жива группа активации, все глобальные и статические данные сохраняются между вызовами одной программы, а таких ситуаций у нас достаточно). Это позволяет избежать лишних операций. Те же настройки - при первом вызове прочитали, организовали в памяти под быстрое и удобное использование, а при следующих 100500 вызовах уже просто пользуемся.
Тут сама платформа много тонкостей таких имеет, позволяющих оптимизировать программы при правильном использовании.
В этом и проблема миграции - там не просто с одного языка на другой перевести, там очень много логики менять надо. И придумывать как обходить те моменты, которых нет на других платформах.
А что там с работой с БД? Только SQL, причем только динамический? Без возможности подготовки запроса на этапе компиляции? И даже по одной таблице по индексированным полям доступ к БД все равно только скулем? Задач, где нужно из одной таблицы прочитать десяток записей по известному значению ключа в реальной жизни достаточно много. И гонять ради этого динамический скуль очень расточительно.
Вообще-то под "динамическим" SQL понимается, когда запрос собирается на ходу из кусков в зависимости от параметров, и это в таких (да наверное и вообще) системах редкость. А для типовых будет стадия PREPARE, так что какая разница-то.
А что там с работой с БД? Только SQL, причем только динамический? Без возможности подготовки запроса на этапе компиляции?
В Коболе, ИБМ-овском, с DB2 for zOS используется традиционно не динамический, а статический SQL, компированный вместе с компиляцией исходного кода Кобол программы и сохраненного в DB2 командой BIND. Динамический тоже есть, но предпочтение отдается статическому.
Да, это так. Потому что в случае с динамикой (как показывают наши PEX статистики) до 30% времени и ресурсов процессора могут уходить только на подготовку запроса. Это неэффективно. Там есть некоторые финты типа ручного формирования SQLDA (SQL Descriptor Area) и использования open cursor using descriptor, но это тот еще гимор. Пару раз использовал в ситуациях когда надо чтобы было быстро, но использовать статику никак не получалось ввиду значительной вариативности запроса в зависимости от набора входных параметров.
SQLDA это про динамический SQL. Я это использую в REXX программах, которые только динамику и имеет. Сам я на Коболе не пишу.
Вы, полагаю, говорите про Кобол. Я много-много лет DB2 DBA для ERP приложения на Коболе и в CICS в z/OS. Все програмы (ладно почти все) используют статику. Безусловно в этом приложении тоже есть проблема с вариативностью запросов. Как то они эту проблему решали походу.
Как мне кажется, на вскидку, в програме на основании исходных данных создается ветвление для разных структур запросов и каждый из них прописывается для статики. Вам ведь все равно приходится строить запрос и вариантов этого не бесконечное множество.
Как то так видится. Можно пообсуждать, могу посмотреть исходники наши.
Да, SQLDA это про динамику.
Но я не про COBOL, а про RPG на IBM i. В целом (если не считать синтаксиса современного RPG) они с COBOL ровесники и функционально очень близки.
COBOL на i есть (номинально входит в группу ILE языков), но тут более 80% кода на RPG пишется.
Как мне кажется, на вскидку, в программе на основании исходных данных создается ветвление для разных структур запросов и каждый из них прописывается для статики.
По возможности - да. Но бывают [крайне редкие] исключения когда пришлось бы писать десяток вариантов статики (слишком большая вариативность по набору входных параметров). И тогда приходится морочиться с SQLDA. Хотя, справедливости ради, за 8 лет работы на АСке с таким столкнулся один раз всего... Что-то очень извратное было.
Со статикой единственный затык - конструкция where ... in (...) - вот там не получается подставить параметром строку в скобках. Набор параметров можно, а чтобы строкой - нет. Не сказать чтобы это было часто нужно, но иногда бывает потребность когда не знаешь заранее сколько там будет параметров.
Со статикой единственный затык - конструкция where ... in (...) ...
С ходу, долго не думая. Не ставить WHERE IN, выбирать все что в других предикатах и уже из результирующего набора, в цикле выбрать то что удовлетворяет WHERE IN.
Другой вариант. Более красивый. В цикл по списку в IN выполняется статический SELECT с WHERE Col_IN = ? подставляя каждый раз новый параметер из неопределенной длинны списка. По завершению цикла вы будете иметь все нужные строки с IN.
Обычно where in - это какая-то строка из настроек. Например,
'U1U2U3N2N3N7N8N9C2'В данном случае, это набор двухсимвольных значений некоторого параметра. Т.е. в итоговом запросе оно должно выглядеть так:
where ... in ('U1', 'U2', 'U3', 'N2', 'N3', 'N7', 'N8', 'N9', 'C2')В принципе, там есть w\a в виде
where ... in (select ELEMENT from table(SYSTOOLS.SPLIT(:str, ',')))где
str = 'U1,U2,U3,N2,N3,N7,N8,N9,C2'Беда в том, что там с производительностью не очень... SPLIT не очень быстрая функция...
Есть мысль написать свое, что-то типа
CONTAIN(elm, str, cnt, len)которое будет на вход брать строку
'U1U2U3N2N3N7N8N9C2'состоящую из
cnt = 9элементов, каждый из которых имеет длину
len = 2будет возвращать 'Y'/'N' в зависимости от того, содержится элемент elm в строке или нет.
Т.е.
CONTAIN('N3', 'U1U2U3N2N3N7N8N9C2', 9, 2)вернет 'Y', а
CONTAIN('S1', 'U1U2U3N2N3N7N8N9C2', 9, 2)Вернет 'N'
Естественно, пишется это на RPG, засовывается в SRVPGM (сервисная программа, аналог динамической библиотеки) со своей именованной группой активации.
На первом вызове строка раскладывается в массив (статическая переменная), при последующих просто сравниваем - изменились ли параметры с прошлого вызова - если нет, то используем уже готовый массив.
Ну а проверка наличия в массиве - это уже есть в RPG
if elm in array;
res = 'Y';
else;
res = 'N';
endif;Ну а дальше погонять PEX и посмотреть получится ли быстрее на больших выборках.
В принципе, у меня есть уже готовая реализация "набора" в которой, в частности, есть такая вот функцийя
dcl-pr SET_FromString int(10) extproc(*CWIDEN : 'SET_FromString');
ptr pointer value;
pString pointer value options(*string);
end-pr;
Инициализация набора строкой без разделителя вида '214599S2K9536793'
Параметры:
ptr - указатель на набор
pString - строка для инициализации (переменная или строковая константа)
при инициализации строка будет разбита на элементы равной длины, той, что указана при
создании набора. Если размер элемента при создании был указан равным 2, то разбивка будет
проведена следующим образом: '21’, ‘45’, ‘99’, ‘S2’, ‘K9’, ‘53’, ‘67’, ‘93'
В набор будут занесены только «полные» элементы. Т.е. если к строке добавить еще один символ,
то при разбивке последним окажется неполный, односимвольный элемент который будет
проигнорирован.
В случае инициализации строковой переменной концевые пробелы предварительно удаляются.И
dcl-pr SET_Exists ind extproc(*CWIDEN : 'SET_Exists');
ptr pointer value;
pItem pointer value options(*string);
end-pr;
Параметры:
ptr - указатель на набор
pItem - строковая переменная или константа, содержащая проверяемый элемент
Размер должен быть не меньше размера элемента набора [указанного при его создании]
Функция возвращает логическое значение *on/*off в зависимости от того найден указанный
элемент в наборе или нет.Можно сделать на нем.
// Инициализируем набор строкой
n = SET_FromString(ptrSet : '234589S1K944675593': 3);
if (n > 0);
// Проверяем наличие элемента в наборе
if (SET_Exists(ptrSet : 'S1'));
// делаем что надо если элемент есть в наборе
else;
// а тут делаем что-то если его нет
endif;
endif;Я соверешнно не в курсе RPG. Знаю о его существовании давным давно, но ровным счетом ничего. Даже Кобол, на котором я не писал ни строчки, я более менее знаю потому что приходилось читать тексты чисто для понимания алгоритма, я знаю более менее.
Поэтому ничего не могу Вам сказать по поводу Ваших рассуждений. Мне, с точки зрения языка типа PL/I или REXX это казалось просто.
Извините.
Тут суть в том, что эта функция будет вызываться многократно (может быть тысячи, может десятки тысяч раз) в рамках одной выборки, и, значит, в рамках одного задания (job). Т.е. в рамках одной группы активации. Это типичный сценарий использования. Как пример - отобрать в таблице доверенных лиц тех, у кого типы доверенностей входят в заданный в настройках список.
При первом вызове с новой строкой будут проведена некоторая подготовка данных (как вариант - превращение строки в массив элементов и его сортировка) для быстрого поиска элемента (например, быстрым поиском). И все последующий вызовы уже не будут манипулировать самой строкой (кроме проверки что он не изменилась с предыдущего вызова), а будет сразу выполняться быстрый поиск элемента в подготовленом при первом вызове массиве.
К RPG это ровным счетом не относится. Все это можно и на С/С++ написать и оно будет работать точно также - группы активации, сохранения статических данных при многократном вызове в рамках одной группы активации - это особенности работы IBM i, а не конкретного языка.
Зная эти особенности и понимание типичных сценариев использования можно таким вот образом использовать их для повышения эффективности.
Думаю, что это будет эффективнее чем SYSTOOLS.SPLIT:
BEGIN
DECLARE FOUND_POSITION INTEGER DEFAULT 1 ;
DECLARE VSPLIT_LENGTH INTEGER DEFAULT 1 ;
DECLARE VWORK CLOB ( 1 M ) ;
DECLARE LIST_ITEM BIGINT DEFAULT 1 ;
DECLARE ITEM_START INTEGER DEFAULT 1 ;
DECLARE SCAN_START INTEGER DEFAULT 1 ;
SET VWORK = INPUT_LIST ;
IF VWORK IS NULL THEN RETURN ;
ELSEIF DELIMITER IS NULL OR LENGTH ( DELIMITER ) = 0 THEN
BEGIN
PIPE ( LIST_ITEM , VWORK ) ;
RETURN ;
END ;
END IF ;
SPLITLOOP : LOOP
SET FOUND_POSITION = LOCATE_IN_STRING ( VWORK , DELIMITER , SCAN_START , 1 ) ;
IF FOUND_POSITION = 0 THEN SET VSPLIT_LENGTH = LENGTH ( VWORK ) - ITEM_START + 1 ;
ELSE
IF ESCAPE IS NOT NULL AND FOUND_POSITION > 1 AND
SUBSTRING ( VWORK , FOUND_POSITION - 1 , 1 ) = ESCAPE THEN
SET VWORK = OVERLAY ( VWORK , '' , FOUND_POSITION - 1 , 1 ) ;
SET SCAN_START = FOUND_POSITION + LENGTH ( DELIMITER ) - 1 ;
ITERATE SPLITLOOP ;
ELSE SET VSPLIT_LENGTH = FOUND_POSITION - ITEM_START ;
END IF ;
END IF ;
PIPE ( LIST_ITEM , SUBSTRING ( VWORK , ITEM_START , VSPLIT_LENGTH ) ) ;
IF FOUND_POSITION = 0 THEN LEAVE SPLITLOOP ;
END IF ;
SET ITEM_START = FOUND_POSITION + LENGTH ( DELIMITER ) ;
SET SCAN_START = ITEM_START ;
SET LIST_ITEM = LIST_ITEM + 1 ;
END LOOP ;
RETURN ;
END
Помоему это такой способ конкурентной борьбы. IBM вырастила себе поляну и сама её топчет. Как только они переведут свои сервисы на что-то более человечное (Java, Scala) и стандартное x86 железо, их тут же потеснят с этого сочного рынка. Все эти IBM i/z и прочие однобуквенные платформы - типичный пример дичайшего переусложнения. Есть мнение, что эти машины тратят более половины своих вычислительных ресурсов только на организацию многоуровневой виртуализации, трансляцию форматов данных и протоколов между ними.
Есть мнение, что эти машины тратят более половины своих вычислительных ресурсов только на организацию многоуровневой виртуализации, трансляцию форматов данных и протоколов между ними.
Это плата за безопасность. Как только все переедет на x86 железо, следом переедет «многоуровневая виртуализация», «трансляция форматов данных и протоколов между ними». Или появятся новые варианты оных. Это как с клавиатурой в банкомате — вроде 12 кнопок, должна стоить копейки, но нет — внутри криптопроцессоры, батарейки для хранения ключей и все залито эпоксидкой с проводками.
Это не безопасность, это "security through obscurity".
Никаких «obscurity». Все задокументировано и объяснено, почему именно так сделано.
Там количество документации умопомрачительное. Прочитать и проанализировать её не сможет ни одна нейросеть в мире. Это ли не "obscurity" ?
В 90-х года мне доводилось администрировать цифровые телефонны станции Nortel Meridian-1, чем-то они похожи на IBM-овских динозавров. Так вот, документации к Meridian-1 было около 80-ти жирных томов. Что либо найти в них можно было если только ты абсолютно точно уверен в каком именно томе искать. При этом нужно быть хорошо знакомым с используемой терминологией, а она там очень специфическая. IBM это вообще отдельный мир.
Это как с клавиатурой в банкомате — вроде 12 кнопок, должна стоить копейки, но нет — внутри криптопроцессоры, батарейки для хранения ключей и все залито эпоксидкой с проводками.
...при этом в недрах мейфрейма лежит плоский файлик с зарегистрированными в системе PAN (собственно, карточки), а в нём есть поле PIN offset, это произвольное значение, которое перед валидацией прибавляется к сгенерированному по криптографическому алгоритму PINу, и которое позволяет изменить его на любое другое значение. И это обычное числовое поле, открытое и доступное любому, кхм, кобол-программисту с соответствующими правами.
Вот именно. Просто исторически на i и z делали много бизнес-приложений. И приходится тянуть это легаси до бесконечности. Я с трудом себе представляю, чтобы сейчас кто-то в здравом уме решил новое приложение с нуля писать именно для IBM
А их никто и не пишет для IBM кроме самой IBM.
См выше. Кто использует эту систему из "крупняка". Там и гугл и амазон есть...
Поверьте, написать что-то работающее с БД и считающее деньги на RPG под ACку намного проще чем под какой-нибудь посгтрес на шарпе или расте под линуксом.
И работать оно будет быстрее на сравнимом железе.
Мне "поверить" не надо, я сам с iseries 10 лет работал... Что вы называете "работающее с БД и считающее деньги"? Это может быть приложение на 50 строк, а может быть огромная система.
Да даже если что-то и будет в моменте проще написать, если есть сильные спецы. Вот только поди найди этих спецов в достаточном количестве. Написать работоспособное приложение - это 10% дела. Его еще потом поддерживать надо. А вот как там, например, с отладкой в RPG? Появилось что-то новое по сравнению с пошаговым нажиманием Fx на зеленом экране? Я не особо спец по RPG, но все, что видел - это уровень 1990-х в лучшем случае. Время-то идет, IDE всякие появились, а IBM все там же.
Насчет быстрее на сравнимом железе - может и будут быстрее простые задачи, если использовать только record level. Да вот только под линуксом можно спокойно накинуть мощностей, сколько надо. А подите накиньте мощностей для iseries. Про уход IBM из России я вообще молчу. Ну а цены их серверов? В общем, нет-нет, и еще раз нет-нет.
С отладкой никаких проблем - хочешь в RDi, хочешь в VSCode (ставим IBM i Development Pack - там есть все, у нас есть свой iTools для VSCode - там помимо всего прочего еще куча нашей специфики наворочено). Все есть.
Не, я понимаю, что если слаще SEU и STRDBG ничего не пробовал, то оно конечно...
И мощностей тут накинуть проще на Power10. Просто цепляете еще одну машинку по PowerAXON и получаете всего больше - и памяти и процессоров и дисков. При этом система (современные версии от 7.5 и выше) все это будет поддерживать абсолютно прозрачно - вы не узнаете сколько там машинок сцеплено. Линуксу до такого как до Пекина...
Мне приходилось с БД разными работать (даже dsVista которая потом тала Velosis а сейчас RDM - Raima Data Manager) - и скулевые и не скулевые были. По ДОС, Вин, Линукс. И проще и удобнее чем это сделано на АСке с дибитухой я не встречал. Когда БД интегрирована в систему а язык нативно поддерживает все ее типы данных и обеспечивает как SQL, так и прямой доступ - это очень упрощает разработку.
Ну а уход... Много чего "ушло" из РФ. Но все равно оно тут есть :-)
Те сервера, на которые вы собираетесь ставить линукс - они тоже не в РФ делаются. И тоже денег стоят. А мощностей потребуется поболе (все это просчитано уже не раз).
И тем не менее...
"Nobody got fired for using IBM" (c) ...
for buying Oracle же :)
Когда появилась эта фраза, отцы основатели Orace еще писали в горшок. :) И у неё, кстати, есть продолжение: "But they should."
О том, что IBM это страшная монополия которая путем различных технических ухищрений (и избыточных усложнений) пытается удерживать свою поляну от посягательств со стороны, было известно еще в 70-х годах прошлого столения. Её несколько раз пытались разделить по типу Bell Labs, но не срослось. Однако волею случая она разделилась сама собой - "рынок порешал". :)
Да, только сразу вопросы:
1) Они с нуля эти серверы закупали в последние пару десятилетий? Или используют просто потому, что их системы писались еще в 20 веке, и приходится тянуть все это?
2) Какой процент от информационной инфраструктуры занимают IBM i? В списке Microsoft и другие очень большие компании. Может, там 1 сервер стоит на всю компанию, а уже можно включать в список, ведь используют же.
Я думаю, что там сидят разумные люди и считают деньги. И там, где выгоднее использовать эту систему - будут использовать ее потому что это выгоднее.
Если бы все было бы так плохо, у IBM просто не было бы возможности и потребности выпускать каждые несколько лет новый процессор, каждые пару лет новую версию ОС и регулярно (пару раз в год) минорные обновления (TR - Technology Refresh).
Т.е. рынок есть. Он специфический, нишевый, но достаточно стабильно развивающийся.
https://www.tectrade.com/articles/why-ibm-i-is-still-the-market-favourite/
Это мнение ложное. Ничем не обоснованое. Бла-бла-бла.
В качестве образцового примера «мягкой» модернизации COBOL‑систем стоит привести проект NN Group — одного из крупнейших европейских страховщиков. Вместе с Deloitte за 23 месяца они поэтапно перенесли свои ключевые страховые приложения с мэйнфрейма на современную Java‑платформу, не прерывая при этом работу сервисов. Сначала провели глубокий аудит существующего COBOL‑кода и составили карту зависимостей, затем автоматизировали рефакторинг и внедрили CI/CD‑конвейер для «плавающего» запуска новых модулей параллельно со старой системой.
История даёт хороший ответ, почему старые продукты живут десятилетиями, а современные по сто раз переписывают. Потому что МОГУТ. Во-первых, на новые ещё не потеряна вся документация, во-вторых, они изначально писались так, что в них проще вносить изменения.
Пост писался с помощью чатгопоты
Звучит как "кобол знаешь - работу имеешь".
Вот что значит "заCOBOLились" :)
Про COBOL ходит много легенд. Не смотря на то что в статье чувствуется GPT, она их хотя бы не повторяет. Со стека съехали давно кто мог, ничего в COBOL такого уникального нет кроме вендор лока. Это примитивный ЯП, все фишки в библиотеках, которые совсем не опенсорс, и завязаны на конкретный компилятор конкретной ОС.
Что-то у вас не едет я. Если COBOL это примитивный язык программирования , который был популярен в60-70 годы, то на нем активно писали от силы 20 лет. О его Смерти говорят уже дано, однако за прошедшие 40 лет, избавиться от него не смогли. Похоже это ЯП сделанный как надо для своего класса задач.
И вопрос на каком языке вы бы переписывали код в 90-х из тех что поддерживаются сейчас?
По поводу gRPC - сколько лет технологии как с неё мигрировать через 30 лет?
Там основной вопрос не в языке и нехватке программистов, а в том кто будет следующие 20 лет предоставлять поддержку
Во время Короны поконтрибьютил Open Mainframe Project, кое что написал, с некоторыми вендороми диалектов даже лично пообщался. COBOL как спецификация (COBOL-85) скуден но, примитивность сделала возможным транспиляцию в C (GnuCOBOL), .NET IL (vCOBOL) и JVM bytecode (isCOBOL). COBOL-85 изучается за 2 недели, а инфраструктура и процессы вокруг одной программы сколь угодно долго. Вместе с тем, миграция с Мейнфреймов как бизнес существует лет 40 и простые/дешевые кейсы уже давно выполнены.
Насчет комюнити. Тысячи индийцев по зову IBM зарегались на https://community.openmainframeproject.org/c/calling-all-cobol-programmers/15 в надежде заработать, и все еще периодически забегают в группу на ФБ в поиске работы. Из любопытства тогда прошел обучение Enterprise COBOL - IBM заказал у подрядчика Z Open Editor для VS Code, чтобы порог входа снизить. Поискал помимо основной работы практику в компаниях Германии и Швейцарии в стеке z/OS COBOL. Разослал более 20 резюме релевантным, в основном страховым и банкам, с проектами и библиотеками для 3 диалектов. Все HR ответили в ключе что в интернах не нуждаются. В группе лишь подтвердили что консалтинг гоняется за знаниями области, а не кодом COBOL, и потом выкидывает.
Не имею желания спорить. Для меня с техстеком все ясно. COBOL как экосистема была давно присвоена IBM. Специфическое железо, софт и жадность IBM сделала COBOL маргинальным в современном мире. Поняв, что укусила собственный хвост, компания начала срочно инвестировать в инструменты, обучение и сообщество. Но поздно, не смотря на периодические статьи про количество строк кода, умноженного на количество устройств. Люди держат экосистему живой, не корпорации.
Вы не поверите, но IBM COBOL особо не развивала. COBOL - это MicroFocus.
На IBM i (которая более популярна оказалась чем IBM z) COBOL есть, но на нем мало кто пишет - там более 80% кода на RPG (который чисто IBM'вский). Вот он развивается - нормальный процедурный язык со специфическими возможностями для работа с БД.
И маргинальность - не совсем то слово. Это нишевый, узкоспециализированный язык. Рынок замкнутый и ограниченный. И там, действительно, нужны знания не столько самого языка (он достаточно простой), сколько предметной области и систем на которых все это работает.
Да не поверили. Вот это Cobol для zOS: "IBM Enterprise COBOL for z/OS" https://www.ibm.com/products/cobol-compiler-zos
MicroFocus Cobol это не про ИБМ мэйнфрэйм (z). На z c CICSиспользуется Cobol от ИБМ.
И что? На IBM i тоже есть компилятор COBOL в рамках ILE. А еще есть компиляторы С и С++. Но это не значит что IBM их все развивает.
Активно развивает она свой RPG (который пытались портировать на другие платформы, в т.ч. VisualAge RPF for #NET, но без большого успеха). Вот там да. Постоянно что-то новое появляется.
Не поверите, но для работы с БД и коммерческих расчетов не нужны никакие библиотеки (в отличии от современных языков в которых вы не сможете данные по ключу из БД получить без внешних зависимостей). Там все уже есть в самом языке.
Вообще интересно, конечно, спорить с теми, кто с подобными вещами не сталкивался.
Вообще интересно, конечно, спорить с теми, кто с подобными вещами не сталкивался.
Вот-вот! Мы, работающие на IBM i/z, видим окружающий нас мир. И можем сравнивать решения одной и той же задачи на разных платформах, СУБД и языках программирования. И правильно вы написали - у IBM i/z своя ниша. И там где это требуется и техника закупается и специалисты находятся/выращиваются. И если бы эта ниша сокращалась - не развивалась бы ни техника ни COBOL. А для тех кто лично не знаком это - легаси большой чёрный ящик, о котором говорят что он очень дорогой и писать надо на устаревшем языке". Я, на пример, знаком с проектом, в котором таблицы по несколько миллиардов записей. И даже интересно какая платформа в начале 2000-х годов была на такое способна, да ещё и совместить OLTP с приемлемым OLAP.
Что такое "полный переписок"?
Кобол - он не только мейнфреймы, в нашем биллинге у одного желто-полосатого оператора был миллион строк на нём (и десять на Си) на вполне себе Solaris/SPARC/Oracle.
Все эти транспиляторные решения - ну такое себе. Компаниям обычно дешевле оказывается научить новых людей Коболу, чем поддерживать сгенерированный "переведённый" код. А некоторые - мы вот GNU COBOL использовали - вообще почти нечитаемое генерируют
Статья явно перевод. Более того вроде бы статья про zOS, CICS и вдруг:
... В 2023 году появились и свежие уязвимости: CVE‑2023‑4501 в составе Micro Focus Visual COBOL и Enterprise Server допускала обход аутентификации и давала злоумышленнику путь к критичным функциям. Банки и госструктуры вынуждены экстренно выпускать ночные патч‑релизы, чтобы не допустить простоев и утечек данных.
MicroFocus COBOL это не про zOS, CICS. В zOS вообще нет уязвимостей которые надо было бы патчить ночью. Интернет вроде сообщает про MicroFocus Cobol for zOS, но нормально использовать вот этот: "IBM Enterprise COBOL for z/OS".
Наконец, растущий тренд — гибридное размещение: «горячие» онлайн‑транзакции продолжают своё дело на доказанном z/OS, а тяжёлые batch‑задачи переселяются в облако. Баланс выдерживается легко: экономятся ресурсы мэйнфрейма, новые сервисы запускаются быстрее, а проверенная бизнес‑логика остаётся под надёжной защитой.
Нет такого тренда. И не нужно. В zOS, c правильно настроенной WLM полиси, онлайн транзакции прекрасно уживаются с "batch-задачами". Трескотня какая то словесная право дело.
Вся IRS сша работает полностью на коболе + mainframe. Запросто сжирает миллионы транзакций в секунду.
Почему COBOL так живуч
Не поломано — не чини!
Хороший пример этого можно наблюдать во время пандемии. В первые дни Covid-19 бизнесы массово закрывались. Уволенные сотрудники рванулись онлайн, чтобы подать заявление на получение пособий по безработице, и веб-сайты многих правительств штатов не выдержали нагрузки. Губернатор Нью-Джерси сообщил прессе, что их системы COBOL отчаянно нуждаются в помощи, чтобы справиться с новыми потребностями. «У нас в буквальном смысле есть системы, которым от сорока и более лет», — заявил он.
Но технологи, работавшие за кулисами над устранением неполадок, знали, проблема заключалась не в перемалывающем числа COBOL. Эти старые системы работали хорошо. Нет, всегда ломались более новые элементы — программы, управлявшие самим веб-сайтом.
«С ума сходило веб-приложение между мейнфреймом и внешним миром. Именно оно падало», — рассказывает программистка и писательница Марианна Беллотти, годами работавшая с государственными системами и следившая за этой системой Нью-Джерси. Но, по словам историка Хикса, властям было слишком неудобно признать «ой, да, это сломались наши веб-системы».
Я писал на русском Коболе для Минск-32. Целый год!
Самый подходящий язык для реализации всяких АСУ предприятия.
COBOL в XXI веке: почему банки и госслужбы не могут отказаться от языка 1959 года