А АКБ жив? Если АКБ прошивкой/системой помечен как проблемный/неисправный - система будет достаточно жестко ограничивать производительность процессора даже когда питание от сети подключено. Проще и надежнее в этом случае заменить АКБ.
А это особенность организации "классической" части операционной системы z/OS (предки: MVS и OS/390). Там действительно нет иерархической файловой системы в том виде как она есть для Windows/Unix/Linux.
Есть таблица оглавления диска "VTOC" и именованные "наборы данных". Имена наборов данных "одномерные" с максимальной длиной в 44 символа. По сути "набор данных" это аналог файла, но, в отличие от файла он имеет набор дополнительных параметров определяющих его свойства и назначение. От этих свойств зависит способ работы с этим набором даных.
Кроме этого на уровне операционной системы есть структура каталогов которая объединяет оглавления разных дисков в единое представление.
Поэтому "иерархической файловой системы" там действительно нет, но при этом информация на диске структурирована, правильнее будет сказать что "плоская" файловая система там есть.
Кроме "классической" части в z/OS есть еще и "Unix" часть, вот там уже есть вполне привычная иерархическая файловая система, Unix-way.
Насколько я помню у IBM было собственное руководство по разработке таких интерфейсов и там было и про цвета и их комбинации, и про взаимное расположение элементов, и про количество элементов на экране и про именование команд и сокращений и про допустимое количество «шагов» (переходов) между пунктами и многое другое. Полезное руководство было.
Кстати до сих пор в IBM z/OS многие действия быстрее и «короче» выполнить в терминале 3270 чем через аналогичное браузерное приложение.
Недавно случайно выяснили что Apple Maps лучше «знают» про местные автобусные и трамвайные маршруты (Германия, Маннхейм). Там где гуглокарты предлагали только пешком или на такси - карты Apple подсказали актуальные маршруты общественного транспорта.
Озвучьте пожалуйста "критично значительные" минусы лент и ленточных накопителей.
Сразу напоминаю что лента (ленточный картридж) это сменный накопитель предназначенный для последовательного чтения или записи больших объемов данных. Не предназначена для быстрого произвольного доступа.
Основное назначение - долговременное хранение данных. Насколько я помню: в оптимальных условиях до 30 лет, в реале 10-20 лет. Более точно нужно смотреть спецификации на конкретные стандарты и поколения.
Современный HDD является технически сложным устройством и не факт что он сможет гарантированно пролежать на полке без единого включения 10-20 лет и остаться исправным.
Получается что на ленте с определенного объема хранить данные будет просто дешевле, даже при том что устройство чтения LTO-9 обойдётся в ~6000$. Если не ошибся в расчетах, то уже (50 лент + привод) будут равны по стоимости 50 HDD на 18 ТБ. (120$*50+6000$ = 240$*50).
Если эксплуатируют и не собираются отказываются - значит все устраивает. Почему бы и не похвалить тогда?
Я хвалю ленты и ленточные библиотеки. Свой класс задач они решают, проблем (с точки зрения настройки/эксплуатации) особо не доставляют. Да, как любое другое оборудование - оно тоже иногда выходит из строя, но это решается гарантией или резервированием.
PS: Пару раз участвовал в процессе миграции данных между физически удаленными площадками когда допустимое время на "простой" было весьма ограничено, возможности настроить репликацию данных не было, а копирование данных по интернет-каналу не умещалось в выделенный промежуток времени. При этом на обоих площадках были ленточные приводы и задача решалась выгрузкой данных на ленты, физической доставкой лент на другую площадку (в одном из случаев это был самолет) и дальнейшей загрузкой данных с лент. После миграции эти же ленты стали частью ленточной библиотеки для регулярного использования. Да можно было бы сделать подобное и на обычных HDD, но их еще нужно было где-то приобрести к моменту миграции, а ленты уже были в наличии и они из библиотеки изымаются/вставляются штатно.
Мой ответ был на комментарий что ленты хвалят те кто их "не пробовал". Так вот это не так. Есть те кто эксплуатирует и отказываться не собирается.
Компания, где работаю, ежегодно пересматривает и оценивает эксплуатационные расходы. Если будет приемлемая альтернатива лентам - от них откажутся. Я работаю в команде которая отвечает, в том числе, и за реализацию политик хранения, миграции и восстановления данных. Мы регулярно оцениваем альтернативы на предмет снижения эксплуатационных расходов.
Ленты и ленточные библиотеки вполне себе конкурентны с другими технологиями для конкретных сценариев. Но да, можно и без лент обойтись и построить систему резервного копирования на других технологиях. Зависит от ситуации, потребностей и возможностей.
Это зависит от конкретного бизнеса, юридических/законодательных обязательств по сохранности и срокам хранения данных, объёмов хранимых и обрабатываемых данных и многого другого.
У компании где работаю сейчас (Германия, основной офис - США) - две площадки. На каждой площадке есть СХД, виртуальная ленточная библиотека и физическая ленточная библиотека. Между площадками настроена репликация отдельно для СХД и отдельно для виртуальных лент. Далее каждая виртуальная ленточная библиотека независимо "экспортирует" виртуальные ленты на физические ленты. Все оборудование на гарантии и на поддержке. Компания коммерческая, расходы считает достаточно четко. Текущая конфигурация по соотношению расходов и рисков всех устраивает.
По хорошему устройств любого типа (речь не только про чтение/запись лент, но например и про маршрутизатор) нужно иметь как минимум два чтобы обеспечить хоть минимальную защиту от неожиданного выхода из строя. Это "мышку" можно купить быстро и то желательно иметь запас у себя на складе чтобы быстро заменить. А тут - часть системы резервного копирования. Если устройство чтения лент всего одно - значит есть шанс на неопределенное время остаться без доступа ко всем архивам пока не будет найдена, куплена и доставлена замена.
Следом вопрос к организации эксплуатации - вовремя заменять устройства на более новые по заданным критериям (срок работы, снятие с поддержки вендором, окончание срока гарантии и т.п.). То же относится и к лентам - периодически заменять и следить чтобы используемый тип лент был совместим с текущим (а желательно и следующим) поколением устройств для чтения.
Одиночная лента которую нужно ручками доставать из спец. хранилища и руками вставлять в считыватель - это конечно "дико холодные" данные.
Автоматическое ленточное хранилище это уже "гораздо теплее". Основная задержка там - это роботу "взять ленту из лотка и доставить в считыватель" + "перемотать до нужного места" и далее уже последовательное чтение или запись данных с достаточно высокой скоростью. Для архивов, резервных копий, архивных логов СУБД и других файлов которые нужно читать или писать только целиком и последовательно - отлично подходит. ПО управления ленточной библиотекой помогает управлять "жизненным циклом" данных на лентах.
Там где нужно минимизировать задержки на обращение к физическим лентам - перед физическими лентами ставят "виртуальную ленточную библиотеку" которая по интерфейсу - лента, но фактически внутри нее диски SSD или HDD, и она служит кэшем/буфером к физической ленте.
Те организации кто пишут/читают большие объемы лент - обычно не вставляют картриджи с лентой вручную. Там используются полностью автоматические хранилища, внутри которых полки с лентами и несколько "роботов" и приводов для работы с этими лентами. С жесткими дисками подобную автоматику сделать конечно можно. Но, насколько я помню, жесткие диски не любят частых включений/выключений и физических перемещений. Поэтому для жестких дисков это "вырождается" в обычные дисковые полки или массивы где диски включены постоянно, тратят свой физический ресурс, потребляют электричество и греют воздух.
Конечно, условия хранения должны быть соблюдены и это справедливо для любого носителя данных.
Для бумаги/пергамента тоже нужны определенные условия хранения, просто "диапазон" другой. Бумага тоже боится огня и влажности, ее могут "погрызть", используемые компоненты для печати могут выцвести, и т.п.
У ленты гораздо более высокая плотность хранения по сравнению с бумагой и при записи используются технологии для возможности восстановления данных: избыточность, специальное кодирование и т.д. Ну и для тех кому это действительно нужно, могут использовать несколько разных типов носителей, в расчете что что-то да сохранится.
Согласно спецификации IBM на картриджи 3592, они должны хранить данные порядка 30 лет. В самом документе, в разных местах написано "более 30 лет" и "до 30 лет". Сами картриджи разных моделей вышли уже после 2000г., поэтому эти данные приведены по тестам "ускоренного старения", так как даже самые старые картриджи из этой линейки "доживут" до указанного значения через 12 лет (2033 г.).
Насколько я помню, финансовые организации, в соответствии с законодательством стран, где они работают, обязаны хранить исторические данные очень много (десятки) лет. При этом, по правилам, нужно хранить несколько копий, географически удаленно друг на друга. Т.е. "потерять" эти данные финансовая организация не имеет права ни в коем случае.
Уж не знаю как сейчас насчет "физической бумаги", хотя ранее видел как печатают и хранят ежедневную бумажную отчетность по определенным операциям.
Практики, когда важные данные выгружаются на ленту (несколько копий) и развозятся по разным изолированным складам/хранилищам точно существуют и по сей день. Хранить магнитную ленту все таки проще и дешевле чем, например, жесткие диски сравнимого объема.
Нет конечно. :) В качестве "первичного носителя" магнитная лента не используется очень давно (точно более 20 лет). Используются внешние СХД, сейчас все чаще "Full Flash".
При этом, магнитная лента вполне себе используется и сейчас как второй/третий уровень для хранения резервных копий и миграции "холодных" данных. Емкость современных магнитных картриджей очень неплоха, 20ТБ сырой емкости на картридж размером 25ммx110ммx125мм.
Почему-то говоря про 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 позволяет поднимать уровень системного и прикладного ПО "на ходу", без простоя. Понятное дело, что происходит это поочерёдно на каждом из "узлов" кластера и отдельные узлы какое-то время будут поочередно недоступны, но перерыва в обработке транзакций не будет. Аналогично можно и сервера целиком заменить поочередно.
Это процессор для следующего поколения серверов линейки IBM Z, текущее поколение - z15. В первую очередь это процессор общего назначения, но с новым дополнительным функционалом.
В поколении z15 в процессор "запихали" дополнительные блоки для компрессии данных, которые раньше реализовывались за счет внешних устройств (z/EDC). Это дало прирост производительности, так как данные сжимаются и разжимаются "близко" к процессору.
В новом поколении похоже проделали аналогичный "фокус" и добавили в процессор некий AI-модуль, в который можно поместить готовую обученную модель нейросети. Это дает возможность выполнить AI-операции над данными в кэше процессора, т.е. быстро и непосредственно в процессе обработки транзакции.
Скорее всего, IBM предложит готовый API для взаимодействия с этими новыми AI-блоками и встроит поддержку в свои основные продукты для IBM Z.
Сравнивать джоб (в ОС z/OS) с микросервисом по моему не совсем правильно. Джоб — это все таки ближе к Shell или Windows Batch. Это весьма простой язык (JCL) предназначенный для запуска программы или цепочки программ на исполнение. Shell по сравнению c JCL — гораздо более сложен.
Джоб на мейнфреме (ОС z/OS) вполне может быть очень простым.
Минимальный джоб — это буквально две строки в JCL. Первая — заголовок JOB, вторая — STEP, который вызывает программу или скрипт (процедуру в терминах JCL).
Если джоб «наворотили» и он состоит из 50+ шагов со сложными условиями и зависимостями — это вполне себе повод для рефакторинга, как и любой другой код (например скрипт на Shell). Хотя, могут быть случаи когда это обосновано.
То что на конкретном «мейнфрейме» нет стейджинг-систем — это опять же проблема не «мейнфрейма», а организации процесса внедрения и эксплуатации. Сам «мейнфрейм», как и любой другой сервер, ну никак этому не мешает.
Спеца на Котлин/Джаву проще найти «сейчас», сложно сказать как оно будет через N-лет. Я не к тому что Кобол вдруг станет популярнее, я к тому что Котлин/Джава тоже могут потерять популярность и специалистов по этим языкам станет меньше.
А АКБ жив? Если АКБ прошивкой/системой помечен как проблемный/неисправный - система будет достаточно жестко ограничивать производительность процессора даже когда питание от сети подключено. Проще и надежнее в этом случае заменить АКБ.
Есть еще вариант "пошаманить" с настройками CPU чтобы заблокировать получение процессором сигнала "BD_PROCHOT". Сам такое не пробовал.
Найдено здесь: https://hackaday.com/2023/02/17/hack-lets-intel-macbook-run-without-a-battery/
А это особенность организации "классической" части операционной системы z/OS (предки: MVS и OS/390).
Там действительно нет иерархической файловой системы в том виде как она есть для Windows/Unix/Linux.
Есть таблица оглавления диска "VTOC" и именованные "наборы данных". Имена наборов данных "одномерные" с максимальной длиной в 44 символа. По сути "набор данных" это аналог файла, но, в отличие от файла он имеет набор дополнительных параметров определяющих его свойства и назначение. От этих свойств зависит способ работы с этим набором даных.
Кроме этого на уровне операционной системы есть структура каталогов которая объединяет оглавления разных дисков в единое представление.
Поэтому "иерархической файловой системы" там действительно нет, но при этом информация на диске структурирована, правильнее будет сказать что "плоская" файловая система там есть.
Кроме "классической" части в z/OS есть еще и "Unix" часть, вот там уже есть вполне привычная иерархическая файловая система, Unix-way.
IBM Omegamon ?
Насколько я помню у IBM было собственное руководство по разработке таких интерфейсов и там было и про цвета и их комбинации, и про взаимное расположение элементов, и про количество элементов на экране и про именование команд и сокращений и про допустимое количество «шагов» (переходов) между пунктами и многое другое. Полезное руководство было.
Кстати до сих пор в IBM z/OS многие действия быстрее и «короче» выполнить в терминале 3270 чем через аналогичное браузерное приложение.
Недавно случайно выяснили что Apple Maps лучше «знают» про местные автобусные и трамвайные маршруты (Германия, Маннхейм). Там где гуглокарты предлагали только пешком или на такси - карты Apple подсказали актуальные маршруты общественного транспорта.
Озвучьте пожалуйста "критично значительные" минусы лент и ленточных накопителей.
Сразу напоминаю что лента (ленточный картридж) это сменный накопитель предназначенный для последовательного чтения или записи больших объемов данных. Не предназначена для быстрого произвольного доступа.
Основное назначение - долговременное хранение данных. Насколько я помню: в оптимальных условиях до 30 лет, в реале 10-20 лет. Более точно нужно смотреть спецификации на конкретные стандарты и поколения.
Современный HDD является технически сложным устройством и не факт что он сможет гарантированно пролежать на полке без единого включения 10-20 лет и остаться исправным.
Другие параметры LTO-9 на примере FUJIFILM: https://asset.fujifilm.com/www/us/files/2021-09/00cf66b46b9ddfd4c3f35d8f93230c7d/FB_LTO9_SellSheet_V1.pdf
Размер картриджа: ~ 110x110x22(мм).
Вес картриджа: 250-300 грамм.
Стоимость: примерно 120$ (смотрел в Амазоне).
Картридж: https://www.amazon.de/-/en/LTO9-18TB-45TB-Ultrium-BaFe/dp/B09L4TLR6D/ref=sr_1_3?crid=1F0KCM0EGJA08&keywords=LTO9+tape&qid=1693503979&sprefix=lto9+tape%2Caps%2C186&sr=8-3
Привод для чтения картриджей: https://www.amazon.de/-/en/StoreEver-LTO-9-Ultrium-45000-Internal/dp/B0B45D5PGL/ref=sr_1_12?crid=1RHDNMJWV06NW&keywords=LTO9+drive&qid=1693503422&sprefix=lto9+drive%2Caps%2C155&sr=8-12
HDD аналогичной емкости (18ТБ) будет немного больше по физическим размерам, тяжелее в 2-3 раза и дороже примерно в два раза.
https://www.amazon.de/-/en/Toshiba-18TB-Enterprise-Internal-Drive/dp/B093Z5LFWD/ref=sr_1_4?crid=27QDCEXOA78CG&keywords=HDD%2B18TB&qid=1693504033&sprefix=hdd%2B18tb%2Caps%2C138&sr=8-4&th=1
Получается что на ленте с определенного объема хранить данные будет просто дешевле, даже при том что устройство чтения LTO-9 обойдётся в ~6000$. Если не ошибся в расчетах, то уже (50 лент + привод) будут равны по стоимости 50 HDD на 18 ТБ. (120$*50+6000$ = 240$*50).
Если эксплуатируют и не собираются отказываются - значит все устраивает. Почему бы и не похвалить тогда?
Я хвалю ленты и ленточные библиотеки. Свой класс задач они решают, проблем (с точки зрения настройки/эксплуатации) особо не доставляют. Да, как любое другое оборудование - оно тоже иногда выходит из строя, но это решается гарантией или резервированием.
PS: Пару раз участвовал в процессе миграции данных между физически удаленными площадками когда допустимое время на "простой" было весьма ограничено, возможности настроить репликацию данных не было, а копирование данных по интернет-каналу не умещалось в выделенный промежуток времени.
При этом на обоих площадках были ленточные приводы и задача решалась выгрузкой данных на ленты, физической доставкой лент на другую площадку (в одном из случаев это был самолет) и дальнейшей загрузкой данных с лент. После миграции эти же ленты стали частью ленточной библиотеки для регулярного использования.
Да можно было бы сделать подобное и на обычных HDD, но их еще нужно было где-то приобрести к моменту миграции, а ленты уже были в наличии и они из библиотеки изымаются/вставляются штатно.
Согласен.
Если одной ленты хватает на неделю - тогда можно и руками поменять. Но это относительно небольшие объемы данных.
Мой ответ был на комментарий что ленты хвалят те кто их "не пробовал". Так вот это не так. Есть те кто эксплуатирует и отказываться не собирается.
Компания, где работаю, ежегодно пересматривает и оценивает эксплуатационные расходы. Если будет приемлемая альтернатива лентам - от них откажутся. Я работаю в команде которая отвечает, в том числе, и за реализацию политик хранения, миграции и восстановления данных. Мы регулярно оцениваем альтернативы на предмет снижения эксплуатационных расходов.
Ленты и ленточные библиотеки вполне себе конкурентны с другими технологиями для конкретных сценариев. Но да, можно и без лент обойтись и построить систему резервного копирования на других технологиях. Зависит от ситуации, потребностей и возможностей.
Это зависит от конкретного бизнеса, юридических/законодательных обязательств по сохранности и срокам хранения данных, объёмов хранимых и обрабатываемых данных и многого другого.
У компании где работаю сейчас (Германия, основной офис - США) - две площадки. На каждой площадке есть СХД, виртуальная ленточная библиотека и физическая ленточная библиотека. Между площадками настроена репликация отдельно для СХД и отдельно для виртуальных лент. Далее каждая виртуальная ленточная библиотека независимо "экспортирует" виртуальные ленты на физические ленты. Все оборудование на гарантии и на поддержке. Компания коммерческая, расходы считает достаточно четко. Текущая конфигурация по соотношению расходов и рисков всех устраивает.
Так это уже вопрос к организации эксплуатации.
По хорошему устройств любого типа (речь не только про чтение/запись лент, но например и про маршрутизатор) нужно иметь как минимум два чтобы обеспечить хоть минимальную защиту от неожиданного выхода из строя. Это "мышку" можно купить быстро и то желательно иметь запас у себя на складе чтобы быстро заменить. А тут - часть системы резервного копирования. Если устройство чтения лент всего одно - значит есть шанс на неопределенное время остаться без доступа ко всем архивам пока не будет найдена, куплена и доставлена замена.
Следом вопрос к организации эксплуатации - вовремя заменять устройства на более новые по заданным критериям (срок работы, снятие с поддержки вендором, окончание срока гарантии и т.п.). То же относится и к лентам - периодически заменять и следить чтобы используемый тип лент был совместим с текущим (а желательно и следующим) поколением устройств для чтения.
Одиночная лента которую нужно ручками доставать из спец. хранилища и руками вставлять в считыватель - это конечно "дико холодные" данные.
Автоматическое ленточное хранилище это уже "гораздо теплее". Основная задержка там - это роботу "взять ленту из лотка и доставить в считыватель" + "перемотать до нужного места" и далее уже последовательное чтение или запись данных с достаточно высокой скоростью. Для архивов, резервных копий, архивных логов СУБД и других файлов которые нужно читать или писать только целиком и последовательно - отлично подходит. ПО управления ленточной библиотекой помогает управлять "жизненным циклом" данных на лентах.
Там где нужно минимизировать задержки на обращение к физическим лентам - перед физическими лентами ставят "виртуальную ленточную библиотеку" которая по интерфейсу - лента, но фактически внутри нее диски SSD или HDD, и она служит кэшем/буфером к физической ленте.
Те организации кто пишут/читают большие объемы лент - обычно не вставляют картриджи с лентой вручную. Там используются полностью автоматические хранилища, внутри которых полки с лентами и несколько "роботов" и приводов для работы с этими лентами.
С жесткими дисками подобную автоматику сделать конечно можно. Но, насколько я помню, жесткие диски не любят частых включений/выключений и физических перемещений. Поэтому для жестких дисков это "вырождается" в обычные дисковые полки или массивы где диски включены постоянно, тратят свой физический ресурс, потребляют электричество и греют воздух.
Конечно, условия хранения должны быть соблюдены и это справедливо для любого носителя данных.
Для бумаги/пергамента тоже нужны определенные условия хранения, просто "диапазон" другой. Бумага тоже боится огня и влажности, ее могут "погрызть", используемые компоненты для печати могут выцвести, и т.п.
У ленты гораздо более высокая плотность хранения по сравнению с бумагой и при записи используются технологии для возможности восстановления данных: избыточность, специальное кодирование и т.д.
Ну и для тех кому это действительно нужно, могут использовать несколько разных типов носителей, в расчете что что-то да сохранится.
Согласно спецификации IBM на картриджи 3592, они должны хранить данные порядка 30 лет. В самом документе, в разных местах написано "более 30 лет" и "до 30 лет". Сами картриджи разных моделей вышли уже после 2000г., поэтому эти данные приведены по тестам "ускоренного старения", так как даже самые старые картриджи из этой линейки "доживут" до указанного значения через 12 лет (2033 г.).
Ссылка на документ со спецификацией: https://www.ibm.com/downloads/cas/GLDJAXRP
Насколько я помню, финансовые организации, в соответствии с законодательством стран, где они работают, обязаны хранить исторические данные очень много (десятки) лет. При этом, по правилам, нужно хранить несколько копий, географически удаленно друг на друга. Т.е. "потерять" эти данные финансовая организация не имеет права ни в коем случае.
Уж не знаю как сейчас насчет "физической бумаги", хотя ранее видел как печатают и хранят ежедневную бумажную отчетность по определенным операциям.
Практики, когда важные данные выгружаются на ленту (несколько копий) и развозятся по разным изолированным складам/хранилищам точно существуют и по сей день. Хранить магнитную ленту все таки проще и дешевле чем, например, жесткие диски сравнимого объема.
Нет конечно. :) В качестве "первичного носителя" магнитная лента не используется очень давно (точно более 20 лет). Используются внешние СХД, сейчас все чаще "Full Flash".
При этом, магнитная лента вполне себе используется и сейчас как второй/третий уровень для хранения резервных копий и миграции "холодных" данных. Емкость современных магнитных картриджей очень неплоха, 20ТБ сырой емкости на картридж размером 25ммx110ммx125мм.
Почему-то говоря про 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 позволяет поднимать уровень системного и прикладного ПО "на ходу", без простоя. Понятное дело, что происходит это поочерёдно на каждом из "узлов" кластера и отдельные узлы какое-то время будут поочередно недоступны, но перерыва в обработке транзакций не будет. Аналогично можно и сервера целиком заменить поочередно.
Это процессор для следующего поколения серверов линейки IBM Z, текущее поколение - z15. В первую очередь это процессор общего назначения, но с новым дополнительным функционалом.
В поколении z15 в процессор "запихали" дополнительные блоки для компрессии данных, которые раньше реализовывались за счет внешних устройств (z/EDC). Это дало прирост производительности, так как данные сжимаются и разжимаются "близко" к процессору.
В новом поколении похоже проделали аналогичный "фокус" и добавили в процессор некий AI-модуль, в который можно поместить готовую обученную модель нейросети. Это дает возможность выполнить AI-операции над данными в кэше процессора, т.е. быстро и непосредственно в процессе обработки транзакции.
Скорее всего, IBM предложит готовый API для взаимодействия с этими новыми AI-блоками и встроит поддержку в свои основные продукты для IBM Z.
Архитектура - IBM Z (ранее z/Architecture), в Linux имеет обозначение s390x.
Джоб на мейнфреме (ОС z/OS) вполне может быть очень простым.
Минимальный джоб — это буквально две строки в JCL. Первая — заголовок JOB, вторая — STEP, который вызывает программу или скрипт (процедуру в терминах JCL).
Если джоб «наворотили» и он состоит из 50+ шагов со сложными условиями и зависимостями — это вполне себе повод для рефакторинга, как и любой другой код (например скрипт на Shell). Хотя, могут быть случаи когда это обосновано.
То что на конкретном «мейнфрейме» нет стейджинг-систем — это опять же проблема не «мейнфрейма», а организации процесса внедрения и эксплуатации. Сам «мейнфрейм», как и любой другой сервер, ну никак этому не мешает.
Спеца на Котлин/Джаву проще найти «сейчас», сложно сказать как оно будет через N-лет. Я не к тому что Кобол вдруг станет популярнее, я к тому что Котлин/Джава тоже могут потерять популярность и специалистов по этим языкам станет меньше.