Bellacosa Mainframe e as variaveis computacionais do COBOL 

☕💣🚀 COMP-1, COMP-2, COMP-3, COMP-4 e COMP-5 para o Programador COBOL Jr.

Uma das maiores fontes de confusão para quem começa em COBOL é entender por que existem tantos tipos numéricos.

A resposta está na história dos mainframes IBM.

Cada COMP surgiu para resolver um problema específico de armazenamento, desempenho ou precisão matemática. (IBM)

---

Linha do Tempo

Tipo	Surgiu
COMP	Década de 1960
COMP-1	Década de 1970
COMP-2	Década de 1970
COMP-3	Década de 1960
COMP-4	Década de 1970
COMP-5	Década de 1980

Os números exatos variam conforme compilador e plataforma, mas COMP-3 e COMP já existiam nos ambientes System/360. COMP-1, COMP-2 e COMP-4 apareceram como extensões IBM. COMP-5 surgiu posteriormente para resolver limitações do BINARY tradicional. (IBM)

---

Bellacosa Mainframe apresenta as variavis numericas do cobol comp

COMP-1

O que é

Ponto flutuante simples (single precision).

Ocupa:

• 4 bytes

Utilizado para:

• cálculos científicos

• engenharia

• estatística

Não deve ser usado para dinheiro. (IBM)

---

Exemplo

01 WS-TEMPERATURA COMP-1.

MOVE 23.75 TO WS-TEMPERATURA.

---

Vantagens

• rápido

• suporta expoentes

• ocupa pouco espaço

---

Desvantagens

• perde precisão decimal

• gera arredondamentos inesperados

---

Exemplo clássico

COMPUTE RESULT = 0.1 + 0.2

Resultado pode não ser exatamente:

0.300000

Isso acontece porque o valor é armazenado em binário.

---

COMP-2

O que é

Ponto flutuante duplo (double precision).

Ocupa:

• 8 bytes

Muito mais preciso que COMP-1. (IBM)

---

Exemplo

01 WS-PI COMP-2.

MOVE 3.14159265358979 TO WS-PI.

---

Vantagens

• enorme faixa de valores

• excelente precisão científica

---

Desvantagens

• mais lento

• ocupa mais memória

• inadequado para dinheiro

---

COMP-3

O Rei dos Bancos

Também chamado:

PACKED DECIMAL

ou

COMPUTATIONAL-3

É o formato mais amado pelos bancos. (IBM)

---

Como funciona

Cada byte armazena:

2 dígitos

mais um nibble de sinal.

---

Exemplo

01 SALDO PIC S9(7)V99 COMP-3.

Valor:

12345.67

Internamente:

12 34 56 7C

(C = positivo)

---

Vantagens

• extremamente compacto

• precisão decimal perfeita

• ideal para dinheiro

---

Desvantagens

• CPU precisa converter para cálculo

• não é legível em dump

---

Melhor uso

Contas correntes
Faturas
Cartões
Seguros
Folha de pagamento

---

COMP-4

O que é

Binário IBM.

Sinônimo de:

BINARY
COMP

na maioria dos compiladores IBM. (IBM)

---

Exemplo

01 CONTADOR PIC S9(4) COMP-4.

---

Tamanho

Dígitos	Bytes
1-4	2
5-9	4
10-18	8

(IBM)

---

Vantagens

• muito rápido

• ideal para índices

• excelente para contadores

---

Desvantagens

O comportamento depende do:

TRUNC(STD)
TRUNC(OPT)
TRUNC(BIN)

Isso já causou milhares de bugs em migrações COBOL. (IBM)

---

COMP-5

O que é

Binary Native.

Foi criado para eliminar limitações do COMP-4. (IBM)

---

Exemplo

01 WS-ID PIC S9(4) COMP-5.

---

Diferença Fundamental

Mesmo declarando:

PIC S9(4)

um COMP-5 de 2 bytes pode armazenar:

-32768
até
+32767

porque usa a capacidade real do campo binário. (IBM)

---

Vantagens

• mais rápido

• ideal para APIs

• ideal para CICS

• ideal para LE

• ideal para interoperabilidade com C

---

Desvantagens

• pode surpreender quem espera validação pelo PIC

• programas antigos podem comportar-se diferente

---

Comparação Geral

Característica	COMP-1	COMP-2	COMP-3	COMP-4	COMP-5
Tipo	Float	Float	Decimal	Binário	Binário Nativo
Bytes	4	8	Variável	2/4/8	2/4/8
Dinheiro	❌	❌	✅	⚠️	⚠️
Velocidade	Alta	Alta	Média	Muito Alta	Muito Alta
Precisão Decimal	Baixa	Média	Excelente	Boa	Boa
Interoperabilidade	Média	Média	Baixa	Média	Excelente

---

Opções de Compilação que Afetam Tudo

TRUNC

TRUNC(STD)
TRUNC(OPT)
TRUNC(BIN)

Principal responsável por diferenças em COMP e COMP-4. (IBM)

---

ARITH

ARITH(COMPAT)
ARITH(EXTEND)

Impacta precisão matemática.

Muito importante para:

COMP-3
COMPUTE
DIVIDE
MULTIPLY

---

NUMPROC

NUMPROC(PFD)
NUMPROC(MIG)
NUMPROC(NOPFD)

Afeta tratamento de sinais inválidos em COMP-3.

---

RULES(NOEVENPACK)

Detecta packed decimals com número par de dígitos, ajudando a otimizar COMP-3. (IBM)

---

Problemas Conhecidos

1. Dinheiro em COMP-1

Erro clássico.

01 SALDO COMP-1.

Nunca faça isso.

---

2. Migração COBOL V4 → V6

Mudanças em:

TRUNC
ARITH
OPTIMIZATION

geraram diferenças de resultados em milhares de aplicações. (IBM)

---

3. COMP-3 Corrompido

Dump:

12 34 5F

Sinal inválido.

Pode gerar:

S0C7

---

4. Overflow Silencioso

Muito comum em:

COMP
COMP-4

quando TRUNC(BIN) está ativo.

---

Easter Eggs e Curiosidades

1. O banco não gosta de FLOAT

Em muitos bancos você encontrará:

0 ocorrências de COMP-1
0 ocorrências de COMP-2

em milhões de linhas COBOL.

---

2. COMP-3 domina Wall Street

Grande parte dos sistemas financeiros de alto volume ainda utiliza COMP-3 para valores monetários devido à precisão decimal exata.

---

3. TRUNC(BIN) "transforma" COMP em COMP-5

Na prática, muitos comportamentos tornam-se equivalentes para operações binárias. (IBM)

---

4. Packed Decimal foi uma genialidade da IBM

Quando memória custava fortunas, armazenar dois dígitos por byte era uma enorme vantagem econômica.

---

Regra de Ouro para o Programador COBOL Jr.

Se estiver em dúvida:

Dinheiro      -> COMP-3
Contadores    -> COMP-5
Índices       -> COMP-5
Percentuais   -> COMP-3
Cálculos científicos -> COMP-2
Integração C/C++ -> COMP-5

Em ambientes modernos z/OS com Enterprise COBOL 6.x, a combinação mais comum e segura é:

COMP-3 para valores financeiros
COMP-5 para inteiros e contadores

Essa dupla cobre praticamente 95% das necessidades de aplicações corporativas em bancos, seguradoras e grandes empresas. (IBM)

☕ Um Café no Bellacosa Mainframe

Viagem ao Fundo do Mar dos Formatos Numéricos COBOL

Uma expedição pelas profundezas de COMP-1, COMP-2, COMP-3, COMP-4 e COMP-5, onde cada byte pode esconder uma criatura binária.

COMP-4 e COMP-5 sem Mistérios Abrir artigo ↗

SUPERFÍCIE

ABISMO BINÁRIO

⚓

Descendo aos arquivos do mainframe...

📡 Diário de Bordo do Programador Padawan

1

COMP-1

Ponto flutuante de precisão simples.

2

COMP-2

Ponto flutuante de precisão dupla.

3

COMP-3

Decimal compactado para valores exatos.

4

COMP-4

Binário influenciado pelo PICTURE e pelo TRUNC.

5

COMP-5

Binário nativo usando a capacidade física do campo.

🔗 Rotas permanentes da expedição

Consulte diretamente os artigos completos:

COMP-4 e COMP-5: formato binário, TRUNC e exemplos COBOL COMP-1, COMP-2, COMP-3, COMP-4 e COMP-5: guia completo

Aprenda como o COBOL armazena números em ponto flutuante, decimal compactado, binário e binário nativo. Compare tamanho, precisão, desempenho, PICTURE, TRUNC, uso em cálculos financeiros e interoperabilidade com outras linguagens.

EBCDIC: O Código que o Mundo Chama de Legado, Mas que Ainda Move Bilhões de Transações Todos os Dias

 

Bellacosa Mainframe iniciando no EBCDIC e cartão perfurado

☕ Um Café no Bellacosa Mainframe

EBCDIC: O Código que o Mundo Chama de Legado, Mas que Ainda Move Bilhões de Transações Todos os Dias

"Quem ri do EBCDIC normalmente nunca precisou garantir que um banco inteiro fechasse o balanço sem perder um único centavo."

Existe um momento na vida de praticamente todo programador que começa a trabalhar com Mainframe.

Você recebe um arquivo vindo do z/OS.

Abre no Notepad.

E aparece algo parecido com isto:

ÁêØ¢ËÑÇ@@@âÑÄÅ...

A primeira reação costuma ser:

"O arquivo está corrompido."

A segunda:

"Alguém esqueceu de salvar em UTF-8."

A terceira:

"Isso é tecnologia dos dinossauros."

Nenhuma delas está correta.

Na verdade, aquele arquivo está absolutamente perfeito.

O problema é que você está tentando ler um livro escrito em outro alfabeto.

Esse alfabeto chama-se EBCDIC (Extended Binary Coded Decimal Interchange Code).

E, apesar de muita gente tratá-lo como uma curiosidade histórica, ele continua presente nos maiores bancos, seguradoras, governos e companhias aéreas do planeta.

Hoje vamos tomar um café e desmistificar um dos assuntos mais mal compreendidos do universo IBM Z.

---

Bellacosa Mainframe apresenta o ebcdic

O maior mito sobre o EBCDIC

Pergunte para dez desenvolvedores que nunca trabalharam com Mainframe:

"Por que existe EBCDIC?"

As respostas costumam ser parecidas.

"Porque a IBM queria prender os clientes."

É uma boa história.

Mas é falsa.

Quando o EBCDIC nasceu, em 1963, praticamente ninguém utilizava ASCII.

Aliás...

Nem mesmo o ASCII era um padrão consolidado.

Cada fabricante possuía sua própria codificação.

Burroughs.

Honeywell.

CDC.

UNIVAC.

ICL.

Todos tinham soluções próprias.

A IBM simplesmente continuou evoluindo aquilo que ela já utilizava desde os computadores baseados em cartões perfurados.

Não era uma conspiração.

Era evolução tecnológica.

---

O mundo era completamente diferente

Hoje pensamos em computadores conectados pela Internet.

Em 1963...

Não havia Internet.

Não havia Wi-Fi.

Não havia APIs.

Não havia JSON.

Muito menos ChatGPT.

O computador era uma máquina corporativa.

Seu trabalho era processar:

• folhas de pagamento;

• contas bancárias;

• extratos;

• impostos;

• seguros;

• notas fiscais;

• cartões perfurados.

O objetivo não era conversar com outros computadores.

Era processar documentos com absoluta confiabilidade.

Essa diferença muda tudo.

---

ASCII nasceu para conversar

O ASCII descende do Código Baudot, criado para telegrafia.

Imagine um cabo atravessando centenas de quilômetros.

Cada bit enviado custava tempo.

Tempo custava dinheiro.

Por isso o ASCII foi pensado para transmissão serial.

Seu projeto privilegiava simplicidade eletrônica.

Existe uma curiosidade fantástica.

Observe:

A = 65
a = 97

A diferença entre as duas letras é praticamente um único bit.

Isso permitia que um circuito eletrônico transformasse letras maiúsculas em minúsculas simplesmente alterando um sinal elétrico.

Hoje parece detalhe.

Na época era genial.

---

Enquanto isso...

Na IBM...

O problema era outro.

Ela precisava representar cartões perfurados.

E aí entra um personagem quase esquecido da computação moderna.

---

Bellacosa Mainframe e a anatomia de um cartão perfurado

O cartão perfurado

Imagine uma folha de papel rígido.

Ela possui 80 colunas.

Cada coluna representa um caractere.

Cada coluna possui 12 posições possíveis para perfuração.

12
11
0
1
2
3
4
5
6
7
8
9

As três primeiras posições eram chamadas de Zona.

As demais eram os Dígitos.

Para escrever uma letra não bastava perfurar um único lugar.

Era necessário combinar uma zona com um dígito.

Por exemplo:

Zona 12 + Dígito 1 = A

Esse padrão tornou-se tão importante que a IBM decidiu preservá-lo quando criou o System/360.

---

O nascimento do EBCDIC

Em vez de inventar um alfabeto completamente novo...

A IBM fez algo extremamente inteligente.

Ela traduziu a lógica física do cartão diretamente para um byte.

Cada caractere passou a ocupar:

4 bits
+
4 bits

Ou seja:

Nibble superior
↓

Zona

Nibble inferior
↓

Dígito

É por isso que o EBCDIC parece "bagunçado".

Na verdade...

Ele apenas respeita a lógica física do cartão.

---

O famoso buraco entre I e J

Essa é uma das primeiras coisas que um curioso percebe.

No ASCII temos:

ABCDEFGHIJKLMN...

Tudo contínuo.

Já no EBCDIC acontece algo diferente.

As letras ficam divididas em blocos.

A até I

↓

salto

↓

J até R

↓

salto

↓

S até Z

Por quê?

Porque era exatamente assim que funcionava o cartão perfurado.

O que parece estranho hoje fazia todo sentido em 1964.

---

O EBCDIC não é uma tabela.

Ele é uma filosofia.

Essa talvez seja a maior diferença.

ASCII resolve um problema.

Representar caracteres.

O EBCDIC fazia parte de uma arquitetura inteira.

Quando a IBM lançou o System/360 ela criou uma plataforma capaz de durar décadas.

E conseguiu.

Hoje, mais de sessenta anos depois, conceitos daquela arquitetura continuam presentes no IBM Z.

Entre eles:

• canais de I/O;

• processamento batch;

• registros de tamanho fixo;

• decimal compactado;

• formatos de impressão;

• arquivos VSAM;

• e o EBCDIC.

Nada disso surgiu isoladamente.

Tudo fazia parte da mesma visão de engenharia.

---

"Então por que não mudar para UTF-8?"

Essa pergunta aparece em praticamente toda palestra.

A resposta curta é:

Porque não faz sentido.

Imagine um banco.

Ele possui cinquenta anos de software.

Bilhões de linhas em:

• COBOL;

• PL/I;

• Assembler.

Agora imagine alterar a representação interna dos caracteres.

O que precisaria ser testado?

Tudo.

Literalmente tudo.

Comparações.

Ordenações.

Relatórios.

Impressoras.

Interfaces.

Conversões.

Milhões de programas.

Décadas de auditoria.

Bilhões de registros históricos.

O custo seria gigantesco.

O benefício?

Praticamente nenhum.

---

O IBM Z odeia UTF-8?

Muito pelo contrário.

Esse é outro mito.

Hoje o IBM Z executa naturalmente:

• Java;

• Python;

• Node.js;

• Go;

• C/C++;

• OpenJDK;

• OpenSSH;

• Linux on Z;

• Docker;

• Kubernetes;

• APIs REST;

• GraphQL;

• OpenAPI.

Todos utilizando UTF-8.

O segredo está na arquitetura.

As aplicações modernas trabalham em UTF-8.

Os componentes tradicionais continuam utilizando EBCDIC.

Entre eles:

• COBOL;

• CICS;

• IMS;

• DB2;

• arquivos sequenciais.

No meio do caminho existem conversores.

Tudo acontece automaticamente.

Na maioria das vezes o desenvolvedor nem percebe.

---

Um exemplo simples

Imagine um aplicativo no celular.

Cliente

↓

API REST

↓

z/OS Connect

↓

COBOL

↓

DB2

O celular envia UTF-8.

O z/OS Connect converte.

O COBOL recebe EBCDIC.

Na volta acontece exatamente o contrário.

Para quem usa o aplicativo...

Nada muda.

---

Curiosidade nº 1

Existe apenas um EBCDIC?

Não.

Existem centenas.

São chamadas de Code Pages.

Algumas famosas:

• CP037

• CP500

• CP273

• CP1047

• CP1140

Cada uma adapta caracteres para determinados idiomas.

É parecido com as antigas páginas de código do Windows.

---

Curiosidade nº 2

Nem todo problema é "EBCDIC".

Muitas vezes o arquivo já está em EBCDIC.

Mas você está usando a página errada.

É como abrir um texto em português utilizando uma fonte chinesa.

Os bytes continuam corretos.

A interpretação é que muda.

---

Curiosidade nº 3

COBOL também depende do EBCDIC.

Quando você escreve:

IF CLIENTE-A > CLIENTE-B

Ou executa:

SORT

Existe uma sequência de classificação.

Essa sequência depende da codificação utilizada.

No Mainframe ela normalmente segue o EBCDIC.

Isso significa que uma ordenação feita no Windows pode produzir resultados diferentes daquela executada no z/OS.

---

Curiosidade nº 4

No ASCII:

9

↓

A

↓

a

No EBCDIC...

A ordem muda.

Esse pequeno detalhe já causou inúmeros bugs em integrações entre plataformas.

---

Curiosidade nº 5

Você provavelmente usa EBCDIC sem perceber.

Quando um banco expõe uma API REST.

Quando um PIX consulta uma conta.

Quando um cartão de crédito é autorizado.

Quando uma companhia aérea consulta uma reserva.

Quando um caixa eletrônico responde.

Existe uma enorme chance de existir um programa COBOL falando EBCDIC em algum lugar da infraestrutura.

---

Easter Egg para Padawans 🥚

Se você assistir ao filme Apollo 13, verá computadores IBM em operação.

Se visitar museus de computação encontrará cartões perfurados.

Se estudar a arquitetura do System/360 descobrirá que muitas decisões tomadas naquela época continuam influenciando os processadores IBM Z atuais.

É como encontrar fósseis vivos.

Só que ainda processando bilhões de dólares por dia.

---

Outro Easter Egg

O EBCDIC costuma ser chamado de "dinossauro".

Mas existe uma ironia divertida.

Grande parte das aplicações modernas utiliza JSON.

JSON é texto.

Texto precisa de codificação.

Sem um padrão de caracteres...

Nem mesmo APIs modernas existiriam.

No fim das contas...

Todo sistema continua dependendo de um "alfabeto".

A diferença é apenas qual deles.

---

Dicas para quem está começando no Mainframe

Nunca abra arquivos EBCDIC diretamente no Notepad.

Use ferramentas que suportem conversão.

---

Aprenda a diferença entre arquivo texto e arquivo binário.

Nem tudo pode ser convertido.

Campos COMP, COMP-3 e binários jamais devem ser tratados como texto.

---

Conheça sua Code Page.

CP037 não é igual à CP1047.

Esse detalhe salva horas de investigação.

---

Aprenda como funciona FTP ASCII e FTP Binary.

Uma configuração incorreta pode "corromper" um arquivo apenas durante a transferência.

Na verdade, o arquivo original continua íntegro.

---

Não tenha medo do EBCDIC.

Ele parece estranho apenas porque crescemos utilizando ASCII e UTF-8.

Depois de alguns dias convivendo com Mainframe ele se torna completamente natural.

---

O verdadeiro legado do EBCDIC

Existe uma frase famosa na engenharia:

"Se algo funciona perfeitamente há cinquenta anos, talvez exista uma boa razão para não mexer."

O EBCDIC sobreviveu não porque o mercado ficou parado.

Mas porque ele faz parte de uma arquitetura extremamente estável.

Enquanto tecnologias aparecem e desaparecem a cada cinco anos...

O IBM Z continua processando alguns dos sistemas mais críticos do planeta.

Não porque seja antigo.

Mas porque foi projetado para durar.

---

Um Café Antes de Ir...

O programador júnior normalmente olha para o EBCDIC e enxerga um problema.

O desenvolvedor experiente enxerga compatibilidade.

O arquiteto enxerga engenharia.

E o engenheiro de Mainframe enxerga algo ainda maior: uma decisão de projeto que atravessou gerações sem interromper negócios, preservando décadas de investimentos e garantindo que milhões de pessoas possam sacar dinheiro, comprar passagens, pagar contas e realizar transações todos os dias.

Da próxima vez que você abrir um arquivo EBCDIC e encontrar uma "sopa de caracteres", lembre-se: o arquivo não está errado. Apenas está falando a língua nativa de um dos ecossistemas computacionais mais robustos já construídos.

Porque, no fim das contas, o EBCDIC nunca foi um obstáculo ao futuro. Ele sempre foi a ponte silenciosa entre mais de 60 anos de história da computação e o IBM Z que continua sustentando o mundo digital de hoje.

E essa, meu colega Padawan, é uma das maiores lições que o Mainframe pode ensinar: boas arquiteturas envelhecem muito melhor do que modismos tecnológicos. ☕

COBOL : Muito Além do PIC S9(7)V99 COMP-3

 

Bellacosa Mainframe analisa as variaveis estilo cobol

☕ Um Café no Bellacosa Mainframe

Muito Além do PIC S9(7)V99 COMP-3

O Que Todo Programador COBOL Padawan Precisa Saber Sobre a Anatomia de uma Variável, Como o IBM Z Enxerga Seus Dados e Por Que Essa Sintaxe Continua Dominando o Mundo Financeiro

"Qual é a variável mais importante do COBOL?"

A maioria dos programadores iniciantes responde algo como:

"WS-NOME."

Ou talvez:

"WS-SALARIO."

Mas essa pergunta possui uma resposta muito mais interessante.

A variável mais importante do COBOL não é uma variável específica.

É o conceito por trás de todas elas.

Uma simples declaração como esta:

05 WS-MONTANTE PIC S9(7)V99 COMP-3.

parece pequena.

São apenas alguns caracteres.

Entretanto, essa única linha descreve muito mais informações do que praticamente qualquer linguagem moderna consegue expressar de forma tão compacta.

Ela informa ao compilador:

• onde o dado pertence;

• qual seu significado;

• como será armazenado;

• como será processado pela CPU;

• quanto espaço ocupará;

• se aceita números negativos;

• onde está a posição decimal;

• como será gravado em disco;

• como será enviado ao DB2;

• como participará das operações matemáticas.

Em outras palavras...

Ela descreve completamente a vida daquele dado.

Hoje vamos abrir essa declaração como um engenheiro desmonta um motor Rolls-Royce.

Pegue seu café.

Vamos viajar para dentro da memória do IBM Z.

---

Bellacosa Mainframe e a anatomia de uma variavel

COBOL pensa diferente

Quem vem de Java, Python, C# ou JavaScript costuma enxergar uma variável assim:

double salario;

ou

salario = 1500.50

Pronto.

Acabou.

Mas o COBOL nasceu em uma época completamente diferente.

Na década de 60 memória era absurdamente cara.

Processadores eram lentos.

Discos eram pequenos.

Cada byte economizado representava milhares de dólares.

Por isso o COBOL não pergunta apenas:

"Que tipo de variável é essa?"

Ele pergunta:

"Como exatamente esse dado existirá dentro do computador?"

Essa filosofia mudou toda a arquitetura da linguagem.

---

Primeiro elemento: o nível

05 WS-MONTANTE ...

O número 05 não possui absolutamente nenhuma relação com tamanho.

Ele representa hierarquia.

Imagine um organograma de uma empresa.

Empresa

    Financeiro

        Contabilidade

            Funcionários

O COBOL organiza dados exatamente assim.

Exemplo:

01 CLIENTE.

   05 DADOS-PESSOAIS.

      10 NOME.

      10 CPF.

   05 DADOS-FINANCEIROS.

      10 LIMITE.

      10 SALDO.

Visualmente:

CLIENTE
│
├── DADOS-PESSOAIS
│      ├── NOME
│      └── CPF
│
└── DADOS-FINANCEIROS
       ├── LIMITE
       └── SALDO

Percebe?

O COBOL constrói verdadeiras árvores de dados.

É uma linguagem extremamente orientada à estrutura.

Muito antes de XML.

Muito antes de JSON.

Muito antes de objetos.

---

O nome importa muito

Observe:

WS-MONTANTE

Isso não é apenas um identificador.

É documentação.

Durante décadas milhares de desenvolvedores trabalharam simultaneamente no mesmo sistema.

Ninguém tinha IDE colorida.

Não existia autocomplete.

Então surgiram convenções.

Por exemplo:

WS-

significa:

Working-Storage

Já:

LS-

é Local Storage.

LK-

Linkage.

SQL-

variáveis utilizadas pelo DB2.

DFH-

estruturas do CICS.

Quando você vê um nome começando por WS-, imediatamente sabe onde aquela variável foi declarada.

Isso aumenta muito a legibilidade.

---

O verdadeiro coração da declaração

Chegamos ao famoso:

PIC

PIC significa:

Picture

Muitos imaginam que ele define apenas o tamanho.

Não.

Ele descreve a forma como o dado será representado.

É quase um DNA.

Vamos ver alguns exemplos.

Texto:

PIC X(30)

Trinta caracteres.

Somente letras:

PIC A(20)

Numérico:

PIC 9(8)

Numérico com casas decimais:

PIC 9(7)V99

Editado para impressão:

PIC $$$,$$9.99

Cada Picture possui uma finalidade diferente.

---

O significado do "9"

Na nossa variável aparece:

9(7)

O nove significa:

um dígito decimal.

Logo:

9

aceita:

0 até 9

Enquanto

99

aceita

00 até 99

Já

9(7)

é apenas uma forma elegante de escrever:

9999999

Ou seja:

sete dígitos.

Nada mais.

Nada menos.

---

O misterioso S

Agora observe:

S9(7)

O "S" significa:

Signed.

Número com sinal.

Sem ele:

0
até

9999999

Com ele:

-9999999

até

+9999999

Mas aqui existe uma curiosidade interessante.

O sinal normalmente não ocupa um byte inteiro.

No formato COMP-3 ele é armazenado dentro do último nibble do número.

Uma solução extremamente elegante criada quando memória era um recurso precioso.

---

A genialidade da vírgula invisível

Agora chegamos ao personagem mais incompreendido do COBOL.

A letra:

V

A maioria dos iniciantes acredita que ela representa uma vírgula.

Na realidade...

Ela representa a posição lógica da vírgula.

A vírgula nunca é gravada.

Nunca.

Suponha:

PIC 9(5)V99

Na memória teremos:

1234567

Mas o COBOL interpreta como:

12345,67

Onde foi parar a vírgula?

Ela nunca existiu.

O compilador apenas sabe que, ao interpretar aquele número, deve considerar duas casas decimais.

Parece um detalhe.

Mas imagine milhões de registros.

Economizar um byte em cada registro significava reduzir discos inteiros.

---

A importância da precisão

Vamos comparar.

Python:

0.1 + 0.2

Resultado:

0.30000000000000004

Não é erro do Python.

É matemática binária.

Agora veja o COBOL usando Packed Decimal.

0.10

+

0.20

=

0.30

Sempre.

Sem aproximações.

Sem surpresas.

Sem arredondamentos inesperados.

É exatamente por isso que bancos utilizam COMP-3 há décadas.

Dinheiro exige precisão absoluta.

---

O que é COMP-3?

Agora chegamos ao astro da declaração.

COMP-3

Também conhecido como:

Packed Decimal.

BCD.

Decimal Empacotado.

Ao contrário do DISPLAY, onde cada dígito ocupa um byte inteiro, o COMP-3 armazena dois dígitos por byte.

Cada dígito utiliza apenas quatro bits.

Ou seja:

12

cabe em um único byte.

Muito mais eficiente.

---

Como o número fica na memória?

Suponha:

123456789

Em DISPLAY:

F1 F2 F3 F4 F5 F6 F7 F8 F9

Nove bytes.

No COMP-3:

12 34 56 78 9C

Cinco bytes.

O "C" representa positivo.

Se fosse negativo:

9D

Essa codificação ainda hoje é utilizada por praticamente todos os grandes bancos do planeta.

---

Quantos bytes essa variável ocupa?

Existe uma fórmula famosa.

(dígitos + 2) / 2

Arredondando para cima.

Nossa variável possui:

7

+

2

=

9 dígitos

Logo:

(9 + 2) / 2

=

5 bytes

Apenas cinco bytes.

---

Parece pouco?

Imagine um cadastro contendo:

300 milhões

de clientes.

Economizar quatro bytes por registro significa aproximadamente:

1,2 GB

Apenas em um campo.

Agora multiplique isso por centenas de campos.

Depois por milhares de tabelas.

Depois por backups.

Depois por replicações.

Agora você entende por que arquitetos de mainframe pensam diferente.

---

O compilador faz muito mais do que imaginamos

Quando escrevemos:

05 WS-MONTANTE PIC S9(7)V99 COMP-3.

Nós enxergamos apenas texto.

O compilador enxerga uma enorme quantidade de metadados.

Ele sabe:

✔ É numérico.

✔ É decimal.

✔ Possui sinal.

✔ Tem duas casas decimais.

✔ Ocupa cinco bytes.

✔ Pode participar de operações aritméticas.

✔ Será armazenado em Packed Decimal.

✔ É compatível com DECIMAL do DB2.

✔ Pode ser usado em comandos ADD, SUBTRACT, MULTIPLY e COMPUTE.

Tudo isso antes mesmo do programa começar a executar.

---

Por que DB2 gosta tanto de COMP-3?

Observe esta coluna SQL.

SALDO DECIMAL(9,2)

Em COBOL normalmente teremos:

PIC S9(7)V99 COMP-3

Os dois formatos representam exatamente o mesmo conceito.

Resultado?

Conversões mínimas.

Mais velocidade.

Menor consumo de CPU.

Menor custo operacional.

---

VSAM, IMS e CICS também entendem esse formato

Quando um programa COBOL grava um registro VSAM contendo COMP-3, os números são gravados exatamente nesse formato empacotado.

Quando outro programa COBOL lê esse registro, nenhuma conversão é necessária.

Tudo continua extremamente eficiente.

Por isso sistemas desenvolvidos há quarenta anos continuam rápidos até hoje.

---

O preço dessa eficiência

Existe um lado curioso.

Abra um arquivo contendo COMP-3 em um editor hexadecimal.

Você verá algo parecido com:

12 34 56 7C

Não parece um número.

Porque não é texto.

É uma representação física otimizada.

Por isso ferramentas modernas precisam converter esses bytes antes de exibi-los.

---

E quando falamos em APIs REST?

Hoje muitas aplicações COBOL conversam com Java, Python, Node.js e microsserviços.

Entretanto JSON não entende Packed Decimal.

Então ocorre uma conversão.

Internamente:

12 34 56 7C

Externamente:

{
  "saldo": 12345.67
}

É exatamente esse trabalho que tecnologias como IBM z/OS Connect, CICS Web Services e diversos frameworks de integração realizam.

Eles traduzem o universo do IBM Z para um formato compreendido pelas aplicações modernas, preservando a precisão decimal do COBOL.

---

Uma lição para o Programador Padawan

Talvez você esteja pensando:

"Tudo isso para declarar uma variável?"

Exatamente.

Essa é a beleza do COBOL.

Em linguagens modernas, muitas decisões ficam escondidas dentro da máquina virtual, do compilador ou da biblioteca de execução.

No COBOL, elas são explícitas.

O programador descreve com precisão quase cirúrgica como seus dados devem existir.

Essa filosofia nasceu da necessidade, mas transformou-se em uma das maiores virtudes da linguagem.

Não é por acaso que os maiores bancos, seguradoras, bolsas de valores e órgãos governamentais do mundo continuam confiando no IBM Z para processar trilhões de dólares diariamente.

Quando um PIX é liquidado, um cartão é autorizado, um financiamento é calculado ou uma aposentadoria é paga, há uma grande chance de que, em algum ponto dessa jornada, exista uma variável muito parecida com a nossa velha conhecida:

05 WS-MONTANTE PIC S9(7)V99 COMP-3.

Ela pode parecer simples.

Mas dentro dela vivem mais de seis décadas de engenharia, otimização, compatibilidade e confiabilidade.

E talvez essa seja a maior lição para todo Programador Padawan: no universo do Mainframe, uma linha de código raramente faz apenas uma coisa. Cada declaração carrega décadas de experiência acumulada, decisões arquiteturais cuidadosamente pensadas e um compromisso absoluto com precisão, desempenho e estabilidade. Aprender a "ler" uma variável COBOL é aprender a enxergar a lógica invisível que sustenta alguns dos sistemas mais críticos do planeta. Quando você dominar essa linguagem dos dados, deixará de apenas escrever programas e passará a compreender como o IBM Z realmente pensa.

O Mistério das Variáveis COMP e BINARY Quando Sherlock Holmes Descobre que o Verdadeiro Crime Nunca Foi o Código COBOL..

 

Bellacosa Mainframe e o cobol variaveis bynary e comp

☕ Um Café no Bellacosa Mainframe

O Mistério das Variáveis COMP e BINARY

Quando Sherlock Holmes Descobre que o Verdadeiro Crime Nunca Foi o Código COBOL... Foi Confundir Como os Números São Guardados na Memória

"Meu caro Watson... você observa um número. Eu observo como ele ocupa a memória."
— Sherlock Holmes, se tivesse trabalhado na IBM.

---

Introdução

Existem mistérios que desafiaram a humanidade durante séculos.

Quem foi Jack, o Estripador?

Onde está o Santo Graal?

Como Stonehenge foi construído?

Mas existe um enigma ainda mais intrigante para quem começa a programar em COBOL no IBM Mainframe.

Qual é a diferença entre COMP e BINARY?

À primeira vista parecem duas tecnologias diferentes.

Alguns livros usam COMP.

Outros usam BINARY.

Alguns dizem que um é antigo.

Outros afirmam que são iguais.

Há quem diga que COMP é mais rápido.

Há quem jure que BINARY é moderno.

Sherlock Holmes sorriria.

Porque esse é exatamente o tipo de caso onde as pistas estão todas espalhadas diante de nossos olhos.

Hoje vamos investigar este crime tecnológico.

Coloque seu chapéu de detetive.

Pegue sua lupa.

E venha até a Baker Street do IBM Z.

O jogo começou.

---

Capítulo 1 — A Cena do Crime

Watson chega ao laboratório.

Sobre a mesa existe um programa COBOL.

01 WS-IDADE PIC S9(4) COMP.

Ao lado existe outro.

01 WS-IDADE PIC S9(4) BINARY.

Watson pergunta:

— Holmes... qual deles é o correto?

Holmes acende o cachimbo.

Sorri.

E responde:

— Ambos.

Watson arregala os olhos.

— Como assim?

Holmes responde:

— Porque o verdadeiro mistério não está no nome.

Está na memória.

---

Capítulo 2 — O Primeiro Suspeito: DISPLAY

Antes de entender COMP precisamos compreender DISPLAY.

Imagine o número

12345

Quando declaramos

01 WS-NUMERO PIC 9(5).

o COBOL guarda exatamente cinco caracteres.

Na memória temos algo semelhante a:

+---+---+---+---+---+
| 1 | 2 | 3 | 4 | 5 |
+---+---+---+---+---+

Em hexadecimal:

F1 F2 F3 F4 F5

Cada dígito ocupa um byte.

É extremamente fácil de visualizar.

Mas existe um problema.

O processador IBM Z não faz contas com caracteres.

Ele faz contas com números binários.

Toda vez que executamos

ADD 1 TO WS-NUMERO

o compilador precisa:

1. Ler caracteres.

2. Converter para binário.

3. Somar.

4. Converter novamente.

5. Escrever caracteres.

Sherlock olha para Watson.

— Muito trabalho para adicionar apenas um.

---

Capítulo 3 — O Verdadeiro Assassino: Conversão

Esse é o verdadeiro culpado.

Não é a instrução ADD.

Não é o compilador.

Não é o COBOL.

O culpado é a conversão.

Imagine fazer milhões de conversões por segundo.

Agora imagine um banco processando:

• cartões

• PIX

• TED

• boletos

• empréstimos

• seguros

• previdência

Tudo ao mesmo tempo.

Cada conversão custa CPU.

CPU custa dinheiro.

Holmes fecha o caderno.

— Encontramos o motivo.

Agora falta descobrir a solução.

---

Capítulo 4 — Surge o BINARY

Ao invés de guardar

1
2
3

o computador resolve guardar

1111011

que é

123 decimal

Não existem caracteres.

Existe apenas o número.

O processador entende isso imediatamente.

Sem tradução.

Sem conversão.

Sem intermediários.

É exatamente isso que faz

USAGE BINARY

---

Capítulo 5 — E onde entra o COMP?

Watson encontra outra pista.

Um programa de 1987.

PIC S9(9) COMP.

Outro de 1994.

PIC S9(9) COMP.

Outro de 2026.

PIC S9(9) BINARY.

Holmes sorri.

— Encontramos nosso suspeito favorito.

COMP.

---

Capítulo 6 — A Revelação

Nos primórdios do COBOL, cada fabricante possuía suas próprias extensões.

IBM utilizava

COMP

Outros fabricantes preferiam

BINARY

Com o passar das décadas a IBM resolveu tornar o nome mais explícito.

Assim nasceu oficialmente

USAGE BINARY

Mas para preservar bilhões de linhas existentes...

COMP permaneceu funcionando.

Sherlock fecha a investigação.

COMP e BINARY.

Mesmo armazenamento.

Mesmo código gerado.

Mesmo desempenho.

Nomes diferentes.

Mesmo suspeito.

---

Capítulo 7 — A Anatomia do Binário

Vamos abrir o corpo...

...do número.

Suponha

PIC S9(4) COMP.

O valor

123

vira

00000000 01111011

São apenas dois bytes.

Enquanto DISPLAY precisava de quatro caracteres...

COMP usa somente dois bytes.

Economia de memória.

Economia de CPU.

Maior velocidade.

---

Capítulo 8 — Quantos Bytes?

Sherlock desenha na lousa.

Declaração	Bytes
S9(1) até S9(4)	2
S9(5) até S9(9)	4
S9(10) até S9(18)	8

Curiosamente...

Mesmo que o número seja

1

um

PIC S9(18) COMP

continuará ocupando oito bytes.

Porque o espaço é reservado pelo tipo.

Não pelo conteúdo.

---

Capítulo 9 — O Cofre do Banco

Imagine um enorme banco.

Existem três cofres.

Primeiro cofre

DISPLAY.

Guarda tudo escrito.

Fácil de ler.

Difícil de calcular.

---

Segundo cofre

BINARY.

Guarda apenas números.

Perfeito para matemática.

---

Terceiro cofre

COMP-3.

Guarda cada dígito decimal exatamente.

Ideal para dinheiro.

Sherlock bate na mesa.

— Nunca misture os cofres.

---

Capítulo 10 — O Caso dos Centavos Perdidos

Suponha

19,99

Será que cabe perfeitamente em binário?

Não.

Assim como

1/3

não cabe exatamente em decimal.

Algumas frações decimais não possuem representação binária exata.

Por isso bancos usam

PIC S9(9)V99 COMP-3

Cada centavo é preservado.

Nenhum arredondamento inesperado.

Nenhum processo judicial.

Nenhum gerente desesperado.

---

Capítulo 11 — Quando Usar COMP?

Sherlock entrega uma lista.

✔ Contadores

✔ Loops

✔ Índices

✔ Número de registros

✔ Totalizadores inteiros

✔ Controle interno

✔ Sequenciadores

✔ Flags numéricas

✔ Códigos internos

✔ Chaves temporárias

---

Capítulo 12 — Quando NÃO Usar

Nunca para:

• salários

• juros

• impostos

• aplicações financeiras

• câmbio

• contas bancárias

Nesses casos...

COMP-3 reina absoluto.

---

Capítulo 13 — Um Passeio pela CPU do IBM Z

Quando o compilador encontra

ADD WS-A TO WS-B

com ambos em COMP/BINARY, ele pode gerar instruções nativas da arquitetura z/Architecture, como:

• AH (Add Halfword)

• A (Add)

• AG (Add Grande)

• AGR (Add Grande em Registrador)

O processador trabalha diretamente com inteiros binários.

É como entregar a Sherlock uma pista já traduzida.

Sem precisar chamar um intérprete.

---

Capítulo 14 — O Segredo que Quase Ninguém Conta

Existe uma razão histórica para encontrarmos milhões de variáveis COMP em sistemas bancários.

Durante décadas, praticamente toda a documentação IBM utilizava COMP.

Mesmo quando BINARY passou a existir, ninguém reescreveu bilhões de linhas de código.

Resultado?

Hoje encontramos programas escritos em 1985 que compilam sem qualquer alteração em um IBM z17.

Essa é uma das maiores demonstrações da retrocompatibilidade do ecossistema IBM.

Enquanto outras plataformas obrigam reescritas completas, o Mainframe preserva investimentos de décadas.

Esse talvez seja o maior "superpoder" do IBM Z.

---

Capítulo 15 — E o Misterioso COMP-5?

Watson acredita que o caso terminou.

Holmes sorri novamente.

— Ainda existe outro personagem.

COMP-5.

Ele também utiliza armazenamento binário.

Mas, diferentemente de COMP/BINARY, segue mais de perto a representação inteira nativa da máquina, sendo muito usado em interfaces de baixo nível, chamadas de sistema, APIs, rotinas em C e integrações específicas no z/OS.

Não substitui COMP.

É uma ferramenta especializada.

Mais um suspeito inocentado.

---

Capítulo 16 — Passo a Passo para Escolher o Tipo Correto

Imagine que você está criando uma variável. Faça estas perguntas:

1. É texto?

• Use PIC X(...).

2. É um número apenas para exibição ou entrada do usuário?

• Use DISPLAY (padrão).

3. É um contador, índice ou acumulador inteiro?

• Use COMP ou BINARY.

4. Representa dinheiro, impostos, juros ou valores decimais exatos?

• Use COMP-3.

5. Vai interoperar diretamente com APIs de baixo nível ou código em C?

• Avalie COMP-5.

Seguindo esse roteiro, a chance de errar diminui drasticamente.

---

Curiosidades de Baker Street

Curiosidade 1

A maioria dos iniciantes acredita que COMP significa "Compact".

Na verdade, historicamente o nome está associado à ideia de Computational, indicando um formato otimizado para processamento interno.

---

Curiosidade 2

Milhões de programas COBOL escritos nas décadas de 1970 e 1980 ainda utilizam exclusivamente COMP.

---

Curiosidade 3

Você pode passar anos trabalhando em Mainframe sem nunca encontrar uma variável declarada explicitamente como BINARY, embora ela esteja sendo usada o tempo todo sob o nome COMP.

---

Curiosidade 4

Em dumps de memória (CEEDUMP, IPCS ou Abend-AID), reconhecer rapidamente um campo COMP pode acelerar muito a identificação de corrupção de dados e problemas de alinhamento.

---

Easter Eggs Bellacosa Mainframe 🕵️

🔎 221B Baker Street = SYS1.PROCLIB
É dali que começam muitas investigações importantes.

🔎 Dr. Watson = Programador Júnior
Sempre faz a pergunta certa, mesmo sem perceber.

🔎 Sherlock Holmes = Analista de Performance
Enxerga conversões de dados onde ninguém mais vê.

🔎 Professor Moriarty = CPU em 99%
O verdadeiro vilão pode estar escondido em milhões de conversões desnecessárias entre DISPLAY e BINARY.

🔎 Scotland Yard = Operação do CPD
Chega quando o incidente já aconteceu.

🔎 A lupa de Holmes = IPCS, Abend-AID, Fault Analyzer e SMF
Ferramentas que revelam pistas invisíveis ao olho comum.

---

Conclusão — O Caso Está Encerrado

Sherlock fecha o dossiê.

Watson observa as anotações.

A resposta era muito mais simples do que parecia.

COMP e BINARY não são rivais.

São duas faces da mesma moeda no Enterprise COBOL para IBM Z.

O verdadeiro aprendizado não é decorar palavras-chave, mas compreender como os dados vivem na memória. É essa compreensão que diferencia quem apenas escreve programas de quem realmente entende a plataforma.

Da próxima vez que você encontrar:

01 WS-CONTADOR PIC S9(9) COMP.

não enxergue apenas uma declaração.

Veja décadas de história da computação corporativa, bilhões de linhas de código preservadas, a elegância da retrocompatibilidade da IBM e um processador IBM Z executando operações binárias com precisão quase cirúrgica.

Porque, assim como Sherlock Holmes nunca resolvia um caso olhando apenas para o suspeito, um grande programador COBOL nunca olha apenas para a variável.

Ele observa o que está escondido por trás dela.

E é justamente ali, na memória, que mora o verdadeiro mistério.

O Grande Mistério da Memória

                 DADO COBOL
                     │
     ┌───────────────┼───────────────┐
     │               │               │
 DISPLAY         BINARY/COMP      COMP-3
     │               │               │
 Texto          Inteiro Binário   Decimal Empacotado

---

1) DISPLAY

Como o ser humano enxerga

Número:

12345

Na memória

+----+----+----+----+----+
| F1 | F2 | F3 | F4 | F5 |
+----+----+----+----+----+

ou

+---+---+---+---+---+
| 1 | 2 | 3 | 4 | 5 |
+---+---+---+---+---+

Cada caractere ocupa

1 BYTE

Total

5 BYTES

✔ Fácil leitura

✔ Fácil gravação em arquivos texto

❌ CPU precisa converter para fazer contas

---

2) COMP / BINARY

Número

12345

Decimal

12345

Binário

00110000 00111001

Na memória

+--------+--------+--------+--------+
|             12345                |
+--------+--------+--------+--------+

ou

00003039 (HEX)

Ocupa

4 BYTES

✔ Processador calcula diretamente

✔ Muito rápido

✔ Excelente para loops

✔ Excelente para contadores

---

Comparação Visual

DISPLAY

┌─┬─┬─┬─┬─┐
│1│2│3│4│5│
└─┴─┴─┴─┴─┘

COMP

┌─────────────────┐
│00003039 (HEX)   │
└─────────────────┘

Mesmo número.

Representações totalmente diferentes.

---

3) COMP-3 (Packed Decimal)

Número

12345

Na memória

+----+----+----+
|12|34|5C|
+----+----+----+

Cada byte guarda

2 dígitos

O último nibble

C

indica

positivo

Se negativo

D

Exemplo

12345

↓

12 34 5C

Ocupa

3 BYTES

---

Exemplo Financeiro

R$ 1523,87

COMP-3

152387C

Nenhum centavo perdido.

Nenhum arredondamento.

Precisão decimal absoluta.

---

4) COMP-5

Visualmente

COMP

┌────────────────┐
│ Inteiro Binário│
└────────────────┘

COMP-5

┌──────────────────────────────┐
│ Inteiro Nativo da Arquitetura│
└──────────────────────────────┘

Muito usado em

✔ APIs

✔ C

✔ LE

✔ Chamadas de Sistema

✔ Integração

---

Comparativo Geral

                 DISPLAY
                     │
        Fácil leitura humana
                     │
          Conversão obrigatória
                     │
             Mais CPU utilizada

↓

              COMP/BINARY
                     │
         Número em Binário
                     │
        CPU calcula diretamente
                     │
             Muito rápido

↓

                COMP-3
                     │
      Decimal Exato
                     │
      Ideal para dinheiro

↓

                 COMP-5
                     │
     Binário da Arquitetura
                     │
      APIs e Baixo Nível

---

Quantidade de Bytes

Declaração	DISPLAY	COMP	COMP-3
S9(4)	4	2	3
S9(9)	9	4	5
S9(18)	18	8	10

---

Velocidade

DISPLAY

READ

↓

Converter

↓

Somar

↓

Converter

↓

WRITE

CPU

██████████████████

---

COMP

READ

↓

SOMAR

↓

WRITE

CPU

██████

---

Quando usar?

DISPLAY

✔ Relatórios

✔ Tela

✔ Arquivos TXT

✔ Entrada do usuário

---

COMP/BINARY

✔ Contadores

✔ Índices

✔ Loops

✔ Acumuladores

✔ Controle interno

---

COMP-3

✔ Salário

✔ Juros

✔ PIX

✔ TED

✔ Bancos

✔ Impostos

✔ Contabilidade

---

COMP-5

✔ APIs

✔ DLL

✔ C

✔ LE

✔ z/OS

✔ Chamadas internas

---

Exemplo Real

01 WS-NOME        PIC X(30).
01 WS-IDADE       PIC S9(4) COMP.
01 WS-CONTADOR    PIC S9(9) BINARY.
01 WS-SALARIO     PIC S9(9)V99 COMP-3.
01 WS-API-CODE    PIC S9(9) COMP-5.

---

Fluxo da CPU IBM Z

               Programa COBOL
                     │
                     ▼
             Enterprise COBOL
                     │
                     ▼
        Instruções z/Architecture
                     │
     ┌───────────────┼───────────────┐
     ▼               ▼               ▼
 DISPLAY         COMP/BINARY      COMP-3
 Conversão      Soma Direta      Decimal Exato
     │               │               │
     └───────────────┴───────────────┘
                     ▼
                 Resultado

---

Regra de Ouro

É TEXTO?

↓

DISPLAY

É CONTADOR?

↓

COMP ou BINARY

É DINHEIRO?

↓

COMP-3

É API?

↓

COMP-5

---

Bellacosa Mainframe — Dica do Detetive 🕵️

Sherlock Holmes olharia para uma variável e perguntaria: "Como ela é armazenada?" Antes mesmo de perguntar "Qual é o seu valor?".

No universo do IBM Mainframe, o segredo da performance não está apenas no algoritmo, mas na escolha correta do formato de armazenamento. Saber quando usar DISPLAY, COMP/BINARY, COMP-3 ou COMP-5 é uma habilidade que diferencia um programador COBOL iniciante de um verdadeiro especialista em IBM Z.