Клинту-частному лицу может быть просто нужно общаться с небольшим кругом родных-друзей. А youtube/инста и прочие мордокниги ему могут быть нафиг не нужны.
И в такой ситуации проще сразу всем узким кругом уйти на какие-нибудь imo/bip чем каждый день подбирать работающий сегодня прокси или периодически искать VPN который пока еще не научились определять и блочить.
Да. При условии что приложение не работает со связанными в нескольких файла данными, не обеспечивает работу в транзакционном режиме и еще много чего не делает.
Т.е. это что-то с достаточно простой логикой (относительно внешних данных хотя бы) и достаточно изолированное (не являющееся частью более сложной системы).
Но сам факт что разработчик этим не одумляется в принципе не есть хорошо. Потому что если он попадает в более другой проект, приходится переучивать.
Вы всерьез думаете, что разговариваете здесь с людьми, которые сложнее примитивных утилит командной строки ничего не делали?
Я надеюсь что это не так. И при этом странно читать утверждения о том, что программу можно просто уронить , а система сама все подчистит.
Я вообще не знаю что именно тов.@aeder подразумевал под “транзацией”.
Транзакция в общем случае - последовательность действий, которая должна быть завершена до конца. А в случае ошибки должен быть откат с исходному состоянию.
Я занимался разработкой ПО для системы мониторинга инженерного оборудования зданий. Там с одной стороны сеть промконтроллеров с подключенными датчиками и механизмами, в другой - набор интерфейсных клиентов. Между ними микроядро (которое, собственно, я и делал) - оно занималось согласование форматов и маршрутизацией сигналов.
Так вот там транзакция начиналась на момент формирование сигнала на контроллере и заканчивалась отображением информации в интерфейсном клиенте. или наоборот - от формирования команды в клиенте и до исполнения ее контроллером.
Потерять бесследно сигнал или команду по дороге - непозволительно. Отправляющая сторона всегда должна четко знать - дошла посылка до адресата или нет (нужна перепосылка или нет).
Второй пример транзакции - проведение платежа в банках. Там нельзя окончательно списать деньги со счета пока не будет получено подтверждение от получателя. А это может занять от нескольких минут до нескольких дней. И при этом платежей может быть несколько разным получателя и нельзя допустить технического овердрафта. Там свои механизмы, более сложные, нежели просто транзакция БД.
Изменение нескольких связанных по данным файлов (не таблиц БД) - тоже транзакция. Если упали в середине и не откатили то, что уже поменяли - нарушите связность данных.
Примеров мильен можно привести. И везде придете к тому, что просто так грохнуть процесс без корректной обработки аварийного завершения чревато.
Выглядит как свидетельство очевидца – где-то что-то когда-то как-то, но где что и как точно не помню.
Помилуйте, я под винду не писал уже почти 9 лет... И слава богу :-)
Но проблем там хватало. Особенно если поток не один, а продукт сложнее (а мне приходилось заниматься разработкой достаточно сложных вещей, как правило, работающих в фоне 24/7) чем небольшая утилитка командной строки.
И санитайзерами приходилось пользоваться для выявления неосвобожденных объектов, и с потоками извертываться чтобы один при падении не тащил все остальное...
Отсюда и твердое убеждение что обработка ошибок, особенно критических, не такое простое дело и надеяться что система все сделает за вас очень самонадеянно.
Да и "транзакция" может быть сложнее чем обычная транзакция БД. И вообще это может быть не БД совсем. Точнее, не только БД, но что-то более распределенное (получил из одного канала, никоем образом обработал - отправил в другой канал и все это с подтверждениями что получил и что отправленное дошло), но тоже требующее транзакционного подхода.
Тут остается только воскликнуть “Да что вы говорите?!!!”
Вот то и говорю... Какая-то изоляция там есть, конечно. Но не 100% как для заданий в той же АСке где задание - контейнер. Не зря же в винде/линухе всякие докеры-шмокеры придумывают... Как раз по причине недостаточной изоляции процессов.
Я наблюдал это именно на динамически выделенной памяти. Которая выделяется "где-то там" без привязки к конкретному процессу.
В винде (да и в линуксе тоже) процессы не изолированы, как например, в той же AC/400 под которую пишу последние 8 лет - тут нет процессов, есть задания (job) каждое из которых является изолированным контейнером (а внутри задания еще есть группы активации - подконтейнеры). Но тут могут быть свои приколы.
В винде утечки памяти наблюдал неоднократно. Именно той, которая была выделена динамически. А с учетом того, что в С++ динамическая память направо и налево выделяется...
Справедливости ради: а какие ОС общего назначения не подчищают память и не закрывают автоматически открытые процессом файлы?
Честно скажу - не знаю. Но проблема утечек памяти-то есть. Т.е. если ваш процесс динамически выделил память а потом ее не освободил на выходе, возникает утечка.
Какой-то из них падает (например, родитель), а остальные не могут по каким-то причинам диагностировать исчезновение родителя и продолжают держать открытыми ресурсы.
И это тоже.
Еще весело бывает, когда два процесса общаются друг с другом через shared-memory и один из них внезапно падает.
И это.
Про транзакции уже писал. Любая транзакция должна быть или закоммичена, или откачена.
Поэтому и говорю - любое падение должно быть контролируемым. Не падение, но мягкое приземление. Тут всегда должен работать принцип "кто девушку ужинает, тот ее и танцует" и "мы в ответе за тех, кого приручили".
А что вы подразумеваете под "любым классом задач"?
Системы реального времени исключили. Ну ок. Высоконагруженные системы исключили. Тоже ок. И что остается? Мелкие утилики? А не слишком ли сложный язык вы выбрали для написания утилиты из 300-500 строк кода?
Да, не влезет. Да, через стек. Но эти накладные расходы (на передачу дополнительного параметра) ничтожны по сравнению с расходами на Stack Unwinding которые неизбежны при исключении.
Освобождение памяти, закрытие файлов и откат транзакций - это всё обеспечивает операционная система.
Ой ли? А утечки памяти откуда берутся? А сообщение "файл невозможно удалить т.к. он занят другим процессом" после падения этого самого процесса откуда берется?
Я не говорю о более сложных ситуациях когда изменили данные в 5-ти таблицах, на изменении в 6-й упали с треском и в результате получили неконсистентность данных.
Если вы просто "упадёте" - файл останется без этого наредактированного, но хоть корректный. А вот если попытаетесь сохраниться...
А это тут при чем? Речь о том, что вы должны восстановить "как было до запуска вашей программы". Откатить все изменения (если они не доведены до конца), освободить все файлы, освободить всю выделенную динамически память.
в таких областях как реальное время – это непредсказуемость операции выброса исключения
В RT системах - да - нарушение гарантированного времени отклика. В HiLoad - ресурсы.
В случае с явным возвратом объекта вместо выброса исключения накладных расходов, на самом-то деле, может оказаться даже больше
Наверное, зависит от системы в целом, но по нашим PEX (Performace EXplorer) статистикам Stack Unwinding - очень дорогая штука с точки зрения ресурсов процессора...
Мы даже динамическую память стараемся по минимуму использовать - даже это для нас дороговато.
Структура ошибки фактически получается одна - на стеке верхнего уровня. Дальше она уже передается вниз по ссылке.
Ну бывают редкие ситуации когда нужно собирать историю неблокирующих ошибок (предупреждений). Тогда делается "стек ошибок" из таких структур. Тоже один и по ссылке передается сверху вниз с постепенным заполнением.
Насколько я понял, в вашем случае не происходит Stack Unwinding, поиска обработчика, не требуется создания LSDA.
Т.е. тут по определению ощутимо меньше накладных расходов.
В нашем случае мы пользуемся "структурированной ошибкой" - ошибка заполняется в структуру
typedef struct Qus_EC
{
int Bytes_Provided;
int Bytes_Available;
char Exception_Id[7];
char Reserved;
char Exception_Data[];
} Qus_EC_t;
Но это уже определяется поддержной на уровне самой системы - тут есть т.н. файл сообщений (message files) где хранятся все ошибки - коды, текстовки, уровень серьезности и т.п.
MCH0601 - код сообщения - поле Exception_Id
&1, &2 и &3 - места для подстановки конкретных данных (которые передаются в поле Exception_Data)
И есть системное API
void QMHRTVM (void *, /* Message information */
int, /* Length of message information */
char *, /* Format name */
char *, /* Message identifier */
void *, /* Qualified message file name */
void *, /* Message data */
int, /* Length of message data */
char *, /* Replace substitution values */
char *, /* Return format control */
void *, /* Error Code */
... ); /* Optional parameter group:
Retrieve option
Convert to CCSID
Message data CCSID */
Которое вернет (при необходимости) полный текст сообщения с подставленными данными и уровень серьезности (0 - информационное, 10 - предупреждение, 20 и выше - ошибка).
Можно создавать свои файлы сообщений, создавать свои типы сообщений.
При обработке ошибки обычно достаточно просто ее кода.
А принципе, такое несложно реализовать на уровне библиотеки.
Более того, мы часто используем более краткий формат структуры - 7 символов код ошибки + 3х10 символов параметры. Этого вполне достаточно.
Если функция вернула заполненную структуру (код ошибки не пустой) - уже смотрим что дальше делать с данной конкретной ошибкой - возвращать выше, обрабатывать тут, просто логировать и продолжать работу...
Поскольку у нас есть еще и системные исключения, то эта же ошибка может быть прокинута и как системное исключение (с возможностью регулировать на какой уровень стека ее прокидывать). Но это тяжелый механизм, его посильно избегаем, предпочитая просто возвращать заполненную структуру в виде параметра.
Весной 2020 года COBOL-зависимость государственных систем США стала особенно заметной. В первую неделю пандемийных ограничений число заявок на пособие по безработице в штате Нью-Джерси выросло на 1 600% и только за два последующих месяца поступило более 362 000 заявлений.
COBOL-система рухнула под такой нагрузкой. В правительстве выступили с публичным призывом найти программистов COBOL
Это неправда. Точнее, это "официальная версия", на самом же деле
Хороший пример этого можно наблюдать во время пандемии. В первые дни Covid-19 бизнесы массово закрывались. Уволенные сотрудники рванулись онлайн, чтобы подать заявление на получение пособий по безработице, и веб-сайты многих правительств штатов не выдержали нагрузки. Губернатор Нью-Джерси сообщил прессе, что их системы COBOL отчаянно нуждаются в помощи, чтобы справиться с новыми потребностями. «У нас в буквальном смысле есть системы, которым от сорока и более лет», — заявил он.
Но технологи, работавшие за кулисами над устранением неполадок, знали, проблема заключалась не в перемалывающем числа COBOL. Эти старые системы работали хорошо. Нет, всегда ломались более новые элементы — программы, управлявшие самим веб-сайтом.
«С ума сходило веб-приложение между мейнфреймом и внешним миром. Именно оно падало», — рассказывает программистка и писательница Марианна Беллотти, годами работавшая с государственными системами и следившая за этой системой Нью-Джерси. Но, по словам историка Хикса, властям было слишком неудобно признать «ой, да, это сломались наши веб-системы».
Беллотти наблюдала подобные явления и в других государственных органах, например в Налоговом управлении США (IRS). Однажды её вызвали для помощи с неработающим веб-приложением IRS. После расследования выяснилось, что проблема и в самом деле была в новых программах, «в куске плохо написанного кода на Java». Мейнфрейм с запущенным COBOL, напротив, гнал вперёд подобно Ferrari.
Банк, работающий на COBOL, не может за неделю запустить новый продукт: любое изменение требует осторожного ручного вмешательства в систему, где одна ошибка может заблокировать миллионы транзакций. Это прямые конкурентные потери — финтех-стартапы без унаследованного кода делают всё в десятки раз быстрее.
И сколько таких стартапов доросло до уровня крупных банков?
Финтех - крайне консервативная область. какой бы современный стек вы не выбрали сегодня, через пять лет он устареет. И вы окажетесь ровно в том же положении (если ваш стартап не схлопнется и обрастет хотя бы несколькими десятками миллионов клиентов и выйдет на уровне хотя бы сотни миллионов бизнес операций в сутки) - просто так поменять стек на еще более современный вы уже не сможете.
И прелесть кобола в том, что он изначально создавался специально для работы с БД и коммерческих вычислений в больших высоконагруженных системах. Это специализированный язык, он не требует никаких внешних зависимостей для работы с БД. Он поддерживает все типы данных, которые есть в БД без необходимости тратить время на создание каких-то дополнительных объектов, эмулирующих нужный тип данных. С/С++, Java, Rust не умеют сразу работать с каким-нибудь decimal или numeric (и то и другое - типы с фиксированной точкой, вс коммерческие расчеты ведутся в них) просто получив их из буфера записи. Им обязательно придется потратить время и такты процессора на создание соответствующего объекта. А потом обратно потратить время чтобы из этого объекта что-то положить в запись. В коболе все это намного проще. Там все эти типы поддерживаются языком и не требуют дополнительных преобразований.
В этом плане у кобола единственный аналог - RPG (кстати, ровесник COBOL). Но это пропертиарный язык от IBM и работает только на платформе IBM i (AS/400). Но, как и в кобол, там тоже поддерживаются все имеющиеся в БД типы данных и реализована простая и удобная работа с БД. Хоть напрямую, хоть посредством использования SQL запросов непосредственно в коде программы (и никаких внешних библиотек для этого не надо).
А вообще, банк это очень сложная и неоднородная система. И тот же кобол там используется только на уровне центральных серверов, в ядре АБС. То, что относится к mission critical уровню. Это мастер-система, отвечающая за надежное хранение данных и обработку базовых бизнес-операций. Тут максимальные требования по надежности, способности выдерживать высокие нагрузки и быстродействию.
А дальше уже вокруг него множество "внешних систем", работающих на других стеках. В частности тех, что обеспечивают взаимодействии с клиентами. Там уже уровень пониже, bisuness critical. Обрушение такой системы будет весьма неприятным для пользователя, но никоим образом не затронет целостность данных. Там и нагрузка другого рода и не такие жесткие требования к надежности. И, конечно, никаким коболом там уже не пахнет. Он там и не нужен и откровенно неудобен.
Проблема кобола не в том, что он устарел, проблема в том, что ему нет адекватной замены. Языка, который таже просто позволяет работать с БД и теми данными, которые там лежат. И который будет разработан специально и исключительно для того, чтобы обеспечить максимальную производительность и надежность именно в область коммерческих расчетов.
Лично я пришёл к этому не сразу, на заре карьеры у меня было стремление сделать свои программы "выживальщиками", в которых может продолжаться функционирование, даже если "что-то идёт не так". Со временем я на личном опыте понял, что последствия от "продолжения функционирования при ошибках" куда существеннее, чем немедленная паника.
Программа должна быть "выживальщиком" в том смысле, что в ситуации когда дальнейшая работа может привести к непредсказуемому результату, она должна обеспечивать "мягкую посадку" - освобождение памяти, закрытие файлов, откат транзакций и т.п. Плюс оставить "в истории" (логи и т.п.) максимально подробную информацию о том, что случилось, где и почему.
Т.е. речь ни в коем случае не идет о продолжении работы любой ценой, но и не о том, чтобы бросить все на полпути и рухнуть с треском.
Причем, давно уже.
Правда, на домашнем инете у меня и ТГ работает безо всяких обходов. Но только десктопная версия. Мобильная - нет.
Клинту-частному лицу может быть просто нужно общаться с небольшим кругом родных-друзей. А youtube/инста и прочие мордокниги ему могут быть нафиг не нужны.
И в такой ситуации проще сразу всем узким кругом уйти на какие-нибудь imo/bip чем каждый день подбирать работающий сегодня прокси или периодически искать VPN который пока еще не научились определять и блочить.
Кого он будет записывать, если у клиентов оно не работает?
Да. При условии что приложение не работает со связанными в нескольких файла данными, не обеспечивает работу в транзакционном режиме и еще много чего не делает.
Т.е. это что-то с достаточно простой логикой (относительно внешних данных хотя бы) и достаточно изолированное (не являющееся частью более сложной системы).
Но сам факт что разработчик этим не одумляется в принципе не есть хорошо. Потому что если он попадает в более другой проект, приходится переучивать.
Я надеюсь что это не так. И при этом странно читать утверждения о том, что программу можно просто уронить , а система сама все подчистит.
Транзакция в общем случае - последовательность действий, которая должна быть завершена до конца. А в случае ошибки должен быть откат с исходному состоянию.
Я занимался разработкой ПО для системы мониторинга инженерного оборудования зданий. Там с одной стороны сеть промконтроллеров с подключенными датчиками и механизмами, в другой - набор интерфейсных клиентов. Между ними микроядро (которое, собственно, я и делал) - оно занималось согласование форматов и маршрутизацией сигналов.
Так вот там транзакция начиналась на момент формирование сигнала на контроллере и заканчивалась отображением информации в интерфейсном клиенте. или наоборот - от формирования команды в клиенте и до исполнения ее контроллером.
Потерять бесследно сигнал или команду по дороге - непозволительно. Отправляющая сторона всегда должна четко знать - дошла посылка до адресата или нет (нужна перепосылка или нет).
Второй пример транзакции - проведение платежа в банках. Там нельзя окончательно списать деньги со счета пока не будет получено подтверждение от получателя. А это может занять от нескольких минут до нескольких дней. И при этом платежей может быть несколько разным получателя и нельзя допустить технического овердрафта. Там свои механизмы, более сложные, нежели просто транзакция БД.
Изменение нескольких связанных по данным файлов (не таблиц БД) - тоже транзакция. Если упали в середине и не откатили то, что уже поменяли - нарушите связность данных.
Примеров мильен можно привести. И везде придете к тому, что просто так грохнуть процесс без корректной обработки аварийного завершения чревато.
Помилуйте, я под винду не писал уже почти 9 лет... И слава богу :-)
Но проблем там хватало. Особенно если поток не один, а продукт сложнее (а мне приходилось заниматься разработкой достаточно сложных вещей, как правило, работающих в фоне 24/7) чем небольшая утилитка командной строки.
И санитайзерами приходилось пользоваться для выявления неосвобожденных объектов, и с потоками извертываться чтобы один при падении не тащил все остальное...
Отсюда и твердое убеждение что обработка ошибок, особенно критических, не такое простое дело и надеяться что система все сделает за вас очень самонадеянно.
Да и "транзакция" может быть сложнее чем обычная транзакция БД. И вообще это может быть не БД совсем. Точнее, не только БД, но что-то более распределенное (получил из одного канала, никоем образом обработал - отправил в другой канал и все это с подтверждениями что получил и что отправленное дошло), но тоже требующее транзакционного подхода.
Вот то и говорю... Какая-то изоляция там есть, конечно. Но не 100% как для заданий в той же АСке где задание - контейнер. Не зря же в винде/линухе всякие докеры-шмокеры придумывают... Как раз по причине недостаточной изоляции процессов.
Я наблюдал это именно на динамически выделенной памяти. Которая выделяется "где-то там" без привязки к конкретному процессу.
В винде (да и в линуксе тоже) процессы не изолированы, как например, в той же AC/400 под которую пишу последние 8 лет - тут нет процессов, есть задания (job) каждое из которых является изолированным контейнером (а внутри задания еще есть группы активации - подконтейнеры). Но тут могут быть свои приколы.
Я это на семерке наблюдал. И на 2000 (которая NT5)
В винде утечки памяти наблюдал неоднократно. Именно той, которая была выделена динамически. А с учетом того, что в С++ динамическая память направо и налево выделяется...
GC таки не зря придумали...
Честно скажу - не знаю. Но проблема утечек памяти-то есть. Т.е. если ваш процесс динамически выделил память а потом ее не освободил на выходе, возникает утечка.
И это тоже.
И это.
Про транзакции уже писал. Любая транзакция должна быть или закоммичена, или откачена.
Поэтому и говорю - любое падение должно быть контролируемым. Не падение, но мягкое приземление. Тут всегда должен работать принцип "кто девушку ужинает, тот ее и танцует" и "мы в ответе за тех, кого приручили".
А что вы подразумеваете под "любым классом задач"?
Системы реального времени исключили. Ну ок. Высоконагруженные системы исключили. Тоже ок. И что остается? Мелкие утилики? А не слишком ли сложный язык вы выбрали для написания утилиты из 300-500 строк кода?
То же самое относится и к высоконагруженным системам с высокими требованиями к производительности и эффективности использования ресурсов процессора.
Да, не влезет. Да, через стек. Но эти накладные расходы (на передачу дополнительного параметра) ничтожны по сравнению с расходами на Stack Unwinding которые неизбежны при исключении.
Ой ли? А утечки памяти откуда берутся? А сообщение "файл невозможно удалить т.к. он занят другим процессом" после падения этого самого процесса откуда берется?
Я не говорю о более сложных ситуациях когда изменили данные в 5-ти таблицах, на изменении в 6-й упали с треском и в результате получили неконсистентность данных.
А это тут при чем? Речь о том, что вы должны восстановить "как было до запуска вашей программы". Откатить все изменения (если они не доведены до конца), освободить все файлы, освободить всю выделенную динамически память.
Да, все верно
В RT системах - да - нарушение гарантированного времени отклика. В HiLoad - ресурсы.
Наверное, зависит от системы в целом, но по нашим PEX (Performace EXplorer) статистикам Stack Unwinding - очень дорогая штука с точки зрения ресурсов процессора...
Мы даже динамическую память стараемся по минимуму использовать - даже это для нас дороговато.
Структура ошибки фактически получается одна - на стеке верхнего уровня. Дальше она уже передается вниз по ссылке.
Ну бывают редкие ситуации когда нужно собирать историю неблокирующих ошибок (предупреждений). Тогда делается "стек ошибок" из таких структур. Тоже один и по ссылке передается сверху вниз с постепенным заполнением.
Насколько я понял, в вашем случае не происходит Stack Unwinding, поиска обработчика, не требуется создания LSDA.
Т.е. тут по определению ощутимо меньше накладных расходов.
В нашем случае мы пользуемся "структурированной ошибкой" - ошибка заполняется в структуру
Но это уже определяется поддержной на уровне самой системы - тут есть т.н. файл сообщений (message files) где хранятся все ошибки - коды, текстовки, уровень серьезности и т.п.
MCH0601 - код сообщения - поле Exception_Id
&1, &2 и &3 - места для подстановки конкретных данных (которые передаются в поле Exception_Data)
И есть системное API
Которое вернет (при необходимости) полный текст сообщения с подставленными данными и уровень серьезности (0 - информационное, 10 - предупреждение, 20 и выше - ошибка).
Можно создавать свои файлы сообщений, создавать свои типы сообщений.
При обработке ошибки обычно достаточно просто ее кода.
А принципе, такое несложно реализовать на уровне библиотеки.
Более того, мы часто используем более краткий формат структуры - 7 символов код ошибки + 3х10 символов параметры. Этого вполне достаточно.
Если функция вернула заполненную структуру (код ошибки не пустой) - уже смотрим что дальше делать с данной конкретной ошибкой - возвращать выше, обрабатывать тут, просто логировать и продолжать работу...
Поскольку у нас есть еще и системные исключения, то эта же ошибка может быть прокинута и как системное исключение (с возможностью регулировать на какой уровень стека ее прокидывать). Но это тяжелый механизм, его посильно избегаем, предпочитая просто возвращать заполненную структуру в виде параметра.
А вообще, это далеко не первая (и не последняя) статья про COBOL
COBOL — древний код, который управляет вашими деньгами
Язык программирования, который контролирует мировые финансы: 240 миллиардов строк кода на COBOL
COBOL: все еще в строю спустя столько лет
Заложники COBOL и математика. Часть 1
Заложники COBOL и математика. Часть 2
Старые языки программирования, новые успехи: растёт популярность COBOL и Fortran
Это неправда. Точнее, это "официальная версия", на самом же деле
https://habr.com/ru/articles/532554/
И сколько таких стартапов доросло до уровня крупных банков?
Финтех - крайне консервативная область. какой бы современный стек вы не выбрали сегодня, через пять лет он устареет. И вы окажетесь ровно в том же положении (если ваш стартап не схлопнется и обрастет хотя бы несколькими десятками миллионов клиентов и выйдет на уровне хотя бы сотни миллионов бизнес операций в сутки) - просто так поменять стек на еще более современный вы уже не сможете.
И прелесть кобола в том, что он изначально создавался специально для работы с БД и коммерческих вычислений в больших высоконагруженных системах. Это специализированный язык, он не требует никаких внешних зависимостей для работы с БД. Он поддерживает все типы данных, которые есть в БД без необходимости тратить время на создание каких-то дополнительных объектов, эмулирующих нужный тип данных. С/С++, Java, Rust не умеют сразу работать с каким-нибудь decimal или numeric (и то и другое - типы с фиксированной точкой, вс коммерческие расчеты ведутся в них) просто получив их из буфера записи. Им обязательно придется потратить время и такты процессора на создание соответствующего объекта. А потом обратно потратить время чтобы из этого объекта что-то положить в запись. В коболе все это намного проще. Там все эти типы поддерживаются языком и не требуют дополнительных преобразований.
В этом плане у кобола единственный аналог - RPG (кстати, ровесник COBOL). Но это пропертиарный язык от IBM и работает только на платформе IBM i (AS/400). Но, как и в кобол, там тоже поддерживаются все имеющиеся в БД типы данных и реализована простая и удобная работа с БД. Хоть напрямую, хоть посредством использования SQL запросов непосредственно в коде программы (и никаких внешних библиотек для этого не надо).
А вообще, банк это очень сложная и неоднородная система. И тот же кобол там используется только на уровне центральных серверов, в ядре АБС. То, что относится к mission critical уровню. Это мастер-система, отвечающая за надежное хранение данных и обработку базовых бизнес-операций. Тут максимальные требования по надежности, способности выдерживать высокие нагрузки и быстродействию.
А дальше уже вокруг него множество "внешних систем", работающих на других стеках. В частности тех, что обеспечивают взаимодействии с клиентами. Там уже уровень пониже, bisuness critical. Обрушение такой системы будет весьма неприятным для пользователя, но никоим образом не затронет целостность данных. Там и нагрузка другого рода и не такие жесткие требования к надежности. И, конечно, никаким коболом там уже не пахнет. Он там и не нужен и откровенно неудобен.
Проблема кобола не в том, что он устарел, проблема в том, что ему нет адекватной замены. Языка, который таже просто позволяет работать с БД и теми данными, которые там лежат. И который будет разработан специально и исключительно для того, чтобы обеспечить максимальную производительность и надежность именно в область коммерческих расчетов.
Программа должна быть "выживальщиком" в том смысле, что в ситуации когда дальнейшая работа может привести к непредсказуемому результату, она должна обеспечивать "мягкую посадку" - освобождение памяти, закрытие файлов, откат транзакций и т.п. Плюс оставить "в истории" (логи и т.п.) максимально подробную информацию о том, что случилось, где и почему.
Т.е. речь ни в коем случае не идет о продолжении работы любой ценой, но и не о том, чтобы бросить все на полпути и рухнуть с треском.