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

 

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 apresenta o VSAM RLS superpoderes em dataset

🔥 SEU VSAM ESTÁ TE SEGURANDO… OU TE LIMITANDO?

💣 VSAM RLS: o modo transacional escondido do z/OS que poucos dominam (e menos ainda sabem usar direito)

Se você ainda trata VSAM como dataset batch com lock global…
👉 você está deixando throughput, concorrência e disponibilidade na mesa.

Hoje vamos abrir a caixa-preta do VSAM RLS (Record-Level Sharing) — no nível que interessa para quem já respira COBOL, CICS e JCL.

---

🧠 Origem: quando o VSAM precisou evoluir ou morrer

O VSAM nasceu lá atrás, nos tempos de:

• Batch dominante
• Processamento sequencial
• Lock em nível de dataset

Só que o mundo mudou:

• CICS explodiu
• OLTP virou padrão
• Multi-LPAR virou realidade

👉 E o VSAM começou a virar gargalo.

---

🚀 O nascimento do RLS

O RLS surgiu no z/OS como resposta direta a esse problema:

👉 permitir concorrência real sem reescrever tudo para DB2

Baseado em:

👉 IBM Coupling Facility

💡 Data de adoção forte: final dos anos 90 / início dos 2000 (z/OS já consolidando Parallel Sysplex)

---

⚙️ O que é VSAM RLS (sem romantismo)

VSAM RLS é:

Um mecanismo que move o controle de lock e cache para fora do dataset e coloca no Coupling Facility

Resultado:

• 🔐 Lock em nível de registro (ou CI)
• 🧠 Cache compartilhado entre LPARs
• ⚡ Acesso simultâneo real

---

🔍 Como funciona (visão de arquitetura)

Sem RLS:

Programa → VSAM → Disco
           (lock global)

Com RLS:

Programa → VSAM → CF (lock/cache) → Disco

👉 O CF vira o “gerente de concorrência”

---

🧪 IDCAMS: como nasce um VSAM RLS

Aqui começa a responsabilidade.

DEFINE CLUSTER(NAME(PROD.CLIENTES.RLS)
       INDEXED
       KEYS(10 0)
       RECORDSIZE(100 100)
       SHAREOPTIONS(3 3)
       LOG(UNDO)
       FREESPACE(10 10)
       )

⚠️ Pontos críticos

• SHAREOPTIONS(3 3) → obrigatório para multi-acesso
• LOG(UNDO) → rollback consistente
• Dataset precisa ser SMS-managed

---

📖 Exemplo COBOL – leitura com RLS

SELECT CLIENTES ASSIGN TO VSAMFILE
       ORGANIZATION IS INDEXED
       ACCESS MODE IS RANDOM
       RECORD KEY IS WS-KEY
       FILE STATUS IS WS-STATUS.

READ CLIENTES
    INVALID KEY
        DISPLAY "NAO ENCONTRADO"
END-READ.

👉 Aqui o lock é gerenciado pelo RLS automaticamente.

---

✍️ Exemplo COBOL – gravação com concorrência

WRITE REGISTRO-CLIENTE
    INVALID KEY
        DISPLAY "ERRO NA GRAVACAO"
END-WRITE.

Ou update:

READ CLIENTES
UPDATE
    INVALID KEY
        ...
END-READ.

REWRITE REGISTRO-CLIENTE.

💡 O segredo:

👉 O lock é no registro, não no dataset.

---

⚖️ Locking: onde mora o poder (e o perigo)

Tipos:

• 🔹 RECORD → alta concorrência (recomendado)
• 🔹 CI → menos overhead, mais contenção

---

📊 Monitoramento (vida real)

Ferramentas:

• RMF
• SMF

---

Métricas que importam

• Lock contention
• CF response time
• Cache hit ratio
• Buffer efficiency

---

🚀 Pontos fortes (quando bem usado)

✔️ Concorrência absurda

• Batch + CICS juntos
• Sem fila de espera

---

✔️ Alta disponibilidade

• CF permite resiliência
• Recovery consistente

---

✔️ Escalabilidade

• Multi-LPAR sem dor

---

💣 Pontos fracos (o lado sombrio)

❌ Complexidade operacional

• Não é plug-and-play
• Exige tuning constante

---

❌ Dependência do CF

Se o CF sofre…

👉 todo mundo sofre

---

❌ Debug mais difícil

• Deadlock não é trivial
• Problemas são distribuídos

---

⚠️ Limitações (que pegam senior distraído)

• ❌ Skip-sequential → proibido
• ❌ Sequential update clássico → problema
• ❌ Batch mal escrito → vira gargalo

---

🧪 Curiosidades de bastidor

💡 VSAM RLS é quase um “NoSQL raiz”

• Sem SQL
• Controle transacional básico
• Altíssimo desempenho

---

💡 RLS vs DB2

VSAM RLS	DB2
Ultra rápido	Mais completo
Menos overhead	Mais recursos
Sem SQL	SQL completo

---

🧠 Caso real (modo guerra)

Cenário:

• 5 regiões CICS
• 2 jobs batch
• 1 dataset VSAM crítico

Sem RLS:

👉 fila de espera
👉 SLA estourando

Com RLS:

👉 concorrência plena
👉 throughput triplicado

---

⚙️ Tuning (o que separa júnior de senior)

🎯 Ajustes críticos

• Buffer pool
• Estrutura do CF
• Lock level
• Cache strategy

---

💡 Regra de ouro

RLS mal configurado é pior que não usar RLS

---

🔥 Insight final (Bellacosa mode ON)

VSAM RLS é isso:

“Transformar VSAM de arquivo batch em engine transacional distribuído”

Se você domina RLS:

👉 você reduz fila
👉 aumenta throughput
👉 salva SLA

Se você ignora:

👉 seu sistema vira gargalo invisível

---

☕ Fechamento

VSAM não morreu.

Ele só evoluiu.

E o RLS é o ponto onde:

👉 legado encontra alta performance
👉 batch encontra tempo real
👉 e o COBOL continua reinando 👑