Bellacosa Mainframe apresenta o Db2 Commands

🔥☕ DB2 COMMANDS NO IBM Z — A “SALA DE CONTROLE” DO MAINFRAME QUE QUASE NINGUÉM DOMINA 💾🚨

Existe uma enorme diferença entre:

• usar DB2,
  e

• controlar o DB2.

A maioria dos profissionais conhece:

• SQL,

• SELECT,

• tabelas,

• índices,

• packages.

Mas poucos realmente entendem o universo dos:

🔥 DB2 COMMANDS

E é exatamente aí que mora o verdadeiro poder operacional do IBM Z.

Porque quando:

• o online trava,

• o batch explode,

• o CPU dispara,

• o lock congela produção,

• o DDF enlouquece,

• o bufferpool satura,

não é o SQL que salva o ambiente.

É o operador que conhece:

-DISPLAY
-START
-STOP
-RECOVER
-MODIFY
-TRACE

E consegue enxergar o subsystem “por dentro”.

---

💾 O QUE SÃO DB2 COMMANDS?

Os DB2 Commands são comandos operacionais do Db2 for z/OS usados para:

• monitoramento,

• administração,

• recovery,

• troubleshooting,

• tuning,

• automação,

• controle do subsystem.

Eles podem ser executados:

• no SDSF,

• DB2I,

• console z/OS,

• batch,

• CICS,

• IMS,

• TSO,

• programas autorizados.

---

🔥 A GRANDE VERDADE

O DB2 no Mainframe não é apenas:

SELECT * FROM CLIENTES

Ele é:

• locking engine,

• recovery engine,

• log manager,

• memory manager,

• distributed server,

• transaction coordinator,

• storage subsystem.

E os comandos são o “painel de engenharia” desse motor gigantesco.

---

🚨 O COMANDO MAIS IMPORTANTE: DISPLAY

Quase tudo começa com:

-DISPLAY

ou forma curta:

-DIS

Esse comando possui dezenas de variações.

Cada uma revela uma parte diferente da “anatomia” do DB2.

---

🔥 DISPLAY THREAD — O ECG DO DB2

Comando

-DIS THREAD(*)

---

💾 O QUE ELE MOSTRA?

Threads ativas:

• CICS,

• batch,

• DDF,

• TSO,

• IMS,

• utilities.

---

🧠 O QUE É UMA THREAD?

É uma unidade ativa de execução DB2.

Pense como:

“uma conversa acontecendo agora com o banco”.

---

🚨 O QUE O DBA ANALISA?

WAIT

Pode indicar:

• lock,

• I/O lento,

• deadlock.

---

CPU ALTÍSSIMA

Uma única thread pode:

• consumir MSU,

• destruir zIIP,

• travar subsystem.

---

THREADS ZUMBI

Conexões:

• abertas,

• sem commit,

• esquecidas pela aplicação.

---

💥 CENÁRIO REAL

Aplicação Java:

• abre milhares de conexões DDF,

• não fecha corretamente.

Resultado:

-DIS THREAD(*)

mostra:

• avalanche de threads,

• consumo absurdo,

• risco subsystem.

---

🔥 DISPLAY DATABASE — A RADIOGRAFIA DO STORAGE LÓGICO

Comando

-DIS DB(*)

ou:

-DIS DATABASE(DBPROD)

---

💾 O QUE ELE ENTREGA?

Mostra:

• tablespaces,

• status,

• pendências,

• utilities,

• recovery,

• states críticos.

---

🚨 ESTADOS MAIS IMPORTANTES

Estado	Significado
RW	Read/Write
STOP	Parado
RO	Read Only
UT	Utility rodando
COPY	Backup pendente
CHKP	Check pending
RECP	Recovery pending

---

💣 RECP — O PESADELO

Recovery Pending significa:

o objeto não pode ser usado.

Pode ocorrer após:

• LOAD falho,

• recover incompleto,

• corrupção.

---

🔥 DISPLAY BUFFERPOOL — O RAIO-X DA MEMÓRIA

Comando

-DIS BPOOL(*)

---

💾 O QUE É BUFFERPOOL?

É o cache inteligente do DB2.

Armazena:

• páginas,

• índices,

• dados acessados recentemente.

---

🚨 O QUE O SYSPOG OBSERVA?

HIT RATIO

Baixo hit ratio:

• mais I/O,

• mais disco,

• mais CPU.

---

PGFIX(NO)

Pode gerar:

• paging,

• overhead CPU.

---

VPSIZE PEQUENO

Causa:

• sync I/O,

• gargalo físico.

---

💥 A VERDADE INCÔMODA

Muitos problemas “de SQL” são:

problemas de bufferpool.

---

🔥 DISPLAY DDF — O PULMÃO DISTRIBUÍDO

Comando

-DIS DDF

---

💾 O QUE É DDF?

Distributed Data Facility.

Responsável por:

• JDBC,

• APIs,

• microservices,

• Linux,

• cloud,

• aplicações externas.

---

🚨 O QUE PODE DAR ERRADO?

CONDBAT ESGOTADO

Muitas conexões simultâneas.

---

THREADS DISTRIBUÍDAS PRESAS

Pode indicar:

• problema TCP/IP,

• timeout,

• Java pool ruim.

---

DDF STOPPED

🔥 desastre moderno.

APIs param imediatamente.

---

🔥 DISPLAY LOCKS — O DETETIVE DO CRIME

Comando

-DIS LOCKS

---

💾 O QUE ELE REVELA?

• locks,

• waits,

• deadlocks,

• recursos presos.

---

💥 CENÁRIO CLÁSSICO

Batch:

UPDATE CLIENTES

sem commit adequado.

Resultado:

• CICS trava,

• PIX para,

• ATM congela.

DBA roda:

-DIS LOCKS

e encontra:

• o “assassino” da produção 😄

---

🔥 DISPLAY UTILITY — O CENTRO CIRÚRGICO

Comando

-DIS UTIL(*)

---

💾 UTILITIES IMPORTANTES

Utility	Função
REORG	Reorganização
COPY	Backup
LOAD	Carga
RUNSTATS	Estatísticas
RECOVER	Recovery

---

🚨 O QUE O DBA PROCURA?

Utility parada

Pode indicar:

• falta espaço,

• lock,

• erro I/O.

---

REORG ETERNA

Talvez:

• tablespace gigantesca,

• SORT insuficiente,

• disco saturado.

---

🔥 DISPLAY LOG — O DNA DO DB2

Comando

-DIS LOG

---

💾 O QUE ANALISAR?

• active logs,

• archive logs,

• checkpoints,

• offload,

• dual logging.

---

🚨 QUANDO O LOG SOFRE…

O subsystem inteiro sofre:

• commits lentos,

• rollback lento,

• recover piora,

• throughput cai.

---

💣 O LOG É O “SISTEMA NERVOSO” DO DB2

Sem log saudável:

não existe integridade transacional.

---

🔥 ADVISORY STATES — O DB2 TENTANDO TE AVISAR

Comando

-DIS DB(*) SPACENAM(*) ADVISORY

---

💾 O QUE É ADVISORY?

O DB2 dizendo:

“isso ainda funciona… mas vai piorar.”

---

🚨 AREO*

Advisory REORG Pending.

O DB2 recomenda:

REORG

---

🚨 ARBDP

Advisory Rebuild Pending.

Índice precisa rebuild.

---

💥 O QUE ACONTECE SE IGNORAR?

• access path degrada,

• CPU sobe,

• scans aumentam,

• overflow explode.

---

🔥 LPL — QUANDO O DB2 ENTRA EM MODO SOBREVIVÊNCIA

Comando

-DIS DB(DBPROD) SPACENAM(*) LPL

---

💾 LPL = LOGICAL PAGE LIST

Lista páginas:

• danificadas,

• inconsistentes,

• problemáticas.

---

🚨 COMO ISSO ACONTECE?

• falha I/O,

• corrupção,

• queda sistema,

• escrita interrompida.

---

💥 IMPACTO

• SQLCODE,

• abends,

• indisponibilidade,

• recover obrigatório.

---

🔥 START E STOP — O “PODER ABSOLUTO”

START DATABASE

-START DB(DBPROD)

Disponibiliza objeto.

---

STOP DATABASE

-STOP DB(DBPROD)

Indisponibiliza objeto.

---

🚨 USADO EM:

• maintenance,

• recovery,

• migração,

• REORG,

• troubleshooting.

---

💣 UM STOP ERRADO EM PRODUÇÃO…

…vira reunião de crise 😄

---

🔥 CANCEL THREAD — O BOTÃO VERMELHO

Comando

-CANCEL THREAD(token)

---

💾 PARA QUE SERVE?

Mata:

• thread travada,

• SQL infinito,

• aplicação congelada.

---

🚨 RISCO

Cancelar thread:

• pode gerar rollback gigante,

• lock storm,

• pressão de log.

---

🔥 TRACE — O MODO CSI DO DB2

Comando

-START TRACE

---

💾 O QUE É TRACE?

Captura:

• eventos internos,

• IFCIDs,

• waits,

• SQL,

• locking,

• performance.

---

🚨 PROBLEMA

Trace excessivo:

• consome CPU,

• gera overhead,

• pode piorar produção.

---

🔥 DSN — A PORTA DE ENTRADA DO DB2

Comando

DSN SYSTEM(DB9G)

---

💾 O QUE ELE FAZ?

Inicia sessão DB2 sob TSO.

---

🚨 SE DER ERRO

IKJ56500I COMMAND DSN NOT FOUND

normalmente:

• SDSNLOAD ausente,

• STEPLIB errada.

---

💾 SDSNLOAD — O “CORAÇÃO” DO DB2 BATCH

Contém:

• DSN,

• utilities,

• runtime,

• SPUFI,

• módulos DB2.

Sem SDSNLOAD:

não existe DB2 batch.

---

🔥 IKJEFT01 — O CANIVETE SUÍÇO

Programa clássico usado para:

• batch DB2,

• SPUFI,

• RUN,

• BIND,

• REBIND,

• comandos DISPLAY.

---

💥 EXEMPLO REAL

//STEP1 EXEC PGM=IKJEFT01
//STEPLIB DD DISP=SHR,DSN=DSN910.SDSNLOAD
//SYSTSIN DD *
 DSN SYSTEM(DB9G)
 -DIS THREAD(*)
 END
/*

---

🔥 O QUE SEPARA O OPERADOR COMUM DO VETERANO

O iniciante:

• olha dashboard.

O veterano:

• olha threads,

• logs,

• locks,

• utilities,

• bufferpools,

• advisory states,

• DDF,

• recovery.

Porque ele sabe:

o DB2 SEMPRE avisa antes do desastre.

---

☕ O VERDADEIRO PODER DO MAINFRAME

No mundo distribuído:

• reiniciam servidor.

No IBM Z:

• analisam causa raiz.

E os DB2 Commands continuam sendo:

• rápidos,

• leves,

• resilientes,

• precisos,

• praticamente eternos.

Décadas depois…
o terminal 3270 ainda continua revelando tudo para quem sabe ler os sinais do subsystem DB2 💾🔥

 

Bellacosa Mainframe apresenta o REXX em modo batch JCL script versus compilado

🚀☕ O REXX VIROU OPERADOR DE MAINFRAME! — Quando Scripts Ganham Superpoderes no z/OS ☕🚀

“O dia em que você descobre que REXX consegue conversar diretamente com o console do MVS… é o dia em que você percebe que o Mainframe nunca foi apenas um computador.”

— Bellacosa Mainframe Chronicles

---

😮 O GRANDE MAL-ENTENDIDO SOBRE REXX

Muita gente acha que REXX é apenas:

• linguagem de automação simples,
• script de login TSO,
• “CLIST melhorado”,
• ferramentinha de produtividade.

Mas isso é como dizer que:

• um z15 é “um computador grande”.

REXX no z/OS é MUITO mais profundo.

Quando você entra em:

• compilação,
• batch,
• console MVS,
• automação operacional,

o REXX deixa de ser “script” e começa a virar:

🔥 interface viva do sistema operacional.

---

🧠 O MOMENTO EM QUE O REXX MUDA DE NÍVEL

Existe um ponto na jornada Mainframe em que ocorre uma transformação mental.

É quando você percebe que um EXEC consegue:

✅ emitir comandos de operador
✅ capturar mensagens do sistema
✅ automatizar JES2
✅ monitorar jobs
✅ analisar IPL
✅ operar subsistemas
✅ rodar em batch
✅ virar código compilado
✅ esconder source
✅ ganhar performance absurda

Nesse momento o REXX deixa de ser:

"SAY 'HELLO WORLD'"

e vira:

"D IPLINFO"
"D A,L"
"F CICS,EMERG"

😳

---

☕ O REXX NÃO FOI CRIADO “ONTEM”

Criado por Mike Cowlishaw na IBM nos anos 70, o REXX nasceu com uma filosofia quase revolucionária:

“A linguagem deve ser legível para humanos.”

Enquanto outras linguagens:

• complicavam,
• abreviavam,
• obscureciam,

o REXX dizia:

IF SALDO < 0 THEN
   SAY 'VOCÊ ESTÁ DEVENDO'

Isso parecia simples…

Até alguém descobrir que ele podia controlar o MVS inteiro.

💀

---

🏛️ O REXX NO CORAÇÃO DO z/OS

Pouca gente percebe o quanto o REXX está infiltrado no ecossistema IBM:

Área	Uso
ISPF	diálogos
SDSF	automação
RACF	administração
JES2	operações
DB2	utilities
CICS	scripts
NetView	automação
TSO	comandos
z/OS UNIX	integração

REXX é quase um “sistema nervoso” invisível do Mainframe.

---

⚡ QUANDO O INTERPRETADOR VIRA LIMITAÇÃO

O interpretador REXX é fantástico:

• flexível,
• amigável,
• poderoso.

Mas existe um problema.

Ele lê:

linha por linha

Toda vez.

Imagine um loop gigantesco:

DO I = 1 TO 5000000
   X = I * I
END

O interpretador precisa:

• analisar sintaxe,
• resolver símbolos,
• interpretar operações,
• gerenciar tipos,

em tempo real.

Resultado:
🐢

---

🚀 O DIA EM QUE O REXX GANHA TURBO

A IBM resolveu isso criando o:

IBM REXX Compiler

Agora o fluxo vira:

SOURCE REXX
     ↓
COMPILER
     ↓
CEXEC / OBJECT
     ↓
EXECUÇÃO MUITO MAIS RÁPIDA

O ganho pode ser brutal.

Em alguns testes:

• 6x
• 8x
• 10x mais rápido.

😳

---

💥 O DETALHE QUE MUITA GENTE NÃO SABE

O compilador não melhora apenas performance.

Ele muda completamente a confiabilidade do programa.

---

🧨 O INTERPRETADOR TEM UMA PEGADINHA

Veja:

IF 1 = 2 THEN
   SAY 'ERRO

O interpretador:

• nunca entra no IF,
• nunca detecta erro.

Agora o compilador…

💀

Ele analisa tudo.

Resultado:

• syntax validation global,
• detecção estrutural,
• análise completa.

Isso transforma REXX em linguagem enterprise séria.

---

🕵️ O XREF — A FEATURE SUBESTIMADA

Quem já herdou um REXX com:

• 20 mil linhas,
• 900 variáveis,
• 300 CALLs,
• labels aleatórios,

sabe o inferno que isso é.

Então entra o:

XREF

Cross Reference Listing.

Ele lista:

• variáveis,
• funções,
• labels,
• comandos host,
• referências.

Exemplo:

USERID BUILT-IN 6(f)
SYSVAR SYSTM RTN 7(f)

Isso é ouro puro para:

• manutenção,
• auditoria,
• engenharia reversa,
• modernização.

---

👀 EASTER EGG #1 — O REXX “SECRETO”

Pouca gente conhece:

PARSE VERSION V
SAY V

Resultado:

REXX370

ou:

REXXC370

🔥

Você consegue descobrir:

• se o código está compilado,
• qual engine está rodando,
• versão do interpretador.

Quase um “SHOW VERSION” interno do REXX.

---

🧠 O QUE É CEXEC?

O compilador pode gerar:

Tipo	Descrição
CEXEC	REXX compilado
OBJECT	object module

O CEXEC continua:

• sendo REXX,
• mas compilado.

Já OBJECT pode:

• virar LOAD MODULE,
• ser link-editado,
• chamado como programa.

---

😈 O “LADO OCULTO” DO CONDENSE

Existe uma opção misteriosa:

CONDENSE

Ela:

• compacta,
• “embaralha”,
• reduz tamanho.

O resultado parece:

Æاµ▒╬╫╩

😵

Muitos juniors acham que:

• dataset corrompeu,
• encoding morreu,
• EBCDIC explodiu.

Não.

É só REXX compilado condensado.

---

⚙️ REXX EM BATCH — A PORTA PARA AUTOMAÇÃO REAL

Agora começa a magia operacional.

O REXX pode rodar:

• foreground,
• TSO,
• batch,
• scheduler,
• automation.

E aí entra uma entidade lendária do z/OS:

IKJEFT01

---

👑 IKJEFT01 — O “REI INVISÍVEL” DO TSO BATCH

Quem trabalha com Mainframe inevitavelmente encontra:

//STEP1 EXEC PGM=IKJEFT01

Esse programa:

• cria ambiente TSO/E,
• habilita comandos TSO,
• executa CLIST,
• executa REXX.

É quase um:

"TSO portátil dentro do batch"

---

💻 EXEMPLO REAL

//BELLA JOB CLASS=A,MSGCLASS=X
//STEP1 EXEC PGM=IKJEFT01
//SYSEXEC DD DSN=VAGNER.REXX.EXEC,DISP=SHR
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
%BELLA01
/*

---

🔥 O REXX EXECUTADO

/* REXX */

SAY 'BELLACOSA MAINFRAME ONLINE'

ADDRESS TSO
"LISTCAT LEVEL(SYS1)"

SAY 'FIM'

---

😮 MAS EXISTE UMA VERSÃO MAIS “ROOT”

E aí chegamos no:

IRXJCL

---

☠️ IRXJCL — O “MODO HARDCORE”

Com:

//STEP1 EXEC PGM=IRXJCL

o REXX roda:

• diretamente no MVS,
• sem TSO/E.

🔥

Agora começam as restrições.

---

💀 O ERRO CLÁSSICO

Isso NÃO funciona:

ADDRESS TSO "ALLOC ..."

Porque:
❌ não existe TSO.

---

🧠 O QUE MUDA?

Ambiente	Recursos
IKJEFT01	TSO completo
IRXJCL	MVS puro

---

👑 AGORA CHEGAMOS AO “CHEAT CODE” DO z/OS

ADDRESS CONSOLE

Quando alguém aprende isso…
não existe volta.

---

🤯 O REXX CONSEGUE VIRAR OPERADOR MVS

Sim.

Você pode emitir:

D IPLINFO
D A,L
D U,VOL=TSO001

diretamente do EXEC.

😳

---

⚠️ ISSO É PODER OPERACIONAL REAL

Agora o REXX pode:

• monitorar sistema,
• detectar falhas,
• responder eventos,
• automatizar operações,
• capturar mensagens WTO,
• agir sozinho.

Isso é praticamente a base conceitual:

• do NetView,
• OPS/MVS,
• System Automation.

---

🧩 EASTER EGG #2 — O TOKEN FANTASMA

Existe um conceito fascinante:

CART

Command And Response Token.

Exemplo:

"CART IPL001"
"DISPLAY IPLINFO"

O CART funciona como:

• identificador,
• etiqueta,
• correlation-id do comando.

Muito parecido com:

• tracing distribuído moderno,
• request-id de APIs,
• observabilidade cloud.

😳

O Mainframe já fazia isso décadas atrás.

---

💬 CAPTURANDO A RESPOSTA DO MVS

Agora entra:

GETMSG()

RC = GETMSG('MSG.','SOL','IPL001',,30)

E pronto.

As mensagens do console vão parar:

• dentro de variáveis REXX.

🤯

---

🚀 EXEMPLO COMPLETO — “OPERADOR AUTOMÁTICO”

/* REXX */

ADDRESS TSO
"CONSPROF SOLDISPLAY(NO) SOLNUM(400)"
"CONSOLE ACTIVATE"

ADDRESS CONSOLE

"CART IPL001"
"DISPLAY IPLINFO"

RC = GETMSG('MSG.','SOL','IPL001',,30)

DO I = 1 TO MSG.0
   SAY MSG.I
END

ADDRESS TSO
"CONSOLE DEACTIVATE"

---

😳 O QUE ESSE CÓDIGO FEZ?

Ele:
✅ ativou console MCS
✅ virou operador do z/OS
✅ executou comando MVS
✅ capturou respostas
✅ armazenou tudo em STEM variables

Tudo usando REXX.

---

☕ E AÍ VOCÊ PERCEBE…

O Mainframe nunca foi “ultrapassado”.

Ele sempre foi:

• automatizável,
• observável,
• integrável,
• scriptável.

Muito antes de:

• DevOps,
• IaC,
• observability,
• automation frameworks,
• cloud scripting.

---

🧠 O REXX ERA “DEVOPS” ANTES DO DEVOPS EXISTIR

Pense:

Hoje	Mainframe fazia
Python automation	REXX
IaC	PROCs/JCL
Monitoring	WTO/GETMSG
Event Driven	Console automation
Observability	CART
CI/CD	Endevor/Changeman
Scripting	TSO/E

😳

---

👑 CONCLUSÃO — O DIA EM QUE O REXX DEIXA DE SER “LINGUAGEM”

Quando você domina:

• Compiler,
• IKJEFT01,
• IRXJCL,
• ADDRESS CONSOLE,
• GETMSG,
• CART,

o REXX deixa de ser:

"uma linguagem"

e vira:

🔥 Interface operacional viva do z/OS 🔥

E talvez esse seja o segredo mais subestimado do Mainframe moderno.

---

☕ Bellacosa Mainframe Final Thought

“Quem aprende REXX de verdade percebe uma coisa assustadora:

o Mainframe não é apenas um sistema…

ele conversa com você.” 🚀☕

 

Bellacosa Mainframe mergulhas em comandos avançados do Db2

🔥☕ DB2 COMMANDS AVANÇADOS NO IBM Z — TRADUÇÃO, EXPLICAÇÃO E LABORATÓRIO PASSO A PASSO PARA SYSPOGS E DBAs 💾🚨

Os comandos DB2 são usados para controlar praticamente todo o ambiente operacional do Db2 for z/OS. Eles podem ser executados via:

• console z/OS,

• TSO,

• SDSF,

• DB2I,

• CICS,

• IMS,

• batch JCL,

• programas autorizados.

Mas a grande verdade é:

esses comandos são muito mais do que “comandos”.

Eles são:

• sensores,

• diagnósticos,

• controles cirúrgicos,

• mecanismos de sobrevivência do subsystem.

---

🔥 -DISPLAY THREAD

“Mostre quem está vivo dentro do DB2”

Tradução

Exibe informações sobre threads ativas do Db2.

---

💾 O QUE É UMA THREAD?

Thread é:

• uma conexão ativa,

• uma unidade de execução,

• uma conversa em andamento com o DB2.

Pode vir de:

• CICS,

• batch,

• DDF,

• Java,

• IMS,

• TSO.

---

🧪 PASSO A PASSO

Passo 1 — Entrar no painel DB2

Digite:

DSN SYSTEM(DB9G)

---

Passo 2 — Executar comando

-DIS THREAD(*)

---

Passo 3 — Analisar saída

Você verá:

• THREADID

• STATUS

• PLAN

• AUTHID

• CPU

• WAIT

---

🚨 O QUE OBSERVAR?

WAIT

Pode indicar:

• lock,

• I/O lento,

• deadlock.

---

CPU muito alta

Pode indicar:

• SQL ruim,

• scan massivo,

• aplicação travada.

---

💥 EXEMPLO REAL

Sistema PIX lento.

Você executa:

-DIS THREAD(*)

e encontra:

• thread Java com milhões de gets,

• CPU disparando,

• WAIT=LCK.

Resultado:

lock contention distribuído.

---

🔥 -DISPLAY DATABASE

“A radiografia do storage lógico”

Tradução

Exibe informações de status das databases Db2.

---

🧪 PASSO A PASSO

Passo 1

-DIS DB(DBPROD)

---

Passo 2 — Expandir spaces

-DIS DB(DBPROD) SPACENAM(*)

---

💾 O QUE APARECE?

• tablespaces,

• indexspaces,

• status,

• pendências,

• utilities,

• recovery states.

---

🚨 STATUS IMPORTANTES

Status	Significado
RW	Read Write
RO	Read Only
STOP	Parado
UT	Utility ativa
RECP	Recovery Pending
CHKP	Check Pending

---

💥 EXEMPLO REAL

Após LOAD falho:

STATUS=RECP

O objeto:

• não aceita acesso,

• exige recovery.

---

🔥 -DISPLAY BUFFERPOOL

“O raio-x da memória do DB2”

Tradução

Exibe o status atual dos buffer pools ativos ou inativos.

---

💾 O QUE É BUFFERPOOL?

Cache inteligente do DB2.

Armazena:

• páginas,

• índices,

• dados frequentemente acessados.

---

🧪 PASSO A PASSO

Mostrar todos

-DIS BPOOL(*)

---

Mostrar detalhe

-DIS BPOOL(BP0) DETAIL

---

🚨 O QUE ANALISAR?

HIT RATIO

Baixo:

• excesso de disco,

• I/O alto,

• CPU alta.

---

VPSIZE

Muito pequeno:

• gargalo memória.

---

PGFIX(NO)

Pode gerar:

• paging,

• overhead CPU.

---

💥 EXEMPLO REAL

Batch lento.

DBA executa:

-DIS BPOOL(*)

e descobre:

• hit ratio despencando,

• BP saturado.

---

🔥 -DISPLAY DDF

“O pulmão das conexões distribuídas”

Tradução

Exibe informações sobre o status e configuração do DDF.

---

💾 O QUE É DDF?

Distributed Data Facility.

Responsável pelas conexões:

• JDBC,

• APIs,

• Linux,

• cloud,

• microservices.

---

🧪 PASSO A PASSO

Passo 1

-DIS DDF

---

Passo 2 — Verificar

• STATUS

• CONDBAT

• threads distribuídas

• localização remota

---

🚨 ALERTAS

CONDBAT saturado

Excesso conexões.

---

DDF STOPPED

APIs param imediatamente.

---

💥 EXEMPLO REAL

Aplicação Java:

• abre milhares de conexões.

Resultado:

DDF THREAD LIMIT REACHED

---

🔥 -DISPLAY LOCKS

“O detetive do crime em produção”

Tradução

Exibe locks e claims mantidos por threads ativas.

---

🧪 PASSO A PASSO

Passo 1

-DIS LOCKS

---

Passo 2 — Procurar

• lock owner,

• waiting threads,

• lock type.

---

🚨 CENÁRIO CLÁSSICO

Batch:

UPDATE MASSIVO

sem commit.

Resultado:

• online trava,

• CICS para.

---

💥 O DBA ENCONTRA

WAIT=LCK

---

🔥 -DISPLAY LOG

“O DNA transacional do DB2”

Tradução

Exibe informações sobre active logs e checkpoints.

---

🧪 PASSO A PASSO

Passo 1

-DIS LOG

---

Passo 2 — Analisar

• active logs,

• archive logs,

• offload,

• checkpoints.

---

🚨 RISCOS

Log cheio

Pode:

• parar commits,

• travar subsystem,

• gerar degradação severa.

---

💥 EXEMPLO REAL

Sistema:

• commits lentos,

• rollback gigante.

DBA verifica:

-DIS LOG

e encontra:

• pressão de active logs.

---

🔥 -DISPLAY UTILITY

“O centro cirúrgico do DB2”

Tradução

Exibe status das utilities Db2.

---

🧪 PASSO A PASSO

Passo 1

-DIS UTIL(*)

---

Passo 2 — Procurar

• REORG,

• COPY,

• LOAD,

• RUNSTATS,

• RECOVER.

---

🚨 O QUE PODE DAR ERRADO?

REORG presa

Pode indicar:

• lock,

• I/O lento,

• SORT insuficiente.

---

🔥 -CANCEL THREAD

“O botão vermelho do DBA”

Tradução

Cancela processamento de threads locais ou distribuídas.

---

🧪 PASSO A PASSO

Passo 1 — Identificar thread

-DIS THREAD(*)

---

Passo 2 — Cancelar

-CANCEL THREAD(token)

---

🚨 CUIDADO

Cancelar thread:

• pode gerar rollback gigantesco,

• pressão de log,

• lock storm.

---

🔥 -START DATABASE

“Trazer o objeto de volta à vida”

Tradução

Torna a database disponível para uso.

---

🧪 PASSO A PASSO

Passo 1

-START DB(DBPROD)

---

Passo 2 — Confirmar

-DIS DB(DBPROD)

---

🔥 -STOP DATABASE

“Parar o coração do objeto”

Tradução

Torna objetos indisponíveis para aplicações.

---

🧪 PASSO A PASSO

Passo 1

-STOP DB(DBPROD)

---

Passo 2 — Validar

STATUS=STOP

---

🚨 IMPACTO REAL

Se parar database crítica:

• PIX para,

• ATM trava,

• APIs falham.

---

🔥 -ARCHIVE LOG

“Forçar rotação do log”

Tradução

Fecha active log atual e abre próximo disponível.

---

🧪 EXEMPLO

-ARCHIVE LOG

---

💾 USO REAL

Muito usado:

• antes backup,

• antes maintenance,

• troubleshooting log.

---

🔥 -START TRACE

“Modo CSI do DB2”

Tradução

Inicia traces Db2.

---

🧪 EXEMPLO

-START TRACE(PERFM)

---

🚨 RISCO

Trace excessivo:

• aumenta CPU,

• gera overhead.

---

🔥 -MODIFY DDF

“Alterar DDF online”

Tradução

Modifica status/configuração do DDF.

---

🧪 EXEMPLO

-MODIFY DDF PKGREL(COMMIT)

---

💾 USO

Ajuste:

• threads distribuídas,

• comportamento JDBC,

• tuning online.

---

🔥 O QUE UM SYSPOG VETERANO FAZ?

Sequência clássica:

-DIS THREAD(*)
-DIS DB(*)
-DIS LOCKS
-DIS BPOOL(*)
-DIS DDF
-DIS LOG
-DIS UTIL(*)

---

💣 O QUE ELE CONSEGUE VER?

• gargalos,

• locks,

• CPU,

• memória,

• recovery,

• corrupção,

• pressão DDF,

• degradação,

• risco subsystem.

---

☕ O GRANDE SEGREDO DO IBM Z

No Mainframe:

• tudo deixa rastros,

• tudo gera sinais,

• tudo pode ser analisado.

O verdadeiro especialista não é quem sabe apenas SQL.

É quem consegue olhar um:

-DISPLAY THREAD

e entender:

a saúde inteira do negócio em produção 💾🔥

REXX : Hello World em JCL Batch

 

Um Café no Bellacosa Mainframe

2,167 subscribers

Hello World em JCL Batch

Bellacosa Mainframe

4,424 followers

July 20, 2025

Salve jovem padawan, neste pequeno artigo apresento um JCL explicando com rodar seu primeiro programa REXX no processo BATCH.

O programa é bem pequenino com apenas 4 linhas de código

 /* REXX */
  Say "Hello world!!!!"
  Exit 0
  @@

Explicando cada linha:

1ª /* REXX / indica que é um programa REXX

2ª SAY "Hello World!!!!" exibira a mensagem seja na tela ou na sysout a depender de onde executar

3ª EXIT 0 - encerra o programa e devolve return-code 0 para a operação

4ª @@

O Job devera ser executado no ambiente e a SYSOUT analisada no SDSF.

//REXXJOB1 JOB 'REXX','Hello World',CLASS=A,MSGCLASS=W,               
//         MSGLEVEL=(1,1)
//*
//**********************************************************
//**           REXX em Batch Process                   **
//**********************************************************
//STEP1    EXEC PGM=IEBGENER
//SYSUT1   DD *,DLM=@@
  /* REXX */
  Say "Hello world!!!!"
  Exit 0
  @@
//SYSUT2   DD DSN=&&PDS(PROG1),DISP=(,PASS),UNIT=VIO,
//         SPACE=(CYL,(1,1,1),RLSE)
//SYSPRINT DD SYSOUT=*
//SYSIN    DD DUMMY
//*
//STEP2    EXEC PGM=IRXJCL,PARM='PROG1'
//SYSEXEC  DD DSN=&&PDS,DISP=(OLD,PASS)
//SYSTSPRT DD SYSOUT=*
//SYSTSIN  DD DUMMY
//* 

O resultado será exibido numa SYSOUT

Listagem com todos as sysouts no SDSF

Para quem não se recorda, segue o job sendo SUBmetido no JES2.

Espero ter ajudado, qualquer dúvida estou a disposição.