Comments 74
Проблема ведь не в синтаксисе, если бы дело было только в этом, то проблемы не было бы вообще — горшки не боги обжигают, и нет никакой проблемы в том, чтобы выучить COBOL, как люди учат С или Lua. Подозреваю, что настоящая ценность коболистов вовсе не в самом Коболе, а в понимании работы систем, которые на нем написаны — им не нужно вникать с нуля, поэтому они могут выполнить работу в разы быстрее и потому дешевле, за что их и нанимают. Ситуация примерно как с 1С-программистам, основная ценность которых не в том, что они умеют программировать кириллическими буквами, а в значении самой предменой области.
Я так понимаю, нормальных обучающих материалов нет, нормальной IDE нет, open-source проектов нет, доступа к нативной среде исполнения (мейнфреймы) в обучающих целях тоже нет, как и актуальной документации к ним в открытом доступе. Практически 100% вакансий - работа над критическими системами в крупном энтерпрайзе (банки, страховые и т.п.), в таких местах джунов-мидлов не нанимают в принципе, а проектов, на которых можно набраться опыта - не существует. При том что спрос, несмотря на "рост", все равно ничтожен - перспективнее разобраться в очередном JS-фреймворке.
У меня в анамнезе есть 3 года подтвержденного опыта на COBOL over VAX/VMS, в конце 90-х. Каждую осень — несколько входящих с предложениями на такие деньги, которые мне в Европе никогда не получить.
Основная проблема — эта работа сезонная, контракт «до нового года», залатать дыры для генерации отчетов. Предложений на постоянку я не видел уже лет 15.
Что значит “не пускает”? Учите Кобол, никто не запрещает. Почему вы до сих пор не изучили?
Порог входа высокий, а рынок относительно небольшой.
При этом сам язык Кобол у меня, например, с детства вызывает физиологическое отвращение, хотя я люблю мейнфреймы и всякий винтаж.
1) "Для состоявшегося в IT спеца, желающего сменить стек, никакая IDE не проблема" - только если проблема не вида что раньше была IDE, а теперь можно сказать что нет. Инструменты гораздо менее развиты.
2) "Мейнфреймы нынче в вируталках" - эмулировать нормально так и не научились, в виртуалках что-то что поможет написать helloy world но не более
3) "Отсутствие документации" - так же как и с IDE - в сравнении можно считать что ее нет.
ПС. Watsonx Code Assistant еще пару лет назад был очень сомнителен. А пилить его начали чуть ли не 10 лет назад - сомневаюсь что сильно продвинулись
нормальной IDE нет, open-source проектов нет, доступа к нативной среде исполнения (мейнфреймы) в обучающих целях тоже нет
Написал уже ниже. Регистрируемся на на POUB400.COM, ставим VSCode + IBM i Development Pack и получаем все что надо. Так что сказки все это.
Другое дело, что да. Придется думать самому и писать самому. А не лепить из готовых кирпичиков по-быстрому.
в таких местах джунов-мидлов не нанимают в принципе
Да ладно? У нас вот нанимают. Не КОБОЛ, но... Писать банковскую логику на RPG под IBM i (и да, компилятор КОБОЛ тут тоже есть).
Варианта два - если совсем без опыта - стажером на полгода. Если с опытом разработки - просто первые три месяца "испытательный срок" (в полной оплатой и всеми делами) - фактически обучение (будет наставник персональный, план обучения) конкретному языку и платформе.
перспективнее разобраться в очередном JS-фреймворке
Естественно. Там не будут каждую поставку через нагрузочное тестирование прогонять и придираться к каждому проценту утилизации CPU. Там можно выучить пару фреймворков и вперед - "херак-херак и в продакшн".
"open-source проектов нет"
Есть. https://sourceforge.net/projects/gnucobol/
Кобол отличный язык если вам нужно перерабатывать заумные текстовые формы с полями данных
с точностью до позиции. Ввод-вывод таких документов - его конек.
Рынок не перенасыщенный и массовых увольнений не было.
в ней примут участие уже не только избранные, т. е. программисты на COBOL
А какой смысл им убивать свою востребованность?
А какой смысл программистам делать нейронки для написания кода? Тоже ведь убивают свою востребованность.
Для обучения нейронки необязательно ведь нужен опытный заинтересованный программист.
А если обучает и такой, то может и сомневается, что что-то выйдет, зато деньги получает.
Это действительно интересный вопрос — кто обучает нейронку для замены своей профессии.
Какой-нибудь транслятор выглядит более реализуемым, чем нейронки, способные полноценно заменить программиста.
Наверное разово можно заработать много больше, чем за годы поддержки. Да и сроки миграции могут быть не маленькими.
COBOL. На Java... Примерно то, что где-то активно в 2010-15 годах делалось с сомнительным успехом (из-за специфики организации памяти в коболе, которую проще на C перенести, чем на Java). И тут внезапно проявился "ассистент" для переноса... Ну просто ахренеть
Эту песню про уход Кобола с рынка я слышу последние 30 лет.
А что касается конкретной технологии кросс-компиляции на другой язык, то я в своей жизни не видел ни одного примера, когда бы кто-то пользовался результатом такого процесса, хотя идея отнюдь не нова. Как верно замечено в комментарии выше, вопрос же не в том, чтобы поменять синтаксис операторных скобок. 99% текста легаси программ вообще низачем не нужно в современных условиях, и глупо его переписывать (это будут, скажем, манипуляции с блоками DSCB, или переименования файлов, или выделение памяти руками через анус, или какая-нибудь ещё дичь). Но весь код вместе с исполняющим его окружением обладает системным эффектом пригодности для решения задачи.
Есть некоторые мифы о Коболе, гуляющие из статьи в статью.
Коболов, а именно их диалектов, несколько. Полной совместимости они не имеют. Тот диалект, про который обычно журналисты пишут - это IBM Enterprise Cobol. Компилятор его доступен только на мейнфреймах, разработка и отладка либо через терминал, либо через плагин для VSCode, который делал подрядчик из Чехии. Этот плагин реализует клиента АПИ к Z/os.
Курсы и документация есть. Смотрите на Гитхабе OpenMainframe Project. В рамках курса IBM даёт аккаунт на мейнфрейм. Но не все современные практики разработки применимы. Репортил ребятам чтобы ненулевой код возврата клиент отдавал, для построения нормального CICD, но понимания не встретил. Нет юнит тестов, нет привычного дебаггера с брейкпойнтами, культуры документирования и версионирования.
Люди есть. В начале пандемии СМИ тиражировали статьи что все пропало и последние разрабы умрут. На клич подтянулся народ, в основном из Индии, и зарегистрировался в проекте OpenMainframe. Около 2k профилей, но работы для них не нашлось.
Потому? Дело не в программерах. Ванильный Кобол, а именно спека COBOL85, прост как валенок, хватит и пары недель чтобы начать на нем писать. Сложность в тотальной закрытости стека и утрате знаний о бизнес процессах, куда эти кобольные модули встроены.
Бизнес портирования в Яву существует минимум лет 20. Главным игроком в нем является MicroFocus. Они пылесосят носителей знаний и предлагают перенос бизнес процессов. В группах жаловались, что после отжима знаний консультанта выкидывают "на мороз".
Компилятор его доступен только на мейнфреймах
Не только на менфреймах (IBM z), но и на миддлваре (IBM i). Не знаю точно какой там диалект, но КОБОЛ там есть, входит в группу языков ILE (интегрированная языковая среда) - COBOL, RPG, CL, C/C++
разработка и отладка либо через терминал, либо через плагин для VSCode, который делал подрядчик из Чехии
Для IBM i есть плагин IBM i Development Pack с поддержкой всех языков ILE. В т.ч. и КОБОЛ. Ну или через RDi - IDE от IBM на базе Eclipce
В рамках курса IBM даёт аккаунт на мейнфрейм.
Для IBM i есть публичный бесплатный сервер PUB400 - регистрируетесь, получаете аккаунт и работаете.
нет привычного дебаггера с брейкпойнтами
Привычный - это какой?
Для IBM i отладка возможна как в IDE (RDi, VSCode с плагинами), так и в терминале (встроенный отладчик STRDBG). С брейкпойнтами (в т.ч. и сервисными когда можно отлаживать программы, работающие в других заданиях, например, фоновых), отслеживанием изменения состояния переменных и т.п. Функциональности вполне достаточно.
Сложность в тотальной закрытости стека и утрате знаний о бизнес процессах, куда эти кобольные модули встроены.
Так это все равно на чем оно написано. Тут не в языке дело.
Дебаггер, например, такой https://marketplace.visualstudio.com/items?itemName=OlegKunitsyn.gnucobol-debug
Да, бизнес модель такая. Которая перестает работать когда кто-то начинает играть иначе, по правилам сотрудничества, открытости и равноправия. Не сочтите за политику, а то уже прилетало в карму. :)
В группах жаловались, что после отжима знаний консультанта выкидывают "на мороз".
После обучения английскому репетира тоже "выкидывают", но разве это странно? Зачем кому-то учиться всю жизнь у одного учителя?
Изучать и дебажить можно на OpenVMS еще
COBOL первой свежести.
https://publibfp.dhe.ibm.com/epubs/pdf/igy6lr40.pdf
Fourth edition (31 August 2023 update)
Интересный факт:
в 1977 г. был принят отечественный стандарт на язык программирования КОБОЛ (ГОСТ 22558-77).
Нам COBOL преподавали в академии, и учебники по этому языку писали наши преподаватели:
Столько лет прошло, а мы говорим о COBOL-е. Интересно бы знать, что будут говорить через очередные 50 лет!
Через еще 50 лет ИИ оставит человеков жить лишь потому, что среди них надо будет искать тех, кто сможет поддерживать КОБОЛ.
Все эти ситуации в своё время (задолго до появления сегодняшнего понятия ИИ) описал Рэй Бредбери. Чего стоит один его рассказ "Вычислитель":
Я им не угоден или не нужен, — сказал он. — В наши дни машины лучше. На кой им черт старикашка, вроде меня, к тому же пристрастившийся к марсианской выпивке? Ни на кой! А машина не стареет, не выживает из ума и не напивается до чертиков!
Да. Я считаю, что сюжет фильма «Матрица» достаточно глуп — якобы энергию из людей собирают, подключив их мозги к Матрице. Разве для этого людям нужно создавать реалистичное окружение?
Гораздо правдоподобнее выглядит так: ИИ держит огромные фермы людей для создания обучающих выборок. С этой целью создаёт человеческим мозгам нужные окружения, разные ситуации, записывает реакцию.
Хм, а Java это точно удачный выбор? Наверняка в написанном на COBOL софте есть много взаимодействий с железом, которые будут переписаны... на JNI? В идеале для таких надёжных и требовательных систем бы взять Rust (да простят меня хейтеры языка), может куда интереснее получиться.
Крайне неудачный.
Эти системы в большинстве своем достаточно высоконвгружены и требуют предельной эффективности.
Прямой работы с железом там нет. Но арифметика на 99% с фиксированой точкой. В т.ч. операции типа "присвоение с округлением".
Также очень много занимает работа с БД. Как непосредственно с файлами (позиционирование по ключу и т.п.), так и средствами embedded sql (как статического, что быстрее, так и динамического когда других вариантов нет).
Все это реализовано на уровне языка.
Поактически нет динамической работы с памятью - выделение/освобождение суть лишние накладные расходы снижающие эффективность.
Ну и, наконец, в итоге получаем полноценный и быстро работающий программный объект, не требующий JVM, которая сама по себе ресурсы жрет.
Я бы ещё добавил, что Java тоже не образец обратной совместимости, и если сейчас кого-то беспокоит, что есть три диалекта Кобола, то через 40 лет будут легаси системы на 10 несовместимых версиях Java, и для каждой будут нужны свои специалисты, вот уж решили проблему, называется.
С чего это вдруг? Можете прямо сейчас скачать JDK 1.2, скомпилировать им что-нибудь и запустить на JRE 17. Можно и наоборот, так как все новые возможности в язык добавляются без нарушения совместимости. Единственная проблема, на которую можно наткнуться - желание новых JRE работать с модулями при отсутствии модульной системы до Java 9. Ничего более совместимого в мире просто нет.
Увы, если бы это было так, но это даже близко не так. У меня есть JAR-файлы, которые прекрасно работали на 1.4, но не работают на 17. Ещё одна точка отсчёта -- Java 8, для которой тоже немало софта, не работающего под 17.
Мне надо раскопать архив, чтобы привести примеры, но это вот прямо настолько общее место в личном опыте, что даже странно слышать обратное. Стандартная история -- держать по четыре версии JVM на случай запуска того или иного софта.
Крайне интересно было бы услышать примеры. Пишу на Java уже лет двадцать, но с проблемами несовместимости не сталкивался ещё ни разу. Если не считать уже упомянутый Jigsaw.
Например, у меня есть программы на Java, которые используют работу через jdbc работу с клиентом СУБД определённой версии, которая в настоящее время не поддерживается. Это не проблема самого языка Java, но реальный фактор, ограничивающий жизненный цикл приложений. А мейнфрейм бинарно совместим с 1966 года.
Где-то у меня лежит java-сервер для линейки, который емнип не запускается выше седьмой версии. Если интересно, могу попытаться его выкопать, попробовать запустить и, не знаю, логи ошибок вам выложить?
Буду признателен.
Понял: сегодня-завтра найду и отпишусь.
(Крайне озадаченно)
Он заработал… Вот теперь пойди и пойми, где что было не так: то ли я тогда что-то делал неверно, то ли совместимость поправили, потому как сейчас у меня java -version 1.8; проблемы были то ли на 1.7, то ли на 1.6, а писан этот сервак на 1.4. Помнится, тогда специально искал, скачивал и бережно хранил старую версию рядом с дистрибутивом сервака. И я точно помню, что со старой версией работал без проблем, а на более новую ругался.
Ошибки кидает, метод replace(char, char) в java.Lang.String отказывается принимать аргументы (java.Lang.String, java.Lang.String) — но запуститься это ему во всяком случае не помешало. Ну и клиент игры коннектится, проверил.
Полдня вспоминал, как его ставить, как клиент патчить… Ностальгия!
JDK ломали обратную совместимость даже в рамках одной версии:
https://github.com/McModLauncher/modlauncher/issues/91
Работало на версии 8u312, перестало на 8u321.
Не ломали. Пакет sun не является открытым API и его совместимость не гарантируется. Авторы лаунчера сами себе злые буратины.
Ну вот, например, есть у меня такая программка. Она отлично компилируется с помощью JDK 1.5 2005 года, но не хочет ни одной современной версией. Я уже не помню, в чём конкретно проблема, т.к. она возникает в недрах 3rd-party компонента (JAR), но как-то связано с поломкой совместимости в Swing. Впрочем, в чём бы ни была причина, мне от этого было бы не легче :)
Интереса ради попробую разобраться. Но обычно проблемы в 3rd-party связаны с их любовью опираться на детали реализации внутреннего API. От этого не застрахован ни один язык и ни одна платформа.
Это 3rd party в том смысле, что не я писал, поэтому и не в курсе подробностей. Но там никакой магии, обычная open source библиотека JGraph 2.1, которая к пятой версии "починилась", а теперь вообще выросла в diagrams.net.
Вот вдогонку ещё пример: отсюда берётся jar 1.2, далее вызываем
java -jar omp4j-1.2.jar w08_ompPrimes.java
(исходник). У меня это отлично работает на Win11 под OpenJDK11 и OpenJDK19, но не работает под AdoptOpenJDK16, например.
Опять же, 3rd party, но ничего гениального; ну и да, такой софт есть, и вот я представляю себе, как с ним будут возиться через 30 лет. Потребуются специалисты по "деталям реализации API" всех мажорных версий.
Но вообще, Java ещё не худший вариант. Куда хуже (имхо), чем C# с точки зрения обратной совместимости, но на четыре головы лучше Unity, например.
Глянул я бегло на cpv-src, проблема с совместимостью действительно есть, но не в языке, а в библиотеке Swing. Где-то между Java 1.3, под которую скомпилирована библиотека JGraph, и Java 8 изменилось API класса javax.swing.TransferHandler. Всё ещё не думаю, что в мире есть развивающиеся библиотеки графического интерфейса, которые сохраняли API неизменным в течении четырнадцати лет. Как и не думаю, что эти изменения требуют отдельных специалистов по разным версиям Java.
Ну, имеете право на мнение. "Не в языке, а в библиотеке Swing" -- не совсем аккуратное замечание, библиотека Swing является такой же частью языка, как Integer или sqrt(), поэтому не считаю возможным считать какие-то куски Java platform "равнее" других. Сам я пользуюсь джавой крайне редко, поэтому не думаю, что мне вот так повезло, что сходу наткнулся на единственную несовместимость.
Но это же в целом история о другом. Несовместимость не приговор, в Python вообще всё плохо, и все об этом знают. Но если платформа подаётся именно как совместимая, это же selling point, и я думаю, надо держаться за совместимость. Данный случай показателен тем, что совместимость нарушена не ради секьюрити или исправления бага, а вообще не пойми зачем -- какой-то второстепенный класс в недрах системы, так что отношение к пользователям не радует.
щас бы автоматически переписывать на язык, на котором всё лопнет при попытке компиляции, платформа под которую надо работать не поддержана, а на следующем релизе код перестанет работать
Целевую платформу, вероятно, выбирал маркетинг. Дотнет и ява корпорациям ближе, но ява во времена принятия решения была более открытой и портируемой. Например, у GnuCOBOL нет своего компилятора, он транспилит в С, который компилируется уже тем что есть в системе.
Джва не дотянет. Там, где сократить общее время утилизации процессора на 3-5% считается хорошим результатом, аредаочтение всегда будет отдаваться языкам, выдающим полноценный исполняемый код.
GnuCOBOL вообще не в тему - это поделие для студентов. На используемых в данной области платформах есть нативные компиляторы.
О, нашел свой коммент 2020 года:
На сейчас живых (разрабатываемых и выпущенных в 2020) COBOL диалектов 7:
IBM Enterprise COBOL
Fujitsu NetCOBOL
Envyr ICOBOL
GnuCOBOL
Micro Focus Visual COBOL
Veryant isCOBOL
Raincode COBOL
Первые три имеют собственный компилятор в нативный рантайм Windows (NetCOBOL, ICOBOL), Linux (NetCOBOL, ICOBOL), Z/OS (Enterprise COBOL). Последние три исполняются в .NET, .NET Core и JVM.
Обесценивать вклад Simon Sobisch (немного с ним знаком) и других контирибьютеров в GnuCOBOL и экосистему Кобола вцелом несколько высокомерно. Технологии без людей мертвы. IBM сам же это и продемонстрировал.
Технологии без людей мертвы.
Технологии мертвы когда они не используются в реальных приложениях.
Сколько реально работающих коммерческих приложений написано на gnuCOBOL?
И сколько на IBM Enterprise COBOL... Просто сравните.
Тут еще надо понимать историю откуда все это взялось.
Когда большие компьютеры начали внедряться в коммерческие структуры потребовался язык для реализации именно коммерческих вычислений со всеми их особенностями. И вот тогда появился COBOL (аналогично тому как для математических расчетов был создан FORTRAN) случился "большой взрыв" - повальная автоматизация банков и крупных коммерческих структур.
Тут надо понимать что КОБОЛ не является языком общего назначения, но специализированным языком. И в этом у него не было конкурентов
За годы было написано огромное количество кода, который работает до сих пор. Это старый, быстрый, до блеска вылизанный код. И заменить его не так просто - это не просто переписать все, это еще все оттестировать по полной программе. И убедиться, что оно не только работает правильно, но и как минимум не медленнее на том же железе. Огромные затраты ресурсов, которые не окупятся.
И еще надо понимать, что под Win или Linux COBOL никому не нужен. Целевые платформы там, где он нужен, совсем другие - это или мейнфреймы типа IBM z, или мидлваре типа IBM i там, правда, у COBOL есть мощный конкурент - RPG на котором написано и пишется более 80% кода под эту платформу, который по возможностям для коммерческих расчетов как минимум не хуже COBOL но активно развивается и сейчас представляет собой нормальный процедурный язык (в синтаксисе четко ощущается привкус PL/I). И, кстати, это уже личный опыт, в своей области по быстродействию и ресурсоэффективности он как минимум не хуже С (а на С++ еще постараться надо чтобы оно было столько же быстрым и эффективным - минимум динамичесой работы с памятью, минимум всяких "безопасных копий объектов", минимум исключений). И что характерно, в том же RPG фактически нет UB, коими изобилует С/С++.
Было бы интересно почитать про архитектуру таких систем и требования к ним. Выжимание рантайма до такта выглядит как вертикальное масштабирование. Но оно имеет предел, в том числе и экономический, поэтому сейчас так бурно развиваются распределенные системы. Когда-то давно попалась история архитектуры Гугла, когда они решили вместо больших дорогих ящиков ставить много дешёвых.
Здесь также. Почитайте про новые процессоры Power10.
Если кратко на пальцах, то там есть возможность объединения нескольких машин фактически в одну высокопроизводительной шиной. Контроллер шины непосредственно на кристалле процессора (т.е. фактически вы "сцепляете" процессоры друг с другом). При этом общим становится все, включая память. И для конечного пользователя все это выглядит как одна машина.
Но дело не в этом. Дело в том, чтобы то, что можно сделать просто написав оптимальный код без затрат на новое железо, должно делаться оптимизацией кода. Это быстрее и дешевле. Никто не побежит покупать новую машину в кластер только потому что кому-то по голове ударило концептуальностью и он наворотил 100500 уровней абстракций там, где это совсем не нужно.
Речь в целом идет о том, что есть вполне специфические задачи. И для решения этих специфических задач есть специализированные языки, наилучшим образом для этих задач предназначенные.
Если "приблизить физику к кухне". Вот бывает цепная пила, бывает циркулярная, бывает лобзик. Вам нужно порезать большой лист фанеры на прямоугольники. Можно сделать это цепной пилой, но получится плохо. Можно лобзиком, но получится криво. А можно это ровно и быстро сделать циркуляркой.
А вот попилить дрова можно и циркуляркой, но неудобно - тут лучше цепная пила подойдет.
Так и здесь. Зачем искать какие-то библиотеки для джавы для работы с фиксированной точкой и плодить зависимости, когда у меня в том же RPG такие типы поддерживаются на уровне языка.
Аналогично для работы с датами и временем - есть типы, есть набор функций (арифметика, поддержка конвертации в разные типы, поддержка множества форматов). Операция типа "взять дату в виде строки в формате EUR (DD.MM.YYYY) вычесть из нее один месяц и вывести в строку в формате ISO (YYYY-MM-DD)" пишется в одну строчку средствами языка.
Но на самом деле все еще сложнее. На используемой нами платформе (IBM i) используется ILE которая поддерживает несколько языков - RPG, CL, COBOL, C, C++. И все ILE компиляторы генерируют одинаковый код в MI (ассемблер тут недоступен на пользовательском уровне). В результате получается т.н. "модуль" (аналог объектного файла). Несколько модулей собираются (bind) в один программный объект (pgm) и тут уже все равно на каком языке написан тот или иной модуль.
Совершенно нормальным является писать на (например) RPG то, что удобнее писать на RPG, на С то, что удобнее писать на С (например, какие-то низкоуровневые вещи) и потом объединять это в одну программу. Тут главное правильно прототипы описать для вызовов функций на разных языках. Еще более того - я из кода на RPG могу вызывать любую функцию из, например, С-шной библиотеки просто описав ее прототип. Пример:
//==============================================================================
// Текущее время в секундах с точностью до мкс
//==============================================================================
dcl-proc GetTime;
dcl-pi *n packed(16: 6);
end-pi;
dcl-ds t_dsTimeVal qualified template align(*full);
tv_sec int(10) inz;
tv_usec int(10) inz;
end-ds;
dcl-ds t_dsTimeZone qualified template align(*full);
tz_minuteswest int(10) inz;
tz_dsttime int(10) inz;
end-ds;
dcl-pr GetTimeofDay int(10) extproc(*CWIDEN : 'gettimeofday');
dsTime likeds(t_dsTimeVal);
dsZone likeds(t_dsTimeZone) options(*omit);
end-pr;
dcl-ds dsTimeVal likeds(t_dsTimeVal) inz(*likeds);
dcl-s pktTime packed(16: 6) inz(*zero);
dcl-s fltSecs float(8);
dcl-s fltUSecs float(8);
if GetTimeofDay(dsTimeVal: *omit) = 0;
fltSecs = dsTimeVal.tv_sec;
fltUSecs = dsTimeVal.tv_usec;
fltUSecs /= 1000000;
pktTime = fltSecs + fltUSecs;
endif;
return pktTime;
begsr *pssr;
dump;
endsr;
end-proc;
Нужно мне в RPG время в формате секунды.микросекунды в переменной с фиксированной точкой (packed(16: 6) - 16 знаков, 6 после запятой). Ок. Используем сишную функцию gettimeofday просто описав ее прототип так, что его понял компилzтор RPG
dcl-pr GetTimeofDay int(10) extproc(*CWIDEN : 'gettimeofday');
dsTime likeds(t_dsTimeVal);
dsZone likeds(t_dsTimeZone) options(*omit);
end-pr;
указываем что GetTimeofDay на самом деле есть внешняя функция gettimeofday. И это работает.
Но и это еще не все. Каждый программный объект кроме исполняемого кода содержит еще MI код из которого он был сгенерирован. И метку для какого процессор он был сгенерирован. Переносим программу с машины на Power9 на новую машину на Power10, запускаем и при первом запуске система видит что исполлняемый код для другого процессора и автоматом его перегенерирует из MI под текущий процессор. Т.о. автоматом всегда получаем оптимальный исполняемый код для той архитектуры на которой сейчас работает программа.
И вы предлагаете от всего этого отказаться и переписать все на джаву потому что это сейчас модно? Серьезно? Вы потратите на это куеву хучу времени и сил. Вам придется решать куеву хучу проблем - "а как это написать на джава если в ней и близко нет ничего подобного"? Потом нужен полный ретест (компонентный, бизнес, нагрузочный, интеграционный...) всего что переписали... И в итоге что? Будет оно быстрее работать? Ой не факт... скорее всего нет (т.е. пройдите в кассу и купить еще пару-тройку серверов?).
И все ради чего? Чтобы была возможность нанимать джава-джунов, которые вам кривыми руками запоганят все что с таким трудом переписали?
Наша практика показывает что если взять человека с опытом разработки (не важно на чем, лишь бы умел читать ТЗ и переводить его в алгоритм), то через полтора-два месяца он осваивает базовые принципы и синтаксиc того же RPG + основы работы в системе IBM i (которая вообще ни на что не похожа - там "все есть объект", свои принципы организации файловой системы, и вообще все свое) и готов решать несложные "боевые" задачи. А через год-полтора это уже крепкий мидл (а то и сеньор, в зависимости от начального опыта).
И это проще и дешевле, чем натягивать сову на глобус и пытаться все переписать под "современный модный стек" который по большому счету не является нативным для этой системы.
Тем временем НСПК (Карты МИР) не согласится с вами, что Java плохой выбор для решения таких задач.
https://habr.com/ru/companies/oleg-bunin/articles/695262/
У Java есть главное преимущество, нет привязки к конкретному типу аппаратного обеспечения.
Обрабатывает более 50 миллионов операций;
Генерит более 3 000 различных файлов и отчётов для банков;
Получает данные из большого количества ключевых систем Мир Plat.Form, а также является источником транзакционных данных;
Обеспечивает строгий SLA на каждом этапе работы. Так как важно, чтобы все расчёты происходили точно, в срок и без ошибок.
Ну ок. А теперь смотрим всего лишь один банк. Точнее, даже не весь банк, а только ядро АБС.
27 тыс. программных объектов
15 тыс. таблиц и индексов базы данных
Более 150 программных комплексов
Занимает более 30 Терабайт дискового пространства
В день изменяется более 1,5 Терабайт информации в БД
За день выполняется более 100 млн. бизнес операций
Одновременно обслуживается более 10 тыс. процессов
только в процедуре закрытия дня производится более 500 миллионов изменений в БД
И банк - это не только счета-проводки. Это огромное количество клиентских данных. Это контроль каждого платежа. Это огромное количество отчетов (3тысячи? Ха... детский лепет), это рассылка различных уведомлений (как клиентам, так и различным структурам) в самых разных форматах.
И все это только один банк (ну пусть крупный, пусть из топ-10, но все равно один банк).
Думаете не пробовали джаву? Пробовали. Не тянет оно. Жрет ресурсы как не в себя и тормозит. В результате она осталась на всяких внешних системах (коих в банке порядка 60-ти штук) которые не являются mission critical. А на ядре совсем другой стек.
Те числа, которые вы привели, вполне соразмерны показателям АБС сбера, который тоже весь работает на джаве и по большей части на х86.
Просто для перехода надо взять и заварить кашу на весь банк в десять лет длительностью. В рыночных условиях это сложно.
Естественно. Банки сравнимы. Вопрос в том, сколько серверов у сбера и сколько у нас :-) И во сколько обойдется сберу перенести все на новые сервера и во сколько это обойдется нам (опыт перехода с 8xx серверов на 9хх у нас есть - ничего страшного в этом нет).
Ну я не могу с уверенностью сказать что у сбера джава именно на уровне ядра АБС...
слушайте, джава очень много где и все ее недостатки известны, это дополнительная память и медленный старт. ну и еще унификация, из-за которой у вас может не быть какого-то модного api из OC, или если вы прям очень много делаете запросов к какому-то другому нативному коду, например в dll. так что все эти рассказы про тормозящую java рассчитаны на тех, кто в середине нулевых застрял :) в худшем случае вы потеряете по скорости в 2 раза (если мерять приложение целиком), но при этом получите огромное количество плюсов начиная от написания кода, заканчивая средствами мониторинга и управления.
паузы уже починили со сборщиком zgc, они меньше миллисекунды.
в принципе и с памятью/временем старта тоже разобрались через нативную компиляцию с graalvm.
если вы прям очень много делаете запросов к какому-то другому нативному коду, например в dll
Банковская система - это не одна большая программа. Это куча разных модулей запускаемых для выполнения конкретных задач (тут ближе всего модель акторов). Большинство модулей job-isolatetd - работают в разных заданиях (выпадение в дамп одного вообще никак не влияет на все остальное). Но они между собой все взаимодействуют разными способами (а способов тут очень много всяких и разных, например, в системе есть такой объект как USRQ - пользовательская очередь, очень удобно для организации всяких конвейеров, но работа с ним только на низком уровне через MI).
в худшем случае вы потеряете по скорости в 2 раза
Для наших реалий это катастрофа.
Делал тут комплекс проверок для системы расчетов (контроль платежей). Плотность вызовов зашкаливает (каждый платеж идет через эти проверки). Нагрузку прошли, внедрение согласовано. Но анализируя (для себя уже) PEX-статистику (результат нагрузочного тестирования), увидел одну вещь, которая не понравилась. Потратил немного времени, переписал. В итоге:
Утилизация ЦП на 1 вызов (до/после):
CPOCHK#ACC - 372 мксек / 357 мксек
CPOCHK#BAN - 1,5 мксек / 0,4 мксек
CPOCHK#CRE - 200 мксек / 88 мксек
CPOCHK#DEP - 39 мксек / 37 мксек
CPOCHK#INR - 0,9 мксек / 0,2 мксек
CPOCHK#MIN - 6,8 мксек / 4,5 мксек
CPOCHK#RR - 13 мксек / 8,4 мксек
CPOCHK#SGM - 9,5 мксек / 6 мксек
CPOCHK#SPI - 6,3 мксек / 2,4 мксек
CPOCHK#WHL - 8,9 мксек / 5,8 мксек
CPOSRVPGM / CPOCHK#HD - 51 мксек / 38 мксек
Заключение
Доработка положительно влияет на производительность функционала.
Совокупное потребление процессорного времени сократилось на 20%.
Вот за что бьемся. И это не потому что "сервер не тянет". Просто есть нормативы внутренние на предельную загрузку сервера. Запас по процессору должен быть всегда. Даже в периоды пиковых нагрузок. Это надежность и безопасность. Поэтому любой код должен быть максимально эффективен прежде всего.
А вы говорите в два раза...
но при этом получите огромное количество плюсов начиная от написания кода, заканчивая средствами мониторинга и управления
Какие именно плюсы в "написании кода" я получу?
Что касается мониторинга и управления, то тут он и без того хорош. Просто не сталкивались с подобными системами. Тут все работает в отдельных заданиях - зашли терминалом на сервер - вот вам задание. Запустили что-то в фоне (submit job) - вот еще одно задание. У каждого задания могут быть свои настройки и права...
Система позволяет мониторить все - видеть джоблоги в реальном времени, видеть статус каждого задания и сколько ресурсов оно потребляет (процессор, ввод-вывод, открытые файлы и т.п.), управлять заданиями (вплоть до принудительного закрытия).
Никакая джава не даст вам таких возможностей.
Поэтому любой код должен быть максимально эффективен прежде всего.
любой код должен в первую очередь работать без ошибок, потом желательно чтобы он был понятным остальным, потом чтобы он работал и через 30 лет на другом железе, те его не пришлось переделывать заново. потом можно уже и на скорости заморочиться. эффективность важна там где есть прямая зависимость на прибыль. ну те если бы из-за просадки в скорости на эти 2 раза платежи не проходили и люди доставали налик - да, а так вопрос только в цене покупки второй машины. если она стоит 5 миллионов, а зп в фирме 500 и работает с десяток человек, то да, эта оптимизация имеет смысл, иначе - нет. не так просто большие компании сидят на java, например twitter, им проще заниматься ее оптимизаций, чем писать все на плюсах.
Система позволяет мониторить все - видеть джоблоги в реальном времени, видеть статус каждого задания и сколько ресурсов оно потребляет (процессор, ввод-вывод, открытые файлы и т.п.), управлять заданиями (вплоть до принудительного закрытия).
вы видимо плохо знаете java ;) все это есть и для этого не надо колупаться в "мозгах" ОС. можно даже код приложения на лету обновить.
Думаете не пробовали джаву? Пробовали. Не тянет оно.
Почему не тянет? Очень даже тянет. Везде, где нет вот этого легаси-кобола и унаследованных мейнфреймов тянет и хорошо тянет. А там где сохранилось менфреймовое ядро, его снаружи обвешивают конверторами и сервисами на той же яве и постепенно откусывают от ядра куски опять же в пользу явы. Я работал с банками из первого примера и собеседовался с банками из второго (как раз эти адаптеры надо было писать). А ещё успел поделать немножко торговли на чикагской мерчант бирже. Там не фондовая и нет HFT, а с не хай фриквенси торговлей ява вполне справляется (но работа с памятью глубока затюнена, да).
А на ядре совсем другой стек.
Неа. Та же самая ява. Зоопарк стеков невыгоден. Он остался в легаси и специальных случаях, вроде HFT.
И все это только один банк (ну пусть крупный, пусть из топ-10, но все равно один банк).
Это вы про какой?
А там где сохранилось менфреймовое ядро, его снаружи обвешивают конверторами и сервисами на той же яве и постепенно откусывают от ядра куски опять же в пользу явы.
Ядро как раз и обеспечивает всю основную бизнес-логику. Это mission critical часть. Сервисы на джаве - это внешние интерфейсы для других систем. Не более того. Делаются они не потому что "джава лучше", а для того, что не вешать на ядро то, чего там не должно быть. Как пример - ядро не должно заниматься всякой ерундой типа отсылки всяких уведомлений (смс, почта и т.п.). Оно просто формирует данные и "выпихивает" их во внешнюю систему. А та уже делает все эти подробности.
Мобильное приложение не имеет доступа к БД. Ему дают REST API, которое завязано на вебсервисы, формирующие запрос к ядру, получающие от него ответ и отдающие приложению. Ядро вообще изолировано от внешенего мира ("Б" - безопасность), находится во внутреннем контуре и общаться с ним можно только через запросы (очереди, вебсервисы...)
Нашумевшая ситуация в начале пандемии когда "мейнфремы начали падать под нагрузкой":
Хороший пример этого можно наблюдать во время пандемии. В первые дни Covid-19 бизнесы массово закрывались. Уволенные сотрудники рванулись онлайн, чтобы подать заявление на получение пособий по безработице, и веб-сайты многих правительств штатов не выдержали нагрузки. Губернатор Нью-Джерси сообщил прессе, что их системы COBOL отчаянно нуждаются в помощи, чтобы справиться с новыми потребностями. «У нас в буквальном смысле есть системы, которым от сорока и более лет», — заявил он.
Но технологи, работавшие за кулисами над устранением неполадок, знали, проблема заключалась не в перемалывающем числа COBOL. Эти старые системы работали хорошо. Нет, всегда ломались более новые элементы — программы, управлявшие самим веб-сайтом.
«С ума сходило веб-приложение между мейнфреймом и внешним миром. Именно оно падало», — рассказывает программистка и писательница Марианна Беллотти, годами работавшая с государственными системами и следившая за этой системой Нью-Джерси. Но, по словам историка Хикса, властям было слишком неудобно признать «ой, да, это сломались наши веб-системы».
Беллотти наблюдала подобные явления и в других государственных органах, например в Налоговом управлении США (IRS). Однажды её вызвали для помощи с неработающим веб-приложением IRS. После расследования выяснилось, что проблема и в самом деле была в новых программах, «в куске плохо написанного кода на Java». Мейнфрейм с запущенным COBOL, напротив, гнал вперёд подобно Ferrari.
Да, неудобненько вышло, но таковы факты...
У Java есть главное преимущество
Причем преимущество не уникальное до такой степени, что оно есть практически у каждого мейнстримного языка и платформы: JavaScript (Node / Deno), Python, .NET (C#, за остальные не скажу).
Пишу как кодер в одном из немногих, если не единственном, банке в России, который от начала и до конца работает на .NET
может куда интереснее получиться
последнее что надо банкам это эксперименты, они деньги в первую очередь зарабатывают. им желательно 1 раз купить и лет 40 пользоваться
Один из старейших языков программирования COBOL, похоже, вскоре уйдёт с рынка. И поможет ему в этом IBM