Если спросить администратора любой системы на х86 сервере в чем их система и как измеряет выполненную работу, то в ответ услышишь «А зачем это надо? Выполняется и хорошо. Чего еще?». Может я ошибаюсь, поправьте в комментариях.

Здесь я хочу рассказать о измерении выполненой работы в z/OS, зачем это делается и какие из этого могут быть финансовые последствия (нет не штрафы и пени, а скорее наоборот).

Вот фрагмент протокола выполнения пакетного задания:

17.25.40 JOB18531  IEF403I SIVBRGE0 - STARTED
17.25.41 JOB18531  -                                      -----TIMINGS (MINS.)------                          -----PAGING COUNTS----
17.25.41 JOB18531  -STEPNAME PROCSTEP    RC   EXCP   CONN       TCB       SRB  CLOCK          SERV  WORKLOAD  PAGE  SWAP   VIO SWAPS
17.25.41 JOB18531  -STEP1    D1          00      5      3       .00       .00     .0            12  BATCH        0     0     0     0
17.26.18 JOB18531  -DBRGET   GO          00    684    192       .09       .00     .6         31555  BATCH        0     0     0     0
17.26.18 JOB18531  -STEP2    D1          00      5      3       .00       .00     .0            11  BATCH        0     0     0     0
17.32.40 JOB18531  -DBRGET   GO          00   2221    591       .43       .04    6.3        149929  BATCH        0     0     0     0
17.32.40 JOB18531  IEF404I SIVBRGE0 - ENDED

Если присмотреться то можно почти все понять без особых объяснений. И все таки. В задании SIVBRGE0 выполнялись два шага (STEP1, and STEP2). В каждом шаге выполнялась процедура с двумя исполняемыми шагами D1, и GO. Т.е. проще говоря исполнялись два шага процедуры с двумя исполняемыми шагами.

И мы видим столбцы RC - код возврата, 0 это очень хорошо, EXCP - количество выполненных операций I/O, CONN - какие то коннекции, наверное к базе данных, не важно пока, TCB - время выполнения в состоянии задача, SRB - в состоянии Service Request Block , CLOCK - wall clock.

Сдвинем картинку вправо и увидим столбец SERV, и WORKLOAD. Paging Counts нас сегодня не интересует.

SERV это количество сервисных единиц (Service Units, SU) затраченных на выполнение шага задания. WORKLOAD название первого уровня иерархии (Workload) в WLM полиси на котором "живут" другие элементы полиси как то Service Classes. В данном случае workload это пакетное задание (BATCH).

Вернемся к SU, Что это? Это интегрированный показатель используемых ресурсов МФ, он включает и время CPU и ввод-вывод и память. Естественно просто складывать время и ... что там в вводе-выводе, не понятно, память в мега-, гига- байтах измеряется не возможно. Но ИБМ (z/OS) умеет измерять и скадывать нескладываемое используя коэффициенты разные для каждого ресурса. Измерение в SUs используется давно, на основании опыта создания многих поколений МФ, знаний о МФ, измерений, исследований.

Равно как ИБМ (z/OS) умеет измерять количество SU использованых, в данном случае пакетным заданием, а в общем случае любой активности в z/OS, ИБМ также умеет измерять производительность конкретной конфигурации МФ. Но уже не в SU, а в миллионах SU или MSU. МФ на котором выполнялось задание, протокол которого приведен выше, это z14, ZR1, capacity model A01 и его производительность 11 MSU.

Это как электростанции и потребители электричества.

Ну и что с этим делать спросите вы. Первое это то что цены на лицензии ПО (z/OS, DB2, CICS, ! Cobol и другое ПО называемое Сlassic) зависят напрямую от MSUs вашего МФ, точнее его capacity model, их сотни и их можно менять как вверх так и вниз ничего не изменяя в самом железе. Чем это вам не облако? Для этого правда надо быть на саппорте в ИБМ. Ниже я пиведу больше информацию про цены и настройке производительности МФ под нужды пользователя, которые к сожалению пока недоступно в России.

Другое применение (доступное в Росси при наличии МФ и z/OS) способности измерять SU мы находим в WLM (я в предыдущей статье привел некоторую информацию о WLM здесь приведу дополнение для лучшего понимания WLM).

Каждая активность будь то пакетное задание, адресные пространств DB2 (их несколько на каждую инстранс DB2), DB2 threads запущенные из TSO или CICS, DB2 enclaves (enclave это транзакция, которая может охватывать несколько диспетчируемых единиц в одном или нескольких адресных пространствах, WLM различает и управляет enclave как единым целым), запущенные удаленным клиентом, адресные прстранства CICS, WebSphere enclaves процессы в Unix System Services, и тд. и т.п. всё отслеживается системой и доступно WLM. Что еще важно это то что квалификационные признаки активностей, например, юзер аккаунт, его сетевые координаты тоже доступны и используются WLM. Посмотрим для чего.

WLM на основе квалификационных параметров и квалификационных правил назначает активностям классы сервисов (Service Class). Связь их один-к-одному. Сервис класс состоит из периодов. Их может быть от одного до нескольких. Каждый период кроме последнего имеет продолжительность. Продолжительность задается... в SUs. Это работает следущим образом. Стартует активность, WLM назначает ей параметры выполнения первого периода в сервис классе. Идет выполнение активности с параметрами первого периода сервис класса. И вот активность использовала назначенные периоду SUs. WLM переключает активность на параметры следущего периода, с более низкими важностью и другими параметрами периода, но может быть и наоборот, более высокими. Правил на этот счет нет. Последний период не имеет продолжительности и активность выполняется до своего завершения в последнем периде. Активность может завершиться на любом периоде. Т.е. в течении жизни активности она может иметь разные параметры выполнения (выражаемые в итоге в приоритете диспетчирования) в разное время жизни.

Отчеты WLM содержат гистограммы нахождений активностей на разных периодах сервис классов и используются для настройки продолжительностей периодов.

Как видим измерение использованых работами/активностями ресурсов применяется на Мф в самом широчайшем смысле от просто учета до управления процессами работ и активностей.

z14 десять кор процессор чип
z14 десять кор процессор чип

Дополнения об управлении производительностью МФ.

Ручное управление или Capacity Backup Upgrade (CBU).

При покупке МФ оговаривается конфигурация, которую хочет использовать покупатель. Это включает количество и типы CPU (их несколько), уровень производительности тех CPU на каких будет выполняться z/OS. Последнее выражется в т.н. capacity model в формате LNN, где L - буква от A до Z, NN - число, количество CPU для z/OS. Уровней capacity model сотни, Собственно 26 помножить на количество CPU. А также размер памяти для LPARs доступный для пользователя (у нас на МФ 128 Gb, но использовать мы можем до 64 GB. Мы купили тольуо 64. Но могли бы увеличить до 128 по необходимости. На самом сейчас используется только 2 GB. Да 2. Остальные раньше использовались для DR другого МФ).

Именно эта оговоренная при покупке конфигурация и будет встроена в предоставленном МФ. На самом деле в МФ будет такая конфигурация (их немного) какую делают на заводе.

В процессе установки МФ на нем конфигурируется служба т.н. Call-home. Т.е. связь через инет в ИБМ Control and Support Center (Outbound Connectivity). Это нужно для того чтобы ИБМ получала все сигналы от МФ по поводу поломок и для другого ниже описанного. Call-home не обязателен, МФ работает и без этого. Но никто вам не позвонит и не скажется что у вас не так с МФ и вы не сможете делать описаное ниже и еще многое другое (см. CoD ниже).

В процессе использования пользователь может захотеть добавить "дровишек" к конфигурации. Это оформляется как Purchase Order, обсчитывается, выставляется счет, оплачивается. В итоге ИБМ создает некий Record и сообщает пользователю Order number. Системный программист пользователя заходит на Hardware Management Console (HMC), выбирает нужный МФ, переходит в "Single Object Operation" для этого МФ, выбирает "Perform model conversion" и далее в "Receive, and Active" for "Permanent Upgrade". HMC запрашивает Order number, вводим, Ок, ждем несколько минут, Done, можем приступать к использованию новой конфигурации. Большей, или ......меньшей. Мы переходили однажды и на меньшую, это экономило деньги.

Есть еще Temporary Upgrade это когда можно на до 10 дней увеличивать мощность МФ. Рекорды для таких апгрейдов закупаются заранее нужным количеством и могут использоваться например для ежегодных DR test или чего угодно еще (годовых отчетов). Эти рекорды могут активироваться системщиком когда угодно. Использованные рекорды из списка удаляются и так пока все не использованы. Их можно докупать по мере надобности. У нас такие рекорды использывались для DR test и изменяли capacity model с А01 (один CPU на наименьшей скорости) до z03 (три CPU на максимальной скорости).

Capacity on demand (перевод из Redbook)

Расширенные возможности предоставления ресурсов по требованию (CoD) предоставляют клиентам большую гибкость в управлении и администрировании временных потребностей в ресурсах. z14 ZR1 поддерживает тот же архитектурный подход к предложениям CoD, что и z13 (временным или постоянным). В z14 ZR1 может быть доступно одно или несколько гибких определений конфигурации для решения различных временных задач, и несколько конфигураций ресурсов могут быть активны одновременно. Можно создать до 200 промежуточных записей (конфигураций - zVlad909) для обработки различных сценариев. До восьми таких записей можно установить на сервере в любое время. После установки записей их можно активировать вручную, или z/OS Capacity Provisioning Manager может автоматически запустить активацию при достижении пороговых значений политики Workload Manager (WLM). Доступны токены, которые можно приобрести для On/Off CoD до или после выполнения рабочей нагрузки (предоплата или постоплата).

Дополнение к CoD от себя (без перевода). Довольно замысловатое объяснение я нашел. С рекламным уклоном. Простыми словами это работает следущим образом. Идет работа, все Ок. Ок это значит удается удержимать Performance Indexes (PI) в желаемом диапозоне (PI это отношение цели управления к достигнутому результату управления. Идеально должен быть равен 1. Меньше единицы, скажем так, "перелет" (over achieved), Больше единицы "недолет" (under achieved)). И вдруг WLM обнаруживает что ему не хватает производительности МФ чтобы удержать PI. Используя "записи" из предыдущего объяснения WLM повышает производительность МФ. Может повышать несколько раз, но не больше раза в 4 часа (так было раньше как сейчас не знаю). Если оказывается что нагрузка упала то делается понижение производительности используя другие "записи".

Расчет в долларах ведется на основании отчета по использованию предоставляемого в ИБМ ежемесячно отчета, который создается пользователем на основе данных собранных системой и обработанных программой ИБМ, на основании этого отчета ИБМ выставляет инвойс (счет) на оплату. Как можно заметить это своего рода Pay as You Go, по фактическому использованию ресурсов пусть даже вашего МФ, но за программное обеспечение.

Вот фрагмент нашего отчета в ИБМ за май. Это не для CoD, но он показывает что наш МФ имеет 125 MSU, в пике было до 15 MSU, всего за месяц потребили 204 MSU и показано какое ПО мы использовали. Здесь нет CICS котороый у нас есть, но его ни разу не запускали в мае.

Machine Rated Capacity (MSUs)

125

Machine Peak Utilization

15

Machine MSU Consumed

204

MLC Product Name

MLC Product ID

Tool MSUs

z/OS V1

5694-A01

15

DB2 V9 for z/OS

5635-DB2

15

IBM Enterprise Cobol for z/OS V4

5655-S71

15

IBM z14 функциональность доступная на всех z14 моделях
IBM z14 функциональность доступная на всех z14 моделях

Комментарии (25)


  1. sotland
    11.07.2025 22:59

    А что кроме кобола и db2 у вас используется? Вероятно железка классная.


    1. zVlad909 Автор
      11.07.2025 22:59

      CICS само собой. В нем выполняются Кобол программы, которые через CICS ходят в DB2. Классический набор. Это использовалось для приложения которое ушло (вендор увел) на Оракл. Есть еще приложение на IDMS и CICS. Скоро и ее уведут. Была WebSphere.

      Железка класная я про нее отдельную статью хочу написать, но это будет сложно.

      Де факто это Дата Центр. К нему надо добавить диски и выход в интернет. Все файрволы, DNS, IPsec, IDS, Certificate Authority, Encryption, LDAP, все есть, даже Kubernetes есть. Web, Java, Unix, C.


  1. zVlad909 Автор
    11.07.2025 22:59

    Хорошая картинка для следущей статьи, но помещу ее в комментариях здесь чтобы не вызывать недоумения от моих примеров с всего лишь одним CPU в МФ.

    z14 ZR1 aннонсирована ИБМ April 10, 2018. Семь плюс лет назад. В этом году тоже в апреле аннонсирована z17.

    Страница приводит производительность не в MSUs как в статье, а более понятных для широких кругов MIPS (Millions of Instructions Per Second). Коэффициент первода 8, A01 - 11 MSU, or 88 MIRS.

    Z01 - 8000 MIPS, значит полная производительность ZR1 будет 34 * 1570 = 53380 MIPS и 8 ТВ RAM. Рассказ про I/O впереди. PUs сконфигурированные не как CP всегда выполняются на полную мощность.

    Как видно из таблички максимальное количество PUs доступных пользователю 34. Из этого набора можно под z/OS сконфигурировать максимум 6 (CP), плюс к этому 28 IFL (Integrated Faculty for Linux) 6 + 28 = 34. На IFL можно запускать Linux в LPARS, и/или zVM с Linux на виртуальных машинах.

    Можно часть PUs можно отдать в помощь z/OS в виде zIIPs. zIIPs помогут DB2 for z/OS и WebSphere(Java) for z/OS.

    Если нужен Parallel Sysplex (хотя на 6 CP много z/OS запускать смысла нет особого) то к вашим услугам ICF(Integrated Coupling Facility). Можно, например, из двух LPAR по 3 закрепленных CP сделать Sysplex из двух members. А можно сделать Sysplex из 4 z/OS LPARs с 6 СP в каждом в shared mode. И с парочкой ICF.

    Это ли не Дата Центр? Price $50,575.00 https://trianglevipstore.com/ibm-z14-zr1-3907-mainframe/


    1. useribs
      11.07.2025 22:59

      Круто. Кому интересно как устроены подобные штуки внутри => https://www.youtube.com/watch?v=AptJJsO5qCg . Там еще много всякого проприетарного железа разбирают


      1. zVlad909 Автор
        11.07.2025 22:59

        В ролике показан МФ z890. Это 2004 год. Музейный экспонат. Лаптопов уже давно нет, но Support Element две штуки есть. Они на U mounted mother boards и выдвижная клавиатура с дисплеем. Это для электронщиков. Системщики работают удаленно через HMC.


    1. Jijiki
      11.07.2025 22:59

      а сколько там процессоров, какая частота, сколько всего ядер ? флопсы еще посчитать можно ) FLOPS

      интересно сколько там террафлопсов ) или там больше/меньше


    1. krids
      11.07.2025 22:59

      Как видно из таблички максимальное количество PUs доступных пользователю 34. Из этого набора можно под z/OS сконфигурировать максимум 6 (CP) плюс к этому 28 IFL (Integrated Faculty for Linux) 6 + 28 = 34. На IFL можно запускать Linux в LPARS, и/или zVM с Linux на виртуальных машинах.

      А если вдруг захочется погонять на этих IFLях какую-нибудь корпоративщину а-ля SAP, то не забыть заплатить 12K$/год на одно IFL-ядро за, например, SLES-подписку (т.е. 336K$/год за всю машину). А еще понадобятся диски. И не с какой-нибудь entry/midrange level СХД, а с hi-end а-ля IBM DS8K с соответствующим ценником за террабайт.

      Если нужен Parallel Sysplex (хотя на 6 CP много z/OS запускать смысла нет особого) то к вашим услугам ICF(Integrated Coupling Facility). Можно, например, из двух LPAR по 3 закрепленных CP сделать Sysplex из двух members. А можно сделать Sysplex из 4 z/OS LPARs с 6 СP в каждом в shared mode. И с парочкой ICF.

      Это ли не Дата Центр? 

      C таким capacity разве что образца 30-летней давности

      Price $50,575.00 https://trianglevipstore.com/ibm-z14-zr1-3907-mainframe/

      Бизнес, который точно знает зачем ему IBM System Z БУ-шные z-ки на барахолке не покупает, а все-таки берет у IBM за "более другой" прайс. За 50k сегодня можно взять 2-сокетный x86-сервер на 256 ядер, а за 5K$/год SLES-подписку на него на неограниченно кол-во виртуалок. За стоимость годовой SLES-подписки на указанную выше z14 можно будет взять еще пяток таких "писюков" и собрать в кластер. По capacity и price/performance это будет гораздо больше похоже на современный "дата-центр" (хоть и маленький)

      IBM Sytem Z - технически великолепная платформа, но для новых проектов (а не поддержки легаси) в 99% кейсов экономически абсолютно бессмысленная (1% на всякие визы/мастеркарды, сити/жпморганы и т.д где по требованиям надежности core-систем нужны все эти z/OS-сисплексы и, соответственно, в части бюджета "мы за ценой не постоим")


      1. zVlad909 Автор
        11.07.2025 22:59

        А если вдруг захочется погонять на этих IFLях какую-нибудь корпоративщину а-ля SAP, то не забыть заплатить 12K$/год на одно IFL-ядро за, например, SLES-подписку (т.е. 336K$/год за всю машину)

        Нет не за всю, а только за то что будет в LPAR с Linux для SAP. Вы и на сервере х86 за SLES будете платить по $12 000/год за ядро. Вот только ядер у Вас будет раз в десять больше.

        А еще понадобятся диски. И не с какой-нибудь entry/midrange level СХД, а с hi-end а-ля IBM DS8K с соответствующим ценником за террабайт.

        Диски понабятся и желательно не entry/midrange level (хотя и такие можно подключать к МФ чего я лично не рекомендую), но и не обязательно IBM DS8K. У нас, например, Dell VMAX 40K, которые нынче сыплются после 3 лет отказа от саппорта от Dell.

        C таким capacity разве что образца 30-летней давности

        Так это всего лишь одна, 19", стойка, каковых в современных ДЦ десятки и сотни стоят. Плюс это 2018 год. И это младшая модель семейства z14 M05, старшая, аннонсированная годом раньше, не 34, а 170 PUs доступных пользователю предлагает.

        С каким таким capacity? Вы посмотрели только на числа CPU. А что Вы знаете про ввод-вывод этой стойки 19"?

        В целом совершенно безответственное заявление. Что Вы можете сказать про 30 летнюю давность? Приведите пример.

        За 50k сегодня можно взять 2-сокетный x86-сервер на 256 ядер, а за 5K$/год SLES-подписку на него на неограниченно кол-во виртуалок. 

        Вы где такие прайсы берете? 336K$/год за 30 ядер и 5K$/год за 256. Поделитесь, пожалуйста.

        Я несколько лет работал с SuSe на МФ. Бесплатно.


        1. krids
          11.07.2025 22:59

          Нет не за всю, а только за то что будет в LPAR с Linux для SAP.

          Естественно. Речь о том, сколько придется заплатить, если нужно лицензировать аж все 28 IFL-ядер

          Вы и на сервере х86 за SLES будете платить по $12 000/год за ядро. Вот только ядер у Вас будет раз в десять больше

          За 2 сокета (что нынче в максимуме равно 384 ядрам) придется заплатить аж ~1500$/год. Да, на x86 такая вот "халява" в отличие от.

          Диски понабятся и желательно не entry/midrange level (хотя и такие можно подключать к МФ чего я лично не рекомендую)

          Уже можно подключать СХД не умеющее в FICON ? Какие например ?

          С каким таким capacity? Вы посмотрели только на числа CPU.

          C тем которое указано Вами в z14.

          А что Вы знаете про ввод-вывод этой стойки 19"?

          SAP-процессоры, каналы, i/o offload и т.д.

          В целом совершенно безответственное заявление. Что Вы можете сказать про 30 летнюю давность? Приведите пример.

          Что назвать 34 "ядра" (например в виде пачки S/390-машин) датацентром можно было году в 95-ом и уж точно не сегодня какие-бы волшебные технологии не были бы внутри.

          Вы где такие прайсы берете? 336K$/год за 30 ядер и 5K$/год за 256. Поделитесь, пожалуйста.

          https://www.suse.com/shop/server/

          Я несколько лет работал с SuSe на МФ. Бесплатно.

          Можно и бесплатно, но без обновлений и поддержки, что например для работы всякой 3rd party-корпоративщины есть моветон (тем более если решили для этого зачем-то залезть на IBM System z)


          1. zVlad909 Автор
            11.07.2025 22:59

            Я спросил:

            "Вы где такие прайсы берете? 336K$/год за 30 ядер и 5K$/год за 256. Поделитесь, пожалуйста."

            Вы ответили:

            https://www.suse.com/shop/server/

            Я сходил и увидел:

            1-2 Sockets (x86-64) with Unlimited virtual machines with live patching:

            Priority:

            5 Year Subscription

            CA$  21,707.00

            IBM Z (без количества каких либо сокетс или ядер)

            Priority:

            5 Year Subscription

            CA$  58,491.00

            Вопрос: где 336K$/год?

            Можно и бесплатно, но без обновлений и поддержки, что например для работы всякой 3rd party-корпоративщины есть моветон (тем более если решили для этого зачем-то залезть на IBM System z)

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


            1. krids
              11.07.2025 22:59

              5 Year Subscription

              CA$  58,491.00

              Вопрос: где 336K$/год?

              Вы не заметили "мелкий шрифт внизу договора" : To entitle systems with more than 1 IFL, please purchase multiples of this product. У RedHat (который нынче принадлежит IBM), кстати, точно также (что вообще лютая наглость). Лично у меня от такой "дифференциации по цвету штанов" одного продукта для разных платформ сильно пригорает, типа "z-кастомер дофига богатый раз покупает такую машину, поэтому купит и лунукс за 12K$/год на ядро" . Есть, конечно, еще убунта, с гораздо более вменяемым ценником, но это не для "корпоративщины"


      1. vadimr
        11.07.2025 22:59

        За стоимость годовой SLES-подписки на указанную выше z14 можно будет взять еще пяток таких "писюков" и собрать в кластер.

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


        1. krids
          11.07.2025 22:59

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

          Pacemaker - зло ;) Я имел виду кластер виртуализации, скажем, к примеру, на Proxmox.


  1. ma1uta
    11.07.2025 22:59

    Ужас, что кто-то в 2025 году до сих пор лицензируется по CPU.


    1. krids
      11.07.2025 22:59

      Тут скорее не "кто-то", а "не только лишь все" :(


  1. mk2
    11.07.2025 22:59

    Ситуация, когда покупается железка с Х CPU ядрами и Y гигабайт памяти, но использовать можно только часть из этих ресурсов, потому что это регулируется условием подписки, мне видится прямо совсем дичью. Считай, мы берём модель ценообразования от облачных ДЦ, но при этом оставляем недостатки от on-premise.

    Касательно же "как x86 сервер измеряет выполненную работу" - то Windows/Linux сервер на x86 или arm измеряет текущее потребление памяти и нагрузку на CPU в целом и для каждого процесса, и этого достаточно - собственно операционная система с этим ничего всё равно не сделает.

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

    А если нужно поскейлить систему - то это уровнем ниже, к оркестратору или гипервизору. Изменить количество памяти/ядер на лету эти ОС сами по себе не умеют. И хотя docker/k8s контейнеры скейлить вертикально можно (в пределах hardware пода, конечно), обычно предпочитают горизонтальное масштабирование.

    В общем, Windows/Linux это системы общего назначения, которые могут работать на любом железе и запускать любые приложения, а z/OS - очень специализированная система, туго интегрированная и вендорлокнутая. Как сказано выше, её покупают только те, кто точно знает зачем им IBM System Z . Я, например, не знаю )) Остальные берут любое железо, ставят Linux или иногда Windows, и запускают что хотят.


    1. krids
      11.07.2025 22:59

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

      Это такая фишка IBM по выкачиванию бабла из заказчиков System Z и POWER. Типа "если вы спрашиваете какой расход топлива у этого автомобиля, значит этот автомобиль не для вас".


    1. zVlad909 Автор
      11.07.2025 22:59

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

      Не запрещается, и даже очень поощряется использование всех ядер и всей памяти. Но это будет дороже в смысле платы за софтваре. Имеется в виду софтваре с z/OS и под ним. Железка продается по фиксированной цене, и вы сами не захочете активировать всю конфигурацию когда увидите, очень скоро, что используете то вы, скажем, 30% железа, а платите за софт как будто используете на все 100.

      Вот тут то и поймете зачем у z14 ZR1 имеется 26 * 6 = 156 уровней капасити причем вы легко можете скакать по этим уровням (бесплатно, почти) и находить тот уровень который отвечает вашем потребностям и влечет за собой адекватную плату за софтваре. Вы даже можете попросить установить Вам несколько (до 200, см. в статье) разных конфигураций и менять их в зависимости от потребностей. И восторжествует принцип коммунизма: "От каждого по способностям, каждому по потребностям".

      Но эта роскошь доступна только если Вы используете МФ с z/OS. Если вы берете МФ исключительно для Linux и zVM, то вы платите некоторую базовую цену, скажем так, "пустого" МФ и потом набираете, как в столовой самобслуживания, блюда по важему желанию. На кассе вам подсчитают за все и вы заплатите и будете использовать все за что заплатили. Т.е. точно так же как Вы и представляете это должно быть.

      Потом вы можете позвонить в столовую (ИБМ) и заказать дополнительные блюда. Вам их привезут (вместе с инвойсом) установят и пожалуйста пользуйтесь. За софт вы будете платить (или не платить) отдельно, SuSe, RedHat whoever.


      1. vadimr
        11.07.2025 22:59

        Это с мелочей начинается у IBM. Допустим, x86 сервер IBM/Lenovo имеет 4 встроенных сетевых порта, но исходно активировано 2. Доплатишь - пришлют код активации на 2 других. Софт тут не причём.


        1. zVlad909 Автор
          11.07.2025 22:59

          В Вашем примере софт не причем, но Вы, извините, не поняли, если это касается z/OS, DB2, CICS, etc... Софт очень даже причем. И я по моему ясно показал что когда речь идет о том что в ИБМ называется New Workload то все становится как у всех.

          А Lenovo уже давно не ИБМ. Ни десктопы, ни сервера. При всем к Вам уважении.

          З.Ы. Аналогом сетевых портов в пресловутом Lenovo сервер, но на МФ является OSA card. Если мы оговорили при покупке две карты в двумя портами, то в МФ поставленном нам будет именно две с двумя и все порты открыты. Если нам понадобится другие две, то мы их закажем, оплатим и получим. Иначе говоря что там происходит с Lenovo серверами не имеет отношение к ИБМ МФ.

          Я предлагаю не думать об американских компаниях как о советских колхозах. Компания может быть разной с разных углов зрения и дверей. Как говорится все фломастеры на вскус и свет разные.

          В 70-е и 80-е все компании ИТ старались быть похожими на ИБМ. И самая преуcпевшая в этом называется Microsoft.


          1. vadimr
            11.07.2025 22:59

            если это касается z/OS, DB2, CICS, etc... Софт очень даже причем

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

            Вы к этому привыкли, но это извращение.

            А Lenovo уже давно не ИБМ

            Так это ещё с IBM было заведено.


            1. zVlad909 Автор
              11.07.2025 22:59

              Потому что компьютеры разной конфигурации это разные компьтеры. Такое объяснение Вас устроит?

              Я как Вы предлагаете определять цену за софт?

              Изначально ИБМ не брал отдельно за его софт. ИБМ софт был бесплатным. Но появилсь и много компаний пишущих софт для МФ и берущих за это деньги.

              Т.е. не ИБМ первым начал.


              1. vadimr
                11.07.2025 22:59

                Потому что компьютеры разной конфигурации это разные компьтеры. Такое объяснение Вас устроит?

                Нет, потому что это не объяснение.

                как Вы предлагаете определять цену за софт?

                Да как нормальные люди, экономически обоснованным образом. Себестоимость разработки плюс норма прибыли, делённые на ожидаемое количество копий.

                Изначально ИБМ не брал отдельно за его софт. ИБМ софт был бесплатным. Но появилсь и много компаний пишущих софт для МФ и берущих за это деньги. 

                Т.е. не ИБМ первым начал.

                Не очень понимаю, каким образом наличие платных конкурентов для бесплатного софта к чему-либо могло вынудить IBM.

                Я всю жизнь занимаюсь коммерческой разработкой ПО, и уверяю, что у разработчика есть миллион способов гибкого ценообразования и без таких извращений (которые по-хорошему надо было бы запретить антимонопольным законом). Например, продавать дополнительные функциональные модули за отдельные деньги. И обычно так и делают.

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


                1. zVlad909 Автор
                  11.07.2025 22:59

                  Я всю жизнь занимаюсь коммерческой разработкой ПО, и уверяю, что у разработчика есть миллион способов гибкого ценообразования  ...

                  Вот ИБМ и выбрали один из миллиона гибких способов тот который им наиболее подходящь. ИБМ был основан в конце 19 века.


                  1. vadimr
                    11.07.2025 22:59

                    В начале 20. И при Холлерите и Уотсонах в IBM всё было очень круто, и такой фигни не было. А потом пошли эффективные менеджеры со своей лажей, и начала выручка перемещаться из реального производства в финансовый пузырь. Первым, помнился, Герстнер заявил, что IBM means service, и покатилось всё.

                    Давно бы уже и производство мейнфреймов продали Хитачи или китайцам, да правительство США запрещает.

                    Рынок мейнфреймов почти... ээ... потеряли. PC потеряли. POWER почти потеряли. OS/2 потеряли. DB2 почти потеряли. PL/I потеряли. А ведь это всё были ДОМИНИРУЮЩИЕ на рынке решения. Продают линукс зато.

                    Осталось еще возрастных сотрудников разогнать, как планируется.