REXX вообще весьма простой язык. Иногда даже слишком, поэтому некоторые алгоритмические конструкции на нем получаются несколько «многословные».
Применительно к z/OS — весьма удобен для автоматизации и для него есть готовые API к многим системным функциям.
Нехватка кадров для мейнфреймов — проблема частично надуманная.
Там где мейнфреймы исторически более распространены: США, отдельные страны Европы — специалистов больше. В России — постепенно становится меньше, ибо и самих мейнфреймов, особенно современных, очень мало.
Да и новых специалистов обучить — не космически сложная задача. Выпускник после ИТ-вуза, который ни разу не сталкивался с платформой вполне осваивается за полгода-год.
Насчет миграции. Не зная конкретной задачи и всех ее взаимосвязей очень сложно оценить затратность миграции на другую платформу и другой стек софта. И совсем не факт, что после смены платформы стоимость эксплуатации останется такой же или снизится.
Насколько я знаю, многие конечные пользователи (компании) вполне довольны мейнфреймами и их возможностями и не собираются менять платформу в обозримой перспективе.
Да, любой бизнес считает стоимость владения и пытается ее снизить. Миграция на другой стек/платформу — один из вариантов.
Лично видел несколько проектов, когда руководству компании «заносили» идею что на другой платформе/стеке все станет гораздо быстрее/эффективнее/дешевле. И ни один раз видел что после выстраивания аналогичного решения на другой платформе оно не давало достаточных преимуществ и принималось решение остаться на мейнфрейме.
Облако — не панацея от всех бед.
Везде есть своя стоимость внедрения и сопровождения и под конкретную задачу нужно много разных факторов учитывать.
Опять, же современный мейнфрейм вполне себе интегрируется в облако.
Ну и большой вопрос, а что именно значит «эффективнее»?
Если мейнфрейм(ы) в компании уже есть, есть коллектив который сопровождает существующее ПО, есть своя команда или партнеры, которые разрабатывают что-то новое (или модернизируют существующее ПО), то может запросто оказаться, что разработать или внедрить что-то новое, что будет работать «рядом» на той же платформе, гораздо более эффективно (по времени реализации, по времени внедрения, по стоимости сопровождения), чем пытаться это сделать на другой платформе.
Кроме того, автор статьи описывает проблемы, с которыми сталкивается далеко не каждый разработчик ПО для ОС z/OS. Работа в нулевом ключе, это по сути работа с правами «ядра» системы. Это весьма привилегированный режим, который дает доступ к памяти других процессов/приложений. Обычному прикладному ПО, которое занимается обработкой данных или обслуживанием веб-запросов это не требуется.
Соответственно и «тяжелая артиллерия» для специфичной отладки требуется тоже далеко не всегда и не всем. Для той-же Java например, инструментарий отладки/трассировки тот же самый что и для других платформ.
Не знаю, не пробовал, но крипто-карты для EC12/BC12 уже были, насколько я помню, поэтому, скорее всего будет работать, возможно с какими-то ограничениями.
Ну раз в Вашей реальности похороны уже состоялись, продолжать аргументацию в этой ветке не буду.
Я похоже живу и работаю в совсем другой реальности где и IBM System z и продукты для этой платформы вполне себе живы и востребованы.
Для тех кому интересно, оставлю здесь ссылку на документацию, в ней описано как происходит процесс изменения данных в случае DB2 в режиме Data Sharing:How an update happens.
Более подробно можно поискать ключевые слова «Lock Avoidance», «commit log sequence number (CLSN)» и блог «Robert Catterall».
Саму систему блокировок там настраивать не нужно чаще всего.
В отдельных случаях можно «покрутить» гранулярность блокировки для таблицы (одна запись, страница, партиция, таблица) и предел после которого происходит эскалация блокировки. Но это не так часто нужно делать.
Чаще, смотрится топ-10 запросов, которые или долго выполняются, или кушают неприличное количество ресурсов и далее принимаются меры или со стороны СУБД ( индексы, определенные виды статистики и т.п.) или со стороны прикладного ПО (замена SQL-запроса на более «адекватный»).
Дополнительно можно «отстреливать» запросы которые превышают лимиты по потреблению, но не для всякой бизнес-логики это применимо.
Из того что вижу в существующих системах — вполне себе работает.
Да, блокировки (не все подряд) хранятся в CF (Coupling Facility), измененные страницы таблиц — тоже в CF. Да, это может стать узким местом.
Работа по оптимизации сигнализации и снижению нагрузки на CF идет постоянно и на всех уровнях: внутренний код CF, z/OS, прикладное ПО под z/OS (DB2, MQ, CICS, и т.д.).
Ну и дальше идет уже архитектура приложений, которые все это используют, архитектура таблиц, оптимизация конкретных запросов.
Т.е. сделать этому кластеру «плохо» — можно. Но и пространство для маневра тоже есть.
А так, помимо масштабирования производительности, кластер (DB2 Data Sharing group) позволяет прозрачно для приложения «потерять» один из узлов, обновить СУБД без останова всего кластера, работать с разным «уровнем» обновлений на разных узлах и т.п.
Даже если говорить про Россию, где мейнфреймов IBM z в принципе мало, то и в этом случае DB2 for z/OS не всегда является «основой» применяемого решения.
Если не ограничиваться Россией, то количество разных use-cases гораздо больше.
Да, DB2 for z/OS вполне популярна у тех, кто эксплуатирует IBM z, но не является единственной «фишкой» платформы.
К сожалению, одну из современных «фишек», аппаратно-ускоренное сквозное шифрование данных, в России эксплуатировать в прямом виде нельзя. «Отечественное» шифрование прикрутить можно, но для этого кто-то имеющий нужные сертификации внутри России должен разработать, изготовить и сертифицировать карту расширения, выполняющую шифрование/дешифрование по стандартам России.
Возвращаясь к DB2, DB2 for z/OS и DB2 for LUW — это две разных линейки продуктов с совместимым синтаксисом SQL. И копирование фич там точно перекрестное а не одностороннее.
DB2 for z/OS вполне активно развивается. Насколько мне известно, IBM добавляет те или иные фичи по пожеланиям крупных клиентов, т.е. продукт меняется и развивается по желаниям клиентов, которые платят за лицензии и за тех.поддержку. Что, по моему, вполне логично.
Насчет применимости других СУБД — спорить не буду, ибо нет нигде «золотой пули». Разные базы данных имеют разные требования от бизнеса и для их воплощения могут подходить разные СУБД, в том числе и IBM DB2 for z/OS.
Говоря про 100% нагрузку. Да, мейнфреймовое «железо» и «софт» отлично умеют долговременно выдерживать 100% нагрузку на процессор, ввод/вывод и прочие ресурсы. При этом встроенный в z/OS планировщик с настраиваемой пользователем политикой (которая может быть весьма сложной) позволяет системе не «затыкаться» и обслуживать нагрузку согласно приоритетам в этой политике. Но, это не говорит о том, что такой ситуации нужно «радоваться».
Приложения, написанные под z/OS (ASM, COBOL, PL/I, C++, Java, Perl, Python, Go) обычно существуют не в вакууме, а взаимодействуют с другим промежуточным ПО (СУБД, обработка сообщений, управление транзакциями и т.д.). И вот для этого ПО, актуальных версий, могут потребоваться аппаратные возможности, которые в Геркулесе не реализованы.
Очень хорошо что Геркулес есть, но он применим далеко не всегда. И в первую очередь из за весьма скромной производительности.
С поддержкой старого «железа» все не так уж и грустно.
Например самая «свежая» на сегодняшний день IBM z/OS версии 2.4, вышедшая в сентябре 2019 года, официально поддерживает поколение z12 (EC12/BC12), которое было выпущено в августе 2012 года.
Я знаю как минимум один сайт в России, который периодически покупает новое «железо», потому как всю доступную мощность «старых» уже скушали за счет роста нагрузки и за счет разворачивания там же новых приложений.
Как единичная «железка» мейнфрейм (имею в виду линейку IBM System z) весьма надежен, но как любое единичное устройство — это точка отказа. Поэтому дублирование оборудования и репликация данных плюс резервное копирование — обязательны, как и для других платформ.
Ничто не мешает иметь несколько мейнфреймов в нескольких в географически распределенных дата-центрах и распределять нагрузку между ними. Тут принципиальной разницы с другими платформами нет.
Кроме того, на основе операционной системы z/OS можно построить кластер (aka SYSPLEX) с узлами active-active на расстоянии (если память не подводит) до 100 км. И иметь возможность, например, единой копии СУБД, которую можно обновлять с любого из узлов.
Ну в геркулесе к сожалению работает далеко не все.
Да, z/OS там запускается, но многих полезных расширений там просто нет, не реализовано.
Нет поддержки аппаратного сжатия (z/EDC), шифрования (CryptoExpress), полноценной работы сетевого адаптера в режиме QDIO, я уже не говорю про невозможность сделать кластерный режим aka SYSPLEX.
Производительность геркулеса очень и очень невысокая, в сравнении с реальным современным «железом» (поколение z14 или z15).
Они продали бизнес, который считали непрофильным или недостаточно доходным.
Платформа x86 (сервера, персоналки и ноутбуки) — это всего лишь одна из платформ, на которой IBM предоставляет свои продукты и сервисы.
IBM это много разных бизнесов, они экспериментируют с разными направлениями. Что-то взлетает и приносит прибыль, что-то закрывают или продают или выделяют в отдельный бизнес. Это нормальный процесс существования большой и сложной компании.
После прочтения статьи осталось ощущение, что IBM «похоронили», а компания вполне себе жива. Да и линейка «мейнфреймов», известная в настоящий момент как «IBM System z» живет, развивается и с рынка исчезать не собирается.
Я имею в виду общемировой рынок. На Российском рынке «IBM System z» не успел закрепиться и, с моей точки зрения, быстро теряет позиции.
Как пример, пригласила на работу американская компания, на выбор для переезда предлагали Германию или Нидерланды. И там и там у компании открыты «офисы». Выбор пал на Германию.
Сама работа полностью «удаленка», все общение внутри компании на английском языке.
На момент переезда был достаточный уровень английского и абсолютно отсутствовало знание немецкого.
Нам очень помогли друзья, переехавшие туда же на год раньше, так как у них был свежий опыт «хождения по граблям».
Заказывал две сим-карты ALDI Talk онлайн в декабре 2019 года, сразу после переезда в Германию.
Сим-карты пришли по почте, после чего их нужно активировать (на сайте) и пройти процесс идентификации (онлайн, через мобильное приложение).
Единственная задержка была пока сим-карты пришли по почте (2-3 дня).
Веб-сайт на немецком, но Яндекс/гугл переводчик в помощь.
Уже позже нам сказали что сим карты можно было купить в супермаркете и не ждать доставки, сам не проверял так ли это.
Time Machine на сетевой NAS (FreeNAS/TrueNAS), по Sambe, с двух Mac-ноутбуков делаю постоянно.
Бекап спасал уже несколько раз, в том числе и от внезапного выхода из строя встроенного SSD (который поменяли по гарантии).
У Synology DSM, которым пользовался некоторое время ранее, иногда бывали проблемы с TM. В самых тяжелых случаях лечились созданием новой копии Time Machine «с нуля». Предыдущая копия при этом или переименовывается или удаляется (через web или через командную строку).
С самой Time Machine тоже бывают «приколы», но со стороны операционной системы. Один раз по логам долго искал из за чего внезапно перестал работать бекап. Оказалось — из за файла с очень «кривым» названием. На файловой системы файл существовал и открывался, а вот TimeMachine не могла его скопировать и аварийно прерывала бекап.
Иногда TimeMachine прекращает работать, если на файловой системе остается мало места для создания локального Snapshot.
Обычно по логам можно найти причины проблем. Команда для вывода в консоль логов, параллельно работе TM: log stream --style syslog --predicate 'senderImagePath contains[cd] "TimeMachine"' --info
А я в ВУЗе успел застать только «демонтаж» бывшей там ЕС ЭВМ.
Но, познакомился там же с VM, работавшим на P/390, это отдельная плата которая вставлялась в комп под управлением OS/2 и являлось маленьким сервером платформы S/390.
А потом был ОАО РЖД и «большие» серверы S/390 и, позже, System z.
ISPF и REXX и сейчас вполне живы и используются как минимум в z/OS.
Вообще ISPF хороший скриптовый инструмент позволяющий достаточно просто реализовать терминальный UI.
Применительно к z/OS — весьма удобен для автоматизации и для него есть готовые API к многим системным функциям.
Там где мейнфреймы исторически более распространены: США, отдельные страны Европы — специалистов больше. В России — постепенно становится меньше, ибо и самих мейнфреймов, особенно современных, очень мало.
Да и новых специалистов обучить — не космически сложная задача. Выпускник после ИТ-вуза, который ни разу не сталкивался с платформой вполне осваивается за полгода-год.
Насчет миграции. Не зная конкретной задачи и всех ее взаимосвязей очень сложно оценить затратность миграции на другую платформу и другой стек софта. И совсем не факт, что после смены платформы стоимость эксплуатации останется такой же или снизится.
Насколько я знаю, многие конечные пользователи (компании) вполне довольны мейнфреймами и их возможностями и не собираются менять платформу в обозримой перспективе.
Да, любой бизнес считает стоимость владения и пытается ее снизить. Миграция на другой стек/платформу — один из вариантов.
Лично видел несколько проектов, когда руководству компании «заносили» идею что на другой платформе/стеке все станет гораздо быстрее/эффективнее/дешевле. И ни один раз видел что после выстраивания аналогичного решения на другой платформе оно не давало достаточных преимуществ и принималось решение остаться на мейнфрейме.
Везде есть своя стоимость внедрения и сопровождения и под конкретную задачу нужно много разных факторов учитывать.
Опять, же современный мейнфрейм вполне себе интегрируется в облако.
Ну и большой вопрос, а что именно значит «эффективнее»?
Если мейнфрейм(ы) в компании уже есть, есть коллектив который сопровождает существующее ПО, есть своя команда или партнеры, которые разрабатывают что-то новое (или модернизируют существующее ПО), то может запросто оказаться, что разработать или внедрить что-то новое, что будет работать «рядом» на той же платформе, гораздо более эффективно (по времени реализации, по времени внедрения, по стоимости сопровождения), чем пытаться это сделать на другой платформе.
Кроме того, автор статьи описывает проблемы, с которыми сталкивается далеко не каждый разработчик ПО для ОС z/OS. Работа в нулевом ключе, это по сути работа с правами «ядра» системы. Это весьма привилегированный режим, который дает доступ к памяти других процессов/приложений. Обычному прикладному ПО, которое занимается обработкой данных или обслуживанием веб-запросов это не требуется.
Соответственно и «тяжелая артиллерия» для специфичной отладки требуется тоже далеко не всегда и не всем. Для той-же Java например, инструментарий отладки/трассировки тот же самый что и для других платформ.
Я похоже живу и работаю в совсем другой реальности где и IBM System z и продукты для этой платформы вполне себе живы и востребованы.
Для тех кому интересно, оставлю здесь ссылку на документацию, в ней описано как происходит процесс изменения данных в случае DB2 в режиме Data Sharing:How an update happens.
Более подробно можно поискать ключевые слова «Lock Avoidance», «commit log sequence number (CLSN)» и блог «Robert Catterall».
В отдельных случаях можно «покрутить» гранулярность блокировки для таблицы (одна запись, страница, партиция, таблица) и предел после которого происходит эскалация блокировки. Но это не так часто нужно делать.
Чаще, смотрится топ-10 запросов, которые или долго выполняются, или кушают неприличное количество ресурсов и далее принимаются меры или со стороны СУБД ( индексы, определенные виды статистики и т.п.) или со стороны прикладного ПО (замена SQL-запроса на более «адекватный»).
Дополнительно можно «отстреливать» запросы которые превышают лимиты по потреблению, но не для всякой бизнес-логики это применимо.
Да, блокировки (не все подряд) хранятся в CF (Coupling Facility), измененные страницы таблиц — тоже в CF. Да, это может стать узким местом.
Работа по оптимизации сигнализации и снижению нагрузки на CF идет постоянно и на всех уровнях: внутренний код CF, z/OS, прикладное ПО под z/OS (DB2, MQ, CICS, и т.д.).
Ну и дальше идет уже архитектура приложений, которые все это используют, архитектура таблиц, оптимизация конкретных запросов.
Т.е. сделать этому кластеру «плохо» — можно. Но и пространство для маневра тоже есть.
А так, помимо масштабирования производительности, кластер (DB2 Data Sharing group) позволяет прозрачно для приложения «потерять» один из узлов, обновить СУБД без останова всего кластера, работать с разным «уровнем» обновлений на разных узлах и т.п.
Если не ограничиваться Россией, то количество разных use-cases гораздо больше.
Да, DB2 for z/OS вполне популярна у тех, кто эксплуатирует IBM z, но не является единственной «фишкой» платформы.
К сожалению, одну из современных «фишек», аппаратно-ускоренное сквозное шифрование данных, в России эксплуатировать в прямом виде нельзя. «Отечественное» шифрование прикрутить можно, но для этого кто-то имеющий нужные сертификации внутри России должен разработать, изготовить и сертифицировать карту расширения, выполняющую шифрование/дешифрование по стандартам России.
Возвращаясь к DB2, DB2 for z/OS и DB2 for LUW — это две разных линейки продуктов с совместимым синтаксисом SQL. И копирование фич там точно перекрестное а не одностороннее.
DB2 for z/OS вполне активно развивается. Насколько мне известно, IBM добавляет те или иные фичи по пожеланиям крупных клиентов, т.е. продукт меняется и развивается по желаниям клиентов, которые платят за лицензии и за тех.поддержку. Что, по моему, вполне логично.
Насчет применимости других СУБД — спорить не буду, ибо нет нигде «золотой пули». Разные базы данных имеют разные требования от бизнеса и для их воплощения могут подходить разные СУБД, в том числе и IBM DB2 for z/OS.
Говоря про 100% нагрузку. Да, мейнфреймовое «железо» и «софт» отлично умеют долговременно выдерживать 100% нагрузку на процессор, ввод/вывод и прочие ресурсы. При этом встроенный в z/OS планировщик с настраиваемой пользователем политикой (которая может быть весьма сложной) позволяет системе не «затыкаться» и обслуживать нагрузку согласно приоритетам в этой политике. Но, это не говорит о том, что такой ситуации нужно «радоваться».
Очень хорошо что Геркулес есть, но он применим далеко не всегда. И в первую очередь из за весьма скромной производительности.
С поддержкой старого «железа» все не так уж и грустно.
Например самая «свежая» на сегодняшний день IBM z/OS версии 2.4, вышедшая в сентябре 2019 года, официально поддерживает поколение z12 (EC12/BC12), которое было выпущено в августе 2012 года.
Я знаю как минимум один сайт в России, который периодически покупает новое «железо», потому как всю доступную мощность «старых» уже скушали за счет роста нагрузки и за счет разворачивания там же новых приложений.
Ничто не мешает иметь несколько мейнфреймов в нескольких в географически распределенных дата-центрах и распределять нагрузку между ними. Тут принципиальной разницы с другими платформами нет.
Кроме того, на основе операционной системы z/OS можно построить кластер (aka SYSPLEX) с узлами active-active на расстоянии (если память не подводит) до 100 км. И иметь возможность, например, единой копии СУБД, которую можно обновлять с любого из узлов.
Да, z/OS там запускается, но многих полезных расширений там просто нет, не реализовано.
Нет поддержки аппаратного сжатия (z/EDC), шифрования (CryptoExpress), полноценной работы сетевого адаптера в режиме QDIO, я уже не говорю про невозможность сделать кластерный режим aka SYSPLEX.
Производительность геркулеса очень и очень невысокая, в сравнении с реальным современным «железом» (поколение z14 или z15).
Платформа x86 (сервера, персоналки и ноутбуки) — это всего лишь одна из платформ, на которой IBM предоставляет свои продукты и сервисы.
IBM это много разных бизнесов, они экспериментируют с разными направлениями. Что-то взлетает и приносит прибыль, что-то закрывают или продают или выделяют в отдельный бизнес. Это нормальный процесс существования большой и сложной компании.
Я имею в виду общемировой рынок. На Российском рынке «IBM System z» не успел закрепиться и, с моей точки зрения, быстро теряет позиции.
Сама работа полностью «удаленка», все общение внутри компании на английском языке.
На момент переезда был достаточный уровень английского и абсолютно отсутствовало знание немецкого.
Нам очень помогли друзья, переехавшие туда же на год раньше, так как у них был свежий опыт «хождения по граблям».
Сим-карты пришли по почте, после чего их нужно активировать (на сайте) и пройти процесс идентификации (онлайн, через мобильное приложение).
Единственная задержка была пока сим-карты пришли по почте (2-3 дня).
Веб-сайт на немецком, но Яндекс/гугл переводчик в помощь.
Уже позже нам сказали что сим карты можно было купить в супермаркете и не ждать доставки, сам не проверял так ли это.
Бекап спасал уже несколько раз, в том числе и от внезапного выхода из строя встроенного SSD (который поменяли по гарантии).
У Synology DSM, которым пользовался некоторое время ранее, иногда бывали проблемы с TM. В самых тяжелых случаях лечились созданием новой копии Time Machine «с нуля». Предыдущая копия при этом или переименовывается или удаляется (через web или через командную строку).
С самой Time Machine тоже бывают «приколы», но со стороны операционной системы. Один раз по логам долго искал из за чего внезапно перестал работать бекап. Оказалось — из за файла с очень «кривым» названием. На файловой системы файл существовал и открывался, а вот TimeMachine не могла его скопировать и аварийно прерывала бекап.
Иногда TimeMachine прекращает работать, если на файловой системе остается мало места для создания локального Snapshot.
Обычно по логам можно найти причины проблем. Команда для вывода в консоль логов, параллельно работе TM:
log stream --style syslog --predicate 'senderImagePath contains[cd] "TimeMachine"' --infoНо, познакомился там же с VM, работавшим на P/390, это отдельная плата которая вставлялась в комп под управлением OS/2 и являлось маленьким сервером платформы S/390.
А потом был ОАО РЖД и «большие» серверы S/390 и, позже, System z.
Вообще ISPF хороший скриптовый инструмент позволяющий достаточно просто реализовать терминальный UI.