 |
| 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
REDEFINESrealmente 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:
A
ou outra etiqueta:
B
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:
REDEFINEScria 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:
20
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
NOLAXREDEFcomo 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.”
e:
“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:
Sei exatamente qual área está sendo redefinida.
Conheço o tamanho da área original.
Conheço o tamanho de cada redefinição.
Entendo por que a redefinição existe.
Conferi
COMP,COMP-3e outros USAGE.Verifiquei
OCCURS.Consultei o
MAP.Consultei referências com
XREF.Verifiquei copybooks relacionados.
Verifiquei interfaces externas.
Sei qual versão do compilador foi utilizada.
Conferi as opções efetivamente em uso.
Não estou confiando apenas em
MAXCC=0.
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
e:
layout efetivo
Entre:
intenção
e:
compilação
Entre:
programa compilado
e:
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
