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 explica como funciona um programa COBOL com DB2

🔥☕ PACKAGE, PLAN, DBRM E O SUBMUNDO DA COMPILAÇÃO Db2 — O GUIA PADAWAN DO COBOL MAINFRAME ☕🔥

Todo programador COBOL iniciante passa por isso.

Você escreve:

EXEC SQL
   SELECT *
   FROM EMPLOYEE
END-EXEC.

compila…

e de repente aparecem criaturas malignas como:

• DBRM
• PACKAGE
• PLAN
• BIND
• DSNHPC
• SQLCODE -805
• SQLCODE -818

E o padawan pensa:

“Mas eu só queria fazer um SELECT…”

☕🔥

Então vamos entrar no verdadeiro submundo do Db2 z/OS.

---

☕ O MAIOR SEGREDO DO Db2

O Db2 NÃO executa SQL diretamente do fonte COBOL.

Ele precisa:

• analisar SQL
• validar objetos
• escolher access path
• gerar runtime structures

Por isso existe toda a cadeia:

SOURCE
 ↓
PRECOMPILE
 ↓
DBRM
 ↓
COMPILE
 ↓
LINK
 ↓
BIND PACKAGE
 ↓
BIND PLAN
 ↓
RUN

---

🔥 VISÃO GERAL DA ARQUITETURA

---

☕ SOURCE COBOL

Seu programa original.

Exemplo:

EXEC SQL
   SELECT EMPNO
   INTO :WS-EMPNO
   FROM EMPLOYEE
END-EXEC.

Dataset típico:

USERID.COBOL.SOURCE(MEUCOB)

---

🔥 STEP 1 — PRECOMPILE

Programa usado:

//DB2PC EXEC PGM=DSNHPC

---

☕ O QUE É O DSNHPC?

É o:

Db2 PRECOMPILER

---

🔥 O QUE ELE FAZ?

Ele:

✅ encontra EXEC SQL
✅ valida sintaxe SQL
✅ remove SQL do COBOL
✅ gera COBOL expandido
✅ gera DBRM

---

☕ RESULTADO DO PRECOMPILE

Saídas:

Saída	Função
COBOL expandido	será compilado
DBRM	usado no BIND

---

🔥 O QUE É O DBRM?

DBRM =

DATABASE REQUEST MODULE

---

☕ PENSE NO DBRM COMO:

“o extrato SQL do seu programa”

Ele contém:

• SQL do programa
• informações internas Db2
• metadados SQL

---

🔥 O DBRM NÃO É EXECUTÁVEL

Isso é importante.

Ele NÃO roda.

Ele apenas alimenta o BIND.

---

☕ ONDE O DBRM É SALVO?

Normalmente em:

//DBRMLIB DD DSN=USERID.DBRM.LIB(MEUPRG)

Dataset típico:

USERID.DBRM.LIB

Tipo:

PDS ou PDSE

---

🔥 EXEMPLO REAL DE PRECOMPILE

//DB2PC EXEC PGM=DSNHPC,
// PARM=('HOST(IBMCOB),APOST')

---

☕ EXPLICANDO OS PARÂMETROS

---

HOST(IBMCOB)

Define linguagem COBOL IBM.

---

APOST

Aspas simples delimitam strings SQL.

---

SOURCE

Mantém fonte expandido legível.

---

XREF

Gera cross reference.

---

DATE(ISO)

Formato ISO de datas.

---

🔥 STEP 2 — COMPILE COBOL

Programa:

//COB EXEC PGM=IGYCRCTL

---

☕ O QUE ACONTECE?

Agora o compilador COBOL compila:

o COBOL expandido gerado pelo precompiler

---

🔥 ELE NÃO COMPILA MAIS EXEC SQL

Porque o precompiler já removeu.

---

☕ SAÍDA DO COMPILE

Gera:

OBJECT MODULE

temporário.

---

🔥 STEP 3 — LINK-EDIT

Programa:

//LKED EXEC PGM=IEWL

---

☕ O QUE O LINK FAZ?

Une:

• objeto COBOL
• bibliotecas runtime
• chamadas Db2

---

🔥 RESULTADO

LOAD MODULE EXECUTÁVEL

---

☕ ONDE FICA O LOAD MODULE?

Exemplo:

//SYSLMOD DD DSN=USERID.LOADLIB(MEUPRG)

Dataset típico:

USERID.LOADLIB

---

🔥 AGORA ENTRA O VERDADEIRO MUNDO Db2

Até aqui temos apenas:

programa COBOL executável

Mas o Db2 ainda NÃO sabe nada sobre ele.

---

☕ STEP 4 — BIND PACKAGE

Programa:

//BIND EXEC PGM=IKJEFT01

---

🔥 O QUE É O PACKAGE?

PACKAGE é:

o SQL compilado e otimizado do programa

---

☕ O PACKAGE CONTÉM

✅ access paths
✅ SQL otimizado
✅ metadados
✅ permissões
✅ informações de runtime

---

🔥 QUEM CRIA O PACKAGE?

O comando:

BIND PACKAGE

---

☕ O BIND USA:

• DBRM
• catálogo Db2
• índices
• estatísticas
• permissões

---

🔥 O ACCESS PATH NASCE AQUI

Db2 decide:

• index scan?
• tablespace scan?
• join order?
• sort?
• parallelism?

---

☕ ONDE PACKAGE É ARMAZENADO?

No próprio catálogo Db2.

Tabelas internas como:

SYSIBM.SYSPACKAGE

---

🔥 NÃO FICA EM PDS

Isso pega MUITOS iniciantes.

PACKAGE NÃO fica em dataset.

Fica dentro do Db2.

---

☕ EXEMPLO DE BIND PACKAGE

DSN SYSTEM(DBCG)

BIND PACKAGE(MYCOLL)
      MEMBER(MEUPRG)
      ACTION(REPLACE)
      ISOLATION(CS)
      VALIDATE(BIND)
      EXPLAIN(YES)

---

🔥 EXPLICANDO OS PARÂMETROS

---

PACKAGE(MYCOLL)

Collection/package name.

---

MEMBER(MEUPRG)

Nome do DBRM.

---

ACTION(REPLACE)

Substitui package antigo.

---

ISOLATION(CS)

Cursor Stability.

---

VALIDATE(BIND)

Valida objetos no bind.

---

EXPLAIN(YES)

Salva access path.

---

☕ STEP 5 — BIND PLAN

Agora vem o PLAN.

---

🔥 O QUE É O PLAN?

PLAN é:

um agrupador de packages

---

☕ ANTIGAMENTE

Db2 antigo usava:

PLAN + DBRM

---

🔥 Db2 MODERNO USA:

PLAN + PACKAGE

---

☕ O PLAN FUNCIONA COMO

“container lógico de execução”

---

🔥 EXEMPLO

BIND PLAN(MYPLAN)
     PKLIST(MYCOLL.*)

---

☕ PKLIST

Lista packages autorizados.

---

🔥 ONDE O PLAN FICA?

Também no catálogo Db2.

Tabela:

SYSIBM.SYSPLAN

---

☕ EXECUÇÃO — RUN

Agora sim:

RUN PROGRAM(MEUPRG)
    PLAN(MYPLAN)

---

🔥 O FLUXO EM EXECUÇÃO

Programa chama:

PLAN
 ↓
PACKAGE
 ↓
SQL
 ↓
Db2 Engine

---

☕ ANALOGIA PADAWAN

Imagine:

---

☕ SOURCE

Receita escrita.

---

🔥 DBRM

Lista dos ingredientes.

---

☕ PACKAGE

Receita otimizada pelo chef.

---

🔥 PLAN

Cardápio do restaurante.

---

☕ LOAD MODULE

Cozinheiro executando.

☕🔥

---

🔥 ERROS MAIS FAMOSOS

---

☕ SQLCODE -805

O terror dos iniciantes.

PACKAGE NÃO ENCONTRADO

---

CAUSAS

✅ bind não executado
✅ collection errada
✅ package apagado
✅ plan errado

---

🔥 SQLCODE -818

TIMESTAMP MISMATCH

---

SIGNIFICA

LOAD MODULE ≠ PACKAGE atual.

---

ACONTECE QUANDO

recompila COBOL mas não rebinda package.

---

☕ SQLCODE -204

objeto não encontrado

---

NORMALMENTE

schema/qualifier errado.

---

🔥 SQLCODE -551

sem autorização

---

☕ COMO INVESTIGAR PROBLEMAS

---

🔥 VER PACKAGE

SELECT *
FROM SYSIBM.SYSPACKAGE
WHERE NAME = 'MEUPRG'

---

☕ VER PLAN

SELECT *
FROM SYSIBM.SYSPLAN
WHERE NAME = 'MYPLAN'

---

🔥 DISPLAY PACKAGE

-DISPLAY PACKAGE(*)

---

☕ O QUE O JUNIOR PRECISA ENTENDER

---

🔥 O COBOL NÃO EXECUTA SQL DIRETAMENTE

---

☕ O PACKAGE É O SQL “COMPILADO”

---

🔥 O PLAN ORGANIZA EXECUÇÃO

---

☕ O DBRM É A PONTE ENTRE FONTE E PACKAGE

---

🔥 O BIND DEFINE PERFORMANCE

---

☕ O ACCESS PATH NASCE NO BIND

---

🔥 O MAIOR SEGREDO DO Db2

Muitos problemas de produção NÃO estão no COBOL.

Estão em:

• package inválido
• bind errado
• access path ruim
• rebind problemático
• estatísticas ruins
• qualifier incorreto

---

☕ A VERDADEIRA MAGIA

Enquanto frameworks modernos escondem tudo…

o programador mainframe aprende:

• como SQL realmente executa
• como runtime funciona
• como otimização nasce
• como banco conversa com aplicação

E isso transforma um simples padawan COBOL…

num verdadeiro Jedi do Db2 z/OS. ☕🔥