Комментарии 60
Приятно
Однако, какой неожиданный всплеск потребности в Cobol-программерах, я как то посмотрел в его сторону некоторе время назад, надо сказать на любителя, некоторые операторы будут раздражать своей многобуквенностью… но посмотрю, что они там такое выложат:-)
НЛО прилетело и опубликовало эту надпись здесь
В Европейских банках или страховых разве не используются? Я как то интереса ради на xing.de сделал рассылку по словам Cobol developer, штуки три в месяц приходили.
000500 DATA DIVISION.
000510 WORKING-STORAGE SECTION.
000520 01 WS-A PIC 999.
000530 01 WS-B PIC 9(3).
000540 01 WS-RESULT PIC9(6).
PROCEDURE DIVISION.
000700 BEGIN.
000800 DISPLAY “Hello I'm your new calculator!”.
000900 DISPLAY “Please Enter first number from 0 to 999”.
001000 ACCEPT WS-A.
001100 DISPLAY “Please Enter second number from 0 to 999”.
001200 ACCEPT WS-B.
001300 DISPLAY “------------------------------------”.
001400 DISPLAY “ “.
001500 DISPLAY “Your results are:”.
001600 ADD WS-A TO WS-B GIVING WS-RESULT.
001700 DISPLAY “Summ is: ”, WS-RESULT.
001800 SUBTRACT WS-A FROM WS-B GIVING WS-RESULT.
001900 DISPLAY “Subtract is: ”, WS-RESULT.
002000 MULTIPLY WS-A BY WS-B GIVING WS-RESULT.
002100 DISPLAY “Multiplication is: ”, WS-RESULT.
002200 DIVIDE WS-A BY WS-B GIVING WS-RESULT.
002300 DISPLAY “Divide is: ”, WS-RESULT.
002400 STOP RUN.
000500 DATA DIVISION.
000510 WORKING-STORAGE SECTION.
000520 01 WS-A PIC 999.
000530 01 WS-B PIC 9(3).
000540 01 WS-RESULT PIC9(6).
PROCEDURE DIVISION.
000700 BEGIN.
000800 DISPLAY “Hello I'm your new calculator!”.
000900 DISPLAY “Please Enter first number from 0 to 999”.
001000 ACCEPT WS-A.
001100 DISPLAY “Please Enter second number from 0 to 999”.
001200 ACCEPT WS-B.
001300 DISPLAY “------------------------------------”.
001400 DISPLAY “ “.
001500 DISPLAY “Your results are:”.
001600 ADD WS-A TO WS-B GIVING WS-RESULT.
001700 DISPLAY “Summ is: ”, WS-RESULT.
001800 SUBTRACT WS-A FROM WS-B GIVING WS-RESULT.
001900 DISPLAY “Subtract is: ”, WS-RESULT.
002000 MULTIPLY WS-A BY WS-B GIVING WS-RESULT.
002100 DISPLAY “Multiplication is: ”, WS-RESULT.
002200 DIVIDE WS-A BY WS-B GIVING WS-RESULT.
002300 DISPLAY “Divide is: ”, WS-RESULT.
002400 STOP RUN.
НЛО прилетело и опубликовало эту надпись здесь
Каждый раз когда читаю все эти «DIVISION», представляю что исполнять это будет не компьютер, а целый этаж белых воротничков с калькуляторами и стопками бумаг )
Да, особенно когда, из средств ввода, под руками только печатная машинка/телетайп с вечно протертой ленточкой… и то в лучшем случае, а так — блокнот с ручкой ))
Если серьезно, то думаю, навыки программирования на Коболе могут быть востребованы только если находишься в США, и то не факт.
Для интереса поискал в Израиле: www.alljobs.co.il/SearchResultsGuest.aspx?position=1205 выдаёт кучу вакансий на Коболе.
в США сейчас примерно 200 вакансий всего по COBOL, это сложно назвать всплеском и даже бульком, разве что на фоне других полузабытых технологий и языков
IBM выпускает и поставляет своим заказчикам мейнфреймы с поддержкой COBOL
А можно ссылку хочется на это посмотреть
А можно ссылку хочется на это посмотреть
Ну если нет людей знающих кобол, наймите любого нормального програмиста за хороший прайс, я думаю он за неделю две в этом вашем коболе разберется. Там же не должно быть никакой магии в этом коболе чтобы нужен были бэкграунд 5+ лет.
Специфика есть у любого языка а вот со средствами разработки думаю там совсем беда. Даже просто пересесть с Intellij Idea на блокнот это боль. Пересесть на блокнот и COBOL это был бы тот еще челленж. Не говоря уже о том что мышление разработчика часто формируется первым языком программирования а дальше идут попытки перенести тот самый первый язык на новое поле. Так что я бы не был излишне оптимистичен указывая сроки освоения языка.
Почему сразу блокнот? Только vi ;)
На самом деле даже не знаю как там это все может выглядеть.
На самом деле даже не знаю как там это все может выглядеть.
Большинство программистов которые я знаю работают в vim.
Лично я использую geany. Так что IDE это не проблема.
И курсы же по COBOL, а не по IDE.
Что может быть сложно — это environment, там у них майнфреймы, вот это все. Наверное еще DB2 какой-нибудь. С другой стороны, можно найти того кто знает этот env и я уверен что COBOL для него станет проблемой.
Лично я использую geany. Так что IDE это не проблема.
И курсы же по COBOL, а не по IDE.
Что может быть сложно — это environment, там у них майнфреймы, вот это все. Наверное еще DB2 какой-нибудь. С другой стороны, можно найти того кто знает этот env и я уверен что COBOL для него станет проблемой.
Ну если нет людей знающих кобол, наймите любого нормального програмиста за хороший прайс, я думаю он за неделю две в этом вашем коболе разберется. Там же не должно быть никакой магии в этом коболе чтобы нужен были бэкграунд 5+ лет.
- Джуны — это не круто. Лучше бы с бэкграундом, пусть и в других языка.
- Кобол используется в старейший системах учета. Раньше компьютеры могли себе позволить только крупнейшие корпорации и крупнейшие банки. То есть типичный работодатель по Коболу — крупный банк. А если посмотреть какие десятки тысячи программистов продают западным банкам только украинские и российские бодишопы (там Java), то понятно, что и на Коболе нужен не один программист, и даже не 100.
- За совсем уж оверпрайс программист не нужен.
- Чтобы начать работу — программисту нужно все же разобраться. Кобол — не самый распространенный язык. Обучающих материалов нет. Именно эти материалы и собираются публиковать.
Причем тут джуны? Джун это человек без опыта программирования, а не опыта программирования на конкретном языке. Я уверен, что если мы возьмем нормального senior который давно и успешно может в enterprise на java или, допустим, человека с глубоким бэкгранудом в plain c, то он без проблем разбереться и с коболом. Другой вопрос что оно ему не нужно. А вот с этим курсами они как раз и наймут джуна который прошел эти курсы, но не факт что им это поможет и он сможет реально разобраться в том коде который там наворотили за 50 лет. Знание конкретного языка не особо помогает, все решает опыт.
Не знаю, насколько это правда, но слышал от чувака из IBM что проблема, неожиданно, — хороший прайс.
Недостаток коболистов в частном секторе — это миф.
А сильно нехватает их как раз в госсекторе, который не предлагает конкурентные деньги и близко. То есть клепать сайтики не только легче чем ковыряться в слоях ископаемых отходов полумертвых технологий, но и лучше оплачивается, да еще и смузи нальют.
Недостаток коболистов в частном секторе — это миф.
А сильно нехватает их как раз в госсекторе, который не предлагает конкурентные деньги и близко. То есть клепать сайтики не только легче чем ковыряться в слоях ископаемых отходов полумертвых технологий, но и лучше оплачивается, да еще и смузи нальют.
Дело не в языке, а в том, как его использовать в работе с данными в файлах. Как минимум, нужно отлично представлять структуру данных, как она может быть отражена в языке, какие возможности у операторов файлового ввода/вывода. Сорокалетняя программа может напрямую работать с файлами, реализуя метод ISAM, колхозить транзакции и прочие части ACID. Здесь важнее знание, как это все чисто и гармотно реализовать, нежели знание собственно самого языка. Также программа может использовать сервис межделмашевского сервера транзакций.
НЛО прилетело и опубликовало эту надпись здесь
Выкупила бы IBM этот ЯП и развивала бы его на благо всем.
Сами языки программирования не охраняются, только их конкретные реализации в виде компиляторов и интерпретаторов.
Мне кажется им прилетит за такой выкуп). Мейнфреймы и кобол это один из бизнесов IBM.
Проблема не столько в старости (вон С тоже не молод), сколько в специфике их решений. По сути это то, как выглядит 100% vendor lock. Если вы допустим представляете, как работает компьютер — ну там директории, файлы — можете смело забыть. Они для всего придумали собственную терминологию, с длинными названиями и кучей неочевидных нюансов. Будто система проектировалась таким образом, чтобы без специального обучения и кансалта в ней стороннему специалисту было не разобраться. Мечта фрилансера — даже код обфусцировать не нужно.
Из-за того, что подготовка дорогая и конкуренции на рынке практически нет, это довольно интересная ниша в плане стабильности как для разработчиков так и для организаций которым это нужно. Вас не заменят, но и сами бежать особенно некуда.
Проблема не столько в старости (вон С тоже не молод), сколько в специфике их решений. По сути это то, как выглядит 100% vendor lock. Если вы допустим представляете, как работает компьютер — ну там директории, файлы — можете смело забыть. Они для всего придумали собственную терминологию, с длинными названиями и кучей неочевидных нюансов. Будто система проектировалась таким образом, чтобы без специального обучения и кансалта в ней стороннему специалисту было не разобраться. Мечта фрилансера — даже код обфусцировать не нужно.
Из-за того, что подготовка дорогая и конкуренции на рынке практически нет, это довольно интересная ниша в плане стабильности как для разработчиков так и для организаций которым это нужно. Вас не заменят, но и сами бежать особенно некуда.
По сути это то, как выглядит 100% vendor lock. Если вы допустим представляете, как работает компьютер — ну там директории, файлы — можете смело забыть. Они для всего придумали собственную терминологию, с длинными названиями и кучей неочевидных нюансов.
Мне кажется, более корректно говорить о разных школах, некоторые из которых пошли в «масс-маркет» и потому стали известны широкому кругу людей.
А так — даже сейчас, здесь, на хабре видел претензию от человека, привыкшего к unix-way и стеку, претензии к NT, мол, почему и зачем они все свое придумали и называют иначе и делают по-другому, вот, мол, дураки, просто чтобы отличиться. Хотя это такое же legacy, полученное из, по сути, VAX/VMS, RSX и вообще DEC школы. Можно посмотреть на разницу подходов и терминологии в Netware в ту эпоху, когда они еще были конкурентами NT и т.д. Вот и здесь получилось, что у IBM своя школа, по понятным причинам не пошедшая в масс-маркет.
Я бы, пожалуй, прошел этот курс, чисто из любопытства.
как работает компьютер — ну там директории, файлы — можете смело забыть
Можно пример, что там вместо этого?
На свой новодельный СР/М-совместимый компьютер Microsoft COBOL-80 v4.01 установил ещё год назад. Вещь оказалась достаточно интересная, вот теперь упрекаю себя, что не занимался им плотно ;), поскольку литературы-то как раз и нет в наличии, хотя компик постоянно в работе…
в какой работе?
В смысле «какой»? Для себя на нём решаю две трети задач: набор текстов, база данных, аппаратный журнал, программирование и отладка (уже) редких микроконтроллеров, управление радиостанцией,… Писюк только для общения остался.
Если кому интересна, что за машинка, кратко описал её тут, rw6hrm.qrz.ru/z80.htm
Если кому интересна, что за машинка, кратко описал её тут, rw6hrm.qrz.ru/z80.htm
поскольку литературы-то как раз и нет в наличии
COBOL for the 21st Century 10th Edition, я такую в электронном виде искал, но не нашел.
Там же беда ни разу не с коболом как таковым, а с экосистемой, очень мало людей, понимающих, как работает мейнфрейм и весь стек технологий там, ничего общего с современным не имеющий. Далёкая аналогия — посадить фронтендера писать встраиваемые системы для авиации, притом не новые, а поддерживать какой-нибудь Боинг 737 или Ту-160.
НЛО прилетело и опубликовало эту надпись здесь
Жизнь была бы очень простой, если бы деньги можно было моментально конвертировать в специалистов или любые другие материальные блага. Но в материальном мире помимо денег нужно время — на обучение (в случае специалистов), наладку производства и логистики (в случае масок и аппаратов ИВЛ), рост сельхозкультур и вот это всё.
Т.е., помимо денег, должны быть мозги, чтобы это время запланировать заранее или, как в данном случае, преодолеть естественную жадность и годами тратить эти самые деньги на поддержание «устаревшей и ненужной» инфраструктуры на случай пушистых северных зверей.
Т.е., помимо денег, должны быть мозги, чтобы это время запланировать заранее или, как в данном случае, преодолеть естественную жадность и годами тратить эти самые деньги на поддержание «устаревшей и ненужной» инфраструктуры на случай пушистых северных зверей.
Когда и классический Бейсик с номерами строк понадобится кому-нибудь, предупредите.
В Японии есть традиция перестраивать храмы каждые [обычно] 20 лет. В итоге знание не теряется — участвовавшие в строительстве предыдущего храма могут в реальном проекте передавать навыки молодым.
Это была моя первая работа после института. Писать программы на КОБОЛе (которого я до этого не знал). И я не припомню, что были сложности в его изучении. Он древний и простой. Что-то типа улучшенного Фортрана для бухгалтерских задач. Но это было давно. Полагаю, в современном КОБОЛе полно всяких новомодных штучек.
А в чем проблема все это переписать на современный стек?
Ну т.е. я не думаю, что поддержка жуткого «легаси» будет проще и дешевле, чем переписывание всего стека. В конце концов не останется людей умеющих с ним работать, раз уже есть проблемы.
Или есть какая-то магия Кобола, которую нельзя сделать, например, на C++?
Или «работает — да и хер с ним» просто не прокатило в текущей ситуации, отсюда и шухер? А если все устаканится, то снова все забьют на Кобол?
Ну т.е. я не думаю, что поддержка жуткого «легаси» будет проще и дешевле, чем переписывание всего стека. В конце концов не останется людей умеющих с ним работать, раз уже есть проблемы.
Или есть какая-то магия Кобола, которую нельзя сделать, например, на C++?
Или «работает — да и хер с ним» просто не прокатило в текущей ситуации, отсюда и шухер? А если все устаканится, то снова все забьют на Кобол?
Нет там никакой магии. Там просто есть миллионы строк взаимосвязанного, корректно работающего кода и тысячелетия человеко-часов, вбуханных в его разработку и отладку. Нет никакого смысла делать эту работу снова. Банкомату же всё равно, какой там снаружи стек считается сейчас модным. Его задача выдать деньги. И он уже 20 лет спокойно себе работает на OS/2.
Судя по посту, все же не спокойно он там работает. И дело не в моде, а в поддержке.
Я сильно сомневаюсь, что все 20 лет там не вносилось никаких изменений и чтобы продолжать их вносить нужны разработчики, которые понимают что делают. Проблема сама по себе есть и чем дальше ее затянут, тем сильнее она затянет потом.
Да и никто не заставляет переписывать все и сразу, можно же частями. Я сомневаюсь, что там все миллионы строк — это одна цельная программа.
Я сильно сомневаюсь, что все 20 лет там не вносилось никаких изменений и чтобы продолжать их вносить нужны разработчики, которые понимают что делают. Проблема сама по себе есть и чем дальше ее затянут, тем сильнее она затянет потом.
Да и никто не заставляет переписывать все и сразу, можно же частями. Я сомневаюсь, что там все миллионы строк — это одна цельная программа.
«все это переписать на современный стек», который «завтра» потеряет актуальность. Или не потеряет. Это я к тому, что, наверное, оценкой рисков кто-то занимается и, вероятно, оставить все как есть, с минимальными изменениями для поддержки новых требований, может быть мене рискованным и эффективным с точки зрения вложений, которые потребуются на «всё переписать».
Нет проблемы, потому что нет такой задачи — переписать на «современный» стек. Это в Восточной Европе, где переизбыток инженеров и они готовы работать за копейки, есть устоявшаяся схема работы — инженер/сисадмин/штатный программист знает свою систему, может её оценить и видит, где можно и нужно что-то переделать.
В Северной Америке стандартная схема работы — система построена на заказ много лет назад. Обслуживающий персонал знает, как заводить новые учётные записи и, в лучшем случае, выполнять регламентные работы по инструкции. Если надо что-то поменять, идёт обращение в поддержку поставщика либо консалтинговой организации. Название должности — «системный администратор» — логично для такой административной должности и совсем не подходит под круг инженерных задач, которые выполняют «сисадмины» Восточной Европы.
Таким образом, просто нет того звена, которое бы оценивало "green screen" (как здесь ласково зовут терминальный доступ к мэйнфрейму) как что-то, что подлежит замене. Руководство в такие нюансы не вникает. Местные «администраторы» ведут свои административные дела согласно инструкции, для них что устаревшая система, что новейшая — всё равно чёрный ящик. Поставщик или обслуживающая организация очень заинтересованы в том, чтобы клиент оставался к ним привязан и не менял систему. Даже если мэйнфрейм находится в той же организации, то отдел его обслуживания, даже если в нём есть грамотные инженеры, всё равно не будет выходить с инициативой его замены, потому что это их хлеб, а специализация у них узкая, для обслуживания новой системы они не подойдут.
Ну и стоимость переписывания с нуля при текущих ценах на труд программистов достаточно пугает, чтобы не начинать переписывать, пока жареный петух не клюнет. Нет ведь никакой, скорее всего, документации уровня разработчика. Для операторов подробные инструкции есть. Может быть есть даже какие-то руководства по переустановке и ремонту. Но описаний алгоритмов, логики системы — нет. Плюс ко всему, кто-то же должен взять ответственность за то, что миграция пройдёт гладко. Если там банковские проводки, то потери от неправильных подсчётов легко переплюнут стоимость миграции.
И главное, а что случилось-то? Ну вылетают под нагрузкой старые системы. Снизят нагрузку. Объявят, что сегдодня принимают заявки только от людей, родившихся с января по март. Объяснят, что "we are experiencing higher than normal volume..." (110 миллионов результатов в Google). Это и в обычные-то времена нормально воспринимается, а уж в текущей ситуации — само собой.
В Северной Америке стандартная схема работы — система построена на заказ много лет назад. Обслуживающий персонал знает, как заводить новые учётные записи и, в лучшем случае, выполнять регламентные работы по инструкции. Если надо что-то поменять, идёт обращение в поддержку поставщика либо консалтинговой организации. Название должности — «системный администратор» — логично для такой административной должности и совсем не подходит под круг инженерных задач, которые выполняют «сисадмины» Восточной Европы.
Таким образом, просто нет того звена, которое бы оценивало "green screen" (как здесь ласково зовут терминальный доступ к мэйнфрейму) как что-то, что подлежит замене. Руководство в такие нюансы не вникает. Местные «администраторы» ведут свои административные дела согласно инструкции, для них что устаревшая система, что новейшая — всё равно чёрный ящик. Поставщик или обслуживающая организация очень заинтересованы в том, чтобы клиент оставался к ним привязан и не менял систему. Даже если мэйнфрейм находится в той же организации, то отдел его обслуживания, даже если в нём есть грамотные инженеры, всё равно не будет выходить с инициативой его замены, потому что это их хлеб, а специализация у них узкая, для обслуживания новой системы они не подойдут.
Ну и стоимость переписывания с нуля при текущих ценах на труд программистов достаточно пугает, чтобы не начинать переписывать, пока жареный петух не клюнет. Нет ведь никакой, скорее всего, документации уровня разработчика. Для операторов подробные инструкции есть. Может быть есть даже какие-то руководства по переустановке и ремонту. Но описаний алгоритмов, логики системы — нет. Плюс ко всему, кто-то же должен взять ответственность за то, что миграция пройдёт гладко. Если там банковские проводки, то потери от неправильных подсчётов легко переплюнут стоимость миграции.
И главное, а что случилось-то? Ну вылетают под нагрузкой старые системы. Снизят нагрузку. Объявят, что сегдодня принимают заявки только от людей, родившихся с января по март. Объяснят, что "we are experiencing higher than normal volume..." (110 миллионов результатов в Google). Это и в обычные-то времена нормально воспринимается, а уж в текущей ситуации — само собой.
Ну и стоимость переписывания с нуля при текущих ценах на труд программистов достаточно пугает, чтобы не начинать переписывать, пока жареный петух не клюнет.К этой сумме еще нужно добавить замену парка терминалов на ПК ил тонкие клиенты, обновление серверов/мейнфреймов, скорее всего длительное тестирование, возможные простои… Короче, никто в здравом уме такое делать не будет, пока бизнес не начнет терять деньги.
Всё так, замечу только, что аппаратные терминалы уже давно никто не использует, применяется протокол tn3270 поверх TCP/IP с/без TLS. На обычном компьютере устанавливается IBM Reflection или любой другой эмулятор терминала 3270, traffic может ходить по VPN через пол мира. Ещё популярны front-end web-сервера, которые подключаются по tn3270 к мэйнфрейму, а пользователю показывают web-интерфейс.
По Вашему комменту можно четко определить, что Вы программист из СНГ. Только СНГшники «легко» переписывают любой старый софт, в новую реинкарнацию, внося в него дополнительный порядок проблем и ошибок вместе с новыми функциями. Слава Богу, в штатах серьезные разрабы работают несколько по-другому. Проблема в другом, — нет, Cobol никогда не собирался умирать (подобные сообщения всегда вызывали улыбку), потихоньку приобретая современные (но ненужные ему функции, типа ООП), дабы удержать современную «молодежь» при «себе», что в принципе, немного удалось (Индия), и современным Рукразрабам, при доработке «старого софта», придется смириться с реализацией «новых глупостей в языке» при модификации ПО, но… этого мало, обязательно в большом количестве (~10 Cobol/1 HLASM) потребуются специалисты по языку HLASM (высокоуровневый ассемблер zOS), причем в современном, — 64 битном исполнении, а таких спецов почти нет (от слова совсем) и знатоки IBM ASMH (ASMF) — не подойдут (коих еще можно найти и «за речкой» и у нас). Новый HLASM похож на «старый» ASMH, как «барашек» на мотороллер (ТМ). И если, по моим расчетам, старого спеца по Коболу обучить новым «фичам» это 2-4 недели, то старых спецов ассемблера для превращения в «современных», потребуется 8-12 месяцев, а с «нуля», так года полтора-два. Интересно, что будут делать штатовцы?
Если вирус не затронет самих Ковбоев, так затронет их деятельность.
Любопытно читать в ретроспективе. Курс использует закрытый компилятор и среду исполнения от IBM. Она же является драйвером Open Mainframe Project и, вероятно, конечным бенефициаром сего действа.
Упомянутое обсуждение Tools and resources уже закрыто, но привело к двум инструментам с открытым кодом — Дебаггеру для VS Code и Среде исполнения в Докере на основе GnuCOBOL, силами пары энтузиастов в свободное время. Можно писать новый курс, Open по-настоящему.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
IBM проведет бесплатные курсы по COBOL и выложит их на GitHub