Comments 73
Спасибо, очень познавательно.
Особенно приятно было почитать про перфокарты и вспомнить юность. Я так же написал свою первую программу в 1978 году и она уместилась на одной перфокарте так как советский перфоратор располагал литеры не поперек перфокарты, а вдоль, что позволяло разместить в разы больше информации на одной карте.
Так же в то время был часто задаваемый вопрос среди студентов программистов - у тебя есть "крошка"?
Агащазблин. Особенно если учесть, что одна дырка — один бит, а число дырок не меняется, если карту развернуть на 90 градусов :)
Вот я тоже не понял, как можно уместить там больше, чем один символ в колонке. Может, они просто писали на них?)))
Перфокарты я застал на практике, когда учился. ЕС-ЭВМ.
Технически в моем посте речь шла не о кодировке, а машинных кодах для Минска-32. Насколько мне память не изменяет длина слова там 37 бит т.е. в одну строку можно было залить два слова. Но вроде как для простоты писали одна строка одно слово. Задачка как сейчас помню вроде была вычислительная в цикле т.е. вполне помещалась на одной перфокарте.
У IBM вполне возможно был такой подход в ранних реализациях до языков программирования. В той конфигурации когда пришли ЕС ЭВМ уже был классический стандарт 80 символов на перфокарту. Я вообще сомневаюсь, что дамп памяти можно было набить и тем более грузить через перфосчитыватель в стандартном режиме. Обычно все ж если надо было подгрузить PSW пользовались тумблерами панели.
Если коротко, то когда перешли на ЕС ЭВМ количество перфокарт резко возросло так как на одной перфокарте можно было поместить 80 символов. В советском варианте исходя из предположения один символ 8 бит можно было последовательно набить 80х11 = 880 т.е. 110 символов если писать на том же Алгол-60.
А то что можно было бинарные коды считывать и записывать — да, конечно, без сомнения. Скомпилированные в частности. По сути я читал на ЕС перфокарты от М-222, которые пробивались по строкам, потому что у М-222 тоже было кажись 48 битовое слово.
На самом деле мне просто было приятно поговорить о перфокартах и встретить виртуально коллегу кто знаком с перфокартами не понаслышке. С удивлением обнаружил сколько всякой бессмысленной информации помнит человеческая память столько времени прошло.
Очередь к перфоратору часто была настолько огромна, что часто быстрее было вырезать дырки вручную обычной бритвой и прогнать через дубликатор.
Читал про Томаса пару лет назад
Уже было на Хабре в прошлом году https://habr.com/ru/post/532554
Читал когда-то "Глубину в небе" Винджа, где прекрасно описана специальность "компьютерного археолога". А ведь это книга еще конца XX века...
Не могу удержаться от цитирования:
Фам Нювен несколько лет провел, обучаясь программировать и исследовать. Программирование восходило к началу времен. Как та навозная куча за замком отца. Когда ее промыло ручьем на десять метров в глубь, обнаружились искореженные корпуса машин – летающих машин, как говорили крестьяне, еще от тех великих дней колонизации Канберры. Но та навозная куча была чистой и свежей по сравнению с тем, что лежало в локальной сети «Репризы». Были программы, написанные пять тысяч лет назад, когда человечество еще не покинуло Землю. И самое чудесное (самое ужасное, как говорила Сура) было то, что, в отличие от бесполезных обломков прошлого Канберры, эти программы все еще работали! И через миллион миллионов запутанных нитей наследования многие из старейших программ все еще выполнялись во внутренностях системы Кенг Хо.
Кто эти два человека, ответившие, что написали много программ? Отзовитесь!
Тот самый случай, когда про текст можно сказать "словам тесно, а мыслям просторно"...
По десять раз повторяются одни и те же тезисы, а подробностей почти нет.
Много обобщений на основе одного человека из одного банка... из пальца высосанные обобщения на всю страну. Ну такое.
Язык и технологии скорее всего не главная проблема. В легаси обычно главная проблема "как бы так починить вот тут, чтобы ничего не сломалось", или "если я тут исправлю, что я могу сломать и как это протестировать", или "есть ли на свете живой человек который еще помнить как это работает"...
В банковской сфере есть и другая проблема, нельзя просто взять и вырубить старый рабочий модуль. Нужно создавать дупликат, и переключение проводить live. А если учесть что формат данных который понимает COBOL не подходит. Придется создать с 0 систему выполняющую те-же функции, как-то конвертировать старые БД в новый формат, протестировать и не дай бог у вас ошибка типа Y2K, банк не сможет просто так отозвать переводы на неправильныe проценты, даже через суд.
В банковской сфере есть и другая проблема, нельзя просто взять и вырубить старый рабочий модуль. Нужно создавать дупликат, и переключение проводить live.
Да, это так. А еще нужно убедиться что новый модуль работает не хуже - не медленнее, потребляет не больше ресурсов, не конфликтует с остальными 100500 параллельно работающими процессами...
А если учесть что формат данных который понимает COBOL не подходит. Придется создать с 0 систему выполняющую те-же функции, как-то конвертировать старые БД в новый формат
Ну это уже не столько к COBOL, сколько к архитектуре системы в целом. В те времена действительно архитектуры строились под один конкретный язык.
Я работаю в банке. Банк работает на платформе IBM i (бывшая AS/400). Это не мейнфреймы, IBM позиционируют ее как middleware. В мире достаточно популярна в финтехе, банках, страховых компаниях, госстурктурах. Система удивительно цельная. Там сразу интегрирована и БД (DB2) и компиляторы нескольких языков (COBOL, RPG, CL, C/C++), поддержка SQL, в том числе и интерактивная (выполнение отдельных SQL запросов из командной строки). И там доступ к БД возможен из любого языка. Более того, двумя способами - вставкой в код SQL запросов (позволяющих использовать как на вход, так и на выход используемые в программе переменные), так и прямым, noSQL обращением к таблицам и индексам.
Вместо COBOL IBM продвигает RPG. Тоже очень старый язык, ориентированный на работу с БД и коммерческие вычисления (типы данных с фиксированной точкой, много форматов даты и времени и функций работы с ними и т.п.). Но этот язык живой и развивающийся - поменялся синтаксис - от изначального FIXED (где каждая буковка должна быть на свей позиции - наследие эпохи когда программы писались на специальных бланках) с линейным кодом перешли к нормальному процедурному FREE.
Да, это легаси все равно. В том смысле что здесь нет модных фреймворков. Точнее, они есть, но на более высоких слоях. А на нижнем, core, слое, где работает АБС, там легаси. Быстрый, эффективный до предела, надежный как скала легаси. Потому что цена ошибки - не дизлайк от пользователя, а огромные репутационные потери и штрафы со многими нулями от регулятора "на ненадлежащее исполнение обязательств перед клиентами". Т.е. код, работающий на core уровне является mission critical. И там используются только сверхнадежные решения.
Естественно, что на фронтах и промежуточных слоях используются современные стеки технологий. Но там нет бизнес-логики, они не имеют доступа к данным. Они только формируют запросы к ядру и представляют пользователю ответы.
да, только код на COBOL придется писать
возможности, наверняка, есть, а вот со специалистами, кто мог бы этот код написать, вероятно, все сложно.
Речь про код ядра?
Там, к счастью, не COBOL, а RPG. И исходники все выкуплены и залиты в наш гит.
И мы (и я в том числе) их постоянно дорабатываем (оптимизация, доработки по изменениям и новым бизнес требованиям).
Фактически у нас несколько уровней. Легаси только на уровне core. Там mission-critical, более 90% всей бизнес-логики банка (а это очень сильно не только счета-проводки, там еще до черта всего) и требуется предельная эффективность.
Просто речь о том, что любое изменение любого из многих тысяч компонентов потребует полного ретеста - компонентного, бизнес, нагрузочного, интеграционного. И просто так менять то, что и так работает нецелесообразно.
Каких-то радикальных нерешаемых проблем с теми, кто все это дело разрабатывает у нас нет и в обозримом будущем не предвидится.
Ну я как бы знаю что у нас :-) И именно в этом слое (IBM i/RPG) работаю
IBM i ими самими позиционируется как middleware. Мейнфреймы у них считаются IBM z
COBOL у нас не используется, но поддерживается в рамках ILE (т.е. компилятор есть в системе - хочешь, пиши). Просто функционально RPG не хуже, но писать на нем проще в плане синтаксиса.
Тут правильно сказали - проблема не в коболе, а в платформе на которой он работает. Человек, выучивший синтаксис кобола, но не понимающий особенности и тонкости платформы, ничего путнего на нем не напишет сложнее Hello World.
И наоборот, знающий платформу сможет писать под нее на любом доступном на ней языке.
Обнадеживает. Дает надежду на то, что не смотря на взрывной рост популярности "безопасных" языков... Людям хорошо знающим "небезопасные" работы хватит и до, и на пенсии. И на масло к хлебу всегда заработать можно будет. А уж без икры можно и пережить.
Хм, а разве это не очевидно? Как раз те сферы, где минимум творчества и максимум легаси, где от скуки дохнут даже мухи - вроде кобола, 1С, прочего асап, вот там как раз с покушать проблем не возникает. А молодые и шутливые часто перебиваются с хлеба на воду со своими интересными, но (пока) не приносящими прибыли проектами/языками/направлениями.
старая система позволяла ввести только 40 символов — и она не позволяла использовать дефисы, поэтому нельзя было использовать краткую форму, например, «Пн-Ср», чтобы показать, что вы свободны с понедельника по среду.
Интересно чем плохо было бы использовать Пн:Ср, или даже [Пн1000, Пн1630)
COBOL демократизировал кодирование; компании могли бы брать обычных людей и обучать их быть полезными программистами COBOL за несколько месяцев.
какая ирония в том, что теперь нужно искать этих обычных людей на персии, чтобы поддерживать весь тот код, который был написан.
Так классические банки вымрут, да и всё. Ну, вернее, не вымрут, а "ужмутся" до минимального бекенд-функционала: сделать перевод, выдать кредит. А "фронтенд" банков будут делать молодые стартапы, на современных технологиях, со всякими свистелками и феерверками. Вот как типа Монобанк в Украине: на фронте модное мобильное приложение, на беке - какой-то старый банк, который даже не каждый и вспомнит, как называется. И вот в том старом банке, всякий Кобол и Джава могут бегать ещё 1000 лет для операций перевода денег, пока на фронте будут менятся мобильные платформы, веб-фреймворки и прочий тлен.
Работаю в банке. Да, у нас есть майнфреймы и программы на кобол. И новые приложения ходят по сетке к ним чего-то от них получают. И вот теперь есть мысль увести часть инфраструктуры в облако, но с кусками, зависящими от майнфреймов это произойдёт... возможно, никогда. Откоадывается, и, предполагаю, будет откладываться на неопределённый срок.
Ну как в чём? В том, о чём написано в статье и комментариях. В человеко-десятилетиях работы. В десятках (сотнях?) миллионов денег. В необходимости поддерживать непрерывно работающий сервис.
К счастью, я не знаю. От меня запрос в сеть улетает, мне ответ прилетает.
Нет конечно. :) В качестве "первичного носителя" магнитная лента не используется очень давно (точно более 20 лет). Используются внешние СХД, сейчас все чаще "Full Flash".
При этом, магнитная лента вполне себе используется и сейчас как второй/третий уровень для хранения резервных копий и миграции "холодных" данных. Емкость современных магнитных картриджей очень неплоха, 20ТБ сырой емкости на картридж размером 25ммx110ммx125мм.
Насколько я помню, финансовые организации, в соответствии с законодательством стран, где они работают, обязаны хранить исторические данные очень много (десятки) лет. При этом, по правилам, нужно хранить несколько копий, географически удаленно друг на друга. Т.е. "потерять" эти данные финансовая организация не имеет права ни в коем случае.
Уж не знаю как сейчас насчет "физической бумаги", хотя ранее видел как печатают и хранят ежедневную бумажную отчетность по определенным операциям.
Практики, когда важные данные выгружаются на ленту (несколько копий) и развозятся по разным изолированным складам/хранилищам точно существуют и по сей день. Хранить магнитную ленту все таки проще и дешевле чем, например, жесткие диски сравнимого объема.
Согласно спецификации IBM на картриджи 3592, они должны хранить данные порядка 30 лет. В самом документе, в разных местах написано "более 30 лет" и "до 30 лет". Сами картриджи разных моделей вышли уже после 2000г., поэтому эти данные приведены по тестам "ускоренного старения", так как даже самые старые картриджи из этой линейки "доживут" до указанного значения через 12 лет (2033 г.).
Ссылка на документ со спецификацией: https://www.ibm.com/downloads/cas/GLDJAXRP
Конечно, условия хранения должны быть соблюдены и это справедливо для любого носителя данных.
Для бумаги/пергамента тоже нужны определенные условия хранения, просто "диапазон" другой. Бумага тоже боится огня и влажности, ее могут "погрызть", используемые компоненты для печати могут выцвести, и т.п.
У ленты гораздо более высокая плотность хранения по сравнению с бумагой и при записи используются технологии для возможности восстановления данных: избыточность, специальное кодирование и т.д.
Ну и для тех кому это действительно нужно, могут использовать несколько разных типов носителей, в расчете что что-то да сохранится.
Почему-то говоря про COBOL, упоминают его как отдельный язык, умалчивая про инфраструктуру, внутри которой он существует. Одна из "фишек" этой инфраструктуры, что до сих пор можно напрямую исполнять код, откомпилированный много лет назад и он будет работать. Но, если хочется прироста производительности - то перекомпилировать код все таки придется. Более новые версии компилятора COBOL как правило создают более оптимальный двоичный код, с использованием новых возможностей аппаратуры, операционной системы и смежного ПО.
Далее, программы на COBOL существуют не в вакууме, обычно они исполняются в операционной системе и тесно связаны с существующими там данными (последовательные наборы данных, индексированные наборы данных), смежным ПО: СУБД (DB2, IMS, ADABAS и другие), обмен сообщениями (IBM MQ и др.), управление транзакциями (IBM CICS) и так далее. Соотвественно и COBOL-программист нужен не абстрактный (знающий только сам язык), а тот, кто на достаточном уровне знает все "окружение" в котором эта программа будет исполняться.
Поэтому, с моей точки зрения, сложность не столько в малом количестве людей со знанием языка COBOL, а в том, что сложная система постепенно превращается в "черный ящик", потому что ушли те, кто знает как эта система устроена. А это уже вопрос к бизнесу. Процесс передачи знаний, их актуальности, проверка наличия в команде сопровождения нужных компетенций и восстановление этих компетенций - это большая и сложная задача, которая требует времени и финансирования. Абсолютно аналогичным образом любая новая система созданная сегодня на любых модных/современных технологиях может через 10-20-30 лет превратиться в такой же "волшебный черный ящик", если не останется специалистов, понимающих как она устроена.
Про "мейнфреймы", а именно линейку серверов IBM Z.
IBM регулярно обновляет и сами сервера и весь стек системного и прикладного ПО для них. Официально приобрести поддержку можно только на несколько последних поколений "железа" и ПО. Эксплуатировать и "железо" и ПО без поддержки можно, но на собственный страх и риск. Поэтому чаще в эксплуатации находятся более-менее актуальные версии и "железа" и ПО. Т.е. вполне нормальна ситуация, когда COBOL-программы, разработанные 10-20-30 лет назад, компилируются актуальной версией компилятора COBOL, линкуются с актуальными версиями библиотек смежного ПО и после тестирования продолжают эксплуатироваться. Т.е. сам комплекс программ "старый", но он откомпилирован и работает на вполне современном оборудовании и ПО и может показывать очень хорошую производительность.
Насчет непрерывности. Правильно построенный кластер на основе систем z/OS позволяет поднимать уровень системного и прикладного ПО "на ходу", без простоя. Понятное дело, что происходит это поочерёдно на каждом из "узлов" кластера и отдельные узлы какое-то время будут поочередно недоступны, но перерыва в обработке транзакций не будет. Аналогично можно и сервера целиком заменить поочередно.
Абсолютно аналогичным образом любая новая система созданная сегодня на любых модных/современных технологиях может через 10-20-30 лет превратиться в такой же "волшебный черный ящик", если не останется специалистов, понимающих как она устроена.
Сейчас участвую в проекте по в написанию ТЗ для одной очень сложной промышленной системы. Заказчики потребуют что бы мы добавили требование о том что срок службы этой системы должен составлять минимум 60 лет. На мой вопрос кто будет через 60 лет в 2080 году с этим старьем работать никто не смог ответить.
На моё предложение что для поддержания "актуальности" системы следует на этапе ТЗ определить регулярную модернизацию системы каждые 10 -15 лет. Мне сказали что денег на это не закладывали.
Где-то есть уральный вагонный колёсоточильный завод со станками 1959 года.
Где-то есть оклахомский деньгокладильный районный банк с кодом 1959 года.
Это их проблемы. Когда их кобол таки скопытится (потому что последний человек, способный думать в парадигме кобола помрёт), то банк обнаружит, что вагоноточильный завод не может так больше жить. И просто закроет подразделение. Данные выгрузят, а обработкой "миллиарда транзакций за 8 часов" будет заниматься небольшой кластер (для надёжности) из нескольких обычных серверов СУБД, которые вполне могут себе позволить выдать 34кTPS на простейшие insert'ы в правильном порядке.
Браво! Отличный комент по теме. Попутно стоит отметить, что сверстник COBOLа не менее древний FORTRAN за эти полвека пережил столько ренесансов, которые коболистам и не снились. Как раз в случае FORTRAN написанные библиотеки численных методов оказались настолько удачными и востребованными, что вошли в другие языки. 90% задач, решаемых на суперкомпьютерах, написаны на различных версиях правнуков FORTRAN-66.
почему до сих пор никто не написал транспилятор?Есть вполне живой (и продвинутый, судя по being used in commercial settings) GnuCOBOL, который как раз через транспиляцию в C и работает. При этом пятистрочный «hello world» превращается в сто с лишним строк кода на C, без учета комментариев и вайтспейса. Понятно, что там много стартового бойлерплейта, было бы интереснее посмотреть результат на какой-нибудь реальной программе, но, боюсь, поддерживать такой код будет еще труднее, чем оригинальный.
Таких 2 тысячи на https://community.openmainframeproject.org/c/calling-all-cobol-programmers/15 зарегались в надежде грести и периодически забегают в группу на ФБ. В прошлом году пробовал найти помимо основной работы практику в компаниях Германии и Швейцарии в стеке z/OS COBOL. Разослал более 20 резюме релевантным, в основном страховым и банкам, с проектами, библиотеками для 3 диалектов, статьями, CI/CD и этими вашими микросервисами в Докерах. Ага.
Я брал на работу молодого парня по Кобол. В качестве бонуса обещал ему, что через 5 лет он сможет выбирать страну, в которую хочет уехать. Так и вышло. Он давно в Нидерландах и по прежнему пишет на Коболе :-)
PS Ну а пока спецы по Фортран-4 не очень востребованы, пишу на C++ и Go :-)
Какие вообще перспективы у джуна на коболе? С учётом специфики области ощущение, что ниже сеньорского уровня к работе не пустят, а учиться и расти банально негде.
Таки что с вакансиями? Я вот знаю, что если выучу условный Swift, то без работы не останусь. Если выучу Haskell, то уже намного сложнее, но всё равно работу найти можно.
А вот если я засяду учить Cobol IBM/z, то получится ли у меня устроиться на работу?
Каждый раз, когда вижу статьи про вездесущий кобол, у меня появляются сомнения: авторы рассказывают, как количество кода на коболе превосходит все остальные языки вместе взятые, но разработчиков на коболе нигде не видно.
HH показывает 5(!) вакансий на всю Россию, LinkedIn находит двадцать вакансий в Берлине с упоминанием этого яызка, но только одна из них — позиция разработчика. В Лондоне с его огромной банковской индустрией нужно аж 3(!) cobol-разработчика. Для сравнения, Java-разработчиков нужно пять с половиной тысяч.
3 человека поддерживают весь существующий код? Звучит подозрительно.
Попробуем зайти с другой стороны: предположим, что Cobol почему-то потерял популярность, оставаясь востребованным в индустрии. Разработчики существовали в каком-то периоде в прошлом. Сколько кода реально могло дожить до нашего времени и какую долю от работающего он может составлять?
Взглянем на количество разработчиков, как на простой способ сравнить размеры индустрии:
Даже в 2002-м году, когда компьютеров было уже относительно много, а Cobol уже не был популярен, в США было всего 600k разработчиков против 3.9m в 2016-м.
Если же взглянуть на страны победнее, то на время расцвета Cobol там программистов вообще можно было пересчитать по пальцам: например, в Индии в 1985-м было семь тысяч разработчиков. Сейчас их около четырёх миллионов.
Семь тысяч разработчиков на всю страну, из которых не все пишут на Cobol, согласно этим прохладным историям, за 20-30 лет(с 1969-го, когда Cobol был выпущен по 1990-2000-й, когда с него разработчики окончательно сбежали на Java / C / C++) должны были написать сравнимое количество кода с миллионами разработчиков в 21-м веке. Реалистичности добавляет и то, что на начало этого периода код писался и отлаживался на перфокартах, что не сильно способствовало продуктивности по сравнению с разработкой в интерактивной IDE.
Очень забавно, как в тексте с почтением твердятся эти "Миллионы транзакций в день" или "миллиард транзакций за шестичасовое окно".
У меня есть базки, которые тривиально выполняют сотни тысяч тразакций в секунду.
И сервис, который сохраняет в базу примерно квадриллион строк в день (гордится тут, конечно, нечем, это позор и растопка печки ассигнациями :) )
Язык программирования, который контролирует мировые финансы: 240 миллиардов строк кода на COBOL