Bellacosa Mainframe e os primeiros passos para um programador cobol

☕ Um Café no Bellacosa Mainframe

De Volta para o Mainframe — Quando o Dr. Brown Abriu o ISPF, Encontrou um Programa COBOL de 15 Anos e Descobriu que o Futuro Usava Jira

Ou: o jovem padawan achava que desenvolver COBOL era passar o dia digitando `MOVE`, mas bastaram 1,21 gigawatts, um job noturno e uma especificação ambígua para quase alterar o saldo de dois milhões de clientes

Prólogo — Estradas? Para onde vamos não precisamos de estradas, mas precisamos do JCL

Itatiba, 8h07 da manhã.

Igor, nosso jovem padawan COBOL, chegou para seu primeiro dia numa instituição financeira. Na mochila havia um caderno novo, três canetas, um curso de COBOL concluído com 98% de aproveitamento e a certeza de que passaria o dia escrevendo programas numa tela preta com letras verdes.

Ele imaginava uma sala escura.

Imaginava veteranos silenciosos digitando comandos secretos diante de terminais antigos.

Imaginava pilhas de manuais IBM, fitas magnéticas girando e um operador gritando:

— O banco de dados está entrando em colapso!

Quando abriu a porta, encontrou algo muito mais desconcertante: pessoas usando Teams, Jira, Confluence, planilhas, dashboards, Git, e-mail e uma cafeteira que aparentemente possuía prioridade maior que produção.

No centro da sala estava um homem de cabelos brancos, jaleco e olhos arregalados, tentando conectar um cabo amarelo à lateral de um terminal 3270.

— Grande Scott! — gritou o Dr. Emmett Brown. — Este computador não possui porta USB!

— Doutor, isso é um emulador TN3270 — explicou Bellacosa. — E tire esse cabo daí antes que o RACF registre uma tentativa de acesso intertemporal.

Marty McFly observou a tela.

— Doc, estamos em 1985?

— Não, Marty. Estamos no presente. Eles usam Scrum, Jira e Confluence, mas o sistema central executa COBOL.

Marty franziu a testa:

— Isso é possível?

Bellacosa serviu o café.

— No mainframe, garoto, duas coisas aparentemente contraditórias podem ser verdadeiras ao mesmo tempo. O código pode ter 15 anos e a tarefa pode ter chegado há cinco minutos pelo Jira.

Naquela manhã, Igor descobriria que o trabalho de um desenvolvedor COBOL não consiste apenas em escrever código.

Consiste em compreender o negócio, investigar o passado, proteger o presente e impedir que uma regra ambígua seja enviada para o futuro em escala industrial.

1. A sala escura que só existe no cinema

Existe uma caricatura bastante popular do desenvolvedor COBOL: um profissional envelhecido, isolado numa sala subterrânea e diante de uma tela verde, mantendo programas incompreensíveis criados quando a internet ainda usava fraldas.

A tela verde existe.

O ISPF continua sendo utilizado. O acesso por TN3270 continua presente em muitas empresas. Existem programas com 10, 20, 30 ou mais anos de existência.

Porém, ferramentas antigas não significam necessariamente práticas antigas.

Uma equipe COBOL moderna pode utilizar:

Scrum ou Kanban;
Jira para gerenciar tarefas;
Confluence para documentação;
Git para versionamento;
pipelines de integração e entrega;
revisão de código;
testes automatizados;
análise estática;
observabilidade;
APIs;
mensageria;
práticas DevOps;
IDEs como IBM Developer for z/OS;
Visual Studio Code com extensões para IBM Z.

O código pode executar no z/OS enquanto a equipe participa de uma reunião pelo Teams.

Um programa batch pode ler um arquivo sequencial durante a madrugada e depois disponibilizar seus resultados para uma API consumida por um aplicativo móvel.

O cliente toca numa interface criada ontem. A solicitação atravessa várias camadas modernas e termina num programa COBOL criado antes do nascimento de parte da equipe.

A experiência visual é nova. O compromisso financeiro continua no sistema central.

O primeiro ensinamento do Dr. Brown é, portanto:

Não confunda a idade da interface com a capacidade da plataforma.

Um sistema não se torna moderno apenas porque possui botões coloridos. Da mesma forma, não se torna obsoleto apenas porque utiliza uma tela preta.

Um microsserviço criado há seis meses pode ter arquitetura caótica, documentação inexistente e nenhuma observabilidade. Um programa COBOL criado há 20 anos pode ser estável, eficiente, bem monitorado e processar milhões de operações todos os dias.

A idade é uma informação. Não é um diagnóstico.

2. O dia começa olhando o passado recente

Antes de abrir o Jira, responder ao e-mail ou participar da reunião diária, muitos desenvolvedores verificam o que aconteceu durante a noite.

O Dr. Brown gostou imediatamente dessa ideia.

— Finalmente uma profissão que compreende a importância de analisar o passado!

Em ambientes financeiros, o sistema não encerra o expediente quando os funcionários deixam o escritório. Durante a madrugada, começa uma enorme movimentação batch.

Podem ser executados:

fechamento contábil;
cálculo de juros;
processamento de parcelas;
atualização de saldos;
consolidação de movimentos;
geração de extratos;
aplicação de tarifas;
conciliações;
processamento de cartões;
liquidação de operações;
recebimento e envio de arquivos;
backups;
reorganizações;
relatórios gerenciais e regulatórios.

Enquanto a cidade dorme, o mainframe trabalha.

Por isso, uma verificação rápida pode procurar:

jobs que terminaram com código de retorno inesperado;
ABENDs;
arquivos ausentes;
etapas não executadas;
registros rejeitados;
SQLCODEs negativos;
filas MQ acumuladas;
transações CICS com erro;
aumento anormal no tempo de execução;
inconsistências em totais de controle;
alertas abertos pela monitoração;
chamados criados pelo plantão.

Na maioria dos dias, nada grave aconteceu.

E essa é exatamente a finalidade da disciplina operacional: descobrir rapidamente quando o dia não é igual à maioria.

`RC=0000` não é certificado de perfeição

Igor olhou o painel e comemorou:

— Todos os jobs terminaram com RC=0000. Está tudo certo!

O Dr. Brown levantou o dedo.

— Grande Scott! Você acaba de confundir “o programa terminou” com “o programa fez a coisa certa”.

Um retorno igual a zero geralmente indica que o processamento terminou sem uma falha técnica detectada. Isso não garante que a regra de negócio esteja correta.

Considere:

IF WS-SALDO > 1000
    COMPUTE WS-TARIFA = WS-SALDO * 0.01
END-IF

O programa compila.

O programa executa.

O job termina com RC=0000.

Mas a especificação talvez determinasse que a tarifa fosse aplicada somente quando o saldo médio mensal fosse superior a 1.000, e não quando o saldo atual ultrapassasse esse valor.

A máquina executou exatamente o que recebeu.

O erro nasceu antes da execução: nasceu na interpretação da regra.

Essa é uma das verdades mais importantes para quem começa no mainframe:

O computador pode executar com perfeição uma decisão completamente errada.

Um S0C7 é barulhento. O job para, o monitoramento alerta e alguém investiga.

Um erro lógico pode ser silencioso. Ele continua processando milhares ou milhões de registros e termina educadamente com RC=0000.

O ABEND assusta. O erro silencioso sorri.

3. Plantão, recuperação e o ritual do job ressuscitado

Sistemas críticos costumam possuir uma escala de plantão para incidentes fora do horário comercial.

Quando algo falha, o profissional responsável precisa:

receber ou identificar o alerta;
medir o impacto;
consultar logs e procedimentos;
determinar a etapa afetada;
executar uma recuperação segura;
acionar especialistas quando necessário;
comunicar o andamento;
preservar evidências;
registrar o ocorrido.

Mas existe uma diferença importante entre recuperar o serviço e solucionar o problema.

Imagine que um job falhe toda terça-feira e alguém simplesmente o reinicie.

Isso pode manter o processamento funcionando, mas não constitui uma correção definitiva.

Reiniciar é recuperação.
Corrigir a causa é manutenção.
Impedir a recorrência é engenharia.

Se o mesmo job precisa ser ressuscitado semanalmente, a empresa não possui uma solução. Possui um ritual religioso documentado no Confluence.

E talvez nem esteja bem documentado.

Não abra o editor antes de entender o incidente

Um chamado pode dizer:

“O arquivo de pagamentos não foi processado.”

Igor imediatamente procuraria o programa COBOL responsável.

O Dr. Brown perguntaria primeiro:

O arquivo chegou?
Chegou no horário?
Chegou vazio?
O nome estava correto?
O dataset foi catalogado?
O job foi submetido?
A etapa anterior terminou?
Houve falha de autorização?
O programa começou a executar?
Existem registros parcialmente processados?
A retomada pode duplicar movimentos?
O sistema de origem enviou o arquivo correto?

A causa pode estar no programa. Mas também pode estar no JCL, no scheduler, na comunicação, no RACF, no sistema anterior ou no próprio arquivo.

Alterar código antes de reconstruir o acontecimento seria como o Dr. Brown desmontar o DeLorean porque Marty esqueceu de abastecer o gerador.

4. Scrum no mainframe: o futuro chegou e dura 15 minutos

Depois da verificação matinal, chega a reunião diária.

Ela costuma responder a três perguntas:

O que foi concluído?
O que será feito?
Existe algum bloqueio?

A reunião não precisa conter nenhuma peculiaridade COBOL.

Um desenvolvedor pode dizer:

Ontem concluí a análise de impacto do programa de tarifas. Hoje vou implementar o tratamento da nova modalidade. Estou bloqueado porque a especificação não informa como tratar contratos retroativos.

Esse bloqueio não é sinal de fraqueza.

Em sistemas financeiros, reconhecer uma ambiguidade é uma atitude de segurança. O perigoso seria inventar uma resposta e codificá-la.

Jira não é uma máquina de requisitos

O Jira ajuda a controlar tarefas, responsáveis, estados, prioridades e critérios de aceitação. Mas colocar uma frase vaga dentro dele não a transforma numa especificação completa.

Uma tarefa como:

“Alterar cálculo de juros para clientes especiais.”

ainda exige respostas:

Quem é cliente especial?
Onde essa classificação está armazenada?
Qual taxa deve ser aplicada?
A partir de qual data?
Vale para contratos existentes?
O cálculo é retroativo?
Como tratar estornos?
Qual regra de arredondamento?
Quais produtos estão incluídos?
Quais devem ser excluídos?

O Jira organiza a incerteza. Ele não a elimina.

Confluence não é o Livro do Destino

O Confluence pode armazenar:

regras de negócio;
diagramas;
contratos de interface;
decisões técnicas;
procedimentos operacionais;
evidências de testes;
planos de implantação;
instruções de recuperação.

Mas uma página desatualizada não se torna verdadeira porque possui um cabeçalho bonito e o logotipo da empresa.

A documentação precisa ser comparada com:

o código atual;
o comportamento de produção;
tickets antigos;
decisões funcionais;
regras regulatórias;
conhecimento dos usuários experientes.

A modernização não está no nome da ferramenta. Está na qualidade do conhecimento que passa por ela.

5. O verdadeiro trabalho começa antes do `IDENTIFICATION DIVISION`

O iniciante normalmente acredita que sua atividade principal será escrever COBOL.

A parte mais difícil, porém, é descobrir o que deve ser escrito.

A sintaxe básica é relativamente legível:

IF CLIENTE-ATIVO
    PERFORM CALCULAR-TARIFA
ELSE
    PERFORM REGISTRAR-ISENCAO
END-IF

O problema não está necessariamente no IF.

O problema é descobrir o significado de CLIENTE-ATIVO.

Uma conta bloqueada pertence a um cliente ativo?
Cliente falecido continua ativo até o encerramento formal?
Um contrato suspenso é ativo?
A condição é verificada na data atual ou na data de processamento?
Em reprocessamentos, utiliza-se o estado atual ou o estado histórico?
Uma conta sem movimentação há dois anos permanece ativa?

Quando uma expressão de negócio vira uma condição binária, o desenvolvedor precisa transformar uma realidade cheia de tons de cinza em uma decisão executável.

Essa transformação é o coração do trabalho.

6. A especificação simples que quase alterou o futuro

A área de produtos envia a seguinte regra:

“Clientes com saldo superior a R$ 10.000 receberão bonificação de 1%.”

Igor sorri. Parece fácil:

IF WS-SALDO > 10000
    COMPUTE WS-BONUS = WS-SALDO * 0.01
END-IF

O Dr. Brown pega um marcador e começa a escrever perguntas no quadro.

Qual saldo?

Pode ser:

saldo contábil;
saldo disponível;
saldo atual;
saldo médio;
saldo no encerramento do mês;
saldo sem considerar limite;
saldo consolidado entre contas.

“Superior” inclui exatamente R$ 10.000?

Tecnicamente, “superior” sugere:

IF WS-SALDO > 10000

Mas talvez a área de negócio tenha pretendido “a partir de R$ 10.000”:

IF WS-SALDO >= 10000

Um único caractere muda quem recebe o benefício.

O bônus incide sobre qual valor?

Sobre o saldo inteiro?

$R\$ 12.000 \times 1\% = R\$ 120$

Ou somente sobre a parcela superior a R$ 10.000?

$(R\$ 12.000 - R\$ 10.000) \times 1\% = R\$ 20$

Quando o valor deve ser calculado?

diariamente;
no último dia útil;
no fechamento do mês;
no aniversário da conta;
durante a consulta;
quando o arquivo é processado.

Quem deve ser excluído?

contas bloqueadas;
inadimplentes;
funcionários;
contas judiciais;
produtos encerrados;
clientes com pendência documental.

O código pode ser pequeno. A regra não é.

Marty observa o quadro cheio de perguntas:

— Doc, nós precisamos voltar no tempo para perguntar o que eles queriam dizer?

— Não, Marty. Precisamos de critérios de aceitação.

7. Edge cases: onde Igor encontra o Biff Tannen

O caminho feliz é o cenário em que tudo acontece como esperado.

Uma transferência comum pode seguir:

receber a solicitação;
verificar o saldo;
verificar o limite;
debitar a origem;
creditar o destino;
confirmar a operação.

Mas sistemas reais não vivem apenas no caminho feliz.

Existem:

valores negativos;
valor igual ao limite;
contas bloqueadas;
conta de destino inexistente;
moedas diferentes;
transferências agendadas;
duas operações simultâneas;
timeout durante o processamento;
reenvio da mesma mensagem;
falha depois do débito;
feriado;
mudança de limite durante a operação;
conta conjunta;
reprocessamento de movimento antigo.

O edge case é o Biff Tannen da especificação: aparece quando todos acreditavam que a aventura estava resolvida e muda o destino da família inteira.

Uma regra bem descrita deve ser convertida em cenários testáveis:

DADO um cliente ativo
E um limite diário de R$ 5.000
E transferências anteriores no total de R$ 4.000

QUANDO solicitar uma nova transferência de R$ 1.000
ENTÃO a operação deverá ser permitida

QUANDO solicitar uma transferência de R$ 1.000,01
ENTÃO a operação deverá ser rejeitada
E nenhuma movimentação deverá ser gravada

Agora existe uma fronteira clara.

O desenvolvedor sabe o que implementar. O testador sabe o que validar. A área de negócio pode confirmar se a interpretação está correta.

8. Centavos viajam no tempo e voltam como duzentos mil reais

Um erro de R$ 0,01 parece pequeno.

Mas sistemas financeiros operam em escala.

Se a diferença ocorrer em 20 milhões de transações:

$20.000.000 \times R\$ 0,01 = R\$ 200.000$

Além do valor, podem surgir:

divergências contábeis;
reclamações;
ressarcimentos;
auditoria;
retrabalho;
reprocessamento;
investigação regulatória;
dano reputacional.

Por isso, temas aparentemente modestos recebem atenção especial:

casas decimais;
arredondamento;
sinal;
datas;
limites;
moedas;
duplicidade;
ordem das atualizações;
COMMIT;
reinício;
totais de controle.

Considere:

COMPUTE WS-JUROS ROUNDED =
    WS-PRINCIPAL * WS-TAXA * WS-DIAS / 360

A fórmula pode ser válida para um produto e incorreta para outro que utiliza uma base de 365 dias.

O programa não produzirá obrigatoriamente um ABEND. Ele continuará executando a fórmula errada com excelente desempenho.

O mainframe não transforma uma regra incorreta em correta.

Ele apenas permite executá-la muito rapidamente.

9. Antes de alterar o programa, descubra em que linha do tempo ele vive

Depois de compreender a solicitação, o desenvolvedor precisa mapear o sistema.

Uma alteração pode envolver:

programas COBOL;
copybooks;
JCLs;
PROCs;
arquivos sequenciais;
VSAM;
tabelas Db2;
mapas BMS;
transações CICS;
filas MQ;
APIs;
rotinas chamadas;
schedulers;
programas anteriores e posteriores.

Uma tarefa chamada “alterar o cálculo” talvez afete um fluxo inteiro:

flowchart TD
    A["Arquivo recebido"] --> B["Validação"]
    B --> C["Cálculo COBOL"]
    C --> D["Atualização Db2"]
    C --> E["Arquivo contábil"]
    D --> F["Consulta on-line"]
    E --> G["Conciliação"]

Se o cálculo mudar no batch, mas a consulta on-line continuar utilizando a regra anterior, o cliente verá um valor enquanto a contabilidade registra outro.

Esse é o tipo de universo paralelo que nem o Dr. Brown deseja visitar.

O copybook compartilhado e o paradoxo dos quatro bytes

Imagine:

01 CLIENTE-REGISTRO.
   05 CLIENTE-ID          PIC 9(10).
   05 CLIENTE-NOME        PIC X(40).
   05 CLIENTE-STATUS      PIC X.

A empresa decide ampliar o identificador:

05 CLIENTE-ID             PIC 9(14).

A mudança parece envolver apenas quatro posições.

Mas pode alterar:

o tamanho total do registro;
a posição de todos os campos seguintes;
layouts de arquivos;
contratos de mensagens;
chaves;
telas;
relatórios;
programas consumidores;
interfaces externas.

Se um consumidor continuar esperando o layout antigo, poderá interpretar quatro caracteres do nome como parte do identificador e ler o status na posição errada.

No mainframe, quatro bytes podem alterar o futuro.

10. Programas antigos não são fósseis; são cidades construídas em camadas

Igor recebe a tarefa de modificar um programa executado há 15 anos.

Ao abrir o fonte, encontra:

IF WS-TIPO-CONTA = 47
    MOVE 'N' TO WS-COBRA-TARIFA
END-IF

Não há comentário explicando a razão.

Igor pensa:

— Isso parece desnecessário. Vou remover.

O Dr. Brown quase derruba o café.

— Nunca apague uma regra misteriosa antes de descobrir qual desastre ela impediu!

O código pode representar:

uma determinação judicial;
uma regra regulatória;
uma isenção contratual;
um produto incorporado de outro banco;
uma correção aplicada após um incidente;
compatibilidade com dados antigos;
uma condição temporária que se tornou permanente.

Código antigo é uma forma de documentação executável. Ele mostra o que o sistema faz, mas nem sempre explica por que faz.

Por outro lado, o fato de uma regra estar no código não prova que continua correta.

Podemos encontrar quatro situações:

Documentação	Código	Diagnóstico
correta	correto	cenário ideal
correta	incorreto	defeito de implementação
desatualizada	correto	falha de documentação
desatualizada	incorreto	investigação profunda

Existe ainda o cenário clássico do mainframe:

Ninguém sabe, mas sempre funcionou assim.

Nesse momento, é necessário consultar:

histórico de mudanças;
chamados antigos;
usuários experientes;
analistas de negócio;
evidências de testes;
relatórios;
legislação;
contratos;
sistemas consumidores.

O desenvolvedor torna-se arqueólogo corporativo — mas um arqueólogo que precisa manter a cidade funcionando enquanto escava.

11. TN3270: a tela verde não é o mainframe inteiro

O acesso por TN3270 continua sendo realidade em algumas equipes.

Por meio dele, o profissional pode acessar:

TSO;
ISPF;
editor;
SDSF;
datasets;
utilitários;
compiladores;
ferramentas de comparação;
produtos de gerenciamento de fontes.

Para o iniciante, a interface pode parecer hostil. Para o veterano, ela se torna memória muscular.

Comandos de linha, teclas de função, edição em bloco, pesquisa, repetição, exclusão e submissão de jobs permitem trabalhar com grande velocidade.

A existência de uma interface antiga não significa que a plataforma seja incapaz. Mas pode haver limitações para práticas contemporâneas:

navegação visual por dependências;
integração com Git;
análise durante a edição;
refatoração assistida;
depuração visual;
testes automatizados;
integração com pipelines;
onboarding;
produtividade de novos profissionais.

Por isso, algumas organizações adotam IBM Developer for z/OS, Visual Studio Code, Zowe Explorer e outras ferramentas.

Trocar o editor não basta

Modernizar a experiência exige também resolver:

gerenciamento de dependências;
copybooks;
build;
versionamento;
testes;
promoção entre ambientes;
segurança;
licenciamento;
treinamento;
governança.

Caso contrário, a empresa coloca um painel futurista no DeLorean, mas continua empurrando o carro porque esqueceu o combustível.

12. O JCL é a estrada por onde o programa chega aos dados

O programa COBOL contém a lógica. Mas, num processamento batch, o JCL informa como o programa será executado.

Exemplo simplificado:

//BONUS    JOB ...
//STEP01   EXEC PGM=CALCBON
//STEPLIB  DD DSN=APP.TEST.LOADLIB,DISP=SHR
//ENTRADA  DD DSN=APP.TEST.CLIENTES,DISP=SHR
//SAIDA    DD DSN=APP.TEST.BONUS,
//            DISP=(NEW,CATLG,DELETE),
//            SPACE=(CYL,(5,2)),
//            DCB=(RECFM=FB,LRECL=120)

O JCL informa:

qual programa executar;
onde encontrar o módulo de carga;
qual arquivo fornecer como entrada;
onde criar a saída;
como alocar recursos;
o que fazer em caso de sucesso ou falha.

Um programa correto com JCL incorreto pode processar o arquivo errado.

Um JCL correto com programa incorreto pode executar perfeitamente uma regra errada.

Ambos precisam ser testados.

Também é necessário compreender o fluxo das etapas. Se o STEP02 depende do arquivo produzido pelo STEP01, não basta analisar cada etapa isoladamente.

O batch é uma viagem. Cada job, step, programa e dataset representa parte da rota.

13. `COMMIT`, `ROLLBACK` e a viagem que talvez já tenha acontecido

Suponha que uma transferência realize:

débito na conta de origem;
crédito na conta de destino;
gravação do histórico;
envio da confirmação.

Se o sistema falhar entre o débito e o crédito, o cliente pode perder dinheiro sem que o destino o receba.

Por isso, alterações relacionadas devem fazer parte de uma unidade de trabalho controlada.

Uma representação simplificada:

EXEC SQL
    UPDATE CONTA
       SET SALDO = SALDO - :WS-VALOR
     WHERE CONTA_ID = :WS-ORIGEM
END-EXEC

IF SQLCODE = 0
    EXEC SQL
        UPDATE CONTA
           SET SALDO = SALDO + :WS-VALOR
         WHERE CONTA_ID = :WS-DESTINO
    END-EXEC
END-IF

IF SQLCODE = 0
    EXEC SQL
        COMMIT
    END-EXEC
ELSE
    EXEC SQL
        ROLLBACK
    END-EXEC
END-IF

Mas até esse exemplo abre novas perguntas:

O que acontece se a origem não tiver saldo?
E se o destino não existir?
As atualizações podem ocorrer simultaneamente?
O histórico faz parte da mesma unidade de trabalho?
E se o timeout acontecer depois do COMMIT, mas antes da resposta?
O cliente tentará novamente?
Como impedir débito duplicado?
A operação possui um identificador único?

Este último cenário é especialmente perigoso.

O cliente envia uma transferência. O sistema confirma o COMMIT, mas a resposta se perde. O aplicativo acredita que houve falha e reenvia a solicitação.

A primeira viagem aconteceu, mas Marty não recebeu a fotografia.

Sem idempotência ou controle de duplicidade, o débito poderá ocorrer duas vezes.

14. Compilar não significa testar

Quando a compilação termina sem erros, Igor comemora:

— Funcionou!

Bellacosa aponta para a tela:

— Compilou.

Existe uma diferença enorme.

A compilação demonstra que o código está formalmente aceitável para o compilador. Não demonstra que:

a regra está correta;
o arquivo certo foi utilizado;
os limites foram tratados;
o arredondamento está correto;
o programa suporta o volume esperado;
o processamento pode ser reiniciado;
o rollback funciona;
não haverá duplicidade;
outros sistemas continuam compatíveis.

Um teste adequado deve cobrir:

Caminho feliz

O cenário normal, com dados válidos e resultado esperado.

Limites

Valores exatamente iguais, imediatamente inferiores e imediatamente superiores às fronteiras.

Dados inválidos

Campos ausentes, caracteres onde deveriam existir números, datas impossíveis e códigos desconhecidos.

Falhas técnicas

Arquivo ausente, SQLCODE inesperado, indisponibilidade de serviço, fila bloqueada.

Reprocessamento

O que acontece se o mesmo arquivo, mensagem ou movimento for enviado novamente?

Volume

O processamento termina dentro da janela disponível?

Efeitos laterais

Além da saída principal, o sistema atualizou corretamente histórico, contabilidade, mensagens e auditoria?

O teste mais perigoso é aquele preparado apenas para confirmar a hipótese do próprio desenvolvedor.

15. A equipe precisa de aprendizes porque o conhecimento precisa viajar

Uma equipe saudável mistura:

profissionais juniores;
profissionais plenos;
profissionais seniores.

Isso não serve apenas para distribuir tarefas por dificuldade. Serve para transportar conhecimento entre gerações.

Existem pelo menos três tipos de conhecimento.

Conhecimento técnico

COBOL;
JCL;
CICS;
Db2;
VSAM;
MQ;
TSO/ISPF;
ferramentas de diagnóstico.

Conhecimento da aplicação

quais programas participam do fluxo;
quais dados são consumidos;
onde estão as dependências;
como testar;
como reiniciar;
quais resultados validar.

Conhecimento do negócio

por que a regra existe;
quais produtos são exceções;
quais áreas utilizam a informação;
quais controles são obrigatórios;
quais incidentes já aconteceram.

O conhecimento técnico pode ser adquirido em cursos e laboratórios.

O conhecimento da aplicação surge com experiência prática.

O conhecimento do negócio frequentemente vive na memória das pessoas.

Por isso, transferência de conhecimento não acontece entregando 500 fontes COBOL ao júnior e dizendo:

Estude. Depois conversamos.

Ela acontece por meio de:

programação em pares;
revisão de código;
análise conjunta;
participação em incidentes;
acompanhamento de implantações;
documentação;
rotação de responsabilidades;
explicação das decisões;
exercícios controlados.

O sênior não deve ser o único dono do capacitor de fluxo

Se apenas uma pessoa sabe recuperar determinado processo, a organização possui um risco.

Se toda madrugada alguém liga para “o Geraldo do fechamento”, porque somente ele conhece a sequência correta, Geraldo pode ser excelente — mas o sistema é frágil.

O profissional experiente aumenta seu valor quando transforma conhecimento pessoal em capacidade coletiva.

Um verdadeiro sênior não ensina apenas sintaxe. Ensina consequências.

O júnior pergunta:

— Como faço um READ?

O sênior acrescenta:

— O que acontecerá se o arquivo estiver vazio? Você verificou o FILE STATUS? O programa pode ser reiniciado depois de ler metade dos registros? Como evitar duplicidade?

O júnior vê uma instrução.

O sênior vê a madrugada que essa instrução pode produzir.

16. Passo a passo do jovem padawan COBOL

Ao receber uma nova tarefa, Igor deveria seguir este roteiro.

Passo 1 — Leia tudo antes de editar

Não abra imediatamente o programa. Leia a descrição, os critérios de aceitação e os documentos relacionados.

Passo 2 — Marque os termos ambíguos

Palavras perigosas incluem:

ajustar;
corrigir;
excluir;
cancelar;
automaticamente;
retroativo;
cliente ativo;
apenas;
normalmente.

“É apenas uma pequena alteração” costuma ser o trovão que atinge a torre do relógio.

Passo 3 — Converta frases em exemplos

Se a regra diz “acima do limite”, escreva casos com valor abaixo, igual e acima.

Passo 4 — Descubra onde a regra está implementada

Procure programas, copybooks, tabelas, arquivos, transações e consumidores.

Passo 5 — Faça a análise de impacto

Pergunte o que lê, chama, grava ou depende do componente alterado.

Passo 6 — Entenda o comportamento atual

Antes de mudar, consiga explicar o que o programa faz hoje.

Passo 7 — Investigue trechos misteriosos

Não remova exceções sem descobrir sua origem.

Passo 8 — Prepare os testes antes ou durante a implementação

Inclua caminho feliz, limites, erros, duplicidade e reprocessamento.

Passo 9 — Implemente a menor mudança segura

Evite misturar uma mudança funcional com uma grande refatoração desnecessária.

Passo 10 — Compile e leia as mensagens

Não ignore warnings apenas porque o módulo foi criado.

Passo 11 — Teste os resultados e os efeitos laterais

Confira arquivos, tabelas, históricos, totais e mensagens.

Passo 12 — Solicite revisão

Outro profissional pode perceber uma suposição que ficou invisível para quem escreveu.

Passo 13 — Atualize a documentação

Registre o que mudou, por que mudou e como validar.

Passo 14 — Planeje implantação e retorno

Defina como instalar, monitorar e desfazer a mudança com segurança.

Passo 15 — Verifique produção

Uma implantação não termina quando o componente chega à produção. Termina quando existem evidências de que o comportamento esperado ocorreu.

17. Curiosidades escondidas no DeLorean

Um programa antigo pode usar um compilador atual

A idade do código-fonte, do módulo executável e do hardware não precisa ser a mesma. Um programa criado décadas atrás pode ser recompilado com Enterprise COBOL moderno e executar num IBM Z recente.

COBOL não é automaticamente confiável

A plataforma oferece recursos poderosos de disponibilidade, processamento e recuperação. Entretanto, um programa mal projetado continua sendo um programa mal projetado.

A tela verde é uma interface, não uma arquitetura

Atrás do TN3270 podem existir APIs, pipelines, testes, mensageria, monitoração e integrações contemporâneas.

O conhecimento mais raro talvez não seja a linguagem

É possível ensinar COBOL. Mais difícil é encontrar quem compreenda simultaneamente o código, a aplicação, o fluxo operacional e as regras financeiras acumuladas durante anos.

“Legado” não significa inútil

Legado é aquilo que foi herdado. Pode ser valioso ou problemático. O diagnóstico depende de manutenção, risco, documentação, custo e capacidade de evolução.

Reescrever pode apagar regras invisíveis

Uma reescrita precisa reproduzir não apenas as funcionalidades documentadas, mas também comportamentos e exceções que foram acumulados no sistema atual.

O número 1,21 não serve apenas para gigawatts

Se Igor calcular juros de 1,21% utilizando uma escala decimal incorreta, o DeLorean talvez não viaje no tempo, mas a conciliação certamente desaparecerá no espaço.

18. Modernização não significa jogar o passado no lixo

Quando alguém diz “modernizar COBOL”, pode estar falando de muitas coisas diferentes:

Dimensão	Possível modernização
Editor	IDz ou Visual Studio Code
Fontes	Git e revisão por pull request
Build	automação com DBB ou pipelines
Testes	testes unitários e regressivos
Integração	APIs, eventos e mensageria
Operação	observabilidade e automação
Código	refatoração e modularização
Conhecimento	documentação e capacitação
Plataforma	atualização de compilador e middleware

Uma reescrita completa é apenas uma das possibilidades — e frequentemente a mais arriscada.

Antes de substituir um sistema, a organização precisa responder:

Onde estão todas as regras que ele executa?

Se parte da resposta for “no código” e outra parte for “na cabeça do Geraldo”, o projeto de reescrita já possui dois grandes riscos.

Modernização inteligente preserva o que funciona, reduz os pontos frágeis e aumenta a capacidade de mudança.

Não se trata de permanecer em 1985.

Trata-se de trazer para o futuro aquilo que continua gerando valor, sem transportar os mesmos problemas escondidos no porta-malas.

19. O trabalho consequencial

No final do dia, o desenvolvedor talvez tenha escrito apenas cinquenta linhas de COBOL.

Mas, antes disso, ele:

verificou produção;
participou do Scrum;
leu a especificação;
questionou uma ambiguidade;
consultou a área de negócio;
investigou programas antigos;
analisou dependências;
preparou dados;
executou testes;
revisou resultados;
ajudou um júnior;
atualizou a documentação;
acompanhou a implantação.

As cinquenta linhas são a parte visível.

O trabalho principal foi reduzir a incerteza.

Em sistemas financeiros, decisões do desenvolvedor podem determinar:

se um salário será creditado;
se um cartão será autorizado;
se uma apólice será renovada;
se os juros estarão corretos;
se uma transferência será duplicada;
se a contabilidade fechará;
se o relatório regulatório será consistente.

Na maioria dos dias, nada cinematográfico acontece.

Os jobs terminam. As transações respondem. Os totais fecham. O dinheiro chega ao destino correto.

Essa normalidade não significa que o trabalho seja pouco importante.

A normalidade é justamente o produto do trabalho.

Epílogo — Para onde vamos, ainda precisamos de logs

Eram 18h42 quando o Dr. Brown finalmente se levantou.

O programa havia sido alterado, revisado e testado. O caso do valor exatamente igual ao limite fora esclarecido. Os contratos retroativos receberam uma regra específica. A conciliação fechou.

Igor olhou orgulhoso para o fonte.

— Então é isso que faz um desenvolvedor COBOL?

Bellacosa respondeu:

— Isso é parte do que ele faz.

— Mas escrevemos tão pouco código!

O Dr. Brown apontou para a tela.

— Meu jovem, qualquer máquina pode executar instruções. O difícil é decidir quais instruções devem atravessar o tempo.

Marty entrou no DeLorean e perguntou:

— Doc, para onde vamos agora?

Brown verificou o relógio.

— Para amanhã, 8h07. Quero descobrir se o job terminou corretamente.

— Mas nós já testamos!

— Exatamente. Agora precisamos descobrir o que aconteceu com dados reais.

O capacitor de fluxo acendeu. O DeLorean acelerou pelo corredor e desapareceu num clarão, deixando duas marcas de pneu ao lado da cafeteira.

No monitor, uma mensagem apareceu:

JOB CALCBON ENDED - RC=0000

Igor sorriu.

Depois lembrou-se da primeira lição, abriu o relatório de conciliação e conferiu os totais.

Porque o desenvolvedor COBOL maduro sabe que RC=0000 significa apenas que a máquina terminou sua viagem.

Ainda cabe ao ser humano verificar se ela chegou ao futuro correto.

Translate

domingo, 2 de abril de 2023