🔥💣 “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 em tuning DB2

🔥☕ DB2 PERFORMANCE TUNING — O “MOTOR INVISÍVEL” DO MAINFRAME IBM Z

Como um SYSprog/DBA Padawan Aprende a Domar SQL, Buffer Pool, RID Pool, SORT e LOCKING no DB2 z/OS 💾🚀

No universo do DB2 for z/OS existe uma verdade brutal:

💣 “O problema quase nunca é o Mainframe.”

O IBM Z aguenta pancada absurda.
Quem normalmente destrói CPU, I/O e tempo de resposta é:

• SQL mal escrito

• Buffer pool mal dimensionado

• RID pool estourando

• SORT explodindo em WORKFILE

• Locking gerando contenção

O DB2 é praticamente uma cidade viva dentro do z/OS.
E tuning é aprender onde o trânsito trava. ☕🏛️

---

🔥 1. SQL TUNING — O VERDADEIRO REI DA PERFORMANCE

💣 Regra número 1:

“O SQL errado derruba até z17.”

---

☕ O que mais mata performance?

🚨 TABLESPACE SCAN (TBSCAN)

Quando o DB2 lê a tabela inteira.

Exemplo ruim:

SELECT *
FROM CLIENTES
WHERE NOME = 'JOAO'

Sem índice em NOME:

-> scan completo
-> milhões de linhas
-> CPU sobe
-> I/O explode

---

🔥 Como melhorar?

✅ Use índices corretos

CREATE INDEX IX1
ON CLIENTES (NOME)

---

🚀 Prefira Stage 1 Predicates

Predicados Stage 1 são processados cedo pelo DB2.

Bom:

WHERE DATA = '2026-05-14'

Ruim:

WHERE YEAR(DATA) = 2026

A função quebra o uso eficiente do índice.

---

💣 Evite SELECT *

Ruim:

SELECT *

Bom:

SELECT ID, NOME

Menos colunas:

• menos GETPAGE

• menos I/O

• menos CPU

---

🔥 Verifique o ACCESS PATH

Use:

EXPLAIN PLAN

Olhe:

• MATCHCOLS

• INDEX ONLY

• TBSCAN

• SORT

• RID LIST

---

🚨 Sinais perigosos no EXPLAIN

Problema	Impacto
TBSCAN	scan completo
SORT	uso pesado de workfile
Hybrid Join ruim	CPU explode
List Prefetch excessivo	RID pool sofre
Cartesian Join	caos absoluto

---

☕ Ferramentas clássicas

SPUFI

EXPLAIN YES

---

PLAN_TABLE

Tabela mágica do DBA.

---

Visual Explain

No Data Studio ou ferramentas IBM.

---

🔥 2. BUFFER POOL TUNING — O “CACHE SAGRADO” DO DB2

O Buffer Pool é onde páginas ficam em memória.

Quanto mais HIT:

• menos I/O

• menos disco

• mais velocidade

---

☕ Conceito simples

Sem buffer pool:

Programa -> Disco

Com buffer pool:

Programa -> Memória

Muito mais rápido.

---

🔥 Métricas importantes

Buffer Hit Ratio

Ideal:

> 90%

---

🚨 Sintomas de buffer pool ruim

• Sync I/O alto

• Read I/O excessivo

• CPU esperando disco

• Response time ruim

---

☕ Comandos úteis

Ver status

-DISPLAY BUFFERPOOL(BP0) DETAIL

---

🚀 Alterar tamanho

ALTER BUFFERPOOL BP0 VPSIZE 200000

---

💣 Mas cuidado…

Buffer pool gigante demais:

• rouba memória do z/OS

• aumenta paging

• piora tudo

Tuning é equilíbrio.

---

🔥 Estratégia clássica

Separar objetos críticos

Exemplo:

Buffer Pool	Uso
BP0	sistema
BP1	OLTP
BP2	batch
BP32K	LOB/XML

---

☕ Pagesize correta

Tipo	Page
OLTP	4K
Scan grande	32K

---

🔥 3. RID POOL TUNING — A GUERRA DAS RID LISTS

RID = Record ID.

DB2 usa RID LIST quando:

• vários índices participam

• list prefetch ocorre

---

💣 Quando RID pool estoura…

O DB2 muda estratégia:

RID LIST -> TABLESPACE SCAN

Resultado:
🔥 desastre de performance

---

☕ Verificar RID pool

-DISPLAY BUFFERPOOL

ou IFCID traces.

---

🚀 Ajustar tamanho

ZPARM:

MAXRBLK

---

🔥 Sintomas clássicos

Sintoma	Causa
RID overflow	pool pequeno
fallback para scan	RID cheio
CPU alta	excesso de leitura

---

☕ Soluções

Melhorar índices

Muitas vezes RID pool explode porque:

• índice ruim

• predicates ruins

• cardinalidade ruim

---

Atualizar RUNSTATS

Sem estatística:
DB2 toma decisões erradas.

RUNSTATS TABLESPACE ...

---

🔥 4. SORT TUNING — O BURACO NEGRO DO WORKFILE

SORT é caro.

Muito caro.

---

💣 O que gera SORT?

• ORDER BY

• GROUP BY

• DISTINCT

• UNION

• JOIN sem índice

---

☕ O perigo invisível

SORT -> WORKFILE -> I/O -> CPU -> contenção

---

🚀 Como reduzir SORT?

Criar índices compatíveis

Exemplo:

SELECT *
FROM VENDAS
ORDER BY DATA

Índice:

CREATE INDEX IXDATA
ON VENDAS(DATA)

O DB2 evita SORT.

---

🔥 Monitorar WORKFILE

Veja:

• DSNDB07

• utilização

• overflow

• spill

---

☕ ZPARMs importantes

Parâmetro	Função
SRTPOOL	memória do sort
MAXSORT_IN_MEMORY	sort em memória
DSMAX	datasets

---

🚨 Sintomas clássicos

• DSNDB07 lotado

• I/O absurdo

• elapsed alto

• batch lento

---

🔥 5. LOCKING TUNING — O INFERNO DAS CONTENÇÕES

O DB2 protege dados com locks.

Mas lock demais:
💣 trava o sistema inteiro.

---

☕ Tipos de lock

Tipo	Nível
Row	linha
Page	página
Table	tabela
Tablespace	tudo

---

🚨 Deadlock

Dois processos esperam um ao outro.

Resultado:

SQLCODE -911
ou
SQLCODE -913

---

🔥 Timeout

Um processo espera demais.

---

☕ Estratégias de tuning

✅ Commit frequente

Ruim:

COMMIT a cada 1 milhão

Bom:

COMMIT a cada 1000

---

🚀 Use LOCKSIZE ROW

LOCKSIZE ROW

Menos contenção.

---

💣 Evite lock escalation

Quando muitos locks viram lock maior.

Exemplo:

10000 row locks
-> table lock

Caos no OLTP.

---

☕ CURRENTDATA(NO)

Ajuda em consultas read-only.

---

🔥 ISOLATION LEVEL

Nível	Característica
UR	mais rápido
CS	comum
RS	consistente
RR	máximo lock

---

🚨 RR é perigoso

Repeatable Read

Pode prender milhares de locks.

---

☕ Comandos úteis

Ver locks

-DISPLAY DATABASE(*) LOCKS

---

Threads travadas

-DISPLAY THREAD(*)

---

🔥 O SEGREDO QUE TODO DBA MAINFRAME APRENDE

A maioria dos problemas NÃO é resolvida aumentando hardware.

O fluxo correto é:

1. SQL
2. Índice
3. RUNSTATS
4. Access Path
5. Buffer Pool
6. Sort
7. Locking
8. Só depois pensar em CPU

---

☕ A FILOSOFIA DO DB2 z/OS

O DB2 é como uma megacidade subterrânea.

Cada:

• página

• lock

• RID

• sort

• getpage

é trânsito acontecendo em tempo real.

E o DBA/Sysprog experiente aprende uma coisa:

🔥 “Performance não é força bruta.
É arquitetura inteligente.” 💾🚀

 

 

Bellacosa Mainframe mergulhando em performance e custo de query db2 no Mainframe

🔥☕ “O MAINFRAME NÃO ESTÁ LENTO — SEU SQL É QUE ESTÁ INCENDIANDO A CPU DO IBM Z” 💾🚨

A Verdade Brutal que Todo Sysprog Júnior Descobre Quando Entra no Mundo Real do DB2 for z/OS

Por Bellacosa Mainframe

---

Existe um momento na vida de todo sysprog júnior…

aquele instante mágico, traumático e inesquecível…

quando ele percebe que:

💣 O problema não era o CICS.

💣 Não era o z/OS.

💣 Não era o storage.

💣 Nem o “mainframe velho”.

Era um único SQL.

Sim.

Uma linha aparentemente inocente:

SELECT *
FROM CLIENTES
WHERE CPF = '12345678900'

…destruindo CPU, queimando MIPS, elevando MSU, congestionando buffer pool e transformando a LPAR num inferno termonuclear digital.

Bem-vindo ao mundo real do DB2 for z/OS.

---

☕ O DIA EM QUE O PADAWAN DESCOBRE QUE CPU NO MAINFRAME = DINHEIRO

No universo distribuído moderno, quando falta performance, a resposta costuma ser:

• sobe mais VM

• coloca Kubernetes

• aumenta cluster

• escala horizontalmente

No mainframe?

HAHAHAHA.

Aqui a conversa é outra.

Aqui:

CPU = LICENSING

CPU = MLC

CPU = 4HRA

CPU = FATURA MILIONÁRIA

Um SQL ruim não deixa apenas o sistema “mais lento”.

Ele:

• aumenta custo mensal

• afeta SLA

• derruba throughput

• impacta batch

• congestiona CICS

• aumenta I/O

• cria lock contention

• vira incidente de produção

E o mais assustador?

Muitas vezes tudo começa com um programador dizendo:

“Mas é só um SELECT…”

---

🏛️ O MAINFRAME NÃO PENSA COMO VOCÊ

O sysprog júnior normalmente imagina que o DB2 executa SQL exatamente como foi escrito.

Não.

O DB2 é muito mais sofisticado.

Quando você envia um SQL, o DB2 chama uma entidade quase mística:

🔥 O OPTIMIZER

Ele analisa:

• estatísticas

• cardinalidade

• índices

• distribuição de dados

• filtros

• joins

• sort

• predicates

• paralelismo

• buffer access

E então decide:

“Qual será o caminho menos custoso para encontrar esses dados?”

Esse caminho se chama:

☕ ACCESS PATH

E é aqui que nascem:

• os heróis

• os vilões

• os incêndios de CPU

• e os DBA traumatizados.

---

💣 O TABLESPACE SCAN — O DEMÔNIO QUE ASSOMBRA PRODUÇÃO

Imagine uma tabela com:

• 900 milhões de linhas

• 14 TB

• milhões de acessos diários

Agora imagine um SQL sem índice adequado:

SELECT *
FROM CLIENTES
WHERE CPF = '12345678900'

Sem índice…

o DB2 pode precisar ler:

• página por página

• bloco por bloco

• segmento por segmento

Isso se chama:

🚨 TABLESPACE SCAN

Ou seja:

o DB2 sai varrendo o oceano inteiro para encontrar um peixinho.

Resultado:

• GETPAGE explode

• CPU dispara

• synchronous I/O aumenta

• elapsed cresce

• batch atrasa

• CICS sofre

E o sysprog júnior começa a ouvir palavras assustadoras no war room:

• “buffer pool saturation”

• “RID failure”

• “class 2 CPU”

• “dynamic statement cache”

• “DSNZPARM”

• “DSNDB07 lotado”

---

☕ O PODER SOBRENATURAL DE UM ÍNDICE

Agora veja a mesma consulta com índice:

CREATE INDEX IXCPF
ON CLIENTES (CPF)

O cenário muda completamente.

Agora o DB2:

• acessa diretamente o valor

• evita scan massivo

• reduz GETPAGE

• diminui I/O

• baixa CPU

O que levava:

• 40 minutos

passa a levar:

• 2 segundos

Sem exagero.

No mundo IBM Z isso acontece TODOS OS DIAS.

---

🔥 O ERRO MAIS COMUM DOS PROGRAMADORES COBOL

Padawan…

grave isso na alma:

“O COBOL não mata CPU sozinho.”

“O SQL dentro dele mata.”

Um clássico infernal:

PERFORM VARYING WS-I FROM 1 BY 1
   EXEC SQL
      SELECT ...
   END-EXEC
END-PERFORM

Parabéns.

Você acabou de criar:

☠️ O APOCALIPSE DO ROW-BY-ROW PROCESSING

Também conhecido como:

• slow by slow

• chatty SQL

• cursor abuse

O programa funciona.

Mas em produção:

• executa milhões de SQLs

• congestiona DB2

• aumenta context switch

• explode CPU

O júnior acha:

“Funcionou no teste.”

O veterano olha e já sente dor física.

---

🧠 O MITO DO “SELECT *”

Outra heresia clássica:

SELECT *

Isso é praticamente um ritual proibido em ambientes críticos.

Porque talvez você precise:

• 2 colunas

Mas o DB2 entrega:

• 180 colunas

• LOBs

• dados inúteis

• mais I/O

• mais buffer

• mais sort

• mais CPU

O correto:

SELECT NOME, CPF

No mainframe:

eficiência é religião.

---

☕ RUNSTATS — O ALIMENTO DO OPTIMIZER

O optimizer do DB2 depende de estatísticas.

Sem elas:

ele fica cego.

RUNSTATS informa:

• quantidade de linhas

• distribuição

• cardinalidade

• clustering

• seletividade

Sem RUNSTATS atualizada…

o DB2 toma decisões absurdas.

Exemplo real:

Tabela cresceu de:

• 10 milhões
  para

• 800 milhões linhas

Mas estatística continua antiga.

O optimizer acredita que a tabela ainda é pequena.

Escolhe nested loop inadequado.

Resultado:

💣 CPU 100x maior

---

🔥 EXPLAIN — O RAIO-X DA ALMA DO SQL

Veterano de DB2 não confia em “achismo”.

Ele usa:

EXPLAIN PLAN

Porque EXPLAIN revela:

• índice usado

• join method

• scans

• sorts

• custo estimado

• stage 1 / stage 2

• parallelism

É literalmente:

a anatomia do pensamento do DB2.

---

☕ STAGE 2 — O CEMITÉRIO DA INDEXABILITY

Veja isso:

WHERE SUBSTR(NOME,1,3) = 'MAR'

Parece elegante.

Mas pode impedir uso eficiente de índice.

Outro clássico:

WHERE YEAR(DATA) = 2025

Muito bonito.

Muito moderno.

Muito destrutivo.

Melhor:

WHERE DATA BETWEEN '2025-01-01'
              AND '2025-12-31'

Porque agora:

• o índice pode respirar

• o optimizer consegue navegar melhor

---

🔥 GETPAGE — A PALAVRA QUE FAZ DBA SUAR FRIO

No DB2 z/OS:

GETPAGE = acesso à página de dados.

Muito GETPAGE:

• mais CPU

• mais latch

• mais memória

• mais I/O

Veteranos monitoram:

• GETPAGE

• sync read

• class 1

• class 2

• lock wait

• RID list

como cardiologista monitorando ECG.

---

☕ “RÁPIDO” NÃO SIGNIFICA “BARATO”

Essa é uma das maiores lições do mainframe.

Às vezes:

• elapsed time está ótimo

MAS:

• CPU está monstruosa.

O usuário acha:

“Nossa, ficou rápido!”

O financeiro vê:

💸🔥💸🔥💸🔥

Porque no IBM Z:

CPU custa dinheiro real.

---

🤖 A ERA DA IA NO TUNING DB2

Hoje ferramentas modernas analisam:

• SQLs problemáticos

• regressão de access path

• mudanças após REBIND

• índices ausentes

• scans perigosos

• CPU anomalies

E algumas usam IA para:

• prever degradação

• sugerir rewrite

• detectar padrões tóxicos

• identificar SQLs assassinos

O futuro do tuning DB2 já começou.

---

🏛️ O QUE O SYSprog JÚNIOR PRECISA ENTENDER URGENTEMENTE

Mainframe não é:

• “computador velho”

• “COBOL antigo”

• “legado ultrapassado”

Mainframe é:

engenharia extrema de throughput.

E DB2 for z/OS é:

um dos motores transacionais mais eficientes já criados pela humanidade.

Ele processa:

• bancos

• cartões

• bolsa

• aviação

• seguros

• governo

• PIX

• ATM

• clearing financeira

Em escala absurda.

---

☕ A GRANDE VERDADE FINAL

O mundo moderno fala:

• cloud

• containers

• microservices

• IA

Mas nos bastidores…

existe um IBM Z executando milhões de transações por segundo…

e um DBA desesperado tentando descobrir:

🔥 “QUAL SQL ESTÁ QUEIMANDO A CPU?” 🔥

Porque no fim…

o COBOL processa o negócio…

o CICS coordena as transações…

mas:

💾 É O ACCESS PATH DO DB2 QUE DECIDE QUANTO CUSTA MANTER O MUNDO FUNCIONANDO. ☕🔥

 

Bellacosa Mainframe fala sobre o futuro do profissional mainframe

☕🔥 O NOVO PROFISSIONAL MAINFRAME — O “SYSOP DO FUTURO” JÁ CHEGOU… E MUITA GENTE AINDA NÃO PERCEBEU 🔥☕

Durante anos o mercado repetiu a mesma ladainha:

“Mainframe morreu.”
“COBOL acabou.”
“Tudo vai para cloud.”
“Só tem profissional velho.”
“Daqui 5 anos ninguém mais usa z/OS.”

…e mesmo assim o mainframe continua processando bilhões de transações financeiras, cartões, seguros, companhias aéreas, governo, saúde e bancos do planeta inteiro.

O mais curioso?

Enquanto muita gente fazia meme do COBOL…
a IBM lançava:

• novas releases do z/OS,
• melhorias absurdas de segurança,
• integração com Linux,
• OpenShift,
• containers,
• APIs REST,
• IA embarcada,
• automação,
• observabilidade,
• criptografia quântica,
• integração cloud híbrida,
• DevOps,
• Ansible,
• Zowe,
• Python no z/OS,
• pipelines CI/CD,
• modernização de CICS,
• Db2 acelerado,
• zCX,
• Wazi,
• integração com Kubernetes…

Ou seja:

o mainframe não ficou parado.

Muita gente ficou.

☕💾 O PROFISSIONAL MAINFRAME DE HOJE NÃO É MAIS “OPERADOR DE TELA VERDE”

Esse é talvez o maior choque cultural.

O profissional moderno de mainframe virou um híbrido raro no mercado.

Hoje ele precisa entender:

• infraestrutura,
• cloud,
• segurança,
• automação,
• Linux,
• APIs,
• containers,
• integração distribuída,
• observabilidade,
• DevOps,
• redes,
• performance,
• IA,
• além do velho e poderoso conhecimento de z/OS.

O cara que antes conhecia apenas:

• JCL,
• JES2,
• TSO,
• COBOL,
• CICS,

…agora conversa com:

• squads cloud,
• times DevOps,
• arquitetos AWS/Azure/GCP,
• desenvolvedores Java,
• SRE,
• engenharia de plataforma,
• segurança ofensiva,
• APIs e microsserviços.

E isso muda completamente a carreira.

☕🔥 O MAINFRAME VIROU O “CORE ENGINE” DA CLOUD HÍBRIDA

Muita gente ainda pensa:
“Cloud substitui mainframe.”

Mas na prática o mercado percebeu algo diferente:

☁️ Cloud resolve elasticidade.
💾 Mainframe resolve missão crítica.

E o mundo corporativo descobriu que:

• downtime custa bilhões,
• segurança importa,
• consistência importa,
• throughput importa,
• governança importa,
• estabilidade importa.

Resultado?

O discurso mudou de:
“vamos eliminar o mainframe”

…para:
“como integrar o mainframe com cloud?”

Esse é o novo jogo.

E quem entende dos dois mundos virou profissional premium.

☕🚀 O PROFISSIONAL 50+ MAINFRAME NÃO ESTÁ ULTRAPASSADO

Esse talvez seja o ponto mais importante.

Existe uma geração inteira de profissionais carregando:

• décadas de experiência,
• conhecimento de negócio,
• troubleshooting real,
• visão sistêmica,
• disciplina operacional,
• capacidade analítica,
• experiência em crises reais.

Essa experiência vale ouro.

Porque infraestrutura crítica não é TikTok.
Não é hype.
Não é framework da semana.

Banco não pode “dar refresh”.
PIX não pode travar.
Cartão não pode cair.
Folha de pagamento não pode falhar.

E quando tudo explode às 2h da manhã…
a empresa descobre rapidamente quem é profissional de verdade.

☕💡 O DESAFIO NÃO É IDADE. É ATUALIZAÇÃO.

O mercado não está descartando profissionais 50+.

O mercado está descartando quem:

• parou no tempo,
• rejeita aprender,
• tem medo de mudança,
• trata novidade como inimiga.

Porque hoje existe espaço gigantesco para:

• mentor técnico,
• especialista híbrido,
• arquiteto legado/cloud,
• modernização,
• automação z/OS,
• segurança,
• observabilidade,
• integração API/mainframe,
• DevOps enterprise.

O profissional experiente que aprende:

• Linux,
• automação,
• APIs,
• Python,
• cloud híbrida,
• IA aplicada,
• ferramentas modernas IBM,

vira praticamente um “unicórnio corporativo”.

☕🔥 IA NÃO VEIO PARA MATAR O MAINFRAME

Na verdade…

IA vai aumentar ainda mais a importância dos ambientes estáveis.

Porque IA precisa:

• dados confiáveis,
• processamento consistente,
• segurança,
• governança,
• rastreabilidade.

E adivinha onde estão os dados mais críticos do planeta?

No mainframe.

O que muda é o papel do profissional.

Menos trabalho repetitivo.
Mais automação.
Mais integração.
Mais análise.
Mais arquitetura.
Mais inteligência operacional.

O futuro do mainframe não é apertar ENTER em tela verde.

É orquestrar ambientes híbridos gigantescos.

☕💾 HOME OFFICE MUDOU O JOGO

Antigamente o profissional mainframe era visto quase como:
“o cara preso no CPD.”

Hoje:

• participa de reuniões globais,
• trabalha remoto,
• atende clientes internacionais,
• opera ambientes gigantes de casa,
• ensina online,
• cria conteúdo,
• ministra treinamento,
• faz consultoria mundial.

O conhecimento ficou global.

E isso abriu espaço enorme para profissionais experientes.

☕🔥 O MAINFRAME NÃO MORREU. ELE EVOLUIU.

Talvez a maior mentira da TI tenha sido:
“mainframe vai acabar.”

O que acabou foi:

• o isolamento do mainframe,
• a cultura fechada,
• o profissional que só conhecia um único mundo.

O novo profissional z/OS conversa com:

• cloud,
• Linux,
• IA,
• APIs,
• automação,
• DevSecOps,
• observabilidade,
• analytics,
• containers.

E isso é fascinante.

☕🚀 UMA MENSAGEM PARA O PROFISSIONAL MAINFRAME 50+

Se você tem décadas de carreira:
não carregue vergonha da sua experiência.

Carregue orgulho.

Você sobreviveu:

• a migração Y2K,
• downsizing,
• ondas Unix,
• client/server,
• virtualização,
• internet,
• cloud,
• DevOps,
• microsserviços,
• IA…

…e o mainframe continua aqui.

Mas agora existe uma missão nova:

não proteger o passado.

E sim conectar o passado ao futuro.

Aprenda algo novo.
Teste Linux.
Brinque com Python.
Entenda cloud.
Automatize tarefas.
Explore IA.
Converse com equipes jovens.
Compartilhe experiência.

Porque o mercado não precisa apenas de juventude.

O mercado precisa de gente que entende o que acontece quando sistemas críticos realmente importam.

E nisso…
o profissional mainframe ainda é uma das peças mais valiosas da tecnologia mundial. ☕🔥

 

Bellacosa Mainframe com dicas para padawan cobol dominar o db2

🔥☕ O CAMINHO DO PADAWAN Db2 — COMO UM PROGRAMADOR COBOL JÚNIOR SOBREVIVE AO MUNDO REAL DOS BANCOS NO MAINFRAME ☕🔥

Tem uma coisa que quase nenhum curso ensina direito.

O problema de aprender Db2 no mainframe NÃO é decorar:

• SELECT

• FETCH

• CURSOR

• JOIN

Isso qualquer apostila faz.

O verdadeiro desafio é entender:

🚀 COMO O Db2 “PENSA”

Porque no ambiente bancário:

• performance é dinheiro

• CPU custa milhões

• lock errado derruba sistema

• SQL ruim gera guerra entre desenvolvimento e DBA

• um tablespace scan pode parar um banco inteiro

E é aqui que nasce a diferença entre:

• um programador COBOL comum

• e um verdadeiro guerreiro do z/OS.

---

☕ O MAIOR ERRO DO PADAWAN COBOL

Todo iniciante chega no Db2 tentando programar como se estivesse lendo VSAM.

Faz:

• loop

• READ

• IF

• PERFORM

• validação manual

• cursor desnecessário

e transforma o Db2 num simples “arquivo sofisticado”.

🔥 Grave isso:

Db2 NÃO é VSAM.

Db2 é:

• relacional

• baseado em conjuntos

• otimizado matematicamente

• orientado a custo

• controlado por estatísticas

---

🚀 O PROGRAMADOR MAINFRAME MODERNO NÃO PENSA EM LINHAS

Ele pensa em:

SETS

---

☕ PROCESSAMENTO RELACIONAL

O programador antigo pensa assim:

“Vou buscar linha por linha e processar.”

O programador Db2 sênior pensa:

“Como faço o Db2 processar tudo sozinho?”

Essa mudança mental vale OURO.

---

🔥 SQL NÃO É APENAS CONSULTA

O padawan acha que SQL é:

SELECT *
FROM CLIENTE

Mas Db2 é MUITO maior:

• optimizer

• locking

• clustering

• filter factors

• parallelism

• stage 1/stage 2

• access paths

• static SQL

• dynamic SQL

• utilities

• EXPLAIN

E quando você entende isso…
você começa a dominar o ambiente bancário.

---

☕ O OPTIMIZER É O VERDADEIRO “CÉREBRO” DO Db2

No mainframe bancário:

• ninguém lê bilhões de linhas “na força”

• ninguém faz scan por diversão

• ninguém quer CPU extra

O optimizer decide:

• qual índice usar

• qual join usar

• se haverá sort

• se haverá prefetch

• se haverá paralelismo

---

🚀 E O QUE O OPTIMIZER USA?

Estatísticas.

RUNSTATS é praticamente:

“os olhos do optimizer”

Sem estatísticas:

• access path piora

• índice é ignorado

• FF fica errado

• CPU explode

---

☕ FILTER FACTOR — O SEGREDO QUE MUITOS IGNORAM

Pouca gente iniciante entende isso.

Mas FF muda TUDO.

🚀 Filter Factor

é:

• a estimativa da porcentagem de linhas que satisfazem um predicado.

---

☕ Exemplo

WHERE DEPT = 'A00'

Se existem:

• 10 departamentos

Db2 estima:

1/10 = 0.1

Ou seja:

• 10% das linhas serão retornadas.

---

🔥 Quanto MENOR o FF:

MELHOR

Porque:

• menos linhas

• menos I/O

• menos CPU

• menos pages

• menos lock

---

☕ O ERRO CLÁSSICO DO PADAWAN

WHERE COL <> 'X'

🔥 Péssimo FF.

Db2 entende:

“quase todas as linhas servem”

Então:

• índice perde valor

• scan aparece

• CPU sobe

---

🚀 INDEX NÃO É MAGIA

Outro choque do iniciante.

Ter índice NÃO garante performance.

O optimizer escolhe:

• usar

• ignorar

• combinar

• fazer screening

• fazer scan

dependendo:

• FF

• cardinalidade

• clustering

• custo estimado

---

☕ O MUNDO REAL DOS BANCOS

Em banco grande:

• tabela pode ter bilhões de linhas

• índice pode ter centenas de GB

• um SQL ruim pode consumir milhares de MIPS

Por isso:

access path é assunto sagrado.

---

🔥 STAGE 1 vs STAGE 2

Esse conceito separa:

• SQL eficiente

• SQL sofrível

---

☕ Stage 1

Predicado processado cedo:

• no Data Manager

• usando índice

• reduzindo linhas rapidamente

Mais rápido.

---

☕ Stage 2

Predicado processado depois:

• mais CPU

• mais linhas avaliadas

• menos eficiência

---

🚀 Exemplo ruim

WHERE YEAR(DATA) = 2025

Função na coluna:

• pode matar indexabilidade

• virar stage 2

---

☕ Melhor abordagem

WHERE DATA BETWEEN '2025-01-01'
AND '2025-12-31'

---

🔥 LOCKING — O TERROR DOS BANCOS

Padawan geralmente aprende SELECT…

mas não aprende:

concorrência.

E no banco:

• milhares de programas acessam a mesma tabela ao mesmo tempo.

---

☕ Lock errado gera:

• timeout

• deadlock

• lentidão

• aplicação travada

• fila no CICS

• caos operacional

---

🚀 LOCKSIZE

Db2 pode bloquear:

• row

• page

• table space

---

☕ O perigo do PAGE LOCK

Uma página pode conter:

• várias linhas

Então:

• um lock pode bloquear muitos registros sem você perceber.

---

🔥 ISOLATION LEVEL

Outro tema CRÍTICO.

---

☕ CS — Cursor Stability

Mais comum no OLTP bancário.

Balanceia:

• integridade

• concorrência

---

☕ RR — Repeatable Read

Mais rígido.
Mais locks.
Mais contenção.

---

☕ UR — Uncommitted Read

O famoso:

dirty read

Excelente para:

• relatórios

• analytics

• consultas não críticas

Péssimo para:

• saldo bancário

• movimentação financeira

😄

---

🚀 COMO EVITAR DEADLOCK

O curso mostrou algo IMPORTANTÍSSIMO:

Todos os programas devem atualizar na mesma sequência.

---

☕ Exemplo

Programa A:

CLIENTE → CONTA

Programa B:

CONTA → CLIENTE

🔥 Receita perfeita para deadlock.

---

🚀 ACCESS PATH — A ALMA DO Db2

Toda query possui um plano.

Db2 decide:

• scan

• index access

• nested loop

• merge scan

• hybrid join

• hash join

---

☕ TABLESPACE SCAN

Lê tudo.

Pode ser:

• correto

• ou desastre absoluto.

---

☕ INDEXED ACCESS

Busca seletiva.

Muito mais eficiente quando:

• FF é baixo

• índice é adequado

---

🚀 JOINS — O CAMPO DE BATALHA

Padawan normalmente só aprende:

INNER JOIN

Mas Db2 usa:

• nested loop

• merge scan

• hybrid join

• star join

dependendo:

• tamanho

• índices

• cardinalidade

---

☕ MERGE SCAN JOIN

Excelente para:

• tabelas grandes

• sem índices úteis

• dados ordenados

---

🔥 STATIC SQL vs DYNAMIC SQL

No banco:
isso é discussão séria.

---

☕ STATIC SQL

Pré-compilado.
Pré-otimizado.

Perfeito para:

• CICS

• OLTP

• alta performance

---

☕ DYNAMIC SQL

Construído runtime.

Excelente para:

• analytics

• ferramentas

• SQL variável

---

🚀 Por que bancos AMAM STATIC SQL?

Porque:

• menos CPU

• menos prepare

• access path estável

• melhor governança

---

☕ EXPLAIN — O RAIO-X DO OPTIMIZER

Se você não usa EXPLAIN…
você está programando no escuro.

---

🚀 EXPLAIN mostra:

• índice usado

• tipo de join

• matching columns

• prefetch

• paralelismo

• custo estimado

---

☕ PLAN_TABLE

É praticamente:

a Bíblia do tuning Db2.

---

🔥 UNION vs UNION ALL

Padawan frequentemente usa:

UNION

sem perceber:

• Db2 faz SORT

• remove duplicatas

• aumenta CPU

---

🚀 UNION ALL

Muito mais rápido.

Use quando:

• duplicatas não importam.

---

☕ FETCH FIRST

Outro segredo simples que salva CPU.

---

❌ Errado

SELECT *
FROM BIGTABLE

---

✅ Melhor

FETCH FIRST 10 ROWS ONLY

---

🚀 “PEÇA SOMENTE O NECESSÁRIO”

Essa é uma filosofia inteira do Db2.

---

☕ EVITE ESCREVER CÓDIGO

A aula falou algo brilhante:

“Avoid Writing Code”

---

🚀 O Db2 já sabe:

• somar

• converter

• truncar

• upper/lower

• calcular datas

• agregar

• ordenar

• paralelizar

Então:

• use funções SQL

• use set processing

• use procedures

• use triggers

---

☕ O COBOL NÃO DEVE FAZER O QUE O Db2 FAZ MELHOR

Essa frase muda carreiras.

---

🔥 O SEGREDO FINAL

No ambiente bancário:
o programador COBOL NÃO domina apenas COBOL.

Ele precisa entender:

• SQL

• optimizer

• access path

• locking

• concurrency

• CPU

• I/O

• clustering

• statistics

• utilities

Porque:

o verdadeiro programa executa dentro do Db2.

---

☕ O PADAWAN VIRA MESTRE QUANDO ENTENDE:

“SQL não é uma linguagem de acesso.
SQL é uma linguagem de processamento.”

🔥☕ Welcome to the real mainframe world, padawan.

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:

Elemento	Mundo Real
z/OS	pessoas trabalhando
Db2	arquivos/documentos
CICS	atendentes
Coupling Facility	central de coordenação
Lock Structure	semáforo
Cache Structure	memória compartilhada
List Structure	fila organizada

---

🔥 O QUE A COUPLING FACILITY FAZ?

Ela trabalha principalmente com:

Estrutura	Função
Lock Structure	controle de locks
Cache Structure	cache compartilhado
List Structure	filas/listas
Serialization	sincronismo
Signaling	comunicaçã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:

Sistema	Ação
DB2A	atualiza cliente
DB2B	tenta 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

Componente	Descrição
CFRM	Coupling Facility Resource Management
XCF	Cross-system Coupling Facility
IXLCONN	conecta aplicações
IXLLIST	manipula listas
IXLCACHE	cache compartilhado
IXLLOCK	lock 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:

Tipo	Descrição
Internal CF	dentro do próprio CPC
External CF	má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:

Painel	Uso
RMF	performance
SDSF LOG	mensagens
DA	devices
ENC	enclosures

---

📊 MONITORAMENTO

Ferramentas clássicas:

Ferramenta	Uso
RMF Monitor III	performance CF
OMEGAMON	análise avançada
IBM Tivoli	monitoramento
SMF 74	mé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:

Subtype	Uso
74-4	CF Activity
74-5	CF Cache
74-7	Lock 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étrica	Significado
Request Rate	requisições
Service Time	latência
Lock Contention	disputa
Rebuild Count	rebuilds
CF CPU	uso 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:

Sistema	Transações
DB2A	internet banking
DB2B	PIX
DB2C	ATM
DB2D	cartã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.” ☕🔥