✨ Bem-vindo ao meu espaço! ✨
Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens.
Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê.
Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão.
Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes
☕🔥 Guia Completo — ABENDs Clássicos do IBM OS/VS e z/OS
Excelente observação! No resumo anterior realmente ficaram faltando vários ABENDs importantes da lista original do artigo histórico do OS/VS. Agora segue a versão completa, revisada e expandida, incluindo TODOS os códigos mencionados no documento.
🔥 S013 — OPEN ERROR / DCB ERROR
Mensagem comum
IEC141I
O que significa
Falha ao abrir dataset.
Principais causas
BLKSIZE incompatível
RECFM incorreto
LRECL errado
Membro inexistente em PDS
Muito comum em
SORT
COBOL batch
IDCAMS
🔥 S0C1 — OPERATION EXCEPTION
O que significa
Execução de instrução inválida.
Causas
Overlay de memória
Programa corrompido
Executar área de dados como código
Compilação/link incorreto
🔥 S0C4 — PROTECTION EXCEPTION
O clássico absoluto do z/OS
O que significa
Acesso inválido à memória.
Causas comuns
Subscript fora do limite
Ponteiro inválido
Tabela ultrapassada
LINKAGE SECTION incorreta
🔥 S0C5 — ADDRESSING EXCEPTION
O que significa
Tentativa de acessar endereço inexistente.
Muito comum em
CALLs errados
Parâmetros incompatíveis
Ponteiros inválidos
🔥 S0C7 — DATA EXCEPTION
O ABEND mais famoso do COBOL
O que significa
Campo numérico contém valor inválido.
Exemplos clássicos
MOVE 'ABC' TO WS-VALOR-NUM
ADD 1 TO WS-VALOR-NUM
Principais causas
Campo COMP-3 corrompido
Dados não numéricos
Index fora da tabela
Working-storage sem inicialização
🔥 S106 — LINK/LOAD ERROR
O que significa
Falha durante LOAD ou LINK.
Causas
Biblioteca incorreta
Módulo inconsistente
Problema de disco
🔥 S213 — DATASET NOT FOUND
Mensagem comum
IEC143I
O que significa
Dataset inexistente.
Causas
DSNAME errado
Dataset não catalogado
VOL=SER incorreto
🔥 S222 — JOB CANCELADO
Mensagem comum
IEF301I
O que significa
Operador cancelou o job.
Normalmente ocorre por
Loop infinito
Job preso
Alto consumo
🔥 S2F3 — SYSTEM FAILURE
O que significa
Falha do sistema operacional durante execução.
Causas
Crash do sistema
IPL
Problema interno do z/OS
Procedimento
Reexecutar o job
Verificar logs do sistema
🔥 S322 — TIME EXCEEDED
O que significa
Job excedeu o tempo permitido.
Muito comum em
Loops infinitos
SQL sem índice
SORT gigantes
Exemplo
TIME=1
🔥 S613 — TAPE I/O ERROR
Mensagem comum
IEC147I
O que significa
Erro de I/O em fita magnética.
Causas
Fita mal posicionada
Multi-volume incorreto
Problema físico na fita
🔥 S722 — SYSOUT LIMIT EXCEEDED
O que significa
Quantidade de linhas impressas excedeu limite.
Muito comum em
LOOP com DISPLAY
Relatórios infinitos
Dumps excessivos
🔥 S804 — INSUFFICIENT VIRTUAL STORAGE
O que significa
Falta de memória virtual.
Causas
REGION pequena
Programa gigante
Uso excessivo de tabelas
Exemplo
REGION=512K
🔥 S806 — MODULE NOT FOUND
O loader não encontrou o módulo
Causas
STEPLIB errada
LOADLIB ausente
Nome incorreto do programa
Mensagem clássica
CSV003I REQUESTED MODULE NOT FOUND
🔥 S80A — STORAGE SHORTAGE
O que significa
Complemento do S804.
Causa principal
Falta de memória virtual disponível.
🔥 S813 — TAPE LABEL ERROR
Mensagem comum
IEC149I
O que significa
Nome do dataset na fita não bate com DD.
Causas
LABEL incorreto
DSNAME errado
Volume errado
🔥 S913 — RACF SECURITY VIOLATION
Mensagem comum
IEC150I
O que significa
Acesso negado pelo RACF.
Muito comum em
Produção
Db2
GDGs
VSAM corporativo
🔥 SA13 — END OF TAPE / FILE NOT FOUND
Mensagem comum
IEC151I
O que significa
Arquivo não encontrado na fita.
Causas
LABEL incorreto
Número sequencial errado
Volume incorreto
🔥 SB37 — OUT OF SPACE
Mensagem comum
IEC030I
O que significa
Dataset ficou sem espaço.
Causas
Espaço secundário insuficiente
Muitas extents
Volume cheio
🔥 SD37 — NO SECONDARY SPACE
Mensagem comum
IEC031I
O que significa
Acabou espaço primário e não existe secondary allocation.
Exemplo clássico
SPACE=(CYL,(10,0))
🔥 SE37 — EXTENT LIMIT EXCEEDED
Mensagem comum
IEC032I
O que significa
Dataset atingiu limite máximo de extents.
Muito comum em
PDS antigos
SORT gigantes
Arquivos temporários
☕🔥 Os ABENDs Mais Icônicos da História do Mainframe
ABEND
Significado
S0C7
Data Exception
S0C4
Protection Exception
S806
Module Not Found
S913
RACF Violation
SB37
Dataset sem espaço
S322
Timeout
S213
Dataset não encontrado
☕ Curiosidade Histórica
Nos tempos do:
OS/360
OS/VS1
OS/VS2
MVS/XA
os operadores praticamente decoravam os ABENDs “na raça”.
Muitos programadores COBOL antigos conseguiam identificar o erro apenas olhando:
IEF450I
ou:
IEC141I
sem precisar abrir dump.
Isso virou quase uma “linguagem secreta” do mundo mainframe.
Bellacosa Mainframe apresenta o ibm mainframe parte vii
☕ Um Café no Bellacosa Mainframe
Capítulo VII — O Grande Terminal de Embarque da Galáxia
JES — O Sistema que Organiza Milhões de Missões Sem Perder uma Única Mala
QUARTA REGRA DAS VIAGENS INTERESTELARES
Nunca entregue um plano de voo diretamente ao piloto.
Porque ele está ocupado voando.
Alguém precisa verificar:
se a nave está abastecida;
se existe pista disponível;
se há autorização para decolagem;
se a carga foi embarcada;
se a tripulação está completa;
se existe um destino válido.
Agora imagine repetir esse processo...
cem vezes.
Mil vezes.
Um milhão de vezes.
Todos os dias.
Esse é exatamente o trabalho do JES.
O Job Entry Subsystem.
O aeroporto mais movimentado da galáxia corporativa.
O Universo Nunca Dorme
Enquanto você lê este livro...
algum banco está:
calculando juros.
Emitindo boletos.
Atualizando investimentos.
Processando PIX.
Gerando extratos.
Enquanto isso...
alguma seguradora está:
calculando riscos.
Emitindo apólices.
Atualizando clientes.
Em outra parte da galáxia...
um supermercado fecha seu movimento.
Uma companhia aérea recalcula tarifas.
Um governo processa milhões de declarações.
Grande parte dessas atividades acontece em Batch.
E quase todas passam pelo JES.
Imagine o Maior Aeroporto do Universo
Esqueça computadores.
Imagine um aeroporto.
Não um aeroporto comum.
Um aeroporto com:
um milhão de voos diários;
centenas de pistas;
milhares de hangares;
milhões de passageiros;
bilhões de toneladas de carga.
Agora imagine que absolutamente nenhum voo pode sair na ordem errada.
Porque um erro pode significar:
salários incorretos.
contas erradas.
impostos errados.
pagamentos duplicados.
Esse aeroporto existe.
Seu nome é JES.
O Grande Equívoco do Padawan
Todo iniciante acredita que um Job funciona assim:
JCL
↓
Programa
↓
Fim
Seria maravilhoso.
Mas completamente falso.
Na realidade...
existe um enorme universo escondido entre essas três linhas.
O Plano de Voo
Imagine que um comandante recebe um envelope.
Dentro existe:
rota.
combustível.
tripulação.
carga.
destino.
tempo previsto.
prioridade.
Esse envelope é o:
JCL.
O JCL não é um programa.
É um plano operacional.
Ele explica ao sistema:
"O que precisa ser feito."
Jamais:
"Como fazer."
Essa diferença muda tudo.
O Primeiro Funcionário do Aeroporto
Quando o Job chega...
ele ainda não pode executar.
Primeiro precisa passar pela recepção.
Quem faz isso?
O JES.
Ele verifica:
nome.
estrutura.
prioridade.
classe.
recursos.
saídas.
dispositivos.
Tudo antes da decolagem.
Segundo Wilhelm G. Spruth, o JES atua como o grande coordenador da execução batch, controlando submissão, filas, dispositivos de entrada e saída e toda a logística de processamento dos jobs.
A Sala de Espera
Imagine milhares de passageiros.
Todos desejam embarcar imediatamente.
Infelizmente...
existem apenas algumas pistas disponíveis.
O que fazer?
Fila.
No JES tudo entra em filas.
Jobs.
Impressões.
Leituras.
Saídas.
Relatórios.
Cada elemento aguarda sua vez.
Sem empurrões.
Sem desespero.
Sem caos.
Classe Econômica, Executiva e Diplomática
Você já percebeu que aeroportos possuem prioridades?
Diplomatas.
Emergências.
Carga viva.
Voos internacionais.
No JES acontece exatamente o mesmo.
Cada Job pode pertencer a uma:
JOB CLASS.
Alguns possuem prioridade maior.
Outros podem esperar.
É uma forma elegante de distribuir recursos.
O Fiscal da Bagagem
Imagine um passageiro levando:
uma geladeira.
quatro vacas.
um submarino.
E dizendo:
"Quero embarcar."
O aeroporto responderia:
"Talvez isso não seja uma boa ideia."
O JES faz algo semelhante.
Ele verifica se os recursos solicitados fazem sentido.
Memória.
Discos.
Dispositivos.
Impressoras.
Datasets.
Antes de liberar o voo.
O Manifesto de Carga
Cada DD Statement do JCL lembra um documento de embarque.
Ele informa:
qual arquivo será utilizado.
quem poderá acessá-lo.
onde está localizado.
como será aberto.
qual formato possui.
Sem essas informações...
a missão simplesmente não acontece.
O Grande Painel de Voos
Imagine um enorme painel eletrônico.
Ele mostra:
EMBARCANDO
AGUARDANDO
EM EXECUÇÃO
FINALIZADO
CANCELADO
No universo Mainframe esse painel chama-se:
SPOOL.
O SPOOL — O Armazém Galáctico
Muitos iniciantes acreditam que relatórios vão diretamente para a impressora.
Não.
Primeiro passam pelo SPOOL.
Imagine um gigantesco depósito automatizado.
Ali ficam armazenados:
SYSOUT.
JESMSGLG.
JESJCL.
JESYSMSG.
Relatórios.
Logs.
Mensagens.
Tudo organizado.
Tudo indexado.
Tudo esperando o momento correto para ser entregue.
Spruth destaca o SPOOL como uma das grandes responsabilidades do JES, permitindo desacoplar completamente a execução dos jobs dos dispositivos físicos de saída.
A Impressora Não Tem Pressa
Imagine um banco imprimindo:
300 mil relatórios.
Seria absurdo obrigar cada programa a esperar a impressora terminar.
Então surgiu uma ideia brilhante.
Primeiro gravamos tudo.
Depois imprimimos.
Essa decisão simples tornou todo o sistema muito mais eficiente.
O Carteiro Interplanetário
Quando um programa termina...
o JES ainda continua trabalhando.
Ele distribui:
relatórios.
mensagens.
arquivos.
logs.
estatísticas.
É quase um gigantesco serviço postal interestelar.
O Despachante da Nave
Agora imagine centenas de missões.
Algumas dependem das anteriores.
Exemplo:
Primeiro:
Atualizar Clientes.
Depois:
Calcular Juros.
Depois:
Emitir Boletos.
Depois:
Gerar Extratos.
Depois:
Enviar Arquivos.
Executar fora dessa ordem seria um desastre.
O JES garante justamente essa organização.
O Relógio Cósmico
Nem toda missão deve partir imediatamente.
Algumas precisam esperar:
meia-noite.
fim do expediente.
fechamento bancário.
último voo.
última venda.
O JES trabalha em conjunto com ferramentas de automação e agendamento para que essas execuções ocorram exatamente no momento planejado.
A Torre de Controle Nunca Dorme
Enquanto milhares de Jobs executam...
o JES continua observando:
quem entrou.
quem saiu.
quem falhou.
quem terminou.
quem está esperando.
Tudo isso simultaneamente.
É como controlar um milhão de aeronaves.
Sem colisões.
JES2 e JES3
Durante décadas existiram duas grandes escolas.
Como duas gigantescas federações espaciais.
JES2
Mais distribuído.
Mais simples.
Mais utilizado.
JES3
Mais centralizado.
Mais integrado.
Excelente para determinados cenários de grandes instalações.
Ao longo do tempo, o JES2 tornou-se predominante no ecossistema z/OS, incorporando muitas capacidades que antes diferenciavam o JES3.
O Que Acontece Quando um Job Falha?
Um Padawan costuma imaginar:
"Acabou."
Na verdade...
o trabalho apenas começou.
O JES registra:
mensagens.
SYSOUT.
Return Codes.
ABENDs.
Tempo.
CPU.
Datasets.
Tudo cuidadosamente documentado.
É por isso que um bom analista passa tanto tempo lendo:
JESMSGLG
JESYSMSG
SYSOUT
quanto lendo o próprio código COBOL.
SDSF — A Janela da Torre de Controle
Imagine uma enorme parede de vidro.
Dela você observa:
todos os voos.
todas as pistas.
todos os hangares.
No Mainframe essa janela chama-se:
SDSF.
Ali operadores acompanham:
Jobs ativos.
Filas.
Impressões.
STCs.
TSUs.
Mensagens do sistema.
É praticamente a sala de comando da nave.
O Batch Nunca Morreu
Existe um mito curioso.
"As empresas trabalham apenas em tempo real."
Na prática...
elas trabalham nos dois mundos.
Online.
E Batch.
Durante o dia:
clientes consultam saldo.
À noite:
milhões de contas são recalculadas.
O processamento Batch continua sendo uma das engrenagens fundamentais da economia mundial.
O Que Mudou Desde 2010?
Desde que Spruth escreveu seu relatório, o ecossistema Batch evoluiu bastante.
Hoje encontramos:
integração com z/OSMF;
automação inteligente;
Workload Scheduler muito mais sofisticado;
monitoramento por APIs REST;
integração com DevOps;
pipelines CI/CD;
execução híbrida envolvendo Linux on Z;
observabilidade em tempo real.
Mas o princípio permanece exatamente igual.
Organizar milhões de trabalhos sem perder o controle.
A Filosofia do JES
Existe uma lição escondida aqui.
Nenhuma grande civilização cresce sem logística.
Não importa se falamos de:
Império Romano.
NASA.
Ferrovias.
Internet.
Ou IBM Z.
O segredo nunca foi apenas produzir.
Foi organizar.
O JES é exatamente isso.
Organização transformada em software.
Curiosidades do Diário de Bordo
🚀 Muitos ambientes processam centenas de milhares de Jobs diariamente sem intervenção humana.
📦 O conceito de SPOOL revolucionou a separação entre processamento e impressão, permitindo enorme ganho de desempenho.
🌌 Um Job pode permanecer aguardando recursos ou prioridades sem consumir CPU, aguardando o momento ideal para iniciar.
📋 Grande parte do trabalho de um Analista de Produção envolve interpretar as mensagens produzidas pelo JES, tornando seus logs tão importantes quanto o código executado.
Diário de Bordo do Padawan COBOL
Antes de sair do Terminal Espacial Batch, registre estas coordenadas:
✅ O JCL é um plano de voo, não um programa.
✅ O JES funciona como a torre de controle responsável por organizar toda a produção batch do z/OS.
✅ O SPOOL desacopla processamento e dispositivos físicos, aumentando eficiência e flexibilidade.
✅ Um bom profissional de Mainframe aprende a "ler a conversa" do JES — porque os logs contam a história completa da execução.
Missão Seguinte
No próximo capítulo, atravessaremos uma das áreas mais movimentadas da nave: o CICS (Customer Information Control System).
Lá descobriremos como milhões de passageiros conseguem ser atendidos ao mesmo tempo, por que milhares de programas COBOL compartilham a mesma CPU sem entrar em conflito e como o CICS se tornou um dos maiores sistemas de processamento transacional já construídos pela humanidade.
Prepare seu mapa BMS, revise sua COMMAREA e mantenha sua toalha e seu café à mão. Nossa próxima parada será a metrópole das transações online.
☕ Um Café no Bellacosa Mainframe
O Guia Galáctico do IBM Z
Dezoito capítulos e uma conclusão reunidos em um painel interativo. Escolha uma missão, abra no visor e continue explorando diretamente no artigo original.
Não entre em pânico: se o Blogger impedir a exibição dentro do iframe, use “Abrir artigo”. Os links diretos continuam visíveis para leitores e motores de busca.
A Linguagem que Conversa com o IBM Z Desde a Era dos Cartões Perfurados até a Inteligência Artificial
A imagem apresentada é bastante didática e está correta para alguém iniciando no universo IBM Z. Entretanto, ela simplifica algo que, na prática, representa uma das tecnologias mais sofisticadas e resilientes já construídas pela engenharia de software.
Para um profissional COBOL, um operador, um analista de produção ou um Sysprog, entender JCL significa compreender como o z/OS pensa.
E isso muda completamente a forma de trabalhar.
O que realmente é JCL?
JCL significa:
Job Control Language
Mas essa definição é insuficiente.
Uma definição mais próxima da realidade seria:
JCL é a linguagem declarativa utilizada pelo z/OS para descrever uma unidade completa de processamento batch.
Ela informa:
O que executar
Quando executar
Com quais arquivos
Em quais dispositivos
Com quais limites
Em quais classes
Com qual prioridade
Como tratar erros
Como reiniciar
Como gerar relatórios
Como conversar com subsistemas
JCL não é programação
Essa é uma dúvida comum.
COBOL é procedural.
Python é procedural.
Assembler é procedural.
JCL é declarativo.
Você não diz:
Faça isso Depois faça aquilo
Você diz:
"Quero que este programa seja executado utilizando estes datasets, estes recursos e estas condições."
O que realmente acontece quando submetemos um JCL?
A imagem mostra:
Create
Submit
Read
Execute
Mas internamente é muito maior.
Etapa 1
JES2 recebe
Etapa 2
Parser valida sintaxe
Etapa 3
Conversão
Job vira estrutura interna.
JCT
TIOT
JQE
JOE
Control Blocks.
Etapa 4
Scheduler escolhe execução
WLM
Service Class
Importance
Velocity
Etapa 5
Allocation
IEFBR14
Catalog
SMS
Volumes
DASD
Etapa 6
Carregamento
Program Fetch
LPA
Linklist
STEPLIB
Etapa 7
Execução
Etapa 8
Geração de SYSOUT
Spool
JES2
SYSIN é genial
A imagem cita:
SYSIN
Pouca gente entende.
SYSIN é um arquivo virtual.
Exemplo:
//SYSIN DD *
SORT FIELDS=(1,10,CH,A)
SUM FIELDS=NONE
/*
O programa lê como se fosse arquivo.
Mas é texto embutido.
Quase um precursor do conceito de:
Heredoc
ConfigMap
Manifest
Utilitários famosos
IEFBR14
Não faz nada.
Serve para alocar.
Apagar.
Testar.
IDCAMS
VSAM
Catalog
SORT
DFSORT
ICETOOL
IKJEFT01
Executa comandos TSO
DB2
SPUFI
DSN
REXX
IEBGENER
Copiar datasets
Condições e Fluxo
JCL possui lógica.
Pouca gente sabe.
COND
COND=(4,LT)
IF
IF STEP1.RC = 0 THEN
ENDIF
RC
Return Code
0
Sucesso
4
Warning
8
Erro
12
Erro grave
16
Falha crítica
PROC
Reutilização
Semelhante a função.
//PAYPROC PROC ENV=PROD
Chamando:
EXEC PAYPROC
Hoje lembraríamos de:
Template
Ansible
Helm Chart
Pipeline
JCL é DevOps antes do DevOps existir
Comparação moderna:
JCL
DevOps
JOB
Pipeline
EXEC
Stage
DD
Artifact
PROC
Template
SYSIN
Configuração
JES2
Scheduler
WLM
QoS
Catalog
Registry
Restart
Rollback
COND
Workflow
Por que aprender JCL em 2026 ainda vale muito a pena?
Porque praticamente todos os setores críticos continuam dependendo dele:
Bancos
Seguradoras
Bolsa de valores
Previdência
Governo
Telecomunicações
Varejo
Processadoras de cartões
Indústria
Milhões de JCLs são executados diariamente em ambientes z/OS. Muitos deles foram escritos há décadas, evoluíram ao longo do tempo e continuam sustentando operações que movimentam trilhões de dólares por ano.
Pergunta de entrevista para impressionar um recrutador
Pergunta: O JCL é apenas uma linguagem para executar programas COBOL?
Resposta esperada:
Não. O JCL é uma linguagem declarativa de controle de processamento do z/OS que define a execução de workloads batch, alocação de recursos, gerenciamento de datasets, integração com subsistemas, políticas de recuperação, automação operacional e interação com JES e WLM. O COBOL é apenas um dos muitos consumidores desse ambiente.
No fim das contas, o JCL é muito mais do que uma "linguagem de execução". Ele é o contrato operacional entre o negócio, os programas e o sistema operacional IBM Z, permitindo que um ecossistema gigantesco funcione de maneira previsível, auditável e extremamente confiável há mais de seis décadas. Para um Padawan COBOL, dominar JCL é deixar de ser apenas um programador e começar a pensar como um verdadeiro habitante do universo z/OS.
Vagner Renato Bellacosa trabalha com IBM Mainframe
desde 1988
,
é IBM Champion e especialista em COBOL, CICS, Db2,
z/OS e IBM Z. Compartilha experiências profissionais,
conhecimento técnico, história da computação e práticas
do universo mainframe para aproximar novas gerações das
tecnologias que sustentam empresas, bancos e governos
ao redor do mundo.
IBM Champion
IBM Z
COBOL
CICS
Db2
z/OS
Mainframe desde 1988
