🔥💣 “O MAINFRAME NÃO FICOU CARO — VOCÊ É QUE DEIXOU O 4HRA VIRAR UM INCÊNDIO” ☕💾

 

Bellacosa Mainframe e o custo medio de uso do mainframe 4HRA

🔥💣 “O MAINFRAME NÃO FICOU CARO — VOCÊ É QUE DEIXOU O R4HA VIRAR UM INCÊNDIO” ☕💾

Rolling 4HRA no IBM Z: A Verdade Brutal que Todo Sysprog Junior Descobre Quando o CPU Começa a Derreter

Padawan…

Existe um momento sombrio na vida de todo SYSprog junior.

Um momento em que:

• o CPU começa a subir,

• o RMF vira filme de terror,

• o DBA começa a suar frio,

• o gerente pergunta sobre custos,

• e alguém pronuncia uma sigla maldita dentro da sala de guerra:

🚨 R4HA

Ou:

🔥 Rolling 4-Hour Average

Nesse instante…

Você deixa de ser apenas “o cara que olha JES2 e IPL”.

E começa a entender a realidade brutal do mundo IBM Z moderno:

O maior inimigo do mainframe não é a falta de potência.

É workload mal otimizado queimando MSU como se CPU fosse lenha.

---

☕ O GRANDE MITO: “MAINFRAME É CARO”

Padawan…

O IBM Z não ficou caro por acaso.

O problema é que muita empresa roda:

• SQL desastroso,

• batch sem controle,

• SORT monstruoso,

• loops infinitos,

• CICS mal desenhado,

• e workloads completamente desequilibrados.

Depois olha para a conta mensal e diz:

• “o mainframe custa caro”.

É como culpar a usina elétrica porque alguém deixou um forno industrial ligado dentro da garagem.

---

🔥 O QUE É O ROLLING 4HRA?

O Rolling 4HRA é:

• uma média móvel de consumo de CPU/MSU das últimas 4 horas.

Mas dizer só isso é simplificar demais.

Na prática ele é:

💀 O SENSOR FINANCEIRO DO DATACENTER

Porque ele mede:

• consumo sustentado,

• pressão operacional,

• tendência de carga,

• risco financeiro,

• e eficiência arquitetural do ambiente.

---

💾 O MAINFRAME NÃO TEM MEDO DE PICOS

Esse é o detalhe genial do modelo IBM Z.

O sistema foi construído para absorver:

• explosões de workload,

• fechamento bancário,

• Black Friday,

• processamento massivo,

• milhões de transações.

O problema nunca foi:

• o pico curto.

O problema é:

🔥 O INCÊNDIO CONTÍNUO

É aí que o R4HA entra.

---

☕ A FILOSOFIA POR TRÁS DO R4HA

Imagine um motor Ferrari.

Uma acelerada rápida:

• não destrói o motor.

Mas manter:

• giro máximo,

• temperatura extrema,

• pressão contínua,

• por horas…

Aí o sistema começa a sofrer.

O Rolling 4HRA existe justamente para medir:

• desgaste sustentado.

---

🚨 POR QUE A IBM USA ISSO?

Porque seria injusto cobrar:

• pelo pico de alguns minutos.

Então o ecossistema IBM criou:

• média móvel de 4 horas.

Isso suaviza:

• explosões temporárias,

• spikes pequenos,

• ruídos operacionais.

Mas também revela:

• workloads persistentemente ruins.

---

🔥 E É AQUI QUE O SYSprog PADAWAN ACORDA PARA A VIDA

Você percebe que:

• CPU não é apenas CPU.

Ela virou:

• dinheiro,

• licensing,

• SLA,

• capacidade,

• reputação operacional.

No IBM Z moderno:

💰 MSU = DINHEIRO

---

💣 QUANDO O DESASTRE COMEÇA

Tudo parece normal.

Até que alguém sobe:

• um SQL sem índice,

• um tablespace scan monstruoso,

• um batch paralelo sem controle,

• um SORT insano,

• um COBOL looping,

• um CICS runaway task.

Aí…

O CPU começa a subir.

Mas o verdadeiro terror ainda nem começou.

---

☕ O “EFEITO VENENO” DO R4HA

Esse conceito separa:

• o junior do veterano.

Porque mesmo depois de corrigir o problema:

• o R4HA continua alto.

E o padawan pergunta:

“Mas já cancelamos o job… por que continua ruim?”

Porque o Rolling 4HRA:

• ainda está carregando o histórico do desastre.

---

🔥 O R4HA TEM MEMÓRIA

Ele funciona como:

• uma onda de calor.

Mesmo após apagar o incêndio:

• o ambiente continua quente.

Isso gera:

• impacto financeiro,

• impacto operacional,

• pressão no capacity planning.

---

💾 O ERRO CLÁSSICO DOS JUNIORS

Confundir:

• CPU instantânea
  com

• Rolling 4HRA.

São coisas completamente diferentes.

Você pode ter:

• CPU baixa AGORA,

• mas R4HA altíssimo.

Porque a média móvel ainda está contaminada pelas horas anteriores.

---

🚨 O QUE MAIS INCENDIA O R4HA?

🔥 DB2

Aqui mora um dos maiores vilões do datacenter.

Um único SQL ruim pode:

• destruir cache,

• explodir SORT,

• aumentar GETPAGE,

• saturar CPU,

• gerar scan absurdo.

E tudo isso:

• alimenta o R4HA.

---

🔥 CICS

Quando mal desenhado:

• vira um triturador de MSU.

Problemas clássicos:

• pseudo-conversational ruim,

• polling excessivo,

• loops de transação,

• runaway tasks,

• filas gigantes.

---

🔥 BATCH

O batch mal otimizado é um clássico.

Especialmente:

• DFSORT gigantesco,

• JOINKEYS abusivo,

• I/O thrashing,

• múltiplos jobs concorrentes.

O resultado:

💀 tempestade de CPU

---

☕ O WLM TENTA SALVAR O AMBIENTE

O WLM funciona como:

• o maestro do caos.

Ele tenta:

• priorizar workloads,

• proteger online,

• equilibrar recursos,

• manter SLA.

Mas quando:

• tudo começa a consumir demais…

Nem o WLM faz milagre.

---

🔥 SOFT CAPPING: A FACA DE DOIS GUMES

Então alguém diz:

“Vamos limitar MSU!”

Aí nasce o:

💣 Soft Capping

Objetivo:

• evitar explosão financeira.

Mas se configurado errado:

• batch atrasa,

• online degrada,

• filas explodem,

• SLA morre.

---

💾 O PARADOXO DO SYSprog

Se libera CPU:
💰 custo explode.

Se limita demais:
💀 produção explode.

Esse equilíbrio delicado é uma das artes mais difíceis do IBM Z.

---

🚨 O QUE O SYSprog EXPERIENCED APRENDE

Ele aprende que performance tuning não é:

• “deixar rápido”.

É:

🔥 impedir o datacenter de sangrar dinheiro

---

☕ O MAINFRAME MODERNO É UMA MÁQUINA DE EFICIÊNCIA

O IBM Z moderno:

• processa milhões de TPS,

• roda bancos inteiros,

• suporta cloud híbrida,

• executa IA,

• integra APIs,

• conversa com Kubernetes,

• roda Linux massivamente.

O hardware é absurdamente poderoso.

O problema normalmente está:

• no workload.

---

💣 O MAINFRAME NÃO ESTÁ LENTO

Na maioria dos casos:

• o ambiente está sendo sabotado por software ruim.

E o Rolling 4HRA:

• apenas revela isso de forma cruel.

---

🔥 O DIA EM QUE O PADAWAN EVOLUI

A evolução acontece quando ele entende:

tuning não é estética

Não é:

• “ganhar benchmark”.

É:

• sobrevivência financeira,

• estabilidade operacional,

• sustentabilidade do ambiente.

---

☕ RMF: O ORÁCULO DO IBM Z

O SYSprog veterano aprende a ler:

• RMF,

• SMF 70,

• SMF 72,

• OMEGAMON,

• MXG,

• IntelliMagic.

Porque nesses relatórios está:

• a verdade do ambiente.

O R4HA conta uma história.

E essa história normalmente aponta:

• quem está incendiando CPU.

---

🔥 O MAINFRAME CONTINUA SENDO O REI

E aqui está a ironia maravilhosa.

Mesmo sob caos:

• milhões de transações continuam funcionando,

• ATM continua online,

• PIX continua passando,

• cartão continua autorizando,

• folha continua fechando.

Enquanto isso…

• o IBM Z aguenta pancada absurda silenciosamente.

---

💾 A GRANDE VERDADE

O problema nunca foi:

• a potência do mainframe.

O problema é:

• arquitetura ruim,

• SQL ruim,

• falta de governança,

• tuning inexistente,

• e desconhecimento sobre workload management.

---

☕ LIÇÃO FINAL DO PADAWAN IBM Z

Quando você olha um Rolling 4HRA:

• você não está vendo apenas CPU.

Você está vendo:

• comportamento do ambiente,

• disciplina operacional,

• maturidade técnica,

• eficiência arquitetural,

• e o custo real das decisões ruins.

---

🔥 FRASE FINAL ESTILO BELLACOSA MAINFRAME

“O IBM Z não cobra caro por existir.
Ele apenas expõe, em MSU e R4HA, todas as decisões ruins que alguém colocou em produção.” ☕💾🔥

---

🔥 Rollinf 4HRA

 O Rolling 4HRA (Rolling 4-Hour Average) é a média móvel de consumo de capacidade do mainframe IBM Z durante as últimas quatro horas. Ele mede o uso sustentado de CPU e MSU, sendo utilizado pelo WLM, RMF e modelos de licenciamento IBM para calcular custos e avaliar performance do ambiente. Diferente do uso instantâneo de CPU, o 4HRA continua elevado mesmo após um pico terminar, refletindo impactos anteriores no workload. Por isso, SQL ruim, batch pesado e loops podem aumentar custos significativamente.

 

Bellacosa Mainframe apresenta o maestro invisivel do Mainframe: WLM

 

🚀 O Maestro Invisível do Mainframe: Como o WLM Decide Quem Vive, Quem Espera e Quem Domina o IBM Z

“O z/OS não é apenas um sistema operacional. É um sistema de sobrevivência computacional — e o WLM é seu cérebro.”

Se você é um padawan do mainframe 🧙‍♂️, há um momento em que tudo muda.
Você deixa de ver jobs, CICS e DB2 como coisas isoladas… e passa a enxergar um ecossistema vivo, onde milhares de tarefas lutam pelos mesmos recursos.

Nesse universo, existe um árbitro supremo:

🧠 Workload Manager — WLM

Sem ele, um mainframe moderno seria apenas um supercomputador caro brigando consigo mesmo.

---

🏛️ Antes do WLM: o caos elegante dos anos 70 e 80

Nos primórdios do MVS, a prioridade era… manual.

Operadores e sysprogs definiam:

• Prioridades fixas

• Classes de execução estáticas

• Ajustes “no feeling”

• Reconfiguração constante

Problemas clássicos:

💥 Batch travando online
💥 CICS lento em horário de pico
💥 CPU livre e usuários reclamando
💥 Sistema imprevisível

O hardware evoluiu. O software também precisava evoluir.

---

⚙️ O nascimento do WLM — computação orientada ao negócio

O WLM moderno surgiu com o OS/390 nos anos 90.

A ideia foi revolucionária:

❌ Não gerenciar processos
✅ Gerenciar objetivos de negócio

Você não diz:

👉 “Este job tem prioridade 8”

Você diz:

👉 “Quero que 90% das transações respondam em até 1 segundo”

O sistema decide como chegar lá.

---

🎼 O WLM é um maestro, não um executor

Ele não executa código.

Ele coordena:

• Dispatcher (CPU)

• IOS (I/O)

• Memory manager

• PR/SM (hardware)

• Subsystems (CICS, DB2, etc.)

Política → Prioridade → Recursos → Execução

---

🧩 Os elementos fundamentais do WLM

🏷️ Service Class — “Quem é você?”

Categoria de workload com tratamento específico.

Exemplos reais:

• CICS_ONLINE

• DB2_OLTP

• BATCH_HIGH

• TSO_USERS

• DISCRETIONARY

Uma única classe pode representar centenas de workloads.

---

🎯 Goal — “O que esperamos de você?”

Tipos principais:

• ⏱️ Response Time — tempo de resposta

• ⚡ Velocity — progresso contínuo

• 💤 Discretionary — use as sobras

---

⭐ Importance — “Quão importante você é?”

Escala de 1 a 5:

1️⃣ Missão crítica
5️⃣ Pode esperar

Sob escassez, isso decide tudo.

---

⏱️ Performance Periods — prioridade dinâmica

Uma obra-prima do design do WLM.

Permite tratar o mesmo trabalho de forma diferente ao longo do tempo.

Exemplo típico:

Período 1 — Importance 1 — resposta rápida
Período 2 — Importance 3 — menos crítico
Período 3 — Discretionary — só sobras

👉 Protege o sistema contra trabalhos “runaway”.

---

🧭 Classification Rules — o roteador automático

Determinam qual workload entra em qual Service Class.

Critérios possíveis:

• Job name

• User ID

• Address space name

• Transaction name (CICS)

• Atributos de enclave

• Padrões (wildcards)

💎 Curiosidade: também podem marcar workloads como Storage Critical.

---

⚡ Dispatchable Units — quem realmente roda

O dispatcher não agenda jobs.

Ele agenda DUs:

• 🧾 TCB — tasks de aplicação

• ⚡ SRB — trabalho de sistema

Múltiplas DUs podem rodar simultaneamente no mesmo address space.

---

🧮 Dispatching Priority — o número mágico

Escala: 0–255 (geralmente >190)

👉 Maior valor ⇒ maior chance de CPU

Mostrado no SDSF (painel DA).

É recalculado constantemente pelo WLM.

---

📀 I/O Priority e Memory

O WLM também influencia:

📀 I/O

• Prioridade de acesso a discos

• Filas de dispositivos

• Latência de storage

Sem grupos específicos:

👉 I/O priority = Dispatching priority

---

💾 Storage Critical

Protege workloads contra swap.

Não dá mais memória — evita que sejam expulsos da RAM.

Crucial para:

• CICS

• DB2

• Middleware

• Serviços online

---

🩸 Donor vs Receiver — economia de recursos

Sob escassez:

• 🏆 Receivers → precisam cumprir metas

• 🩸 Donors → cedem recursos

• 💤 Discretionary → só sobras

Regra importante:

👉 Só doa quem está usando.

---

🧠 Enclaves — workloads distribuídos

Representam trabalho que atravessa múltiplos address spaces.

Muito usados em:

• DB2 DDF

• APIs

• Java servers

• MQ

• Middleware

Permitem controle ponta a ponta.

---

🧪 Curiosidades e Easter Eggs

💎 O WLM é considerado uma das maiores vantagens competitivas do mainframe.

💎 Muitos conceitos de QoS em cloud vieram daqui.

💎 Sistemas distribuídos ainda lutam para replicar essa sofisticação.

💎 O mainframe pode parecer “antigo”, mas seu scheduler é mais avançado que o de muitos sistemas modernos.

---

💥 Falhas mais comuns em produção

❌ Políticas mal projetadas

Sintomas:

• CPU alta sem ganho real

• Online lento

• Batch dominando horários críticos

---

❌ Service Classes demais

Complexidade gera comportamento imprevisível.

---

❌ Classificação incorreta

Workloads críticos tratados como comuns.

---

❌ Ignorar Performance Periods

Trabalhos longos monopolizam recursos.

---

🛠️ Como controlar e acompanhar

Ferramentas principais:

🖥️ SDSF

• DA — Address Spaces ativos

• ENCLAVES — workloads distribuídos

• ST — Jobs

---

📊 RMF

Análise profunda de performance.

---

⚙️ WLM ISPF / z/OSMF

Configuração de políticas.

---

📈 SMF records

Base para capacity planning e auditoria.

---

🧭 Como pensar como um especialista

Quando algo está lento, pergunte:

👉 Qual recurso está saturado?
👉 Quem está consumindo?
👉 Esse workload deveria ter essa prioridade?
👉 O WLM está cumprindo ou ignorando metas?

---

🏆 A verdade final

O poder do mainframe não está apenas no hardware.

Está na capacidade de usar recursos de forma:

✔️ previsível
✔️ controlada
✔️ orientada ao negócio
✔️ resiliente sob carga extrema

---

🧠 Frase para levar para a vida

WLM não decide quem roda primeiro.
Ele decide quais objetivos do negócio serão preservados quando os recursos acabarem.

https://www.linkedin.com/pulse/o-maestro-invis%25C3%25ADvel-do-mainframe-como-wlm-decide-quem-bellacosa

 

Bellacosa Mainframe analise o enclave no z/os

🔥 “ENCLAVE NO z/OS: O JOB INVISÍVEL QUE MANDA MAIS QUE SEU COBOL” 💀

Se você acha que quem manda no z/OS é o seu JOB, seu STEP ou seu programa COBOL… já começou errado 😈
Existe uma entidade silenciosa, poderosa e MUITO mais inteligente: o ENCLAVE.

E depois que você entende isso… nunca mais olha para performance, WLM ou CICS da mesma forma.

---

🧠 O QUE É UM ENCLAVE (SEM MIMIMI)

Um enclave no z/OS é uma unidade lógica de trabalho gerenciada pelo WLM (Workload Manager).

👉 Tradução Bellacosa:

É como se fosse um “JOB fantasma” criado pelo sistema pra medir, priorizar e controlar o que realmente importa.

Ele não aparece no JES como um JOB comum.
Ele não está preso a um único address space.
Mas… ele é quem decide quanto CPU você ganha ou perde.

---

🏛️ ORIGEM — POR QUE ISSO EXISTE?

Lá atrás, no mundo pré-WLM, o controle era baseado em:

• Prioridade fixa
• Dispatching clássico
• Regras estáticas

Problema? 😬
Ambientes modernos (CICS, DB2, WebSphere, Java, API REST) quebraram esse modelo.

👉 A IBM respondeu com o WLM Goal-Oriented:

E aí nasceu o ENCLAVE:

• Para representar transações distribuídas
• Para permitir gerenciamento baseado em objetivos (response time, velocity, etc.)
• Para desacoplar trabalho de address spaces

💡 Ou seja:

O enclave nasceu quando o mainframe percebeu que o mundo virou distribuído.

---

⚙️ COMO FUNCIONA NA PRÁTICA

Imagine isso:

• Um request entra via CICS
• Faz chamada DB2
• Vai pra MQ
• Volta pro CICS

👉 Isso tudo NÃO é um único processo linear

O z/OS cria um ENCLAVE para representar esse fluxo como uma única entidade lógica

---

🔄 O enclave acompanha:

• Tempo de CPU
• Tempo de resposta
• Esperas (I/O, lock, etc.)
• Prioridade dinâmica (via WLM)

---

🎯 O PAPEL DO WLM (O VERDADEIRO CHEFE)

O WLM não gerencia JOBs diretamente.

Ele gerencia:

👉 ENCLAVES

Com base em:

• Service Class
• Importance
• Performance goals

💡 Resultado:

Dois programas idênticos podem ter comportamentos COMPLETAMENTE diferentes dependendo do enclave.

---

🧨 EXEMPLO REAL (COBOL DEV VAI SENTIR)

Você roda:

• Um batch COBOL via JCL
• Uma transação CICS chamando o mesmo programa

Mesmo código… MAS:

Contexto	Quem manda
Batch	JES / Dispatching
CICS	ENCLAVE + WLM

👉 Resultado:

• No CICS, o desempenho é governado pelo enclave
• No batch, não

💀 É por isso que “funciona no batch mas é lento no online”

---

🕵️ TROUBLESHOOTING (OU: POR QUE SEU JOB APANHA)

Se algo está lento e você ignora enclave… você está investigando errado.

🔍 Sintomas clássicos:

• CPU baixa, mas resposta ruim
• Transação lenta “sem motivo”
• WLM aparentemente ignorando você

🧠 Possíveis causas:

• Service class errada
• Importance baixa
• Goal impossível (ex: response time irreal)
• Contenção em recursos compartilhados

---

🛠️ ONDE INVESTIGAR

• RMF Monitor III
• SMF 72 (WLM)
• SDSF (delay reason)
• CICS statistics

💡 Dica Bellacosa:

Se não olhou SMF 72, você não investigou WLM de verdade.

---

🧩 EASTER EGG (POUCA GENTE SABE)

🔥 Nem todo enclave é igual:

Existem:

• Independent enclaves
• Dependent enclaves

👉 Dependente = herda contexto
👉 Independente = vive sua própria vida

💡 E aqui vem o pulo do gato:

Um enclave pode atravessar múltiplos sistemas via sysplex

Sim… o “fantasma” atravessa LPARs 👻

---

🤯 CURIOSIDADES QUE EXPLODEM A MENTE

• Enclaves são essenciais para Java no z/OS
• DB2 usa enclaves para workloads distribuídos (DRDA)
• z/OS Connect depende disso pra API REST

👉 Ou seja:

Sem enclave… não existe mainframe moderno

---

⚠️ ERROS CLÁSSICOS (E CAROS)

❌ “Aumenta a prioridade do address space”
👉 ERRADO — quem manda é o enclave

❌ “O problema é CPU”
👉 Nem sempre — pode ser política WLM

❌ “Batch está ok, então produção também está”
👉 Contexto diferente = enclave diferente

---

💬 COMENTÁRIO NO ESTILO RAIZ

Enclave é aquele tipo de coisa que:

• Ninguém te ensina direito
• Todo mundo usa sem saber
• E quando dá problema… vira caos

💀

---

🧠 RESUMO DIRETO (SEM ENROLAR)

👉 Enclave é:

• Uma unidade lógica de trabalho
• Controlada pelo WLM
• Independente de address space
• Base para performance moderna no z/OS

---

🔥 FRASE PRA GRUDAR NA SUA CABEÇA

“Você acha que está rodando um programa…
mas quem está sendo julgado é o seu ENCLAVE.”

🔥 SEU JOB NÃO RODA… ELE DISPUTA SOBREVIVÊNCIA 💀 O que o z/OS faz nos bastidores enquanto você “só executa um COBOL”

 

Bellacosa Mainframe apresenta a gestão de tarefas no z/os

🔥 SEU JOB NÃO RODA… ELE DISPUTA SOBREVIVÊNCIA 💀

O que o z/OS faz nos bastidores enquanto você “só executa um COBOL”

Você digita um JCL, dá submit e pensa:
👉 “beleza, agora é só esperar o output”

Errado.

No z/OS, seu job entra em um ecossistema competitivo, onde:

• CPU é disputada
• memória é compartilhada
• prioridades são negociadas
• o sistema decide tudo

Se você quer sair do nível “usuário de mainframe” e virar engenheiro de sistema, esse é o mapa mental que muda o jogo 👊🔥

---

🧠 1. O COMEÇO — SUBMIT NÃO É EXECUÇÃO

Quando você faz submit:

//JOB ...

👉 seu job NÃO executa.

---

🔹 O que acontece de verdade

• JES recebe
• vai pro spool
• ganha um número
• entra numa fila
• espera um initiator

---

🔥 Tradução Bellacosa

“Submit é só entrar na fila do sistema.”

---

💡 Exemplo real

Você tem 100 jobs na fila…

👉 seu job pode esperar minutos ou horas

---

⚙️ 2. JOB → TASK (A TRANSFORMAÇÃO INVISÍVEL)

O z/OS não trabalha com “jobs”.

👉 Ele trabalha com:

TASKS (TCBs)

---

🔹 Como funciona

JOB → STEPS → TASKS (TCB)

Cada step vira uma unidade executável.

---

🧨 Curiosidade

Um job pode gerar várias tasks simultâneas.

---

⚡ 3. DISPATCHER — O “DEUS DO CPU”

Esse é o cara mais importante do sistema.

---

🔹 Função

Decidir:

“Quem roda AGORA?”

---

🔥 Como ele faz isso

• varre a fila (WUQ)
• pega TCB ou SRB
• escolhe o de maior prioridade
• carrega contexto
• entrega CPU

---

💡 Insight poderoso

O dispatcher troca tarefas milhares de vezes por segundo

---

🧠 Tradução

CPU nunca fica “presa” a um programa

---

🧩 4. TCB vs SRB — A BRIGA INTERNA

🔹 TCB

• usado por aplicações (COBOL 👀)
• pode ser interrompido

---

🔹 SRB

• usado pelo sistema
• maior prioridade
• execução mais rápida

---

🔥 Tradução Bellacosa

SRB é o “VIP do sistema”
TCB é o trabalhador comum 😄

---

🧠 5. ENCLAVES — O NÍVEL CORPORATIVO

Aqui o sistema evolui de técnico → negócio.

---

🔹 O que é?

Um conjunto de tarefas:

👉 espalhadas em vários address spaces
👉 tratadas como uma unidade

---

🔥 Exemplo real

App Web → WAS → CICS → DB2

👉 tudo isso vira um enclave

---

💡 Insight

O z/OS não gerencia código… gerencia transações de negócio

---

🖥️ 6. PR/SM — O MESTRE DO HARDWARE

Antes do z/OS, existe:

👉 PR/SM (hypervisor)

---

🔹 Ele faz:

• divide hardware em LPARs
• entrega CPU virtual
• controla recursos

---

🔥 Relação

Hardware → PR/SM → z/OS → Task

---

🧨 Curiosidade

Seu z/OS pode não saber qual CPU física está usando 😳

---

⚡ 7. CPU MANAGEMENT — ONDE PERFORMANCE NASCE

🔹 Conceitos:

• HyperDispatch
• afinidade CPU/memória
• otimização de cache

---

💡 Insight

Rodar perto do dado = menos latência

---

🔥 Tradução Bellacosa

Não é só rodar… é rodar no lugar certo

---

👥 8. ADDRESS SPACES — O UNIVERSO ISOLADO

Cada coisa roda em seu próprio espaço:

• Batch
• TSO
• Started Task

---

🔥 Dentro deles:

• TCBs
• subtasks
• memória isolada

---

💡 Exemplo

Um batch:

Initiator → cria address space → cria TCB → executa

---

🔗 9. DYNAMIC LINKAGE — COMO OS PROGRAMAS SE CONECTAM

🔹 Comandos principais:

• LINK
• LOAD
• ATTACH
• XCTL

---

🔥 O que fazem?

• chamam programas
• carregam módulos
• transferem controle

---

💡 Ordem de busca:

1. memória (LPA)
2. JOBLIB/STEPLIB
3. LINKLIST

---

🧨 Easter Egg

Se está na LPA… é MUITO mais rápido

---

🧠 10. WLM — O VERDADEIRO CHEFE

🔥 Workload Manager

Define:

• prioridade
• objetivos
• distribuição de CPU

---

💡 Exemplo real

Tipo de workload	Prioridade
pagamento online	alta
batch relatório	baixa

---

🔥 Tradução Bellacosa

O sistema não atende quem pede… atende quem importa

---

🔒 11. SERIALIZATION — EVITANDO O CAOS

🔹 Problema:

2 jobs querem o mesmo recurso

---

🔹 Solução:

• ENQ / DEQ
• GRS

---

💡 Exemplo

Dois jobs acessando dataset:

👉 um espera

---

🧨 CURIOSIDADES (NÍVEL ROOT)

🤯 1. Seu job pode nunca rodar

Se prioridade for baixa

---

🔥 2. CPU pode trocar de task milhares de vezes

Você nem percebe

---

💀 3. SRB pode interromper seu programa

Sem você saber

---

🧠 4. Um único negócio pode rodar em vários address spaces

(enclave)

---

⚙️ PASSO A PASSO REAL (SIMPLIFICADO)

Submit Job
 ↓
JES spool
 ↓
Fila de execução
 ↓
Initiator pega job
 ↓
Cria Address Space
 ↓
Cria TCB
 ↓
Dispatcher escolhe
 ↓
CPU executa
 ↓
WLM ajusta prioridade
 ↓
Output no spool

---

🎯 RESUMO FINAL

✔ Job vira task

✔ Task disputa CPU

✔ Dispatcher decide

✔ WLM prioriza

✔ PR/SM gerencia hardware

✔ Enclave agrupa negócio

---

💥 FRASE FINAL

“Você não executa um job no mainframe…
você entra numa competição onde o z/OS decide se você merece rodar.”

 

 

Bellacosa Mainframe e o system capacity em z/os

☕📈 “O PROFISSIONAL QUE DECIDE SE O BANCO SOBREVIVE AMANHÔ — O UNIVERSO BRUTAL DO MAINFRAME CAPACITY NO IBM Z 💣🖥️

Existe uma área do Mainframe que quase ninguém fora do IBM Z entende.

Ela não aparece em filmes.
Não vira hype no LinkedIn.
Não ganha palco em eventos de startup.

Mas é uma das funções mais críticas da computação corporativa mundial.

Porque ela responde uma pergunta assustadora:

“Quanto tempo falta para o sistema entrar em colapso?”

Estamos falando de:

Mainframe Capacity Planning.

Ou simplesmente:

Capacity.

No universo IBM Z, Capacity não significa apenas medir CPU.

Significa prever o futuro operacional da empresa.

---

⚡ O QUE É CAPACITY NO IBM Z?

Capacity é a disciplina responsável por:

• prever crescimento computacional

• evitar saturação operacional

• otimizar consumo de recursos

• controlar custos milionários

• garantir SLA

• sustentar expansão do negócio

• evitar colapsos invisíveis

O profissional de Capacity trabalha analisando:

• CPU

• memória

• I/O

• DASD

• network

• batch

• transações online

• workload

• throughput

• comportamento sistêmico

Mas o verdadeiro trabalho não é medir recurso.

É entender comportamento corporativo.

Porque cada gráfico conta uma história.

---

☠️ O MAIOR ERRO SOBRE CAPACITY

Muitos imaginam que Capacity é apenas:

“tirar relatório de CPU”.

Errado.

Capacity em IBM Z é quase uma ciência preditiva.

O especialista precisa responder perguntas perigosíssimas:

• O ambiente suporta a Black Friday?

• O batch vai fechar no horário daqui 8 meses?

• Quanto custa crescer 20%?

• O Sysplex está perto do limite?

• O WLM está mascarando degradação?

• Existe gargalo invisível em I/O?

• O consumo MSU vai explodir?

• O zIIP está realmente eficiente?

• O throughput real acompanha o crescimento do negócio?

• O storage suporta expansão orgânica?

Capacity trabalha no território do invisível.

Quando ele acerta…
ninguém percebe.

Quando ele erra…
a empresa inteira sente.

---

🖥️ O PROFISSIONAL DE CAPACITY

Ele é uma mistura rara de:

• engenheiro operacional

• matemático corporativo

• especialista em performance

• analista financeiro

• estrategista de infraestrutura

• investigador sistêmico

• arquiteto de crescimento

Ele precisa entender:

• tecnologia

• comportamento do negócio

• sazonalidade

• arquitetura

• custos

• performance

• tendências operacionais

Porque no IBM Z…

crescimento descontrolado custa milhões.

---

☕ ROTINA DIÁRIA DO PROFISSIONAL DE CAPACITY

📊 Monitoramento de Consumo

Todos os dias ele analisa:

• utilização de CPU

• consumo MSU

• uso de zIIP

• paging

• utilização de memória

• filas JES2

• throughput batch

• transações CICS

• locks DB2

• contention

• saturação de canais

• resposta de aplicações

• uso de DASD

O objetivo não é “olhar gráfico”.

É detectar tendências invisíveis.

---

🔥 DETECÇÃO DE ANOMALIAS

O profissional de Capacity aprende algo brutal:

O desastre sempre deixa sinais antes.

Ele procura:

• crescimento anormal

• degradação gradual

• workloads desbalanceados

• aumento silencioso de batch

• crescimento de I/O

• consumo zIIP ineficiente

• explosão de transações

• mudanças de perfil operacional

Pequenos desvios hoje podem virar desastre daqui 6 meses.

---

⚙️ ANÁLISE DE PERFORMANCE

Capacity trabalha profundamente com:

• WLM

• RMF

• SMF

• throughput

• response time

• dispatch delay

• enqueue contention

• cache behavior

• coupling facility

• HiperDispatch

Aqui começa a engenharia pesada do IBM Z.

---

🧠 CONHECIMENTOS OBRIGATÓRIOS

📈 RMF E SMF

Esses são os “olhos” do Capacity.

Sem eles, o ambiente fica invisível.

O especialista domina:

• RMF Monitor I

• RMF Monitor III

• SMF 70-79

• SMF 30

• SMF 72

• performance classes

• workload activity

• device activity

• coupling activity

Ele literalmente reconstrói o comportamento do sistema usando telemetria.

---

⚡ WLM (WORKLOAD MANAGER)

Capacity sem entender WLM é impossível.

Porque o WLM pode:

• esconder gargalos

• redistribuir prioridade

• mascarar degradação

• alterar percepção operacional

O profissional precisa entender:

• service classes

• velocity

• response goals

• importance

• discretionary workloads

• enclaves

• policy tuning

---

💾 STORAGE E I/O

Aqui mora uma das maiores armadilhas.

Muitos ambientes parecem ter CPU sobrando…

mas estão morrendo em I/O.

Capacity analisa:

• cache hit ratio

• IOS queueing

• device response

• channel path utilization

• FICON saturation

• DASD growth

• SMS behavior

Porque I/O mal dimensionado destrói performance invisivelmente.

---

🌐 NETWORK E TRANSAÇÕES

Mainframe moderno é distribuído.

Capacity também acompanha:

• TCP/IP

• OSA

• Sysplex Distributor

• MQ throughput

• CICS transaction rate

• DB2 concurrency

• API workload

• OpenTelemetry metrics

Hoje IBM Z é altamente conectado.

---

📅 ROTINAS SEMANAIS

📊 Trending Analysis

O profissional cria tendências de:

• crescimento CPU

• uso storage

• throughput batch

• workload online

• utilização zIIP

• expansão de transações

• crescimento de datasets

Aqui nasce o planejamento estratégico.

---

💣 Forecasting

Uma das tarefas mais críticas.

Ele projeta:

• crescimento de negócio

• impacto operacional

• expansão de recursos

• necessidade de upgrade

• consumo futuro de licenciamento

Capacity não trabalha apenas com TI.

Ele impacta diretamente:

• orçamento

• planejamento financeiro

• expansão corporativa

---

🛠️ Tuning Estratégico

O especialista sugere:

• redistribuição de workloads

• tuning WLM

• otimização batch

• uso eficiente de zIIP

• melhorias de scheduling

• balanceamento Sysplex

• redução de gargalos

Pequenos ajustes podem economizar milhões por ano.

---

📆 ROTINAS MENSAIS

💰 Revisão de Custos

No IBM Z, performance e dinheiro estão ligados.

Capacity participa de:

• controle de MSU

• análise de software billing

• consumo MLC

• redução de picos

• SCRT analysis

• otimização de licenciamento

Aqui entra uma verdade brutal:

Às vezes reduzir 5% de CPU economiza milhões.

---

🔥 Planejamento de Upgrade

Ele avalia:

• expansão do CPC

• novos processadores

• upgrade zIIP

• expansão memória

• crescimento storage

• novos links FICON

Capacity participa diretamente da evolução física do ambiente.

---

🚨 TESTES DE ESTRESSE

Capacity também participa de:

• testes de pico

• DR simulations

• Black Friday preparation

• fechamento bancário

• virada fiscal

• sazonalidade crítica

Porque o ambiente precisa sobreviver ao pior cenário possível.

---

🧰 FERRAMENTAS MAIS IMPORTANTES

📊 RMF

A principal ferramenta de performance do z/OS.

---

📈 SMF

A caixa-preta operacional do ambiente.

---

⚡ MXG

Muito usado para consolidar e analisar métricas históricas.

---

🔍 OMEGAMON

Observabilidade moderna enterprise.

---

🧠 IntelliMagic

Analytics avançado para IBM Z.

---

📉 zBNA

IBM z Business Network Analyzer.

---

🖥️ IBM zPCR

Ferramenta para projeção de capacidade futura.

---

☠️ O PESO DA RESPONSABILIDADE

Capacity trabalha com um problema cruel:

O futuro ainda não aconteceu.

Ele precisa prever comportamento antes do desastre aparecer.

Isso exige:

• experiência

• estatística

• visão sistêmica

• interpretação operacional

• conhecimento profundo do negócio

Porque crescimento linear quase nunca existe.

---

🚀 O FUTURO DO CAPACITY NO IBM Z

A área está mudando rapidamente.

Hoje Capacity envolve:

• IA preditiva

• machine learning operacional

• observabilidade cognitiva

• analytics em tempo real

• automação adaptativa

• anomaly detection

• self-optimization

Mas existe uma ironia fascinante:

Quanto mais automação surge…

mais valioso fica quem realmente entende comportamento sistêmico.

---

☕ CONCLUSÃO — O PROFISSIONAL QUE ENXERGA O FUTURO ANTES DO CAOS

O especialista de Capacity não administra apenas recursos.

Ele administra:

• crescimento

• sobrevivência

• estabilidade

• dinheiro

• continuidade corporativa

Ele é o profissional que olha para gráficos…

e consegue enxergar o amanhã.

Enquanto o resto da empresa vê:

“o sistema funcionando”.

O Capacity vê:

• riscos

• tendências

• gargalos

• explosões futuras

• limites invisíveis

E talvez essa seja a definição perfeita do Capacity em IBM Z:

O homem que precisa impedir um desastre que ainda não aconteceu.

 

 

Bellacosa Mainframe monoplex e sysplex o poder do hardware

💣🔥 MONOPLEX vs SYSPLEX — QUANDO O SISTEMA PARA DE SER UMA MÁQUINA E VIRA UM ORGANISMO 🔥💣

---

🧾 Expansão Comentada

Se você já trabalhou com mainframe, provavelmente já ouviu os termos monoplex e sysplex.
Mas a diferença entre eles vai muito além de arquitetura.

👉 Não é tecnologia. É mentalidade operacional.

---

🧠 MONOPLEX — O REINO DO “UMA MÁQUINA SÓ”

✔ Tradução direta:

Um monoplex é um único sistema mainframe rodando de forma independente.

💡 Expansão Bellacosa:

Você tem:

• Um único z/OS ativo
• Recursos locais
• Controle centralizado
• Tudo dependendo de UMA instância

👉 É como um JOB crítico rodando sem checkpoint:

• Se falhar… volta do zero
• Se parar… para tudo

---

⚠️ Limitações reais (que pouca gente fala):

• Janela de manutenção obrigatória
• Escala vertical cara (mais CPU, mais memória, mais $$$)
• Ponto único de falha lógica
• Isolamento entre workloads

---

💣 Analogia mainframe raiz:

Monoplex é um batch gigante rodando sozinho na fila JES2.
Se ele ABENDA… não tem fallback.

---

⚙️ SYSPLEX — QUANDO O MAINFRAME APRENDE A TRABALHAR EM EQUIPE

✔ Tradução direta:

Um sysplex conecta múltiplos mainframes em um ambiente cooperativo unificado.

💡 Expansão Bellacosa:

Aqui o jogo muda completamente:

• Vários sistemas z/OS trabalhando juntos
• Workload distribuído dinamicamente
• Recursos compartilhados em tempo real
• Sistema se comporta como UMA entidade lógica

---

🧩 Componentes que fazem a mágica acontecer:

• Workload Manager (WLM) → decide quem executa o quê
• Coupling Facility → cérebro compartilhado
• XCF → comunicação entre sistemas

---

💣 Analogia Bellacosa:

Sysplex é um cluster de jobs cooperando via checkpoint compartilhado em memória.
Um falha… outro continua de onde parou.

---

🔥 O PONTO MAIS IMPORTANTE (E MAIS IGNORADO)

Você disse:

“No monoplex, disponibilidade é uptime de uma máquina
No sysplex, disponibilidade é projetada no sistema”

💥 Isso aqui é ouro.

Mas vamos aprofundar:

🧠 Monoplex:

• Alta disponibilidade = evitar falhar

⚙️ Sysplex:

• Alta disponibilidade = falhar sem impacto

👉 Isso muda tudo.

---

⚡ ESCALABILIDADE — O PULO DE MATURIDADE

Monoplex:

• Scale-up (vertical)
• Limite físico inevitável

Sysplex:

• Scale-out (horizontal)
• Adição de nós sem parada

---

💣 Analogia moderna:

• Monoplex = subir a máquina no cloud (vertical scaling)
• Sysplex = cluster Kubernetes antes do Kubernetes existir

---

💥 FALHA: O TESTE FINAL DE ARQUITETURA

Monoplex:

• Falha = incidente
• Recovery = reativo

Sysplex:

• Falha = evento esperado
• Recovery = automático

---

🧨 Exemplo real (nível produção):

Imagine:

• Banco rodando CICS + DB2
• Milhares de transações por segundo

👉 Em monoplex:

• IPL → sistema indisponível

👉 Em sysplex:

• Uma LPAR cai
• WLM redistribui carga
• Usuário nem percebe

---

🧬 O SEGREDO DO SYSPLEX (QUE O CLOUD AINDA PERSEGUE)

O sysplex resolve um problema que até hoje dá dor de cabeça em arquitetura distribuída:

👉 Consistência + disponibilidade + performance

Com ajuda do:

• Coupling Facility (lock, cache, list structures)

---

💣 Traduzindo brutalmente:

Enquanto sistemas modernos brigam com:

• cache inconsistente
• race condition
• eventual consistency

👉 O sysplex já fazia:

• lock global
• cache coerente
• sincronização em hardware

---

⚠️ VERDADE QUE NINGUÉM TE CONTA

Sysplex NÃO é mágico.

Se mal projetado:

• CF vira gargalo
• WLM mal configurado gera desequilíbrio
• Links saturam

👉 Ou seja:

Sysplex ruim é pior que monoplex bem feito.

---

🌍 O INSIGHT FINAL (O MAIS IMPORTANTE DE TODOS)

Você falou:

“o futuro já estava aqui”

💥 Vamos elevar isso:

O mainframe não ficou ultrapassado.
Ele resolveu cedo demais problemas que o resto da indústria só entendeu depois.

---

🚀 FRASE PRA CRAVAR

Monoplex é força.
Sysplex é estratégia.

 

 

Bellacosa Mainframe e a introdução a performance no mainframe

Introdução aos Conceitos de Performance em Mainframe

Quando falamos em Performance em Mainframe, estamos falando da arte e da ciência de fazer com que aplicações, bancos de dados, transações online e processos batch executem com máxima eficiência, consumindo o mínimo possível de recursos computacionais.

No universo IBM Z, performance não significa apenas velocidade. Ela envolve:

✅ Tempo de resposta

✅ Consumo de CPU

✅ Uso de memória

✅ Acesso a disco

✅ Tráfego de rede

✅ Custos de licenciamento

✅ Capacidade futura do ambiente

---

O Que é Performance?

De forma simples:

Performance =
Quantidade de trabalho realizado
÷
Recursos consumidos

Um sistema é considerado eficiente quando consegue processar mais transações utilizando menos recursos.

---

Por Que Performance é Tão Importante?

Em ambientes Mainframe, pequenas melhorias podem representar economias enormes.

Exemplo:

1% de redução de CPU
↓
Menos consumo de MSU
↓
Redução de custos
↓
Economia anual significativa

Por isso, grandes bancos possuem equipes dedicadas exclusivamente à performance.

---

Os Quatro Pilares da Performance

CPU

É o cérebro do Mainframe.

Responsável por executar:

• COBOL

• PL/I

• Java

• CICS

• IMS

• DB2

Exemplo:

CPU = 90%

Pode indicar gargalo.

---

Memória

Armazena programas e dados em execução.

Analisa-se:

• Frames

• Real Storage

• Paging

• Cache

Problemas comuns:

Pouca memória
↓
Paging excessivo
↓
Lentidão

---

I/O (Entrada e Saída)

Envolve:

• Discos

• Storages

• FICON

• VSAM

• DB2

Muitas vezes o gargalo não está na CPU, mas no acesso aos dados.

---

Rede

Hoje os Mainframes estão conectados a:

• APIs

• Cloud

• Mobile

• Open Banking

Logo, performance também envolve:

TCP/IP
OSA
HiperSockets
TLS

---

Conceitos Fundamentais

Tempo de Resposta

Quanto tempo o usuário espera.

Exemplo:

Consulta Saldo
↓
0,3 segundos

Excelente.

---

Throughput

Quantidade de trabalho processado.

Exemplo:

50.000 transações/segundo

---

Latência

Tempo necessário para iniciar uma operação.

Exemplo:

Aplicação
↓
DB2
↓
Resposta

Quanto menor, melhor.

---

Utilização

Percentual de uso de um recurso.

Exemplo:

CPU = 40%

---

Capacidade

Quanto o ambiente suporta antes de saturar.

---

Performance em Batch

Muito importante em Mainframe.

Exemplo:

JOB NOTURNO

Início: 22:00
Fim:    04:00

Objetivo:

22:00
↓
01:30

Menor janela batch.

---

Performance em CICS

Em ambiente online analisa-se:

• Tempo de resposta

• Número de transações

• Esperas

• Locks

Fluxo:

Terminal
↓
CICS
↓
COBOL
↓
DB2

Cada etapa é medida.

---

Performance em DB2

Grande parte dos problemas de performance está no SQL.

Exemplo ruim:

SELECT *
FROM CLIENTES

---

Melhor:

SELECT NOME
FROM CLIENTES
WHERE CPF = ?

---

Aspectos analisados:

• Índices

• Buffer Pools

• Access Path

• Tablespaces

---

Performance em COBOL

Algumas boas práticas:

Evitar Leitura Desnecessária

Ruim:

READ ARQUIVO

milhões de vezes.

---

Carregar Tabelas em Memória

Melhor:

READ UMA VEZ
↓
WORKING-STORAGE

---

Utilizar SEARCH ALL

Mais eficiente que busca sequencial.

---

Reduzir Chamadas ao Banco

Menos SQL significa:

Menos I/O
↓
Mais Performance

---

Principais Gargalos

CPU

Uso excessivo

---

Disco

I/O elevado

---

SQL

Full Table Scan

---

Rede

Latência

---

Aplicação

Loops ineficientes

---

Ferramentas de Performance

RMF

Resource Measurement Facility

Ferramenta nativa do z/OS.

Monitora:

• CPU

• Memória

• I/O

• Rede

---

SMF

System Management Facility

Gera registros estatísticos.

Exemplo:

SMF Type 30
SMF Type 110
SMF Type 101

---

OMEGAMON

Monitoramento em tempo real.

Muito utilizado para:

• CICS

• DB2

• IMS

• z/OS

---

MainView

Solução Broadcom.

---

Capacity Planning

Não basta analisar o presente.

É necessário prever o futuro.

Perguntas comuns:

O ambiente suporta
o crescimento do próximo ano?

---

Avalia:

• CPU

• Memória

• Storage

• Rede

---

MIPS e MSU

MIPS

Million Instructions Per Second

Métrica histórica.

---

MSU

Million Service Units

Mais utilizada atualmente.

---

zIIP e Performance

Os processadores zIIP ajudam a reduzir carga dos CPs.

Executam:

• Java

• XML

• JSON

• DB2

• Analytics

---

Fluxo:

CP
↓
zIIP
↓
Menos CPU

---

Workload Manager (WLM)

Controla prioridades.

Exemplo:

PIX
↓
Alta Prioridade

Relatório
↓
Baixa Prioridade

---

Performance e Cloud

Hoje também envolve:

APIs
OpenShift
Containers
z/OS Connect
LinuxONE

---

O Papel do Analista de Performance

Ele atua como um "médico do Mainframe".

Analisa:

• Sintomas

• Gargalos

• Tendências

• Crescimento

E propõe otimizações.

---

Curiosidade

Muitas das técnicas modernas de observabilidade utilizadas em Cloud Computing possuem origem em conceitos que os profissionais de Mainframe já utilizavam desde as décadas de 1970 e 1980 através de ferramentas como RMF, SMF e monitores de desempenho.

---

Resumo Rápido

Conceito	Objetivo
CPU	Processamento
Memória	Armazenamento temporário
I/O	Acesso a dados
Rede	Comunicação
Throughput	Volume processado
Latência	Tempo de espera
RMF	Monitoramento
SMF	Estatísticas
OMEGAMON	Tempo real
WLM	Priorização
zIIP	Offload de processamento
Capacity Planning	Planejamento futuro

---

Conclusão

Performance em Mainframe é uma disciplina estratégica que busca maximizar a eficiência dos recursos do IBM Z. Ela envolve monitoramento, análise, tuning e planejamento de CPU, memória, I/O, rede, aplicações COBOL, CICS, IMS e DB2. Dominar esses conceitos é fundamental para garantir que ambientes críticos continuem processando milhões de transações com rapidez, estabilidade e o menor custo possível.