Я не по теме статьи, а по вымиранию и по геркулесу.
Да, мы до сих пор разрабатываем под геркулесом.
Уже дело к опытному внедрению, а мы всё на нём.
И уяснили, что это не то, что бы мы хотели, поэтому с нетерпением ждём дисковой стойки для запуска полноценной среды разработки и тестирования на родном железе.
Ключевое слово тестирование. Ибо бывает надо проверить пару вариантов, дабы выбрать, и на геркулесе это делать бессмыслено, перенос на железо в наших условиях операция не самая простая.
Про вымрут.
Пару лет назад пришла ко мне девочка, студент бауманки на тот момент, биомедицинские технгологии. Не программист ни разу.
Сказала, что хочет программировать и с чего бы начать.
ну мы с парнями насоветовали полную панамку про Яву да про С.
Она через какое-то время опять пришла и сказала, что им препождаватель рассказывал, что бывает такое ассемблер.
Тут уже я заинтересовался, начал пытать подробнее.
Забрали мы её к себе, и пользуясь присутствием у нас ныне покойного Владимира Ивановича Шурпенкова, который так мало у нас к сожалению, поработал, (легендарная личность, ещё во времена СССР был инструктором по HLASM) замутили курсы для всей команды.
Вы не поверите - ныне она наш ведущий системный программист. И cross memory services ей подвластны.
Конечно, постигает ещё, но уже полностью самостоятельно.
Много полезного сделала и ещё сделает. Если надо что-то экспериментальное быстро на COBOL + C + HLASM соорудить - это к ней.
Главное - задачи интересные дать и руки не выкручивать.
А молодёж достойная есть. Есть у нас и второй "студент".
Не всё так плохо.

Если я правильно всё понял, то никаких проблем вроде здесь нет.

ZD&T это ведь то, что раньше называлось zPDT? Это решение только для разработки и тестирования. Более того, оно требует ключа, роэтому кто угодно эту штуку не запустит. Не ну понятно, что можно попробовать там считать по-настоящему, но ключ всё равно нужен. Раньше это работало только с железным ключом, а теперь ещё можно запуститься и с сервером лицензий.

Так что нельзя говорить, что это пойдёт в массы и будет работать вместо настоящего фрейма. Это сможет запустить только тот, у кого до этого был ключ ZD&T.

С другой стороны, сворачивая ZD&T в докер-контейнер, мы делаем установку мобильной. И это очень удобно. После этого нам не придётся каждый раз разворачивать это чудо с нуля. Всё что нужно - установить докер в свою любимую ОС и запустить там свой контейнер.

Не вижу проблем, но вижу упрощение своей жизни. Сам так делаю.

не, ну если кому-то что-то упрощает, то это, безусловно, хорошо.
но!
1) вместо эмулятора надо ставить докер, чтобы туда ставить содержимое контейнера, в который завернут эмулятор. и так, и эдак надо ставить приложение, не эмулятор, так докер.
2) это ж не попсовое приложение а-ля движок для сайта, который ты носишься по всему миру и ставишь в сотне экземпляров. это, считай, эмулятор архитектуры для запуска операционной системы. у того, кто купил лицензию, будут единичные (а может и вообще одна штука) установки этого продукта. при таком раскладе какая разница, докер это или нет?.. а вот то, что появилась дополнительная прослойка, никакого оптимизма не внушает.
3) и главное, для кого это? для приличных разработчиков, типа Рокета?)) так они нормальную машину купят. и облачный доступ к чужим мейфреймам стоит дешево. кто будет целевой группой для этого продукта?..

Всё-таки это решение для разработки. Докер тут совсем не мешает.

Я и был той самой целевой группой, которая тестировала решения и писала софт. При этом у нас в ИБМ были и настоящие фреймы.

У разработчиков "типа Рокета" часто есть и то и другое.

Единичные - да, но при этом ZD&T отдаётся то одному юзеру, то другому. Гриша Власов не даст соврать, как мы это из рук в руки передавали.

ZD&T ставится не из репозитория. Для этого есть специальный скрипт, который норовит упасть, если что-то не так (зависимостей нет, например). Поэтому лучше один раз создать контейнер с установленным ZD&T, а потом просто запускать этот контейнер там, где понадобится, не разбираясь как установить очередной странный софт.

Поставить докер очень просто. Запустить контейнер - одна команда. Когда вам нужно запустить на очередном сервере комплект из ZD&T, SonarQube, Jenkins, JFrog Artifactory, то проще взять готовые контейнеры, чем строить всё с нуля.

Когда я был в лабе ИБМ, то нам приходилось менять серверы, создавать новую среду для разработки и т.п. Контейнеры нас сильно спасали. До ZD&T дело не дошло, но была мысль и его свернуть в докер, чтобы не мучиться с размножением и перемещением. Тем более, что нам бы понадобилось несколько ZD&T. Запускать бы их пришлось и на своих ноутах, а громоздить весь стек ZD&T я бы у себя не захотел.

Кстати, об упомянутых приличных разработчиках Залез в нашу вики и нашёл документ об установке zPDT (how-to). Предлагается взять готовый образ Ubuntu с настроенным zPDT и запустить его в VMWare под мак или виндоус.

Имхо докер, всяко лучше будет.

ну что же, если это кому-то поможет - значит, решение было выбрано правильное. время покажет, чо как.

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

Кстати, сейчас вот докер внутри z/OS появился. zCX называется. В реальности это - Ubuntu, работающая в адресном пространстве z/OS, внутри которой работает докер, в котором работают docker images ("как тебе такое Илон Маск"). Все docker images, работающие на zLinux, будут работать и здесь. Т.е., например, теперь в z/OS можно запустить Zabbix и ограничить его через WLM. Наши люди этим заинтересовались. Если дальше будут развивать это направление, то может получится довольно интересно.

это мы видели, осенью. Ubunta в адресном пространстве zOS. я, как VMщик, от такого начинаю чесаться во всех неприличных местах. вместо работы под PR/SM или под нормальным VM, нагородили слоеный пирог, куда более расходный по ресурсам, чем VM под VM под VM и так далее. и что при этом в качестве результата? чем докер под убунту в адресном пространстве zOS лучше или быстрее докера под убунту внутри полноценной виртуальной машины, где работает SIE и другие vm-овские погремушки?...

Из удобств - быстрый обмен данными с локальными СУБД, workload management (WLM), защита средствами RACF. Опять же сисплекс и GDPS. За скорость не скажу, но часто она и не нужна.

Ну и ещё есть пользователи, которые всегда работали с z/OS, но боятся z/VM. Теперь они могут запускать у себя в z/OS Линукс-задачи. И для этого не требуется устанавливать z/VM и/или zLinux.

Моё имхо - IBM могло было бы довести до ума USS и обойтись без zCX. Но меня никто не спросил. Но и zCX совсем даже неплохо.

Система развивается и это хорошо. Новые возможности можно использовать или не не использовать. Хуже, когда этих возможностей нет.

увы, я постоянно вижу подобное. Такое ощущение, что все специалисты либо вымерли по естественным причинам, либо разбежались в другие организации, а остались какие-то вчерашние школьники, которые пытаются что-то делать с тем, что совершенно не понимают. Это примерно то же самое, как если на современном автомобиле напичканном электроникой приехать на СТО, а там сотрудники с каменными топорами и палками-копалками...

все намного страшнее, я думаю.
у меня есть ощущение, что, пользуясь вашей аналогией, разработчики и архитекторы этого решения прицепили к велосипеду (или к мопеду) тяжелые колеса для движения по рельсам и всех убеждают, что это вот почти уже поезд и можно учиться на нем ездить.
с одной стороны вроде как Докеровское решение с zOS - это хорошо, прям как Геркулес от IBM, можно на приличном Intel запустить и писать задачи под zOS. но думается, что это больше убьет платформу, чем поддержит, потому что если есть свои администраторы и сильная инфраструктура с докерами и прочим, то с какой радости переться в zOS, если можно на хлеб заработать без всего этого???