Bellacosa Mainframe e o redefines em cobol risco de perigo eminente

☕ Um Café no Bellacosa Mainframe

REDEFINES, Compiler Options e o Diagnóstico que o COBOL Iniciante Não Vê

🩺 House M.D. entra no CPD: “O compilador não mente. O programador é que perguntou a coisa errada.”

Existe um momento inevitável na vida de todo programador COBOL.

Você está diante de um programa aparentemente simples.

O JCL compilou.

O retorno foi bonito.

MAXCC=0

Nenhuma explosão.

Nenhum abend.

Nenhum operador telefonando.

Nenhum gerente atravessando o corredor com aquela expressão típica de quem acabou de descobrir que o processamento noturno está duas horas atrasado.

Você olha para o código e pensa:

— Funcionou.

E, em algum lugar do hospital Princeton-Plainsboro do mainframe, o Dr. Gregory House manca pelo corredor, toma um Vicodin imaginário e responde:

— Não. Apenas ainda não morreu.

Bem-vindo ao Bellacosa Mainframe.

Hoje vamos investigar um daqueles problemas que parecem pequenos demais para merecer atenção até o dia em que deixam de ser pequenos:

REDEFINES com tamanhos diferentes.

E, a partir dele, vamos abrir uma porta muito maior:

como o COBOL organiza memória;
o que REDEFINES realmente faz;
por que o compilador pode aceitar coisas que você não deveria escrever;
como identificar diferenças de tamanho;
como usar MAP;
como usar XREF;
quais opções de compilação ajudam;
onde essas opções podem ser configuradas;
o que é CBL;
o que é PROCESS;
o que é SYSOPTF;
o que é OPTFILE;
o que é IGYCDOPT;
como funciona a precedência das opções;
e por que um bom programador COBOL precisa aprender a ler o listing como um médico lê um exame de sangue.

Pegue o café.

Temos um paciente.

🩻 Caso clínico: o `REDEFINES` suspeito

Imagine o seguinte código:

       WORKING-STORAGE SECTION.

       01  WS-AREA-ORIGINAL.
           05 WS-CAMPO-A        PIC X(10).
           05 WS-CAMPO-B        PIC X(10).

       01  WS-AREA-NOVA
           REDEFINES WS-AREA-ORIGINAL.
           05 WS-CAMPO-C        PIC X(30).

O iniciante olha rapidamente.

Área original:

10 + 10 = 20 bytes

Área redefinida:

30 bytes

Logo nasce a pergunta:

“Como uma área de 30 bytes pode redefinir uma área que aparentemente tem 20?”

Excelente pergunta.

E é exatamente aí que mora a armadilha.

🧠 Primeiro diagnóstico: `REDEFINES` não significa “nova variável”

Talvez o erro conceitual mais comum seja imaginar que isto:

01 A PIC X(10).
01 B REDEFINES A PIC X(10).

significa:

A = 10 bytes
B = 10 bytes
TOTAL = 20 bytes

Não.

Pense em uma gaveta.

Existe uma única gaveta física.

Você pode colocar uma etiqueta nela escrito:

ou outra etiqueta:

Mas continua sendo a mesma gaveta.

Conceitualmente:

             MEMÓRIA

      ┌──────────────────┐
A --> │ A B C D E F G H I J │
      └──────────────────┘
               ↑
B -------------┘

A e B são duas maneiras diferentes de interpretar os mesmos bytes.

Então grave isto:

REDEFINES cria uma nova visão lógica, não necessariamente uma nova área independente de storage.

Uma frase Bellacosa para decorar:

REDEFINES não constrói outro apartamento. Ele entrega outra planta do mesmo apartamento.

🏠 Um exemplo clássico e correto

Datas são perfeitas para entender isso.

       01  WS-DATA.
           05 WS-DATA-INTEIRA   PIC X(08).

       01  WS-DATA-DETALHE
           REDEFINES WS-DATA.
           05 WS-ANO            PIC 9(04).
           05 WS-MES            PIC 9(02).
           05 WS-DIA            PIC 9(02).

Se WS-DATA-INTEIRA contiver:

20260816

a mesma sequência pode ser visualizada assim:

WS-DATA-INTEIRA

┌─────────────────────────┐
│ 2 0 2 6 0 8 1 6         │
└─────────────────────────┘

ou:

WS-DATA-DETALHE

┌────────────┬──────┬──────┐
│ WS-ANO     │ MÊS  │ DIA  │
│ 2026       │ 08   │ 16   │
└────────────┴──────┴──────┘

Mesmos oito bytes.

Duas interpretações.

Perfeito.

🚨 Então o tamanho precisa ser sempre igual?

Aqui começa a parte interessante.

Para ensinar um iniciante, eu usaria uma regra extremamente conservadora:

TAMANHO DO REDEFINES
        =
TAMANHO DA ÁREA REDEFINIDA

Essa regra evita muitos erros.

Mas o COBOL real é mais complexo.

Dependendo do nível da estrutura, da versão do compilador, das regras da linguagem e do Enterprise COBOL utilizado, algumas redefinições com comprimentos diferentes podem ser aceitas.

Ou seja:

O compilador aceitar não significa que o design seja bom.

House provavelmente escreveria no quadro:

COMPILES ≠ CORRECT

E depois apagaria metade da palavra só para irritar a equipe.

🧪 O erro realmente perigoso

O problema não é simplesmente escrever:

05 B REDEFINES A PIC X(30).

O problema é escrever isso sem perceber as implicações.

Porque daí temos uma diferença enorme entre duas perguntas:

Pergunta errada

“O compilador aceitou?”

Pergunta certa

“O layout de memória resultante é exatamente aquele que eu acredito que seja?”

A segunda pergunta separa quem está apenas digitando COBOL de quem está começando a entender COBOL.

🔬 Não confie apenas nos olhos: use o `MAP`

Aqui aparece um dos recursos mais úteis e menos apreciados pelos iniciantes:

MAP

Ao compilar com MAP, o Enterprise COBOL produz informações sobre o layout da DATA DIVISION.

Em outras palavras:

o compilador mostra como ele entendeu seus campos.

Isso é quase um raio-X da memória.

Imagine:

       01 WS-REGISTRO.
          05 WS-NOME     PIC X(20).
          05 WS-IDADE    PIC 99.
          05 WS-SALARIO  PIC S9(7)V99 COMP-3.

Você pode acreditar que sabe exatamente como isso está organizado.

Mas o listing é a resposta do compilador.

E sempre que houver estruturas complexas com:

REDEFINES
OCCURS
COMP
COMP-3
SYNC
SIGN
GROUP ITEMS
COPYBOOKS

a leitura do mapa se torna extremamente valiosa.

🩻 MAP é o raio-X; SOURCE é a ficha clínica

Eu normalmente colocaria em desenvolvimento algo semelhante a:

MAP
SOURCE
XREF(FULL)

Cada opção responde uma pergunta diferente.

`SOURCE`

Você vê o fonte associado ao listing.

Isso facilita conectar mensagens, offsets e referências ao código que realmente foi compilado.

Parece trivial.

Até você descobrir que o programa que estava olhando não era exatamente o programa que entrou na compilação.

Copybooks entram.

Pré-compiladores entram.

Conditional compilation entra.

E de repente:

“Mas no meu fonte não está assim!”

Bem-vindo ao mainframe.

O compilador não lê suas intenções.

Ele lê aquilo que efetivamente recebeu.

🧬 `XREF(FULL)`: quem mexeu no paciente?

XREF significa referência cruzada.

Imagine que você encontra:

WS-CUSTOMER-AREA

e quer saber:

onde foi declarada;
onde foi usada;
quem altera;
quem consulta;
quais parágrafos fazem referência a ela.

É aí que:

XREF(FULL)

se torna extremamente útil.

Ele não é especificamente um detector mágico de REDEFINES incorreto.

Mas responde uma pergunta fundamental na investigação:

“Quem está usando esta área?”

House chamaria isso de procurar quem teve contato com o paciente antes dos sintomas aparecerem.

🧯 Regra prática para o iniciante

Sempre que você encontrar:

REDEFINES

pare.

Faça quatro perguntas:

1. Qual é o tamanho da área original?

2. Qual é o tamanho da redefinição?

3. Essa diferença é intencional?

4. Eu conferi o MAP?

Essa pausa de trinta segundos pode economizar horas de debugging.

🧮 Não confie demais na contagem visual

Isto parece fácil:

05 CAMPO-A PIC X(10).
05 CAMPO-B PIC X(10).

Total:

Mas layouts reais podem envolver:

05 VALOR-A PIC S9(9) COMP.
05 VALOR-B PIC S9(7)V99 COMP-3.
05 TABELA OCCURS 15 TIMES.

Agora contar “na cabeça” começa a ficar menos divertido.

E podemos adicionar:

SYNC
USAGE
SIGN
OCCURS DEPENDING ON
nested groups
copybooks

Pronto.

Você não está mais contando caracteres.

Está fazendo arqueologia.

🗿 Easter egg número 1: Indiana Jones e o Copybook Perdido

Todo programador COBOL experiente já encontrou algo assim:

COPY ABCD001.

Você abre.

Dentro existe:

COPY ABCD002.

Abre o segundo.

Existe:

COPY ABCD003.

Quinze minutos depois você está procurando um copybook criado em 1989 por um programador chamado Geraldo que se aposentou antes do Windows 95.

Indiana Jones tinha menos trabalho.

🧪 Existe warning para `REDEFINES`?

A resposta precisa ser cuidadosamente entendida.

O Enterprise COBOL possui diversas opções de diagnóstico e comportamento, incluindo regras relacionadas a construções da linguagem.

Uma opção interessante é a família:

RULES

e, dentro dela, configurações relacionadas à permissividade de redefinições.

Por exemplo:

RULES(NOLAXREDEF)

pode tornar determinadas situações de REDEFINES mais rigorosas.

Mas atenção:

não pense em NOLAXREDEF como um “detector universal de REDEFINES maior”.

Isso seria simplificar demais.

Ele atua sobre regras específicas da linguagem e situações de redefinição que o compilador poderia tratar de maneira mais permissiva.

Então a estratégia profissional não deve ser:

“Coloquei NOLAXREDEF, estou protegido.”

Deve ser:

compiler diagnostics
+
MAP
+
coding standard
+
static analysis
+
code review

Defesa em profundidade.

Segurança da informação descobriu isso faz décadas.

COBOL também merece.

🏥 Diagnóstico diferencial

House raramente acreditava na primeira hipótese.

Você também não deveria.

Se um programa possui corrupção de campos, valores estranhos ou informações que aparecem “do nada”, REDEFINES é apenas uma das hipóteses.

Também investigue:

MOVE com tamanhos incompatíveis
subscripts incorretos
índices fora do limite
OCCURS
OCCURS DEPENDING ON
reference modification
COMP-3 inválido
campos numéricos contendo lixo
copybook incompatível
arquivo com LRECL errado
layout diferente entre produtor e consumidor
LINKAGE SECTION incorreta
CALL com assinatura incompatível
CICS COMMAREA
MQ payload
VSAM
Db2 host variables

O sintoma pode aparecer em um campo.

A doença pode estar cinquenta linhas antes.

Ou cinquenta programas antes.

🧰 Minha configuração de investigação

Para ambiente de desenvolvimento, algo nessa filosofia é ótimo:

SOURCE
MAP
XREF(FULL)

e opções adicionais de diagnóstico conforme a política da instalação.

Não estou dizendo:

“Use exatamente esse conjunto em qualquer empresa.”

Cada shop possui padrões, versões, custos de listing, ferramentas, pipelines e políticas.

Mas o princípio é sólido:

Durante desenvolvimento, peça ao compilador para mostrar o máximo possível sobre o que ele entendeu.

🔧 “Mas onde coloco esses parâmetros?”

Agora chegamos a outra pergunta fundamental.

Muitos iniciantes acreditam que as opções de compilação existem apenas no JCL:

//COBOL EXEC PGM=IGYCRCTL,
// PARM='MAP,XREF,SOURCE'

Não.

O JCL é apenas uma das portas.

E entender isso muda completamente sua visão sobre compilação COBOL.

🚪 Porta 1 — PARM no JCL

A forma mais conhecida:

//COB EXEC PGM=IGYCRCTL,
// PARM='MAP,XREF(FULL),SOURCE'

Ou por meio de uma PROC corporativa.

É simples.

É visível.

E funciona bem.

Mas existe uma fraqueza:

depende do ambiente de compilação utilizado.

Se alguém usar outra PROC, outro pipeline ou outro processo, aquelas opções podem mudar.

🚪 Porta 2 — `CBL`

Você pode colocar opções diretamente no fonte.

Exemplo:

       CBL MAP,XREF(FULL),SOURCE
       IDENTIFICATION DIVISION.
       PROGRAM-ID. PACIENTE.

Isso significa:

“Este programa solicita essas opções.”

É muito poderoso porque a configuração viaja junto com o fonte.

🚪 Porta 3 — `PROCESS`

Outra sintaxe:

       PROCESS MAP,XREF(FULL),SOURCE
       IDENTIFICATION DIVISION.

Conceitualmente, PROCESS e CBL servem para informar opções ao compilador a partir do próprio programa.

Existe uma regra importante:

essas diretivas aparecem no início apropriado do fonte.

Elas não são statements executáveis.

Você não coloca:

PROCEDURE DIVISION.
    PROCESS MAP.

Isso seria como tentar mudar a configuração do aparelho de raio-X depois que o paciente já voltou para casa.

🧳 Quando usar `CBL` ou `PROCESS`?

Imagine uma aplicação que, por característica própria, precisa sempre ser compilada com determinada configuração.

Nesse caso faz sentido considerar:

CBL / PROCESS

Mas existe uma discussão arquitetural importante.

Você quer que:

cada programa decida suas próprias opções

ou:

a empresa defina um padrão central?

Essa decisão importa.

Porque programas vivem décadas.

Padrões corporativos mudam.

Compiladores mudam.

Ambientes mudam.

🚪 Porta 4 — `SYSOPTF` e `OPTFILE`

Agora entramos numa solução muito interessante para shops organizadas.

Em vez de escrever quarenta opções no JCL, você pode manter um arquivo de opções.

Algo conceitualmente assim:

EMPRESA.COBOL.OPTIONS(DEV)

contendo:

MAP
SOURCE
XREF(FULL)

E associá-lo como:

//SYSOPTF DD DSN=EMPRESA.COBOL.OPTIONS(DEV),DISP=SHR

O compilador pode então consumir essas opções através do mecanismo apropriado de option file.

Isso permite criar perfis.

Por exemplo:

EMPRESA.COBOL.OPTIONS(DEV)

EMPRESA.COBOL.OPTIONS(TEST)

EMPRESA.COBOL.OPTIONS(PROD)

EMPRESA.COBOL.OPTIONS(DEBUG)

EMPRESA.COBOL.OPTIONS(MIGRATION)

Isso é muito mais elegante do que copiar e colar parâmetros em dezenas de PROCs.

🧠 Easter egg número 2: House odeia copy & paste

Se House fosse tech lead COBOL, provavelmente diria:

— Você copiou quarenta opções de compilação de um JCL de 2017 sem saber o que fazem?

— Sim.

— Então não temos um bug. Temos uma religião.

🚪 Porta 5 — `IGYCDOPT`

Agora chegamos ao porão do hospital.

Lugar onde iniciantes raramente entram.

O Enterprise COBOL possui defaults de instalação.

Um dos nomes importantes nesse universo é:

IGYCDOPT

É nele que a organização pode estabelecer defaults para o compilador.

Pense assim:

programador
   |
   v
programa COBOL
   |
   v
PROC/JCL
   |
   v
Enterprise COBOL
   |
   v
defaults da instalação

O IGYCDOPT permite que a instalação diga:

“Se ninguém especificar nada diferente, use isto.”

E certas opções podem ainda ser controladas de modo que não sejam livremente sobrescritas.

É aí que recomendação vira governança.

🏛️ Política versus preferência

Existe uma diferença gigante entre:

“Recomendamos usar esta opção.”

“A instalação está configurada desta maneira.”

Na primeira:

João usa.

Maria esquece.

Pedro usa outra PROC.

Carlos compila no pipeline antigo.

Na segunda:

a infraestrutura ajuda a garantir consistência.

Esse princípio aparece em tudo:

RACF
DevSecOps
Git
pipeline
quality gates
compiler defaults

Se algo é realmente importante, tente automatizar.

🧭 Mas quem ganha quando existem várias opções?

Excelente pergunta.

Imagine:

instalação:

NOMAP

JCL:

MAP

fonte:

CBL NOMAP

Qual vale?

Isso nos leva à:

⚔️ PRECEDÊNCIA DAS OPÇÕES

Você precisa entender que opções podem ser fornecidas por diferentes origens.

Conceitualmente:

INSTALLATION DEFAULTS
        ↓
INVOCATION / JCL
        ↓
PROCESS / CBL

mas existem particularidades, exceções e opções que podem ser fixadas pela instalação.

Então nunca faça debugging baseado apenas em:

“Eu tenho certeza de que a PROC usa MAP.”

Abra o listing.

Veja:

OPTIONS IN EFFECT

O compilador costuma informar quais opções efetivamente estavam ativas.

Essa seção vale ouro.

🔍 Regra Bellacosa número 1

Não pergunte qual opção estava no JCL. Pergunte qual opção estava em efeito.

Existe uma diferença brutal.

O JCL representa intenção.

O listing representa execução.

🧾 Leia o listing!

Aqui está talvez a maior dica deste artigo.

Programador iniciante pensa que o listing serve para:

achar erro de compilação

Programador intermediário usa para:

achar warning

Programador experiente usa o listing como:

documentação do programa compilado

Ele procura:

compiler version
compiler options
messages
data map
cross reference
code generation
statistics
source expansion

Você começa olhando um erro.

Termina entendendo como o compilador enxerga seu programa.

🩸 MAXCC=0 é apenas pressão arterial normal

Este merece moldura.

Você recebeu:

MAXCC=0

Parabéns.

Isso significa apenas que aquele job terminou com aquela condição.

Não significa:

lógica correta
layout correto
regra de negócio correta
performance boa
thread safety
dados corretos
segurança correta
arquivo correto
transação correta

House olha o monitor cardíaco.

Paciente vivo.

Ele não diz:

— Curado.

Ele pergunta:

— Por que ele desmaiou?

Faça o mesmo.

🔬 Passo a passo para investigar um `REDEFINES`

Encontrou:

REDEFINES

Faça isto.

Passo 1 — identifique a área original

Exemplo:

01 WS-ORIGINAL.
   05 A PIC X(10).
   05 B PIC X(10).

Calcule:

20 bytes

Passo 2 — identifique todas as redefinições

Pode existir mais de uma:

01 WS-TEXTO REDEFINES WS-ORIGINAL.
...

01 WS-NUMERICO REDEFINES WS-ORIGINAL.
...

01 WS-FLAGS REDEFINES WS-ORIGINAL.
...

Não pare na primeira.

Passo 3 — calcule os comprimentos

Faça isso cuidadosamente.

Principalmente se houver:

COMP
COMP-3
OCCURS
nested groups

Passo 4 — procure a intenção

Pergunte:

“Por que alguém criou este REDEFINES?”

Talvez seja:

header/body
mensagem de vários tipos
record type
layout de arquivo
estrutura histórica
flags
data
packed decimal
interface externa

Nem todo código estranho está errado.

Às vezes existe uma razão escrita em 1994.

Às vezes não.

🗿 Easter egg número 3: comentário de 1994

Você encontra:

*> NÃO ALTERAR ESTA ÁREA

Sem explicação.

Sem nome.

Sem ticket.

Sem documentação.

Naturalmente você pensa:

— Por quê?

A resposta está enterrada em uma fita magnética enviada para Iron Mountain durante o governo Itamar Franco.

Não altere.

🧪 Passo 5 — compile com `MAP`

Veja offsets.

Veja comprimentos.

Veja como o compilador efetivamente montou a área.

Nunca deixe a teoria vencer o mapa real.

🔍 Passo 6 — consulte o `XREF`

Descubra quem usa:

área original
área redefinida
campos individuais

Isso ajuda muito a entender o impacto.

🧬 Passo 7 — procure interfaces

Essa área vai para algum lugar?

WRITE
CALL
EXEC CICS LINK
EXEC CICS XCTL
EXEC CICS SEND
EXEC CICS RECEIVE
MQPUT
MQGET

Ou talvez:

arquivo VSAM
arquivo sequencial
Db2
IMS
socket
API
z/OS Connect

A área interna pode ter trinta bytes.

A interface externa pode esperar vinte.

Agora temos um problema de verdade.

💣 O pior cenário: contratos de dados

Imagine:

Programa A produz:

20 bytes

Programa B acredita que recebe:

30 bytes

Programa C possui um copybook antigo com:

24 bytes

Todos compilam.

Todos possuem:

MAXCC=0

House sorri.

— Finalmente um caso interessante.

Isso é exatamente o tipo de problema que aparece em ambientes legados.

O bug não está em um programa.

Está no contrato invisível entre programas.

🧠 Por isso copybook é tão importante

Copybooks não são apenas uma conveniência para evitar repetição.

Eles funcionam como contratos compartilhados de dados.

Quando bem utilizados:

Programa A ─┐
Programa B ─┼── COPY CUSTOMER
Programa C ─┘

todos enxergam a mesma definição.

Mas existe outro perigo:

versões diferentes do mesmo copybook

Programa A compilado ontem.

Programa B compilado seis anos atrás.

O dataset do copybook foi atualizado.

O módulo load de B continua com o layout antigo.

Agora você possui duas verdades.

Uma no fonte.

Outra no executável.

Bem-vindo novamente ao mainframe.

🔦 Static analysis: não espere um humano perceber

Aqui está uma excelente regra automática:

FOR EACH REDEFINES

compare
LENGTH(original)
with
LENGTH(redefinition)

Se:

normal.

Se:

<>

alerta.

Se:

redefinition > original

alerta forte.

Não porque todo caso seja necessariamente inválido.

Mas porque todo caso merece explicação.

Esse é o princípio de uma boa ferramenta estática:

destacar o que é incomum o bastante para merecer revisão humana.

🤖 Code review aumentado por IA

Aqui está uma aplicação interessante para IA em mainframe.

Imagine um pipeline lendo COBOL e produzindo:

WARNING COBOL-RD-001

WS-TRANSACTION-V2
redefines
WS-TRANSACTION

Original logical length: 128
Redefinition length: 136

Difference: +8 bytes

Review recommended.

Depois correlaciona com:

CALL USING
CICS COMMAREA
COPYBOOK
MQ
arquivo

Agora estamos usando IA não para substituir o programador.

Estamos usando IA para apontar:

“Ei, House. Esse exame aqui está estranho.”

🧯 Regra Bellacosa número 2

Nunca trate warning como decoração.

Compile listings antigos e você encontrará:

W
W
W
W
W
W
W

O programa está em produção há quinze anos.

Todo mundo diz:

— Sempre funcionou.

Essa é possivelmente uma das frases mais perigosas da informática.

🐸 “Sempre funcionou”

Uma aplicação COBOL antiga pode ter sobrevivido:

mudanças de hardware
mudanças de compilador
mudanças de sistema operacional
mudanças de middleware
novas versões de Db2
novas versões de CICS
mudanças de encoding
migrações
novos copybooks

Até que alguém recompila.

Então aparece:

“Funcionava antes.”

Talvez.

Talvez apenas estivesse dependendo de um comportamento antigo.

🧬 Compiler migration é medicina geriátrica

Migrar COBOL 4 para COBOL 6, por exemplo, não é simplesmente:

recompile

Você está trazendo código escrito sob determinadas hipóteses para outro ambiente.

Coisas que passaram despercebidas por décadas podem emergir.

Por isso opções de diagnóstico, listings, testes e análise estática são tão importantes.

🔐 Onde eu colocaria as opções?

Aqui entra arquitetura de engenharia.

Para um programa específico

Considere:

CBL
PROCESS

quando fizer sentido que aquela configuração acompanhe o fonte.

Para um projeto

Pode fazer sentido:

SYSOPTF
option file

Para toda a empresa

Pode fazer sentido usar:

defaults de instalação
IGYCDOPT

Para uma execução específica

Use:

PARM no JCL

Isso cria quatro níveis mentais:

PROGRAMA
PROJETO
PIPELINE
EMPRESA

Uma arquitetura muito melhor do que:

“coloca esse PARM aí e vê se funciona.”

🏗️ Um padrão de shop possível

Imagine:

           CORPORATIVO
              |
          IGYCDOPT
              |
     -------------------
     |                 |
  projeto A         projeto B
     |                 |
 SYSOPTF           SYSOPTF
     |                 |
   PROC              PROC
     |                 |
 programa           programa
 CBL/PROCESS        CBL/PROCESS

Agora você consegue controlar:

defaults
exceções
projetos
programas especiais

Isso é engenharia.

🚨 Não transforme opção de compilador em superstição

Outro erro comum:

“Fulano disse para usar SSRANGE.”

Então alguém coloca:

SSRANGE

sem saber o que ela faz.

Depois alguém copia.

Depois vira padrão.

Dez anos depois ninguém sabe por quê.

Toda opção de compilador deveria possuir pelo menos:

nome
objetivo
impacto
ambiente
quando usar
quando não usar

📚 Crie um catálogo corporativo

Algo simples:

OPTION: MAP

Uso:
Development / Migration

Objetivo:
Mostrar layout da Data Division.

Obrigatória:
DEV = SIM
PROD = opcional

Responsável:
Mainframe Engineering

Faça isso para:

MAP
XREF
SOURCE
SSRANGE
NUMCHECK
OPTIMIZE
ARCH
TEST
LIST
OFFSET

Seu eu do futuro agradecerá.

🧠 Easter egg número 4: Differential Diagnosis

Quando House recebe um paciente, a equipe lista hipóteses no quadro.

Faça exatamente isso no debugging.

Sintoma:

WS-VALOR contém lixo

Quadro:

REDEFINES?
MOVE?
SUBSCRIPT?
COMP-3?
COPYBOOK?
CALL?
FILE LAYOUT?
CICS?
STORAGE OVERWRITE?

Depois elimine hipóteses com evidência.

Isso é debugging profissional.

Não:

“Vou mudar isso aqui e rodar.”

🧪 O compilador é testemunha, não advogado

Ele lhe diz:

o que conseguiu compilar

Ele não garante:

o que você quis escrever

Essa distinção é central.

Um compilador pode aceitar código perfeitamente legal que implemente uma ideia completamente errada.

Exemplo:

MOVE WS-SALDO TO WS-CPF.

Talvez os campos sejam compatíveis.

O compilador não conhece sua regra de negócio.

Ele não sabe que você acabou de colocar saldo bancário dentro do CPF.

Ele apenas executa ordens.

🎯 Checklist Bellacosa para `REDEFINES`

Antes de aprovar qualquer REDEFINES, responda:

Se você respondeu “não” a cinco itens:

House acabou de pedir uma ressonância.

🩺 Uma pequena autópsia de exemplo

Considere:

       01 CUSTOMER-RECORD.
          05 CUSTOMER-ID       PIC X(10).
          05 CUSTOMER-NAME     PIC X(30).

       01 CUSTOMER-ALT
          REDEFINES CUSTOMER-RECORD.
          05 CUSTOMER-DATA     PIC X(48).

O programador vê:

CUSTOMER-RECORD = 40

CUSTOMER-ALT = 48

Primeira pergunta:

Por quê?

Talvez exista uma razão.

Talvez CUSTOMER-ALT represente uma versão futura.

Talvez alguém aumentou um campo.

Talvez um copybook tenha sido alterado pela metade.

Talvez seja simplesmente erro.

O ponto é:

a diferença precisa ser explicada.

🧬 Agora imagine produção

Esse registro é enviado:

CALL 'CUSTSRV'
    USING CUSTOMER-RECORD

O programa chamado possui:

LINKAGE SECTION.

01 LK-CUSTOMER PIC X(40).

Mas o chamador manipula uma visão de 48.

Você acabou de transformar uma curiosidade de DATA DIVISION em uma investigação de interface.

Por isso mainframe não é apenas sintaxe COBOL.

É ecossistema.

🚂 O programa nunca viaja sozinho

Todo COBOL real está conectado a alguma coisa:

JCL
PROCs
Db2
CICS
IMS
VSAM
MQ
sort
files
copybooks
subprograms
APIs
RACF
z/OS

Então todo problema de layout deve ser investigado no contexto do sistema.

Esse é um dos saltos mentais mais importantes para quem começa.

Você deixa de perguntar:

“Este programa está certo?”

e começa a perguntar:

“Este programa está correto dentro dos contratos do sistema?”

Isso é maturidade.

🎬 Easter egg final: “Everybody lies”

House possui uma frase famosa:

Everybody lies.

No mainframe eu adaptaria:

Everybody assumes.

O programador assume que o campo possui 20 bytes.

O analista assume que o copybook é o mesmo.

O operador assume que MAXCC=0 significa sucesso funcional.

O arquiteto assume que a PROC é padrão.

O desenvolvedor assume que MAP estava ativo.

O time assume que aquele load module foi recompilado.

E o mainframe?

O mainframe não assume nada.

Ele executa exatamente aquilo que foi definido.

☕ Conclusão — Aprenda a investigar, não apenas a compilar

REDEFINES parece um pequeno detalhe da DATA DIVISION.

Mas ele ensina uma lição gigantesca sobre COBOL.

Ensina que existe diferença entre:

fonte

layout efetivo

Entre:

intenção

compilação

Entre:

programa compilado

programa correto

Por isso, quando você encontrar um REDEFINES, não trate como uma palavra reservada qualquer.

Olhe o tamanho.

Olhe o mapa.

Olhe o listing.

Olhe o XREF.

Descubra quais opções de compilação estavam realmente ativas.

Saiba se vieram:

do JCL
do CBL
do PROCESS
do SYSOPTF
do option file
dos defaults da instalação

Entenda a precedência.

Conheça seu compilador.

E, principalmente, abandone uma das frases mais perigosas da profissão:

“O compilador aceitou.”

O compilador aceitar é apenas o começo da investigação.

A pergunta final continua sendo:

“O programa está fazendo exatamente aquilo que nós pensamos que ele está fazendo?”

House fecharia o prontuário.

O batch terminaria.

O café estaria frio.

E no SDSF apareceria:

MAXCC=0

Você sorriria.

Mas agora saberia que esse zero não é diagnóstico.

É apenas um sinal vital.

E programador COBOL bom não trata sinal vital.

Trata o sistema inteiro.

☕🦖

Bellacosa Mainframe — onde até um PIC X(20) pode esconder uma investigação médica, três copybooks esquecidos, duas PROCs corporativas e um comentário escrito antes de Java existir.

https://eljefemidnightlunch.blogspot.com/2022/07/alerta-vermelho-na-enterprise.html

https://eljefemidnightlunch.blogspot.com/2022/05/da-compilacao-execucao-de-um-programa.html

Translate

terça-feira, 10 de agosto de 2021