 |
| Bellacosa Mainframe e o tratamento de erro no Cobol Parte 1 |
EXCEPTION/ERROR Procedures em COBOL: Os Holocrons Esquecidos do Tratamento de Erros no IBM Z
Parte 1 – O Despertar das DECLARATIVES
Quando o Padawan Descobre que COBOL Possui Seu Próprio Mecanismo Jedi de Tratamento de Erros
Por Bellacosa Mainframe
"Todo Padawan aprende FILE STATUS. Alguns aprendem AT END. Pouquíssimos descobrem que COBOL possui um mecanismo ancestral capaz de interceptar falhas antes que elas se transformem em um ABEND às três da manhã."
Mestre Bellacosa Sysprog Jedi
Introdução
Existe um momento na vida de praticamente todo desenvolvedor COBOL em que ele acredita ter dominado completamente o tratamento de erros.
Ele aprendeu:
FILE STATUS.
Aprendeu:
AT END
Aprendeu:
INVALID KEY
Aprendeu:
ON EXCEPTION
Aprendeu:
ON SIZE ERROR
E então pensa:
Mestre...
Acho que já sei tudo sobre tratamento de erros em COBOL.
O mestre Bellacosa sorri.
Abre um velho manual ANSI COBOL.
Mostra algumas linhas quase esquecidas.
E pergunta:
DECLARATIVES.
ARQ-ERROR SECTION.
USE AFTER STANDARD ERROR PROCEDURE ON ARQUIVO1.
O jovem Padawan arregala os olhos.
O que é isso?
O mestre responde:
Jovem Padawan...
Você acaba de encontrar um dos Holocrons mais antigos e menos estudados do COBOL.
O Grande Mito
Existe um mito bastante difundido.
Muitos acreditam:
COBOL não possui tratamento centralizado de erros.
Na verdade possui.
Há décadas.
E ele atende pelo nome:
DECLARATIVES
O que são DECLARATIVES?
Declaratives são blocos especiais.
São definidos antes da PROCEDURE DIVISION.
Possuem finalidade específica.
Capturar condições excepcionais.
Visualmente.
Programa COBOL
↓
Erro
↓
DECLARATIVES
↓
Tratamento
↓
Continua
ou
Termina
É quase um ancestral dos modernos:
try
catch
exception handler
interceptor
middleware de erros
Quando surgiu?
Precisamos voltar bastante no tempo.
COBOL-68
Possuía capacidades limitadas.
ANSI COBOL 74
Introduziu mecanismos iniciais.
ANSI COBOL 85
Consolidou.
DECLARATIVES.
USE.
Error Procedures.
IBM manteve suporte.
VS COBOL II.
COBOL for MVS.
Enterprise COBOL.
COBOL 6.5.
Sim.
Em 2026.
Ainda funciona.
Por que quase ninguém usa?
Porque a maioria dos programadores aprende.
FILE STATUS.
INVALID KEY.
AT END.
E para por aí.
As Declaratives ficaram escondidas.
Por décadas.
Muitos profissionais com vinte anos de experiência.
Nunca escreveram uma.
Anatomia das Declaratives
Estrutura.
DECLARATIVES.
ERRO-ARQ SECTION.
USE AFTER STANDARD ERROR PROCEDURE
ON ARQCLIENTE.
TRATA-ERRO.
DISPLAY 'ERRO'.
END DECLARATIVES.
Depois.
PROCEDURE DIVISION.
Muito importante.
Declaratives ficam.
Antes.
Da lógica principal.
O que significa USE?
USE é uma instrução especial.
Ela informa.
Ao runtime.
Quando determinada condição ocorrer.
Execute.
Este bloco.
Exemplo.
USE AFTER STANDARD ERROR PROCEDURE
ON CLIENTES.
Significa.
Se CLIENTES falhar.
Execute.
Esta rotina.
O que é STANDARD ERROR PROCEDURE?
Talvez seja a expressão mais misteriosa.
Significa.
Erros detectados.
Pelo sistema de I/O COBOL.
Exemplos.
OPEN
READ
WRITE
REWRITE
DELETE
START
CLOSE
Falhou.
Declaratives.
Recebem controle.
Primeiro exemplo do Padawan
Passo 1
Arquivo.
SELECT CLIENTE
ASSIGN TO ARQCLI
FILE STATUS WS-FS.
Passo 2
Status.
01 WS-FS.
PIC XX.
Passo 3
Declarative.
DECLARATIVES.
ARQ-ERRO SECTION.
USE AFTER STANDARD ERROR PROCEDURE
ON CLIENTE.
ARQ-ERRO-PROC.
DISPLAY 'ERRO'
WS-FS.
END DECLARATIVES.
Passo 4
Procedure.
PROCEDURE DIVISION.
OPEN INPUT CLIENTE.
Arquivo inexistente.
Declarative executa.
Muito elegante.
Fluxo interno
Visualmente.
OPEN
↓
Erro
↓
Runtime COBOL
↓
Declarative
↓
Retorna
ou
STOP RUN
Quase um middleware.
Memória
Padawan pergunta.
Mestre...
Como isso funciona na memória?
Boa pergunta.
Compilador.
Cria.
Tabelas internas.
Associa.
Arquivo.
↓
Rotina.
Quando erro.
Runtime.
Consulta.
Tabela.
Transfere.
Controle.
Visualmente.
Tabela
CLIENTE
↓
ARQ-ERRO
Sem overhead grande.
Muito eficiente.
Chamada automática
Importante.
Programador.
Não faz.
PERFORM ARQ-ERRO
Runtime.
Faz.
Automaticamente.
Quase.
Interrupção.
Controlada.
Pode haver vários?
Sim.
Exemplo.
CLIENTE
↓
DECL1
PEDIDO
↓
DECL2
ESTOQUE
↓
DECL3
Muito poderoso.
FILE STATUS versus DECLARATIVES
Muitos perguntam.
Qual melhor?
FILE STATUS
Explícito.
Exemplo.
OPEN INPUT ARQ.
IF WS-FS NOT = '00'
Vantagem.
Simples.
Problema.
Repete.
Muito.
DECLARATIVES.
Centralizado.
Muito elegante.
Grande volume.
Melhor.
INVALID KEY
Outra dúvida.
INVALID KEY.
Funciona.
Com VSAM.
Declarative.
Mais abrangente.
Pode capturar.
Vários erros.
Cuidados
Nem tudo.
São flores.
Primeiro.
Evitar.
Lógica complexa.
Dentro.
Declarative.
Segundo.
Não abrir.
Mesmo arquivo.
Novamente.
Terceiro.
Cuidado.
Loops.
Exemplo ruim.
Erro.
↓
Declarative.
↓
READ.
↓
Erro.
↓
Declarative.
↓
Loop.
Muito perigoso.
Performance
Excelente.
Quase.
Zero impacto.
Só executa.
Quando.
Erro.
Em produção.
Pouco custo.
Segurança
Pouco comentado.
Muito útil.
Auditoria.
Exemplo.
Registrar.
Arquivo.
Usuário.
Timestamp.
Erro.
Excelente.
Compliance.
LGPD.
SOX.
Auditoria.
Framework Bellacosa
Gosto bastante.
Modelo.
Declarative
↓
Logger
↓
Dataset LOG
↓
MQ
↓
Splunk
↓
Observabilidade
Muito elegante.
Curiosidades
Pouquíssimos desenvolvedores COBOL modernos.
Conhecem.
DECLARATIVES.
Muitos arquitetos bancários.
Adoram.
Principalmente.
Frameworks.
Antigos.
Curiosidade 2
VS COBOL II.
Utilizava.
Muito.
Hoje.
Menos comum.
Curiosidade 3
CICS.
Possui.
Algo semelhante.
HANDLE CONDITION.
Veremos.
Parte 3.
Bellacosa Best Practices
Sempre.
FILE STATUS.
Mesmo.
Com Declaratives.
Documente.
Tudo.
Não abuse.
Use.
Logging.
Padronize.
Framework.
Não coloque.
Regra negócio.
Somente.
Tratamento.
Erro.
O Conselho do Mestre Bellacosa
Durante décadas, milhares de programadores COBOL trataram erros utilizando IF FILE-STATUS, INVALID KEY e AT END.
E isso funciona muito bem.
Mas escondido nas profundezas dos antigos padrões ANSI existe um mecanismo sofisticado.
Elegante.
Pouco conhecido.
Quase esquecido.
Chamado DECLARATIVES.
Ele lembra uma antiga técnica Jedi.
Não é utilizada todos os dias.
Não é necessária para pequenos programas.
Mas quando um sistema possui dezenas de arquivos, centenas de jobs e requisitos rigorosos de auditoria, observabilidade e recuperação, ela pode transformar um emaranhado de verificações repetitivas em uma arquitetura limpa e centralizada.
Talvez esta seja a principal lição da primeira jornada.
O jovem Padawan verifica FILE STATUS.
O Cavaleiro utiliza ON EXCEPTION.
O Mestre Bellacosa conhece DECLARATIVES.
E o Conselho Jedi do IBM Z sabe exatamente quando utilizá-las.
Sem comentários:
Enviar um comentário