☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

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

domingo, 1 de junho de 2025

☕💣🚀 PADAWAN, O ASSEMBLER NÃO É UMA LINGUAGEM. É O MOMENTO EM QUE VOCÊ PARA DE DISCUTIR COM O COMPUTADOR E COMEÇA A CONVERSAR DIRETAMENTE COM A CPU!

Bellacosa Mainframe e a linguagem assembler em mainframe o mitico hlasm

☕💣🚀 PADAWAN, O ASSEMBLER NÃO É UMA LINGUAGEM. É O MOMENTO EM QUE VOCÊ PARA DE DISCUTIR COM O COMPUTADOR E COMEÇA A CONVERSAR DIRETAMENTE COM A CPU!

As Lições Ocultas do Curso IBM z/Architecture Assembler Language – Part 2

Existe um momento na vida de todo profissional de Mainframe em que COBOL deixa de ser suficiente.

Não porque COBOL seja limitado.

Não porque o Mainframe seja antigo.

Mas porque surge uma pergunta perigosa:

"O que realmente acontece quando meu programa executa?"

É nesse momento que nasce o interesse pelo Assembler.

O curso IBM EZ341G — z/Architecture Assembler Language Part 2: Machine Instructions — não ensina apenas instruções. Ele ensina como o processador IBM Z pensa.

E isso muda tudo.


O Grande Segredo: Tudo é Registrador

Durante o curso inteiro existe uma mensagem escondida:

LH    3,NUM
AR    3,4
CR    3,5
BE    IGUAL

Tudo gira em torno dos registradores.

Quando um programador COBOL escreve:

ADD VALOR-A TO VALOR-B

o compilador transforma isso em dezenas de instruções de máquina.

O processador não entende COBOL.

Não entende Java.

Não entende Python.

Ele entende apenas instruções.

E quase todas elas envolvem registradores.


A Regra de Ouro: Se Tem G, Pense em 64 Bits

Uma das maiores pegadinhas do curso é distinguir instruções de 32 e 64 bits.

O padrão da IBM é elegantemente simples:

G = Grande = 64 bits

Exemplos:

LG
LGR
LGFI
AG
AGFI
CG
CGR

Todos trabalham sobre o registrador completo.

Já:

L
A
C
AFI

operam apenas sobre a low half do registrador.

Essa pequena letra "G" aparece em dezenas de questões do exame.


O Mistério do Condition Code

O Condition Code é provavelmente o conceito mais importante do curso.

Após uma comparação:

CR  3,4

a CPU grava um valor invisível dentro do PSW.

Esse valor é:

CC=0 Equal
CC=1 Low
CC=2 High

Depois disso:

JE    IGUAL
JL    MENOR
JH    MAIOR

tomam decisões baseadas nesse resultado.

Perceba a beleza do mecanismo.

O processador não executa "IF".

Ele apenas produz Condition Codes.

Todo o resto é interpretação.


O Macete 8421

Outro conceito que aparece repetidamente no exame:

8 = Zero
4 = Minus
2 = Plus
1 = Overflow

Esse é o famoso padrão das máscaras de branch.

Por isso:

JZ
JM
JP
JO

são apenas apelidos amigáveis para máscaras numéricas.

Quando você entende isso, dezenas de Extended Mnemonics deixam de ser um problema.


Packed Decimal: A Religião Financeira do Mainframe

Se existe uma tecnologia que sobreviveu a todas as modas da computação, é o Packed Decimal.

Enquanto o restante do mundo usa floating point para tudo, bancos continuam confiando bilhões de dólares diariamente em instruções como:

AP
SP
MP
DP
CP

O motivo é simples.

Dinheiro não tolera aproximações.


Como Reconhecer um Packed Decimal Válido

Muitos alunos perdem pontos porque esquecem uma regra básica.

Os dígitos devem conter:

0-9

E o último nibble deve conter um sinal:

C
D
F

Exemplos válidos:

123C
123D
550F

Exemplos inválidos:

12AC
00C1
1ABC

Quando isso acontece:

S0C7
Data Exception

O famoso terror dos programadores COBOL.


O Verdadeiro Significado do S0C7

Muitos iniciantes acreditam que:

S0C7 = erro de COBOL

Errado.

O S0C7 é um erro da CPU.

Ela tentou executar uma operação decimal e encontrou dados inválidos.

O COBOL apenas estava no lugar errado na hora errada.


Multiplicação: Onde Todo Mundo Erra

As instruções:

M
MR
MP

parecem simples.

Mas escondem algumas das regras mais cruéis da arquitetura.

Por exemplo:

MR 2,3

não multiplica R2 por R3.

Na verdade utiliza:

Par R2-R3

e coloca o resultado distribuído entre os dois registradores.

Essa é uma das pegadinhas favoritas da IBM.


Divisão: A Arte de Produzir S0CB

A instrução:

DP

é responsável por um dos abends mais famosos do mundo Mainframe:

S0CB
Decimal Divide Exception

Ele ocorre quando:

  • O divisor é zero.

  • O quociente não cabe no campo de destino.

Ou seja, a CPU está protegendo seus dados.


SRP: A Instrução que Parece Magia

Poucas instruções impressionam tanto quanto:

SRP

Shift and Round Packed.

Com ela podemos:

123.95 -> 123
123.95 -> 124
55 -> 5500

Tudo sem realizar multiplicações ou divisões explícitas.

Na prática, SRP é uma calculadora financeira embutida no hardware.


ED: O Momento em que o Mainframe Aprende a Falar com Humanos

Packed Decimal é excelente para cálculos.

Mas humanos não gostam de ler:

12345C

É aí que entra:

ED

A instrução EDIT.

Ela transforma números internos em formatos amigáveis:

12.345,67
24.00
999.99

O ED é literalmente a ponte entre o mundo da CPU e o mundo dos relatórios.


O Poder das Máscaras

A maioria dos alunos demora para perceber que:

ED

não faz a formatação.

Quem faz é a máscara.

Por isso encontramos padrões como:

20
21
4B
6B
40

onde:

20 = Digit Selector
21 = Significance Starter
4B = Ponto Decimal
6B = Vírgula
40 = Espaço

É um mecanismo brilhante criado décadas antes da maioria das linguagens modernas.


O Que o Curso Realmente Ensina

Oficialmente o curso fala sobre:

  • LOAD

  • STORE

  • ADD

  • SUBTRACT

  • MULTIPLY

  • DIVIDE

  • COMPARE

  • BRANCH

  • CHARACTERS

  • PACKED DECIMAL

Mas na prática ele ensina algo muito mais profundo.

Ele mostra que toda linguagem moderna, toda API, todo framework e toda aplicação corporativa acabam reduzidos a algumas operações fundamentais:

Mover dados
Somar
Subtrair
Comparar
Desviar
Formatar

O Mainframe apenas faz isso de forma extremamente explícita.


Conclusão

☕💣🚀 PADAWAN, quando você aprende Assembler, descobre um segredo que poucos profissionais conhecem.

O computador nunca executou COBOL.

Nunca executou Java.

Nunca executou Python.

Ele sempre executou instruções de máquina.

O Assembler apenas remove o tradutor e permite que você converse diretamente com a arquitetura IBM Z.

E quando isso acontece, você deixa de ser apenas um programador.

Você começa a entender como a própria CPU pensa.


sexta-feira, 18 de junho de 2021

ABEND sem Mistérios — Parte IV

 

Bellacosa Mainframe e o abend sem misterios parte IV

☕ Um Café no Bellacosa Mainframe

ABEND sem Mistérios — Parte IV

O que Acontece Dentro do IBM Z Quando um ABEND Ocorre: Registradores, Memória, TCB, RB e a Jornada de uma Instrução até a CPU

"Para o programador, um ABEND acontece quando o programa para. Para o processador, ele acontece quando uma única instrução viola uma regra da arquitetura."


Introdução

Até agora aprendemos:

  • o que é um ABEND;

  • como investigá-lo;

  • como descobrir sua causa raiz.

Agora vamos entrar em um território que poucos programadores COBOL exploram.

Vamos olhar o problema pelo ponto de vista do próprio IBM Z.

Imagine que você pudesse entrar dentro do processador durante um S0C4.

O que estaria acontecendo?

Quem decidiu interromper seu programa?

Quem chamou o dump?

Como a CPU sabe exatamente qual instrução falhou?

Por que o sistema consegue informar o endereço exato onde tudo aconteceu?

A resposta está na arquitetura do IBM Z.


O IBM Z nunca executa COBOL

Essa é uma das primeiras grandes descobertas.

O processador IBM Z não conhece COBOL.

Nem PL/I.

Nem C.

Nem Java.

Muito menos JCL.

A CPU conhece apenas uma linguagem:

Machine Instructions

Ou seja,

milhões de instruções binárias.


O caminho de um programa

Quando escrevemos:

ADD WS-VALOR
 TO WS-TOTAL.

O compilador transforma isso em dezenas de instruções de máquina.

O fluxo verdadeiro é:

COBOL

↓

Enterprise COBOL Compiler

↓

Assembler

↓

Objeto

↓

Binder

↓

Load Module

↓

Machine Instructions

↓

CPU IBM Z

Quando ocorre um S0C7,

não foi a instrução ADD que falhou.

Foi uma instrução de máquina gerada pelo compilador.


A CPU trabalha uma instrução por vez

Imagine:

READ

MOVE

ADD

WRITE

Para nós parecem quatro comandos.

Para o processador,

podem representar centenas de instruções.

Cada instrução passa por etapas.

Buscar

↓

Decodificar

↓

Executar

↓

Gravar Resultado

Esse processo acontece bilhões de vezes por segundo.


Quando nasce um S0C4

Imagine uma instrução tentando acessar um endereço inexistente.

A CPU verifica:

Endereço

↓

Área permitida?

↓

SIM

↓

Executa

ou

Endereço

↓

Área permitida?

↓

NÃO

↓

Program Interrupt

Nesse instante,

o S0C4 começa a nascer.


O Program Interrupt

O processador possui dezenas de tipos de interrupções.

Algumas delas:

  • Protection Exception

  • Addressing Exception

  • Operation Exception

  • Data Exception

  • Overflow

  • Fixed Point Divide

Quando ocorre uma dessas situações,

a CPU interrompe imediatamente a instrução.

Ela não pergunta ao programa se deseja continuar.


O papel do PSW

O Program Status Word é um dos componentes mais importantes da arquitetura IBM Z.

Ele contém informações como:

  • endereço da próxima instrução;

  • modo de execução;

  • chave de proteção;

  • condição da CPU;

  • máscara de interrupções.

É praticamente o "painel de controle" do processador.

Sempre que ocorre um ABEND,

o PSW é salvo.

É por isso que conseguimos descobrir exatamente onde tudo aconteceu.


Registradores: a mesa de trabalho da CPU

Imagine um marceneiro.

Sobre sua bancada existem:

  • régua;

  • lápis;

  • parafusos;

  • martelo.

A CPU possui algo parecido.

São os registradores.

Ela utiliza esses espaços para guardar:

  • endereços;

  • parâmetros;

  • resultados;

  • ponteiros;

  • contadores.

Quando um dump é produzido,

todos eles são preservados.


O famoso R15

Quem trabalha com COBOL logo aprende sobre o registrador R15.

Ele normalmente contém:

  • endereço inicial de programas;

  • códigos de retorno;

  • informações importantes durante CALLs.

Em muitas análises,

o primeiro registrador observado é justamente ele.


O que é Storage?

Quando dizemos:

WS-NOME

PIC X(30)

Essa variável ocupa memória.

No IBM Z essa memória recebe o nome de:

Storage

É nela que vivem:

  • variáveis COBOL;

  • buffers;

  • tabelas;

  • áreas de comunicação;

  • parâmetros.

Um S0C4 quase sempre está relacionado ao uso incorreto dessa Storage.


O conceito de Address Space

Uma dúvida comum dos iniciantes é:

"O programa acessa toda a memória do computador?"

Não.

Cada JOB ou região CICS executa em um Address Space.

Pense em um apartamento.

Cada morador possui:

  • sala;

  • cozinha;

  • quarto.

Um apartamento não invade o outro.

Da mesma forma,

um programa não pode acessar livremente a memória de outro Address Space.


O que é um TCB?

Agora chegamos a um dos componentes mais importantes do z/OS.

TCB significa:

Task Control Block

Toda tarefa possui um.

Ele contém informações fundamentais sobre a execução:

  • registradores;

  • PSW;

  • prioridade;

  • estado;

  • ponteiros;

  • RB atual.

Sem o TCB,

o sistema não saberia quem está executando.


Imagine um crachá

Imagine uma empresa.

Cada funcionário possui um crachá.

No IBM Z,

o TCB funciona exatamente assim.

Ele identifica aquela tarefa perante o sistema operacional.


O RB (Request Block)

Durante uma chamada de serviço,

o sistema cria um RB.

Ele registra:

  • quem chamou;

  • qual serviço foi solicitado;

  • qual rotina será executada;

  • para onde retornar.

Em uma investigação profunda,

a sequência de RBs ajuda a reconstruir a história da execução.


O Dispatcher

Quem decide qual programa utilizará a CPU?

Não é o JES2.

Não é o COBOL.

É o Dispatcher do z/OS.

Ele distribui tempo de processamento entre milhares de tarefas.

Imagine um maestro regendo uma orquestra.

Cada músico toca por alguns instantes.

Depois outro assume.

Tudo acontece tão rapidamente que parece simultâneo.


O papel do Supervisor

Quando ocorre um Program Interrupt,

a CPU entrega o controle ao Supervisor do sistema operacional.

Ele analisa:

  • tipo da exceção;

  • PSW;

  • registradores;

  • TCB;

  • RB;

  • contexto da tarefa.

Depois decide:

  • gerar dump;

  • emitir mensagens;

  • encerrar a tarefa.

É nesse momento que nasce oficialmente o ABEND.


Como nasce um Dump

O Dump não aparece por mágica.

O sistema percorre diversas estruturas.

Ele salva:

  • registradores;

  • memória;

  • TCB;

  • RB;

  • PSA;

  • LSQA;

  • CSA;

  • pilhas;

  • módulos carregados;

  • áreas do LE.

Tudo isso permite que o problema seja investigado posteriormente.


A pilha de chamadas

Quando fazemos:

Programa A

↓

CALL B

↓

CALL C

↓

CALL D

O sistema mantém uma pilha.

Ela registra:

  • quem chamou;

  • quem foi chamado;

  • para onde retornar.

O CEEDUMP utiliza essa pilha para montar o famoso Traceback.


Por que um Offset é tão importante?

Quando o compilador gera o Load Module,

as linhas do COBOL deixam de existir.

O executável conhece apenas endereços.

Por isso o dump mostra:

Offset

0000A3F2

Ferramentas como IBM Fault Analyzer, Abend-AID e IDz fazem o caminho inverso: relacionam esse offset ao programa-fonte, permitindo localizar a instrução COBOL correspondente.


O papel do Binder

Muitos iniciantes acreditam que a compilação termina quando o compilador gera o objeto.

Na verdade,

existe outra etapa fundamental.

O Binder (antigo Link-Editor) reúne:

  • módulos objeto;

  • bibliotecas;

  • sub-rotinas;

  • Language Environment.

O resultado é o Load Module, que será executado pelo z/OS.

Sem essa etapa,

não existe programa executável.


E no CICS?

Dentro do CICS tudo continua acontecendo.

A diferença é que existe outra camada.

Terminal

↓

Task CICS

↓

Dispatcher CICS

↓

Programa COBOL

↓

Language Environment

↓

CPU

Quando ocorre um ASRA,

o CICS captura o Program Interrupt,

gera suas mensagens

e encerra a Task.


O que realmente vê um SysProg?

Enquanto o desenvolvedor observa:

S0C7

O SysProg costuma enxergar algo muito maior.

Ele analisa:

  • PSW;

  • TCB;

  • RB;

  • ASCB;

  • SRB;

  • Dispatcher;

  • WLM;

  • armazenamento;

  • interrupções;

  • módulos do sistema.

São duas perspectivas diferentes do mesmo problema.


Curiosidades da arquitetura IBM Z

  • O IBM Z possui mecanismos de proteção de memória extremamente sofisticados, fundamentais para executar milhares de workloads simultaneamente com segurança.

  • Um único sistema pode manter milhares de Tasks ativas, cada uma com seu próprio contexto de execução.

  • O PSW é salvo e restaurado continuamente durante trocas de contexto entre tarefas.

  • Grande parte da confiabilidade do IBM Z vem justamente da capacidade de detectar exceções e interromper apenas a tarefa problemática, preservando o restante do sistema.


O caminho completo de um ABEND

Programa COBOL

↓

Compilador

↓

Load Module

↓

CPU executa instrução

↓

Program Interrupt

↓

Supervisor z/OS

↓

Análise do contexto

↓

Dump

↓

Mensagens

↓

ABEND

↓

SDSF

↓

Investigação

↓

Correção

↓

Aprendizado

Conclusão

Quando compreendemos a arquitetura interna do IBM Z, os ABENDs deixam de ser mensagens misteriosas e passam a ser eventos perfeitamente explicáveis.

Um S0C4 não é "azar". Um S0C7 não é "capricho do compilador". Eles são a consequência direta de mecanismos de proteção cuidadosamente projetados para preservar a integridade do sistema.

Essa é uma das grandes diferenças do Mainframe: cada interrupção, cada registrador salvo, cada PSW capturado e cada dump gerado fazem parte de uma arquitetura construída para ser observável, previsível e extremamente resiliente.

O Programador Padawan que entende essa jornada deixa de enxergar apenas o código COBOL e passa a compreender como hardware, sistema operacional, compilador e aplicação trabalham em perfeita sintonia. É nesse momento que ele começa a pensar como um verdadeiro especialista em IBM Z.


quarta-feira, 26 de maio de 2021

ABEND sem Mistérios — Parte III

 

Bellacosa Mainframe em abend sem misterio parte III

☕ Um Café no Bellacosa Mainframe

ABEND sem Mistérios — Parte III

Como Pensam os Especialistas em Mainframe: Engenharia de Diagnóstico, Dumps, IPCS e a Arte de Encontrar a Causa Raiz

"Um bom programador corrige um ABEND. Um grande engenheiro descobre por que ele nunca deveria ter acontecido."


Introdução

Até aqui, aprendemos duas grandes lições.

Na Parte 1 entendemos:

  • o que é um ABEND;

  • como ele nasce;

  • quais são os principais códigos encontrados no dia a dia.

Na Parte 2 aprendemos:

  • como investigar;

  • quais mensagens analisar;

  • como utilizar JESMSGLG, JESYSMSG, CEEDUMP e SYSOUT.

Agora chegamos ao terceiro nível.

Aqui deixamos de ser apenas programadores COBOL.

Passamos a pensar como verdadeiros engenheiros de software para IBM Z.

É exatamente essa mudança de mentalidade que diferencia um desenvolvedor comum de um profissional extremamente valorizado pelos grandes bancos.


O maior erro durante uma investigação

Imagine que um programa termina com:

S0C7

O iniciante pensa:

"Preciso corrigir este S0C7."

O profissional pensa diferente.

"O S0C7 é apenas consequência.
O que gerou os dados inválidos?"

Essa diferença muda completamente a investigação.


O conceito de Causa Raiz

Todo problema possui duas causas.

Sintoma

É aquilo que aparece.

S0C4

S0C7

ASRA

U4038

Causa

É o verdadeiro problema.

Exemplo:

Arquivo recebido com dados inválidos

↓

Campo não validado

↓

ADD

↓

S0C7

O ABEND não começou no ADD.

Começou quando alguém permitiu que dados incorretos chegassem até ali.


O pensamento em camadas

Especialistas enxergam uma aplicação como diversas camadas.

Usuário

↓

Tela

↓

CICS

↓

Programa COBOL

↓

COPYBOOK

↓

Db2

↓

VSAM

↓

MQ

↓

JCL

↓

z/OS

O erro pode nascer em qualquer uma delas.


O princípio dos "Cinco Porquês"

Uma técnica extremamente utilizada em engenharia é o 5 Whys, criado dentro do Sistema Toyota de Produção.

Exemplo.

Programa terminou em S0C7.

Por quê?

Porque tentou somar caracteres.

Por quê?

Porque recebeu "ABCDE".

Por quê?

Porque o arquivo veio corrompido.

Por quê?

Porque o sistema fornecedor alterou o layout.

Por quê?

Porque não existia contrato de interface.

Agora encontramos a verdadeira causa.


O ABC da investigação

Todo incidente pode ser dividido em três perguntas.

A

O que aconteceu?

ABEND S0C4

B

Onde aconteceu?

Programa

Parágrafo

Offset

C

Por que aconteceu?

Essa é a parte difícil.


O conceito de Timeline

Um erro nunca aparece instantaneamente.

Existe uma sequência.

08:00

Arquivo recebido

↓

08:03

Programa inicia

↓

08:05

Registro inválido

↓

08:05

Campo carregado

↓

08:06

Cálculo

↓

08:06

S0C7

Perceba que o problema nasceu seis minutos antes do ABEND.


O poder do CEEDUMP

O CEEDUMP é praticamente uma fotografia.

Mas imagine que você possui uma fotografia de um acidente.

Ela mostra:

  • onde ocorreu;

  • quem estava presente;

  • posição dos veículos.

Mas ela não mostra o momento da colisão.

Por isso precisamos combinar várias evidências.


Entrando no mundo do IPCS

Poucos iniciantes conhecem esta ferramenta.

IPCS significa:

Interactive Problem Control System

É uma das ferramentas mais importantes do z/OS.

Ela permite analisar:

  • dumps completos;

  • memória;

  • registradores;

  • módulos carregados;

  • PSW;

  • TCB;

  • ASCB;

  • cadeias de controle do sistema.

Na prática,

é o laboratório forense do IBM Z.


O que um Dump realmente contém?

Muitos imaginam um dump como um arquivo de texto.

Na realidade ele contém praticamente toda a memória capturada.

Por exemplo:

Endereços

Buffers

Variáveis

Registradores

Storage

TCBs

RBs

LSQA

CSA

ECSA

PSA

Núcleo

É literalmente uma fotografia da memória.


O famoso PSW

O Program Status Word é uma das primeiras informações analisadas.

Ele responde:

  • onde a CPU estava;

  • em qual instrução;

  • qual modo de execução;

  • qual estado do processador.

Por isso um SysProg costuma perguntar:

"Qual é o PSW?"


Registradores: a mochila do processador

O IBM Z possui registradores gerais.

Imagine um pedreiro.

Antes de subir uma escada,

ele coloca ferramentas na mochila.

A CPU faz exatamente isso.

Antes de executar instruções,

ela guarda informações temporárias nos registradores.

Quando ocorre um ABEND,

essa mochila continua exatamente como estava.

É por isso que os registradores são tão importantes.


O papel da Language Environment (LE)

Praticamente todo programa COBOL moderno executa sobre o Language Environment.

Ele fornece:

  • gerenciamento de memória;

  • tratamento de exceções;

  • traceback;

  • serviços comuns;

  • interoperabilidade entre COBOL, C, C++ e PL/I.

Sem o LE, muitos diagnósticos seriam muito mais difíceis.


Quando um U4038 esconde outro erro

Muitos iniciantes acreditam que:

U4038

↓

Erro encontrado

Na realidade,

muitas vezes acontece isto.

S0C7

↓

Language Environment

↓

U4038

Ou seja,

o U4038 pode ser apenas uma "embalagem" para outro problema.

Sempre investigue além do código retornado.


O papel do Fault Analyzer

Hoje muitos bancos utilizam o IBM Fault Analyzer.

Ele transforma um dump complexo em algo muito mais amigável.

Por exemplo.

Em vez de mostrar:

Offset

00003A8F

Ele mostra:

Programa

CLIENTES

Linha

538

Campo

WS-SALDO

Economiza horas de investigação.


Abend-AID

Outra ferramenta extremamente popular.

Ela apresenta:

  • variáveis;

  • CALL Stack;

  • conteúdo dos registros;

  • SQLCA;

  • áreas de memória;

  • File Status;

  • tabelas.

É praticamente um "Google Maps" do dump.


O valor de um bom Log

Imagine um programa sem nenhum DISPLAY.

Agora imagine outro com mensagens como:

Iniciando cálculo...

Cliente 12345

Saldo encontrado

Calculando juros

Atualizando Db2

Commit realizado

Qual será mais fácil de investigar?

A resposta é óbvia.

Logs bem escritos reduzem drasticamente o tempo de diagnóstico.


Engenharia defensiva

Programadores experientes evitam ABENDs antes mesmo que eles aconteçam.

Como?

Validando tudo.

IF NUMERIC

IF FILE STATUS

IF SQLCODE

IF RESP

IF RESP2

IF LENGTH

IF EOF

IF RETURN-CODE

Quem valida dados produz programas muito mais robustos.


Os três níveis da depuração

Nível 1

Corrigir o erro.

Nível 2

Descobrir a causa.

Nível 3

Modificar o sistema para impedir que volte a acontecer.

Esse terceiro nível é onde nasce a excelência técnica.


O pensamento dos grandes bancos

Em ambientes críticos,

a pergunta raramente é:

"Quem escreveu o programa?"

A pergunta costuma ser:

"Por que nossos processos permitiram que isso chegasse à produção?"

Perceba a diferença.

Sai o culpado.

Entra a melhoria contínua.


O custo de um ABEND

Um único ABEND pode provocar:

  • atraso em milhares de transações;

  • indisponibilidade de canais digitais;

  • bloqueio de filas MQ;

  • rollback de atualizações no Db2;

  • atraso em processamentos batch;

  • impacto financeiro;

  • horas de investigação.

Por isso bancos investem tanto em observabilidade, monitoramento e prevenção.


Checklist profissional antes de corrigir um ABEND

Nunca altere o código antes de responder:

  • Qual foi o primeiro erro registrado?

  • O ABEND é causa ou consequência?

  • Houve mudança recente de layout, JCL ou copybook?

  • O problema é reproduzível?

  • Existe CEEDUMP ou SYSMDUMP?

  • O SQLCODE, FILE STATUS ou RESP indicavam falha antes do ABEND?

  • A correção elimina apenas o sintoma ou resolve a origem?


A evolução de um Programador Padawan

Todo profissional passa por estágios.

1

Tenho medo do ABEND.

↓

2

Consigo identificar o código.

↓

3

Aprendo a usar o SDSF.

↓

4

Entendo CEEDUMP.

↓

5

Interpreto mensagens do z/OS.

↓

6

Analiso offsets.

↓

7

Leio dumps.

↓

8

Descubro causas raiz.

↓

9

Evito novos ABENDs.

↓

10

Ensino outras pessoas.

É exatamente assim que surgem os especialistas.


Conclusão

A verdadeira maturidade técnica não está em decorar centenas de códigos de ABEND, mas em desenvolver uma forma estruturada de investigar problemas.

No IBM Z, praticamente nada acontece por acaso. Cada mensagem do JES2, cada registro do SDSF, cada CEEDUMP, cada offset e cada registrador contam parte da história. O papel do engenheiro é reunir essas peças até reconstruir a sequência completa dos acontecimentos.

Quando você deixa de perguntar "qual foi o ABEND?" e passa a perguntar "qual decisão, dado ou processo tornou esse ABEND inevitável?", seu modo de pensar muda para sempre.

É nesse momento que você deixa de ser apenas um programador COBOL e passa a enxergar o IBM Z como ele realmente é: um dos sistemas computacionais mais sofisticados, observáveis e resilientes já construídos. E essa é a habilidade que transforma um simples solucionador de erros em um verdadeiro especialista em Mainframe.

terça-feira, 27 de maio de 2014

☕🔥 ABEND S0CB — O “DIVISOR IMPOSSÍVEL” DO MAINFRAME

 

Bellacosa Mainframe e o abend s0cb

☕🔥 ABEND S0CB — O “DIVISOR IMPOSSÍVEL” DO MAINFRAME

Quando o IBM Z Diz:

“VOCÊ TENTOU FAZER UMA CONTA QUE DESAFIA A MATEMÁTICA.”

Se existe um ABEND que faz o Junior Padawan perceber que:

até a matemática pode explodir no z/OS…

é o lendário:

🚨 S0CB

E normalmente ele aparece assim:

SYSTEM COMPLETION CODE=0CB

ou:

DECIMAL DIVIDE EXCEPTION

ou ainda:

FIXED-POINT DIVIDE EXCEPTION

E então nasce o desespero:

“O COBOL desaprendeu matemática?”
“O divisor virou entidade cósmica?”
“O COMP-3 entrou em colapso?”
“Eu dividi por zero?”
“COMPUTE virou arma nuclear?”

☕ Respira.

Porque o S0CB é um dos ABENDs MAIS CLÁSSICOS da aritmética IBM Z.

E um dos mais importantes para entender:

divisão decimal

overflow matemático

divide by zero

packed decimal

COMP-3

hardware arithmetic

dumps matemáticos


🔥 O QUE É O S0CB?

O S0CB é um:

🚨 DIVIDE EXCEPTION

Traduzindo:

A CPU IBM Z DETECTOU UMA OPERAÇÃO DE DIVISÃO INVÁLIDA.


☕ O GRANDE SEGREDO

O S0CB NÃO nasce no COBOL.

Ele nasce:

no hardware decimal do IBM Z.


🔥 O MOMENTO EXATO

Fluxo:

COMPUTE/DIVIDE
 ↓
COBOL gera instrução máquina
 ↓
CPU executa divisão
 ↓
Resultado inválido
 ↓
S0CB

☕ ANALOGIA BELLACOSA MAINFRAME

Imagine uma calculadora gigante bancária.

Você digita:

100 / 0

A calculadora olha para você em silêncio…

e explode dramaticamente.

Isso é:

☠️ S0CB


🔥 O MAIOR VILÃO

🚨 DIVISÃO POR ZERO

O rei absoluto do S0CB.


☕ EXEMPLO COBOL

COMPUTE WS-RESULT = WS-TOTAL / WS-QTD

Mas:

WS-QTD = ZERO

Resultado:

💥 S0CB


🔥 O “ZERO FANTASMA”

O mais traiçoeiro.


☕ EXEMPLO

MOVE SPACES TO WS-QTD

Depois:

COMPUTE WS-MEDIA = WS-TOTAL / WS-QTD

Dependendo do conteúdo:

☠️ desastre matemático.


🔥 O S0CB E O COMP-3

Agora entramos na matemática obscura do mainframe.


☕ EXEMPLO

PIC S9(7)V99 COMP-3

Packed decimal inválido pode causar:

divisão impossível.


🔥 O OVERFLOW MATEMÁTICO

Outro clássico.


☕ EXEMPLO

Resultado da divisão excede capacidade do campo.

01 WS-RESULT PIC 9(02).

Mas cálculo produz:

999999

CPU entra em sofrimento existencial.

Resultado:

💥 S0CB


🔥 O S0CB E O COMPUTE

Junior acha:

COMPUTE é inocente.

Não.

COMPUTE pode gerar:

  • DIVIDE

  • MULTIPLY

  • decimal arithmetic

  • overflow


☕ EXEMPLO CLÁSSICO

COMPUTE WS-PERC =
   (WS-VALOR * 100) / WS-TOTAL

Mas:

WS-TOTAL = 0

Resultado:

☠️ S0CB


🔥 O S0CB E O “ON SIZE ERROR”

Aqui nasce o conhecimento Jedi.


☕ EXEMPLO

DIVIDE A BY B
   GIVING C
   ON SIZE ERROR
      DISPLAY 'ERRO'
END-DIVIDE

Isso pode evitar alguns colapsos matemáticos.


🔥 MAS CUIDADO

Nem todo S0CB é tratado elegantemente.

Dependendo:

  • do runtime

  • do compilador

  • do tipo decimal

  • da instrução gerada

o ABEND ainda pode ocorrer.


☕ O S0CB E O ASRA

No CICS geralmente aparece como:

🚨 ASRA + S0CB

Porque o CICS intercepta a exceção matemática.


🔥 O S0CB E O DB2

Outro cenário clássico.

Valor vindo do DB2:

NULL
ZERO
DADO INVÁLIDO

Programa assume divisor válido.

Boom:

💥 S0CB


☕ O S0CB E O ARQUIVO

Campo numérico chega:

zerado

Mas ninguém validou.

Agora:

DIVIDE WS-QTD INTO WS-TOTAL

Resultado:

☠️ desastre financeiro.


🔥 O S0CB FANTASMA

O mais cruel.

Erro nasce MUITO antes.


☕ EXEMPLO

Linha 100:

MOVE ZERO TO WS-QTD

Linha 9000:

COMPUTE WS-MEDIA =
   WS-TOTAL / WS-QTD

Explosão distante da origem.


🔥 COMO INVESTIGAR O S0CB PASSO A PASSO


✅ PASSO 1 — IDENTIFIQUE O OFFSET

Exemplo:

PSW AT TIME OF ERROR
OFFSET X'01FA'

✅ PASSO 2 — PEGUE O LISTING COBOL

Cruze offset com:

  • compile listing

  • SYSADATA

  • Abend-AID

  • Fault Analyzer


✅ PASSO 3 — IDENTIFIQUE A DIVISÃO

Exemplo:

DIVIDE WS-A BY WS-B

ou:

COMPUTE WS-C = WS-A / WS-B

✅ PASSO 4 — INSPECIONE O DIVISOR

Pergunta sagrada:

“ELE ESTAVA ZERO?”


✅ PASSO 5 — ANALISE O STORAGE

Veja:

  • packed decimal

  • campos COMP-3

  • conteúdo hexadecimal

  • overflow


🔥 O DUMP DO S0CB

Aqui mora a matemática Jedi.

Veteranos analisam:

  • PSW

  • registers

  • decimal instructions

  • packed fields

  • operandos reais


☕ O PSW

Mostra:

ONDE A MATEMÁTICA MORREU.


🔥 O HEXADECIMAL IMPORTA

Exemplo válido:

F0F1F2

Número correto.


☕ EXEMPLO SUSPEITO

404040

Spaces em campo numérico.

Agora a divisão entra no reino do caos.


🔥 O S0CB E O “SOC7 DISFARÇADO”

Às vezes o problema real é:

dado inválido.

Mas explode durante divisão.

Veteranos investigam ambos:

  • S0CB

  • S0C7


☕ O MAIOR ERRO DOS JUNIORS

Corrigir apenas:

IF divisor = 0

sem entender:

POR QUE o divisor virou zero.


🔥 COMO EVITAR S0CB


✅ Validar divisor


✅ Usar ON SIZE ERROR


✅ Validar dados externos


✅ Revisar COMP-3


✅ Tratar NULL/zeros DB2


✅ Evitar overflow


✅ Revisar layouts


☕ O SEGREDO DOS VETERANOS

Veteranos protegem TODA divisão:

IF WS-QTD NOT = ZERO

Porque sabem:

matemática corporativa é território hostil.


🔥 CURIOSIDADE HISTÓRICA

O S0CB vem da arquitetura decimal do:

IBM System/360

Década de:

🏛️ 1960

IBM implementou aritmética decimal em hardware porque:

  • bancos

  • seguros

  • finanças

precisavam de precisão absoluta.


☕ EASTER EGG MAINFRAME

Veteranos brincam:

“S0CB significa:

Seu Programa Descobriu Que Não Existe Divisão Por Nada.”


🔥 O MAIOR ENSINAMENTO DO S0CB

Ele ensina algo profundo:

no mainframe, matemática é levada absurdamente a sério.

A CPU IBM Z NÃO tolera:

  • divisões impossíveis

  • overflow decimal

  • operandos inválidos


☕ A VERDADE FINAL

O S0C7 pune números inválidos.
O S0C4 pune memória inválida.
O S806 pune programas inexistentes.
O S913 pune acessos proibidos.

Mas…

☕ O S0CB É O MOMENTO EM QUE A PRÓPRIA MATEMÁTICA DO IBM Z DECIDE QUE SUA CONTA NÃO FAZ SENTIDO PARA O UNIVERSO.


quinta-feira, 23 de maio de 2013

☕🔥 ABEND S0C4 — O “BURACO NEGRO DA MEMÓRIA” NO MAINFRAME

 

Bellacosa Mainframe abend s0c4

☕🔥 ABEND S0C4 — O “BURACO NEGRO DA MEMÓRIA” NO MAINFRAME

Quando o IBM Z Diz:

“VOCÊ TOCOU EM UMA ÁREA QUE NÃO DEVERIA EXISTIR.”

Se existe um ABEND que faz veterano suspirar fundo…

é o lendário:

🚨 S0C4

E normalmente ele aparece assim:

SYSTEM COMPLETION CODE=0C4

ou:

PROTECTION EXCEPTION

ou ainda:

ADDRESSING EXCEPTION

E então o Junior Padawan entra em desespero:

“O COBOL explodiu?”
“O dataset corrompeu?”
“O CICS morreu?”
“A memória evaporou?”

☕ Respira.

Porque o S0C4 é um dos ABENDs MAIS IMPORTANTES da computação corporativa.


🔥 O QUE É O S0C4?

O S0C4 é um:

🚨 PROTECTION / ADDRESSING EXCEPTION

Traduzindo:

O PROGRAMA TENTOU ACESSAR UMA ÁREA DE MEMÓRIA INVÁLIDA.

Ou:

  • memória proibida

  • endereço inexistente

  • ponteiro inválido

  • storage corrompido

  • área não autorizada


☕ A FILOSOFIA DO S0C4

O IBM Z protege memória como um cofre nuclear.

Seu programa NÃO pode simplesmente sair acessando qualquer lugar.

Quando tenta…

💥 S0C4


🔥 ANALOGIA BELLACOSA MAINFRAME

Imagine um funcionário entrando em um banco.

Ele pode acessar:

✅ sua mesa
✅ seu departamento

Mas de repente tenta entrar:

❌ no cofre principal
❌ na sala do presidente
❌ na área militar subterrânea

O segurança aparece.

Isso é o:

☠️ S0C4


☕ O QUE REALMENTE ACONTECE

O programa executa:

MOVE
MVC
LOAD
STORE

Tudo normal.

Mas então tenta:

acessar endereço inválido

A MMU (Memory Management Unit) do IBM Z detecta:

❌ acesso ilegal

Resultado:

🚨 INTERRUPTION CODE → S0C4


🔥 OS TIPOS MAIS COMUNS DE S0C4


☠️ Protection Exception

Tentou acessar storage protegido.


☠️ Addressing Exception

Endereço inválido.


☠️ Translation Exception

Página inexistente.


☠️ Storage Overlay

Memória corrompida anteriormente.


☕ O MAIOR VILÃO DO S0C4

🚨 SUBSCRIPT FORA DA TABELA

O clássico dos clássicos.


🔥 EXEMPLO COBOL JUNIOR

01 WS-TABELA.
   05 WS-ITEM OCCURS 10 TIMES
      PIC X(10).

01 IDX PIC 9(04).

Tudo bem.

Mas aí:

MOVE WS-ITEM(999) TO WS-CAMPO

O COBOL tenta acessar memória além da tabela.

Resultado:

☠️ S0C4


☕ O DEMÔNIO CHAMADO SSRANGE

Sem:

SSRANGE

o COBOL NÃO protege tabelas adequadamente.

Então:

  • leitura inválida

  • corrupção silenciosa

  • overlay

  • S0C4 mais tarde


🔥 O S0C4 FANTASMA

O mais assustador.

Erro aparece LONGE da causa real.


☕ EXEMPLO

Linha 100:

MOVE lixo para tabela

Linha 5000:

💥 S0C4

O dano ocorreu antes.

Mas a explosão veio depois.


🔥 O S0C4 E O CICS

No CICS normalmente vira:

🚨 ASRA + S0C4

O CICS intercepta o program check.


☕ O CASO MAIS FAMOSO NO CICS

DFHCOMMAREA inválida

Programa espera:

01 DFHCOMMAREA.
   05 WS-CODIGO PIC 9(05).

Mas recebe:

  • tamanho menor

  • layout diferente

  • lixo

  • ponteiro inválido

Agora:

MOVE WS-CODIGO

explode.


🔥 O LINKAGE SECTION MALDITO

Outro clássico.


☕ EXEMPLO

PROCEDURE DIVISION USING LK-AREA.

Mas o chamador envia:

parâmetro incompatível

Agora o programa lê memória errada.

Resultado:

☠️ S0C4


🔥 O VERDADEIRO HORROR: OVERLAY

Aqui começa o lado sombrio do mainframe.


☕ O QUE É OVERLAY?

Programa sobrescreve memória alheia.

Exemplo:

STRING A B C
 INTO CAMPO-PEQUENO

Overflow.

Agora memória próxima é destruída.

Mais tarde:

💥 S0C4


🔥 O S0C4 E O PONTEIRO NULO

Muito comum em:

  • assembler

  • C

  • LE

  • APIs

Equivalente mainframe do:

NULL POINTER


☕ O QUE O DUMP ESTÁ DIZENDO

O dump do S0C4 é um mapa do crime.

Veteranos leem como CSI mainframe.


🔥 COMO INVESTIGAR PASSO A PASSO


✅ PASSO 1 — IDENTIFIQUE O PSW

Exemplo:

PSW AT TIME OF ERROR

Esse é o GPS do desastre.


✅ PASSO 2 — PEGUE O INTERRUPTION CODE

Exemplo:

0004

ou:

00000010

Ajuda identificar:

  • protection

  • addressing

  • translation


✅ PASSO 3 — IDENTIFIQUE O OFFSET

Exemplo:

OFFSET X'02FA'

✅ PASSO 4 — CRUZE COM O LISTING COBOL

Agora você encontra:

MOVE WS-TABELA(IDX)

Boom.

Caso resolvido.


☕ O SEGREDO DOS REGISTERS

Especialmente:

R1
R13
R14
R15

☕ R13

Stack/save area.


☕ R14

Return address.


☕ R15

Entry point/programa.


🔥 O HEXADECIMAL ENTRE AS SOMBRAS

Veteranos analisam:

00000000

Endereço zero.

Clássico ponteiro inválido.


☕ O “LOW VALUES DA MORTE”

Outro clássico:

X'00'

Memória zerada sendo usada como endereço.


🔥 O S0C4 E O AMODE/RMODE

Modo arquimago mainframe ativado.

Problemas entre:

  • 24 bits

  • 31 bits

  • 64 bits

podem gerar endereços inválidos.


☕ O S0C4 E O COBOL MODERNO

Hoje ainda ocorre muito por:

  • APIs

  • ponteiros

  • XML PARSE

  • JSON PARSE

  • LE

  • integração C


🔥 COMO EVITAR S0C4


✅ Compile com SSRANGE


✅ Valide índices


✅ Revise OCCURS


✅ Cuidado com REDEFINES


✅ Valide COMMAREA


✅ Nunca confiar em parâmetro externo


✅ Revisar overlays


☕ O SSRANGE — O ESCUDO DOS JEDIS

Compilar:

SSRANGE

faz o COBOL detectar acesso inválido ANTES da corrupção.

Sem isso:

corrupção silenciosa.


🔥 CURIOSIDADE HISTÓRICA

O S0C4 vem das arquiteturas:

IBM System/360

Década de:

🏛️ 1960

É literalmente um dos mecanismos clássicos de proteção de memória da história da computação.


☕ EASTER EGG MAINFRAME

Veteranos brincam:

“S0C4 é o mainframe dizendo:

VOCÊ TOCOU ONDE NÃO DEVIA.”


🔥 O MAIOR ERRO DO PADAWAN

Olhar apenas:

S0C4

e pensar:

“o COBOL morreu aqui.”

Não.

Frequentemente:

o crime aconteceu muito antes.


☕ A VERDADE FINAL

O S0C7 destrói números.
O S0C1 destrói instruções.
Mas…

☕ O S0C4 DESTRÓI A PRÓPRIA GEOGRAFIA DA MEMÓRIA.

Porque naquele instante…

O PROGRAMA TENTOU ATRAVESSAR UMA FRONTEIRA QUE O IBM Z JAMAIS PERMITIRIA.

domingo, 14 de abril de 2013

☕🔥 ABEND S0C1 — O “SALTO PARA O VAZIO” DO MAINFRAME

 

Brllacosa Mainframe abend soc1

☕🔥 ABEND S0C1 — O “SALTO PARA O VAZIO” DO MAINFRAME

Quando a CPU IBM Z Tenta Executar…

“ALGO QUE NÃO É UM PROGRAMA.”

Se existe um ABEND que faz o programador COBOL olhar o dump como se fosse hieróglifo alienígena…

é o lendário:

🚨 S0C1

E normalmente ele aparece assim:

IEC999I SYSTEM COMPLETION CODE=0C1

ou:

ABEND=S0C1 U0000 REASON=00000001

ou ainda:

OPERATION EXCEPTION

E aí o Junior Padawan pensa:

“Meu COBOL está quebrado?”
“O compilador enlouqueceu?”
“O load module morreu?”
“A CPU tentou executar magia negra?”

☕ Calma.

Porque o S0C1 é um dos ABENDs MAIS PROFUNDOS do universo z/OS.


🔥 O QUE É O S0C1?

O S0C1 é um:

🚨 OPERATION EXCEPTION

Traduzindo:

A CPU tentou executar uma instrução inválida.

Ou seja:

O processador IBM Z olhou para um byte da memória e disse:

❌ “ISSO NÃO É UMA INSTRUÇÃO MACHINE CODE VÁLIDA.”


☕ A FILOSOFIA DO S0C1

O S0C1 é assustador porque normalmente significa:

o fluxo do programa saiu da realidade esperada.

Algo desviou execução para:

  • lixo

  • dados

  • memória corrompida

  • endereço inválido

  • programa errado

  • módulo quebrado


🔥 O QUE REALMENTE ACONTECE

Imagine:

CPU IBM Z

Executando:

LOAD
ADD
MVC
BRANCH

Tudo normal.

Mas de repente…

o Program Counter aponta para:

FF FF FF FF

ou:

40404040

A CPU tenta interpretar aquilo como instrução.

Resultado:

💥 S0C1


☕ ANALOGIA BELLACOSA MAINFRAME

Imagine um piloto automático de avião.

Ele espera comandos válidos:

SUBIR
DESCER
CURVA

Mas recebe:

ABACAXI CÓSMICO

O sistema entra em colapso.

Isso é o S0C1.


🔥 O MAIOR SEGREDO

S0C1 raramente é “o problema”.

Ele normalmente é:

consequência de corrupção anterior.


☕ AS CAUSAS MAIS COMUNS


🚨 CALL para programa inexistente

Clássico absoluto.

CALL 'PGMXYZ'

Mas o módulo:

não existe

ou está errado.


🚨 Link-edit incorreto

Load module quebrado.


🚨 Branch para storage inválido

O programa desviou para memória errada.


🚨 Overlay de memória

Programa sobrescreveu área crítica.


🚨 Parameter list inválida

Muito comum em LINKAGE SECTION.


🚨 Executar dados como código

O horror máximo.


☕ O CASO MAIS FAMOSO

COBOL CHAMANDO MÓDULO ERRADO

Exemplo:

CALL WS-NOME-PGM

Mas:

WS-NOME-PGM = '     '

ou:

WS-NOME-PGM = '12345'

Agora o sistema tenta carregar lixo.

Resultado:

☠️ S0C1


🔥 O “CALL DINÂMICO MALDITO”

Veteranos têm pesadelos com isso.


☕ CALL ESTÁTICO

Seguro:

CALL 'CALCPGM'

☕ CALL DINÂMICO

Perigoso:

CALL WS-PGM

Porque:

  • pode vir espaço

  • pode vir lixo

  • pode vir nome inválido

  • pode vir lower-case

  • pode vir módulo inexistente


🔥 O S0C1 E O LOAD MODULE

Outro clássico.

Programa compilou.

Mas:

  • link-edit errado

  • módulo corrompido

  • versão incompatível

  • biblioteca incorreta

Então o entry point fica inválido.


☕ O S0C1 E O CICS

No CICS ele normalmente vira:

🚨 ASRA + S0C1

Porque o CICS encapsula o erro.


🔥 O VERDADEIRO TERROR: OVERLAY

Aqui começa o lado sombrio do mainframe.


☕ O QUE É OVERLAY?

Programa sobrescreve memória que não deveria.

Exemplo:

MOVE WS-TEXTO(1:500)
  TO WS-CAMPO(1:10)

ou:

SUBSCRIPT fora da tabela

Agora bytes críticos são destruídos.

Mais tarde…

a CPU tenta executar aquela região.

Resultado:

☠️ S0C1


🔥 O S0C1 FANTASMA

O mais assustador.

Erro acontece LONGE da causa real.

Exemplo:

Linha 100 corrompe memória

Mas o programa explode:

na linha 9000

☕ COMO INVESTIGAR O S0C1 PASSO A PASSO


✅ PASSO 1 — IDENTIFIQUE O PSW

O dump mostra:

PSW AT TIME OF ERROR

Esse é o GPS da tragédia.


✅ PASSO 2 — VEJA O ENDEREÇO

Exemplo:

INSTRUCTION ADDRESS = 00F13A92

✅ PASSO 3 — OLHE O OPCODE

O dump mostra algo como:

0000 0000
FFFFFFFF
40404040

Veterano já suspeita:

“isso não é código executável.”


🔥 O HEXADECIMAL MAIS ASSUSTADOR

40404040

No EBCDIC:

espaços

Ou seja:

A CPU tentou executar espaços como instrução.

Isso é clássico S0C1.


☕ COMO LER O DUMP


☕ PSW

Mostra:

  • endereço

  • modo da CPU

  • interrupção


☕ REGISTERS

Especialmente:

R14
R15

☕ R15

Muitas vezes aponta:

  • programa atual

  • entry point


☕ OFFSET

Exemplo:

OFFSET X'01FA'

Cruze com o listing COBOL.


🔥 O MOMENTO JEDI

Você pega:

  • PSW

  • offset

  • compile listing

E encontra:

CALL WS-PGM

Boom.

Caso resolvido.


☕ O S0C1 E O JCL

Outro clássico:

//STEPLIB DD DSN=LIB.ERRADA

Programa carrega versão incompatível.

Resultado:

💥 S0C1


🔥 O S0C1 E O AMODE/RMODE

Agora entramos no modo arquimago mainframe.

Problemas entre:

  • AMODE 24

  • AMODE 31

  • AMODE 64

podem causar branches inválidos.


☕ O S0C1 E O LE (LANGUAGE ENVIRONMENT)

Às vezes:

  • LE incompatível

  • runtime quebrado

  • mismatch de compilação

também geram S0C1.


🔥 COMO EVITAR S0C1


✅ Validar CALL dinâmico


✅ Não usar nomes vazios


✅ Evitar overlays


✅ Validar subscripts


✅ Revisar LINKEDIT


✅ Conferir STEPLIB/JOBLIB


✅ Usar SSRANGE

Grande arma contra corrupção de tabela.


☕ O SSRANGE — ESCUDO DOS PADAWANS

Compilar com:

SSRANGE

faz COBOL detectar acesso inválido em tabela.

Sem isso:

corrupção silenciosa.


🔥 CURIOSIDADE HISTÓRICA

O S0C1 vem das arquiteturas System/360.

Década de:

🏛️ 1960

Estamos falando de um erro nascido literalmente junto com a computação corporativa moderna.


☕ EASTER EGG MAINFRAME

Veteranos brincam:

“S0C1 é a CPU dizendo:

EU NÃO FAÇO IDEIA DO QUE VOCÊ MANDOU EXECUTAR.”


🔥 O MAIOR ERRO DO JÚNIOR

Ver:

S0C1

e assumir:

“o COBOL está errado.”

Não.

Frequentemente:

  • ambiente

  • load module

  • memória

  • linkage

  • call

  • JCL

são os culpados.


☕ A VERDADE FINAL

O S0C7 quebra números.
O S0C4 quebra memória.
Mas…

☕ O S0C1 QUEBRA A PRÓPRIA LINGUAGEM DA CPU.

Porque naquele instante…

O IBM Z PAROU DE ENTENDER O QUE ESTAVA SENDO EXECUTADO.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

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
GitHub LinkedIn
Inicializando conteúdo...