Bellacosa Mainframe falando sobre SMP/E 

💀🔥 “SEU COBOL NÃO QUEBROU… FOI O SMP/E QUE REESCREVEU O MUNDO AO REDOR”

O guia que todo dev sênior precisa ler antes de culpar o programa

---

Você já viveu isso:

💣 “rodava ontem… hoje ABENDOU… ninguém mexeu no código”

👉 Então deixa eu te contar a verdade que poucos falam no mainframe:

💀 o código raramente muda… o ambiente muda o tempo todo

E quem controla isso?

🔥 SMP/E — System Modification Program / Extended

---

🕰️ UM POUCO DE HISTÓRIA (POR QUE ISSO EXISTE)

Antes do SMP/E:

• sysprog copiava módulo na mão
• sobrescrevia biblioteca sem controle
• não existia rastreabilidade

Resultado?

💣 ambiente inconsistente
💣 bugs “fantasmas”
💣 caos operacional

O SMP nasceu pra resolver isso… e evoluiu para o SMP/E:

👉 controle
👉 consistência
👉 governança

---

🧠 SMP/E NA PRÁTICA (SEM ROMANTIZAR)

Pensa assim:

seu programa = ponta do iceberg
smp/e = quem controla o oceano inteiro

Ele decide:

• qual versão roda
• quais dependências são válidas
• o que entra no sistema
• o que quebra silenciosamente

---

🔠 ACRÔNIMOS (TRADUÇÃO DE VERDADE)

🔥 SMP/E

👉 System Modification Program / Extended
👉 gerenciador de instalação e manutenção

---

📦 SYSMOD

👉 pacote de mudança

Tipos:

• FUNCTION → instala produto
• PTF → correção oficial
• APAR → problema reportado
• USERMOD → customização local

💣 Easter egg:

USERMOD mal feito vira dívida técnica eterna

---

🧬 CSI

👉 Consolidated Software Inventory

👉 banco VSAM onde tudo é registrado:

• versões
• dependências
• histórico

💀 sem CSI consistente:

você não tem ambiente… tem sorte

---

🧠 FMID / RMID / UMID

• FMID → origem (quem criou)
• RMID → última substituição
• UMID → updates incrementais

👉 isso é controle de versão REAL (muito antes do Git 😄)

---

🧱 COMO FUNCIONA O ARMAZENAMENTO

📦 O coração: CSI (VSAM)

👉 dataset VSAM KSDS

Contém:

• ZONES
• entradas de elementos
• relações entre bibliotecas

---

🧩 ZONES (ARQUITETURA LÓGICA)

Zone	Função
GLOBAL	índice e controle
TARGET	o que está rodando
DLIB	base confiável

---

💡 Insight de sênior:

🔥 TARGET mente
🔥 DLIB não mente

---

📁 TIPOS DE DATASETS DO SMP/E

🔹 SMPCSI

👉 o banco (VSAM)

---

🔹 SMPPTS

👉 staging dos SYSMODs (RECEIVE)

---

🔹 SMPLOG / SMPOUT

👉 logs e mensagens (onde está a verdade)

---

🔹 TARGET LIBRARIES

👉 executáveis (load modules)

---

🔹 DISTRIBUTION LIBRARIES (DLIB)

👉 base confiável (source, macros, objetos)

---

💣 Curiosidade:

DLIB geralmente NÃO é executável
e mesmo assim é mais importante que TARGET

---

⚙️ COMO O SMP/E FUNCIONA (O FLUXO QUE MANDA EM TUDO)

RECEIVE → APPLY → ACCEPT

---

🔹 RECEIVE

• carrega SYSMOD
• não altera sistema

---

🔹 APPLY

• altera TARGET
• muda runtime

💀 aqui nasce o problema

---

🔹 ACCEPT

• atualiza DLIB
• vira baseline

---

💣 Easter egg:

APPLY muda o presente
ACCEPT muda o futuro

---

🖥️ SMP/E NO ISPF (TELA VERDE RAIZ)

Acesso típico:

TSO SMPE

Menu clássico:

• RECEIVE
• APPLY
• ACCEPT
• RESTORE
• LIST / REPORT

---

💡 Dica de sênior:

ISPF é interface…
mas quem manda é o JCL

---

⚙️ SMP/E VIA BATCH (MUNDO REAL)

Execução padrão:

//SMPE EXEC PGM=GIMSMP
//SMPCSI DD ...
//SYSIN  DD *
  SET BDY(TZONE).
  APPLY CHECK.
/*

---

💣 Curiosidade:

todo clique no ISPF vira JCL por baixo

---

🧩 MCS — A LINGUAGEM DO SMP/E

Tudo começa com:

++PTF
++VER
++MOD

---

🔥 ++VER (O MAIS IMPORTANTE)

Define:

• FMID
• dependências
• aplicabilidade

💀 erro aqui = APPLY FAIL

---

🔗 DEPENDÊNCIAS (ONDE O BICHO PEGA)

• PRE → precisa antes
• REQ → precisa junto
• SUP → substitui

---

💣 80% dos erros de SMP/E:

👉 dependência não resolvida

---

🏗️ JCLIN — O SEGREDO QUE NINGUÉM TE CONTA

👉 não executa
👉 descreve o link-edit

💡 SMP/E aprende como montar o sistema

---

💀 erro clássico:

código certo… montagem errada

---

🧬 TRACKING (O NÍVEL QUE DIFERENCIA)

SMP/E sabe:

FMID → origem
RMID → substituição
UMID → updates

---

💡 Insight:

• 1 RMID por elemento
• vários UMIDs

👉 isso explica comportamento estranho

---

💣 CASO REAL (VOCÊ JÁ VIU ISSO)

👉 programa mudou comportamento

Causa:

• novo PTF
• RMID alterado
• runtime atualizado

💀 não foi o código

---

⚠️ TROUBLESHOOTING RÁPIDO

Se der erro:

1. leia SMPOUT
2. verifique dependência
3. cheque HOLDDATA
4. valide zone
5. rode APPLY CHECK

---

🍛 A PENSAR NA HORA DO ALMOÇO

👉 quantos bugs você debugou…

…que eram:

• mudança de load module
• alteração de ambiente
• PTF aplicado

---

🚀 CONCLUSÃO (NÍVEL SÊNIOR)

💀 SMP/E não instala software
🔥 ele governa o estado do sistema

---

🔥 FRASE FINAL (ASSINATURA)

💣 “Seu código não mudou…
o mundo ao redor dele mudou — e você não viu.”

 

 

Bellacosa Mainframe Painel de Comando do DB2

🔥☕ “O MAINFRAME NÃO ESTÁ LENTO — VOCÊ É QUE NÃO OLHOU O DB2 PELO PAINEL DE COMANDO” 💾🚨

O laboratório definitivo de DB2 Commands para Sysprogs, DBAs e sobreviventes de produção no IBM Z

Existe um momento na vida de todo profissional de Mainframe em que ele percebe uma verdade brutal:

O problema não está no COBOL.
Não está no CICS.
Não está no batch.
Muitas vezes… o DB2 já estava gritando há horas no painel de comandos.

E é exatamente aí que nasce o verdadeiro operador de produção, o DBA raiz e o sysprog veterano.

Porque enquanto muita gente depende:

• de dashboard web,
• monitor colorido,
• ferramenta gráfica,
• console “moderninho”,

o profissional de IBM Z abre um terminal 3270 e digita:

-DIS THD(*)

E em segundos ele enxerga:

• travamentos,
• contenção,
• deadlocks,
• pressão de memória,
• gargalo de I/O,
• DDF congestionado,
• utilities presas,
• aplicações morrendo lentamente.

Tudo isso diretamente no coração do DB2.

---

💾 O QUE É O DB2 COMMAND FACILITY?

O DB2 Command Facility é o mecanismo operacional do DB2 z/OS usado para:

• monitoramento,
• administração,
• troubleshooting,
• recovery,
• tuning,
• análise de performance.

Ele permite conversar diretamente com o subsystem DB2.

Na prática:

• você não executa SQL,
• você conversa com o motor interno do DB2.

É quase como abrir um shell administrativo do banco.

---

🔥 O PAINEL QUE ASSUSTA INICIANTES… E SALVA PRODUÇÃO

A clássica tela:

DB2 COMMANDS

parece simples.

Mas ela é uma das interfaces mais poderosas do ecossistema IBM Z.

Ali vivem comandos capazes de:

• parar databases,
• analisar locks,
• detectar gargalos,
• visualizar threads,
• monitorar DDF,
• inspecionar bufferpools,
• acompanhar utilities,
• identificar problemas de log.

Em ambientes bancários isso significa:

milhões de transações por minuto.

---

🚨 O PRIMEIRO ERRO QUE TODO MUNDO COMETE

Você digitou:

-DIS

e recebeu:

REQUIRED KEYWORD IS MISSING

Esse erro é quase um ritual de iniciação 😄

O DB2 funciona com estrutura:

-VERBO OBJETO(OPÇÕES)

Exemplo:

Comando	Função
-DIS THREAD(*)	Mostra threads
-DIS DB(*)	Mostra databases
-DIS LOG	Mostra logs
-DIS UTIL(*)	Mostra utilities
-DIS DDF	Mostra Distributed Data Facility

---

🔥 DISPLAY THREAD — O ELETROCARDIOGRAMA DO DB2

Comando

-DIS THD(*)

ou:

-DIS THREAD(*)

---

💣 O QUE ELE MOSTRA?

Esse comando revela:

• conexões ativas,
• jobs batch,
• usuários TSO,
• transações CICS,
• conexões distribuídas,
• planos DB2,
• waits,
• locks.

É literalmente o “quem está vivo” dentro do DB2.

---

🚨 O QUE UM SYSPOG PROCURA?

🔥 STATUS=WAIT

Pode indicar:

• lock contention,
• deadlock,
• timeout,
• gargalo I/O.

---

🔥 THREADS DDF EXCESSIVAS

Pode indicar:

• avalanche de conexão distribuída,
• problema de aplicação Java,
• pool mal configurado.

---

🔥 CPU DISPARANDO

Às vezes um único thread:

• está executando SQL ruim,
• segurando recurso crítico,
• consumindo zIIP,
• causando storm de lock.

---

💾 DISPLAY DATABASE — A RADIOGRAFIA DO STORAGE LÓGICO

Comando

-DIS DB(*)

ou:

-DIS DB(DBPROD) SP(*)

---

🔥 O QUE ISSO ENTREGA?

Mostra:

• status databases,
• tablespaces,
• pendências recovery,
• copy pending,
• utility pending,
• read only,
• stop states.

---

🚨 STATUS QUE ASSUSTAM DBA

Status	Problema
STOP	Database indisponível
UT	Utility executando
COPY	Backup pendente
CHKP	Check pending
RECOVER	Recovery necessário

---

💣 O QUE ISSO SIGNIFICA EM PRODUÇÃO?

Um database em:

STOP

pode derrubar:

• internet banking,
• PIX,
• cartão,
• ATM,
• APIs distribuídas.

---

🔥 DISPLAY DDF — O “PULMÃO” DAS CONEXÕES DISTRIBUÍDAS

Comando

-DIS DDF

---

💾 O QUE É DDF?

DDF = Distributed Data Facility.

É o componente responsável pelas conexões:

• JDBC,
• Java,
• APIs,
• microservices,
• aplicações distribuídas,
• Linux,
• cloud.

Ou seja:

praticamente o mundo moderno acessa DB2 via DDF.

---

🚨 O QUE O SYSPOG ANALISA?

STATUS=STOPD

🔥 Grave.

Significa:

• aplicações externas perderam conexão.

---

CONDBAT EXCEDIDO

Pode indicar:

• excesso de conexões,
• pool mal configurado,
• tempestade de microservices.

---

💣 DISPLAY LOCKS — O DETETIVE DE CRIMES EM PRODUÇÃO

Comando

-DIS LOCKS

---

🔥 O QUE ELE MOSTRA?

• locks ativos,
• quem segura lock,
• recursos travados,
• deadlocks,
• waits.

---

💾 CENÁRIO CLÁSSICO

Batch noturno:

UPDATE MASSIVO

segura lock exclusivo.

Resultado:

• CICS trava,
• online para,
• filas aumentam,
• CPU sobe,
• usuários reclamam.

E então o DBA roda:

-DIS LOCKS

e encontra o culpado.

---

🔥 DISPLAY UTIL — O “CENTRO CIRÚRGICO” DO DB2

Comando

-DIS UTIL(*)

---

💾 O QUE MOSTRA?

Utilities ativas:

• REORG,
• COPY,
• LOAD,
• RUNSTATS,
• RECOVER.

---

🚨 O QUE UM DBA OBSERVA?

Utility presa

Pode indicar:

• lock,
• falta de espaço,
• erro dataset,
• deadlock utility.

---

REORG eterno

Pode indicar:

• tablespace gigantesca,
• I/O saturado,
• SORT insuficiente.

---

🔥 DISPLAY LOG — O DNA TRANSACIONAL DO DB2

Comando

-DIS LOG

---

💾 O QUE ANALISAR?

• active logs,
• archive logs,
• checkpoints,
• dual logging,
• status de escrita.

---

🚨 LOG LOTADO = CAOS

Se active logs saturam:

• aplicações param,
• commits travam,
• DB2 entra em pressão severa.

Pouca gente percebe:

o log é literalmente o sistema nervoso do DB2.

---

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

Comando

-DIS BPOOL(*)

---

💾 O QUE É BUFFERPOOL?

Cache inteligente do DB2.

Armazena:

• páginas,
• índices,
• dados recentes.

Quanto melhor o bufferpool:

• menos disco,
• menos I/O,
• menos CPU.

---

🚨 O QUE UM SYSPOG ANALISA?

PGFIX(NO)

Pode aumentar:

• paging,
• CPU,
• overhead.

---

VPSIZE PEQUENO

Pode causar:

• sync I/O,
• leituras físicas excessivas.

---

HIT RATIO BAIXO

Indica:

• cache ineficiente,
• memória insuficiente.

---

💣 A VERDADE QUE POUCOS ACEITAM

Muitos problemas “de SQL” são:

problemas de bufferpool.

---

🔥 EXECUTANDO VIA JCL BATCH

O verdadeiro poder aparece no batch.

---

💾 EXEMPLO REAL

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

---

🚨 O ERRO CLÁSSICO

Você encontrou:

IKJ56500I COMMAND DSN NOT FOUND

Isso significa:

• SDSNLOAD ausente,
• DB2 runtime não alocado,
• comando DSN indisponível.

É um dos erros mais clássicos do mundo DB2 batch.

---

💾 O QUE É SDSNLOAD?

Biblioteca que contém:

• DSN,
• utilities,
• runtime DB2,
• SPUFI,
• módulos administrativos.

Sem ela:

não existe DB2 no batch.

---

🔥 O QUE SEPARA JUNIOR DE VETERANO

O iniciante:

• olha dashboard.

O veterano:

• olha DISPLAY THREAD,
• DISPLAY LOCKS,
• DISPLAY LOG,
• BUFFERPOOL,
• utilities,
• waits.

Porque ele sabe:

o DB2 sempre dá sinais antes do desastre.

---

☕ A FILOSOFIA DO SYSPOG MAINFRAME

No mundo distribuído:

• muita gente troca ferramenta.

No IBM Z:

• primeiro se entende o problema.

E o painel de comandos DB2 continua sendo:

• rápido,
• confiável,
• preciso,
• resiliente,
• praticamente eterno.

Quarenta anos depois…
ele ainda está ali.

Piscando em verde, azul ou branco no 3270.

Esperando alguém digitar:

-DIS THD(*)

…e descobrir o que realmente está acontecendo dentro do Mainframe IBM Z 🔥💾

 

Bellacosa Mainframe explica sysout 

Como Interpretar SYSOUT num JOB e Quais DDs Auxiliam o JCL

Quando começamos a trabalhar com:

• JCL;

• JES2;

• SDSF;

• spool;

• processamento batch;

uma das habilidades mais importantes é aprender a:

interpretar SYSOUT.

É no SYSOUT que normalmente descobrimos:

• erros;

• resultados;

• mensagens;

• ABENDs;

• comportamento do programa.

Além disso, existem vários cartões:

DD (Data Definition)

que ajudam o JCL e o programa durante execução.

---

Primeiro: o que é SYSOUT?

SYSOUT significa:

System Output.

É a saída gerada durante execução do JOB.

---

O SYSOUT pode conter:

• mensagens COBOL;

• relatórios;

• DISPLAY;

• SQLCODE;

• erros;

• estatísticas;

• logs batch.

---

Onde visualizar SYSOUT?

Principalmente no:

SDSF.

---

Como acessar?

SDSF

Depois:

ST

Selecionar JOB:

?

ou:

S

---

O que aparece no spool?

Arquivos como:

• JESJCL;

• JESMSGLG;

• JESYSMSG;

• SYSOUT;

• CEEDUMP.

---

O SYSOUT é diferente dos outros arquivos

---

JESJCL

Mostra JCL interpretado.

---

JESMSGLG

Mensagens JES2.

---

JESYSMSG

Mensagens do sistema.

---

SYSOUT

Saída da aplicação/programa.

---

Exemplo simples de SYSOUT

Programa COBOL:

DISPLAY 'PROCESSAMENTO OK'

No spool aparece:

PROCESSAMENTO OK

---

O que analisar primeiro no SYSOUT?

---

1. Return Code (RC)

Exemplo:

CC 0000

Sucesso.

---

2. Mensagens de erro

Procurar:

• ERROR;

• ABEND;

• SQLCODE;

• FILE STATUS.

---

3. Quantidade processada

Exemplo:

REGISTROS LIDOS: 15000

---

4. Tempo de execução

---

5. Estatísticas batch

---

Exemplo de SYSOUT típico

INICIO PROCESSAMENTO
ARQUIVO ABERTO
1000 REGISTROS PROCESSADOS
FIM NORMAL

---

Como identificar problemas?

---

Mensagens COBOL

IGZ0006S

Erro COBOL.

---

SQLCODE

SQLCODE = -911

Problema DB2.

---

FILE STATUS

FILE STATUS 35

Arquivo não encontrado.

---

ABEND

S0C7

Erro numérico.

---

O que são cartões DD?

DD significa:

Data Definition.

São instruções JCL que definem:

• arquivos;

• SYSOUT;

• bibliotecas;

• parâmetros.

---

Exemplo básico

//SYSOUT DD SYSOUT=*

---

Principais cartões DD que auxiliam o JCL

---

SYSOUT

Define saída do spool.

---

SYSIN

Entrada de parâmetros/comandos.

---

SYSPRINT

Mensagens e relatórios do programa.

---

SYSUDUMP

Dump em caso de erro.

---

CEEDUMP

Dump do Language Environment.

---

STEPLIB

Bibliotecas de LOAD modules.

---

JOBLIB

Bibliotecas do JOB inteiro.

---

SORTIN

Entrada do SORT.

---

SORTOUT

Saída do SORT.

---

SYSABOUT

Dump do sistema.

---

SYSDBOUT

Mensagens DB2.

---

Explicando os principais DDs

---

SYSOUT DD

Muito comum:

//SYSOUT DD SYSOUT=*

Envia saída para spool.

---

SYSIN DD

Usado para comandos/parâmetros.

Exemplo:

//SYSIN DD *
 SORT FIELDS=COPY
/*

---

STEPLIB DD

Define bibliotecas de programas.

Exemplo:

//STEPLIB DD DSN=MEU.LOADLIB,
// DISP=SHR

---

Sem STEPLIB…

Pode ocorrer:

S806

Programa não encontrado.

---

SYSPRINT DD

Saída de relatórios e logs.

---

Exemplo

//SYSPRINT DD SYSOUT=*

---

SYSUDUMP DD

Gera dump para análise de ABEND.

---

Exemplo

//SYSUDUMP DD SYSOUT=*

---

Muito importante em troubleshooting

---

CEEDUMP DD

Dump do:

Language Environment.

Muito usado em:

• COBOL;

• C;

• PL/I.

---

JOBLIB vs STEPLIB

---

JOBLIB

Vale para todo JOB.

---

STEPLIB

Vale apenas para STEP específico.

---

Exemplo JOBLIB

//JOBLIB DD DSN=EMPRESA.LOADLIB,
// DISP=SHR

---

Exemplo STEPLIB

//STEPLIB DD DSN=TESTE.LOADLIB,
// DISP=SHR

---

Como interpretar SYSOUT corretamente?

---

Ler começo e final

---

Procurar:

• RC;

• ERROR;

• SQLCODE;

• ABEND.

---

Verificar contadores

---

Conferir datasets

---

Observar mensagens JES2

---

Exemplo completo de troubleshooting

---

RC

CC 0012

---

SYSOUT mostra:

FILE STATUS 35

---

Conclusão

Arquivo não encontrado.

---

Fluxo ideal de análise

RC
 ↓
JESMSGLG
 ↓
JESYSMSG
 ↓
SYSOUT
 ↓
DUMP
 ↓
SOLUÇÃO

---

Curiosidades incríveis

1. Grandes batchs geram milhões de linhas de SYSOUT

---

2. Operadores monitoram SYSOUT constantemente

---

3. Muitas falhas só aparecem no SYSPRINT

---

4. Dumps podem ocupar enorme espaço spool

---

Erros comuns de iniciantes

---

1. Ignorar SYSOUT

---

2. Não usar SYSUDUMP

Dificulta troubleshooting.

---

3. Esquecer STEPLIB

Causa S806.

---

4. Não analisar SQLCODE

Muito importante em DB2.

---

Dicas importantes

Sempre utilize:

//SYSOUT DD SYSOUT=*

---

Durante testes inclua:

//SYSUDUMP DD SYSOUT=*

---

Aprenda FILE STATUS COBOL

---

Leia JESYSMSG junto com SYSOUT

---

Como isso aparece no dia a dia?

Praticamente em tudo:

• COBOL;

• DB2;

• SORT;

• CICS batch;

• automação;

• produção.

---

Resumo rápido

DD	Função
SYSOUT	Saída spool
SYSIN	Entrada comandos
SYSPRINT	Relatórios/logs
SYSUDUMP	Dump erro
CEEDUMP	Dump LE
STEPLIB	Biblioteca programa
JOBLIB	Biblioteca JOB

---

Conclusão

Interpretar SYSOUT é uma das habilidades mais importantes no ambiente mainframe IBM Z.

É através dele que operadores e programadores analisam resultados, identificam erros, entendem ABENDs e realizam troubleshooting eficiente em JOBs batch no z/OS.

 

Bellacosa Mainframe explicando abend para padawan

ABEND Explicado para Iniciantes

Quando alguém começa a trabalhar com:

• COBOL;

• JCL;

• SDSF;

• JES2;

• batch no z/OS;

rapidamente encontra uma palavra que assusta muitos iniciantes:

ABEND

E normalmente surge a pergunta:

“O que aconteceu com meu JOB?”

A resposta geralmente é:

ocorreu um ABEND.

---

O que significa ABEND?

ABEND significa:

Abnormal End

Em português:

término anormal.

---

Definição simples

ABEND acontece quando:

um JOB ou programa termina com erro inesperado.

Ou seja:
o processamento não conseguiu continuar normalmente.

---

Analogia simples

Imagine uma fábrica.

Tudo funciona normalmente:

• máquinas;

• produção;

• esteiras.

Mas de repente:

• falta peça;

• quebra equipamento;

• ocorre falha elétrica.

A produção para abruptamente.

ABEND é exatamente isso:

uma interrupção anormal do processamento.

---

O que acontece quando ocorre ABEND?

O z/OS:

• interrompe execução;

• grava mensagens;

• gera logs;

• salva informações para diagnóstico.

Tudo aparece no:

spool.

---

Onde analisar ABEND?

Principalmente:

• SDSF;

• JESMSGLG;

• JESYSMSG;

• SYSOUT;

• CEEDUMP.

---

Como identificar ABEND?

No SDSF normalmente aparece:

ABEND=S0C7

ou:

ABEND=U4038

---

Tipos de ABEND

Existem dois grandes grupos:

---

System ABEND

Começa com:

S

Exemplo:

S0C7

Gerado pelo:

sistema operacional.

---

User ABEND

Começa com:

U

Exemplo:

U4038

Gerado pelo:

programa/aplicação.

---

Origem histórica do ABEND

Desde os primeiros mainframes IBM, era necessário:

• detectar falhas;

• proteger memória;

• impedir corrupção de dados.

Então o sistema passou a gerar:

códigos de término anormal.

Isso evoluiu para os famosos:

ABENDs.

---

Como ler um ABEND?

---

Exemplo

S0C7

---

S

System ABEND.

---

0C7

Código específico do erro.

---

ABENDs mais comuns no mainframe

---

S0C7

Erro de dados numéricos

O mais famoso do COBOL.

---

O que causa?

Campo numérico inválido.

---

Exemplo

Programa espera:

12345

mas recebe:

12A45

---

Muito comum em:

• COMP-3;

• PACKED;

• DISPLAY numérico.

---

Como resolver?

• validar dados;

• revisar layouts;

• conferir FILE STATUS;

• analisar campo inválido.

---

S0C4

Violação de memória

Programa tentou acessar área inválida.

---

Causas comuns

• ponteiro errado;

• tabela fora do limite;

• endereço inválido.

---

Muito comum em

• Assembler;

• COBOL avançado;

• CICS.

---

S806

Programa não encontrado

---

Causa

Módulo inexistente na STEPLIB/LINKLIST.

---

Solução

• verificar LOADLIB;

• conferir nome do programa;

• validar bibliotecas.

---

SB37

Falta de espaço em disco

---

Causa

Dataset sem espaço suficiente.

---

Solução

Aumentar:

• SPACE;

• volume;

• secondary allocation.

---

SD37

Sem espaço em diretório/bloco.

---

SE37

Extensões máximas atingidas.

---

S222

JOB cancelado

Normalmente por operador.

---

S322

Timeout

JOB excedeu tempo permitido.

---

U4038

Erro da aplicação

Muito comum em:

• COBOL;

• CICS;

• LE.

---

Pode indicar

• STOP RUN incorreto;

• CALL inválido;

• falha lógica.

---

O que é CEEDUMP?

Dump gerado pelo:

Language Environment.

Ajuda debugging:

• COBOL;

• C;

• PL/I.

---

O que analisar primeiro?

---

1. RC / ABEND

No SDSF.

---

2. JESMSGLG

Mensagens JES2.

---

3. JESYSMSG

Mensagens sistema.

---

4. SYSOUT

Saída programa.

---

5. CEEDUMP

Detalhes técnicos.

---

Fluxo ideal de análise

ABEND
 ↓
RC
 ↓
JESMSGLG
 ↓
JESYSMSG
 ↓
SYSOUT
 ↓
CEEDUMP
 ↓
CAUSA

---

O que é dump?

Captura do estado da memória durante erro.

---

Dumps ajudam a descobrir:

• variáveis;

• registradores;

• instruções;

• falha exata.

---

Como operadores analisam ABEND?

Eles verificam:

• mensagens JES2;

• status batch;

• spool;

• impacto operacional.

---

Como programadores analisam ABEND?

Eles procuram:

• linha COBOL;

• SQLCODE;

• FILE STATUS;

• dumps;

• variáveis.

---

Como ABEND aparece no spool?

Mensagens típicas:

IEC141I

IGZ0006S

CEE3207S

---

Mensagens importantes

---

IGZ

Mensagens COBOL.

---

IEC

Mensagens de dataset/storage.

---

IEF

Mensagens JCL/sistema.

---

CEE

Mensagens Language Environment.

---

Dicas importantes para iniciantes

---

Sempre leia o final do spool

---

Procure:

• ABEND;

• ERROR;

• IEC;

• SQLCODE.

---

Aprenda principais códigos

S0C7 salva vidas no mainframe.

---

Use FIND no SDSF

Exemplo:

F ABEND

---

Curiosidades incríveis

1. Alguns ABENDs existem há décadas

---

2. Operadores experientes decoram dezenas de códigos

---

3. S0C7 é praticamente lendário no COBOL

---

4. Grandes bancos possuem equipes especializadas em troubleshooting de ABEND

---

Erros comuns de iniciantes

---

1. Ignorar JESYSMSG

Ali estão muitas pistas.

---

2. Ler apenas SYSOUT

Erro pode estar em outro arquivo.

---

3. Não analisar CEEDUMP

Fundamental em COBOL.

---

4. Assustar-se com qualquer ABEND

Muitos são simples de resolver.

---

Como evitar ABEND?

---

Validar dados

---

Conferir datasets

---

Revisar JCL

---

Verificar SPACE

---

Testar programas

---

Usar tratamento de erro COBOL

---

Como ABEND aparece no dia a dia?

Praticamente em tudo:

• COBOL;

• DB2;

• CICS;

• SORT;

• batch;

• automação.

---

Resumo rápido

ABEND	Significado
S0C7	Erro numérico
S0C4	Violação memória
S806	Programa não encontrado
SB37	Falta espaço
S322	Timeout
U4038	Erro aplicação

---

Conclusão

ABEND é o mecanismo usado pelo z/OS para indicar falhas anormais durante execução de JOBs e programas.

Aprender a interpretar ABENDs, analisar spool e entender mensagens do sistema é uma das habilidades mais importantes para qualquer profissional mainframe IBM Z.

Bellacosa Mainframe como ler e entender o spool do sdsf

Como Ler, Entender e Analisar as Mensagens no Spool

Uma das habilidades mais importantes no mundo mainframe é aprender a:

• interpretar spool;

• entender mensagens JES2;

• analisar erros;

• identificar ABENDs;

• descobrir por que um JOB falhou.

Quem domina spool consegue:

• resolver problemas rapidamente;

• entender processamento batch;

• analisar COBOL;

• trabalhar com operações z/OS.

---

Primeiro: o que é spool?

Spool é a área onde ficam armazenados:

• logs;

• SYSOUT;

• mensagens;

• relatórios;

• saídas batch.

Tudo que acontece em um JOB normalmente aparece no:

spool.

---

Onde visualizar o spool?

Principalmente no:

SDSF.

---

Entrando no SDSF

Digite:

SDSF

---

Painel mais usado

ST

Mostra:

• JOBs;

• status;

• JOBID;

• RC.

---

Exemplo típico

NP JOBNAME JOBID OWNER STATUS

---

Como abrir spool do JOB?

Digite:

?

ou:

S

ao lado do JOB.

---

O que aparece dentro do spool?

Arquivos importantes:

• JESJCL;

• JESMSGLG;

• JESYSMSG;

• SYSOUT;

• CEEDUMP.

---

A ordem correta de análise

Iniciantes costumam se perder.

O ideal é seguir esta sequência:

---

1. Verificar RC

Return Code

---

Exemplo

CC 0000

Indica:

sucesso.

---

Outros exemplos

CC 0004

Warning.

CC 0008

Erro moderado.

CC 0012

Erro grave.

---

Se houver ABEND

Exemplo:

S0C7

ou:

U4038

Então existe erro anormal.

---

2. Ler JESMSGLG

Um dos arquivos mais importantes.

Ele mostra:

• mensagens JES2;

• início do JOB;

• fim do JOB;

• alocação;

• spool;

• status batch.

---

Mensagens clássicas

$HASP373 JOB STARTED

JOB iniciado.

---

$HASP395 JOB ENDED

JOB finalizado.

---

O que procurar?

• dataset não encontrado;

• problemas de autorização;

• falhas JCL;

• mensagens system.

---

3. Ler JESJCL

Mostra:

como o sistema interpretou o JCL.

---

Muito útil para encontrar:

• erros de sintaxe;

• parâmetros inválidos;

• datasets errados.

---

Exemplo comum

JCL ERROR

---

4. Ler JESYSMSG

Mostra mensagens do:

z/OS.

Muito importante para:

• alocação;

• datasets;

• ABENDs;

• execução.

---

Mensagens clássicas

---

Dataset não encontrado

DATA SET NOT FOUND

---

Falta de espaço

SPACE NOT AVAILABLE

---

Dataset em uso

DATA SET IN USE

---

5. Ler SYSOUT

Aqui normalmente aparece:

• saída COBOL;

• relatórios;

• DISPLAY;

• resultados do programa.

---

Exemplo COBOL

DISPLAY 'PROCESSAMENTO OK'

Aparece no SYSOUT.

---

Como identificar erros COBOL?

Procurar:

• FILE STATUS;

• SQLCODE;

• ABEND;

• mensagens LE.

---

O que é ABEND?

Abnormal End

Erro anormal de execução.

---

ABENDs famosos

---

S0C7

Erro de dados numéricos.

Muito comum em COBOL.

---

S0C4

Violação de memória.

---

S806

Programa não encontrado.

---

SB37

Falta de espaço em disco.

---

O que é CEEDUMP?

Dump gerado pelo:

Language Environment (LE).

Ajuda debugging COBOL.

---

Como analisar spool corretamente?

---

Comece pelo fim

Muitos erros aparecem perto do final.

---

Procure palavras-chave

• ERROR

• ABEND

• IEC

• IEF

• SQLCODE

• NOT FOUND

---

Observe mensagens $HASP

Elas mostram:

• início;

• fim;

• status.

---

Exemplo completo de análise

---

Passo 1

RC:

CC 0012

Problema detectado.

---

Passo 2

JESMSGLG mostra:

IEF212I DATA SET NOT FOUND

---

Passo 3

Identificar dataset incorreto no JCL.

---

Resultado

Erro encontrado.

---

Como operadores analisam spool?

Eles verificam:

• falhas batch;

• tempo de execução;

• filas;

• spool;

• mensagens críticas.

---

Como programadores analisam spool?

Eles procuram:

• ABEND;

• SQLCODE;

• DISPLAY;

• SYSOUT;

• retorno COBOL.

---

Curiosidades incríveis

1. Operadores passam horas analisando spool diariamente

---

2. Grandes bancos geram milhões de linhas de spool

---

3. Muitas falhas críticas são descobertas apenas lendo spool

---

4. Saber interpretar mensagens é habilidade extremamente valorizada

---

Erros comuns de iniciantes

---

1. Ignorar RC

Primeira coisa que deveria ser verificada.

---

2. Ler apenas SYSOUT

Muitas falhas aparecem no JESMSGLG.

---

3. Não entender ABEND

ABEND indica erro sério.

---

4. Procurar erro no começo do spool

Frequentemente está no final.

---

Dicas extremamente importantes

Sempre leia:

• JESMSGLG;

• JESYSMSG;

• SYSOUT.

---

Aprenda mensagens IEC e IEF

São muito comuns.

---

Memorize principais ABENDs

Isso acelera troubleshooting.

---

Use FIND no SDSF

Exemplo:

F ERROR

---

Como isso aparece no dia a dia?

Praticamente em tudo:

• COBOL;

• DB2;

• SORT;

• batch;

• automação;

• operações;

• suporte.

---

Fluxo mental ideal

RC
 ↓
JESMSGLG
 ↓
JESYSMSG
 ↓
SYSOUT
 ↓
ABEND
 ↓
CORREÇÃO

---

Por que aprender análise de spool?

Porque isso é:

uma das habilidades mais importantes do z/OS.

Quem domina spool domina:

• troubleshooting;

• batch;

• operações;

• COBOL;

• JES2;

• SDSF.

---

Resumo rápido

Arquivo	Função
JESJCL	JCL interpretado
JESMSGLG	Mensagens JES2
JESYSMSG	Mensagens do sistema
SYSOUT	Saída da aplicação
CEEDUMP	Dump COBOL/LE

---

Conclusão

Aprender a ler e interpretar mensagens no spool é fundamental para qualquer profissional mainframe.

O spool contém todas as informações necessárias para entender o comportamento dos JOBs, identificar erros, analisar ABENDs e realizar troubleshooting eficiente no ambiente z/OS IBM Z.