Translate

quinta-feira, 29 de maio de 2025

COMP-4 e COMP-5 : Quando um Programador Cobol Padawan Descobre que um Número Pode Parecer Pequeno no PICTURE... Mas Ocupar um Universo Inteiro de Bits nos Bastidores

Bellacosa Mainframe apresenta o comp-4 e comp-5 no cobol

☕ Um Café no Bellacosa Mainframe

COMP-4 e COMP-5 sem Mistérios para Programadores COBOL

Quando um Programador Padawan Descobre que um Número Pode Parecer Pequeno no PICTURE... Mas Ocupar um Universo Inteiro de Bits nos Bastidores

Existe um momento inevitável na formação de todo programador COBOL.

Ele aprende PIC 9(5), entende COMP-3, consegue ler um arquivo sequencial sem provocar um SOC7 e começa a acreditar que finalmente domina o reino numérico do mainframe.

Então aparece isto:

05 WS-CONTADOR       PIC S9(9) COMP-4.
05 WS-CODIGO-RETORNO PIC S9(4) COMP-5.

O padawan olha para a tela verde e pergunta:

— Mestre, qual é a diferença entre COMP-4 e COMP-5?

O mestre COBOL respira fundo, olha para o teto do data center e responde:

— A diferença está em quem manda no número: o PICTURE ou o recipiente binário.

E desaparece misteriosamente para uma reunião de mudança emergencial.

Neste artigo, entraremos no interior dessas duas representações numéricas, entenderemos sua origem, formato interno, funcionamento, vantagens, riscos, opções de compilação e usos práticos. Também veremos por que dois campos aparentemente iguais podem reagir de maneira diferente ao receber o mesmo valor.


Bellacosa Mainframe e uma visão sobre numericos comp

1. Antes de tudo: o que significa COMP?

Em COBOL, a cláusula USAGE informa como um dado será representado internamente na memória.

Quando declaramos:

05 WS-IDADE PIC 9(3).

o uso padrão normalmente é DISPLAY. Isso significa que cada dígito é armazenado como um caractere.

O valor 123, em ambiente EBCDIC, poderá ocupar três bytes:

F1 F2 F3

Cada byte representa um caractere numérico.

Porém, computadores não realizam sua aritmética interna pensando em caracteres. O processador trabalha com bits, palavras, registradores e representações binárias.

As formas COMP, abreviação de COMPUTATIONAL, foram criadas justamente para permitir representações internas mais apropriadas ao processamento.

No universo IBM COBOL, encontramos tradicionalmente:

COMP ou COMP-4  = binário
COMP-1          = ponto flutuante de precisão simples
COMP-2          = ponto flutuante de precisão dupla
COMP-3          = decimal compactado
COMP-5          = binário nativo

No Enterprise COBOL para z/OS, BINARY, COMP e COMP-4 são sinônimos. Já COMP-5 representa o chamado native binary, ou binário nativo. (IBM)

Essa semelhança entre COMP-4 e COMP-5 é precisamente a origem de boa parte da confusão.

Ambos guardam números em formato binário.

Ambos podem ocupar 2, 4 ou 8 bytes.

Ambos podem ser usados em cálculos rápidos.

Mas eles não obedecem exatamente às mesmas regras de capacidade e truncamento.


Bellacosa Mainframe comp-4 versus comp-5

2. O que é COMP-4?

COMP-4, também escrito como COMPUTATIONAL-4, é sinônimo de BINARY no COBOL da IBM.

Estas declarações têm essencialmente o mesmo significado:

05 WS-VALOR PIC S9(9) BINARY.
05 WS-VALOR PIC S9(9) COMP.
05 WS-VALOR PIC S9(9) COMP-4.

No z/OS, os dados binários são armazenados em complemento de dois, com organização big-endian. O bit de sinal operacional fica associado ao lado mais significativo da representação. (IBM)

O tamanho físico do campo depende da quantidade de dígitos declarada no PICTURE:

Dígitos no PICTURETamanho
1 a 42 bytes
5 a 94 bytes
10 a 188 bytes

Portanto:

05 WS-A PIC S9(4) COMP-4.

ocupa 2 bytes.

05 WS-B PIC S9(9) COMP-4.

ocupa 4 bytes.

05 WS-C PIC S9(18) COMP-4.

ocupa 8 bytes. (IBM)

2.1 A grande característica do COMP-4

Embora o campo seja armazenado em binário, a cláusula PICTURE continua participando de sua semântica COBOL.

Veja:

05 WS-NUMERO PIC 9(4) COMP-4.

Fisicamente, o compilador reserva 2 bytes.

Dois bytes sem sinal poderiam representar valores de:

0 até 65535

Entretanto, o PICTURE 9(4) descreve formalmente um número de quatro dígitos:

0 até 9999

Aqui começa o drama.

O recipiente físico possui capacidade maior que a capacidade decimal descrita no PICTURE.

O que acontece quando tentamos armazenar 12345?

A resposta depende da operação realizada e, principalmente, da opção de compilação TRUNC.

É por isso que COMP-4 não deve ser entendido apenas como “um inteiro de 16 bits”. Ele é um item binário COBOL cujo comportamento também pode ser influenciado pela descrição decimal do PICTURE.


3. O que é COMP-5?

COMP-5 é o formato chamado pela IBM de native binary.

Exemplo:

05 WS-RETORNO PIC S9(4) COMP-5.

Fisicamente, esse campo também ocupa 2 bytes.

A diferença fundamental é que um item COMP-5 pode utilizar toda a capacidade de seu recipiente binário, em vez de ficar limitado à magnitude sugerida pela quantidade de noves do PICTURE.

A documentação da IBM explica que os itens COMP-5 podem armazenar valores até a capacidade da representação nativa de 2, 4 ou 8 bytes. Quando um valor é movido para um COMP-5, o truncamento ocorre conforme o tamanho físico binário, e não conforme o limite decimal indicado pelo PICTURE. (IBM)

Considere:

05 WS-NUMERO PIC 9(4) COMP-5.

O PICTURE tem quatro noves, mas o campo ocupa 2 bytes sem sinal.

Assim, sua capacidade binária é:

0 até 65535

E não apenas:

0 até 9999

Para um campo com sinal:

05 WS-NUMERO PIC S9(4) COMP-5.

os 2 bytes em complemento de dois permitem:

-32768 até +32767

O campo tornou-se, na prática, um inteiro binário de 16 bits.

O PICTURE ainda existe e continua sendo importante para regras sintáticas, edição, escalas decimais e operações COBOL, mas ele não limita a magnitude armazenável da mesma forma que ocorre com um binário comum submetido às regras tradicionais de truncamento.


4. A diferença em uma frase

Podemos resumir assim:

COMP-4 é um campo binário que normalmente respeita a semântica decimal definida pelo PICTURE; COMP-5 é um campo binário que utiliza a capacidade física inteira de seus 2, 4 ou 8 bytes.

Ou, no dialeto Bellacosa Mainframe:

No COMP-4, o gerente funcional chamado PICTURE ainda tenta controlar o orçamento. No COMP-5, o hardware assume a operação e utiliza todos os bits disponíveis.


5. Origem e história

O uso de representações computacionais acompanha o COBOL há décadas. Termos como COMPUTATIONAL, COMP-1, COMP-2, COMP-3 e COMP-4 surgiram em implementações históricas para representar dados em formatos adequados às arquiteturas dos computadores.

COMP-4 consolidou-se no COBOL IBM como sinônimo de BINARY.

COMP-5 surgiu posteriormente no COBOL de host IBM como uma forma explícita de representar um inteiro binário nativo, especialmente útil em interoperabilidade, interfaces de sistema e situações em que a capacidade completa da palavra binária deveria ser preservada.

A documentação de migração da IBM identifica COMP-5 como um tipo que foi novo no COBOL de host e as tabelas de palavras reservadas mostram COMP-5 e COMPUTATIONAL-5 como palavras reservadas a partir do COBOL for OS/390 & VM Version 2 Release 2, produto disponibilizado em 2000. (IBM)

Isso não significa que o conceito de inteiro nativo tenha nascido no ano 2000. Sistemas, linguagens e APIs já trabalhavam com inteiros binários muito antes disso.

O que aconteceu foi a formalização de uma maneira específica e explícita de declarar esse comportamento no COBOL de host IBM.

Antes disso, programadores dependiam mais fortemente de opções como NOTRUNC, comportamentos particulares de compiladores antigos ou convenções locais. Na migração para compiladores modernos, esses detalhes tornaram-se perigosos, pois códigos antigos às vezes armazenavam no campo binário valores maiores do que o PICTURE aparentemente permitia.

COMP-5 oferece uma declaração mais clara:

— Este campo não é apenas um número COBOL com representação binária. Ele é um recipiente binário nativo, e todos os seus bits importam.


6. Formato interno

6.1 Complemento de dois

Campos binários com sinal usam normalmente complemento de dois.

Em 16 bits:

0000 0000 0000 0001 = +1
0000 0000 0000 0010 = +2
0111 1111 1111 1111 = +32767
1000 0000 0000 0000 = -32768
1111 1111 1111 1111 = -1

A vantagem do complemento de dois é que o processador consegue realizar adições e subtrações com circuitos relativamente simples.

Não existe um caractere separado para o sinal. O sinal está incorporado ao próprio padrão binário.

6.2 Big-endian no IBM Z

O IBM Z utiliza organização big-endian para esses dados.

O byte mais significativo aparece primeiro.

Por exemplo, o valor decimal 1000 é hexadecimal:

03E8

Em dois bytes big-endian:

03 E8

Já em uma máquina little-endian, a memória poderia aparecer como:

E8 03

Essa diferença é importantíssima ao trocar estruturas binárias entre plataformas.

Enviar diretamente um campo binário de um mainframe para um servidor Intel sem definir corretamente formato, tamanho e ordem dos bytes é uma excelente forma de transformar o número 1000 em alguma criatura matemática não autorizada pelo Banco Central.


7. Tamanhos e faixas práticas

7.1 Campos com sinal

PICTURE aproximadoBytesFaixa física do COMP-5
S9(1) a S9(4)2-32.768 a 32.767
S9(5) a S9(9)4-2.147.483.648 a 2.147.483.647
S9(10) a S9(18)8-9.223.372.036.854.775.808 a 9.223.372.036.854.775.807

7.2 Campos sem sinal

PICTURE aproximadoBytesFaixa física do COMP-5
9(1) a 9(4)20 a 65.535
9(5) a 9(9)40 a 4.294.967.295
9(10) a 9(18)80 a 18.446.744.073.709.551.615

Versões modernas do COBOL IBM passaram a permitir que itens COMP-5 sem sinal utilizem todos os 16, 32 ou 64 bits. A IBM registra que esse suporte completo está disponível no COBOL for OS/390 & VM V2R2 e nos compiladores Enterprise COBOL posteriores. (IBM)

Contudo, existe um cuidado importante: nem toda operação COBOL, literal, função ou campo receptor conseguirá manipular confortavelmente toda a faixa de um inteiro de 64 bits sem sinal.

O campo pode possuir a capacidade física, mas o restante do programa também precisa estar preparado para ela.

Um hangar pode comportar um dragão. Isso não significa que a porta da cozinha também comporte.


8. Exemplo passo a passo

Considere o programa:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. TESTEC45.

       DATA DIVISION.
       WORKING-STORAGE SECTION.

       01  WS-COMP4-SIGNED       PIC S9(4) COMP-4 VALUE ZERO.
       01  WS-COMP5-SIGNED       PIC S9(4) COMP-5 VALUE ZERO.

       01  WS-COMP4-UNSIGNED     PIC 9(4) COMP-4 VALUE ZERO.
       01  WS-COMP5-UNSIGNED     PIC 9(4) COMP-5 VALUE ZERO.

       01  WS-VALOR-ENTRADA      PIC 9(5) VALUE 30000.

       01  WS-EDICAO             PIC -ZZ,ZZZ,ZZ9.

       PROCEDURE DIVISION.

           DISPLAY 'TESTE COMP-4 E COMP-5'.

           MOVE WS-VALOR-ENTRADA TO WS-COMP4-SIGNED
           MOVE WS-VALOR-ENTRADA TO WS-COMP5-SIGNED

           MOVE WS-COMP4-SIGNED TO WS-EDICAO
           DISPLAY 'COMP-4 SIGNED  : ' WS-EDICAO

           MOVE WS-COMP5-SIGNED TO WS-EDICAO
           DISPLAY 'COMP-5 SIGNED  : ' WS-EDICAO

           MOVE 60000 TO WS-COMP4-UNSIGNED
           MOVE 60000 TO WS-COMP5-UNSIGNED

           MOVE WS-COMP4-UNSIGNED TO WS-EDICAO
           DISPLAY 'COMP-4 UNSIGNED: ' WS-EDICAO

           MOVE WS-COMP5-UNSIGNED TO WS-EDICAO
           DISPLAY 'COMP-5 UNSIGNED: ' WS-EDICAO

           GOBACK.

Passo 1: observe o tamanho

Todos os quatro campos têm PIC 9(4) ou PIC S9(4).

Logo, todos ocupam 2 bytes.

Porém, sua interpretação não é idêntica.

Passo 2: campo com sinal

O valor 30000 cabe em um inteiro de 16 bits com sinal:

máximo = 32767

Ele também possui cinco dígitos decimais, apesar de o campo ter sido declarado como S9(4).

No COMP-5, o valor pode ser armazenado porque cabe nos 2 bytes.

No COMP-4, o comportamento poderá ser influenciado pela opção TRUNC porque o valor ultrapassa a magnitude de quatro dígitos descrita no PICTURE.

Passo 3: campo sem sinal

O valor 60000 cabe em 16 bits sem sinal:

máximo = 65535

Mas não cabe em PIC 9(4) se interpretarmos apenas a quantidade decimal de noves:

máximo decimal descrito = 9999

O COMP-5 utiliza a capacidade binária do campo e pode armazenar 60000.

O COMP-4 pode sofrer truncamento segundo a semântica COBOL e a opção de compilação utilizada.


9. O papel da opção TRUNC

A opção TRUNC é um dos pontos mais importantes para compreender campos binários no Enterprise COBOL.

As formas mais conhecidas são:

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

9.1 TRUNC(STD)

Procura preservar o comportamento definido pelo padrão COBOL, considerando a quantidade de dígitos do PICTURE.

Se um resultado armazenado em um campo binário ultrapassar a quantidade decimal descrita, poderá haver truncamento para aquela precisão.

Exemplo conceitual:

05 WS-NUM PIC 9(4) COMP-4.

Ao receber:

12345

o resultado poderá ser reduzido à capacidade decimal de quatro dígitos, dependendo da operação:

2345

9.2 TRUNC(OPT)

Permite otimizações, partindo da expectativa de que os valores usados pelo programa respeitam o PICTURE.

É normalmente uma boa escolha quando o código está corretamente definido e os campos não recebem valores maiores que os declarados.

Entretanto, não deve ser usado como desculpa para depender de conteúdo fora do contrato do campo.

9.3 TRUNC(BIN)

Faz com que itens binários sejam tratados de maneira mais próxima à sua capacidade física integral.

Um campo binário comum passa a se comportar, em diversos contextos, de forma semelhante a um COMP-5.

Porém, TRUNC(BIN) é uma opção global de compilação e pode gerar código adicional, afetando desempenho. A própria IBM recomenda, quando possível, manter TRUNC(OPT) e declarar especificamente como COMP-5 os campos que realmente precisam receber valores além da precisão decimal indicada no PICTURE. (IBM)

Essa é uma decisão arquitetural importante.

Compare:

TRUNC(BIN)

Pode alterar o tratamento dos itens binários do programa inteiro.

Enquanto:

05 WS-API-RETURN-CODE PIC S9(9) COMP-5.

declara explicitamente que apenas aquele campo precisa de semântica binária nativa.

É a diferença entre reforçar uma porta e transformar o prédio inteiro em um bunker.


10. Exemplo de compilação em JCL

Um JCL simplificado poderia ser:

//COBOL    EXEC PGM=IGYCRCTL,
// PARM='LIB,OBJECT,LIST,MAP,XREF,OPT(2),TRUNC(OPT)'
//STEPLIB  DD DISP=SHR,DSN=IGY.V6R5M0.SIGYCOMP
//SYSIN    DD DISP=SHR,DSN=USER.COBOL(TESTEC45)
//SYSLIN   DD DISP=SHR,DSN=&&OBJ,
//            UNIT=SYSDA,SPACE=(TRK,(1,1)),
//            DCB=(RECFM=FB,LRECL=80,BLKSIZE=0)
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSUT2   DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSUT3   DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSUT4   DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSUT5   DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSUT6   DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSUT7   DD UNIT=SYSDA,SPACE=(CYL,(1,1))

A opção relevante é:

TRUNC(OPT)

Se todos os campos binários precisassem utilizar a capacidade física integral, poderia ser usado:

TRUNC(BIN)

Entretanto, a prática recomendável é analisar o contrato dos dados.

Campos internos comuns, contadores e valores de negócio podem continuar como COMP, COMP-4 ou BINARY.

Campos provenientes de APIs, C, estruturas do sistema operacional ou interfaces externas podem ser declarados como COMP-5.


11. Onde COMP-4 costuma ser usado?

COMP-4 é útil em:

  • contadores;

  • índices auxiliares;

  • acumuladores inteiros;

  • cálculos sem casas decimais;

  • campos cuja faixa respeita claramente o PICTURE;

  • variáveis internas de desempenho;

  • estruturas legadas que já utilizam COMP ou BINARY.

Exemplo:

05 WS-CONTADOR-REGISTROS PIC 9(9) COMP-4 VALUE ZERO.

Incremento:

ADD 1 TO WS-CONTADOR-REGISTROS

Como o campo ocupa 4 bytes, o processador pode trabalhar eficientemente com operações binárias.


12. Onde COMP-5 costuma ser usado?

COMP-5 é especialmente útil em integração com:

  • programas escritos em C;

  • APIs do sistema operacional;

  • Language Environment;

  • CICS;

  • Db2;

  • estruturas binárias;

  • códigos de retorno;

  • tamanhos de buffers;

  • comprimentos;

  • ponteiros auxiliares;

  • interfaces entre linguagens;

  • copybooks gerados por ferramentas;

  • valores que utilizam toda a capacidade de 16, 32 ou 64 bits.

A documentação de interoperabilidade entre C e COBOL recomenda COMP-5 ou TRUNC(BIN) quando um parâmetro inteiro vindo de C puder conter um valor maior do que o permitido pela quantidade de dígitos do PICTURE COBOL. (IBM)

Exemplo:

01  LK-C-PARAMETERS.
    05 LK-BUFFER-LENGTH PIC 9(9) COMP-5.
    05 LK-RETURN-CODE   PIC S9(9) COMP-5.

Em C, campos equivalentes poderiam ser:

int buffer_length;
int return_code;

O objetivo é preservar a correspondência física com o inteiro utilizado pela outra linguagem.


13. COMP-4 e COMP-5 com casas decimais

É possível declarar:

05 WS-TAXA PIC S9(5)V99 COMP-4.

ou:

05 WS-TAXA PIC S9(5)V99 COMP-5.

Não existe ponto decimal armazenado.

O V é um ponto decimal implícito.

O valor:

123.45

é armazenado internamente como o inteiro escalado:

12345

O compilador sabe que existem duas casas decimais implícitas.

Entretanto, para valores monetários, COMP-3 costuma ser mais natural, previsível e compatível com a matemática decimal de negócios.

Exemplo:

05 WS-VALOR-MONETARIO PIC S9(9)V99 COMP-3.

Valores financeiros são expressos em base decimal. Usar decimal compactado reduz certas surpresas de conversão e preserva a precisão decimal esperada.

COMP-4 e COMP-5 brilham principalmente com inteiros, contadores, comprimentos, flags numéricas e interfaces de baixo nível.


14. Vantagens do COMP-4

Uso eficiente de memória

Um PIC S9(9) DISPLAY ocupa nove bytes.

Um PIC S9(9) COMP-4 ocupa quatro bytes.

Em milhões de registros ou grandes tabelas internas, essa diferença pode ser relevante.

Aritmética eficiente

Processadores trabalham naturalmente com valores binários. Contadores e cálculos inteiros podem ser executados eficientemente.

Compatibilidade histórica

COMP, COMP-4 e BINARY aparecem em uma enorme quantidade de sistemas COBOL existentes.

Intenção clara

A declaração mostra que o campo foi criado para processamento, e não para apresentação direta.


15. Desvantagens do COMP-4

Dependência das regras de truncamento

O campo físico pode armazenar um valor, mas o PICTURE pode declarar uma capacidade decimal menor.

Influência da opção TRUNC

Uma recompilação com opções diferentes pode revelar dependências escondidas no código legado.

Não é legível diretamente

Abrir um arquivo binário em um editor de texto não mostrará os dígitos de maneira compreensível.

Portabilidade

Tamanho, endianness e comportamento podem variar entre plataformas e implementações COBOL.

Risco em interfaces

Um programa externo pode preencher todos os bits, enquanto o programa COBOL espera um valor limitado pelo PICTURE.


16. Vantagens do COMP-5

Utiliza toda a capacidade binária

É ideal quando 2, 4 ou 8 bytes devem ser tratados como um verdadeiro inteiro binário.

Excelente para interoperabilidade

Facilita o mapeamento com inteiros de C, APIs, estruturas de sistema e interfaces técnicas.

Intenção explícita

O programador que lê o código entende que aquele campo pode ultrapassar a magnitude decimal indicada pelos noves do PICTURE.

Evita o uso global de TRUNC(BIN)

É possível aplicar a semântica de binário nativo apenas aos campos necessários.

Preserva valores externos

Reduz o risco de perder dígitos de um valor recebido por interface.


17. Desvantagens do COMP-5

Pode surpreender quem confia apenas no PICTURE

Um campo declarado como:

PIC 9(4) COMP-5

pode conter 60000.

Para um iniciante, isso parece uma violação das leis naturais do COBOL.

Pode causar problemas ao mover para DISPLAY

Considere:

05 WS-NATIVO PIC 9(4) COMP-5.
05 WS-TEXTO  PIC 9(4).

Se WS-NATIVO contiver 60000:

MOVE WS-NATIVO TO WS-TEXTO

o receptor possui apenas quatro posições.

O problema não estava no COMP-5. Estava no contrato inadequado do campo receptor.

Pode esconder incompatibilidades

Duas plataformas podem usar tamanhos ou ordem de bytes diferentes.

Não é a escolha padrão para dinheiro

Valores monetários e cálculos decimais normalmente ficam mais claros em COMP-3.


18. Como visualizar o conteúdo hexadecimal

Um pequeno programa pode redefinir o campo:

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

01  WS-BINARIO-X REDEFINES WS-BINARIO.
    05 WS-BYTES PIC X(2).

Em compiladores modernos, funções intrínsecas podem ajudar:

MOVE 1000 TO WS-VALOR

DISPLAY 'VALOR: ' WS-VALOR
DISPLAY 'HEX  : ' FUNCTION HEX-OF(WS-BYTES)

A representação esperada para 1000 em dois bytes big-endian é:

03E8

Para -1, em complemento de dois:

FFFF

Esse tipo de teste é excelente para compreender copybooks, dumps e integrações.


19. Cuidados ao usar REDEFINES

Nunca presuma que um campo binário pode ser interpretado como texto.

Isto:

01 WS-CAMPO.
   05 WS-NUMERO PIC S9(9) COMP-5.

01 WS-TEXTO REDEFINES WS-CAMPO.
   05 WS-CARACTERES PIC X(4).

não converte o número em texto.

Ele apenas oferece outra visão dos mesmos quatro bytes.

Se WS-NUMERO contém 123, WS-CARACTERES não conterá os caracteres:

"0123"

Ele conterá os bytes binários:

00 00 00 7B

REDEFINES não converte.

REDEFINES não formata.

REDEFINES não pergunta se você tem certeza.

Ele apenas remove a tampa do reator nuclear.


20. Boas práticas para o programador padawan

20.1 Escolha o tipo pela função

Use DISPLAY quando o dado for principalmente texto, entrada ou saída humana.

Use COMP-3 para dinheiro e cálculos decimais exatos.

Use COMP-4 ou BINARY para contadores e números inteiros que respeitam a faixa declarada.

Use COMP-5 para inteiros nativos e interfaces que exigem toda a capacidade binária.

20.2 Declare a faixa real quando possível

Embora isto seja permitido:

05 WS-LENGTH PIC 9(4) COMP-5.

pode ser mais claro declarar:

05 WS-LENGTH PIC 9(5) COMP-5.

se o valor esperado pode alcançar 65535.

A declaração deve comunicar a intenção humana, não apenas satisfazer o compilador.

20.3 Conheça a opção TRUNC

Nunca analise um programa com campos binários sem verificar as opções de compilação.

Procure no listing:

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

20.4 Não copie binário diretamente entre plataformas

Defina:

  • número de bytes;

  • presença de sinal;

  • ordem dos bytes;

  • escala decimal;

  • faixa permitida;

  • tratamento de overflow.

20.5 Use campos de edição no DISPLAY

Evite:

DISPLAY WS-COMP5

Prefira:

MOVE WS-COMP5 TO WS-EDITADO
DISPLAY WS-EDITADO

Exemplo:

05 WS-EDITADO PIC -ZZZ,ZZZ,ZZ9.

20.6 Teste os limites

Para 2 bytes com sinal, teste:

-32768
-32767
-1
0
1
32766
32767
32768

Para 2 bytes sem sinal, teste:

0
1
9999
10000
32767
32768
65535
65536

Os bugs mais interessantes não moram no valor médio.

Eles vivem na fronteira, fumando cigarro e esperando o batch de fechamento.


21. Curiosidades

COMP nem sempre significa binário em todas as plataformas

No Enterprise COBOL para z/OS, COMP é equivalente a BINARY.

Entretanto, em outras famílias e ambientes históricos, aliases podem variar. No IBM i, por exemplo, a documentação tradicional associa COMP-4 a BINARY, enquanto outros nomes computacionais podem refletir convenções específicas da plataforma. (IBM)

Portanto, nunca transporte conhecimento entre compiladores sem consultar a documentação daquele ambiente.

O PICTURE não determina sozinho o tamanho em bytes

Nos campos binários, faixas de dígitos são agrupadas:

1 a 4 dígitos  = 2 bytes
5 a 9 dígitos  = 4 bytes
10 a 18 dígitos = 8 bytes

Assim:

PIC 9(5) COMP-4

e:

PIC 9(9) COMP-4

ocupam ambos quatro bytes.

Um único nove pode custar dois bytes extras

Compare:

PIC 9(4) COMP-4

Dois bytes.

PIC 9(5) COMP-4

Quatro bytes.

Apenas um nove adicional fez o campo atravessar a fronteira entre halfword e fullword.

COMP-5 é comum em código gerado

Tradutores, preprocessadores e ferramentas de integração podem gerar campos COMP-5 porque precisam mapear tamanhos, comprimentos e códigos de retorno de maneira previsível.

A própria IBM informa que o coprocessador CICS usa tipos COMP-5 em situações nas quais o truncamento não deve ocorrer. (IBM)


22. Easter egg do data center

Diz a lenda que, em algum sistema bancário criado em 1997, existe a seguinte declaração:

05 WS-TAMANHO PIC 9(4) COMP.

Durante vinte anos, o campo recebeu valores menores que 9999.

Então uma modernização aumentou o buffer para 32000.

O programa continuou funcionando porque o compilador antigo, as opções históricas e os caminhos de execução permitiam que o valor sobrevivesse dentro dos 2 bytes.

Anos depois, alguém recompilou o programa com um compilador moderno e outra opção TRUNC.

O valor 32000 voltou da operação transformado em algo inesperado.

Sete reuniões foram marcadas.

Três fornecedores foram acusados.

Uma API REST foi criada sem necessidade.

Um arquiteto sugeriu Kubernetes.

Até que uma programadora júnior abriu o listing e perguntou:

— Por que este campo é PIC 9(4) se recebe 32000?

O silêncio que se seguiu foi registrado pelo SMF como consumo anormal de CPU emocional.


23. Comparação final

CaracterísticaCOMP-4COMP-5
Nome conceitualBinárioBinário nativo
Sinônimo de BINARYSimNão exatamente
RepresentaçãoComplemento de doisComplemento de dois
Tamanhos comuns2, 4 ou 8 bytes2, 4 ou 8 bytes
Capacidade ligada ao PICTURENormalmente, simCapacidade física do campo
Influência de TRUNCSimNão da mesma maneira
Bom para contadoresSimSim
Bom para integração com CPossível, com cuidadosRecomendado
Usa todos os bitsDepende das regras e opçõesSim
Clareza para valores nativosMenorMaior
Melhor escolha para dinheiroNormalmente nãoNormalmente não
Risco principalTruncamento inesperadoValor maior que o receptor espera

24. Conclusão

COMP-4 e COMP-5 não são apenas dois nomes misteriosos encontrados em copybooks antigos.

Eles representam dois contratos diferentes entre o programa COBOL e a memória.

COMP-4, equivalente a BINARY, armazena números em formato binário, mas continua ligado à descrição decimal do PICTURE e às regras de truncamento escolhidas na compilação.

COMP-5 declara que o campo deve ser tratado como um inteiro binário nativo, utilizando toda a capacidade física de seus 2, 4 ou 8 bytes.

O padawan precisa guardar cinco ensinamentos:

  1. COMP-4 é sinônimo de BINARY.

  2. COMP-5 utiliza a capacidade integral do recipiente binário.

  3. O tamanho depende da quantidade de dígitos do PICTURE.

  4. A opção TRUNC pode alterar o comportamento de campos binários comuns.

  5. Nunca escolha um tipo apenas porque ele “parece mais rápido”.

Escolha-o porque compreende o contrato, a origem do dado, sua faixa, seu destino e a forma como será processado.

No mainframe, um campo numérico nunca é apenas um campo numérico.

Ele é um acordo diplomático entre o COBOL, o compilador, o processador, o copybook, a plataforma externa e aquele programa de 1998 que ninguém recompila porque o último profissional que entendia o código se aposentou e agora cria orquídeas no interior de Minas Gerais.

E essa, jovem padawan, é a verdadeira diferença entre conhecer a sintaxe e compreender o sistema.


Vibe Coding sem Mistérios: da Ideia Nebulosa ao Aplicativo em Produção

 

Bellacosa Mainframe e a vibe coding sem misterios

☕ Um Café no Bellacosa Mainframe

Vibe Coding sem Mistérios: da Ideia Nebulosa ao Aplicativo em Produção

O guia do Programador COBOL Padawan para comandar inteligências artificiais, construir software com disciplina e não transformar a nave em sucata espacial

Imagine a seguinte cena.

Você está sentado diante do terminal, com uma caneca de café ao lado, o cursor piscando na tela e uma ideia aparentemente genial atravessando sua mente:

“Vou pedir para a inteligência artificial criar um aplicativo completo.”

Você respira fundo, digita:

“Faça um aplicativo de controle financeiro.”

A IA responde com entusiasmo. Em poucos segundos aparecem telas modernas, botões elegantes, gráficos coloridos e uma estrutura de código que parece saída diretamente dos laboratórios de engenharia da Frota Estelar.

Você executa o projeto.

A tela inicial abre.

O botão “Salvar” não funciona.

O saldo aceita letras.

A senha aparece no código-fonte.

A aplicação perde todos os dados quando a página é atualizada.

O relatório mensal calcula fevereiro com 31 dias.

E, em algum lugar da galáxia, um velho programador COBOL fecha os olhos, segura a caneca de café e murmura:

“Foi por isso que inventamos análise de sistemas.”

Bem-vindo ao universo do Vibe Coding.

Não, Vibe Coding não é pedir “faça um aplicativo” e torcer para que tudo funcione. Também não é uma forma mágica de eliminar análise, testes, segurança, arquitetura ou responsabilidade.

Vibe Coding é uma nova maneira de construir software utilizando inteligência artificial como copiloto, desenvolvedor assistente, gerador de protótipos, revisor e acelerador de tarefas.

A palavra importante aqui é assistente.

A IA pode gerar o código. Pode desenhar a interface. Pode sugerir um banco de dados. Pode escrever testes. Pode até explicar por que determinada abordagem foi utilizada.

Mas alguém ainda precisa comandar a missão.

E esse alguém é você.


O que é Vibe Coding, afinal?

Vibe Coding é o desenvolvimento de software orientado por linguagem natural, contexto, exemplos visuais e ciclos rápidos de interação com inteligência artificial.

Em vez de escrever manualmente todas as linhas de código, o desenvolvedor descreve o que deseja construir.

A IA então transforma essa descrição em:

  • componentes de interface;

  • regras de negócio;

  • APIs;

  • tabelas;

  • arquivos de configuração;

  • testes;

  • documentação;

  • scripts de publicação.

À primeira vista, parece que a programação desapareceu.

Mas ela não desapareceu.

Ela mudou de lugar.

Antes, boa parte do esforço estava em escrever instruções para a máquina utilizando uma linguagem formal.

Agora, parte do esforço passa a estar em descrever corretamente:

  • qual é o problema;

  • quem tem esse problema;

  • qual comportamento é esperado;

  • quais são os limites;

  • quais dados serão usados;

  • o que não deve ser criado;

  • como saberemos se o resultado está correto.

O programador deixa de ser apenas o tripulante que aperta os botões do console e passa a atuar também como:

  • analista;

  • arquiteto;

  • testador;

  • supervisor;

  • dono do produto;

  • comandante da ponte.

O Vibe Coding não elimina o raciocínio técnico. Ele pune, de maneira quase imediata, quem tenta evitá-lo.


Capítulo 1 — Não comece pela aplicação. Comece pelo problema.

Um dos maiores erros de quem entra no Vibe Coding é começar com a solução.

A pessoa diz:

“Quero criar uma rede social.”

Ou:

“Quero criar um aplicativo com inteligência artificial.”

Ou ainda:

“Quero construir o próximo Airbnb.”

Essas frases podem soar empolgantes, mas não descrevem um problema real. Elas descrevem categorias de produtos ou ambições gigantescas.

Uma boa missão começa com três elementos:

  1. uma pessoa específica;

  2. um problema concreto;

  3. um resultado desejado.

Por exemplo:

Programadores COBOL iniciantes têm dificuldade para interpretar códigos de ABEND porque as informações estão espalhadas em manuais extensos e ambientes diferentes.

Agora temos uma situação clara.

A partir dela, poderíamos criar um pequeno aplicativo chamado:

ABEND Navigator

O usuário digitaria um código, como:

S0C7

E receberia:

  • significado do erro;

  • causas mais comuns;

  • perguntas de diagnóstico;

  • exemplos de código;

  • sugestões de correção;

  • cuidados para evitar recorrência.

Perceba a diferença.

“Criar uma plataforma de mainframe com IA” é nebuloso.

“Consultar causas e soluções iniciais de ABENDs” é concreto, testável e viável.

A fórmula Bellacosa para definir o problema

Use esta estrutura:

[Público] precisa de uma maneira de [ação] porque atualmente enfrenta [dificuldade].

Exemplos:

Analistas iniciantes precisam de uma maneira de organizar comandos JCL porque os exemplos estão dispersos em apostilas e anotações.

Estudantes de COBOL precisam de uma maneira de acompanhar o que estudaram porque esquecem quais assuntos precisam de revisão.

Pequenos comerciantes precisam de uma maneira simples de registrar vendas diárias porque utilizam cadernos e planilhas desorganizadas.

Essa frase funciona como as coordenadas da nave.

Sem coordenadas, até uma Enterprise equipada com os melhores computadores pode terminar dentro de um campo de asteroides.


Capítulo 2 — Escolha uma única funcionalidade inicial

Quando a ideia surge, o entusiasmo costuma assumir o controle.

O criador começa a listar:

  • cadastro de usuário;

  • painel;

  • chat;

  • notificações;

  • relatórios;

  • pagamento;

  • inteligência artificial;

  • integração com WhatsApp;

  • exportação para PDF;

  • modo escuro;

  • aplicativo para celular;

  • ranking;

  • gamificação;

  • rede social;

  • marketplace.

Em poucos minutos, aquele pequeno projeto se transforma em um sistema maior que o computador central da Federação.

Esse fenômeno recebe um nome conhecido na engenharia de software:

Scope creep

É o crescimento descontrolado do escopo.

O projeto começa com uma funcionalidade simples e, pouco a pouco, acumula tantas exigências que ninguém mais sabe qual problema ele deveria resolver.

A primeira versão precisa responder apenas uma pergunta:

A funcionalidade principal ajuda o usuário a resolver o problema?

No caso do ABEND Navigator, a primeira funcionalidade seria:

Digitar um código de ABEND e receber uma orientação estruturada.

Só isso.

Sem login.

Sem favoritos.

Sem assinatura premium.

Sem chatbot holográfico inspirado no computador da Enterprise.

Esses elementos podem ser adicionados depois, caso usuários reais demonstrem necessidade.


MVP não significa produto ruim

MVP é a sigla para Minimum Viable Product, ou Produto Mínimo Viável.

Existe uma confusão comum:

“Se é mínimo, pode ser malfeito.”

Não pode.

O MVP pode ter poucas funcionalidades, mas precisa ser confiável dentro do que promete.

Um sistema simples ainda deve:

  • validar dados;

  • exibir mensagens claras;

  • preservar informações;

  • evitar falhas óbvias;

  • proteger informações sensíveis;

  • funcionar no dispositivo esperado;

  • possuir um fluxo compreensível.

O MVP reduz a quantidade de recursos.

Ele não reduz a responsabilidade.

Um programa COBOL que possui apenas três rotinas ainda precisa calcular corretamente. Ninguém aceita um pagamento errado porque o programa era “uma primeira versão”.


Capítulo 3 — Escolha uma ferramenta e permaneça tempo suficiente para aprender

O ecossistema de Vibe Coding oferece diversas ferramentas.

Existem plataformas voltadas para:

  • criação rápida de aplicações;

  • geração de interfaces;

  • edição de código com IA;

  • execução no navegador;

  • publicação automatizada;

  • criação de componentes;

  • desenvolvimento com agentes.

O iniciante olha para todas elas e pensa:

“Preciso testar cada uma antes de começar.”

É assim que nasce o turismo de ferramentas.

Na segunda-feira, ele abre uma plataforma.

Na terça-feira, assiste a um vídeo sobre outra.

Na quarta-feira, migra o projeto.

Na quinta-feira, descobre uma terceira que promete ser dez vezes melhor.

Na sexta-feira, possui cinco contas, quatro projetos incompletos e nenhuma aplicação publicada.

Escolher a ferramenta perfeita é menos importante do que escolher uma ferramenta adequada e aprender seu fluxo.

Perguntas para escolher a ferramenta

Antes de decidir, avalie:

  • ela gera código exportável?

  • consigo executar o projeto fora da plataforma?

  • existe um plano gratuito para testes?

  • a publicação é simples?

  • há suporte ao banco de dados necessário?

  • consigo utilizar controle de versão?

  • os custos são previsíveis?

  • consigo recuperar versões anteriores?

  • a ferramenta atende ao nível de complexidade do projeto?

A melhor ferramenta não é necessariamente a mais famosa.

É aquela que permite construir, testar, entender e manter sua aplicação.


Capítulo 4 — O primeiro prompt é uma especificação disfarçada

Um prompt ruim gera um projeto baseado em adivinhações.

Considere:

“Faça um aplicativo de estudos.”

A IA precisará decidir sozinha:

  • quem é o usuário;

  • quais assuntos serão estudados;

  • quais telas existirão;

  • se haverá login;

  • como os dados serão armazenados;

  • quais relatórios serão exibidos;

  • qual tecnologia será usada.

Ela preencherá essas lacunas com hipóteses.

Algumas serão razoáveis.

Outras serão completamente incompatíveis com o que você imaginava.

Agora veja este prompt:

Crie uma aplicação web responsiva para estudantes de COBOL organizarem sessões de estudo. A primeira versão deve permitir cadastrar assunto, categoria, duração planejada e data. O usuário deve visualizar as sessões do dia e marcar cada sessão como concluída. Não implemente login, pagamentos, compartilhamento, notificações ou gamificação. Antes de gerar código, apresente a arquitetura proposta, a estrutura das telas, os dados necessários e os critérios de aceitação.

Aqui temos:

  • público definido;

  • problema implícito;

  • funcionalidade principal;

  • limite de escopo;

  • comportamento esperado;

  • exigência de planejamento.

Quanto mais contexto fornecemos, menos a IA precisa inventar.

Os sete elementos de um bom prompt inicial

Um prompt sólido deve indicar:

  1. Público — quem utilizará o sistema;

  2. Problema — qual dificuldade será resolvida;

  3. Objetivo — o que o usuário conseguirá fazer;

  4. Escopo — o que entra na primeira versão;

  5. Limites — o que não deve ser criado;

  6. Critérios — como saber se funciona;

  7. Processo — o que a IA deve apresentar antes de codificar.

Essa estrutura se aproxima muito de uma especificação funcional tradicional.

A diferença é que agora ela é escrita em linguagem natural e utilizada diretamente na construção.


Capítulo 5 — Antes do código, peça o plano de voo

Uma das práticas mais importantes no Vibe Coding é pedir um plano antes da implementação.

A tentação é grande.

Você descreve o projeto e quer ver imediatamente a tela funcionando.

Mas dez minutos analisando o plano podem economizar horas de correção.

Antes de gerar código, solicite:

  • arquitetura;

  • fluxo do usuário;

  • telas;

  • componentes;

  • estrutura dos dados;

  • validações;

  • riscos;

  • estratégia de testes;

  • processo de publicação.

Depois, questione.

Pergunte:

Por que essa arquitetura foi escolhida?

Existe uma alternativa mais simples?

O sistema realmente precisa de banco de dados?

Quais requisitos foram inferidos?

Quais são os principais riscos?

Que parte pode gerar custo futuro?

Existe alguma dependência que pode prender o projeto à plataforma?

Essa etapa é semelhante a revisar um fluxograma antes de escrever um programa COBOL de cinco mil linhas.

É muito mais barato corrigir uma seta no diagrama do que descobrir em produção que a rotina de fechamento contábil está executando antes da validação.


O poder da pergunta: “O que você presumiu?”

Essa é uma das perguntas mais poderosas para trabalhar com IA:

Quais decisões você tomou com base em suposições que eu não informei?

A IA pode responder que presumiu:

  • um único usuário;

  • idioma português;

  • armazenamento local;

  • ausência de dados sensíveis;

  • uso em desktop;

  • ausência de autenticação;

  • disponibilidade permanente da internet.

Agora você pode validar ou corrigir cada hipótese.

Uma inteligência artificial não distingue automaticamente uma regra real de uma lacuna preenchida por probabilidade.

Cabe ao comandante confirmar as coordenadas.


Capítulo 6 — Uma mudança por vez

Após gerar o protótipo, começa a fase de ajustes.

É comum enviar um pedido assim:

“Troque o menu, coloque login, corrija o formulário, mude as cores, adicione um gráfico, crie o banco, ajuste o celular e publique.”

Isso parece eficiente.

Na prática, aumenta brutalmente a chance de regressões.

A IA pode corrigir o formulário e quebrar a navegação.

Pode adicionar o banco e remover dados simulados ainda usados por outras telas.

Pode alterar o layout e destruir a responsividade.

A abordagem correta é trabalhar em mudanças pequenas.

Exemplo:

No formulário de cadastro, impeça que o campo “Assunto” seja enviado vazio. Não altere outros componentes.

Depois:

Mostre uma mensagem de erro abaixo do campo. Preserve o layout atual.

Depois:

Crie um teste para validar esse comportamento.

Uma alteração por vez oferece:

  • maior controle;

  • teste mais simples;

  • reversão mais fácil;

  • menor risco;

  • melhor compreensão do projeto.

Programadores COBOL experientes conhecem esse princípio.

Quando um programa processa milhões de registros, você não altera vinte parágrafos sem necessidade porque encontrou uma condição incorreta em VALIDA-CLIENTE.

Na manutenção, precisão vale mais do que entusiasmo.


Capítulo 7 — Screenshots são telemetria visual

Uma das grandes vantagens das ferramentas modernas é a possibilidade de utilizar imagens durante a conversa.

Em vez de escrever:

“A tela está estranha.”

Você pode anexar uma captura e explicar:

No celular, o botão “Salvar” ultrapassa o limite do cartão. Ele deve ocupar toda a largura disponível abaixo dos campos. Não altere a versão desktop.

A imagem reduz ambiguidades.

Ela mostra:

  • a posição do erro;

  • o tamanho dos elementos;

  • o estado da aplicação;

  • a diferença entre o esperado e o atual.

Como enviar um bom pedido com screenshot

Inclua quatro elementos:

  1. Localização
    “No cartão superior direito...”

  2. Problema atual
    “O texto sobrepõe o botão...”

  3. Resultado esperado
    “O título deve quebrar em até duas linhas...”

  4. Limite da mudança
    “Não altere os demais cartões...”

A captura de tela é como um painel de diagnóstico.

Ela ajuda, mas ainda precisa de interpretação.

Um alerta no console da Enterprise não diz sozinho qual decisão o capitão deve tomar.


Capítulo 8 — Banco de dados apenas quando houver motivo

Muitos projetos de Vibe Coding começam com uma infraestrutura maior do que o próprio problema.

Antes de validar a funcionalidade, o criador já possui:

  • banco relacional;

  • autenticação;

  • funções serverless;

  • APIs;

  • triggers;

  • filas;

  • armazenamento;

  • regras de acesso;

  • painel administrativo.

Ele passa dias configurando tecnologia e quase nenhum tempo testando se alguém precisa da aplicação.

Para um protótipo, muitas vezes é suficiente utilizar:

  • dados simulados;

  • arquivo JSON;

  • armazenamento local;

  • planilha;

  • estrutura temporária em memória.

O banco de dados passa a ser necessário quando precisamos:

  • persistir dados entre dispositivos;

  • trabalhar com vários usuários;

  • controlar permissões;

  • relacionar entidades;

  • processar volumes maiores;

  • manter histórico;

  • garantir consistência.

Exemplo prático

Considere um diário de estudos.

Na primeira versão, o navegador pode armazenar:

Assunto
Categoria
Data
Nível de confiança
Observação

Se o usuário utiliza somente um computador, isso pode ser suficiente para validar a ideia.

Mais tarde, ao precisar acessar pelo celular e pelo desktop, um banco remoto passa a fazer sentido.

A regra é simples:

Adicione complexidade quando ela resolver um problema real, não quando parecer tecnologicamente elegante.


Capítulo 9 — A IA também pode modelar dados errado

A inteligência artificial pode criar uma tabela em segundos.

Isso não significa que a estrutura esteja correta.

Imagine uma tabela:

TAREFAS
ID
USUARIO
CLIENTE
TITULO
STATUS
PRAZO
OBSERVACAO

Para uma demonstração, pode funcionar.

Mas, se vários clientes possuem muitas tarefas, provavelmente teremos entidades separadas:

USUARIOS
CLIENTES
TAREFAS

Agora surgem perguntas importantes:

  • qual é a chave de cada tabela?

  • uma tarefa pode existir sem cliente?

  • o que acontece quando um cliente é excluído?

  • precisamos guardar histórico?

  • o status possui valores controlados?

  • uma tarefa pertence a um ou mais usuários?

  • informações antigas podem ser alteradas?

Essas decisões continuam existindo.

Vibe Coding não revogou normalização, integridade referencial ou consistência transacional.

No mundo mainframe, ninguém trataria a estrutura de um arquivo VSAM ou uma tabela Db2 como detalhe decorativo.

Dados são o coração do sistema.

A interface pode mudar.

A tecnologia pode mudar.

Mas um dado mal modelado costuma assombrar o projeto por muitos anos.


Capítulo 10 — Segurança: o campo minado escondido

Aplicações geradas rapidamente podem conter vulnerabilidades sérias.

Entre os problemas mais frequentes estão:

  • chaves de API expostas;

  • senhas armazenadas de forma inadequada;

  • ausência de validação no servidor;

  • acesso aos dados de outros usuários;

  • permissões excessivas;

  • informações pessoais em logs;

  • upload de arquivos sem controle;

  • dependências vulneráveis;

  • consultas inseguras.

A interface pode parecer maravilhosa enquanto o sistema possui uma porta aberta no casco da nave.

Nunca aceite uma declaração genérica como:

“A aplicação está segura.”

Peça explicações concretas:

Onde os segredos são armazenados?

Alguma chave é enviada para o navegador?

Como um usuário é impedido de acessar dados de outro?

A validação ocorre apenas na tela ou também no servidor?

Existe proteção contra envio duplicado?

Quais informações aparecem nos logs?

Como os dados são excluídos?

Quais bibliotecas foram instaladas?

Para sistemas que lidam com pagamentos, saúde, dados pessoais, documentos ou credenciais, a revisão humana especializada é indispensável.

A IA pode acelerar o trabalho.

Ela não pode assumir legalmente a responsabilidade pelo vazamento.


Capítulo 11 — Teste o usuário real, não o usuário imaginário

A IA costuma demonstrar o caminho perfeito:

  1. o usuário preenche tudo corretamente;

  2. clica uma vez;

  3. a conexão está estável;

  4. o banco responde;

  5. a operação termina.

Usuários reais fazem coisas muito mais interessantes.

Eles:

  • deixam campos vazios;

  • digitam texto em campos numéricos;

  • clicam duas vezes;

  • perdem a conexão;

  • voltam pelo navegador;

  • abrem várias abas;

  • colam textos enormes;

  • utilizam caracteres especiais;

  • fecham a tela no meio da operação.

Por isso, teste pelo menos os seguintes cenários.

Caminho feliz

Dados válidos, fluxo normal e resultado esperado.

Entrada inválida

Campos vazios, números negativos, datas impossíveis e formatos errados.

Repetição

Cliques duplos, envio repetido e atualização da página.

Interrupção

Falha de rede, erro do servidor ou fechamento inesperado.

Permissão

Tentativa de acessar recursos de outro usuário.

Persistência

Verificação de que os dados permanecem corretos após reiniciar.

Responsividade

Teste em computador, tablet e celular.

Volume

Teste com dez, cem e mil registros, quando fizer sentido.

O programa não está pronto porque funcionou uma vez.

Ele começa a merecer confiança quando continua funcionando diante de comportamentos imperfeitos.


Capítulo 12 — Controle de versão: o botão de voltar no tempo

Uma das práticas mais importantes no desenvolvimento é o controle de versão.

Ferramentas como Git permitem registrar o estado do projeto ao longo do tempo.

Antes de uma mudança importante, você cria um ponto de recuperação.

Se algo quebrar, pode comparar versões ou retornar.

Sem controle de versão, o fluxo costuma ser:

projeto-final
projeto-final-2
projeto-final-agora-vai
projeto-final-correto
projeto-final-correto-mesmo
projeto-final-correto-mesmo-ultimo

Esse sistema de nomes funciona apenas até o dia em que ninguém lembra qual versão realmente funcionava.

No Vibe Coding, o controle de versão é ainda mais importante porque agentes podem alterar vários arquivos rapidamente.

Uma boa instrução é:

Antes de modificar, informe quais arquivos serão alterados. Faça a mudança em uma etapa isolada e gere um resumo ao final.

E, idealmente:

Crie um commit antes da alteração.

Mesmo quem está começando deve aprender pelo menos:

git init
git status
git add .
git commit -m "Versão inicial funcional"

Isso já cria uma rede de segurança.

Na Frota Estelar, antes de testar uma dobra experimental, alguém certamente registra o estado dos sistemas. Pelo menos deveria.


Capítulo 13 — Publicar cedo, mas não de maneira irresponsável

Manter o projeto para sempre no computador impede o aprendizado real.

O usuário precisa testar.

A publicação revela problemas que não aparecem no ambiente local:

  • lentidão;

  • diferenças de navegador;

  • falhas de configuração;

  • permissões;

  • erros de rota;

  • comportamento em dispositivos móveis;

  • custos inesperados.

Entretanto, publicar cedo não significa lançar um sistema inseguro para milhares de pessoas.

Uma estratégia sensata é:

  1. testar localmente;

  2. compartilhar com uma pessoa;

  3. corrigir problemas graves;

  4. liberar para cinco usuários;

  5. observar o uso;

  6. coletar feedback;

  7. estabilizar;

  8. ampliar gradualmente.

Essa abordagem é chamada de liberação progressiva.

Ela reduz risco e melhora o aprendizado.

Tenha um plano de reversão

Antes de publicar, responda:

  • como volto para a versão anterior?

  • existe backup?

  • onde os erros serão registrados?

  • quem será avisado em caso de falha?

  • consigo desativar a funcionalidade?

  • os dados serão preservados durante a reversão?

Publicar sem rollback é como entrar em dobra sem saber como reduzir a velocidade.

Pode funcionar.

Mas você não quer descobrir o contrário perto de uma estrela.


Capítulo 14 — Feedback real vale mais que elogio educado

Depois que os primeiros usuários testarem, não pergunte apenas:

“Você gostou?”

Quase todos responderão “sim”.

Perguntas melhores são:

Em que momento você ficou confuso?

O que esperava que acontecesse ao clicar?

Qual etapa demorou mais?

Que tarefa você ainda precisou fazer fora da aplicação?

Qual parte parece desnecessária?

Você usaria isso novamente amanhã?

O objetivo não é receber aplausos.

É descobrir atrito.

Talvez você tenha criado um painel sofisticado com gráficos, enquanto os usuários realmente desejam um botão simples para duplicar o registro anterior.

O usuário real frequentemente destrói nossas teorias em menos de cinco minutos.

E isso é ótimo.

Cada hipótese destruída cedo economiza meses de trabalho na direção errada.


Capítulo 15 — O programador COBOL possui uma vantagem secreta

À primeira vista, Vibe Coding parece pertencer apenas ao universo de JavaScript, aplicações web e startups.

Mas programadores COBOL possuem uma vantagem enorme.

Eles estão acostumados a pensar em:

  • regras de negócio;

  • processamento confiável;

  • validação;

  • dados;

  • impacto de alterações;

  • transações;

  • recuperação;

  • produção;

  • manutenção de longo prazo.

Um programador COBOL sabe que o valor do sistema não está apenas na sintaxe.

Não é o MOVE, o PERFORM ou o EVALUATE que sustenta um banco.

É o entendimento do processo.

Da mesma forma, no Vibe Coding, saber pedir código é apenas uma parte.

O verdadeiro diferencial é saber:

  • o que deve ser construído;

  • o que não deve ser construído;

  • qual regra não pode falhar;

  • qual dado precisa ser protegido;

  • qual cenário precisa ser testado;

  • qual alteração pode afetar outra rotina.

O Padawan COBOL que aprende a utilizar IA sem abandonar seus fundamentos pode se tornar um profissional extremamente poderoso.

Ele combina:

  • experiência de negócio;

  • disciplina de sistemas críticos;

  • conhecimento de dados;

  • capacidade de modernização;

  • velocidade de ferramentas generativas.

É quase como instalar motores de dobra em uma nave construída para sobreviver décadas.


Capítulo 16 — Exemplo completo: COBOL Learning Log

Vamos construir mentalmente uma aplicação simples.

Problema

Estudantes de mainframe aprendem muitos assuntos, mas não acompanham o que já estudaram e o que precisa de revisão.

Público

Programadores COBOL iniciantes.

Objetivo

Registrar tópicos estudados e indicar o nível de confiança.

Funcionalidade principal

Cadastrar e consultar tópicos de estudo.

Dados mínimos

  • assunto;

  • categoria;

  • data;

  • nível de confiança;

  • observação.

Categorias

  • COBOL;

  • JCL;

  • Db2;

  • CICS;

  • VSAM;

  • z/OS.

Fora do escopo inicial

  • login;

  • pagamentos;

  • certificados;

  • chat;

  • integração com cursos;

  • ranking;

  • gamificação;

  • IA recomendando conteúdo.

Prompt inicial

Ajude-me a criar uma aplicação web responsiva chamada COBOL Learning Log, destinada a estudantes iniciantes de mainframe. O problema é que eles estudam vários tópicos, mas não possuem uma visão clara do que aprenderam e do que precisa de revisão.

A primeira versão deve permitir cadastrar um tópico contendo nome, categoria, data de estudo, nível de confiança de 1 a 5 e observação opcional. A tela inicial deve listar os registros e permitir filtro por categoria.

Não implemente login, pagamentos, certificados, compartilhamento, chat ou integração com IA.

Antes de gerar código, apresente a arquitetura mais simples, o fluxo do usuário, as telas, a estrutura dos dados, as validações, os testes e a estratégia de publicação.

Utilize armazenamento local inicialmente. Faça no máximo cinco perguntas caso alguma decisão seja indispensável.

Critérios de aceitação

  • assunto obrigatório;

  • categoria obrigatória;

  • nível entre 1 e 5;

  • data não pode estar no futuro;

  • dados permanecem após atualizar;

  • filtro funciona corretamente;

  • exclusão exige confirmação;

  • interface funciona no celular.

Perceba como o projeto deixou de ser uma ideia vaga.

Agora temos uma missão clara, critérios objetivos e fronteiras definidas.


Capítulo 17 — O ciclo Bellacosa de Vibe Coding

Um fluxo seguro pode seguir dez etapas.

1. Descrever

Explique o problema e o público.

2. Limitar

Escolha uma única funcionalidade principal.

3. Planejar

Peça arquitetura, telas e dados antes do código.

4. Questionar

Investigue suposições, riscos e custos.

5. Construir

Implemente uma parte pequena.

6. Executar

Teste no ambiente real.

7. Observar

Compare o resultado com os critérios.

8. Corrigir

Faça uma mudança por vez.

9. Publicar

Disponibilize para poucos usuários.

10. Aprender

Use o feedback para decidir o próximo passo.

Depois, repita.

Esse ciclo é muito mais importante do que qualquer ferramenta específica.

Ferramentas mudam.

Modelos mudam.

Plataformas surgem e desaparecem.

O processo continua válido.


Capítulo 18 — Um prompt mestre para sua próxima missão

Utilize este modelo:

Atue como analista de produto, arquiteto de software, desenvolvedor e testador responsável.

Ajude-me a criar um aplicativo para [PÚBLICO] resolver [PROBLEMA].

O resultado principal esperado é [RESULTADO].

Antes de gerar código:

  1. reescreva o problema de forma objetiva;

  2. identifique dúvidas e suposições;

  3. proponha um MVP com uma única funcionalidade central;

  4. liste o que ficará fora da primeira versão;

  5. recomende a ferramenta mais simples;

  6. descreva o fluxo do usuário;

  7. proponha as telas;

  8. modele os dados mínimos;

  9. liste validações;

  10. identifique riscos de segurança;

  11. crie critérios de aceitação;

  12. prepare casos de teste;

  13. explique a publicação;

  14. defina uma estratégia de rollback.

Não acrescente funcionalidades sem minha autorização.

Durante a implementação, faça uma mudança por vez, informe quais arquivos serão alterados e preserve tudo o que já estiver funcionando.

Esse prompt não garante perfeição.

Mas cria um ambiente muito mais controlado.


Curiosidades do convés de engenharia

A IA não “entende” seu projeto como um colega humano

Ela trabalha a partir do contexto disponível.

Quando informações faltam, ela pode completar as lacunas com padrões estatísticos.

Isso significa que uma resposta convincente pode conter uma decisão errada.

Código bonito não significa código correto

Uma interface elegante pode esconder:

  • regra incorreta;

  • falha de segurança;

  • cálculo errado;

  • dados inconsistentes;

  • dependência problemática.

O protótipo é uma pergunta, não uma resposta

Seu objetivo inicial não é provar que a ideia é genial.

É descobrir se ela resolve um problema.

A complexidade cobra juros

Cada banco, integração, serviço e dependência adiciona custo de manutenção.

O usuário raramente pede aquilo de que realmente precisa

Ele pode pedir um gráfico.

Após observar seu trabalho, você descobre que ele precisava de um alerta.


Easter egg da Frota Estelar

Em muitas histórias de Star Trek, o computador da Enterprise parece capaz de executar quase qualquer ordem:

“Computador, analise a composição da atmosfera.”

“Computador, localize a nave.”

“Computador, simule o cenário.”

Mas observe um detalhe.

Os oficiais fazem perguntas específicas.

Eles informam parâmetros.

Eles verificam resultados.

Eles discordam do computador.

Eles cruzam dados.

Eles assumem o comando quando a situação muda.

A ficção nunca disse que possuir um computador poderoso eliminaria a necessidade de julgamento humano.

Na verdade, ela sugeriu o contrário.

Quanto mais poderosa a tecnologia, mais importante se torna a responsabilidade de quem a utiliza.

Vibe Coding é exatamente isso.

Temos acesso a uma espécie de computador de bordo capaz de criar sistemas em minutos.

A pergunta não é apenas:

“O que ele consegue construir?”

A pergunta mais importante é:

“Somos capazes de descrever corretamente o que deve ser construído?”


Conclusão — A IA é o motor de dobra, não o capitão

Vibe Coding representa uma transformação extraordinária.

Pessoas que nunca construíram software podem criar protótipos.

Programadores experientes podem acelerar tarefas repetitivas.

Empresas podem validar ideias em menos tempo.

Estudantes podem aprender observando código funcional.

Mas nenhum desses benefícios elimina os fundamentos.

Um bom sistema ainda exige:

  • clareza;

  • escopo;

  • análise;

  • validação;

  • testes;

  • segurança;

  • controle de versão;

  • observabilidade;

  • responsabilidade;

  • aprendizado contínuo.

A habilidade principal do futuro talvez não seja escrever cada linha manualmente.

Será saber conduzir máquinas capazes de escrevê-las.

O programador deixará de ser apenas quem produz instruções e se tornará cada vez mais quem:

  • define intenções;

  • estabelece limites;

  • avalia riscos;

  • verifica resultados;

  • protege usuários;

  • decide prioridades;

  • mantém coerência.

Para o Programador COBOL Padawan, isso não é uma ameaça.

É uma oportunidade histórica.

Você já conhece o valor da precisão.

Já sabe que uma pequena regra pode movimentar milhões.

Já aprendeu que sistemas vivem muito mais tempo do que a primeira versão imaginava.

Agora chegou o momento de levar essa disciplina para o universo da inteligência artificial.

Use a IA.

Explore.

Construa.

Publique.

Mas nunca abandone o painel de comando.

Porque, no final, não importa quantos agentes, modelos ou geradores estejam trabalhando na sala de máquinas.

Quando o alerta vermelho tocar, alguém ainda precisará sentar na cadeira do capitão e dizer:

“Computador, explique exatamente o que você alterou.”

E talvez acrescentar:

“Desta vez, sem mexer no módulo que já estava funcionando.”

Vibe on, Padawan. Mas mantenha o controle da nave.

quarta-feira, 28 de maio de 2025

Java no IBM Mainframe: Quando o Programador COBOL Descobre que a JVM Também Mora no z/OS

 

Bellacosa Mainframe e o java no mundo mainframe

☕ Um Café no Bellacosa Mainframe

Java no IBM Mainframe: Quando o Programador COBOL Descobre que a JVM Também Mora no z/OS

"O futuro do Mainframe nunca foi COBOL ou Java. Sempre foi COBOL e Java trabalhando juntos."


Durante muitos anos surgiu um mito que assustou milhares de programadores COBOL.

"O Java vai substituir o COBOL."

O tempo mostrou exatamente o contrário.

Hoje, praticamente todos os grandes bancos, seguradoras, operadoras de cartão, bolsas de valores e órgãos governamentais utilizam COBOL e Java lado a lado, cada um fazendo aquilo em que é melhor.

Na realidade, aprender Java não significa abandonar o COBOL.

Significa entender como funciona o restante do ecossistema moderno do IBM Z.

Se você é um programador COBOL Junior, este artigo é praticamente um mapa mostrando onde o Java entra na arquitetura Mainframe e por que ele pode transformar sua carreira.

Pegue seu café.

Hoje vamos conhecer um dos moradores mais importantes do IBM Z.


O dia em que o Java chegou ao Mainframe

Quando a Sun Microsystems lançou o Java em 1995, sua proposta era revolucionária.

Write Once, Run Anywhere.

Escreva uma vez.

Execute em qualquer lugar.

Enquanto isso, o Mainframe continuava executando milhões de linhas de COBOL.

A IBM rapidamente percebeu que aquela linguagem seria importante.

Ao invés de ignorá-la, fez algo típico da empresa:

levou o Java para dentro do z/OS.

Poucos anos depois surgiu a JVM para Mainframe.

Desde então, cada geração do IBM Z recebeu melhorias específicas para acelerar Java.

Hoje existem instruções de hardware dedicadas para execução da JVM.

Ou seja:

O Java não está "rodando emulado" no Mainframe.

Ele roda utilizando otimizações do próprio processador IBM Z.


Onde o Java aparece no Mainframe?

Muito mais lugares do que imaginamos.

Você provavelmente já utiliza sistemas Java sem perceber.

Exemplos:

  • Internet Banking

  • Aplicativos Mobile

  • APIs REST

  • Microserviços

  • IBM MQ

  • WebSphere Liberty

  • CICS Java

  • Batch Java

  • z/OS Connect

  • IBM Z Open Automation Utilities

  • Ansible

  • Jenkins

  • Zowe

  • Eclipse

  • IBM Developer for z/OS

  • Spring Boot para z/OS

Em muitos ambientes, o COBOL continua sendo o responsável pelas regras de negócio.

O Java apenas conversa com ele.


A arquitetura moderna

Imagine um banco.

Cliente
     │
Internet
     │
API REST
     │
Spring Boot
     │
z/OS Connect
     │
CICS
     │
Programa COBOL
     │
DB2

Perceba algo interessante.

O Java raramente substitui o COBOL.

Ele funciona como uma ponte.


Java Batch

Quando pensamos em Mainframe normalmente lembramos de processamento Batch.

A boa notícia é que Java também executa Batch.

Por exemplo:

Leitura de arquivos

↓

Validação

↓

Processamento

↓

Atualização DB2

↓

Geração de Relatórios

A execução ocorre através do JCL.

Exemplo simplificado:

//JAVAJOB JOB
//STEP01 EXEC PGM=JVMLDM86
//STDENV DD *
JAVA_HOME=/usr/lpp/java
CLASSPATH=/u/apps/meuapp.jar
/*

Na prática, o JCL prepara o ambiente.

Quem executa o processamento é a JVM.


Um pequeno programa Java

public class HelloMainframe {

    public static void main(String[] args){

        System.out.println("Olá IBM Z!");

    }

}

Compilação:

javac HelloMainframe.java

Execução:

java HelloMainframe

No z/OS funciona praticamente da mesma forma.

A diferença está no ambiente preparado pelo JCL.


Java Online

Agora imagine uma aplicação bancária.

O cliente faz um PIX.

O aplicativo envia uma requisição.

Essa requisição chega ao Mainframe.

Quem recebe?

Pode ser um programa Java.

Ou um serviço REST.

Depois disso:

Java

↓

CICS

↓

COBOL

↓

DB2

↓

Resposta JSON

Tudo ocorre em poucos milissegundos.


Java dentro do CICS

Muitos desenvolvedores não sabem.

O CICS executa programas Java.

Isso permite:

  • APIs REST

  • SOAP

  • JSON

  • XML

  • JMS

  • MQ

Tudo dentro do ambiente transacional.

O COBOL continua executando a lógica principal.

O Java cuida da integração.


Java e DB2

Uma das maiores vantagens do Java é sua integração com bancos relacionais.

O acesso normalmente ocorre através do JDBC.

Exemplo:

Connection conn =
DriverManager.getConnection(url,user,password);

PreparedStatement ps =
conn.prepareStatement(
"SELECT NOME FROM CLIENTES");

ResultSet rs = ps.executeQuery();

No Mainframe ocorre exatamente o mesmo conceito.

A diferença está no driver utilizado.

Normalmente utiliza-se o IBM Data Server Driver.


JDBC ou SQL Embutido?

Programadores COBOL costumam perguntar:

"Se existe SQL Embutido, por que usar JDBC?"

Porque são tecnologias diferentes.

COBOL

EXEC SQL
SELECT ...
END-EXEC

Java

PreparedStatement

O resultado final é semelhante.

Ambos acessam o DB2.


Vantagens do PreparedStatement

Nunca monte SQL concatenando Strings.

Ruim:

"SELECT * FROM CLIENTES WHERE ID="+id;

Correto:

PreparedStatement

Além de mais rápido, evita SQL Injection.


Java e Stored Procedures

Outra integração muito comum.

Java

↓

Stored Procedure DB2

↓

SQL

↓

Resultado

Muitos bancos utilizam esse modelo.


Java conversando com COBOL

Existem diversas formas.

Por exemplo:

  • CICS LINK

  • MQ

  • REST

  • SOAP

  • z/OS Connect

  • JNI

  • Arquivos

  • Stored Procedures

Na maioria dos projetos modernos, REST e MQ são os campeões.


Java e IBM MQ

Imagine dezenas de sistemas conversando.

Ao invés de chamadas diretas, utiliza-se filas.

Java

↓

MQ

↓

COBOL

Se o COBOL estiver ocupado...

A mensagem continua aguardando.

Isso aumenta a disponibilidade.


Java e z/OS Connect

Talvez esta seja a tecnologia que mais mudou o Mainframe.

Antes:

Aplicações externas precisavam conhecer CICS.

Hoje:

REST

↓

JSON

↓

z/OS Connect

↓

COBOL

Quem desenvolve a API geralmente utiliza Java.


WebSphere Liberty

O Liberty tornou-se praticamente o servidor Java padrão do IBM Z.

Leve.

Moderno.

Compatível com Jakarta EE.

Executa:

  • REST

  • MicroProfile

  • JWT

  • OAuth

  • OpenAPI

Tudo muito integrado ao z/OS.


Java e LinuxONE

Aqui surge uma dúvida.

LinuxONE é Mainframe?

Sim.

É a mesma arquitetura IBM Z.

A diferença é que executa Linux como sistema operacional principal.

Nesse ambiente podemos instalar:

  • Java

  • Spring Boot

  • Docker

  • Kubernetes

  • Kafka

  • PostgreSQL

  • MongoDB

  • Redis

Tudo rodando sobre hardware IBM.

É comum encontrar arquiteturas híbridas:

LinuxONE

↓

Java

↓

API

↓

MQ

↓

z/OS

↓

COBOL

Java e Containers

Hoje o Java roda perfeitamente em containers.

Exemplo:

Docker

↓

Java

↓

Spring Boot

No IBM Z isso normalmente acontece utilizando:

  • Red Hat OpenShift

  • Kubernetes

  • LinuxONE


Java e OpenShift

Imagine centenas de APIs.

Em vez de dezenas de servidores, utiliza-se OpenShift.

Cada API Java roda em um container.

Quando aumenta o acesso...

O OpenShift cria novos containers automaticamente.


Java e Ansible

Aqui está uma surpresa para muitos programadores COBOL.

O Ansible também administra aplicações Java.

Por exemplo:

  • Deploy

  • Atualização

  • Reinício

  • Configuração

  • Instalação

  • Coleta de logs

Tudo automatizado.

Um Playbook simples:

- hosts: zos

  tasks:

    - name: Reiniciar Liberty

      command: server stop liberty

    - name: Iniciar Liberty

      command: server start liberty

Java e Zowe

O Zowe aproximou muito o Mainframe do mundo Open Source.

Com ele podemos:

  • enviar JCL

  • consultar Jobs

  • acessar datasets

  • acessar USS

  • automatizar builds

Tudo usando JavaScript, Node.js ou Java.


Java e USS

O UNIX System Services é praticamente um Linux dentro do z/OS.

É nele que encontramos:

/usr/lpp/java

Ali estão instalados:

  • JVM

  • Bibliotecas

  • Ferramentas

  • Scripts

Grande parte das aplicações Java vive dentro do USS.


Java e Git

Hoje é comum encontrar projetos Java armazenados no GitHub.

Fluxo típico:

Git

↓

Jenkins

↓

Compilação

↓

Testes

↓

Deploy

↓

Liberty

Tudo automático.


Java e DevOps

Mainframe moderno faz DevOps.

Ferramentas comuns:

  • Git

  • GitHub

  • GitLab

  • Jenkins

  • UrbanCode Deploy

  • Ansible

  • Zowe CLI

  • Maven

  • Gradle

  • SonarQube


Maven

Quase todo projeto Java utiliza Maven.

Arquivo:

pom.xml

Ali ficam:

  • dependências

  • plugins

  • versão

  • compilação

É o equivalente ao gerenciamento de bibliotecas do projeto.


Gradle

Outro gerenciador bastante utilizado.

Mais flexível.

Mais rápido em projetos grandes.


Java e APIs REST

Hoje praticamente toda integração passa por APIs.

Exemplo simples:

GET

/clientes/123

Resposta:

{
 "id":123,
 "nome":"João"
}

Quem produz esse JSON?

Na maioria das vezes:

Java.

Quem consulta o DB2?

COBOL.


Curiosidades

Pouca gente sabe que:

  • O IBM Z possui otimizações específicas para Java.

  • Existe JIT Compiler dedicado.

  • A JVM recebe melhorias a cada geração do processador.

  • Grande parte das ferramentas IBM modernas utiliza Java.

  • O IBM Developer for z/OS é baseado em Eclipse, escrito em Java.

  • O IBM Installation Manager é Java.

  • Diversos componentes do IBM MQ possuem módulos Java.

  • O z/OS Explorer e o CICS Explorer também são baseados em Eclipse.

Ou seja...

Mesmo sem programar Java, você provavelmente já utiliza softwares escritos nessa linguagem todos os dias.


Dicas para quem vem do COBOL

1. Aprenda Orientação a Objetos

É a maior mudança de mentalidade.

COBOL organiza programas.

Java organiza objetos.


2. Domine Collections

Aprenda:

  • List

  • Set

  • Map

  • Queue

Você utilizará essas estruturas constantemente.


3. Entenda Exceptions

Em COBOL temos:

IF SQLCODE

Em Java temos:

try{

}
catch(Exception e){

}

É outra forma de tratar erros.


4. Não tenha medo do Garbage Collector

COBOL trabalha muito com controle explícito de memória.

Java possui coleta automática.

Isso reduz vazamentos de memória, mas exige entender como o Garbage Collector funciona para escrever aplicações eficientes.


5. Aprenda SQL antes de JDBC

Quem domina SQL aprende JDBC muito mais rapidamente.

O banco continua sendo o mesmo.


6. Conheça o ecossistema

Não estude apenas a linguagem.

Conheça também:

  • Spring Boot

  • Maven

  • Gradle

  • Git

  • Docker

  • OpenShift

  • Ansible

  • Zowe

  • Liberty

  • MQ

  • z/OS Connect


Um roteiro de estudos para o Programador COBOL Junior

Uma boa sequência é:

  1. Fundamentos da linguagem Java (variáveis, classes, objetos e herança).

  2. Coleções, exceções, entrada/saída e programação funcional com Streams.

  3. JDBC e acesso ao DB2.

  4. Maven ou Gradle para gerenciamento de dependências.

  5. Git e GitHub.

  6. Spring Boot e criação de APIs REST.

  7. IBM MQ para mensageria.

  8. WebSphere Liberty e implantação de aplicações Java no z/OS.

  9. z/OS Connect para expor programas COBOL como APIs.

  10. LinuxONE, Docker e OpenShift.

  11. Zowe CLI para integração com o ambiente Mainframe.

  12. Ansible para automação de deploy, configuração e administração.

Essa jornada amplia sua visão do ecossistema IBM Z e faz de você um profissional muito mais versátil.

O que muda na carreira?

Há vinte anos, um programador COBOL precisava conhecer principalmente JCL, CICS e DB2.

Hoje isso continua importante, mas o cenário mudou.

O profissional mais valorizado é aquele que entende o fluxo completo da aplicação:

  • O aplicativo móvel envia uma requisição.

  • Uma API Java recebe a chamada.

  • O z/OS Connect faz a integração.

  • O CICS executa a transação.

  • O COBOL aplica as regras de negócio.

  • O DB2 armazena e recupera os dados.

  • O MQ garante comunicação assíncrona quando necessário.

  • O Liberty hospeda os serviços.

  • O OpenShift escala os containers.

  • O Ansible automatiza o ambiente.

  • O Zowe integra tudo ao pipeline de DevOps.

Perceba que o COBOL continua no centro da operação. O Java amplia as possibilidades de integração, modernização e entrega contínua.

Conclusão

Existe uma frase muito conhecida no universo Mainframe:

"As regras de negócio ficam onde elas sempre estiveram; o que muda é a forma de acessá-las."

É exatamente isso que aconteceu com o Java no IBM Z.

Ele não chegou para substituir o COBOL, mas para conectar o Mainframe ao restante do mundo: aplicações web, dispositivos móveis, microsserviços, nuvem híbrida, APIs, automação e DevOps. Enquanto o COBOL continua executando com confiabilidade as transações críticas, o Java oferece a flexibilidade necessária para construir novas interfaces e integrar tecnologias modernas.

Para o programador COBOL Junior, aprender Java significa entender como as aplicações corporativas são construídas hoje. Você continuará valorizando conceitos clássicos como JCL, CICS, DB2 e VSAM, mas também passará a dominar ferramentas como Maven, Spring Boot, Liberty, MQ, Zowe, OpenShift e Ansible.

No fim das contas, o mercado não procura especialistas em uma única linguagem. Procura profissionais capazes de navegar por todo o ecossistema IBM Z. E, nesse ecossistema, COBOL e Java não são rivais — são parceiros que, juntos, mantêm funcionando alguns dos sistemas mais importantes do planeta.


terça-feira, 27 de maio de 2025

💬 Guia Prático para Garotos Tímidos

 

Bellacosa Mainframe e o guia para garotos timidos

💬 GUIA PRÁTICO DE CONVERSA E EMPATIA PARA GAROTOS TÍMIDOS (versão 2025)

👦 Introdução – O problema não é você. É o “mundo pós-like”.

Ser tímido em 2025 é mais comum do que parece.
O problema é que as redes sociais criaram uma cultura de performance: todo mundo parece confiante, bonito e interessante — menos você.
Mas é ilusão. Por trás das telas, 90% das pessoas têm medo de não serem aceitas.
O segredo não é vencer a timidez. É usar a timidez como força, com calma, humor e autenticidade.


🌱 1. Comece sendo bom com as pessoas, não “com garotas”

Antes de pensar em namoro, treine a arte da conversa leve:

  • Puxe papo com colegas sobre algo simples (música, séries, jogos, esportes).

  • Observe as pessoas — o que elas gostam, o que as faz rir.

  • Seja gentil, mas sem parecer que quer algo em troca.

👉 Treino prático:
Durante o dia, tente dizer “oi” para três pessoas diferentes — colegas, atendentes, professores.
É um pequeno treino para destravar o cérebro social.


💭 2. Entenda o novo “código” das garotas

As garotas de hoje:

  • Não gostam de cantadas, mas valorizam atenção verdadeira.

  • Notam quem ouve, não quem fala mais.

  • Querem respeito, mas também humor — sem forçar.

  • E, acima de tudo, sentem quando alguém está tentando ser algo que não é.

👉 Dica:
Não tente “impressionar”.
Tente conectar. Uma frase sincera vale mais do que 10 piadas ensaiadas.


💡 3. Use o poder do interesse genuíno

Quer parecer confiante? Mostre curiosidade.
Pergunte sobre algo que ela comentou, mostre que você ouviu — é raro hoje em dia.
Exemplo:

“Vi que você gosta de tal série — vale a pena? Eu tô procurando algo novo pra ver.”

Simples, educado, e abre espaço pra conversa.

👉 Evite: comentários sobre aparência.
O mundo já faz isso demais. Se você for diferente, vai se destacar.


🎮 4. A timidez pode ser charme

Parece brincadeira, mas é verdade: garotas notam quando um cara é sincero e um pouco retraído — isso transmite calma e segurança.
A diferença é não deixar o medo travar.
Se ela falar algo, responda.
Não planeje frases, responda com naturalidade, mesmo que seja simples.

Exemplo:

Ela: “Eu adoro tal música.”
Você: “Sério? Eu ainda não ouvi, mas agora fiquei curioso.”

Não é sobre “parecer interessante”. É sobre estar presente.


🧭 5. Rejeição não é fracasso

Ser rejeitado faz parte — e acontece com todo mundo, até com os mais “populares”.
O que te define é como você lida com o não.
Sorria, agradeça, siga em frente.
Isso mostra maturidade, e acredite: maturidade atrai.


⚙️ 6. Dicas práticas de 2025

  • Evite exagerar no digital. Um “oi” no Instagram é ok, mas não insista se não houver resposta.

  • Fotos naturais > poses forçadas. Mostre quem você é de verdade.

  • Higiene, roupa limpa, sorriso discreto. Sim, ainda é o básico que funciona.

  • Seja o cara tranquilo, não o desesperado. O mundo tá cheio de ansiedade. Seja o oposto: calma é poder.


❤️ 7. O segredo final

Você não precisa de frases prontas.
Precisa gostar de quem você é — o resto vem naturalmente.
Garotas se conectam com gente de verdade, não com personagens.
Seja educado, curioso e gentil.
No fim, quem é você quando ninguém está olhando… é o que realmente conquista.

segunda-feira, 26 de maio de 2025

O que mudou na paquera de 2025

 

Bellacosa Mainframe e as mudanças na paquera em 2025

O que mudou na paquera de 2025

🧠 1. As regras sociais mudaram — e muito

Nos anos 80, 90 e até início dos 2000, o flerte era algo espontâneo, com interações presenciais e uma cultura de “conhecer alguém” em festas, escola ou amigos em comum.
Hoje, as relações começam (e terminam) digitalmente. A rede social é o “cartão de visita” — aparência, postura e até posicionamento social contam. A garota de 2025 cresceu conectada, mais consciente das questões de gênero, assédio e respeito, e muitas vezes mais seletiva e defensiva por conta da exposição constante.
O “oi” que funcionava no passado, hoje pode soar invasivo se feito fora de contexto digital.




💬 2. As garotas estão mais seguras… mas também mais pressionadas

Elas cresceram ouvindo sobre empoderamento feminino, corpo positivo e independência emocional — o que é ótimo. Mas junto disso, há uma pressão imensa por imagem, status e aprovação nas redes.
Então, elas parecem mais inacessíveis, mas muitas também se sentem inseguras e cobradas. O resultado é uma postura mais “fechada” no contato social, para evitar julgamentos ou vulnerabilidade.


🧍‍♂️ 3. Os garotos, em contrapartida, perderam espaço para errar

No seu tempo, um erro numa abordagem era esquecido no dia seguinte. Hoje, um comentário mal interpretado pode virar meme, print ou chacota. Isso cria um medo real de se expor.
Por isso, os meninos tímidos — como seu filho — se retraem ainda mais. Eles preferem não tentar do que correr o risco de “errar”.


❤️ 4. Mas a essência ainda é a mesma

Apesar de toda essa revolução digital, o coração humano continua igual. Todos ainda buscam conexão, acolhimento, risadas e sentir-se visto.
Seu filho não precisa “virar um sedutor” — precisa apenas aprender a se comunicar com autenticidade e respeito, entendendo o novo contexto.


🧭 5. Como você pode ajudá-lo

Algumas ideias práticas e modernas que você pode transmitir:

  • Não foque em “pegar garotas”, e sim em conversar bem com pessoas. A empatia vem antes do romance.

  • Ajude-o a desenvolver hobbies sociais — esportes, música, programação, arte, voluntariado. A paixão por algo gera confiança e atrai naturalmente.

  • Explique que o “não” não é rejeição pessoal, e sim parte natural da vida.

  • Incentive-o a sair do mundo digital — encontros presenciais ainda são onde o vínculo real acontece.

  • E o mais importante: mostre que ser tímido não é defeito. É só um jeito diferente de viver as emoções.

domingo, 25 de maio de 2025

IBM Cloud Object Storage : Optimize Active Workloads e Reduza Custos Inteligentemente

 

Bellacosa Mainframe introduz ibm cloud

☕ Um Café no Bellacosa Mainframe

IBM Cloud Object Storage

Optimize Active Workloads e Reduza Custos Inteligentemente

O Que Todo Programador COBOL Padawan Precisa Saber Sobre o Ciclo de Vida dos Dados na Era da Inteligência Artificial e da Computação em Nuvem

"O dado é como um funcionário da empresa. Quando nasce, trabalha intensamente. Com o tempo, passa a ser consultado apenas ocasionalmente. Anos depois, continua importante, mas apenas como registro histórico. Guardá-lo da mesma maneira durante toda a sua vida é um desperdício de recursos."


Introdução

Imagine que você acabou de chegar ao Bellacosa Mainframe para mais uma conversa acompanhada de um bom café.

Você, jovem Padawan COBOL, olha para seu professor e pergunta:

Professor, por que a IBM criou tantas categorias diferentes de armazenamento no IBM Cloud Object Storage? Não seria mais simples existir apenas um tipo de disco?

O professor sorri.

Essa é exatamente a pergunta que milhares de arquitetos de infraestrutura fazem quando começam a trabalhar com Cloud Computing.

Durante décadas, no mundo Mainframe, aprendemos uma lição fundamental:

nem todos os dados possuem o mesmo valor durante toda a sua existência.

Essa ideia não nasceu na nuvem.

Ela nasceu muito antes.

Muito antes do Hadoop.

Muito antes do Amazon S3.

Muito antes do Azure Blob Storage.

Ela nasceu nos grandes computadores IBM.

E continua sendo um dos conceitos mais importantes para qualquer profissional que deseja construir sistemas modernos, escaláveis e economicamente sustentáveis.

Hoje vamos entender como o IBM Cloud Object Storage transporta essa filosofia clássica do Mainframe para a era da Inteligência Artificial.


O grande problema do armazenamento moderno

Imagine uma empresa de comércio eletrônico.

Ela possui:

  • 500 milhões de imagens de produtos

  • notas fiscais

  • contratos

  • backups

  • vídeos

  • modelos de IA

  • Data Lake

  • logs de aplicações

  • documentos digitalizados

Tudo isso ocupa vários Petabytes.

Agora pense.

Será que todos esses arquivos são acessados diariamente?

Claro que não.

Na realidade, estudos mostram que em muitas organizações:

  • aproximadamente 80% dos dados são frios (Cold Data);

  • apenas 20% permanecem ativos.

Mesmo assim, muitas empresas continuam pagando armazenamento de alta performance para 100% dos dados.

É como comprar um carro de Fórmula 1 para ir ao supermercado.

Funciona?

Sim.

É inteligente?

Definitivamente não.


O mesmo problema já existia no Mainframe

Se você trabalha com IBM Z, isso deve parecer familiar.

Décadas atrás, quando discos DASD custavam pequenas fortunas, ninguém deixava tudo armazenado no disco principal.

Existia uma estratégia.

Arquivos recentes permaneciam nos discos.

Arquivos antigos migravam automaticamente.

Depois eram enviados para fitas.

Quem fazia isso?

O famoso:

DFSMS/HSM

(Hierarchical Storage Manager)

Veja a analogia.

MainframeIBM Cloud
DASDStandard Storage
ML1Vault
ML2Cold Vault
TapeArchive

Percebe?

A IBM praticamente trouxe a filosofia do DFSMS para a nuvem.


A ideia mais importante: Data Lifecycle

A IBM não vende apenas armazenamento.

Ela vende gerenciamento do ciclo de vida da informação.

O conceito é simples.

Quando um dado nasce...

ele costuma ser extremamente importante.

Após alguns meses...

sua importância diminui.

Após alguns anos...

ele continua valioso.

Mas apenas para auditoria.

Ou para exigências legais.

Portanto...

não faz sentido pagar o mesmo preço durante toda sua existência.


Pense em uma Nota Fiscal

Primeiro dia

É utilizada o tempo inteiro.

Primeira semana

Continua sendo consultada.

Primeiro mês

Algumas consultas.

Primeiro ano

Quase nenhuma.

Cinco anos depois

Talvez uma auditoria.

Dez anos depois

Provavelmente nunca mais.

Então por que manter essa nota fiscal no armazenamento mais caro durante dez anos?

Não existe lógica financeira.


IBM Cloud Object Storage

O IBM Cloud Object Storage foi projetado exatamente para resolver esse problema.

Ele oferece diferentes camadas de armazenamento.

Cada uma otimizada para um padrão de utilização.

A imagem apresenta seis grandes categorias.

Vamos entender cada uma.


One Rate Plan

Comecemos pela novidade.

O One Rate Plan.

Imagine entrar em um restaurante.

Ao invés de pagar:

  • entrada

  • prato principal

  • sobremesa

  • couvert

  • taxa de serviço

  • bebida

  • estacionamento

Você paga apenas um valor fixo.

Foi exatamente isso que a IBM fez.

No One Rate Plan você possui uma cobrança previsível.

Incluindo praticamente tudo.

  • armazenamento

  • leitura

  • gravação

  • APIs

  • transferência de dados

  • egress

Isso simplifica enormemente a estimativa de custos.

Especialmente para projetos de IA.


Por que IA muda completamente o armazenamento?

Treinar Inteligência Artificial significa ler arquivos.

Milhões.

Bilhões.

Imagine um modelo semelhante ao GPT.

Durante semanas.

Milhares de GPUs ficam lendo datasets continuamente.

Cada leitura pode representar uma operação.

Em alguns provedores isso gera milhares de cobranças adicionais.

No One Rate essa complexidade praticamente desaparece.


Exemplo

Imagine um treinamento com:

120 TB de imagens.

Durante trinta dias.

Cada GPU realiza milhões de leituras.

Num modelo tradicional você paga:

  • armazenamento

  • GET

  • PUT

  • LIST

  • Egress

  • APIs

No One Rate.

A conta torna-se previsível.

Isso é extremamente importante para empresas.


Smart Tier

Agora chegamos a uma das funcionalidades mais inteligentes.

O Smart Tier.

Pense nele como um WLM (Workload Manager) do armazenamento.

Você não precisa decidir onde colocar o arquivo.

O próprio IBM Cloud Object Storage observa o comportamento.

Se um objeto passa a ser muito utilizado.

Ele otimiza automaticamente.

Quando deixa de ser acessado.

Também ajusta automaticamente.

Sem intervenção humana.


Imagine um portal de notícias.

Na segunda-feira:

todos querem ler sobre economia.

Na terça-feira:

a notícia mais acessada muda completamente.

O Smart Tier acompanha essa mudança.

Automaticamente.


Standard

Essa é a camada tradicional.

Ideal para aplicações que necessitam acesso frequente.

Exemplos:

  • aplicações web

  • APIs REST

  • microsserviços

  • sistemas bancários

  • imagens de produtos

  • vídeos sob demanda

É o equivalente ao DASD de produção no Mainframe.

Alta disponibilidade.

Resposta imediata.

Baixa latência.


Vault

Agora começamos a economizar dinheiro.

O Vault foi criado para dados pouco acessados.

Talvez uma vez por mês.

Ou ainda menos.

Exemplos:

  • backups operacionais

  • documentos antigos

  • contratos encerrados

  • projetos concluídos

Os dados continuam disponíveis.

Mas a infraestrutura utilizada é otimizada para reduzir custos.


Cold Vault

O Cold Vault representa um nível ainda mais econômico.

Aqui a IBM assume que os arquivos serão consultados poucas vezes por ano.

É perfeito para:

  • arquivos históricos

  • fotografias antigas

  • vídeos institucionais

  • backups anuais

  • documentos fiscais

Você continua tendo acesso.

Mas pagando muito menos.


Archive

Chegamos ao nível mais barato.

Archive.

Aqui a filosofia muda completamente.

A IBM assume que você praticamente nunca utilizará esses arquivos.

Eles permanecem extremamente seguros.

Porém.

Caso precise recuperá-los.

Será necessário aguardar.

Isso reduz drasticamente o custo.


Accelerated Archive

Existe uma situação intermediária.

Imagine uma auditoria.

Ou um desastre.

Você precisa restaurar rapidamente.

Mas não imediatamente.

Nesse caso existe o Accelerated Archive.

Tempo típico de recuperação:

aproximadamente duas horas.

Excelente para:

  • Disaster Recovery

  • Auditorias

  • Compliance


Archive Tradicional

Já o Archive tradicional possui recuperação em torno de doze horas.

Pode parecer muito.

Mas pense.

Se o documento ficou guardado durante oito anos.

Esperar algumas horas não representa problema algum.

Em troca.

O custo é extremamente reduzido.


O ciclo de vida dos dados

Um dos recursos mais poderosos do IBM Cloud Object Storage é a automação.

Você define regras.

Por exemplo:

Após 30 dias.

Migrar para Standard.

Após 90 dias.

Migrar para Vault.

Após 180 dias.

Migrar para Cold Vault.

Após um ano.

Migrar para Archive.

Tudo ocorre automaticamente.

Sem scripts.

Sem operadores.

Sem intervenção humana.


A analogia perfeita para um Programador COBOL

Imagine um JOB Batch.

Logo após sua execução.

O relatório permanece no spool.

Depois.

Vai para um dataset.

Após alguns dias.

É arquivado.

Depois.

Migrado para HSM.

Mais tarde.

Vai para fita.

Anos depois.

Pode ser restaurado.

Esse processo já existe há décadas.

A nuvem apenas utiliza a mesma lógica.


Data Lake

Os Data Lakes representam outro excelente exemplo.

Imagine um Data Lake contendo:

5 Petabytes.

Todos os dias.

Apenas 8% dos dados são realmente utilizados.

Os outros 92% permanecem armazenados.

Sem qualquer acesso.

Por que pagar armazenamento Premium para tudo?

Não faz sentido.

A IBM permite mover automaticamente os dados antigos para camadas mais econômicas.


Inteligência Artificial

A IA está mudando completamente o perfil dos armazenamentos.

Antes.

Os sistemas armazenavam documentos.

Hoje.

Também armazenam:

  • embeddings

  • vetores

  • modelos treinados

  • checkpoints

  • datasets

  • imagens

  • vídeos

  • áudios

Tudo isso aumenta exponencialmente o volume de dados.

Sem gerenciamento inteligente.

Os custos explodem.


Segurança

Não basta ser barato.

O IBM Cloud Object Storage continua oferecendo:

  • criptografia

  • alta durabilidade

  • redundância geográfica

  • controle de acesso

  • versionamento

  • políticas de retenção

  • proteção contra exclusão acidental

Ou seja.

Economizar não significa abrir mão da segurança.


Comparando com outros provedores

A IBM não está sozinha.

Todos os grandes provedores seguem filosofia semelhante.

Amazon S3 possui:

  • Standard

  • Intelligent Tiering

  • Glacier

  • Deep Archive

Azure Blob Storage oferece:

  • Hot

  • Cool

  • Cold

  • Archive

Google Cloud Storage trabalha com:

  • Standard

  • Nearline

  • Coldline

  • Archive

A diferença da IBM está em dois pontos muito fortes:

  • forte integração com ambientes corporativos e IBM Z;

  • modelo One Rate, que reduz a complexidade de cobrança para cargas intensivas.


O que um Programador COBOL pode aprender com isso?

Talvez você esteja pensando:

"Eu programo COBOL. Por que preciso entender armazenamento em nuvem?"

Porque o papel do desenvolvedor mudou.

Hoje espera-se que um programador compreenda não apenas a lógica de negócio, mas também como suas decisões impactam infraestrutura, desempenho e custos. Um programa COBOL que gera milhões de arquivos temporários, uma rotina Batch que produz grandes volumes de logs ou um processo de integração que envia documentos para um Data Lake influenciam diretamente o consumo de armazenamento e, consequentemente, o orçamento da empresa.

Da mesma forma que aprendemos a otimizar acesso a VSAM, reduzir I/O em Db2 ou organizar datasets para melhorar performance no z/OS, agora também precisamos pensar em Data Lifecycle Management. Um desenvolvedor que entende quando um dado deve permanecer em uma camada ativa ou migrar para uma camada de menor custo agrega valor à arquitetura como um todo.


Conclusão

O IBM Cloud Object Storage representa muito mais do que um serviço para guardar arquivos. Ele materializa uma filosofia que os profissionais de Mainframe conhecem há décadas: os dados evoluem ao longo do tempo e sua infraestrutura deve evoluir junto com eles.

A proposta da IBM é clara: manter dados ativos em camadas de alta performance, mover automaticamente informações menos utilizadas para níveis de menor custo e preservar dados históricos com segurança e conformidade, sem desperdiçar recursos. Com planos como One Rate, Smart Tier, Standard, Vault, Cold Vault e Archive, as organizações conseguem equilibrar desempenho, previsibilidade financeira e governança.

Para o Programador COBOL Padawan, essa é uma oportunidade de perceber que muitos conceitos considerados "novos" na nuvem têm raízes profundas no universo IBM Z. O gerenciamento hierárquico de armazenamento, a migração automática entre camadas e a otimização baseada no ciclo de vida dos dados já faziam parte da cultura dos grandes sistemas corporativos muito antes da explosão da computação em nuvem.

No fim das contas, a tecnologia muda, os nomes evoluem e as plataformas se transformam. Porém, a boa engenharia continua seguindo os mesmos princípios: armazenar com inteligência, processar com eficiência e investir recursos apenas onde eles realmente geram valor. Esse é o tipo de visão arquitetural que transforma um simples programador em um profissional capaz de projetar soluções preparadas para o futuro. Afinal, no Bellacosa Mainframe, aprendemos que a experiência acumulada do Mainframe continua iluminando o caminho da computação moderna.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...