 |
| 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.
Sem comentários:
Enviar um comentário