Translate

Mostrar mensagens com a etiqueta STEPLIB. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta STEPLIB. Mostrar todas as mensagens

sábado, 28 de dezembro de 2013

☕🔥 ABEND S806 — O “PROGRAMA FANTASMA” DO z/OS

 

Bellacosa Mainframe e o Abend S806

☕🔥 ABEND S806 — O “PROGRAMA FANTASMA” DO z/OS

Quando o Mainframe Diz:

“EU NÃO ENCONTREI O QUE VOCÊ MANDOU EXECUTAR.”

Se existe um ABEND que já fez TODO programador COBOL Junior Padawan olhar para o JCL em silêncio absoluto…

é o lendário:

🚨 S806

E normalmente ele aparece assim:

IEF450I JOBNAME STEP01 - ABEND=S806

ou:

CSV028I ABEND806-04 JOBNAME STEP01
PROGRAM PROGXYZ NOT FOUND

ou ainda:

IEC130I PROGRAM NOT FOUND

E então começa a crise existencial:

“MAS O PROGRAMA EXISTE!”
“EU COMPILEI!”
“FUNCIONAVA ONTEM!”
“O LOADLIB SUMIU?”
“O z/OS ESTÁ ME GASLIGHTEANDO?”

☕ Respira.

Porque o S806 é um dos ABENDs MAIS CLÁSSICOS da história do mainframe.

E um dos mais importantes para aprender:

JCL

LOADLIB

STEPLIB

LINKLIST

BINDER

EXEC PGM

load modules


🔥 O QUE É O S806?

O S806 é um:

🚨 PROGRAM NOT FOUND

Traduzindo:

O z/OS NÃO CONSEGUIU ENCONTRAR O PROGRAMA EXECUTÁVEL.


☕ A FILOSOFIA DO S806

Seu JCL disse:

//STEP1 EXEC PGM=COBPROG

O z/OS respondeu:

❌ “NÃO EXISTE NENHUM EXECUTÁVEL COM ESSE NOME NOS LUGARES ONDE PROCUREI.”


🔥 O QUE O z/OS FAZ QUANDO VÊ EXEC PGM=

Fluxo real:

EXEC PGM=PROG1
 ↓
Procurar módulo
 ↓
STEPLIB
 ↓
JOBLIB
 ↓
LNKLST
 ↓
SYS1.LINKLIB
 ↓
Encontrou?

Se NÃO:

💥 S806


☕ ANALOGIA BELLACOSA MAINFRAME

Imagine um aeroporto.

O sistema anuncia:

“CHAMEM O PILOTO DO VOO.”

Mas:

  • piloto não apareceu

  • nome errado

  • terminal errado

  • aeroporto errado

  • piloto nem existe

O voo nunca sai.

Isso é o:

☠️ S806


🔥 O MAIOR SEGREDO

S806 NÃO significa:

“source COBOL não existe.”

Significa:

o LOAD MODULE executável não foi encontrado.


☕ SOURCE ≠ EXECUTÁVEL

Isso traumatiza juniors.

Você pode ter:

✅ source COBOL
✅ compile OK

Mas sem:

LINK-EDIT/BINDER

não existe executável.


🔥 O MAIOR VILÃO DO S806

🚨 STEPLIB ERRADA

O rei absoluto.


☕ EXEMPLO CLÁSSICO

 //STEPLIB DD DSN=EMPRESA.TEST.LOAD,DISP=SHR

Mas o programa está em:

EMPRESA.PROD.LOAD

Resultado:

💥 S806


🔥 O ERRO MAIS HUMANO DA HISTÓRIA

//STEP1 EXEC PGM=COBPRG1

Mas o member real é:

COBPROG1

Faltou:

O

Resultado:

☠️ S806


☕ O MAINFRAME NÃO “ADIVINHA”

No z/OS:

nome precisa ser EXATO.


🔥 O S806 E O BINDER

Aqui nasce o verdadeiro conhecimento Jedi.


☕ O QUE É O BINDER?

Ferramenta que cria:

LOAD MODULES

Executáveis do z/OS.


🔥 FLUXO REAL COBOL

SOURCE COBOL
 ↓
COMPILER
 ↓
OBJETO
 ↓
BINDER/LINK-EDIT
 ↓
LOAD MODULE
 ↓
EXECUÇÃO

Se faltar binder:

💥 S806


☕ O ERRO CLÁSSICO DO PADAWAN

“Compilei com sucesso.”

Mas esqueceu:

LINK-EDIT


🔥 O S806 E O FTP ASCII

Lenda urbana real.

Load module transferido em:

ASCII

ao invés de:

BINARY

O executável vira lixo hexadecimal.

Às vezes:

  • S806

  • S0C1

  • S0C4

dependendo do dano.


☕ O S806 E O CALL

Outro clássico COBOL.

CALL 'CALCPGM'

Mas:

CALCPGM não existe na loadlib

Resultado:

💥 S806


🔥 O CALL DINÂMICO MALDITO

CALL WS-PGM

Mas:

WS-PGM = 'ABC123'

e esse módulo não existe.


☕ O S806 E O CICS

No CICS normalmente aparece como:

🚨 PGMIDERR

ou:

AEI0

ASRA

dependendo do cenário.


🔥 O S806 E O DB2

Outro clássico sombrio.

Programa depende de runtime DB2:

DSNHLI

ou módulos LE.

STEPLIB errada?

☠️ caos.


☕ COMO INVESTIGAR O S806 PASSO A PASSO


✅ PASSO 1 — IDENTIFIQUE O PROGRAMA

Mensagem:

CSV028I ABEND806-04 PROGRAM PROGXYZ NOT FOUND

Suspeito identificado.


✅ PASSO 2 — VERIFIQUE STEPLIB

Veja:

//STEPLIB DD DSN=...

Confirme:

  • dataset correto

  • DISP=SHR

  • biblioteca existe


✅ PASSO 3 — USE ISPF 3.4

Procure o member.

Existe?

PROGXYZ

✅ PASSO 4 — CONFIRA O NOME

Mainframe não perdoa:

  • typo

  • espaço

  • caractere errado


✅ PASSO 5 — VERIFIQUE O BINDER

Talvez o módulo nunca tenha sido gerado.


🔥 O SEGREDO DO ISPF 3.4

Veteranos vivem nele.

Comandos:

MEMBER

ou:

B

ajudam localizar executáveis.


☕ O S806 E O LNKLST

Se não há STEPLIB/JOBLIB:

o z/OS procura em:

LINKLIST

Bibliotecas globais do sistema.


🔥 O S806 FANTASMA

O mais traiçoeiro.

Funcionava ontem.

Hoje:

💥 S806

Porque:

  • loadlib mudou

  • promoção falhou

  • member deletado

  • IEBCOPY sobrescreveu

  • deploy incompleto


☕ O S806 E O PDSE

Hoje muitos ambientes usam:

PDSE

Mais moderno que PDS.

Mas problemas de sincronização e membros ainda acontecem.


🔥 O S806 E O JCLLIB

Às vezes o PROC aponta:

biblioteca errada

E o EXEC herda erro invisível.


☕ O DUMP DO S806

Normalmente pouco útil.

Porque o programa:

NEM CHEGOU A EXECUTAR.

O problema ocorre ANTES.


🔥 O OURO ESTÁ NAS MENSAGENS

Especialmente:

CSV028I
IEF452I
IEWxxxx

☕ COMO O VETERANO PENSA

Veterano vê:

S806

e imediatamente pergunta:

“ONDE ESTÁ A LOADLIB?”


🔥 CURIOSIDADE HISTÓRICA

O S806 vem da era:

IBM OS/360

Década de:

🏛️ 1960

Naquela época:

  • programas eram carregados fisicamente de bibliotecas em disco/tape

  • loader era parte vital do sistema

O S806 virou um dos ABENDs mais clássicos da história corporativa.


☕ EASTER EGG MAINFRAME

Veteranos brincam:

“S806 é o z/OS dizendo:

VOCÊ TEM CERTEZA QUE ESSE PROGRAMA EXISTE?”


🔥 O MAIOR ERRO DO PADAWAN

Ver:

S806

e recompilar COBOL.

Frequentemente o problema NÃO está no source.

Está em:

  • loadlib

  • binder

  • STEPLIB

  • deploy

  • member

  • ambiente


☕ COMO EVITAR S806


✅ Validar STEPLIB


✅ Confirmar LOADLIB


✅ Revisar BINDER


✅ Nunca FTP executável em ASCII


✅ Conferir nome do member


✅ Padronizar deploy


✅ Validar CALLs dinâmicos


🔥 A VERDADE FINAL

O S0C7 pune números inválidos.
O S0C4 pune memória inválida.
O S013 pune datasets incompatíveis.
O S322 pune tempo excessivo.
O S306 pune falhas de carregamento.

Mas…

☕ O S806 É O MOMENTO EM QUE O z/OS PROCURA UM PROGRAMA… E ENCONTRA APENAS O VAZIO.

terça-feira, 24 de setembro de 2013

☕🔥 ABEND S306 — O “PORTAL QUE NÃO ABRIU” DO z/OS

 

Bellacosa Mainframe abend s306

☕🔥 ABEND S306 — O “PORTAL QUE NÃO ABRIU” DO z/OS

Quando o Mainframe Diz:

“EU NÃO CONSIGO INICIAR ESSE PROGRAMA.”

Se existe um ABEND que faz o Junior Padawan olhar para o JCL como se fosse um grimório amaldiçoado…

é o lendário:

🚨 S306

E normalmente ele aparece assim:

IEF452I JOBNAME STEP1 - ABEND=S306

ou:

CSV003I REQUESTED MODULE NOT FOUND

ou ainda:

PROGRAM FETCH FAILED

E então o desespero começa:

“O programa sumiu?”
“A loadlib evaporou?”
“O COBOL compilou errado?”
“O JES2 perdeu meu módulo?”
“O STEPLIB abriu um portal para outra dimensão?”

☕ Respira.

Porque o S306 é um dos ABENDs MAIS IMPORTANTES para entender:

load modules

STEPLIB

JOBLIB

program fetch

link-edit

APF

bibliotecas z/OS


🔥 O QUE É O S306?

O S306 é um:

🚨 PROGRAM FETCH ERROR

Traduzindo:

O z/OS NÃO CONSEGUIU CARREGAR O PROGRAMA NA MEMÓRIA.


☕ A FILOSOFIA DO S306

Seu JCL disse:

//STEP1 EXEC PGM=COBPROG

O z/OS respondeu:

❌ “EU NÃO ENCONTREI OU NÃO CONSEGUI CARREGAR ESSE MÓDULO.”


🔥 O QUE É “FETCH”?

FETCH é o processo de:

localizar

carregar

preparar

o programa executável na memória.


☕ O FLUXO DA MAGIA

EXEC PGM=PROG1
 ↓
Loader/Search
 ↓
STEPLIB/JOBLIB/LNKLST
 ↓
Load Module encontrado?
 ↓
Carregar memória
 ↓
Executar

Se algo falha:

💥 S306


🔥 ANALOGIA BELLACOSA MAINFRAME

Imagine um teatro.

O diretor diz:

“TRAGAM O ATOR PRINCIPAL.”

Mas:

  • ator não existe

  • entrou pela porta errada

  • está trancado

  • veio versão incompatível

  • está corrompido

O espetáculo para.

Isso é o:

☠️ S306


☕ O MAIOR VILÃO DO S306

🚨 STEPLIB ERRADA

O campeão absoluto.


🔥 EXEMPLO CLÁSSICO

//STEPLIB DD DSN=EMPRESA.COBOL.LOAD,DISP=SHR

Mas o programa está em:

EMPRESA.TESTE.LOAD

Resultado:

☠️ S306


☕ O MAINFRAME PROCURA EM ORDEM


☕ STEPLIB

Biblioteca do STEP.


☕ JOBLIB

Biblioteca do JOB.


☕ LNKLST

Bibliotecas globais do sistema.


🔥 O SEGREDO

Se o módulo NÃO estiver em nenhum desses lugares:

💥 S306


☕ O S306 vs S806

Junior confunde MUITO.


☕ S806

Programa não encontrado.


☕ S306

Programa encontrado OU parcialmente localizado…

mas:

não conseguiu carregar/executar corretamente.


🔥 O CASO MAIS FAMOSO

LOAD MODULE CORROMPIDO


☕ COMO ISSO ACONTECE?

  • link-edit incompleto

  • PDS corrompido

  • módulo truncado

  • IEBCOPY errado

  • transferência FTP ASCII

  • member quebrado


🔥 O FTP ASCII DA MORTE

Lenda urbana real do mainframe.

Alguém transfere loadlib em:

ASCII

ao invés de:

BINARY

O executável vira lixo hexadecimal.

Resultado:

☠️ S306


☕ O S306 E O LINK-EDIT

Outro clássico.

Programa compilou.

Mas:

link-edit falhou

ou:

módulo incompleto

Resultado:

💥 S306


🔥 O S306 E O RENT/NORENT

Modo arquimago ativado.

Problemas com:

  • RENT

  • REUS

  • RMODE

  • AMODE

podem impedir carregamento correto.


☕ O S306 E O APF

Outro território sombrio.

Programas privilegiados precisam:

APF authorization

Se biblioteca APF estiver errada:

☠️ caos.


🔥 O S306 E O COBOL

Exemplo clássico:

CALL 'PGMXYZ'

Mas:

  • módulo não está na STEPLIB

  • nome errado

  • versão incorreta

Resultado:

💥 S306


☕ O CALL DINÂMICO MALDITO

Outro trauma coletivo.

CALL WS-PGM

Mas:

WS-PGM = 'PGM123'

e módulo não existe.


🔥 O S306 E O CICS

No CICS pode aparecer como:

ASRA

AEY9

PGMIDERR

dependendo do contexto.


☕ O S306 E O DB2

Outro clássico.

Programa depende de:

DSNHLI

ou módulos DB2 runtime.

Biblioteca errada?

💥 S306


🔥 COMO INVESTIGAR O S306 PASSO A PASSO


✅ PASSO 1 — IDENTIFIQUE O MÓDULO

Mensagem típica:

CSV003I REQUESTED MODULE PROG1 NOT FOUND

Agora temos o suspeito.


✅ PASSO 2 — VERIFIQUE STEPLIB/JOBLIB

Veja:

//STEPLIB DD ...

Confirme:

  • DSN correto

  • DISP correto

  • biblioteca existe


✅ PASSO 3 — USE ISPF 3.4

Procure:

member do load module

✅ PASSO 4 — VERIFIQUE O MEMBER

Existe mesmo?

PROG1

ou:

PROG01

Erro de nome é clássico.


✅ PASSO 5 — CONFIRA O LINK-EDIT

Talvez o módulo nunca tenha sido gerado.


🔥 O SEGREDO DOS LOAD MODULES

Load module NÃO é source.

É:

binário executável IBM Z.


☕ O QUE O DUMP DIZ

O dump do S306 geralmente aponta:

  • loader

  • fetch routine

  • CSV modules

  • search failure


🔥 MENSAGENS IMPORTANTES


☕ CSV003I

Loader/fetch issue.


☕ IEWxxxx

Problemas de binder/link-edit.


☕ IECxxxx

Possíveis problemas dataset.


🔥 O S306 E O BINDER

Outro mundo oculto.

O BINDER cria:

load modules executáveis

Se faltar:

  • INCLUDE

  • ENTRY

  • NAME

o módulo pode nascer defeituoso.


☕ O MAIOR ERRO DOS JUNIORS

Pensar:

“compilou = funciona.”

Não.

Compile ≠ executável válido.


🔥 O S306 FANTASMA

O mais traiçoeiro.

Programa funcionava ontem.

Hoje:

💥 S306

Porque:

  • loadlib mudou

  • versão errada entrou

  • IEBCOPY sobrescreveu

  • promoção falhou


☕ O S306 E O PDSE

Hoje muitos ambientes usam:

PDSE

Mais moderno que PDS.

Mas problemas de cache/member ainda podem gerar situações bizarras.


🔥 O S306 E O “NOT AUTHORIZED”

Às vezes o módulo existe.

Mas:

sem autorização.

Então:

  • RACF

  • APF

  • proteção de biblioteca

entram no jogo.


☕ COMO EVITAR S306


✅ Conferir STEPLIB


✅ Validar LOADLIB


✅ Confirmar member correto


✅ Nunca FTP loadlib em ASCII


✅ Revisar link-edit


✅ Padronizar promoção


✅ Verificar APF


🔥 CURIOSIDADE HISTÓRICA

Nos tempos do OS/360:

programas eram carregados diretamente de bibliotecas físicas em disco/tape.

O mecanismo de FETCH era parte crítica do sistema operacional.

S306 virou um dos erros clássicos da era dos load modules.


☕ EASTER EGG MAINFRAME

Veteranos brincam:

“S306 é o mainframe dizendo:

EU SEI QUE VOCÊ JURA QUE O PROGRAMA EXISTE… MAS EU NÃO ACREDITO.”


🔥 O MAIOR ENSINAMENTO DO S306

Ele ensina algo profundo:

no z/OS, EXECUTAR um programa é um ritual complexo.

Não basta existir source.

É preciso:

  • compilar

  • linkar

  • catalogar

  • localizar

  • autorizar

  • carregar


☕ A VERDADE FINAL

O S0C7 pune dados inválidos.
O S0C4 pune memória inválida.
O S013 pune datasets incompatíveis.
O S322 pune tempo excessivo.

Mas…

☕ O S306 PUNE PROGRAMAS QUE NÃO CONSEGUIRAM ATRAVESSAR O PORTAL DE LOAD DO z/OS.


quinta-feira, 15 de fevereiro de 2007

O que é Compilação e Linkedição de um Programa COBOL?

 

Bellacosa Mainframe o que é Compilação e Linkedição de um programa COBOL

O que é Compilação e Linkedição de um Programa COBOL?

Quando escrevemos um programa COBOL, o computador não executa diretamente o código-fonte.

Antes disso, ele precisa passar por duas etapas fundamentais:

Compilação

e

Linkedição (Link-Edit ou Binder)

Essas etapas transformam o código COBOL em um programa executável pelo z/OS.


Visão Geral

Código COBOL
     ↓
Compilação
     ↓
Objeto (OBJ)
     ↓
Linkedição (Binder)
     ↓
Load Module / Program Object
     ↓
Execução

O que é Compilação?

Compilação é o processo de converter:

Código COBOL

em

Código Objeto

Analogia Simples

Imagine que você escreveu um livro em português.

O compilador é um tradutor que converte o texto para um idioma que o processador entende.


Entrada da Compilação

Programa fonte:

IDENTIFICATION DIVISION.

PROGRAM-ID. HELLO.

PROCEDURE DIVISION.

DISPLAY 'OLA MUNDO'.

STOP RUN.

Saída da Compilação

Arquivo objeto:

OBJETO

Ainda não é executável.


O que o Compilador faz?

Durante a compilação ele:

✅ Analisa sintaxe

✅ Valida comandos COBOL

✅ Expande COPYBOOKs

✅ Verifica variáveis

✅ Gera instruções de máquina

✅ Produz mensagens de erro


Exemplo de erro

DISPLY 'OLA'

Resultado:

IGYPS2121-S

Erro de sintaxe.


Compilador COBOL

Nos ambientes IBM Z normalmente encontramos:

Enterprise COBOL for z/OS

O que é o Código Objeto?

Após a compilação é criado:

OBJETO

Também chamado de:

Object Deck
Object Module
OBJ

Características

  • Não executa sozinho

  • Pode conter referências externas

  • Precisa passar pelo Binder


O que é Linkedição?

Também chamada:

Link-Edit

ou

Binding


Função

Transformar o código objeto em um programa executável.


Fluxo

OBJETO
   ↓
BINDER
   ↓
LOAD MODULE

O que o Binder faz?

Ele:

✅ Resolve chamadas externas

✅ Liga subprogramas

✅ Liga bibliotecas

✅ Resolve referências CICS

✅ Resolve referências DB2

✅ Cria módulo executável


Analogia Simples

Imagine várias peças de LEGO.

A compilação cria as peças.

A linkedição monta tudo em um único brinquedo funcional.


Resultado Final

LOAD MODULE

ou

PROGRAM OBJECT

Onde fica o executável?

Normalmente em uma biblioteca:

USER.LOADLIB

ou

PROD.LOADLIB

Fluxo Completo

COBOL Source
      ↓
Compiler
      ↓
Object Module
      ↓
Binder
      ↓
Load Module
      ↓
JCL EXEC PGM=

Exemplo de Execução

JCL:

//STEP1 EXEC PGM=HELLO

O z/OS procura:

HELLO

na:

STEPLIB
JOBLIB
LINKLIST

O que é STEPLIB?

Biblioteca onde o executável está armazenado.


Exemplo

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

Chamadas entre Programas

Programa principal:

CALL 'CALCSAL'

Durante a Linkedição

O Binder procura:

CALCSAL

e conecta os módulos.


Linkedição com CICS

Programas CICS utilizam bibliotecas especiais.

Exemplo:

DFHEIBLK
DFHCOMMAREA

O Binder resolve essas referências.


Linkedição com DB2

Programas DB2 possuem etapas extras.

COBOL
 ↓
Pré-compilador DB2
 ↓
Compilação
 ↓
BIND DB2
 ↓
Linkedição

O que é BIND no DB2?

Não confundir com Binder.


Binder

Cria executável.


BIND DB2

Cria:

PACKAGE
PLAN

Principais Saídas da Compilação


SYSPRINT

Mensagens do compilador.


LISTING

Listagem fonte expandida.


OBJETO

Código objeto.


Principais Saídas da Linkedição


SYSPRINT

Mensagens Binder.


LOAD MODULE

Executável.


Erros Comuns de Compilação

Variável não declarada

IGYPS...

COPYBOOK inexistente

IGYDS...

Erro de sintaxe

IGYPS...

Erros Comuns de Linkedição

Módulo não encontrado

IEW2456E

Referência externa não resolvida

IEW2646S

Biblioteca ausente

IEW...

Ferramentas Envolvidas

EtapaFerramenta
CompilaçãoEnterprise COBOL
LinkediçãoBinder (IEWL)
Execuçãoz/OS Loader

Exemplo Real de JCL

//COBOL EXEC PGM=IGYCRCTL
//SYSIN DD DSN=USER.COBOL(PROG1)

//LKED EXEC PGM=IEWL
//SYSLMOD DD DSN=USER.LOADLIB(PROG1)

Curiosidades

1. Antigamente a saída da compilação era gravada em cartões perfurados

2. O Binder substituiu o antigo Linkage Editor

3. Um único programa pode ser ligado a dezenas de módulos externos

4. Grandes bancos compilam milhares de programas COBOL diariamente


Resumo Rápido

EtapaFunção
CompilaçãoGera código objeto
Código ObjetoSaída intermediária
BinderLiga módulos
LinkediçãoCria executável
Load ModulePrograma executável
STEPLIBBiblioteca de execução
CALLChama subprograma
BIND DB2Cria Package e Plan

Conclusão

A compilação converte o código COBOL em um módulo objeto, enquanto a linkedição (Binder) conecta todas as dependências e gera o módulo executável que será carregado pelo z/OS. Entender essas etapas é fundamental para diagnosticar erros de compilação, problemas de execução e compreender como os programas COBOL realmente funcionam no ambiente IBM Z.


sábado, 27 de janeiro de 2007

Como Interpretar SYSOUT num JOB e Quais DDs Auxiliam o JCL

 

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

DDFunção
SYSOUTSaída spool
SYSINEntrada comandos
SYSPRINTRelatórios/logs
SYSUDUMPDump erro
CEEDUMPDump LE
STEPLIBBiblioteca programa
JOBLIBBiblioteca 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.