Campos Binários: COMP, COMP-4 e COMP-5 — Qual é a Diferença?

Em um artigo anterior aqui no site, expliquei como funciona o campo COMP-3 (decimal compactado) e mostrei que ele não é nem binário nem ponto flutuante.

Logo, a pergunta natural é: e seu quiser criar um campo realmente binário em COBOL, como eu faço?

Na verdade, o COBOL possui dois tipos de campos binários que apresentam comportamentos diferentes, e entender a diferença entre eles é fundamental.

O Primeiro Tipo: BINARY, COMP ou COMP-4

Quando você declara uma variável assim:

01 WS-VALOR PIC S9(5) COMP.

Você está criando um campo binário. A cláusula BINARY, COMP, COMPUTATIONAL ou COMP-4 significam essencialmente a mesma coisa. Na prática, o que você mais verá em produção é COMP.

Como o tamanho é definido?

Aqui entra um ponto importante: no campo binário tradicional, o PIC funciona como fator de escala. Dependendo da quantidade de dígitos definidos na PIC, o compilador escolhe quantos bytes a variável irá ocupar:

Ou seja, o número de dígitos da picture determina o tamanho físico em memória.

Se o campo não for sinalizado, o valor máximo dobra, pois todos os bits ficam disponíveis para magnitude.

O Detalhe Que Muita Gente Não Percebe: Truncamento

Aqui está o detalhe importante. No COMP tradicional, a picture não serve apenas como fator de escala para definir o tamanho em bytes. Ele também funciona como critério de truncamento.

Por exemplo, se você tiver uma variável definida como:

01 WS-VALOR PIC S9(4) COMP.

Esse campo ocupa 2 bytes e poderia armazenar até 32.767. Mas se você mover o valor 32767 para ele, o dígito 3 à esquerda será truncado, exatamente como aconteceria com um campo numérico zonado. Isso acontece porque o compilador respeita o tamanho definido pela picture do campo.

E é aqui que entra o segundo tipo de campo binário.

O Segundo Tipo: COMP-5 (Binário Nativo)

Quando você declara:

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

Você está criando um binário nativo. Ele continua usando o PIC como fator de escala para definir o tamanho físico (2, 4 ou 8 bytes). Mas existe uma diferença fundamental: No COMP-5, a picture NÃO é usado como critério de truncamento.

Se o valor couber fisicamente no número de bytes alocados para a palavra (halfword, fullword ou doubleword), ele será armazenado integralmente — mesmo que ultrapasse o número de dígitos definidos na picture.

Essa característica faz com que o COMP-5 se comporte como um inteiro binário em linguagens como C ou Java.

Demonstração Prática

Em um teste simples, se você executar o programa abaixo:

identification division.
program-id. testacomp.

data division.
working-storage section.
01 vcomp pic s9(004) comp value zeros.
01 vcomp5 pic s9(004) comp-5 value zeros.

procedure division.

move 32767 to vcomp
display vcomp

move 32767 to vcomp5
display vcomp5

stop run.

O que você vai ver na tela (ou na sysout) é o seguinte:

[d0001 ~/cbl]$ testacomp
+2767
length 2
+32767
length 2

Então Por Que Não Usar Sempre COMP-5?

Porque existe um custo. O COMP-5 introduz um overhead de processamento ao programa, ao gerar código adicional para trabalhar com valores que ultrapassam o limite da picture.

Como no mainframe tudo é feito para obter performance máxima em todos os programas, a própria IBM recomenda que:

• COMP tradicional para programas que processam dados apenas dentro do mainframe
• COMP-5 em programas que interagem com subsistemas como DB2, CICS ou MQ, e/ou troquem dados com outras plataformas que precisam de compatibilidade binária exata

Existe ainda uma diretiva de compilação chamada TRUNC(BIN), que pode ser usada em quase todos os compiladores, e que instrui o compilador a gerar o programa tratando campos COMP como se fossem COMP-5, ou seja, sem truncamento baseado na picture.

Mas isso também pode gerar overhead. E, assim, o uso dessa diretiva também deve seguir as recomendações da IBM.

Conclusão

O COBOL tem dos tipos de campos binários, com comportamentos distintos.

A diferença parece sutil — mas pode impactar diretamente em integridade dos dados, compatibilidade entre sistemas, performance e  cstratégias de migração.

Entender esse detalhe nos ajuda a pensar na arquitetura do sistema, e não só na funcionalidade de cada programa.