✨ 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

Mostrar mensagens com a etiqueta qualidade de software. Mostrar todas as mensagens

quinta-feira, 11 de junho de 2026

☕💣🚀 PADAWAN, TESTAR COBOL NÃO É DESCONFIAR DO PROGRAMA. É DESCONFIAR DE SI MESMO!

Bellacosa Mainframe e tecnicas e ferramentas de teste automatizado em ibm mainframe

☕💣🚀 PADAWAN, TESTAR COBOL NÃO É DESCONFIAR DO PROGRAMA. É DESCONFIAR DE SI MESMO!

A Arte Esquecida dos Testes no IBM Mainframe

Existe uma crença antiga nos corredores dos CPDs:

"Se compilou sem erro e rodou em produção, então está certo."

Foi exatamente esse tipo de pensamento que produziu alguns dos maiores incidentes da história da computação corporativa.

No mundo Mainframe, um erro não afeta apenas um usuário.

Pode afetar:

milhões de contas bancárias
faturamento de operadoras
pagamento de aposentadorias
processamento de cartões
sistemas governamentais

Por isso, testar COBOL nunca foi opcional.

Sempre foi sobrevivência.

O curioso é que durante décadas o programador COBOL executava testes praticamente de forma artesanal:

Criava um arquivo de teste
Submetia um JOB
Esperava terminar
Analisava SYSOUT
Corrigia
Repetia

Hoje o cenário mudou radicalmente.

Temos frameworks modernos, automação, DevOps, CI/CD e até testes unitários para COBOL.

Sim.

Você leu corretamente.

Testes unitários para COBOL.

Como Pensar em Testes COBOL

Antes das ferramentas, precisamos entender os níveis de teste.

1. Teste Unitário

Valida apenas uma rotina.

Exemplo:

Programa calcula juros.

Entrada:

VALOR = 1000
TAXA  = 10

Saída esperada:

Nada de arquivos.

Nada de DB2.

Nada de CICS.

Somente lógica.

2. Teste de Integração

Valida interação entre componentes.

Exemplo:

COBOL
 ↓
DB2
 ↓
MQ
 ↓
Outro Sistema

Aqui os problemas aparecem.

A lógica funciona.

A integração não.

3. Teste de Sistema

Avalia o fluxo completo.

Exemplo:

Tela CICS
 ↓
COBOL
 ↓
DB2
 ↓
IMS
 ↓
MQ

Tudo junto.

Como acontece na produção.

4. Teste de Regressão

O mais importante.

Você altera uma linha.

Precisa garantir que não destruiu outras 500 funcionalidades.

É aqui que a automação brilha.

Ferramenta 1 — IBM ZUnit

A joia da coroa da IBM.

ZUnit é o framework oficial de testes unitários para COBOL.

Foi criado para trazer ao Mainframe conceitos comuns em Java e .NET.

Zunit - https://eljefemidnightlunch.blogspot.com/2021/05/padawan-o-zunit-e-o-momento-em-que-o.html

Vantagens

✔ Teste automatizado

✔ Integrado ao IDz

✔ Repetível

✔ Excelente para DevOps

✔ Integração com pipelines

Desvantagens

✘ Curva de aprendizado

✘ Dependência do ecossistema IBM

✘ Nem sempre simples para programas antigos

Exemplo Prático com ZUnit

Suponha o programa:

IDENTIFICATION DIVISION.
PROGRAM-ID. CALCJURO.

COMPUTE VALOR-FINAL =
        VALOR + (VALOR * TAXA / 100).

Passo 1

Abrir IDz.

Passo 2

Criar projeto ZUnit.

File
  New
    ZUnit Test Case

Passo 3

Selecionar programa COBOL.

CALCJURO

Passo 4

Definir entrada.

VALOR = 1000
TAXA  = 10

Passo 5

Definir saída esperada.

Passo 6

Executar.

Run As
   ZUnit Test

Resultado:

PASS

FAIL

Ferramenta 2 — IBM COBOL Check: Encontrando Defeitos Antes da Execução

Antes de executar qualquer teste, existe uma etapa ainda mais inteligente.

A análise estática.

É aqui que entra o IBM COBOL Check.

IBM Cobol Check - https://eljefemidnightlunch.blogspot.com/2026/06/ibm-cobol-check-ferramenta-que-trouxe.html

O Que É?

O COBOL Check examina o código-fonte procurando defeitos potenciais sem executar uma única instrução.

Ele atua como um inspetor de qualidade automatizado.

Enquanto o ZUnit pergunta:

"O programa funciona?"

O COBOL Check pergunta:

"Existe algo suspeito neste código?"

Problemas Detectados

Variáveis Não Inicializadas

01 WS-TOTAL PIC 9(05).

ADD 100 TO WS-TOTAL.

O campo recebeu valor antes?

Talvez não.

Índices Fora da Faixa

MOVE 150 TO WS-INDICE.

MOVE 'ABC' TO WS-DADO(WS-INDICE).

Tabela com apenas 100 ocorrências.

Possível S0C4.

Código Morto

STOP RUN.

DISPLAY 'NUNCA EXECUTA'

Trecho inalcançável.

Condições Impossíveis

IF VALOR > 100
AND VALOR < 50

Nunca será verdadeiro.

Possíveis S0C7

MOVE 'ABCDE' TO CAMPO-NUMERICO.

ADD 1 TO CAMPO-NUMERICO.

Compila.

Mas pode explodir em produção.

Vantagens do COBOL Check

✔ Não precisa executar o programa

✔ Automatizável

✔ Excelente para DevOps

✔ Descobre defeitos cedo

✔ Padronização corporativa

Desvantagens

✘ Não substitui testes

✘ Pode gerar falsos positivos

✘ Requer parametrização adequada

Ferramenta 3 — IBM Debug Tool

Muita gente acha que Debug Tool serve apenas para depuração.

Errado.

Ele também é excelente para validação de comportamento.

Vantagens

✔ Sem alterar código

✔ Breakpoints

✔ Análise em tempo real

✔ Visualização de variáveis

Desvantagens

✘ Não substitui testes automatizados

✘ Processo mais manual

Exemplo

Interceptar:

COMPUTE TOTAL = A + B

Durante execução:

AT LINE 125
DISPLAY TOTAL

Verificando se:

10 + 15 = 25

Ferramenta 4 — File-AID

Uma das ferramentas mais usadas para testes.

Principalmente em ambientes bancários.

O que faz?

Criação de massa de testes.

Manipulação de arquivos.

Comparação de resultados.

Exemplo

Criar arquivo VSAM contendo:

CLIENTE 001
CLIENTE 002
CLIENTE 003

Executar programa.

Comparar resultado.

Vantagens

✔ Rápido

✔ Simples

✔ Excelente para testes batch

Desvantagens

✘ Não executa lógica unitária

✘ Foco em dados

Ferramenta 5 — Xpediter

O lendário depurador da Compuware/BMC.

Praticamente um microscópio para COBOL.

Permite

Breakpoints
Alteração dinâmica
Rastreamento
Simulação

Vantagens

✔ Muito poderoso

✔ Excelente para programas complexos

✔ Integração com CICS

Desvantagens

✘ Licenciamento

✘ Excesso de recursos para iniciantes

Ferramenta 6 — Abend-AID

Não é exatamente uma ferramenta de testes.

Mas salva vidas.

Quando ocorre:

S0C7

S0C4

Ela mostra:

linha exata
variável envolvida
conteúdo dos campos

Vantagens

✔ Diagnóstico rápido

✔ Redução de MTTR

✔ Histórico de falhas

Desvantagens

✘ Atua após o erro

✘ Não evita defeitos

Técnica Clássica: Golden File

Uma das técnicas mais usadas em Mainframe.

Executa-se um programa conhecido.

Resultado esperado:

ARQ-OK

Depois da alteração:

ARQ-NOVO

Comparação:

SUPERC

File-AID Compare

Se forem idênticos:

TESTE APROVADO

Técnica Moderna: Mocking

Muito usada com ZUnit.

Imagine:

SELECT CLIENTE
       ASSIGN TO VSAMCLI.

Em vez de acessar VSAM real:

VSAM MOCK

Resultado:

teste rápido
sem riscos
repetível

Técnica de Cobertura

Pergunta simples:

Quanto do programa foi realmente executado?

Muitos acreditam:

Teste passou

Logo:

Programa está correto

Não necessariamente.

Você pode ter testado apenas 20% dos caminhos.

Ferramentas modernas ajudam a medir cobertura.

Curiosidades Históricas

COBOL já tinha testes antes da moda

Décadas antes de JUnit existir:

Programadores Mainframe já criavam:

ARQTEST1
ARQTEST2
ARQTEST3

Executando cenários controlados.

Na prática, eram testes unitários artesanais.

O custo do erro

Um defeito descoberto:

Durante codificação → custo 1x
Durante homologação → custo 10x
Em produção → custo 100x

Essa regra continua válida.

Grandes bancos executam milhões de testes

Em ambientes modernos de DevOps Mainframe, pipelines podem disparar milhares de testes automáticos a cada alteração de código COBOL.

O objetivo é simples:

Quebrar no laboratório para não quebrar na produção.

Dicas do Bellacosa

☕ Dica 1

Nunca teste apenas o cenário feliz.

Teste:

zeros
negativos
máximos
mínimos
espaços
nulos

☕ Dica 2

Todo S0C7 que chega em produção é um teste que faltou.

☕ Dica 3

Crie bibliotecas permanentes de massa de testes.

Economiza centenas de horas.

☕ Dica 4

Automatize tudo o que puder.

O programador esquece.

O script não.

☕ Dica 5

Sempre mantenha testes de regressão após correções.

O defeito corrigido hoje costuma reaparecer daqui seis meses.

Exemplo de Pipeline DevOps Mainframe

Git
 ↓
Commit
 ↓
Build COBOL
 ↓
ZUnit
 ↓
Análise de Qualidade
 ↓
Deploy Homologação
 ↓
Testes Integração
 ↓
Produção

Cada etapa reduz riscos.

Cada teste reduz surpresas.

Resumo Executivo

Testar COBOL em ambiente IBM Mainframe deixou de ser uma atividade manual e passou a ser parte fundamental da engenharia moderna de software. Ferramentas como IBM ZUnit, Debug Tool, File-AID, Xpediter e Abend-AID permitem validar lógica, criar massas de teste, depurar falhas e automatizar regressões. O segredo não está apenas na ferramenta, mas na disciplina de criar cenários abrangentes, automatizar execuções e manter uma suíte de testes confiável. No fim das contas, o verdadeiro profissional Mainframe não é aquele que nunca gera defeitos. É aquele que constrói mecanismos para encontrá-los antes que o cliente encontre primeiro.

☕💣🚀 PADAWAN, O TESTE NÃO EXISTE PARA PROVAR QUE SEU COBOL ESTÁ CERTO. ELE EXISTE PARA PROVAR QUANTAS MANEIRAS ELE AINDA TEM DE DAR ERRADO ANTES DA PRODUÇÃO DESCOBRIR!

segunda-feira, 8 de junho de 2026

IBM COBOL Check: A Ferramenta Que Trouxe Testes Unitários Modernos Para o Mundo do Mainframe

Bellacosa Mainframe e o IBM Cobol Check

☕💣🚀 OPERADOR, O COBOL GANHOU UM JUNIT!

IBM COBOL Check: A Ferramenta Que Trouxe Testes Unitários Modernos Para o Mundo do Mainframe

Se você trabalhou anos com COBOL, provavelmente já viveu esta situação:

Altera o programa
↓
Compila
↓
Executa o JCL
↓
Espera o batch
↓
Confere SYSOUT
↓
Descobre erro
↓
Volta para o início

Durante décadas essa foi a rotina natural do desenvolvedor Mainframe.

Enquanto isso, no mundo Java, C#, Python e JavaScript, os programadores criavam centenas de testes automatizados que validavam cada função antes mesmo do deploy.

Então surgiu uma pergunta:

"Por que COBOL não pode fazer o mesmo?"

Foi exatamente dessa necessidade que nasceu o COBOL Check.

O Que é o IBM COBOL Check?

O COBOL Check é um framework de testes unitários para COBOL inspirado diretamente em ferramentas como:

JUnit (Java)
NUnit (.NET)
PyTest (Python)
RSpec (Ruby)

Seu objetivo é permitir que desenvolvedores criem testes automatizados para programas COBOL de forma granular, validando regras de negócio sem depender de execuções batch completas. (GitHub)

Na prática, ele permite testar:

Parágrafos
Seções
Regras de negócio
Cálculos
Validações
Programas inteiros

Tudo de forma automatizada.

Quem Criou o COBOL Check?

Muita gente pensa que é um produto comercial da IBM.

Na realidade, o COBOL Check nasceu dentro do ecossistema do Open Mainframe Project, com apoio da comunidade Mainframe moderna e contribuições de empresas que utilizam COBOL em larga escala. (GitHub)

Seu propósito era resolver um problema antigo:

Como fazer microtestes em aplicações COBOL do mesmo modo que fazemos em Java?

Quando Foi Lançado?

O projeto apareceu publicamente no final da década de 2010 dentro do movimento de modernização DevOps para IBM Z.

Ele surgiu durante a onda de iniciativas Open Source voltadas ao Mainframe, juntamente com projetos como:

Zowe
IBM Z Open Editor
DBB
Galasa

e rapidamente ganhou destaque por trazer testes unitários para COBOL de forma simples. (GitHub)

O Problema Que Ele Resolve

Imagine um programa bancário.

CALCULA-JUROS.
    COMPUTE JUROS =
       SALDO * TAXA.

Sem testes unitários você normalmente:

Compila.
Executa JCL.
Alimenta arquivos.
Analisa relatórios.
Verifica resultados.

Tudo isso para validar uma única regra.

Com COBOL Check você cria um teste automatizado.

A Grande Ideia

O conceito é exatamente o mesmo do JUnit.

Você cria:

Código

CALCULA-DESCONTO.

Teste

TEST-DESCONTO.

Execução

PASS

FAIL

Simples assim.

Como Funciona Internamente?

O COBOL Check cria um ambiente de teste que:

Executa trechos específicos do programa
Injeta dados de entrada
Compara resultados
Gera relatórios

Ele também oferece suporte para:

Assertions
Stubs
Mocks
Verificação de chamadas
Relatórios JUnit XML
Relatórios HTML (GitHub)

Isso o aproxima bastante dos frameworks modernos.

Sistemas Suportados

O foco principal é:

IBM z/OS

Utilizando:

Enterprise COBOL
JCL
Ambientes tradicionais de produção

Também pode ser utilizado em ambientes modernos ligados ao ecossistema Open Mainframe.

Dependências

Uma instalação típica envolve:

Compilador COBOL

Normalmente:

Enterprise COBOL V5+
Enterprise COBOL V6+

Ambiente z/OS

TSO
ISPF
USS (quando aplicável)

Ferramentas modernas

Frequentemente combinado com:

Git
Jenkins
Zowe
DBB
IBM Z Open Editor (Marketplace do Visual Studio)

Como Instalar

O processo varia conforme a empresa.

Em geral:

1. Obter o projeto

Disponível através do repositório oficial do Open Mainframe Project. (GitHub)

2. Fazer upload

Copiar os fontes para datasets do ambiente.

Exemplo:

USER.COBOLCHECK.SOURCE

3. Compilar

Executar os jobs de instalação.

//COMPILE EXEC IGYWCL

4. Configurar bibliotecas

Adicionar:

STEPLIB
SYSLIB
COPYLIB

5. Validar instalação

Executar os exemplos fornecidos.

Primeiro Exemplo Passo a Passo

Vamos criar algo simples.

Programa

IDENTIFICATION DIVISION.
PROGRAM-ID. CALC01.

WORKING-STORAGE SECTION.
01 WS-VALOR PIC 9(5).
01 WS-DESCONTO PIC 9(5).

PROCEDURE DIVISION.

    COMPUTE WS-DESCONTO =
       WS-VALOR * 10 / 100.

    GOBACK.

Cenário de Teste

Queremos provar que:

1000 = 100 de desconto

Caso de Teste

MOVE 1000 TO WS-VALOR

PERFORM CALCULO

ASSERT WS-DESCONTO = 100

Resultado

TESTE 001
PASS

Testando Múltiplos Cenários

Você pode criar vários testes.

Caso 1

1000 -> 100

Caso 2

2000 -> 200

Caso 3

5000 -> 500

Resultado:

3 TESTS
3 PASSED

Assertions

Uma das partes mais importantes.

Exemplo:

ASSERT TRUE

ASSERT FALSE

ASSERT EQUAL

ASSERT NOT EQUAL

Muito parecido com:

assertEquals()
assertTrue()
assertFalse()

Mocks

Outro recurso extremamente poderoso.

Imagine um programa que acessa:

DB2
VSAM
IMS
MQ

Você não quer depender desses recursos durante o teste.

Então cria um Mock.

Exemplo Conceitual

Produção:

READ CLIENTE

Teste:

MOCK CLIENTE

Resultado:

CLIENTE SIMULADO

Sem acessar banco real.

Stubs

Parecido com Mock.

Você substitui componentes complexos por versões simplificadas.

Exemplo:

CONSULTA-SERASA

vira

CONSULTA-SERASA-STUB

Permitindo testes rápidos.

Relatórios

Após executar os testes você pode gerar:

HTML

PASS
FAIL
TOTAL

XML

Formato compatível com:

Jenkins
GitHub Actions
Azure DevOps
GitLab CI/CD (GitHub)

Integração com Jenkins

Fluxo clássico:

Git Commit
      ↓
Build
      ↓
COBOL Check
      ↓
Relatório
      ↓
Deploy

Se um teste falhar:

BUILD FAILED

Sem deploy.

Integração com Git

Imagine:

Pull Request

Antes da aprovação:

Executar COBOL Check

Resultado:

Todos os testes passaram

Só então ocorre o merge.

Benefícios Para Bancos

Os maiores usuários são:

Bancos
Seguradoras
Telecom
Governo

Porque possuem milhões de linhas COBOL.

Alterar uma linha sem proteção pode gerar:

S0C7
Abends
Valores incorretos
Erros financeiros

O COBOL Check reduz drasticamente esse risco.

Curiosidade #1

Muitos programadores COBOL experientes inicialmente desconfiaram da ideia.

A reação típica era:

"Teste unitário é coisa de Java."

Hoje isso mudou completamente.

Curiosidade #2

O projeto nasceu justamente porque ferramentas comerciais existentes geralmente testavam programas inteiros, mas não permitiam testar pequenos blocos de lógica com granularidade suficiente. (GitHub)

Curiosidade #3

Uma das metas do COBOL Check era incentivar melhores práticas de desenvolvimento, como:

Separação de responsabilidades
Modularização
Refatoração segura

Conceitos já populares no mundo Java. (GitHub)

Dicas de Ouro

Dica 1

Comece pelos cálculos.

São os testes mais fáceis.

Dica 2

Não tente cobrir o sistema inteiro.

Comece pelos módulos críticos.

Dica 3

Automatize tudo.

Teste manual não escala.

Dica 4

Integre com Jenkins.

O ganho de produtividade é enorme.

Dica 5

Execute testes a cada alteração.

Não espere a homologação.

Erros Comuns

Erro 1

Criar testes enormes.

Ruim:

Testar 20 regras juntas

Bom:

1 regra = 1 teste

Erro 2

Depender de dados reais.

Use mocks.

Erro 3

Não automatizar.

Se o teste depende de ação humana:

Você perdeu metade do benefício.

Easter Egg Mainframe ☕

Existe uma ironia divertida na história.

Durante décadas ouvimos:

"COBOL é antigo."

Mas hoje encontramos no mundo COBOL:

✅ Git

✅ VS Code

✅ Pipelines CI/CD

✅ DevOps

✅ Open Source

✅ APIs REST

✅ Containers

✅ Testes Unitários

✅ Inteligência Artificial

Enquanto muitos sistemas "modernos" desaparecem após poucos anos, aplicações COBOL escritas nos anos 70 continuam processando bilhões de dólares diariamente.

O COBOL Check é um símbolo dessa evolução.

Ele mostra que o Mainframe não ficou parado no tempo.

Pelo contrário.

O gigante apenas incorporou as melhores ideias do desenvolvimento moderno sem abrir mão da estabilidade que o tornou lendário.

Conclusão

O COBOL Check representa uma das iniciativas mais importantes da modernização do desenvolvimento Mainframe.

Ele trouxe para o COBOL conceitos consagrados por ferramentas como JUnit, permitindo:

Testes unitários automatizados
Mocks e Stubs
Relatórios HTML e XML
Integração com CI/CD
Maior qualidade de código
Refatoração segura
Menor risco em produção (GitHub)

No estilo Bellacosa Mainframe, podemos resumir assim:

O COBOL Check é a prova definitiva de que o COBOL não ficou preso ao passado. O gigante aprendeu a testar como os sistemas modernos, mas continua entregando a confiabilidade que mantém bancos, governos e grandes empresas funcionando todos os dias. ☕💣🚀

quarta-feira, 15 de janeiro de 2025

☕📋💣 BACKLOG: O ARQUIVO SECRETO QUE SEPARA UM PROGRAMADOR COBOL COMUM DE UM VERDADEIRO ARQUITETO DE SISTEMAS

Bellacosa Mainframe e o backlog mainframe

☕📋💣 BACKLOG: O ARQUIVO SECRETO QUE SEPARA UM PROGRAMADOR COBOL COMUM DE UM VERDADEIRO ARQUITETO DE SISTEMAS

"O sistema não está parado. Ele apenas está esperando na fila."

Existe uma cena que se repete diariamente em praticamente todas as empresas que possuem Mainframe.

O telefone toca.

Um gerente aparece.

Um usuário reclama.

Um diretor pede urgência.

Uma área regulatória exige mudanças.

O banco central publica uma nova norma.

O auditor encontra uma inconsistência.

O operador identifica um erro.

E de repente surgem vinte novas tarefas.

A pergunta é:

quem decide o que será feito primeiro?

É exatamente nesse momento que nasce um dos conceitos mais importantes da engenharia de software moderna:

o Backlog.

Se você é um programador COBOL Mainframe iniciante, entender backlog pode acelerar sua carreira mais do que aprender cinquenta comandos novos de JCL.

Porque programar é importante.

Mas entender como o trabalho é organizado é o que diferencia um executor de um profissional estratégico.

Pegue seu café.

Vamos abrir esse dataset.

O QUE É BACKLOG?

A definição mais simples possível:

Backlog é uma lista organizada de tudo aquilo que precisa ser feito.

Simples assim.

Pode conter:

novas funcionalidades;
correções de bugs;
melhorias;
ajustes regulatórios;
documentação;
refatoração;
automação;
modernização.

Tudo entra no backlog.

Pense nele como uma fila de JOBs esperando para executar.

O BACKLOG EXPLICADO COMO UM JOB SCHEDULER

Imagine um ambiente de produção.

Você possui:

JOB001 - Fechamento diário
JOB002 - Atualização de clientes
JOB003 - Relatório gerencial
JOB004 - Backup
JOB005 - Auditoria

Todos precisam executar.

Mas existe uma ordem.

Backlog é exatamente isso.

Uma fila organizada de atividades aguardando execução.

A diferença é que em vez de JOBs estamos falando de trabalho humano.

O MAIOR MITO SOBRE BACKLOG

Muitos iniciantes acreditam:

"Backlog é uma lista de novas funcionalidades."

Errado.

Backlog é muito maior que isso.

Um backlog saudável contém:

inovação;
manutenção;
correções;
melhorias;
dívida técnica.

Quando só existem novas funcionalidades no backlog, algo está errado.

Muito errado.

UM EXEMPLO REAL DE MAINFRAME

Imagine um sistema bancário.

O backlog pode conter:

Criar PIX Internacional
Corrigir cálculo de juros
Atualizar layout FEBRABAN
Refatorar COBCLI01
Documentar JOB FAT0001
Criar testes para módulo de cobrança

Observe.

Nem tudo é desenvolvimento novo.

Parte do trabalho é manutenção.

Parte é prevenção.

Parte é sobrevivência.

ONDE ENTRA A DÍVIDA TÉCNICA?

Agora chegamos ao ponto interessante.

A dívida técnica normalmente vive dentro do backlog.

Por exemplo:

BACKLOG

Criar API de consulta
Novo relatório fiscal
Refatorar COBPAG01
Eliminar COPYBOOK duplicado
Automatizar testes

Os três últimos itens são pagamentos de dívida técnica.

Ou seja:

Todo pagamento de dívida técnica vira backlog.

Mas nem todo backlog é dívida técnica.

COMO A DÍVIDA TÉCNICA APARECE

Imagine que você recebeu uma demanda urgente.

O gerente diz:

"Precisamos colocar isso em produção amanhã."

Você cria uma solução rápida.

Funciona.

Entrega realizada.

Todo mundo feliz.

Meses depois:

ninguém entende o código;
faltam comentários;
surgem bugs;
novas alterações ficam lentas.

Pronto.

A dívida nasceu.

O EFEITO BOLA DE NEVE

O primeiro remendo parece inocente.

Depois vem outro.

E mais outro.

Então surge um IF dentro de outro IF.

Depois outro.

Quando você percebe:

IF A
   IF B
      IF C
         IF D
            IF E

O programa ainda funciona.

Mas ninguém mais entende.

Isso é o juros da dívida técnica.

O DIA EM QUE O BACKLOG VIROU UM CEMITÉRIO

Existe uma curiosidade interessante.

Algumas empresas possuem backlog com milhares de itens.

Mas ninguém sabe:

quem criou;
por que criou;
se ainda faz sentido.

Isso não é backlog.

É arqueologia corporativa.

COMO UM JÚNIOR DEVE ENXERGAR O BACKLOG

Não veja o backlog como uma lista de tarefas.

Veja como um mapa.

Ele mostra:

para onde o sistema está indo;
quais problemas existem;
quais riscos precisam ser tratados.

Os melhores analistas costumam estudar o backlog inteiro.

Não apenas sua tarefa.

COMO IDENTIFICAR DÍVIDA TÉCNICA

Existem sinais clássicos.

Programas gigantes

Mais de 10.000 linhas.

COPYBOOKs duplicados

Mesma estrutura espalhada.

JCLs clonados

Copiar e colar virou arquitetura.

Falta de documentação

Conhecimento armazenado apenas na cabeça de alguém.

Dependência de especialistas

Quando você ouve:

"Somente o Carlos entende isso."

A dívida já existe.

COMO MAPEAR DÍVIDA TÉCNICA

Crie uma planilha simples.

Campos:

Sistema
Programa
Problema
Risco
Complexidade
Prioridade

Exemplo:

Programa	Problema
COBCLI01	Sem documentação
COBPAG02	15.000 linhas
COBFAT03	Sem testes

Agora a dívida ficou visível.

E aquilo que é visível pode ser gerenciado.

MÉTRICAS IMPORTANTES

Os melhores profissionais medem.

Sempre.

Algumas métricas úteis:

Número de ABENDs

Quanto mais ABENDs.

Maior a chance de problemas estruturais.

Tempo médio de correção

Quanto demora para corrigir um incidente?

Quantidade de bugs

Excelente indicador.

Número de programas sem documentação

Métrica simples.

Mas extremamente poderosa.

FERRAMENTAS QUE AJUDAM

Muitos acreditam que Mainframe não possui ferramentas modernas.

Grande erro.

IBM ADDI

Mapeia dependências.

Mostra relações entre:

COBOL;
JCL;
DB2;
CICS.

IBM Application Discovery

Excelente para sistemas legados.

IBM Fault Analyzer

Investiga ABENDs.

IBM Debug Tool

Ajuda a entender programas complexos.

SonarQube

Em ambientes integrados.

Ajuda na análise de qualidade.

Git

Sim.

Mainframe moderno usa Git.

E muito.

COMO CONTROLAR O BACKLOG

Regra simples.

Prioridade.

Nem tudo tem o mesmo peso.

Uma técnica muito usada:

Alta prioridade

Produção parada.

Média prioridade

Risco futuro.

Baixa prioridade

Melhorias desejáveis.

O SEGREDO DOS TIMES MADUROS

Times iniciantes fazem:

100% Funcionalidades

Times maduros fazem:

70% Funcionalidades
20% Correções
10% Dívida Técnica

Alguns chegam a reservar uma sprint inteira para limpeza.

E os resultados aparecem rapidamente.

EASTER EGG MAINFRAME

Se você encontrar comentários como:

* NÃO ALTERAR
* FUNCIONA DESDE 1998

Você encontrou um fóssil corporativo.

Parabéns.

Agora investigue antes de tocar.

Porque muitas vezes esse comentário está escondendo uma dívida técnica de milhões de dólares.

A REGRA DOS 15 MINUTOS

Uma dica que poucos ensinam.

Se você gastou mais de 15 minutos para entender um trecho de código:

documente.

Seu "eu do futuro" agradecerá.

COMO EVOLUIR MAIS RÁPIDO NA CARREIRA

O júnior normalmente aprende:

COBOL;
JCL;
DB2;
CICS.

Mas os profissionais mais valorizados aprendem também:

gestão de backlog;
análise de impacto;
controle de dívida técnica;
arquitetura;
observabilidade.

É isso que os transforma em analistas seniores.

O QUE NINGUÉM CONTA SOBRE BACKLOG

O backlog é uma fotografia do estado de saúde do sistema.

Se ele possui:

centenas de bugs;
dezenas de refatorações pendentes;
documentação atrasada;

o sistema está acumulando dívida.

O backlog está contando uma história.

Aprenda a lê-la.

CONCLUSÃO

Backlog não é apenas uma lista de tarefas.

É o painel de controle do futuro do sistema.

E a dívida técnica é uma das passageiras mais perigosas dessa viagem.

Um programador COBOL Mainframe que aprende a:

identificar problemas;
registrar atividades;
priorizar demandas;
controlar dívida técnica;
documentar descobertas;

deixa de ser apenas alguém que escreve código.

Passa a ser alguém capaz de manter sistemas vivos por décadas.

E no mundo Mainframe, onde muitos programas são mais antigos que seus desenvolvedores, essa habilidade vale ouro.

Porque no final das contas, o verdadeiro segredo não é escrever um programa novo.

É conseguir entender por que aquele programa de 1989 ainda está funcionando perfeitamente em produção.

E sobreviver ao chamado das 03:17 da manhã quando alguém decidir alterá-lo.

sexta-feira, 29 de novembro de 2024

☕💣 O COBOL NÃO É BAGUNÇA: AS BOAS PRÁTICAS DE CODIFICAÇÃO QUE SEPARAM PROGRAMADORES DE MAINFRAME DE VERDADE DOS MEROS ESCREVEDORES DE CÓDIGO

Bellacosa Mainframe e o clean code no Cobol

☕💣 O COBOL NÃO É BAGUNÇA: AS BOAS PRÁTICAS DE CODIFICAÇÃO QUE SEPARAM PROGRAMADORES DE MAINFRAME DE VERDADE DOS MEROS ESCREVEDORES DE CÓDIGO

Durante décadas, o COBOL carregou uma fama injusta. Muitos profissionais associam a linguagem a programas gigantescos, difíceis de entender, cheios de GO TO, variáveis com nomes estranhos e regras de negócio espalhadas por milhares de linhas.

Mas existe uma verdade que poucos percebem:

O problema nunca foi o COBOL.

O problema sempre foi a forma como algumas pessoas escreveram COBOL.

Quando observamos sistemas modernos desenvolvidos em Enterprise COBOL para z/OS, encontramos recursos avançados, suporte a programação estruturada, funções intrínsecas, XML, JSON, tratamento de exceções e diversas funcionalidades que permitem criar aplicações extremamente organizadas e fáceis de manter.

Neste artigo vamos explorar as principais boas práticas de codificação para COBOL Mainframe, conceitos de Clean Code e técnicas utilizadas pelas equipes mais maduras do mercado.

Por que qualidade de código importa no Mainframe?

Em muitas empresas, um programa COBOL permanece em produção por décadas.

Enquanto uma aplicação web pode ser substituída em poucos anos, não é raro encontrar programas COBOL escritos nos anos 80 ou 90 ainda executando processos críticos.

Isso significa que:

O código será lido mais vezes do que escrito.
Diversos profissionais irão mantê-lo.
A regra de negócio precisa ser compreendida rapidamente.
Erros podem gerar impactos milionários.

Portanto, escrever código pensando apenas em "funcionar" é um erro.

O objetivo deve ser:

Funcionar hoje e continuar compreensível daqui a 20 anos.

O princípio mais importante: código deve parecer documentação

Um bom programa COBOL deve ser quase autoexplicativo.

Compare:

Exemplo ruim

IF A = 'S'
   MOVE '1' TO B
END-IF

Agora:

IF CLIENTE-ATIVO
   MOVE STATUS-APROVADO
      TO STATUS-CADASTRO
END-IF

No segundo caso, praticamente não é necessário comentário.

O código descreve o negócio.

Essa é uma das bases do Clean Code.

Utilize nomes significativos

Muitos sistemas antigos utilizam variáveis como:

01 WS-A.
01 WS-B.
01 WS-X.

Isso gera enorme dificuldade de manutenção.

Prefira:

01 WS-SALDO-CONTA.
01 WS-LIMITE-CREDITO.
01 WS-VALOR-SAQUE.

Uma boa regra:

Se o nome não explica o conteúdo, o nome está errado.

Padronize convenções de nomenclatura

Equipes maduras possuem padrões claros.

Exemplo:

WS- = Working Storage
LK- = Linkage
IN- = Entrada
OUT- = Saída
CNT- = Contador
FLG- = Flag

Exemplo:

01 WS-NOME-CLIENTE.
01 WS-IDADE-CLIENTE.
01 FLG-CLIENTE-ATIVO.

A simples leitura permite identificar a finalidade da variável.

Evite GO TO sempre que possível

Durante décadas o GO TO foi utilizado excessivamente.

Exemplo:

IF ERRO
   GO TO 9000-ERRO.

Embora ainda exista em muitos sistemas, o uso excessivo gera:

Fluxo confuso
Difícil rastreamento
Baixa manutenibilidade

Prefira:

IF ERRO
   PERFORM 9000-TRATAR-ERRO
END-IF

O PERFORM torna o fluxo muito mais previsível.

Use terminadores de escopo

Um dos maiores avanços do COBOL moderno foi a introdução dos terminadores explícitos.

Evite:

IF CLIENTE-ATIVO
   IF LIMITE-OK
      MOVE 'S' TO STATUS
ELSE
   MOVE 'N' TO STATUS

Prefira:

IF CLIENTE-ATIVO
   IF LIMITE-OK
      MOVE 'S' TO STATUS
   ELSE
      MOVE 'N' TO STATUS
   END-IF
END-IF

Terminações explícitas eliminam ambiguidades.

Mantenha parágrafos pequenos

Quando um parágrafo possui centenas de linhas, sua manutenção torna-se extremamente difícil.

Ruim:

1000-PROCESSAR.

com 500 linhas.

Melhor:

1000-PROCESSAR.

    PERFORM 1100-VALIDAR-DADOS
    PERFORM 1200-CALCULAR-TAXAS
    PERFORM 1300-ATUALIZAR-SALDOS
    PERFORM 1400-GERAR-RELATORIO.

Cada bloco possui responsabilidade específica.

Uma responsabilidade por parágrafo

Um erro comum é misturar atividades.

Exemplo:

2000-PROCESSAR.

faz:

leitura
validação
cálculo
gravação
relatório

Tudo junto.

Prefira dividir responsabilidades.

Isso segue o princípio conhecido como:

Single Responsibility Principle (SRP).

Evite código duplicado

Nada gera mais problemas do que duplicação.

Exemplo:

COMPUTE WS-VALOR =
        WS-VALOR * 1.15

copiado em 20 programas diferentes.

Quando a regra mudar, será necessário alterar os 20.

Melhor:

Criar uma rotina centralizada.

CALL 'CALCIMPO'

PERFORM 5000-CALCULAR-IMPOSTO

Centralização reduz erros.

Comentários devem explicar o motivo, não o óbvio

Comentário ruim:

MOVE WS-NOME
 TO WS-NOME-SAIDA

Comentário:

* Move o nome para saída

Isso não agrega valor.

Comentário bom:

* Regra exigida pelo Banco Central
* Circular 3456/2024

Explica o motivo da regra.

Organize o programa em camadas lógicas

Uma estrutura clássica é:

IDENTIFICATION DIVISION

ENVIRONMENT DIVISION

DATA DIVISION

PROCEDURE DIVISION

0000-MAIN

1000-INICIALIZAR

2000-LER-ARQUIVO

3000-PROCESSAR

4000-GRAVAR

9000-FINALIZAR

Essa organização ajuda qualquer programador a navegar rapidamente pelo código.

Utilize COPYBOOKS adequadamente

Copybooks são excelentes para reutilização.

Exemplo:

COPY CLIENTE.

Benefícios:

Padronização
Reutilização
Menor manutenção

Mas cuidado:

Não transforme copybooks em monstros de milhares de linhas.

Trate erros explicitamente

Um programa profissional nunca assume sucesso.

Errado:

READ ARQ-CLIENTE

Melhor:

READ ARQ-CLIENTE
   AT END
      SET FIM-ARQUIVO TO TRUE
END-READ

Ou:

EXEC SQL
    SELECT ...
END-EXEC

IF SQLCODE NOT = ZERO
    PERFORM 9000-TRATAR-ERRO
END-IF

Nunca ignore SQLCODE

Em ambientes DB2 esta regra é sagrada.

Após cada comando SQL:

IF SQLCODE = 0

EVALUATE TRUE
   WHEN SQLCODE = 0
   WHEN SQLCODE = 100
   WHEN OTHER
END-EVALUATE

Ignorar SQLCODE é abrir espaço para falhas silenciosas.

Prefira EVALUATE ao invés de IFs excessivos

Ruim:

IF TIPO = 'A'
...
ELSE
   IF TIPO = 'B'
...

Melhor:

EVALUATE TIPO
   WHEN 'A'
      ...
   WHEN 'B'
      ...
   WHEN 'C'
      ...
   WHEN OTHER
      ...
END-EVALUATE

Mais legível e mais fácil de expandir.

Utilize variáveis booleanas (88 Level)

Um recurso poderoso e subutilizado.

01 WS-STATUS.
   05 WS-COD-STATUS PIC X.

88 CLIENTE-ATIVO VALUE 'A'.
88 CLIENTE-INATIVO VALUE 'I'.

Uso:

IF CLIENTE-ATIVO

Muito melhor que:

IF WS-COD-STATUS = 'A'

Reduza dependências externas

Quanto mais dependências:

Mais acoplamento
Mais manutenção
Mais risco

Sempre avalie:

"Essa chamada realmente é necessária?"

Mantenha consistência visual

Exemplo:

MOVE WS-NOME
   TO WS-NOME-SAIDA

ADD WS-VALOR
   TO WS-TOTAL

PERFORM 3000-PROCESSAR

Código alinhado facilita leitura.

A produtividade da manutenção aumenta significativamente.

Evite números mágicos

Ruim:

IF WS-IDADE > 18

Melhor:

78 IDADE-MINIMA VALUE 18.

IF WS-IDADE > IDADE-MINIMA

A regra fica documentada.

Faça validações no início

Evite processar dados inválidos.

Exemplo:

IF WS-CPF = SPACES
   PERFORM 9000-ERRO
   GO TO 9999-SAIDA
END-IF

Falhar cedo reduz complexidade.

Desenvolva pensando em testes

Uma boa prática moderna é escrever código facilmente testável.

Rotinas menores:

1100-VALIDAR
1200-CALCULAR
1300-GERAR

permitem testes independentes.

Registre logs úteis

Logs não devem apenas indicar erro.

Exemplo:

Cliente 12345 rejeitado.
Motivo: Limite insuficiente.

Informação útil reduz tempo de diagnóstico.

Utilize recursos modernos do COBOL

Muitos programadores ainda escrevem COBOL como nos anos 80.

Entretanto o Enterprise COBOL oferece:

Functions
Inline Perform
Scope Terminators
XML PARSE
JSON PARSE
JSON GENERATE
Intrinsic Functions
UTF-8
National Data

Utilizar recursos modernos aumenta produtividade e legibilidade.

Revise código antes de promover

Code Review é uma das melhores práticas existentes.

Benefícios:

Detecta defeitos
Padroniza estilo
Compartilha conhecimento
Melhora qualidade

Nenhum profissional experiente deveria temer revisão.

Métricas que valem a pena acompanhar

Alguns indicadores importantes:

Complexidade ciclomática
Linhas por módulo
Cobertura de testes
Duplicação de código
Defeitos em produção

O que é medido tende a melhorar.

O verdadeiro significado de Clean Code no Mainframe

Muitos acreditam que Clean Code é apenas uma moda criada para Java ou aplicações web.

Não é.

Clean Code significa:

Clareza
Simplicidade
Legibilidade
Manutenibilidade
Organização

Esses princípios são universais.

Eles funcionam tão bem em COBOL quanto em qualquer linguagem moderna.

Conclusão

O mercado frequentemente discute modernização de aplicações, APIs, cloud e inteligência artificial. Entretanto, poucas empresas percebem que a maior modernização possível muitas vezes começa dentro do próprio código COBOL.

Um programa limpo reduz custos, diminui defeitos, acelera manutenções e facilita a transferência de conhecimento entre gerações de profissionais.

O COBOL moderno oferece todos os recursos necessários para produzir software elegante, estruturado e sustentável.

A diferença entre um sistema que sobrevive décadas com qualidade e outro que se transforma em um pesadelo operacional não está na linguagem utilizada.

Está na disciplina de engenharia aplicada por quem escreve o código.

E essa disciplina continua sendo uma das habilidades mais valiosas de qualquer profissional de Mainframe.

Título alternativo para maior engajamento em blog/newsletter:

☕💣 SEU COBOL FUNCIONA... MAS ALGUÉM CONSEGUE ENTENDER? AS 25 REGRAS DE CLEAN CODE QUE TODO PROGRAMADOR MAINFRAME DEVERIA SEGUIR ANTES DA PRÓXIMA PROMOÇÃO PARA PRODUÇÃO

sexta-feira, 5 de janeiro de 2024

☕💣 TESTOU 100% DOS CASOS... E MESMO ASSIM QUEBROU EM PRODUÇÃO? O MAIOR MITO DOS TESTES EM MAINFRAME QUE AINDA ENGANA MUITA GENTE

Bellacosa Mainframe e a cobertura de testes em mainframe

☕💣 TESTOU 100% DOS CASOS... E MESMO ASSIM QUEBROU EM PRODUÇÃO? O MAIOR MITO DOS TESTES EM MAINFRAME QUE AINDA ENGANA MUITA GENTE

Se existe uma frase que todo profissional de Mainframe já ouviu alguma vez, ela é:

"O programa foi totalmente testado."

Curiosamente, essa mesma frase costuma aparecer poucas horas antes de um incidente em produção.

E aqui está uma verdade que muitos profissionais descobrem apenas depois de alguns anos de guerra:

Não existe programa totalmente testado.

O que existe é um programa com um nível de cobertura suficientemente alto para reduzir o risco a um patamar aceitável.

A pergunta correta nunca deveria ser:

"O programa foi testado?"

Mas sim:

"Qual foi a cobertura real do teste?"

E mais importante ainda:

"O que ficou sem ser testado?"

Hoje vamos conversar sobre um dos assuntos mais importantes para analistas, desenvolvedores COBOL, testadores, líderes técnicos e gestores de aplicações Mainframe:

Como medir cobertura de testes, construir um plano realmente abrangente e aumentar drasticamente a qualidade das entregas.

Pegue seu café.

Porque cobertura de teste não é quantidade de cenários.

É ciência.

O grande erro: confundir quantidade com cobertura

Muitos profissionais acreditam que executar muitos casos de teste significa possuir alta cobertura.

Não significa.

Imagine um programa COBOL com:

20 IFs
5 EVALUATEs
3 loops
15 regras de negócio

Você executa 500 casos.

Mas todos seguem o mesmo caminho lógico.

Resultado:

500 execuções
cobertura baixíssima

Você apenas percorreu a mesma estrada centenas de vezes.

É como testar um elevador indo somente para o segundo andar.

Você pode apertar o botão mil vezes.

Ainda não sabe o que acontece no décimo quinto andar.

O que é cobertura de teste?

Cobertura é uma métrica que mede quanto do comportamento do software foi exercitado durante os testes.

Ela responde perguntas como:

Quantas instruções foram executadas?
Quantos IFs foram percorridos?
Quantas decisões foram avaliadas?
Quantos caminhos lógicos foram explorados?
Quantas regras de negócio foram validadas?

Quanto maior a cobertura, maior a confiança.

Mas atenção:

100% de cobertura não significa ausência de defeitos.

Significa apenas que tudo foi visitado.

Não necessariamente validado corretamente.

As camadas de cobertura

Um plano robusto costuma analisar múltiplas camadas.

1. Cobertura de instruções (Statement Coverage)

A mais básica.

Pergunta:

Cada linha executável foi executada ao menos uma vez?

Exemplo:

IF SALDO > 0
   MOVE 'A' TO STATUS
ELSE
   MOVE 'B' TO STATUS
END-IF

Se apenas SALDO > 0 foi testado:

MOVE 'A'

executou.

Mas:

MOVE 'B'

não.

Cobertura parcial.

Para atingir 100%, ambos os caminhos precisam ser executados.

2. Cobertura de decisões (Branch Coverage)

Mais importante.

Pergunta:

Cada decisão assumiu todos os resultados possíveis?

Exemplo:

IF CLIENTE-ATIVO

Devemos testar:

TRUE
FALSE

Muitos projetos param na cobertura de instruções.

Os melhores projetos vão além e medem cobertura de decisões.

3. Cobertura de condições

Exemplo:

IF IDADE > 18
AND RENDA > 5000

Precisamos validar:

IDADE	RENDA
T	T
T	F
F	T
F	F

Caso contrário, parte da lógica pode nunca ter sido exercitada.

4. Cobertura de caminhos (Path Coverage)

Aqui a brincadeira fica séria.

Imagine:

IF A
   IF B
      ...
   END-IF
END-IF

Agora existem vários caminhos:

A=T B=T
A=T B=F
A=F

Quanto mais IFs surgem, mais caminhos aparecem.

O crescimento é explosivo.

Por isso ninguém tenta cobrir absolutamente todos os caminhos em sistemas grandes.

O objetivo é cobrir os caminhos críticos.

O conceito mais importante do Mainframe

Cobertura de negócio

Esta é a cobertura que realmente paga as contas.

Perguntas:

Emissão de apólice funcionou?
Pagamento foi processado?
Cálculo de juros foi validado?
Baixa financeira foi testada?
Cancelamento foi exercitado?

O usuário não se importa se:

PERFORM 1000-PROCESSA

executou.

Ele se importa se o dinheiro caiu na conta correta.

Por isso:

Cobertura técnica sem cobertura funcional é uma ilusão perigosa.

Como construir um plano de teste abrangente

A técnica que uso para ensinar equipes é simples.

Divida os cenários em grupos.

Grupo 1 – Casos normais

Fluxo feliz.

O famoso Happy Path.

Exemplo:

Cliente válido.

Conta válida.

Saldo suficiente.

Arquivo disponível.

Tudo funcionando.

Esses testes validam o comportamento esperado.

Grupo 2 – Casos de fronteira

Aqui vivem os defeitos.

Exemplo:

Campo aceita:

0 a 999999

Testar:

Mas também:

-1
1000000

A maioria dos bugs aparece nos limites.

Grupo 3 – Casos inválidos

Todo sistema recebe lixo.

Você precisa descobrir como ele reage.

Exemplos:

CPF inválido.

Data inválida.

Arquivo vazio.

Campo nulo.

Código inexistente.

Registro duplicado.

Produção faz isso diariamente.

Seu teste também deve fazer.

Grupo 4 – Casos excepcionais

Os mais esquecidos.

Exemplo:

VSAM indisponível.

DB2 retornando erro.

Dataset cheio.

Timeout de CICS.

Lock de registro.

Fila MQ parada.

É justamente aqui que nascem os incidentes mais caros.

O método Bellacosa para testar COBOL

Quando olho um programa, sigo sempre esta sequência.

Entrada

O que entra?

Analise:

LINKAGE
COMMAREA
ARQUIVOS
DB2
MQ
VSAM

Liste tudo.

Processamento

O que acontece?

Mapeie:

IF
EVALUATE
PERFORM
GO TO
loops

Tudo que altera comportamento.

Saída

O que sai?

Arquivos.

Relatórios.

Tabelas.

Mensagens.

Retornos.

Abends.

Tudo deve ser validado.

A matriz de cobertura

Uma técnica extremamente poderosa.

Monte uma tabela.

Regra	Testada
Regra 1	Sim
Regra 2	Sim
Regra 3	Não
Regra 4	Sim

Agora faça o mesmo para:

programas
módulos
telas
transações
jobs

A matriz revela instantaneamente os buracos.

Cobertura para Batch

Em batch devemos validar:

Arquivo vazio

0 registros

Arquivo pequeno

10 registros

Arquivo médio

100.000 registros

Arquivo grande

10 milhões de registros

Registro inválido

Registro duplicado

Chave fora de sequência

Dataset inexistente

Espaço insuficiente

Return codes

Tudo isso precisa aparecer no plano.

Cobertura para CICS

Valide:

Entrada válida
Entrada inválida
PF Keys
Timeout
Commarea vazia
Commarea truncada
Falha de comunicação
Reentrada da transação

Muitos defeitos aparecem apenas em ambiente online.

Cobertura para DB2

Nunca teste apenas o SQLCODE 0.

Teste:

Grande parte dos problemas de produção surge justamente nos códigos de erro.

Cobertura para VSAM

Valide:

READ OK
NOT FOUND
DUPLICATE KEY
END OF FILE
OPEN ERROR

Muitos testes ignoram completamente os File Status.

Erro clássico.

Testes de performance também fazem parte da cobertura

Um programa pode estar funcionalmente correto.

Mas:

consumir CPU demais
gerar EXCP excessivo
aumentar elapsed time

E então falhar operacionalmente.

Portanto inclua:

volume realista
pico de carga
concorrência
consumo de recursos

Como medir cobertura no Mainframe

Hoje existem ferramentas especializadas.

Entre elas:

IBM Debug Tool
IBM Application Delivery Foundation
IBM Fault Analyzer
IBM Application Performance Analyzer
Compuware Topaz
Compuware Xpediter
Micro Focus Enterprise Analyzer
SonarQube para COBOL

Essas soluções conseguem mostrar:

linhas executadas
branches percorridos
percentuais de cobertura
áreas não testadas

Transformando percepção em números.

E números vencem opiniões.

A armadilha do 100%

Imagine:

IF VALOR > 1000

Você executa:

Cobertura:

100%.

Mas você não testou:

Exatamente o limite.

Portanto:

100% de cobertura não significa qualidade máxima.

Significa apenas que todos os pontos foram visitados.

O indicador que realmente importa

Depois de décadas observando projetos, cheguei a uma conclusão.

A melhor pergunta não é:

"Qual a cobertura?"

Mas:

"Qual o risco residual?"

Se uma rotina financeira movimenta bilhões:

95% pode ser insuficiente.

Se uma rotina gera relatório interno:

80% pode ser aceitável.

Cobertura deve ser analisada junto com criticidade.

A filosofia dos grandes times

Equipes maduras fazem quatro perguntas:

O que testamos?

O que não testamos?

Por que não testamos?

Qual o risco disso?

Quando essas respostas existem, o plano de teste deixa de ser um documento burocrático.

Ele vira uma ferramenta de gestão de risco.

Conclusão

O profissional júnior acredita que testar é executar casos.

O profissional experiente entende que testar é procurar defeitos.

E o veterano de Mainframe sabe algo ainda mais importante:

Cobertura não é uma porcentagem. É a medida da sua confiança antes de colocar um programa em produção.

Porque no mundo real ninguém é acordado às 3 da manhã por causa dos cenários que foram testados.

Somos acordados pelos cenários que esquecemos de testar.

E quase sempre eles estavam escondidos exatamente naquele IF, naquele SQLCODE, naquele File Status ou naquele registro de fronteira que alguém julgou improvável.

No Mainframe, assim como na aviação, o problema raramente está no voo que você simulou.

O problema está naquele que você acreditou que jamais aconteceria. ☕💣🚀

sexta-feira, 24 de setembro de 2021

ABEND sem Mistérios — Parte VII

Bellacosa Mainframe em abend sem misterio parte vii

☕ Um Café no Bellacosa Mainframe

ABEND sem Mistérios — Parte VII

Os 100 Erros Mais Comuns dos Programadores COBOL que Acabam Gerando ABENDs (e Como os Grandes Bancos Evitam Cada Um Deles)

"Quase nenhum ABEND nasce de um único erro. Ele costuma ser o resultado de pequenas decisões aparentemente inocentes que foram se acumulando até encontrar o momento perfeito para falhar."

Introdução

Depois de entender:

o que é um ABEND;
como investigá-lo;
como analisar dumps;
como funciona a arquitetura do IBM Z;
como utilizar observabilidade;
como criar laboratórios de treinamento;

chegamos a uma pergunta extremamente importante.

Por que tantos ABENDs continuam acontecendo?

A resposta surpreende muita gente.

Na maioria das vezes, não é por causa do compilador.

Nem do JCL.

Nem do z/OS.

Nem do CICS.

Muito menos do hardware IBM Z.

Na prática, a maior parte dos incidentes nasce de pequenos erros de desenvolvimento que poderiam ter sido evitados.

É exatamente por isso que grandes bancos investem tanto em padrões de programação, revisões técnicas, testes automatizados e engenharia preventiva.

Neste artigo reunimos os erros mais frequentes encontrados em projetos COBOL corporativos e as práticas utilizadas para evitá-los.

O verdadeiro custo de um pequeno erro

Imagine uma variável.

01 WS-SALDO PIC 9(09)V99.

Agora imagine que um arquivo carregue:

12A4500

Nenhum cliente percebe.

Nenhum operador percebe.

Nenhum batch falha imediatamente.

Horas depois...

COMPUTE

↓

S0C7

↓

Rollback

↓

Fila parada

↓

Chamado de Produção

O problema começou muito antes do ABEND.

Os cinco grupos de erros

Praticamente todos os incidentes podem ser classificados em cinco categorias.

Dados

↓

Lógica

↓

Integração

↓

Infraestrutura

↓

Processos

Vamos explorar cada uma delas.

Grupo 1 — Erros de Dados

São disparadamente os mais comuns.

Erro 1

Não validar campos numéricos.

Resultado.

S0C7.

Boa prática.

Sempre utilizar:

IF campo NUMERIC

Erro 2

Assumir que um arquivo sempre virá correto.

Arquivos mudam.

Layouts evoluem.

Campos chegam em branco.

Sistemas fornecedores falham.

Nunca confie cegamente na entrada.

Erro 3

Ignorar FILE STATUS.

Uma simples instrução OPEN pode falhar.

Sem tratamento adequado,

o programa continua executando até produzir consequências mais graves.

Erro 4

Ignorar SQLCODE.

O SELECT pode não encontrar registros.

O UPDATE pode falhar.

O COMMIT pode ser rejeitado.

Sempre teste SQLCODE.

Erro 5

Ignorar RESP e RESP2 no CICS.

Esses códigos são equivalentes ao SQLCODE do ambiente transacional.

Não tratá-los significa dirigir sem painel de instrumentos.

Grupo 2 — Erros de Lógica

Erro 6

PERFORM infinito.

Resultado.

S322

Boa prática.

Toda repetição deve possuir condição clara de encerramento.

Erro 7

Índices fora do OCCURS.

Principal causa de inúmeros S0C4.

Sempre valide limites.

Erro 8

Variáveis não inicializadas.

Nunca suponha que memória contém zeros.

Use INITIALIZE quando fizer sentido e inicialize explicitamente áreas críticas.

Erro 9

REDEFINES utilizado sem documentação.

REDEFINES é poderoso.

Mas também é uma das maiores fontes de confusão em sistemas antigos.

Erro 10

Uso excessivo de GO TO.

Quanto maior o número de desvios,

mais difícil torna-se reproduzir problemas.

Grupo 3 — Integração

Erro 11

Copybooks incompatíveis.

Programa A espera:

100 bytes

Programa B envia:

120 bytes

Resultado.

S0C4.

Erro 12

CALL USING incompatível.

Mudança em parâmetros sem recompilar todos os módulos.

Problema extremamente comum em aplicações legadas.

Erro 13

Layouts de arquivos desatualizados.

Uma alteração aparentemente simples pode afetar dezenas de programas.

Erro 14

Interfaces sem versionamento.

Grandes bancos tratam contratos de interface como código-fonte.

Grupo 4 — Infraestrutura

Erro 15

STEPLIB incorreta.

Resultado.

S806

Erro 16

DCB incompatível.

Resultado.

S013

Erro 17

Datasets pequenos.

Resultado.

SB37

SD37

SE37

Erro 18

TIME insuficiente.

Resultado.

S322

Erro 19

Catálogo inconsistente.

Nem sempre o problema está na aplicação.

Grupo 5 — Engenharia de Software

Aqui aparecem os erros mais caros.

Erro 20

Falta de logs.

Sem informações,

investigar torna-se muito mais difícil.

Erro 21

Ausência de documentação.

Quando apenas uma pessoa entende um programa,

o risco operacional aumenta significativamente.

Erro 22

Não reproduzir o incidente.

Corrigir "no escuro" costuma gerar novos problemas.

Erro 23

Não escrever testes.

A correção resolve o incidente atual,

mas ninguém garante que outro desenvolvedor não reintroduzirá o mesmo defeito.

Erro 24

Não documentar a causa raiz.

Todo incidente importante deveria gerar conhecimento.

Os erros que quase nunca aparecem nos livros

Alguns problemas são extremamente frequentes na vida real.

Por exemplo.

Alteração de layout sem avisar outras equipes.

↓

Mudança de copybook.

↓

Programa recompilado parcialmente.

↓

Ambiente inconsistente.

↓

Produção.

↓

ABEND.

Tecnicamente,

ninguém escreveu código errado.

O problema foi comunicação.

O perigo das suposições

Um excelente programador desconfia de tudo.

Pergunta:

O arquivo realmente existe?

O retorno foi validado?

A variável foi inicializada?

O parâmetro chegou corretamente?

A transação ainda está instalada?

Essa postura reduz enormemente os incidentes.

Como pensam os grandes bancos

Muitas empresas utilizam listas de verificação antes do deploy.

Exemplo.

SQLCODE tratado?
FILE STATUS tratado?
RESP tratado?
Índices validados?
Logs suficientes?
Testes executados?
Revisão realizada?
Plano de rollback pronto?

Esse checklist evita inúmeros problemas.

O princípio da programação defensiva

Programação defensiva significa assumir que algo pode dar errado.

Em vez de escrever:

ADD WS-VALOR TO TOTAL

O profissional escreve:

IF WS-VALOR NUMERIC
    ADD WS-VALOR TO TOTAL
ELSE
    PERFORM TRATAR-ERRO
END-IF

O objetivo não é tornar o código maior.

É torná-lo mais confiável.

A importância da revisão de código

Um desenvolvedor acostuma-se com seu próprio código.

Por isso revisões entre colegas são tão valiosas.

Muitas falhas simples são descobertas antes mesmo dos testes.

Revisar código não é fiscalizar pessoas.

É proteger o sistema.

Testes automatizados no Mainframe

Cada vez mais equipes utilizam:

IBM Developer for z/OS;
IBM Test Accelerator;
ZUnit;
Jenkins;
GitHub Actions;
UrbanCode Deploy;
Ansible.

A ideia é simples.

Sempre que uma alteração ocorrer,

os principais cenários são executados automaticamente.

Assim, regressões são identificadas antes da produção.

Os dez mandamentos do Programador COBOL

Nunca confie nos dados de entrada.
Sempre trate retornos do sistema.
Valide limites de tabelas.
Documente alterações importantes.
Escreva logs úteis.
Faça revisões de código.
Teste cenários de erro, não apenas os de sucesso.
Automatize sempre que possível.
Investigue antes de corrigir.
Compartilhe conhecimento com a equipe.

O ciclo dos incidentes

Os sistemas mais maduros seguem um ciclo contínuo.

Erro

↓

ABEND

↓

Investigação

↓

Root Cause

↓

Correção

↓

Teste

↓

Documentação

↓

Automação

↓

Novo Padrão

↓

Menos ABENDs

Cada incidente fortalece a organização.

O Programador Padawan e o Especialista

O Padawan pergunta:

"Como elimino este S0C7?"

O especialista pergunta:

"Como impedir que qualquer programa desta empresa gere esse mesmo S0C7 novamente?"

Essa diferença de perspectiva muda completamente a qualidade do software.

Construindo uma cultura de qualidade

As organizações mais bem-sucedidas não dependem de heróis que resolvem incidentes às três da manhã.

Elas constroem processos que tornam esses incidentes cada vez mais raros.

Isso inclui:

padrões de codificação;
revisão por pares;
integração contínua;
testes automatizados;
observabilidade;
documentação;
treinamento constante.

Quando essas práticas amadurecem, o número de ABENDs em produção tende a cair de forma consistente.

Conclusão

Os ABENDs não surgem do nada. Eles são o reflexo da qualidade das decisões tomadas ao longo do ciclo de desenvolvimento.

Cada variável validada, cada SQLCODE tratado, cada FILE STATUS verificado, cada revisão de código e cada teste automatizado representam pequenas barreiras que impedem que um erro simples evolua para um incidente crítico.

Os grandes bancos sabem disso há décadas. Por essa razão, investem muito mais em prevenção do que em correção. A investigação continua sendo importante, mas seu verdadeiro objetivo é produzir aprendizado, melhorar processos e reduzir a probabilidade de novos incidentes.

O Programador Padawan que compreender essa filosofia deixará de ver o ABEND como um inimigo. Passará a enxergá-lo como um indicador da saúde do sistema e uma oportunidade de tornar suas aplicações mais seguras, previsíveis e resilientes.

Porque, no fim das contas, a melhor investigação é aquela que um dia deixa de ser necessária.

quarta-feira, 21 de julho de 2021

Da Ideia ao Código: A Engenharia de Software Sem Mistérios - Parte I

Bellacosa Mainframe e a engenharia de software sem misterios parte I

☕ Um Café no Bellacosa Mainframe

Da Ideia ao Código: A Engenharia de Software Sem Mistérios

O Guia Definitivo do Programador COBOL Padawan para Entender Como Nascem os Sistemas que Movem o Mundo — Inspirado no Universo de Star Trek

"A lógica é o começo da sabedoria, não o fim."
— Sr. Spock

Introdução — A Ponte de Comando da USS Enterprise e o IBM Z

Existe uma cena recorrente em praticamente toda série de Star Trek.

O Capitão Kirk recebe uma missão.

Antes de simplesmente sair acelerando rumo ao desconhecido, uma sequência acontece quase sempre da mesma forma:

Uhura recebe as comunicações;
Sulu calcula a rota;
Chekov verifica a navegação;
Scotty analisa os motores;
Dr. McCoy avalia a tripulação;
Spock analisa os riscos.

Somente depois disso...

Warp Factor!

Curiosamente...

É exatamente assim que funciona um projeto de software.

O programador iniciante costuma imaginar que um sistema nasce quando alguém abre o Visual Studio Code, o IDz ou o ISPF e começa a escrever COBOL.

Na realidade...

O código representa apenas a ponta do iceberg.

Antes de existir uma única linha de código, dezenas de profissionais trabalharam durante semanas — ou meses — planejando tudo.

Foi justamente essa percepção que criou uma nova ciência chamada:

Engenharia de Software

E é exatamente essa jornada que faremos hoje.

Pegue sua caneca de café.

Ajuste o brilho do terminal 3270.

Ative os sensores de longo alcance.

Nossa missão começa agora.

Diário de Bordo — Stardate 2026

Imagine que a Federação precisa desenvolver um novo sistema para controlar toda a logística das naves da Frota Estelar.

Esse sistema deverá controlar:

combustível (Dilithium)
tripulação
armamentos
manutenção
suprimentos
teletransporte
missões

Parece simples.

Mas...

Como garantir que um erro nunca destrua uma nave inteira?

É exatamente para isso que existe a Engenharia de Software.

Capítulo 1 — A Grande Crise do Software

Nos anos 50 e início dos anos 60, programar era relativamente simples.

Os programas eram pequenos.

Poucas pessoas trabalhavam neles.

Mas os computadores ficaram cada vez maiores.

Surgiram:

bancos
companhias aéreas
governos
seguradoras
sistemas militares

De repente surgiram programas com:

milhões de linhas
milhares de tabelas
centenas de desenvolvedores

Resultado?

Uma verdadeira catástrofe.

Projetos atrasavam anos.

Custavam dezenas de vezes mais.

Nunca terminavam.

Essa situação ficou conhecida como:

Software Crisis

Foi ela que deu origem à Engenharia de Software.

O verdadeiro significado de Software

As apostilas mostram:

Software = Programas + Dados + Documentação

Na prática moderna...

Software significa muito mais.

Um sistema corporativo normalmente inclui:

código COBOL
programas Java
APIs REST
filas MQ
banco Db2
VSAM
IMS
documentação
monitoramento
pipelines CI/CD
segurança
backups
auditoria
logs
scripts
automação

Ou seja...

O código é apenas uma pequena parte.

Easter Egg nº 1 ☕

No universo Star Trek, o computador da Enterprise nunca mostra apenas "o programa".

Ele conhece:

estado da nave
sensores
mapas
comunicações
banco de dados
diagnósticos

Isso é exatamente o conceito moderno de software.

Engenharia de Requisitos

Antes de escrever código existe uma pergunta extremamente difícil.

"O que exatamente devemos construir?"

Curiosamente...

Essa costuma ser a pergunta mais complicada de todo projeto.

Imagine um banco dizendo:

"Queremos um sistema PIX."

Pronto?

Claro que não.

Agora começam centenas de perguntas.

Quem pode transferir?

Existe limite?

Qual horário?

Pessoa física?

Pessoa jurídica?

Existe auditoria?

Existe rollback?

Existe LGPD?

Existe dupla autenticação?

Existe assinatura digital?

Existe timeout?

Existe integração com BACEN?

Perceba.

Nenhuma dessas perguntas envolve COBOL.

O Analista é um Investigador Vulcano

Spock nunca tira conclusões precipitadas.

Ele primeiro coleta evidências.

Depois formula hipóteses.

Depois valida.

Um bom analista faz exatamente isso.

Ele investiga.

Questiona.

Confirma.

Documenta.

Engenharia de Requisitos é Engenharia de Perguntas

Quanto melhor forem as perguntas...

Melhor será o software.

Existe um velho ditado da IBM:

Um requisito mal entendido custa centenas de horas de retrabalho.

Requisitos Funcionais

São aqueles que respondem:

"O sistema faz o quê?"

Exemplos:

Consultar saldo

Transferir PIX

Emitir boleto

Gerar extrato

Cadastrar cliente

Calcular juros

Tudo isso é comportamento.

Requisitos Não Funcionais

Agora entra uma categoria que muitos iniciantes ignoram.

Ela responde:

"Como o sistema deve funcionar?"

Por exemplo.

Consultar saldo.

↓

Em menos de 300 milissegundos.

Transferir dinheiro.

↓

Disponibilidade de 99,999%.

Cadastrar cliente.

↓

Suportar 50 mil usuários simultâneos.

Esses requisitos normalmente definem se o projeto será aprovado ou não.

O Segredo do Mainframe

Por que um IBM Z consegue processar bilhões de transações?

Porque praticamente todos os seus requisitos importantes são...

Não funcionais.

Disponibilidade.

Escalabilidade.

Confiabilidade.

Segurança.

Performance.

Curiosidade ☕

A famosa meta de 99,999% de disponibilidade ("cinco noves") significa apenas alguns minutos de indisponibilidade por ano. Esse nível é perseguido por plataformas de missão crítica como o IBM Z porque uma interrupção pode afetar milhões de clientes e transações.

Como levantar requisitos

Existem diversas técnicas.

As mais usadas são:

Entrevistas

Observação

Questionários

Brainstorming

Protótipos

Workshops

O poder da observação

Imagine automatizar um caixa bancário.

Você pergunta:

"Como você trabalha?"

Ele responde.

Mas...

Quando você o observa...

Descobre atalhos.

Planilhas escondidas.

Papéis.

Post-its.

Macetes.

Fluxos nunca documentados.

Isso acontece diariamente nas empresas.

O Documento Mais Importante do Projeto

Depois de semanas de entrevistas nasce um documento.

O famoso:

SRS

Software Requirement Specification

Ele é praticamente a Constituição do projeto.

Tudo nasce dele.

Tudo termina nele.

O que existe em um SRS?

Escopo.

Objetivos.

Glossário.

Casos de uso.

Regras de negócio.

Integrações.

Restrições.

Mensagens.

Fluxos.

Requisitos funcionais.

Requisitos não funcionais.

Critérios de aceitação.

No mundo IBM Z, muitas organizações utilizam documentos equivalentes, às vezes com outros nomes, mas a função é a mesma: registrar claramente o que será construído.

A Validação

Agora acontece algo extremamente importante.

Antes de programar...

Pergunta-se:

"Está correto?"

É muito mais barato descobrir um erro aqui do que meses depois.

A Regra dos Custos

Existe um princípio amplamente aceito na Engenharia de Software:

Quanto mais tarde um defeito é encontrado, maior tende a ser o custo para corrigi-lo.

Encontrar uma falha durante a análise geralmente é muito mais barato do que descobri-la após a implantação em produção.

Arquitetura

Agora começa outra etapa.

Imagine construir a USS Enterprise.

Você começaria instalando os motores?

Claro que não.

Primeiro existe um projeto.

Com software acontece igual.

Arquitetura responde perguntas gigantes

Será:

Monolito?

Microserviços?

Mainframe?

Cloud?

MQ?

REST?

Kafka?

Db2?

VSAM?

IMS?

CICS?

Nada disso envolve código ainda.

Um exemplo IBM Z

Imagine uma compra pela Internet.

O fluxo pode ser:

Cliente

↓

API

↓

z/OS Connect

↓

CICS

↓

Programa COBOL

↓

Db2

↓

Sistema de Estoque

Isso é arquitetura.

Arquitetura em Camadas

As apostilas mostram:

Presentation

Business

Data

Database

Curiosamente...

Muitos sistemas COBOL já utilizavam esse conceito décadas antes da popularização dos frameworks modernos.

Tela BMS.

↓

Programa COBOL.

↓

Db2.

É uma separação de responsabilidades.

Microserviços

Hoje muito se fala em Microservices.

A ideia é dividir um sistema enorme em pequenos serviços independentes.

Exemplo:

PIX

Cartões

Empréstimos

Investimentos

Clientes

Cada um evolui de forma independente.

Mas isso não significa que seja sempre a melhor escolha. Em muitos cenários, um monólito bem projetado é mais simples de desenvolver e manter.

HLD — High Level Design

Agora a arquitetura vira documento.

O HLD mostra:

Grandes módulos.

Integrações.

Banco.

Protocolos.

Fluxo de dados.

Não entra nos detalhes.

É o mapa da cidade.

LLD — Low Level Design

Agora sim.

Entramos no nível do desenvolvedor.

O LLD explica:

Algoritmos.

Tabelas.

Campos.

Índices.

Funções.

Pseudocódigo.

Fluxogramas.

Entradas.

Saídas.

Mensagens.

Agora o programador consegue escrever código.

Exemplo COBOL

Imagine um programa chamado:

COBPIX01

O LLD pode dizer:

Entrada:

Agência
Conta
Valor

Processamento:

validar conta
consultar saldo
verificar limite
debitar
registrar auditoria
gravar MQ
atualizar Db2
executar COMMIT

Saída:

código de retorno
novo saldo
mensagem ao usuário

Perceba.

O código praticamente nasce desse documento.

O Pseudocódigo

Uma das ferramentas mais antigas da Engenharia.

Ele permite pensar antes de programar.

Receber conta

↓

Conta existe?

↓

Não

Erro

↓

Sim

Saldo suficiente?

↓

Não

Saldo insuficiente

↓

Sim

Debitar

↓

Registrar log

↓

Atualizar Db2

↓

Commit

↓

Retornar sucesso

Quando esse fluxo está correto...

Programar fica muito mais simples.

SDLC na prática

Todo projeto percorre algo semelhante a:

Ideia

↓

Requisitos

↓

Validação

↓

Arquitetura

↓

HLD

↓

LLD

↓

Codificação

↓

Testes

↓

Implantação

↓

Manutenção

↓

Nova evolução

Perceba que a programação aparece apenas na metade da jornada.

Modelos de Desenvolvimento

A Engenharia criou diversos modelos para organizar esse fluxo.

Waterfall

Segue uma sequência rígida.

Requisitos.

↓

Projeto.

↓

Código.

↓

Testes.

↓

Produção.

Ainda é muito usado em projetos com requisitos estáveis, como diversos sistemas governamentais e aplicações de missão crítica.

Modelo V

Cada etapa de desenvolvimento possui uma etapa correspondente de teste.

Requisitos

⇔ Testes de Aceitação

Projeto

⇔ Testes de Sistema

Arquitetura

⇔ Testes de Integração

Módulos

⇔ Testes Unitários

É excelente para ambientes onde rastreabilidade e qualidade são fundamentais.

Modelo Incremental

Em vez de entregar tudo de uma vez, o sistema cresce por partes.

Primeiro:

Depois:

Cadastro.

Depois:

Relatórios.

Depois:

Integrações.

Cada incremento entrega valor ao usuário.

Modelo Espiral

Muito usado em projetos grandes e de alto risco.

Cada volta da espiral passa por:

Planejamento.

↓

Análise de riscos.

↓

Desenvolvimento.

↓

Avaliação do cliente.

↓

Nova volta.

É um modelo que combina evolução contínua com gestão de riscos.

Os Atributos da Qualidade

Um software não é considerado bom apenas porque "funciona".

Ele precisa ser:

✔ Correto

✔ Confiável

✔ Eficiente

✔ Seguro

✔ Escalável

✔ Portável

✔ Fácil de manter

✔ Disponível

✔ Fácil de usar

Esses atributos influenciam diretamente o sucesso de um sistema em produção.

A Engenharia Invisível

Quando um cliente faz um PIX em dois segundos...

Ele nunca imagina que por trás daquela simplicidade existiram:

Meses de análise.

Centenas de reuniões.

Documentos.

Diagramas.

Arquitetura.

Revisões.

Testes.

Validações.

Planejamento.

Essa é a parte invisível da Engenharia de Software.

Easter Egg nº 2 — A Diretriz Principal

Em Star Trek existe a famosa Prime Directive, um conjunto de regras criado para evitar consequências desastrosas.

Na Engenharia de Software existe um princípio parecido:

Nunca comece a codificar antes de compreender completamente o problema que precisa ser resolvido.

Escrever código sem requisitos claros costuma produzir sistemas que funcionam tecnicamente, mas não atendem ao negócio.

Lições do Sr. Spock para o Programador COBOL Padawan

Se Spock fosse um arquiteto de software no IBM Z, provavelmente deixaria estas recomendações:

A lógica deve vir antes do código.
Requisitos mal definidos geram defeitos bem implementados.
Um bom design reduz a complexidade futura.
Documentação não substitui conhecimento, mas preserva conhecimento.
Teste não cria qualidade; ele revela a qualidade do que foi construído.
O programa termina de ser escrito, mas o software continua evoluindo durante anos.

Conclusão — A Verdadeira Missão da Engenharia de Software

Muitos iniciantes acreditam que o objetivo de um desenvolvedor é escrever muitas linhas de código.

Com o tempo, descobrem que acontece justamente o contrário.

Os melhores engenheiros escrevem o código certo, no momento certo, apoiado por requisitos claros, uma arquitetura consistente e um projeto bem elaborado.

É exatamente por isso que sistemas COBOL executados em IBM Z continuam sustentando bancos, seguradoras, governos e bolsas de valores após décadas de evolução. Eles não sobreviveram apenas por causa da linguagem ou do hardware, mas porque foram construídos sobre fundamentos sólidos de Engenharia de Software: análise cuidadosa, documentação, arquitetura, testes e manutenção disciplinada.

Assim como a USS Enterprise não parte para uma missão sem planejamento, análise de riscos e coordenação entre toda a tripulação, um grande sistema corporativo também não nasce de improviso. Cada documento, cada diagrama, cada revisão e cada teste representa um membro da "tripulação" trabalhando para que, quando chegar o momento da implantação, tudo funcione de forma segura, previsível e confiável.

No fim da jornada, o verdadeiro Padawan COBOL percebe que programar é uma habilidade importante, mas compreender a Engenharia de Software é o que transforma um programador em um engenheiro capaz de construir sistemas que resistem ao tempo — exatamente como os grandes sistemas do IBM Z e as lendárias naves da Frota Estelar. Vida longa e próspera! 🖖

Translate

quinta-feira, 11 de junho de 2026

☕💣🚀 PADAWAN, TESTAR COBOL NÃO É DESCONFIAR DO PROGRAMA. É DESCONFIAR DE SI MESMO!

Bellacosa Mainframe e tecnicas e ferramentas de teste automatizado em ibm mainframe

☕💣🚀 PADAWAN, TESTAR COBOL NÃO É DESCONFIAR DO PROGRAMA. É DESCONFIAR DE SI MESMO!

A Arte Esquecida dos Testes no IBM Mainframe

Como Pensar em Testes COBOL

1. Teste Unitário

2. Teste de Integração

3. Teste de Sistema

4. Teste de Regressão

Ferramenta 1 — IBM ZUnit

Vantagens

Desvantagens

Exemplo Prático com ZUnit

Passo 1

Passo 2

Passo 3

Passo 4

Passo 5

Passo 6

Ferramenta 2 — IBM COBOL Check: Encontrando Defeitos Antes da Execução

O Que É?

Problemas Detectados

Variáveis Não Inicializadas

Índices Fora da Faixa

Código Morto

Condições Impossíveis

Possíveis S0C7

Vantagens do COBOL Check

Desvantagens

Ferramenta 3 — IBM Debug Tool

Vantagens

Desvantagens

Exemplo

Ferramenta 4 — File-AID

O que faz?

Exemplo

Vantagens

Desvantagens

Ferramenta 5 — Xpediter

Permite

Vantagens

Desvantagens

Ferramenta 6 — Abend-AID

Vantagens

Desvantagens

Técnica Clássica: Golden File

Técnica Moderna: Mocking

Técnica de Cobertura

Curiosidades Históricas

COBOL já tinha testes antes da moda

O custo do erro

Grandes bancos executam milhões de testes

Dicas do Bellacosa

☕ Dica 1

☕ Dica 2

☕ Dica 3

☕ Dica 4

☕ Dica 5

Exemplo de Pipeline DevOps Mainframe

Resumo Executivo

segunda-feira, 8 de junho de 2026

IBM COBOL Check: A Ferramenta Que Trouxe Testes Unitários Modernos Para o Mundo do Mainframe

☕💣🚀 OPERADOR, O COBOL GANHOU UM JUNIT!

IBM COBOL Check: A Ferramenta Que Trouxe Testes Unitários Modernos Para o Mundo do Mainframe

O Que é o IBM COBOL Check?

Quem Criou o COBOL Check?

Quando Foi Lançado?

O Problema Que Ele Resolve

A Grande Ideia

Código

Teste

Execução

Como Funciona Internamente?

Sistemas Suportados

IBM z/OS

Dependências

Compilador COBOL

Ambiente z/OS