LINUX.ORG.RU

США из-за коронавируса срочно ищут знатоков COBOL. И не могут найти.

 


1

3

Власти американского штата Нью-Джерси начали поиски программистов, знающих язык COBOL, из-за возросшей в связи с коронавирусом нагрузки на старые ПК в американской системе занятости. Как пишет The Register, специалистам потребуется обновить программное обеспечение на мейнфреймах 40-летней давности, которые перестали справляться с нагрузкой, резко выросшей на фоне увеличившегося числа безработных из-за пандемии CoVID-19.

Проблема нехватки знающих COBOL программистов затронула не только Нью-Джерси. В штате Коннектикут власти тоже ищут специалистов по этому языку, притом в этом случае поиск ведется совместно с чиновниками еще трех штатов. Tom’s Hardware пишет, что их усилия, как и в Нью-Джерси, к успеху пока не привели. https://www.tomshardware.com/news/new-jersey-cobol-coders-mainframes-coronavirus

Согласно опросу Computer Business Review (https://www.cbronline.com/news/cobol-code-bases) , проведенному в I квартале 2020 г., с проблемой необходимости модернизации ПО в настоящее время сталкиваются 70% компаний, по тем или иным причинам до сих пор использующим программы, написанные на COBOL. Точное количество таких предприятий неизвестно, но, по информации Reuters, во всем мире в 2020 г. используется 220 млрд строчек кода этого языка.

COBOL активно применяется не только в системах занятости, но и в финансовых организациях. На 61-летнем языке написано 43% приложений, используемых в банковских сферах, и 95% банкоматов по всему миру в тех или иных масштабах используют созданное с его помощью ПО.

К числу причин, по которым организации не спешат отказываться от COBOL и переходить программы, созданные при помощи актуальных языков программирования – это дороговизна обновления. На своем примере это доказал Банк содружества Австралии, решившийся на полную замену всех приложений, написанных на COBOL.

Представители банка сообщили, что переход на новое ПО занял пять лет – он проходил в период с 2012 по 2017 гг. Размер затрат на это крупномасштабное мероприятие известен – апдейт обошелся банку почти в $750 млн.

>>> Подробности

★★★★★

Проверено: Pinkbyte ()
Последнее исправление: Pinkbyte (всего исправлений: 1)

Ответ на: комментарий от anonymous

Интересная статья. https://habr.com/ru/post/499090/ Усложнение команд консоли, 1979-2020

Говорят, что для такого усложнения инструментов командной строки нет никакой альтернативы. Но люди, которые так говорят, никогда не пробовали альтернативу, что-то вроде PowerShell. У меня много претензий к PowerShell,

Когда автор этой статьи решил покритиковать UNIX-way, какими мотивами он руководстовался? Он хотел конструктивной критики, или может он хотел тонко восхвалить PowerShell, прорекламировать Windows OS. Наверно второе, это в принципе всё что надо знать об этой статье.

Надеюсь, Dan Luu получил деньги от Майкрософт за свою статью.

anonymous
()
Ответ на: комментарий от Vit

Ты видишь шашечки, а не суть ситуации. Оба проекта опенсорсные, не имеющие серьезного прессинга со стороны бизнеса

Опенсорс уже давно подмят бизнесом, просто результат разработки не продается напрямую, а используется для оказания услуг или в составе закрытых разработок. Роль добровольцев при этом заключается скорее в пожертвованиях и исправлении простых багов. Даже работая фултайм кодером над мозилой не получится досконально понять его работу, потому что спустя те несколько лет, которые пройдут до освоения основных вещей, браузер уже поменяют и старые знания будут бесполезны, и это явление усугубляется по мере снижения вовлеченности — «добровольцу» тут нечего ловить, разве что он согласится добровольно работать пять дней в неделю над проектом. И именно фаерфокс является частым предметом споров по поводу его абсурдной опенсорсности: вроде сорцы есть, но сделать с ними толком ничего нельзя.

Дебиан устроен совершенно иначе, и можно иметь лишь минимальные знания о внутренней кухне, при этом успешно собирая пакеты, которые потом может быть попадут в официальные реализы... или не попадут, это не так важно.

выбирать приходится не между «хорошо» и «плохо», а между «вовремя» и «никогда»

Когда наступает «вовремя»? К слову, падение популярности ФФ имеет мало отношения к модели разработки, а вызвано главным образоз агрессивной политикой гугла — именно поэтому я удивлен этой попытке ставить в один ряд дебиан и ФФ.

byko3y ★★★★
()
Ответ на: комментарий от linuxmachtfrei

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

linuxmachtfrei
()
Ответ на: комментарий от byko3y

Ты очень «шумный», и вместо внятного формулирования одной мысли валишь в кучу десяток мусорных. Если считаешь что мне интересно вести на лоре интеллектуальные беседы - зря. Могу делиться опытом, если недолго, и если нужно.

У тебя в декларациях про идеальное качество был очевидный косяк - отсутствие сроков. Из-за которых качеством приходится управлять. На что я попытался обратить внимание, с наглядными примерами. Но если тебе важнее на лоре с бронивичка повещать - ноу проблем, только без меня.

Когда наступает «вовремя»?

Когда в расписании написано. А для этого оно должно быть.

Vit ★★★★★
()
Ответ на: комментарий от linuxmachtfrei

что значит «универсальное» текстовое представление?

Ну в роде «всё есть текст и одна программа передает инфу другой в виде текста». Имя файлов, список процессов, имена пользователей, просто какие-то вспомогательные цифры или текст. Уже в 80-х стало довольно очевидно, что неструктурированный текст малопригоден для обработки.

byko3y ★★★★
()
Ответ на: комментарий от linuxmachtfrei

сама философия Unix неизбежно привела к беспорядку, в котором мы находимся.

афтар - ебанат, что тут ещё скажешь

Уже выучил наизусть все флаги «ls», и не хочешь, чтобы тебя лишали работы?

byko3y ★★★★
()
Ответ на: комментарий от linuxmachtfrei

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

В каком месте экономит? Я сколько лет пользовался ноутбуками - ни разу не пришла в голову мысль «эх, сейчас бы гугл помог сэкономить».

byko3y ★★★★
()
Ответ на: комментарий от Vit

У тебя в декларациях про идеальное качество был очевидный косяк - отсутствие сроков. Из-за которых качеством приходится управлять

Зачастую такое «управление качеством» нужно заказчикам или проектам, которые через год-другой разорятся и закроются. Если же потребителю софт нужен в стабильном работоспособном состоянии, то сроки отодвигаются по необходимости. Можно заложить срок релиза троекратно превыщающий оценку, но что делать, когда проект готов намного раньше? И что делать, если даже такие сроки оказались недостаточными. Программирование — это такая индустрия, что проекты длиннее недели уже не поддаются оценкам.

Если нужно надуть пузырь, устроить пшик, то да, нужно за несколько месяцев до релиза торжественно объявить день релиза, и устроить парад в день релиза, даже если в согфтине остались уязвимости удаленного выполнения и оно падает стабильно хотя бы раз в день — примерно так релизились MongoDB и Docker, например.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Если же потребителю софт нужен в стабильном работоспособном состоянии, то сроки отодвигаются по необходимости.

Ну вот я для этого привел пример, что было с «дебиан будет готов когда будет готов». А как программистское «еще пол часика» на неделю растягиватся - каждый должен был сталкиваться.

Наличие внятных сроков - это тоже «качество» проекта, и по статистике выходит, что оно еще важнее качества кода.

И что делать, если даже такие сроки оказались недостаточными. Программирование — это такая индустрия, что проекты длиннее недели уже не поддаются оценкам.

Использовать регулярные или непрерывные релизы. Чтобы подстраиваться по ходу.

и оно падает стабильно хотя бы раз в день — примерно так релизились MongoDB и Docker, например.

Это не страшно. Просто в ответственных местах никто не апдейтится на свежий мажорный рлиз. И проблем от этого намного меньше, чем от полной неизвестности со сроками, когда вообще ничего невозможно планировать.

Vit ★★★★★
()
Ответ на: комментарий от byko3y

Уже в 80-х стало довольно очевидно, что неструктурированный текст малопригоден для обработки.

Некоторые вещи имеют вполне банальное объяснение. Просто некоторых людей напрягает работа в терминале. И такие люди всё время ворчат на ценности Юникс.

А вообще, цифровой шум облечённый в символьное представление труден для анализа, но анализ вполне возможен. А вот любой человеческий язык представленный в любой письменной лёгок для анализа, так как уже по своей сути структурированным явлением.

anonymous
()
Ответ на: комментарий от Vit

Наличие внятных сроков - это тоже «качество» проекта, и по статистике выходит, что оно еще важнее качества кода

Какой еще статистике? Статистике стартапов, которые и для которых делали релизы в срок? А сколько из них прожило два года? Дистр можно релизить каждые два месяца, но какой в этом смысл? Я подозреваю, что я здесь чего-то не улавливаю, и кому-то очень важно делать регулярные или планируемые релизы, но я почему-то не вижу этих людей, почему-то я вижу любо людей, которые будут пользоваться даже сырющим софтом и ставить патчи два раза в месяц, и я других вижу людей, которые сидят на втором питоне, ES4, и 3.3.16. Я не вижу тех самых людей, которые действуют путем «через два месяца нам релизнут софтину, и мы должны будем готовы сразу переходить не нее».

Использовать регулярные или непрерывные релизы. Чтобы подстраиваться по ходу

Непрерывные? Чем это отличается от отсутствия релизов a.k.a. билд по ревизии из репы?

Просто в ответственных местах никто не апдейтится на свежий мажорный рлиз. И проблем от этого намного меньше, чем от полной неизвестности со сроками, когда вообще ничего невозможно планировать

Во-о-от, релиз есть, но пользоваться им нельзя - в чем тогда его смысл? Какое планирование выручило бы разрабов Firefox? То есть, какую фичу может ждать рядовой пользователь? Лично мне, например, от браузера ничего нового не нужно было, мне скорее нужно было другое — чтобы разрабы не ломали старые расширения со своим Quantum.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Дистр можно релизить каждые два месяца, но какой в этом смысл?

В обратной связи. И в том что «заказчик» (потребитель) видит результат.

Я подозреваю, что я здесь чего-то не улавливаю, и кому-то очень важно делать регулярные или планируемые релизы, но я почему-то не вижу этих людей,

Не знаю твой круг интересов, поэтому не могу комментировать. Я для примера привел 2 достаточно популярных проекта.

Пока у тебя на поруках один мелкий личный проект - ты можешь качество до бесконечности вылизывать. Как только количество проектов и их размеры растут, а в сутках по прежнему 24 часа, приходится искать компромиссы. И внезапно выясняется, что качество херить можно, а сроки крайне не желательно. Исключения конечно есть, но принцип примерно такой.

Непрерывные? Чем это отличается от отсутствия релизов a.k.a. билд по ревизии из репы?

Наличием обратной связи от юзеров, высоким покрытием тестами и автоматическим деплоем если тесты прошли.

Во-о-от, релиз есть, но пользоваться им нельзя - в чем тогда его смысл?

Это тем кому надежность критична нельзя, а фанбоям вполне.

Уточни пожалуйста свои вопросы, а то как-то все в чатик скатывается. Те не веришь в возможность планирования регулярных релизов и их необходимость для большинства проектов сложнее школьных лаб?

Vit ★★★★★
()
Ответ на: комментарий от Vit

Дистр можно релизить каждые два месяца, но какой в этом смысл?

В обратной связи. И в том что «заказчик» (потребитель) видит результат

У FF и Debian есть пререлизные версии. О чем тогда разговор? Даже closed-source тестируют в узком кругу особо лояльных фанатов, прежде чем выпустить в широкую публику. Никто не выпускает софт внезапно из нуля в стабильный релиз — о чем разговор?

Пока у тебя на поруках один мелкий личный проект - ты можешь качество до бесконечности вылизывать. Как только количество проектов и их размеры растут, а в сутках по прежнему 24 часа, приходится искать компромиссы. И внезапно выясняется, что качество херить можно, а сроки крайне не желательно. Исключения конечно есть, но принцип примерно такой

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

Отсюда вопрос: какая разница между сроками релиза софтины, которой не будут пользоваться? Если бы заказчики платили за релиз, а не за работающий софт — наши позиции тогда бы совпадали. Но даже в современной экономической модели желающих платить за сам релиз не так уж и много.

Непрерывные? Чем это отличается от отсутствия релизов a.k.a. билд по ревизии из репы?

Наличием обратной связи от юзеров, высоким покрытием тестами и автоматическим деплоем если тесты прошли

И каким образом отсутствие релизов запрещает пользователям давать обратную связь, запрещает покрывать софт тестами и делать деплои (куда?)?

Те не веришь в возможность планирования регулярных релизов и их необходимость для большинства проектов сложнее школьных лаб?

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

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Представим себе мысленный диалог

byko3y: Аллё, это бухгалтерия? А когда зарплата за апрель будет?

бух: Делаем. Доделаем, скажем.

byko3y: Ну, хотя бы примерные сроки скажите пожалуйста.

бух: А качество вам совсем не важно уже? Правильное движение средств есть основа финансовой деятельности предприятия. Доведём систему управления финансами до совершенства, тогда и зарплату отправим.

byko3y: А на прошлой работе зарплату сразу платили.

бух (раздражённо): Да они там дебилы все … (Дальше следует 5 минутный диалог на тему почему только его способ соответствует его чувству прекрасного, а все остальные способы — отстой для ламеров).

byko3y: Дети малые плачут, кушать просят.

бух: В ЖОПУ ИДИ, ПЁС, ДОСТАЛИ ПОЛУДУРКИ, НИЧЕГО НЕ ПОНИМАЮТ, А ТУДА ЖЕ КОМАНДОВАТЬ ЛЕЗУТ!!!!!

ugoday ★★★★★
()

Проблема решена!

https://tech.informator.ua/2020/04/15/vyplata-posobij-postradavshim-ot-covid-19-v-ssha-okazalas-pod-ugrozoj-iz-za-60-letnego-yazyka-programmirovaniya/

Чтобы справится с кризисом, власти Флориды решили полностью отказаться от старых компьютерных систем и перейти на бумажный документооборот.

Все гениальное - просто.

Владимир

anonymous
()
Ответ на: комментарий от anonymous

Все гениальное - просто.

Было бы ещё гениально, если бы они закупили компьютеры с GNU/Linux.

anonymous
()
Ответ на: комментарий от anonymous

Чтобы справится с кризисом, власти Флориды решили полностью отказаться от старых компьютерных систем и перейти на бумажный документооборот.

Молодцы, я еще на первых страницах это предложил. В печь эти менфреймы вместе с разжиревшими ветеранами кобола.

bread
()
Ответ на: Представим себе мысленный диалог от ugoday

бух: А качество вам совсем не важно уже? Правильное движение средств есть основа финансовой деятельности предприятия. Доведём систему управления финансами до совершенства, тогда и зарплату отправим

Ты не понимаешь сути бухгалтерии в СНГ — зачем ты ее приводишь в пример? Конкретно на моем нынешнем рабстве, например, имеет место непредсказуемая задержка выплат в несколько дней, у нее есть вполне объективные причины.

byko3y ★★★★
()
Ответ на: комментарий от bread

В печь эти менфреймы вместе с разжиревшими ветеранами кобола.

Добрейшей души человек.

О доброте Ленина.

Крупская выступает перед пионерами:

— Дорогие дети! Всем известна доброта Ленина.
Я вам расскажу такой случай.  
Однажды Ленин брился у шалаша в Разливе, а мимо шел маленький мальчик.  
Ленин бритвочку точит, а сам на мальчика поглядывает.  
Вот Ленин побрился, кисточку вымыл, опять бритвочку точит, на мальчика поглядывает.  
Потом бритвочку вытер и положил в футлярчик.  
А ведь мог бы и полоснуть!..
anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.