Translate

Mostrar mensagens com a etiqueta rmf. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta rmf. Mostrar todas as mensagens

quinta-feira, 28 de maio de 2026

☕🔥💣 CHECKLIST DEFINITIVO DE RCA PARA O SYSprog PADAWAN

Bellacosa Mainframe apresenta um checklist de RCA para sysprog junior


☕🔥💣 CHECKLIST DEFINITIVO DE RCA PARA O SYSprog PADAWAN

Como Evoluir de Apagador de Incêndios para Caçador de Causas Raiz

A maioria dos Sysprogs juniores aprende primeiro a resolver incidentes.

Poucos aprendem a impedir que eles aconteçam novamente.

O objetivo deste checklist é desenvolver a mentalidade de investigação que transforma um operador técnico em um verdadeiro engenheiro de confiabilidade.


🔍 NÍVEL 1 — FUNDAMENTOS DO INVESTIGADOR

Conhecer a arquitetura do ambiente

☐ Entender o fluxo completo da aplicação

☐ Conhecer as LPARs existentes

☐ Entender Sysplex

☐ Conhecer JES2/JES3

☐ Entender CICS

☐ Entender DB2

☐ Entender MQ

☐ Conhecer Storage Management

☐ Entender WLM

☐ Conhecer SDSF profundamente

Objetivo

Parar de enxergar componentes isolados e começar a enxergar o ecossistema.


📋 NÍVEL 2 — COLETA DE EVIDÊNCIAS

Antes de agir:

☐ Registrar horário exato do incidente

☐ Identificar quem reportou

☐ Verificar impacto

☐ Capturar mensagens de erro

☐ Salvar logs

☐ Salvar SYSLOG

☐ Salvar JESMSGLG

☐ Salvar JESJCL

☐ Salvar JESYSMSG

☐ Registrar alterações recentes

☐ Verificar deploys recentes

Regra de ouro

Nunca altere o ambiente antes de coletar evidências.


🔥 NÍVEL 3 — ANÁLISE JES2

☐ Verificar initiators

☐ Verificar classes

☐ Verificar backlog

☐ Verificar spool

☐ Verificar HOLDs

☐ Verificar jobs looping

☐ Verificar jobs aguardando recursos

☐ Verificar ENQ contention

☐ Verificar mensagens $HASP

Pergunta obrigatória

O problema começou no JES2 ou chegou até ele?


💾 NÍVEL 4 — STORAGE E MEMÓRIA

☐ Verificar CSA

☐ Verificar ECSA

☐ Verificar SQA

☐ Verificar ESQA

☐ Verificar Private Area

☐ Procurar storage leaks

☐ Analisar crescimento anormal

☐ Verificar mensagens IEA e IEF

☐ Consultar RMF

Atenção

Muitos "problemas de sistema" são apenas vazamentos de memória.


⚡ NÍVEL 5 — PERFORMANCE

☐ Verificar CPU

☐ Verificar I/O

☐ Verificar Paging

☐ Verificar DASD

☐ Verificar Coupling Facility

☐ Verificar WLM

☐ Verificar gargalos

☐ Comparar com baseline

☐ Analisar tendências

Objetivo

Entender se a degradação é sintoma ou causa.


🖥️ NÍVEL 6 — RCA EM CICS

☐ Verificar transações lentas

☐ Verificar tasks pendentes

☐ Verificar Short On Storage

☐ Verificar TD Queues

☐ Verificar TS Queues

☐ Verificar DB2 Attach

☐ Verificar MQ Attach

☐ Verificar abends

☐ Verificar dumps

☐ Analisar traces

Nunca conclua

"CICS está lento"

sem descobrir:

"POR QUE está lento?"


🗄️ NÍVEL 7 — RCA EM DB2

☐ Verificar deadlocks

☐ Verificar lock escalation

☐ Verificar SQLCODEs

☐ Verificar buffer pools

☐ Verificar índices

☐ Procurar full table scan

☐ Verificar RUNSTATS

☐ Verificar REORG pendente

☐ Verificar crescimento de tabelas

Regra

Muitos problemas de CICS são, na verdade, problemas de DB2.


📬 NÍVEL 8 — RCA EM MQ

☐ Verificar Queue Depth

☐ Verificar canais

☐ Verificar backlog

☐ Verificar consumidores

☐ Verificar produtores

☐ Verificar DLQ

☐ Verificar mensagens presas

☐ Verificar timeouts

Lembre-se

Fila cheia normalmente é consequência.

Raramente é a causa raiz.


📊 NÍVEL 9 — OBSERVABILIDADE

☐ Utilizar OMEGAMON

☐ Utilizar RMF

☐ Utilizar SMF

☐ Utilizar NetView

☐ Utilizar Sysview

☐ Criar dashboards

☐ Definir baseline

☐ Identificar anomalias

☐ Correlacionar eventos

Meta

Parar de reagir.

Começar a prever.


🔎 NÍVEL 10 — TÉCNICAS DE INVESTIGAÇÃO

Five Whys

☐ Aplicar os 5 Porquês


Timeline Analysis

☐ Construir linha do tempo


Event Correlation

☐ Correlacionar eventos


Impact Analysis

☐ Medir impacto real


Trend Analysis

☐ Procurar recorrência


🤖 NÍVEL 11 — AUTOMAÇÃO E PREVENÇÃO

☐ Automatizar alertas

☐ Automatizar coleta de evidências

☐ Automatizar correções simples

☐ Criar scripts REXX

☐ Criar procedimentos de recuperação

☐ Integrar com SA z/OS

☐ Integrar com NetView

☐ Criar runbooks

Objetivo

Não resolver mais rápido.

Resolver menos vezes.


📚 NÍVEL 12 — CONHECIMENTO HISTÓRICO

☐ Manter base de incidentes

☐ Documentar RCA

☐ Criar Wiki interna

☐ Registrar lições aprendidas

☐ Catalogar soluções

☐ Criar biblioteca de dumps

☐ Registrar padrões recorrentes

Ouro do Sysprog

Experiência documentada vale mais que memória.


🧠 NÍVEL 13 — MENTALIDADE DE MESTRE

Antes de qualquer ação pergunte:

☐ O que aconteceu?

☐ Quando aconteceu?

☐ Quem foi impactado?

☐ O que mudou?

☐ Isso já aconteceu antes?

☐ O que os logs mostram?

☐ O que os dados mostram?

☐ Estou tratando sintoma ou causa?

☐ Como impedir recorrência?

☐ O que aprendi hoje?


🏆 CHECKLIST FINAL DO SYSprog MESTRE

Quando um incidente ocorrer:

❌ Não reinicie imediatamente

❌ Não assuma conclusões

❌ Não culpe usuários

❌ Não culpe desenvolvedores

❌ Não culpe infraestrutura

✅ Colete evidências

✅ Analise dados

✅ Correlacione eventos

✅ Pergunte "por quê?"

✅ Encontre a causa raiz

✅ Elimine a recorrência

✅ Documente a descoberta

✅ Compartilhe conhecimento


☕ Regra Suprema do Bellacosa Mainframe

"O Padawan reinicia o CICS.

O Sysprog investiga o dump.

O Mestre encontra a causa raiz.

O Arquiteto faz o problema desaparecer para sempre." 🚀💣🔥

 

segunda-feira, 11 de maio de 2026

🔥💣 “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.

 

quarta-feira, 6 de maio de 2026

🔥☕ COUPLING FACILITY — O “CÉREBRO COLETIVO” DOS MAINFRAMES IBM z/OS ☕🔥

Bellacosa Mainframe mergulha no sysplex e comenta sobre CF coupling facility

🔥☕ COUPLING FACILITY — O “CÉREBRO COLETIVO” DOS MAINFRAMES IBM z/OS ☕🔥

O QUE TODO PROGRAMADOR COBOL PADAWAN PRECISA ENTENDER SOBRE O CORAÇÃO DO SYSPLEX

Imagine o seguinte cenário, jovem Padawan do COBOL:

Você possui:

  • vários mainframes IBM zSeries
  • executando o mesmo sistema z/OS
  • compartilhando banco Db2
  • compartilhando filas CICS
  • compartilhando cache
  • compartilhando locks
  • compartilhando discos DASD

…e todos precisam conversar em tempo real sem virar caos.

🔥 É aí que nasce a Coupling Facility (CF).


☕ O QUE É A COUPLING FACILITY?

A Coupling Facility é um componente especializado do ambiente IBM Parallel Sysplex.

Ela funciona como:

  • memória compartilhada ultra rápida
  • coordenador de sincronismo
  • gerenciador de locks
  • cache compartilhado
  • controlador de estruturas compartilhadas

Pense nela como:

“o cérebro central que sincroniza vários mainframes ao mesmo tempo.”


🏛 ORIGEM HISTÓRICA

A IBM criou o conceito nos anos 90 para resolver um problema gigantesco:

❌ Problema antigo

Antes do Parallel Sysplex:

  • cada mainframe era praticamente isolado
  • escalabilidade era limitada
  • failover era complicado
  • compartilhamento de dados era lento

✅ Solução IBM

Criaram:

IBM Parallel Sysplex

com:

  • múltiplos LPARs
  • múltiplos z/OS
  • múltiplos CICS
  • múltiplos Db2
  • tudo operando como “um único supercomputador”.

E a Coupling Facility virou o coração disso tudo.


🧠 ANALOGIA ESTILO BELLACOSA

Imagine:

ElementoMundo Real
z/OSpessoas trabalhando
Db2arquivos/documentos
CICSatendentes
Coupling Facilitycentral de coordenação
Lock Structuresemáforo
Cache Structurememória compartilhada
List Structurefila organizada

🔥 O QUE A COUPLING FACILITY FAZ?

Ela trabalha principalmente com:

EstruturaFunção
Lock Structurecontrole de locks
Cache Structurecache compartilhado
List Structurefilas/listas
Serializationsincronismo
Signalingcomunicação entre sistemas

🔷 TIPOS DE ESTRUTURA

1️⃣ LOCK STRUCTURE

Usada por:

  • Db2
  • GRS
  • CICS

Ela evita:

  • deadlock
  • update simultâneo
  • corrupção de dados

2️⃣ CACHE STRUCTURE

Mantém dados em memória compartilhada.

Exemplo:

  • buffer pools do Db2
  • cache CICS
  • VSAM RLS

Isso reduz I/O em disco absurdamente.


3️⃣ LIST STRUCTURE

Funciona como fila compartilhada.

Muito usada em:

  • WebSphere MQ
  • CICS TS Queue
  • Workload balancing

⚡ COMO FUNCIONA NA PRÁTICA

Imagine dois Db2:

SistemaAção
DB2Aatualiza cliente
DB2Btenta ler mesmo cliente

A CF entra no meio:

  1. DB2A pega lock
  2. CF registra lock
  3. DB2B consulta CF
  4. CF responde:
    • “registro bloqueado”
  5. DB2B espera

🔥 Resultado:
consistência total.


🏗 COMPONENTES IMPORTANTES

ComponenteDescrição
CFRMCoupling Facility Resource Management
XCFCross-system Coupling Facility
IXLCONNconecta aplicações
IXLLISTmanipula listas
IXLCACHEcache compartilhado
IXLLOCKlock manager

🔥 XCF — O “WHATSAPP” DOS MAINFRAMES

O XCF:

  • conecta sistemas do sysplex
  • troca mensagens
  • detecta falhas
  • coordena membros

Sem XCF:
❌ não existe sysplex moderno.


📦 ONDE A CF EXISTE?

Pode existir:

TipoDescrição
Internal CFdentro do próprio CPC
External CFmáquina dedicada
Integrated CF (ICF)processador especializado

🧩 COMO O COBOL JÚNIOR “SENTE” A CF?

Mesmo sem perceber…

você usa CF quando:

  • roda Db2 Data Sharing
  • acessa CICS em sysplex
  • usa VSAM RLS
  • usa MQ Shared Queue

Ou seja:

🔥 praticamente todo ambiente enterprise moderno.


🔎 COMO VER INFORMAÇÕES DA CF?

COMANDO D XCF

D XCF,CF

Mostra:

  • CFs ativas
  • status
  • conectividade
  • estruturas

🔎 LISTAR ESTRUTURAS

D XCF,STR

🔎 VER SYSLEX

D XCF,SYSPLEX

🔎 NO SDSF

Painéis:

PainelUso
RMFperformance
SDSF LOGmensagens
DAdevices
ENCenclosures

📊 MONITORAMENTO

Ferramentas clássicas:

FerramentaUso
RMF Monitor IIIperformance CF
OMEGAMONanálise avançada
IBM Tivolimonitoramento
SMF 74métricas da CF

🔥 SMF 74 — O TESOURO ESCONDIDO

O record:

SMF Type 74

guarda:

  • uso de estruturas
  • tempo de resposta
  • lock contention
  • taxa de requests
  • rebuilds

Subtipos importantes:

SubtypeUso
74-4CF Activity
74-5CF Cache
74-7Lock info

🔥 COMANDOS IMPORTANTES

VER DETALHES

D XCF,CF,CFNAME=CF01

VER ESTRUTURA

D XCF,STR,STRNAME=DB2LOCK1

REBUILD

SETXCF START,REBUILD,STRNAME=DB2LOCK1

⚠️ ERROS CLÁSSICOS

1️⃣ STRUCTURE FULL

Mensagem:

IXL015I STRUCTURE FULL

Significa:

  • estrutura sem espaço
  • excesso de locks/cache/lista

COMO ANALISAR

Ver:

D XCF,STR

Checar:

  • INITSIZE
  • SIZE
  • uso %

CORREÇÃO

Aumentar no CFRM Policy:

SIZE(50000)

2️⃣ REBUILD PENDING

Estrutura precisa rebuild.

Causas:

  • falha CF
  • perda conectividade
  • overload

CORREÇÃO

SETXCF START,REBUILD

3️⃣ PATH FAILURE

Links ICA/IFB falhando.

Pode causar:

  • degradação
  • perda de sincronismo

VERIFICAR

D XCF,PATH

4️⃣ LOCK CONTENTION

Db2 “travando tudo”.

Sintomas:

  • timeout
  • deadlock
  • lentidão

ANALISAR

  • IFCID 172
  • IFCID 196
  • RMF
  • DISPLAY DATABASE LOCKS

🧠 COMO INTERPRETAR PERFORMANCE

Indicadores importantes

MétricaSignificado
Request Raterequisições
Service Timelatência
Lock Contentiondisputa
Rebuild Countrebuilds
CF CPUuso CPU

🔥 LATÊNCIA É TUDO

No sysplex:

microsegundos importam.

Porque:

  • Db2 faz milhões de requests
  • CICS faz milhares por segundo
  • MQ sincroniza filas

Se a CF atrasar:
🔥 o sysplex inteiro sofre.


⚡ CURIOSIDADES ABSURDAS

🔥 A CF NÃO RODA z/OS

Ela roda firmware especializado.

É quase um “mini sistema operacional secreto IBM”.


🔥 UMA CF PODE CONTROLAR VÁRIOS MAINFRAMES

Grandes bancos possuem:

  • dezenas de LPARs
  • múltiplas CFs
  • sysplex gigantescos

🔥 EXISTE FAILOVER DE CF

Se uma CF morrer:

outra assume.

Isso é chamado:

Duplexing / Rebuild


🥚 EASTER EGGS MAINFRAME

🥚 O nome “Coupling”

Vem da engenharia mecânica:

coupling = acoplamento

Ela “acopla” sistemas.


🥚 O sysplex já foi considerado “cloud antes da cloud”

Porque:

  • compartilhava recursos
  • balanceava carga
  • permitia failover automático

Anos antes da computação em nuvem moderna.


🔥 EXEMPLO REAL — DB2 DATA SHARING

Imagine:

SistemaTransações
DB2Ainternet banking
DB2BPIX
DB2CATM
DB2Dcartão

Todos compartilham:

  • mesmos dados
  • mesmos locks
  • mesmo cache

Tudo coordenado pela CF.

Sem ela:
💥 corrupção total.


🛠 PASSO A PASSO PARA INVESTIGAR PROBLEMAS

ETAPA 1 — Verificar estruturas

D XCF,STR

ETAPA 2 — Verificar CF

D XCF,CF

ETAPA 3 — Verificar paths

D XCF,PATH

ETAPA 4 — Analisar RMF

Ver:

  • latency
  • request rate
  • rebuild

ETAPA 5 — Verificar mensagens

No SDSF LOG:

Procure:

IXL
IXC
CF

ETAPA 6 — Verificar Db2

Comandos:

-DISPLAY GROUP
-DISPLAY DATABASE LOCKS

☕ RESUMO BELLACOSA MAINFRAME

Coupling Facility é:

✅ o coração do Parallel Sysplex
✅ sincronismo ultra rápido
✅ lock manager distribuído
✅ cache compartilhado
✅ coordenador do Db2 Data Sharing
✅ base do CICS moderno
✅ peça crítica da alta disponibilidade IBM


🔥 FRASE FINAL DO PADAWAN MAINFRAME

“Quando vários mainframes parecem um só…
existe uma Coupling Facility trabalhando silenciosamente nos bastidores.” ☕🔥

sábado, 11 de abril de 2026

💣 VSAM LENTO? NÃO É O MAINFRAME — É O SEU TUNING! 🔥 Os Segredos de Performance que Ninguém Te Conta

 

Bellacosa Mainframe VSAM lento tuning IDCAMS e outros segredinhos

💣 VSAM LENTO? NÃO É O MAINFRAME — É O SEU TUNING! 🔥 Os Segredos de Performance que Ninguém Te Conta

🧠 1) Escolha o tipo correto de arquivo VSAM

📌 Tradução

O VSAM suporta quatro tipos principais de datasets:

  • ESDS (Entry-Sequenced Data Set) → acesso sequencial
  • KSDS (Key-Sequenced Data Set) → acesso por chave
  • RRDS (Relative Record Data Set) → acesso direto por número relativo
  • LDS (Linear Data Set) → armazenamento bruto (usado por DB2, etc.)

Cada tipo possui características diferentes e deve ser escolhido conforme o padrão de acesso aos dados.


💬 Comentário Bellacosa

Aqui está o primeiro erro clássico de projeto:

❌ “Vou usar KSDS pra tudo porque é mais completo”

👉 Resultado: I/O desnecessário, split, CI/CA fragmentation, e performance indo pro ralo.


🧪 Exemplo prático

✔ Caso ideal:

  • Batch sequencial (ex: faturamento diário)
    ESDS ganha disparado
  • Sistema online CICS com lookup por chave
    KSDS obrigatório
  • Tabela indexada por posição fixa
    RRDS simplifica tudo

🚀 Dica avançada (pouco falada)

Se seu acesso for altamente randômico:

👉 Combine:

  • KSDS
    • SMB + ACCBIAS=DO (Direct Optimized)

Isso muda o jogo de performance.


🧠 2) Otimização de buffers

📌 Tradução

Buffers são áreas de memória usadas para armazenar dados temporariamente durante operações VSAM.

  • Poucos buffers → excesso de I/O
  • Muitos buffers → desperdício de CPU/memória

💬 Comentário Bellacosa

Aqui mora um dos maiores gargalos invisíveis:

VSAM não é lento…
VSAM mal bufferizado é lento.


🧪 Exemplo prático (JCL)

//DD1 DD DSN=SEU.VSAM.KSDS,
// AMP=('BUFND=20','BUFNI=10')
  • BUFND → buffers de dados
  • BUFNI → buffers de índice

🧠 Regra de ouro

Tipo de acessoAjuste
SequencialBUFND alto
RandômicoBUFNI mais importante

🚀 Nível PRO (SMB tuning)

AMP=('ACCBIAS=DO','SMB')
  • DO → acesso randômico otimizado
  • SO → sequencial
  • SW/DW → dinâmico

💣 Isso pode reduzir I/O drasticamente.


🧠 3) Minimizar tamanho de registro

📌 Tradução

O tamanho do registro influencia diretamente:

  • Quantidade de blocos
  • Uso de buffer
  • Transferência de dados

💬 Comentário Bellacosa

Esse é clássico de legado:

“Ah, deixa esse campo aqui... vai que um dia usam”

👉 Resultado:

  • Records inflados
  • CI mal aproveitado
  • Mais EXCP

🧪 Exemplo

❌ Ruim:

Cliente:
- Nome (100 bytes)
- Código (10)
- 20 campos não usados

✔ Melhor:

Cliente:
- Nome (40)
- Código (10)

🚀 Técnicas avançadas

  • Compressão de dados
  • REDEFINES em COBOL
  • Uso de campos variáveis (spanned records com cuidado)

💣 Trade-off real

Registro pequenoRegistro grande
+ menos I/O+ menos splits
- desperdício de espaço- mais dados por I/O

🧠 4) Ajuste da configuração de I/O

📌 Tradução

A configuração de I/O inclui:

  • Tipo de device
  • Velocidade
  • Canais
  • Pathing
  • Alocação

Ferramentas recomendadas:

  • SMF
  • RMF

💬 Comentário Bellacosa

Aqui entramos no território dos sysprogs 🔥

Às vezes o problema NÃO é o VSAM
👉 é o storage, canal ou concorrência


🧪 Exemplo real

Problema:

  • VSAM lento

Análise SMF:

  • Alta contenção em volume

Solução:

  • Redistribuir datasets
  • Melhorar striping
  • Ajustar cache

🚀 Dica ninja

  • Use LSR (Local Shared Resources) em CICS
  • Use RLS (Record Level Sharing) para concorrência

💣 Isso muda completamente o comportamento do VSAM online


🧠 5) Considerações extras (parte mais rica!)

💬 Expansão Bellacosa

Aqui entram os segredos que poucos documentam 👇


🔥 CI SIZE (Control Interval)

  • Sequencial → CI maior (ex: 32K)
  • Randômico → CI menor (ex: 4K ou 8K)

🔥 CA SIZE (Control Area)

  • Afeta splits e performance
  • CA maior → menos splits

🔥 FREESPACE

FREESPACE(20 10)
  • 20% no CI
  • 10% no CA

👉 Reduz splits (ESSENCIAL em KSDS)


🔥 Secondary Allocation

Evite muitos extents:

SPACE=(CYL,(100,50))

🔥 Split (o vilão silencioso)

Quando ocorre:

  • CI Split
  • CA Split

💣 Consequência:

  • Mais I/O
  • Fragmentação
  • Queda brutal de performance

🧪 LAB PRÁTICO (nível Bellacosa 😎)

🎯 Objetivo:

Comparar performance com tuning vs sem tuning


Cenário 1 (ruim)

  • KSDS
  • CI pequeno
  • Sem buffer tuning
  • Sem FREESPACE

Cenário 2 (otimizado)

  • KSDS
  • CI adequado
  • FREESPACE(20 10)
  • SMB + ACCBIAS
  • BUFND/BUFNI ajustado

🔍 Métrica:

  • EXCP count
  • Tempo de execução
  • SMF 64/42

💥 Resultado esperado:

👉 Redução de I/O de 30% a 80% (sim, acontece!)


🏁 Conclusão estilo Bellacosa

VSAM não é velho…
VSAM é mal compreendido.

Quando bem tunado:

💣 Ele compete com banco moderno
💣 Ele escala
💣 Ele é absurdamente eficiente