Bellacosa Mainframe num mergulho no mundo storage do z/os

🔥 SEUS DADOS NÃO MORAM NO DISCO… ELES VIAJAM PELO UNIVERSO DO z/OS 😳

O guia proibido de Storage Management que revela como memória, disco e sysplex trabalham juntos (e quase ninguém entende)

Você acha que seu dataset “fica no disco”?

👉 Não fica.

No z/OS, dados:

• sobem pra memória
• descem pra disco
• migram pra fita
• aparecem em outro LPAR
• e até existem fora do seu address space

💥 “No mainframe, dado não tem endereço fixo… tem estratégia.”

Se você quer sair do nível “usuário” e pensar como engenheiro de sistema, esse é o mapa completo 👊🔥

---

🧠 1. ADDRESS SPACE — O UNIVERSO DO PROGRAMA

Cada programa roda em um address space isolado.

---

🔥 O que isso significa?

• memória protegida
• ambiente independente
• controle total do sistema

---

💡 Insight

cada address space é um “universo privado”

---

⚡ 2. 64-BIT ADDRESSING — MEMÓRIA INFINITA (QUASE)

Com 64 bits:

👉 até 16 EXABYTES

---

🔥 Evolução histórica

Era	Limite
24-bit	16MB 😱
31-bit	2GB
👉 64-bit	16EB 🤯

---

💡 Tradução Bellacosa

“acabou a desculpa de falta de memória”

---

🧠 Uso real

• Java
• Db2
• middleware
• grandes buffers

---

🧩 3. DAT — A MÁGICA DA TRADUÇÃO

DAT (Dynamic Address Translation):

👉 converte endereço virtual → real

---

🔥 Sem DAT:

• programa quebraria
• memória não funcionaria

---

💡 Tradução

“você nunca acessa memória real diretamente”

---

🧠 4. STORAGE REQUESTS — COMO A MEMÓRIA É PEDIDA

Programas pedem memória via:

• GETMAIN
• STORAGE OBTAIN

---

🔥 O sistema decide:

• onde alocar
• em qual subpool
• com qual proteção

---

💡 Insight

memória é gerenciada, não livre

---

🧱 5. SUBPOOLS — ORGANIZAÇÃO INTERNA

Memória é dividida em:

👉 subpools

---

🔥 Exemplos:

• SP0 → sistema
• SP229 → usuário

---

💡 Tradução

“cada tipo de dado tem seu bairro”

---

🌍 6. DATA SPACES & HIPERSPACES — FORA DO ADDRESS SPACE

🔹 Data Spaces

• dados fora do address space
• acessados via AR

---

🔹 Hiperspaces

• alta performance
• acesso indireto

---

🔥 Tradução Bellacosa

“memória extra fora do seu universo”

---

🧠 Exemplo

Programa → usa Data Space → grande volume de dados

---

⚡ 7. PAGING — QUANDO A MEMÓRIA NÃO CABE

Se falta memória:

👉 dados vão para disco (paging)

---

🔥 Fluxo

Memória cheia
 ↓
página vai para DASD
 ↓
quando necessário → volta

---

💡 Problema

👉 excesso de paging = sistema lento 💀

---

💾 8. FLASH STORAGE — O TURBO MODERNO

Flash (SSD):

• baixa latência
• alta velocidade
• ideal para OLTP

---

💡 Uso

• Db2
• logs
• datasets críticos

---

🔗 9. PARALLEL SYSPLEX — MEMÓRIA COMPARTILHADA ENTRE SISTEMAS

Aqui fica poderoso 😄

---

🔥 O que é?

Vários z/OS trabalhando juntos:

👉 como um só sistema

---

💡 Elementos:

• LPARs
• Coupling Facility (CF)
• links de comunicação

---

🧠 Exemplo

LPAR A → acessa dado
LPAR B → acessa o mesmo dado

---

💡 Tradução

“dados compartilhados em tempo real”

---

🧠 10. COUPLING FACILITY (CF) — O CÉREBRO COMPARTILHADO

🔹 Função:

• lock management
• cache
• filas

---

🔥 Tipos:

• Internal CF
• External CF

---

💡 Tradução Bellacosa

“CF = memória compartilhada do sysplex”

---

⚡ 11. DUPLEXING — ZERO PERDA

🔥 O que faz?

• duplica dados
• garante disponibilidade

---

💡 Exemplo

CF primário → falha
CF secundário → assume

---

🧨 Curiosidade

Sistema continua rodando sem impacto 😳

---

🧠 12. CF OPERATIONS — O QUE ACONTECE POR TRÁS

CF gerencia:

• locks
• buffers
• filas

---

💡 Uso real

• Db2 data sharing
• CICS
• IMS

---

⚙️ 13. STORAGE + I/O + CPU — TUDO CONECTADO

Nada funciona isolado:

Memória → I/O → CPU → WLM → Storage

---

💡 Insight

performance é resultado do conjunto

---

🔄 14. PASSO A PASSO COMPLETO

Programa inicia
 ↓
recebe address space
 ↓
pede memória (GETMAIN)
 ↓
DAT traduz endereço
 ↓
usa data space se necessário
 ↓
paging ocorre se faltar memória
 ↓
dados vão para disco/flash
 ↓
sysplex compartilha dados via CF
 ↓
duplex garante disponibilidade

---

🧨 CURIOSIDADES (NÍVEL ROOT)

🤯 1. Você não controla diretamente onde o dado está

---

🔥 2. Dados podem estar fora do seu address space

---

💀 3. Paging excessivo mata performance

---

🧠 4. Sysplex permite vários sistemas compartilharem dados

---

⚡ 5. CF é o segredo da alta disponibilidade

---

🎯 RESUMO FINAL

✔ Address space = isolamento

✔ 64-bit = escala absurda

✔ DAT = tradução

✔ Subpools = organização

✔ Data space = expansão

✔ Paging = fallback

✔ Flash = velocidade

✔ Sysplex = escala

✔ CF = coordenação

✔ Duplexing = resiliência

---

💥 FRASE FINAL

“No z/OS, dados não ficam armazenados… eles são orquestrados entre memória, disco e múltiplos sistemas em tempo real.”

 

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

Road Map para Aprender Mainframe

O que um jovem padawan deve aprender para ser um especialista na Stack Mainframe. Um caminho com inúmeras possibilidades, requer esforço e dedicação, porém os frutos condizem ao esforço. Descubra o z/OS, codifique em COBOL, crie queries no SQL DB2 e vá além. #ibm #mainframe #cobol #cics #db2 #jcl #sdsf #qsam #vsam #query #sql #etl #jobs #procs #jes2 #lpar #sysplex

🔥 Conhecimento básico sobre aplicações distribuídas – um guia para mainframers que sobreviveram ao monólito

 🔥 Conhecimento básico sobre aplicações distribuídas – um guia para mainframers que sobreviveram ao monólito

---

1️⃣ Introdução: quando o monólito saiu da jaula

Mainframer raiz conhece bem o monólito confiável: CICS firme, DB2 consistente, batch noturno pontual como relógio suíço. Durante décadas, aplicação distribuída era vista como “coisa de Unix instável” ou “modinha client-server”.

Mas o mundo girou. A web cresceu, o mobile explodiu, a nuvem virou padrão e, de repente, o monólito começou a ser fatiado em serviços. Nasciam as aplicações distribuídas — e com elas, novos problemas… e velhos conceitos que o mainframe já conhecia muito bem.

💡 Easter egg: se você já lidou com VTAM, MQSeries e sysplex, você já entendeu aplicações distribuídas… só não sabia o nome moderno disso.

---

2️⃣ O que são aplicações distribuídas (sem buzzword)

Uma aplicação distribuída é aquela em que:

• O processamento ocorre em vários nós

• Cada parte da aplicação pode rodar em máquinas, containers ou regiões diferentes

• A comunicação acontece por rede, não por memória compartilhada

Exemplos modernos:

• Microservices em Kubernetes

• APIs REST + filas (Kafka, MQ, RabbitMQ)

• Frontend web → backend → banco → cache → serviços externos

No fundo, é o velho conceito de desacoplamento, agora amplificado.

---

3️⃣ Paralelos diretos com o mundo mainframe 🧠

Mundo Mainframe	Mundo Distribuído
CICS Transaction	Microservice
MQSeries	Event Streaming
Sysplex	Cluster
SMF / RMF	Telemetria / Observabilidade
Abend	Exception distribuída
Batch encadeado	Pipelines assíncronos

👉 Conclusão Bellacosa: mainframers não estão atrasados — estão adiantados há 30 anos.

---

4️⃣ Principais desafios (spoiler: não são novos)

🔹 Latência

No mainframe, o gargalo era I/O.
No distribuído, é rede + serialização + hops excessivos.

🔹 Falhas parciais

No mundo distribuído:

“Se algo pode falhar, vai falhar, mas só um pedaço.”

Isso lembra:

• Regiões CICS indisponíveis

• LPAR isolada

• Subsystem down às 03:12 😈

🔹 Consistência

Aqui entra o famoso CAP Theorem — mas mainframer chama isso de:

“Escolher entre disponibilidade e integridade quando o caldo entorna.”

---

5️⃣ Conceitos essenciais que todo mainframer deve dominar

✔️ Comunicação síncrona vs assíncrona

• Síncrona: REST, RPC (espera resposta)

• Assíncrona: filas, eventos, fire-and-forget
  👉 MQ old school total.

✔️ Escalabilidade horizontal

• Escalar mais instâncias, não máquinas maiores
  (trauma de quem pedia upgrade de MIPS aprovado em comitê 😅)

✔️ Observabilidade

• Logs

• Métricas

• Traces distribuídos

📌 Curiosidade: SMF foi o avô do tracing moderno.

---

6️⃣ Passo a passo mental para entender qualquer sistema distribuído

1️⃣ Identifique quais serviços existem
2️⃣ Veja como eles se comunicam
3️⃣ Descubra onde estão os pontos de falha
4️⃣ Analise latência e dependências
5️⃣ Verifique quem é o dono do dado
6️⃣ Observe como o sistema se comporta quando algo cai

🧨 Dica Bellacosa: desligue mentalmente um serviço e pergunte
“O que quebra primeiro?”

---

7️⃣ Guia de estudo para mainframers curiosos 📚

Conceitos

• Microservices vs Monólito

• Event-driven architecture

• Observabilidade

• Resiliência e retries

Ferramentas modernas (com alma antiga)

• Instana / Dynatrace → RMF da nuvem

• Prometheus → SMF open source

• Kafka → MQSeries com esteroides

• Kubernetes → Sysplex com YAML

---

8️⃣ Aplicações práticas no dia a dia

• Integrar mainframe com APIs modernas

• Expor transações CICS como serviços

• Monitorar ambientes híbridos

• Diagnosticar falhas ponta a ponta

• Atuar como tradutor cultural entre legado e cloud

🎯 Mainframer que entende distribuído vira peça-chave.

---

9️⃣ Comentário final (meia-noite, café frio ☕)

Aplicações distribuídas não são o fim do mainframe.
São apenas o mesmo problema antigo, rodando em mais lugares, com nomes novos e menos disciplina.

Quem sobreviveu a:

• Batch quebrado em fechamento

• Deadlock às 02h

• Região CICS instável em dia útil

…tem todas as credenciais para dominar o mundo distribuído.

🖤 El Jefe Midnight Lunch aprova:
legado não é atraso — é memória de guerra.