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

IBM Sovereign Core : Quando Hercule Poirot Descobre que o Verdadeiro Criminoso Nunca Foi o Hacker

 

Bellacosa Mainframe ibm sovereign core 

☕ Um Café no Bellacosa Mainframe

IBM Sovereign Core sem Mistérios para Programadores COBOL

Quando Hercule Poirot Descobre que o Verdadeiro Criminoso Nunca Foi o Hacker… Mas a Falta de Controle Sobre Quem Controla o Sistema

"As pequenas células cinzentas nunca falham, meu amigo. O erro está quase sempre naquilo que ninguém resolveu investigar." — Hercule Poirot (adaptado)

---

Introdução – Um Crime Perfeito no Datacenter

Imagine que Hercule Poirot fosse contratado para investigar um grande banco.

Ninguém roubou dinheiro.

Nenhum servidor explodiu.

Nenhum disco queimou.

Nenhum programa COBOL apresentou ABEND.

Tudo parece absolutamente normal.

Mesmo assim...

Segredos desapareceram.

Credenciais privilegiadas foram utilizadas.

Bibliotecas desconhecidas chegaram à produção.

Uma Inteligência Artificial tomou decisões sem ninguém saber exatamente por quê.

Logs foram apagados.

E o mais intrigante:

Os dados jamais saíram do datacenter.

Poirot sorri.

Ele ajeita o bigode.

Observa cada detalhe.

E faz apenas uma pergunta.

"Mon ami... quem realmente controla esta aplicação?"

Silêncio.

É exatamente essa pergunta que o IBM Sovereign Core procura responder.

E ela é muito mais profunda do que parece.

Hoje vamos investigar esse mistério como verdadeiros detetives da computação corporativa.

---

Capítulo 1 — O Primeiro Suspeito Sempre é o Lugar Errado

Quando ouvimos falar em Soberania Digital, quase todo mundo pensa imediatamente em localização.

"Os servidores estão no Brasil."

"Os dados ficam em nosso datacenter."

"Nossa cloud é privada."

Caso encerrado?

Nem de longe.

Poirot jamais condenaria alguém apenas porque estava próximo da cena do crime.

Da mesma forma, um sistema não é soberano apenas porque está fisicamente dentro do prédio da empresa.

Imagine um castelo medieval.

As muralhas são enormes.

Os portões são reforçados.

Os guardas vigiam todas as entradas.

Mas...

Quem possui a chave da sala do tesouro?

Quem controla os guardas?

Quem decide quem entra?

Quem administra os cofres?

Quem entrega novas armas?

Se essas respostas pertencem a terceiros...

O castelo nunca foi realmente seu.

---

O Primeiro Easter Egg

Sherlock Holmes dizia:

"Quando eliminamos o impossível..."

Poirot discordaria.

Ele diria:

"Antes de eliminar qualquer hipótese, descubra quem possui as chaves."

Essa diferença resume perfeitamente o IBM Sovereign Core.

---

Capítulo 2 — O Control Plane: O Cérebro Invisível

O primeiro bloco do infográfico apresenta um termo que muitos iniciantes nunca ouviram:

Control Plane.

Vamos imaginar uma agência bancária.

Existe:

• caixa

• gerente

• clientes

• cofres

Esses são os trabalhadores.

Agora imagine outro departamento.

Lá ficam:

• diretor

• segurança

• RH

• auditoria

• controle de acesso

Eles não atendem clientes.

Mas controlam absolutamente tudo.

Isso é o Control Plane.

No Kubernetes...

No OpenShift...

Na Cloud...

No IBM Sovereign Core...

O Control Plane decide:

Quem entra

↓

Quem sai

↓

Quem implanta

↓

Quem administra

↓

Quem altera configurações

↓

Quem possui privilégios

Sem ele existe apenas caos organizado.

---

Curiosidade Bellacosa

No mundo Mainframe isso não é novidade.

Desde décadas atrás o z/OS já separava claramente:

• processamento

• administração

• segurança

Muito antes da palavra Cloud existir.

---

Capítulo 3 — IAM: O Grande Livro de Convidados

Poirot sempre perguntava:

"Quem esteve na mansão naquela noite?"

Na informática fazemos exatamente a mesma pergunta.

IAM significa:

Identity and Access Management.

Ou:

Quem é você?

O que pode fazer?

Até onde pode ir?

Quando pode entrar?

Imagine um banco.

Carlos trabalha no atendimento.

Maria é DBA.

João administra RACF.

A Inteligência Artificial responde clientes.

Todos possuem identidades diferentes.

Todos possuem permissões diferentes.

Isso parece simples.

Mas aqui nasce um dos maiores problemas da computação moderna.

---

O Erro Clássico

Programador iniciante:

Usuário

ADMIN

Senha

123456

Ou pior.

root

root

Ou ainda:

admin

admin

Poirot levantaria uma sobrancelha.

"O assassino praticamente deixou seu cartão de visitas."

---

Dica Bellacosa

Jamais utilize usuários compartilhados.

Cada pessoa.

Cada serviço.

Cada robô.

Cada IA.

Deve possuir sua própria identidade.

---

Capítulo 4 — O Mistério dos Secrets

Agora chegamos ao quarto suspeito.

Os famosos:

Secrets.

Senha.

Token.

API Key.

Certificado.

Connection String.

Muitos iniciantes fazem isso:

MOVE "SenhaDoBanco123" TO WS-PASSWORD.

Ou:

password="admin123"

Ou:

apikey=ABCDEFG12345

Tudo dentro do Git.

Tudo dentro do fonte.

Poirot nem precisaria investigar muito.

O culpado praticamente escreveu uma carta confessando.

---

Como funciona corretamente?

Hoje utilizamos cofres digitais.

Por exemplo:

Vault

IBM Secrets Manager

Hashicorp Vault

Key Protect

O programa nunca conhece a senha permanentemente.

Ela é entregue apenas durante a execução.

Terminou?

Ela desaparece.

---

Capítulo 5 — A Cadeia de Fornecimento do Crime

Uma frase do artigo merece destaque.

Um build bem sucedido não significa software seguro.

Que frase maravilhosa.

Imagine uma fábrica de automóveis.

O carro foi montado.

Funcionou.

Mas...

Os freios vieram de onde?

Os pneus são originais?

O airbag possui defeitos?

O parafuso veio de fornecedor confiável?

Software moderno funciona exatamente assim.

---

Software Supply Chain

Hoje um simples programa Java pode utilizar:

2 bibliotecas próprias

+

580 bibliotecas externas

+

Containers

+

Frameworks

+

Dependências transitivas

O desenvolvedor nem conhece metade delas.

---

Curiosidade

O ataque à SolarWinds mostrou ao mundo inteiro que não basta proteger seu sistema.

Também é preciso proteger quem entrega o software.

Foi um dos maiores marcos da história da segurança.

---

Capítulo 6 — SBOM: O Inventário do Crime

Poirot adorava listas.

Quem entrou?

Quem saiu?

Quem jantou?

Quem segurava a faca?

SBOM faz exatamente isso.

Software Bill of Materials.

Uma lista completa contendo:

Bibliotecas

↓

Versões

↓

Dependências

↓

Licenças

↓

Componentes

↓

Fabricantes

Imagine perguntar:

"Meu sistema utiliza Log4j?"

Sem SBOM...

Boa sorte.

Com SBOM...

Você descobre em segundos.

---

Easter Egg Mainframe

Sabe aqueles enormes inventários de Load Modules feitos há décadas?

A filosofia é surpreendentemente parecida.

Os conceitos mudam.

A necessidade permanece.

---

Capítulo 7 — Compliance: O Inspetor Japp Aprovaria

Compliance significa provar.

Não basta dizer.

É necessário demonstrar.

Quem compilou?

Quem aprovou?

Quem publicou?

Quem executou?

Quando?

Em qual ambiente?

Isso é investigação.

Isso é rastreabilidade.

---

Capítulo 8 — A IA Também é Suspeita

Aqui está talvez o trecho mais interessante de todo o IBM Sovereign Core.

Muita gente acredita:

"Minha IA roda localmente."

Então está segura.

Errado.

Imagine um agente de IA capaz de:

Consultar Db2.

Enviar PIX.

Ler e-mails.

Modificar contratos.

Atualizar clientes.

Excluir registros.

Tudo isso localmente.

Ela continua sendo perigosíssima.

---

Poirot faria apenas uma pergunta

Quem autorizou esse agente?

Quem aprovou?

Quem auditou?

Quem acompanha suas ações?

---

Agentes Precisam de Identidade

Hoje falamos muito sobre IA.

Mas esquecemos algo essencial.

Um agente é quase um funcionário digital.

Ele precisa possuir:

Identidade

↓

Permissões

↓

Limites

↓

Ferramentas autorizadas

↓

Logs

↓

Auditoria

Jamais:

Administrador Universal

---

Capítulo 9 — O Princípio do Menor Privilégio

Imagine uma copeira.

Ela possui acesso à cozinha.

Mas não ao cofre do banco.

Imagine o gerente.

Ele pode aprovar empréstimos.

Mas não alterar o sistema operacional.

Esse conceito chama-se:

Least Privilege.

No RACF ele existe há décadas.

No IBM Sovereign Core ele continua absolutamente essencial.

---

Capítulo 10 — Audit Logging: As Pegadas do Assassino

Poirot resolvia crimes observando pequenas pistas.

Na computação fazemos exatamente o mesmo.

Logs.

Muitos logs.

Imagine:

09:10

Agente IA acessou Db2

↓

09:11

Consultou CPF

↓

09:12

Chamou API

↓

09:13

Gerou contrato

↓

09:14

Enviou e-mail

Tudo registrado.

Sem logs...

Não existe investigação.

---

O Mainframe Sorri em Silêncio

Aqui está uma curiosidade fantástica.

Enquanto Cloud começa agora a falar sobre:

• rastreabilidade

• identidade

• auditoria

• governança

O Mainframe faz isso desde muito antes da internet comercial.

RACF.

SMF.

SAF.

ICSF.

Operlog.

SYSLOG.

RMF.

São décadas de experiência acumulada.

---

Comparando os Dois Mundos

IBM Sovereign Core	IBM Mainframe
IAM	RACF
Secrets	RACF Keyrings / ICSF
Audit	SMF
Compliance	zSecure
Deploy	Endevor, ISPW, DBB
Governance	Change Management
Control Plane	z/OS + RACF + HMC
AI Governance	watsonx + IBM Z

Percebe?

Muitos conceitos considerados "novos" são, na verdade, uma evolução de práticas consolidadas no ambiente IBM Z.

---

Passo a Passo para um Programador COBOL Iniciante

Se você está começando no universo corporativo, este é um roteiro prático inspirado nos princípios do IBM Sovereign Core:

1. Nunca grave senhas ou chaves diretamente no código-fonte.

2. Aprenda os fundamentos de RACF e do conceito de IAM.

3. Entenda o que é um pipeline CI/CD e como ele publica software.

4. Estude SBOM e descubra como identificar dependências de um projeto.

5. Conheça o princípio do menor privilégio e aplique-o em programas, usuários e serviços.

6. Aprenda a interpretar logs e auditorias (SMF, SYSLOG, logs de aplicações e APIs).

7. Entenda que um agente de IA deve ser tratado como um usuário corporativo, com identidade própria e permissões limitadas.

8. Perceba que segurança não é uma etapa final do projeto; ela acompanha todo o ciclo de vida do software.

---

As Pequenas Células Cinzentas do Programador

Hercule Poirot sempre dizia que os maiores mistérios eram resolvidos observando detalhes aparentemente insignificantes.

No desenvolvimento corporativo acontece exatamente a mesma coisa.

O grande incidente raramente começa com um hacker digitando comandos em uma tela preta.

Ele costuma começar com uma pequena decisão aparentemente inocente:

• uma senha gravada no código;

• uma biblioteca sem verificação de origem;

• um usuário compartilhado entre equipes;

• um pipeline sem auditoria;

• um agente de IA executando tarefas sem identidade própria.

Cada uma dessas decisões, isoladamente, parece inofensiva. Juntas, formam o cenário perfeito para um incidente difícil de investigar.

É por isso que o IBM Sovereign Core muda a pergunta tradicional de "Onde meus dados estão?" para uma questão muito mais inteligente:

"Quem controla identidades, segredos, componentes, implantações, auditorias e agentes de IA?"

Essa mudança de perspectiva representa a essência da soberania digital moderna.

---

Conclusão — O Último Caso de Hercule Poirot

Ao final da investigação, Poirot reúne todos na biblioteca do banco.

Há desenvolvedores.

Administradores.

Especialistas em segurança.

Auditores.

Arquitetos de cloud.

Operadores de mainframe.

E até um agente de Inteligência Artificial.

Todos esperam que ele revele o nome do culpado.

Poirot sorri discretamente.

Ajeita o bigode.

Olha para cada um dos presentes e diz:

"Mesdames et Messieurs... o verdadeiro criminoso nunca foi a cloud, a IA, o Kubernetes ou o IBM Z. O culpado sempre foi a ausência de governança."

Silêncio absoluto.

Ele continua:

"Quando identidades não são controladas, segredos ficam expostos, componentes não são rastreados, implantações não são reproduzíveis e agentes de IA agem sem limites, o crime já aconteceu antes mesmo do primeiro ataque."

É nesse momento que percebemos a verdadeira lição do IBM Sovereign Core: soberania digital não é um lugar, é um conjunto de responsabilidades continuamente verificadas.

Como diria Poirot, o caso nunca foi descobrir onde a aplicação executa. O verdadeiro enigma sempre foi descobrir quem realmente segura as chaves do castelo. E, no mundo moderno, essa resposta define se uma organização está apenas hospedando seus sistemas ou se, de fato, mantém o controle sobre seu próprio destino digital.

 

Bellacosa Mainframe explica como funciona um programa COBOL com DB2

☕ Um Café no Bellacosa Mainframe

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