Como entender um programa COBOL legado pela primeira vez

Receber um programa COBOL legado para analisar pode parecer complicado, principalmente quando o fonte possui milhares de linhas, diversos CALLs, copybooks, acessos a arquivos, comandos SQL e vários anos de manutenção.
A melhor estratégia não é começar lendo o programa linha por linha. Primeiro, procure entender o contexto do processamento e somente depois aprofunde a análise do código.
1. Descubra como o programa é executado
Antes de analisar o fonte, identifique:

• O programa é batch ou on-line?
• É executado por JCL?
• É chamado por outro programa?
• É uma transação CICS?
• Faz parte de uma cadeia de processamento?
• É executado diariamente, mensalmente ou sob demanda?

No processamento batch, comece pelo JCL. Ele mostra quais programas são executados, quais arquivos são utilizados e qual é a sequência dos steps.
2. Leia a IDENTIFICATION DIVISION
Procure informações como:

• Nome do programa;
• Objetivo;
• Histórico de alterações;
• Sistemas relacionados;
• Data e motivo das manutenções.

Os comentários podem estar desatualizados, mas ajudam a identificar a intenção original do programa.
3. Mapeie as entradas e saídas
Verifique a ENVIRONMENT DIVISION e a FILE SECTION para descobrir:

• Arquivos de entrada;
• Arquivos de saída;
• Arquivos indexados;
• Relatórios gerados;
• Layouts utilizados;
• DDNAMEs esperados.

Se o programa utilizar DB2, procure comandos como: Se utilizar CICS, procure comandos como: 4. Identifique os copybooks
Os copybooks podem conter:

• Layouts de arquivos;
• Áreas de comunicação;
• Estruturas de tabelas;
• Constantes;
• Códigos de retorno;
• Campos utilizados por vários programas.

Registre quais copybooks são utilizados e onde cada um participa do processamento.
5. Comece pela PROCEDURE DIVISION
Localize o fluxo principal. Muitos programas apresentam uma estrutura parecida com: Essa parte funciona como um mapa resumido do programa. Depois de entendê-la, analise cada rotina separadamente.
6. Mapeie PERFORM, CALL e GO TO
Crie uma lista contendo:

• Rotinas executadas com PERFORM;
• Programas chamados por CALL;
• Desvios realizados por GO TO;
• Pontos de retorno;
• Condições que controlam o fluxo;
• Rotinas de tratamento de erro.

Em programas muito antigos, o fluxo pode não ser totalmente estruturado. Nesse caso, desenhar a sequência de execução ajuda bastante.
7. Identifique as regras de negócio
Procure comandos que alterem o comportamento do processamento:

• IF;
• EVALUATE;
• COMPUTE;
• ADD e SUBTRACT;
• Comparações de status;
• Validações de datas;
• Atualizações de valores;
• Tratamento de códigos de retorno.

Não considere todo IF como regra de negócio. Algumas condições existem apenas para controlar arquivos, loops ou erros técnicos.
8. Analise o tratamento de erros
Verifique como o programa trata:

• FILE STATUS;
• SQLCODE;
• EIBRESP e EIBRESP2;
• RETURN-CODE;
• Códigos retornados por subprogramas;
• ABENDs;
• Mensagens gravadas no spool.

Um programa legado pode esconder falhas quando ignora códigos de retorno ou apenas grava uma mensagem e continua o processamento.
9. Monte um mapa do programa
Ao final da primeira análise, registre:

• Objetivo do programa;
• Forma de execução;
• Arquivos de entrada e saída;
• Tabelas DB2 acessadas;
• Transações ou recursos CICS;
• Copybooks utilizados;
• Programas chamados;
• Principais regras de negócio;
• Possíveis pontos de risco;
• Dúvidas que precisam ser confirmadas.

10. Não altere antes de entender
Evite começar refatorando nomes, removendo GO TO ou reorganizando parágrafos antes de compreender o comportamento atual.
Em sistemas legados, uma instrução aparentemente desnecessária pode existir por causa de uma condição operacional, formato de arquivo ou integração que não está documentada no fonte.
Primeiro documente, depois crie testes e somente então avalie uma alteração.
Qual método você utiliza para analisar um programa COBOL desconhecido? Você começa pelo JCL, pelo fluxo principal ou pelos arquivos envolvidos?