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.”

 

Bellacosa Mainframe cobrança de uso do mainframe mips msu e 4hra

🔥💣 MIPS, MSU E 4HRA: O “RELÓGIO NUCLEAR” DO MAINFRAME — COMO A IBM TRANSFORMOU PODER DE PROCESSAMENTO EM MOEDA CORPORATIVA 💣🔥

“No mundo distribuído você compra servidor.
No Mainframe… você compra TEMPO DE CPU.”

Existe um momento na carreira de todo programador COBOL sênior em que ele percebe uma verdade brutal:

O código não roda sozinho.

Ele gera CUSTO.

E no universo IBM Z, custo tem nome, sobrenome e décadas de engenharia financeira:

• MIPS
• MSU
• R4HA / 4HRA
• SCRT
• Sub-Capacity Billing
• Capacity Planning

Sim…
o batch que você escreveu.
o SORT gigantesco.
o LOOP mal otimizado.
o SQL sem índice.
o programa COBOL que explode CPU em fim de mês…

Tudo isso pode literalmente alterar a fatura milionária de um datacenter.

Bem-vindo ao lado invisível do Mainframe:

A ECONOMIA DA CPU.

---

☕ Antes de Tudo: O Que São MIPS?

MIPS

“Million Instructions Per Second”

O termo nasceu nos anos 1970/1980 como tentativa de medir poder computacional.

A ideia parecia simples:

“Quantas milhões de instruções a máquina executa por segundo?”

Mas havia um problema gigantesco:

Nem toda instrução custa igual.

Uma instrução pode:

• mover bytes
• fazer I/O
• executar decimal arithmetic
• chamar microcode
• acessar cache
• disparar canal

Resultado:

MIPS virou referência comercial… não técnica.

Mesmo assim o mercado adotou o termo como linguagem universal de capacidade computacional.

---

🚀 O NASCIMENTO DO MSU

A IBM percebeu rapidamente que “MIPS” era impreciso demais para cobrança.

Então criou o:

MSU

Million Service Units

A partir dos anos 1980/1990, o MSU virou o padrão comercial IBM para:

• licensing
• software pricing
• capacidade
• contratos
• cobrança de software
• sub-capacity billing

---

🧠 Quem Criou o Conceito?

Não existe um “inventor único” formal do MSU como há em linguagens de programação.

O conceito surgiu internamente na IBM como evolução dos modelos de medição de capacidade do System/370 e ESA/390.

A consolidação comercial aconteceu fortemente na década de 1990.

---

📅 Linha do Tempo Histórica

Ano	Evento
1964	IBM System/360 nasce
1970s	Mercado começa a usar MIPS
1980s	IBM cria modelos de Service Units
1990s	MSU vira padrão de licensing
1999	IBM introduz Sub-Capacity Pricing
2000s	SCRT automatiza relatórios
2000s	R4HA vira base de cobrança
Hoje	Tudo continua girando em MSU

---

💣 O QUE É 4HRA / R4HA?

Aqui começa a parte que faz gerente de infraestrutura perder o sono.

R4HA

Rolling 4-Hour Average

ou popularmente:

4HRA

A IBM percebeu que cobrar pico instantâneo seria injusto.

Então criou um modelo mais “suave”:

---

☕ Como Funciona?

O sistema mede uso de CPU continuamente.

Depois calcula:

A média móvel das últimas 4 horas.

O maior valor encontrado no mês:

vira referência de cobrança.

Sim…
UM pico monstruoso pode impactar o mês inteiro.

---

🔥 Exemplo Realista

Imagine:

Horário	Uso
08h	400 MSU
09h	500 MSU
10h	650 MSU
11h	900 MSU
12h	850 MSU

O R4HA pode disparar absurdamente.

Resultado:

aumento de licensing.

---

💣 O DIA EM QUE O COBOL VIROU FINANCEIRO

Muitos programadores COBOL descobrem tarde demais:

CPU = dinheiro.

Exemplos clássicos:

• SORT desnecessário
• READ sequencial gigante
• PERFORM UNTIL infinito
• SQL sem índice
• tabelas carregadas em memória
• loops com string manipulation
• COMP-3 mal utilizado
• decimal arithmetic excessiva

Um único batch pode:

• aumentar R4HA
• elevar custo mensal
• gerar war room operacional

---

🚀 O MAINFRAME NÃO COBRA HARDWARE…

ELE COBRA PICO

Essa é a genialidade — e crueldade — do modelo IBM.

O cliente não paga apenas:

• máquina
• memória
• storage

Ele paga:

capacidade consumida.

---

☕ SURGE O SUB-CAPACITY BILLING

Nos anos 1990/2000 surgiu uma revolução:

Sub-Capacity Pricing

Antes:
software era cobrado pela capacidade TOTAL da máquina.

Depois:
passou a cobrar apenas LPARs usadas.

Isso salvou bilhões para clientes IBM Z.

---

🧠 SCRT — O “LEÃO DA RECEITA FEDERAL” DO z/OS

SCRT

Sub-Capacity Reporting Tool

Ferramenta IBM usada para:

• gerar relatórios
• medir consumo
• validar licensing
• produzir auditoria

Ela virou peça obrigatória no ecossistema IBM Z.

---

💣 CURIOSIDADE ABSURDA

Muitos bancos possuem:

• equipes de performance
• capacity planners
• especialistas WLM
• analistas RMF

cuja função principal é:

evitar aumento de R4HA.

Sim…
existem profissionais dedicados exclusivamente a impedir picos de CPU.

---

🔥 WLM: O “CONTROLADOR DE TRÁFEGO” DA CPU

O:

Workload Manager (WLM)

decide:

• prioridades
• classes de serviço
• distribuição de CPU
• importância de workloads

Ele é essencial para:

• evitar estouro de MSU
• controlar picos
• proteger SLAs

---

🚀 EXEMPLO COBOL QUE PODE VIRAR DESASTRE

PERFORM UNTIL EOF
   READ ARQ
      AT END
         MOVE 'S' TO EOF
      NOT AT END
         PERFORM PROCURA-TABELA
END-PERFORM

Agora imagine:

• tabela sem SEARCH ALL
• milhões de registros
• batch concorrente
• fechamento mensal

BOOM:

CPU explode.

---

☕ OTIMIZAÇÃO COBOL = ECONOMIA REAL

No Mainframe:

performance não é vaidade.

É orçamento corporativo.

Por isso surgiram:

• tuning specialists
• CPU optimization
• DB2 access path analysis
• zIIP offloading
• assembler tuning

---

🔥 zIIP: O “PARAÍSO FISCAL” DO MAINFRAME

zIIP

IBM Z Integrated Information Processor

CPU especial criada para:

• reduzir custo de licensing
• descarregar workload

Workloads elegíveis:

• DB2
• XML
• Java
• IPSec
• z/OS Connect
• 일부 sort
• analytics

Quando workload vai para zIIP:

muitas vezes não entra na conta principal de MSU.

Sim…
é quase uma engenharia tributária computacional.

---

💣 EASTER EGG DO MUNDO IBM Z

Existe uma piada clássica entre sysprogs:

“O usuário acha que CPU nasce na parede.”

Outra:

“Batch ruim não derruba sistema. Derruba orçamento.”

---

☕ VANTAGENS DO MODELO IBM

✅ Justiça proporcional

Quem usa mais, paga mais.

✅ Escalabilidade gigantesca

Permite crescer sem trocar arquitetura.

✅ Controle refinado

WLM + RMF + SCRT oferecem precisão absurda.

✅ Confiabilidade

Modelo maduro há décadas.

✅ Incentiva otimização

Empresas investem em engenharia de performance.

---

💣 DESVANTAGENS

❌ Complexidade extrema

Pouca gente realmente entende R4HA.

❌ Licenciamento caro

Especialmente software third-party.

❌ Pico pode custar fortuna

Um batch mal planejado pode impactar o mês.

❌ Dependência de especialistas

Capacity planning é quase uma ciência.

---

🚀 O PARADOXO DO MAINFRAME

Quanto mais eficiente o sistema:

menos ele custa.

Por isso COBOL sênior ainda é tão valorizado.

Porque um veterano:

• entende I/O
• entende CPU
• entende paging
• entende VSAM
• entende DB2
• entende JCL
• entende SORT
• entende batch window

E principalmente:

entende impacto financeiro invisível.

---

☕ O QUE O PROGRAMADOR MODERNO NÃO PERCEBE

No mundo cloud:

• desperdiça CPU
• sobe container
• cria pod
• escala horizontalmente

No Mainframe:

eficiência é cultura ancestral.

Cada instrução conta.

Cada I/O importa.

Cada SQL pode custar dinheiro REAL.

---

🔥 O MAINFRAME TRANSFORMOU PERFORMANCE EM ECONOMIA

E talvez essa seja uma das maiores genialidades da IBM.

Ela criou um ecossistema onde:

• arquitetura
• software
• performance
• negócio
• finanças

viraram uma coisa só.

O COBOL deixou de ser apenas linguagem.

Virou ferramenta de gestão financeira operacional.

E no fim…
o verdadeiro poder do programador sênior não é fazer o programa funcionar.

É fazê-lo funcionar consumindo MENOS CPU.

Porque no IBM Z:

eficiência vale ouro.