Translate

quinta-feira, 30 de julho de 2026

Jogador Nº 1 — A Caçada pelo Algoritmo Perdido do LinkedIn


Bellacosa Mainframe e a cacada ao algoritmo perdido para upar no linkedin

☕ Um Café no Bellacosa Mainframe

Jogador Nº 1 — A Caçada pelo Algoritmo Perdido do LinkedIn

Como Attention Quality, reputação técnica e IBM Champions estão mudando as regras do marketing no mundo mainframe

Era uma quinta-feira aparentemente comum no grande datacenter da vida corporativa.

Os ventiladores dos servidores continuavam girando. Os JOBs entravam na fila do JES2. O CICS atendia milhares de transações sem pedir aplausos. Em algum lugar, um programa COBOL compilado antes de muitos profissionais nascerem calculava juros, atualizava saldos e mantinha uma instituição financeira funcionando.

Do lado de fora daquele universo, porém, outra máquina havia mudado silenciosamente suas regras.

Não era um IBM z17.

Não era um novo compilador Enterprise COBOL.

Não era uma atualização do Db2, do CICS ou do z/OS.

Era o LinkedIn.

Enquanto empresas, fornecedores, comunidades e especialistas continuavam publicando como haviam feito durante anos, o sistema de distribuição de conteúdo parecia ter trocado seu antigo mapa por outro completamente diferente.

As luzes do painel continuavam acesas.

O botão “Publicar” ainda funcionava.

As pessoas ainda apertavam “Curtir”.

Os departamentos de marketing ainda preparavam seus tradicionais cards azuis e brancos.

Mas alguma coisa havia mudado atrás da tela.

O alcance diminuía.

As páginas corporativas falavam para auditórios cada vez mais vazios.

Os compartilhamentos automáticos dos funcionários deixavam de produzir resultados.

Os links para whitepapers eram lançados no feed como mensagens dentro de garrafas digitais, desaparecendo no oceano antes que alguém os encontrasse.

A maioria não percebeu.

Continuou jogando segundo as regras antigas.

Foi então que surgiu na tela uma mensagem:

VOCÊ ESTÁ USANDO O MANUAL DA VERSÃO ANTERIOR.

Bem-vindo ao OASIS profissional.

Bem-vindo à busca pelo verdadeiro significado de Attention Quality.



Fase 1 — O velho placar de pontuação

Durante muitos anos, o sucesso de uma publicação nas redes sociais parecia fácil de medir.

O placar exibia números familiares:

  • visualizações;

  • impressões;

  • curtidas;

  • seguidores;

  • cliques;

  • compartilhamentos;

  • comentários.

Quanto maiores os números, melhor parecia o resultado.

Era como observar a pontuação de uma máquina de fliperama.

POST PUBLICADO........... 100 pontos
LIKE RECEBIDO............  10 pontos
COMENTÁRIO...............  50 pontos
COMPARTILHAMENTO......... 100 pontos
NOVO SEGUIDOR............ 200 pontos

O marketing digital aprendeu a perseguir esses números.

Criaram-se horários “perfeitos” para publicar.

Inventaram-se fórmulas para títulos.

Hashtags passaram a ser usadas como se fossem comandos mágicos.

Empresas pediam aos funcionários:

“Curtam e compartilhem a postagem da página.”

Surgiram grupos de engajamento, comentários genéricos e redes de pessoas que interagiam umas com as outras não porque o conteúdo fosse interessante, mas porque todos queriam enganar o placar.

Era o equivalente digital de descobrir uma falha em um videogame antigo e ficar acumulando pontos infinitos no mesmo cenário.

O problema é que as plataformas também aprenderam.

Se um usuário consegue reconhecer um comentário vazio como:

“Excelente reflexão!”

um sistema de aprendizado de máquina também pode aprender a reconhecer esse padrão.

Se um profissional compartilha todas as publicações de sua empresa sem adicionar uma palavra, o sistema pode interpretar aquilo não como recomendação genuína, mas como comportamento automatizado.

Se dezenas de contas sempre interagem entre si alguns minutos depois de uma publicação, a plataforma pode detectar a regularidade.

Os velhos truques começaram a perder eficácia.

O placar ainda existia, mas já não mostrava toda a partida.


Fase 2 — A moeda escondida: Attention Quality

Attention Quality, ou Qualidade da Atenção, representa uma mudança profunda.

No antigo modelo, a pergunta era:

Quantas pessoas viram a publicação?

No novo modelo, a pergunta passa a ser:

O que essas pessoas realmente fizeram quando encontraram a publicação?

Uma impressão informa apenas que o conteúdo apareceu em uma tela.

Ela não prova que alguém leu.

Uma curtida informa que uma pessoa apertou um botão.

Ela não prova que a mensagem foi compreendida.

Um seguidor informa que alguém clicou em “seguir”.

Ele não prova que continuará interessado no conteúdo.

A Qualidade da Atenção tenta separar a simples exposição do interesse verdadeiro.

Imagine duas publicações.

Publicação A

Impressões:       25.000
Curtidas:            400
Comentários:           2
Salvamentos:           1
Tempo médio:       2 segundos

Publicação B

Impressões:        4.000
Curtidas:             90
Comentários:          28
Salvamentos:          37
Tempo médio:      48 segundos

À primeira vista, a Publicação A parece vencedora.

Ela alcançou muito mais gente e recebeu mais curtidas.

Contudo, a Publicação B fez as pessoas permanecerem, pensarem, comentarem e guardarem o conteúdo.

Ela alcançou menos olhos, mas ocupou mais cérebros.

Essa é a essência de Attention Quality.


Fase 3 — O dwell time entra no jogo

Um dos sinais mais importantes nessa discussão é o dwell time, ou tempo de permanência.

O LinkedIn já explicou publicamente que utiliza informações relacionadas ao tempo gasto diante de uma publicação para melhorar o ranking do feed. Em um trabalho de engenharia, a plataforma descreveu o uso da previsão de permanência muito curta como um sinal negativo: quando o comportamento indica que as pessoas passam rapidamente pelo conteúdo, isso pode ajudar o sistema a concluir que a publicação não é relevante. (LinkedIn)

Imagine o seguinte comportamento:

Usuário encontra a publicação
          ↓
Para de rolar o feed
          ↓
Lê as primeiras linhas
          ↓
Clica em “ver mais”
          ↓
Permanece por 50 segundos
          ↓
Lê os comentários
          ↓
Salva a publicação

Mesmo que essa pessoa não deixe uma curtida, ela produziu diversos sinais de interesse.

Agora compare:

Usuário encontra a publicação
          ↓
Passa para a próxima em 0,8 segundo

Tecnicamente, ambas podem ter gerado uma impressão.

Mas são impressões completamente diferentes.

É como comparar dois programas COBOL que terminaram com RETURN-CODE 0.

Um processou dez milhões de registros corretamente.

O outro abriu um arquivo vazio, não encontrou nada e terminou.

O código de retorno é igual.

O valor produzido não é.


Fase 4 — O misterioso 360Brew

Em algum ponto dessa história, surgiu o nome 360Brew.

Ele começou a circular como se fosse o novo chefão do LinkedIn: um grande modelo de Inteligência Artificial capaz de compreender conteúdo, contexto, interesses profissionais e comportamento dos usuários.

Há de fato documentação e discussões técnicas sobre uma arquitetura chamada 360Brew, apresentada como um modelo de base voltado a tarefas de recomendação e ranking. Entretanto, é preciso separar a pesquisa técnica das interpretações de marketing que se espalharam posteriormente.

Em 2026, também circularam relatos de que o sistema teria sido apenas testado com um grupo limitado e depois descontinuado, enquanto outras mudanças de arquitetura e ranking permaneceram. Portanto, afirmações como “todo o feed agora é controlado pelo 360Brew” devem ser tratadas com cautela, não como fato definitivamente confirmado. (LinkedIn)

Essa distinção é importante.

O nome do modelo pode mudar.

Uma experiência pode ser encerrada.

Uma arquitetura pode ser substituída.

Mas a direção geral permanece clara: o LinkedIn utiliza sistemas sofisticados de recuperação, recomendação e ranking, baseados em sinais profissionais e padrões de envolvimento, para decidir quais publicações serão mostradas a cada pessoa. A própria engenharia do LinkedIn descreve uma nova geração do feed baseada em sinais profissionais e padrões de engajamento. (LinkedIn)

Em outras palavras:

O easter egg não está no nome do algoritmo.

Está na lógica por trás dele.


Fase 5 — O algoritmo não é um SORT comum

Para um programador COBOL iniciante, pode ser tentador imaginar o feed como um arquivo classificado por pontuação.

Algo assim:

SORT POSTS-FILE
    ON DESCENDING KEY POST-SCORE.

Mas o sistema real é muito mais complexo.

Não existe uma única classificação universal.

O post que aparece em primeiro lugar para você pode nem aparecer para outro profissional.

A classificação depende de fatores como:

  • relacionamento entre as pessoas;

  • histórico de interações;

  • assunto da publicação;

  • área profissional;

  • idioma;

  • interesse demonstrado anteriormente;

  • probabilidade de leitura;

  • probabilidade de interação;

  • relevância temporal;

  • qualidade estimada;

  • possibilidade de spam;

  • variedade necessária no feed.

Uma representação simplificada poderia ser:

POST
  +
RELEVÂNCIA PARA O USUÁRIO
  +
AUTORIDADE DO AUTOR NO ASSUNTO
  +
HISTÓRICO DE RELACIONAMENTO
  +
PROBABILIDADE DE ATENÇÃO
  +
QUALIDADE DA CONVERSA
  -
SINAIS DE SPAM
  -
CONTEÚDO REPETITIVO
  -
ENGAGEMENT BAIT
  =
PONTUAÇÃO PERSONALIZADA

Portanto, não existe apenas um arquivo de entrada e uma chave de ordenação.

É mais parecido com um grande sistema online que consulta inúmeros sinais, calcula probabilidades e monta um feed diferente para cada usuário.

É um CICS da atenção.

Milhões de solicitações.

Milhares de sinais.

Decisões em frações de segundo.


Fase 6 — A página corporativa perde energia

O texto que iniciou nossa investigação apresenta números impressionantes sobre a queda do alcance das páginas de empresas.

Estudos e levantamentos de terceiros divulgados em 2025 e 2026 indicam forte redução no alcance orgânico de páginas corporativas. Alguns relatórios citam alcance médio próximo de 1,6% da base de seguidores e vantagem de até 561% para perfis pessoais, embora esses valores não sejam métricas oficiais universais do LinkedIn e possam variar conforme amostra, setor, período e método de análise. (Ordinal)

É fundamental compreender essa ressalva.

Não devemos transformar números de estudos independentes em constantes gravadas em pedra.

Não existe:

01 LINKEDIN-CONSTANTS.
   05 COMPANY-REACH      PIC 9V9(3) VALUE 0.016.
   05 PERSONAL-BONUS     PIC 9(3)    VALUE 561.

As taxas mudam.

Os setores mudam.

A qualidade do conteúdo muda.

O tamanho da audiência muda.

Entretanto, mesmo que os números exatos variem, o fenômeno observado faz sentido: publicações de pessoas frequentemente produzem mais conversa e identificação do que publicações institucionais.

Uma página corporativa diz:

“Nossa empresa tem o prazer de anunciar uma nova solução inovadora.”

Um especialista diz:

“Passei seis meses tentando resolver este problema. Duas abordagens falharam. A terceira funcionou por um motivo que eu não esperava.”

Qual das duas mensagens você prefere ler?

A primeira parece um comunicado.

A segunda parece uma história.

A primeira pede atenção.

A segunda conquista atenção.



Fase 7 — O exército dos reposts automáticos

Quando as empresas percebem a queda de alcance da página, a reação geralmente é previsível:

“Vamos pedir para todos os funcionários compartilharem.”

Às nove horas da manhã, a página publica.

Às nove e cinco, vinte funcionários apertam o botão de repost.

Às nove e dez, aparecem vinte cópias do mesmo conteúdo no feed.

Nenhum comentário pessoal.

Nenhuma análise.

Nenhuma experiência.

Apenas duplicação.

É como executar vinte vezes o mesmo JOB esperando que o resultado se torne vinte vezes mais inteligente.

//REP001 JOB ...
//STEP01 EXEC PGM=REPOST
//
//REP002 JOB ...
//STEP01 EXEC PGM=REPOST
//
//REP003 JOB ...
//STEP01 EXEC PGM=REPOST

O problema não é compartilhar.

O problema é compartilhar sem acrescentar valor.

Um repost acompanhado de uma experiência real pode funcionar:

“Participei da implementação mencionada nesta publicação. O maior desafio não foi a migração técnica, mas convencer as equipes de que o processo de teste precisava mudar.”

Agora existe contexto.

Existe conhecimento.

Existe autoria.

Existe um motivo para alguém parar e ler.

O funcionário deixou de ser um repetidor da marca e tornou-se uma fonte.



Fase 8 — O mainframe vive preso no mesmo cenário

O mercado mainframe possui uma dificuldade particular: a repetição.

Os eventos usam as mesmas palavras.

As apresentações usam cores semelhantes.

Os fornecedores destacam praticamente os mesmos argumentos:

  • missão crítica;

  • segurança;

  • disponibilidade;

  • escalabilidade;

  • modernização;

  • Inteligência Artificial;

  • milhões de transações;

  • “o mainframe não é legado”;

  • “o mundo ainda roda sobre ele”.

Essas afirmações podem ser verdadeiras.

O problema não é a veracidade.

É a falta de diferenciação.

No OASIS do marketing mainframe, milhares de avatares usam a mesma armadura azul e branca.

Todos carregam o mesmo escudo de cinco noves.

Todos empunham a mesma espada chamada “missão crítica”.

Todos gritam:

“O mainframe não morreu!”

Depois se perguntam por que ninguém parou para ouvir.

Talvez o público não precise de mais uma defesa abstrata do mainframe.

Talvez queira saber:

  • como um S0C7 quase interrompeu o fechamento contábil;

  • por que uma COMMAREA mal dimensionada destruiu uma madrugada;

  • como um programador encontrou um erro em um COPYBOOK de trinta anos;

  • por que uma migração para Git falhou na primeira tentativa;

  • como uma equipe reduziu o tempo de compilação;

  • o que realmente acontece quando um banco atualiza milhões de contas;

  • quais decisões técnicas deram errado;

  • o que um especialista aprendeu depois de vinte anos.

Essas histórias têm aquilo que o algoritmo e as pessoas procuram:

especificidade.


Fase 9 — O IBM Champion como Jogador Nº 1

Aqui encontramos a primeira chave da caça.

O universo mainframe já possui os personagens que o novo sistema de visibilidade favorece.

São os especialistas.

Os instrutores.

Os arquitetos.

Os líderes de comunidade.

Os autores.

Os palestrantes.

Os IBM Champions.

Um IBM Champion não é apenas alguém que conhece tecnologia.

Ele ocupa uma posição especial entre a empresa, a comunidade e o conhecimento.

Ele pode dizer:

“Eu testei.”

“Eu ensinei.”

“Eu vi falhar.”

“Eu implementei.”

“Eu não concordo.”

“Esta documentação não explica o problema inteiro.”

“Para um iniciante, o verdadeiro perigo está aqui.”

Isso vale ouro em um ambiente saturado por textos genéricos.

O programa IBM Champion costuma ser compreendido como reconhecimento por contribuições técnicas e comunitárias.

Mas existe outra leitura possível:

Trata-se também de uma rede distribuída de confiança.

Cada Champion é como um jogador veterano que conhece uma parte diferente do mapa.

Um domina Db2.

Outro entende CICS.

Outro vive no universo de storage.

Outro ensina COBOL.

Outro trabalha com segurança.

Outro conecta mainframe e cloud.

Outro produz laboratórios.

Outro organiza comunidades.

Nenhuma página corporativa consegue reproduzir perfeitamente essa variedade de experiências humanas.

A empresa possui a marca.

O Champion possui a voz.


Fase 10 — A estratégia dos cinco avatares

Imagine uma empresa mainframe com uma única voz pública: o CEO.

Toda comunicação depende dele.

Isso cria um ponto único de falha.

Em COBOL, poderíamos representar assim:

TODAS AS MENSAGENS
        ↓
       CEO
        ↓
      LINKEDIN

Agora imagine uma estrutura com cinco especialistas:

CEO................ Visão de mercado
ARQUITETO........... Decisões técnicas
PROGRAMADOR......... Experiência prática
INSTRUTOR............ Educação
COMMUNITY LEADER.... Conversa com o ecossistema

Cada pessoa fala sobre aquilo que realmente conhece.

Não precisam repetir o mesmo comunicado.

Podem abordar o mesmo tema por perspectivas diferentes.

Exemplo: lançamento de uma ferramenta de testes.

Página da empresa

Publica:

  • anúncio oficial;

  • link;

  • data;

  • funcionalidades;

  • documentação.

Arquiteto

Explica:

“Por que escolhemos testes automatizados antes de modernizar o pipeline.”

Programador

Conta:

“O primeiro teste revelou um comportamento que existia havia doze anos.”

Instrutor

Ensina:

“Três conceitos que um programador COBOL precisa dominar antes de usar a ferramenta.”

Líder de comunidade

Pergunta:

“Por que tantas equipes mainframe ainda tratam teste como uma etapa final?”

Agora não existem cinco cópias.

Existem cinco portas de entrada.


Fase 11 — Links externos e a porta de saída

O texto original afirma que publicações com links externos podem sofrer reduções significativas de alcance.

Estudos independentes frequentemente relatam desempenho inferior para conteúdos que conduzem o usuário para fora da plataforma. Contudo, percentuais exatos, como uma redução fixa de 60%, devem ser tratados como estimativas dependentes de contexto, e não como regra oficial invariável.

A lógica econômica, porém, é simples.

O LinkedIn deseja que o usuário permaneça no LinkedIn.

Um link externo é uma porta de saída.

Isso não significa que você nunca deva usar links.

Significa que o post precisa entregar valor antes de pedir que a pessoa saia.

Estratégia fraca

Novo artigo publicado!

Clique no link para ler.

O usuário precisa sair da plataforma para descobrir se existe algo interessante.

Estratégia melhor

Durante anos tratamos o S0C7 como um simples erro de dados.

Mas, em muitos ambientes, ele revela um problema maior:
a distância entre o layout documentado e o registro realmente recebido.

Neste artigo mostro três casos:

1. campo numérico contaminado;
2. COPYBOOK incompatível;
3. redefinição interpretada incorretamente.

O material completo está no link.

A publicação já ensinou alguma coisa.

O link tornou-se aprofundamento, não isca.


Fase 12 — O tesouro dos comentários reais

Comentários possuem valor porque exigem mais esforço do que curtidas.

Mas nem todo comentário é igual.

Compare:

Muito bom!

com:

Passei por algo semelhante durante uma migração de Endevor
para Git. O problema não foi versionar o fonte COBOL, mas
reproduzir as dependências do processo de build.

O segundo comentário acrescenta conhecimento.

Ele pode gerar resposta.

Pode atrair outro especialista.

Pode iniciar uma conversa técnica.

O post deixa de ser uma placa e vira uma sala.

Relatórios independentes sugerem que a interação inicial pode influenciar a amplificação, mas fórmulas como “três comentários na primeira hora produzem cinco vezes mais alcance” não devem ser consideradas garantias universais. O próprio LinkedIn evita publicar uma receita matemática completa, justamente porque o ranking combina muitos sinais e evolui continuamente.

A lição prática não é:

“Consiga três comentários a qualquer custo.”

A lição é:

“Publique algo que dê às pessoas uma razão verdadeira para comentar.”


Fase 13 — Salvamentos: o inventário secreto

Em videogames, o jogador guarda itens que pretende usar depois.

No LinkedIn, o botão “Salvar” cumpre função semelhante.

Salvar uma publicação pode significar:

  • quero ler com calma;

  • preciso usar isso no trabalho;

  • quero estudar depois;

  • pretendo mostrar para minha equipe;

  • esse exemplo será útil;

  • não quero perder esta referência.

Para um criador técnico, isso é valioso.

Conteúdos que costumam gerar salvamentos incluem:

  • checklists;

  • diagramas;

  • exemplos de código;

  • comandos;

  • comparações;

  • roteiros de estudo;

  • mapas mentais;

  • explicações passo a passo;

  • tabelas de referência;

  • listas de erros;

  • procedimentos de diagnóstico.

Exemplo:

Post esquecível

“O VSAM continua importante nas empresas.”

Post salvável

“Antes de investigar um erro em KSDS, verifique nesta ordem: FILE STATUS, chave, modo de acesso, definição do SELECT, IDCAMS LISTCAT e consistência entre FD e cluster.”

O primeiro expressa uma opinião genérica.

O segundo oferece uma ferramenta.


Fase 14 — O poder dos documentos e carrosséis

Levantamentos de marketing frequentemente apontam documentos em formato carrossel entre os conteúdos de melhor desempenho no LinkedIn, embora o resultado varie segundo audiência e execução. Uma explicação provável é o aumento do tempo de permanência: o usuário precisa avançar por várias páginas, o que produz uma interação mais longa do que simplesmente passar por uma imagem. (LinkedIn)

Para o programador COBOL, um carrossel poderia seguir esta estrutura:

SLIDE 1 — O mistério
“Por que este programa terminou com FILE STATUS 35?”

SLIDE 2 — O significado
Arquivo inexistente ou não localizado.

SLIDE 3 — Primeira verificação
Nome do dataset no JCL.

SLIDE 4 — Segunda verificação
SELECT e ASSIGN.

SLIDE 5 — Terceira verificação
DISP e catálogo.

SLIDE 6 — Exemplo de JCL

SLIDE 7 — Exemplo COBOL

SLIDE 8 — Checklist final

Cada página oferece uma pequena recompensa.

Cada avanço mantém a atenção.

O formato não salva conteúdo ruim, mas pode ajudar conteúdo bom a ser consumido.


Fase 15 — O perigo do texto fabricado

A Inteligência Artificial tornou a produção de conteúdo muito fácil.

É possível gerar cinquenta publicações em alguns minutos.

O problema é que facilidade de produção não significa valor.

Quando milhares de pessoas usam as mesmas estruturas, surgem textos com aparência semelhante:

“No mundo acelerado de hoje…”

“Aqui estão cinco lições poderosas…”

“Concorda? Deixe sua opinião nos comentários.”

“Vamos juntos nessa jornada!”

O feed fica cheio de vozes que parecem ter sido compiladas pelo mesmo programa.

INPUT: TEMA
PROCESS: ADICIONAR FRASES CORPORATIVAS
OUTPUT: POST GENÉRICO

A IA pode ajudar a organizar ideias, revisar linguagem, estruturar argumentos e transformar uma palestra em texto.

Mas a matéria-prima precisa vir de uma pessoa.

A IA não viveu sua madrugada no CPD.

Não discutiu com o change manager.

Não tentou descobrir por que o arquivo tinha um byte a mais.

Não sentiu o silêncio da sala quando alguém perguntou quem havia executado o JOB errado.

Não carregou a lembrança de um sistema antigo que funcionava melhor do que sua substituição “moderna”.

A experiência continua sendo humana.


Fase 16 — O método Bellacosa de Attention Quality

Sem usar esse nome, o estilo Bellacosa Mainframe já trabalha com diversos elementos capazes de aumentar a qualidade da atenção.

1. Criar uma entrada narrativa

Em vez de começar com:

“Neste artigo explicaremos DFSORT.”

começar com:

“Às duas da manhã, o arquivo chegou com dez milhões de registros fora de ordem.”

O leitor entra na cena.

2. Usar referências culturais

Filmes, séries, livros, animes e quadrinhos funcionam como pontos de conexão.

O leitor talvez não conheça SORT FIELDS, mas conhece um pelotão tentando colocar o caos em ordem.

3. Explicar por camadas

Primeiro a metáfora.

Depois o conceito.

Depois o exemplo.

Depois o código.

Depois o caso real.

Isso permite que iniciantes e veteranos encontrem valor no mesmo texto.

4. Criar elementos salváveis

Checklists, comandos, exemplos de JCL e estruturas COBOL fazem o leitor guardar o artigo.

5. Inserir curiosidades e easter eggs

Eles recompensam a atenção.

Quem lê rapidamente recebe a explicação.

Quem lê até o fim encontra algo a mais.

6. Manter uma voz reconhecível

O leitor não encontra apenas informação.

Encontra Bellacosa.

Essa identidade é difícil de substituir.


Fase 17 — Passo a passo para o programador COBOL

Você não precisa virar influenciador.

Não precisa dançar diante de um mainframe.

Não precisa publicar frases motivacionais.

Precisa apenas transformar experiência em conhecimento compartilhável.

Passo 1 — Escolha um problema real

Exemplos:

  • um ABEND;

  • um erro de arquivo;

  • uma dúvida de JCL;

  • uma dificuldade com Git;

  • uma diferença entre COMP e COMP-3;

  • um comportamento inesperado do CICS;

  • uma falha em teste;

  • uma curiosidade histórica.

Passo 2 — Escreva o gancho

Hoje encontrei um S0C7 em uma linha que não realizava
nenhuma operação matemática.

Essa frase cria mistério.

Passo 3 — Explique o contexto

O erro aparecia durante a movimentação de um campo recebido
de um arquivo legado.

Passo 4 — Mostre a investigação

1. Conferi o FILE STATUS.
2. Examinei o layout.
3. Comparei o LRECL.
4. Descobri que o campo estava deslocado.

Passo 5 — Entregue a lição

O S0C7 aparecia no MOVE, mas a causa estava na interpretação
incorreta do registro.

Passo 6 — Acrescente um artefato útil

Pode ser:

  • código;

  • checklist;

  • diagrama;

  • comando;

  • comparação;

  • pergunta técnica específica.

Passo 7 — Converse nos comentários

Não responda apenas:

“Obrigado!”

Aprofunde.

Pergunte sobre o ambiente.

Compare experiências.

Explique exceções.

Os comentários podem se tornar uma continuação do artigo.


Fase 18 — Métricas que realmente interessam

Para avaliar Attention Quality, não observe apenas impressões.

Crie um painel mais completo:

ALCANCE
Quantas pessoas receberam a publicação?

RETENÇÃO
A publicação fez as pessoas permanecerem?

EXPANSÃO
Quantas abriram “ver mais”?

CONVERSA
Os comentários possuem conteúdo real?

SALVAMENTO
A publicação foi guardada para consulta?

COMPARTILHAMENTO
Alguém considerou útil enviar para outra pessoa?

CONVERSÃO
A publicação trouxe visitas, inscrições, contatos ou convites?

REPUTAÇÃO
As pessoas passaram a associar seu nome ao assunto?

A última métrica é a mais difícil de visualizar.

Também pode ser a mais valiosa.

Quando alguém pensa em COBOL e lembra de você, ocorreu uma conversão de reputação.

Quando uma empresa procura um instrutor e recebe seu nome como indicação, o conteúdo cumpriu uma missão muito maior do que acumular curtidas.


O easter egg final — Halliday não escondeu três chaves

No romance e no filme Jogador Nº 1, os participantes procuram chaves escondidas pelo criador do OASIS.

No universo da Attention Quality, também existem três chaves.

A Chave de Cobre — Atenção

Faça a pessoa parar.

Use uma pergunta, uma história, uma contradição ou um problema real.

A Chave de Jade — Conhecimento

Entregue algo que justifique o tempo investido.

Uma explicação.

Uma solução.

Um aprendizado.

A Chave de Cristal — Confiança

Publique com consistência, honestidade e identidade.

Admita erros.

Explique limites.

Não finja ter vivido o que não viveu.

A atenção abre a porta.

O conhecimento mantém a pessoa na sala.

A confiança faz com que ela volte.


Epílogo — O verdadeiro Jogador Nº 1

O futuro do marketing mainframe provavelmente não pertencerá à empresa com o maior número de cards publicados.

Nem àquela que repetir mais vezes que o mainframe não é legado.

Nem à que possuir mais hashtags.

Nem à que obrigar todos os funcionários a compartilhar o mesmo anúncio.

Pertencerá às organizações capazes de reconhecer que seu maior ativo de comunicação já está dentro de casa.

É o programador que conhece os detalhes.

É o operador que viu a madrugada dar errado.

É o arquiteto que sabe por que uma decisão foi tomada.

É o instrutor que consegue explicar.

É o Champion que já possui a confiança da comunidade.

É a pessoa que escreve algo que apenas ela poderia escrever.

A página corporativa continuará tendo utilidade.

Ela será o catálogo.

O arquivo oficial.

A vitrine.

O lugar dos anúncios, lançamentos, vagas e documentos.

Mas a descoberta, a conversa e a construção da reputação acontecerão cada vez mais por meio das pessoas.

Porque ninguém cria relacionamento com um logotipo.

Ninguém conta uma história inesquecível sobre uma página empresarial.

Ninguém confia em um degradê azul.

Confiamos em nomes.

Em rostos.

Em trajetórias.

Em pessoas que demonstraram conhecimento antes de tentar vender alguma coisa.

O algoritmo pode mudar novamente amanhã.

O 360Brew pode existir, desaparecer, ser substituído ou renascer com outro nome.

Os percentuais de alcance podem subir ou cair.

Os carrosséis podem perder espaço para vídeos.

Os links podem ser tratados de outra maneira.

Mas uma regra provavelmente continuará valendo:

A conta nunca foi a empresa. A conta sempre foi a pessoa que estava por trás dela.

E talvez esse seja o maior easter egg escondido no LinkedIn.

O Jogador Nº 1 não é quem descobriu como enganar o algoritmo.

É quem compreendeu que não precisa enganá-lo.

Precisa apenas conquistar a atenção de seres humanos reais, compartilhar conhecimento verdadeiro e construir uma reputação que nenhum ajuste de ranking consiga apagar.

No final da partida, o prêmio não é um milhão de impressões.

É ser lembrado.

E, no grande OASIS do mainframe, onde sistemas antigos sustentam o futuro e veteranos carregam histórias que nunca foram documentadas, ainda existem milhares de aventuras esperando que alguém aperte o botão:


https://eljefemidnightlunch.blogspot.com/2026/03/badge-ibm-champion-class-2026-gratidao.html

quarta-feira, 29 de julho de 2026

IBM zSkill Fest 2026 : O Caso do Evento que Todo Profissional IBM Z Deveria Investigar

Bellacosa Mainframe orgulhosamente apresenta zSkill Fest 2026

🕵️☕ Um Café no Bellacosa Mainframe

O Caso do Evento que Todo Profissional IBM Z Deveria Investigar

"Elementar, meu caro Watson..."

Sherlock Holmes jamais ignoraria uma pista importante.

Então permita-me fazer uma pergunta...

🔎 Você já garantiu sua participação no ZSkillsFest 2026?

Falta menos de uma semana para o início de um dos maiores encontros da comunidade IBM Z do mundo, reunindo milhares de profissionais, estudantes, especialistas, IBM Champions, arquitetos, desenvolvedores, administradores de sistemas e apaixonados pelo Mainframe.

Se você acredita que conhecimento é poder, então este é o lugar onde novos capítulos da história do IBM Z serão escritos.

🧐 O mistério não é "vale a pena participar?".

O verdadeiro mistério é...

Por que você ainda não se registrou?

Mais de 4.000 participantes já confirmaram presença para aprender, compartilhar experiências, conhecer novidades e fortalecer sua rede de contatos com profissionais de diversos países.

Se você já está inscrito...

💬 Escreva nos comentários:

"Eu já estou inscrito!"

E melhor ainda...

🔁 Compartilhe esta publicação e convide mais pessoas para essa grande investigação tecnológica.

Se ainda não fez sua inscrição...

🎩 Considere este o seu convite oficial.

A comunidade IBM Z sempre cresce quando compartilhamos conhecimento.

Nos encontramos no ZSkillsFest 2026!



━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🚀 INSCREVA-SE AGORA
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

📌 Registro Oficial
IBM.biz/zsf2026

📌 Formulário de Inscrição
https://airtable.com/app4e1B2CCUAsPp9c/paguvQoyaG8u4jH1a/form

📌 Página Oficial do Evento
https://community.ibm.com/community/user/events/event-description?CalendarEventKey=b9bca5b1-51ec-4102-a1a7-019e8ffdc8fc&CommunityKey=e7b7d299-8509-4572-8cf1-c1112684644f


🔍 Porque, no universo do Mainframe, a maior descoberta nunca acontece sozinho... ela acontece em comunidade.

#IBMZ #Mainframe #ZSkillsFest2026 #COBOL #zOS #CICS #Db2 #RACF #DevOps #IBMChampion #BellacosaMainframe

O Portal Stargate do IBM Z : Descobre que Git, DevOps e CI/CD Não São Tecnologias Alienígenas.

 

Bellacosa Mainframe e o portal stargata para adentrar no novo mundo do desenvolvimento mainframe

☕ Um Café no Bellacosa Mainframe

O Portal Stargate do IBM Z

Quando um Programador COBOL Descobre que Git, DevOps e CI/CD Não São Tecnologias Alienígenas... São os Endereços para Viajar Entre Galáxias de Software

"Há milhares de anos, os Antigos construíram uma rede capaz de conectar mundos instantaneamente. No século XXI, engenheiros criaram outra rede capaz de conectar milhares de aplicações corporativas espalhadas pelo planeta. Seu nome não é Stargate... é Pipeline DevOps."



Prólogo — O Chevron Número Sete

O relógio marcava 03:27 da madrugada.

No Centro de Processamento de Dados, apenas o z16 permanecia acordado.

Milhões de transações cruzavam seus canais FICON.

Cartões eram autorizados.

PIX eram liquidados.

Voos eram confirmados.

Hospitais consultavam prontuários.

Bolsa de valores processava ordens.

E, em algum lugar daquele universo invisível, um jovem programador COBOL fazia sua primeira alteração em um COPYBOOK.

Ele acreditava que bastava alterar o código.

Mas o veterano apenas sorriu.

— Você ainda acha que um programa vive sozinho...

Naquele instante, uma enorme estrutura metálica começou a girar.

Não era um Stargate.

Era uma Pipeline.

Os chevrons começaram a travar.

Git...

DBB...

GitLab...

Jenkins...

ZUnit...

Deployment...

Produção.

O portal foi ativado.

E a verdadeira aventura começou.



Episódio 1 — O IBM Z é um Planeta

Em Stargate SG-1, cada planeta possui sua própria civilização.

No mundo IBM Z acontece exatamente o mesmo.

Cada ambiente é praticamente um planeta independente.

Desenvolvimento

↓

Integração

↓

Homologação

↓

Pré-Produção

↓

Produção

Cada um possui:

  • regras

  • segurança

  • bases de dados

  • usuários

  • aplicações

  • auditoria

  • monitoramento

Mover software entre esses mundos nunca foi simples.

Durante décadas isso era feito manualmente.

Hoje quem controla os portais é o DevOps.



Episódio 2 — O DHD Chama-se Git

Em Stargate existe um equipamento chamado DHD (Dial Home Device).

Ele controla o portal.

Sem ele, ninguém viaja.

No desenvolvimento moderno existe um equivalente.

Seu nome é Git.

Muitos iniciantes pensam que Git serve apenas para "guardar arquivos".

Isso seria como dizer que o DHD serve apenas para acender luzes.

Git controla praticamente toda a história da aplicação.

Ele registra:

  • quem alterou

  • quando alterou

  • por que alterou

  • quem aprovou

  • qual versão entrou em produção

  • qual versão voltou (rollback)

Cada commit representa um novo endereço gravado na memória do portal.


Curiosidade Bellacosa ☕

Em projetos antigos, a "verdade absoluta" era um PDS ou um Endevor.

Hoje, em arquiteturas modernas, a verdade oficial normalmente reside no repositório Git. Os datasets do z/OS continuam essenciais para compilação e execução, mas o histórico e a colaboração passam a ser organizados pelo controle de versão.


Episódio 3 — A Linguagem dos Antigos

Existe um problema que todo iniciante descobre cedo ou tarde.

Mainframe fala EBCDIC.

O restante do planeta fala ASCII ou UTF-8.

Imagine Daniel Jackson tentando traduzir uma inscrição dos Antigos.

Se errar um símbolo...

Toda a tradução muda.

O mesmo acontece durante uma migração para Git.

Sem conversão correta podemos encontrar situações como:

Antes

AÇÃO

Depois

AÇÃO

Parece pequeno.

Na prática pode causar:

  • conflitos de merge

  • comentários ilegíveis

  • documentação perdida

  • comparações falsas

  • arquivos inutilizados

Por isso existe toda uma estratégia de conversão de code pages.

É um dos assuntos mais importantes do curso.


Episódio 4 — O SGC Chama-se GitLab

No universo Stargate existe o Stargate Command.

É dali que todas as missões são coordenadas.

No DevOps existe um equivalente.

GitLab.

Ele não é apenas um servidor Git.

Ele funciona como uma base operacional.

Ali encontramos:

  • Issues

  • Merge Requests

  • Pipelines

  • Releases

  • Segurança

  • Artefatos

  • Auditoria

Quando um desenvolvedor envia um commit...

É como uma equipe SG retornando de uma missão.

Tudo será analisado.


Episódio 5 — O Iris é a Pipeline

No Stargate existe um Iris.

Ele impede que qualquer coisa atravesse o portal sem autorização.

No DevOps existe um Iris muito parecido.

A Pipeline.

Ela verifica automaticamente:

✔ O código compila?

✔ Os testes passaram?

✔ Existe vulnerabilidade?

✔ O padrão foi respeitado?

✔ Há aprovação?

Se alguma resposta for negativa...

O portal permanece fechado.

Nenhum software chega à produção.


Episódio 6 — Os Asgard Chamam-se DBB

Os Asgard eram extremamente inteligentes.

Criavam tecnologia capaz de resolver problemas gigantescos.

O DBB (Dependency Based Build) faz algo semelhante.

Imagine um banco com:

  • 18.000 programas COBOL

  • 6.000 COPYBOOKS

  • centenas de mapas BMS

  • milhares de JCLs

Você altera apenas um COPYBOOK.

A pergunta é inevitável.

Quem precisa ser recompilado?

Todos?

Claro que não.

O DBB investiga as dependências.

Ele descobre:

Programa A

↓

COPY X

↓

Programa B

↓

Programa C

↓

Programa D

Somente quem realmente depende daquela alteração será recompilado.

Isso economiza:

  • CPU

  • MIPS

  • tempo

  • dinheiro


Easter Egg ☕

Assim como os Asgard dominavam conhecimento acumulado durante milênios, o DBB concentra décadas de experiência em engenharia de build para IBM Z. O verdadeiro "superpoder" não é compilar mais rápido, mas evitar compilar o que não mudou.


Episódio 7 — Thor Apresenta o zAppBuild

O DBB precisa de alguém dizendo como construir a aplicação.

Esse papel pertence ao zAppBuild.

Ele funciona como um roteiro.

Compile

↓

Link

↓

Bind Db2

↓

Package

↓

Deploy

Sem improviso.

Sem dezenas de JCL diferentes.

Tudo padronizado.


Episódio 8 — O Antigo Conhecimento Perdido

Imagine encontrar um programa COBOL criado em 1987.

Ninguém sabe:

  • quem chama

  • quem utiliza

  • quais tabelas acessa

  • quais COPYBOOKS dependem dele

É exatamente aí que entra o ADDI.

Application Discovery and Delivery Intelligence.

Ele funciona como Daniel Jackson.

Escava.

Relaciona.

Traduz.

Reconstrói.

Mostra mapas gigantescos das dependências.

Você finalmente entende uma aplicação criada há quarenta anos.


Episódio 9 — A Equipe SG-1 Chama-se Jenkins

Em Stargate cada missão possui uma equipe.

No DevOps quem coordena diversas missões pode ser o Jenkins.

Ele recebe a ordem.

Executa.

Compila.

Chama scripts.

Executa testes.

Publica resultados.

Tudo automaticamente.

Em muitos ambientes ele trabalha lado a lado com GitLab, Azure DevOps ou outras plataformas de automação.



Episódio 10 — Outros Mundos: Azure e Wazi

O IBM Z já não vive isolado.

Hoje conversa naturalmente com:

  • Azure

  • OpenShift

  • Kubernetes

  • GitHub

  • GitLab

  • APIs REST

  • microsserviços

O Wazi as a Service demonstra exatamente isso.

Você pode desenvolver aplicações IBM Z utilizando ferramentas modernas hospedadas em nuvem.

É como atravessar o Stargate para outro planeta...

Sem abandonar seu idioma.


Episódio 11 — O Campo de Treinamento Tok'ra

Uma civilização não evolui sem treinamento.

Durante muito tempo acreditava-se que COBOL não fazia testes unitários.

Isso mudou.

Com o ZUnit podemos automatizar testes de programas COBOL.

Imagine uma alteração aparentemente simples.

Antes:

Alterar

↓

Compilar

↓

Mandar para homologação

Hoje:

Commit

↓

Build

↓

ZUnit

↓

Resultado

↓

Deploy

Se algum teste falhar...

A missão é cancelada.


Dica do Coronel O'Neill

"Confiar apenas porque compilou é como atravessar um Stargate sem verificar o planeta de destino."

Teste sempre.


Episódio 12 — O Conselho dos Antigos

Chega o momento do Deployment.

Aqui muitos iniciantes imaginam que basta copiar datasets.

Não.

Deployment moderno envolve:

  • empacotamento

  • aprovação

  • auditoria

  • versionamento

  • rollback

  • rastreabilidade

Cada release recebe identidade própria.

Nada entra em produção sem deixar um rastro.


Episódio 13 — As Coordenadas Galácticas (Branches)

Em Stargate cada planeta possui um endereço formado por chevrons.

No Git acontece algo parecido.

Cada branch representa um caminho de desenvolvimento.

main

├── develop

├── release

├── feature

└── hotfix

Cada uma possui finalidade específica.

Misturar tudo seria como discar símbolos aleatórios no Stargate.

Você provavelmente chegaria ao planeta errado.


Episódio 14 — A Cidade Perdida dos Antigos

Muitas empresas possuem aplicações criadas nos anos 1970.

Décadas de evolução.

Milhões de linhas COBOL.

Esses sistemas lembram Atlantis.

Imensos.

Poderosos.

Pouco compreendidos.

Ferramentas como o ADDI ajudam a revelar sua arquitetura, permitindo que equipes modernas façam mudanças com muito mais segurança.


Episódio 15 — O Oráculo da Performance

No fim da jornada surge outro personagem importante.

O APA (Application Performance Analyzer).

Compilar não basta.

Executar também não.

É preciso executar bem.

O APA mostra:

  • consumo de CPU

  • hotspots

  • chamadas excessivas

  • gargalos

  • desperdícios

É como um sensor Asgard analisando cada detalhe de uma nave antes da decolagem.



A Grande Missão DevOps

Quando unimos todas as tecnologias do curso, obtemos uma cadeia contínua de entrega de software:

Programador COBOL
        │
        ▼
 VS Code / IDz
        │
        ▼
      Git
        │
        ▼
 Merge Request
        │
        ▼
 GitLab / Jenkins
        │
        ▼
 DBB + zAppBuild
        │
        ▼
     Build
        │
        ▼
     ZUnit
        │
        ▼
      ADDI
        │
        ▼
  Empacotamento
        │
        ▼
 Deploy Automatizado
        │
        ▼
   CICS • Batch • Db2 • IMS
        │
        ▼
 APA • Monitoramento

Observe como praticamente tudo ocorre de maneira automática. O desenvolvedor continua sendo indispensável, mas passa a dedicar mais tempo ao desenho da solução e menos às tarefas repetitivas.


Passo a Passo para o Iniciante

Se você está começando agora no mundo IBM Z, esta é uma sequência de estudos que faz muito sentido:

  1. Aprenda bem COBOL, JCL, TSO/ISPF e os fundamentos do z/OS.

  2. Entenda VSAM, Db2, CICS e como uma aplicação corporativa é estruturada.

  3. Estude Git profundamente: commits, branches, merge, rebase e revisão de código.

  4. Aprenda conceitos de CI/CD antes de decorar ferramentas específicas.

  5. Conheça DBB e zAppBuild para compreender como builds modernos funcionam.

  6. Estude ZUnit e incorpore testes automatizados desde cedo.

  7. Explore o ADDI para entender impacto de mudanças em aplicações legadas.

  8. Aprenda uma plataforma de orquestração, como GitLab ou Jenkins.

  9. Entenda estratégias de deployment, rollback e versionamento.

  10. Finalmente, aprofunde-se em performance, observabilidade e engenharia de plataformas.

Essa sequência faz com que cada etapa tenha um propósito claro e evita a sensação de aprender tecnologias desconectadas.


Curiosidades que Pouca Gente Conhece

  • O maior desafio de uma pipeline IBM Z normalmente não é compilar COBOL, mas entender corretamente as dependências entre milhares de componentes.

  • Muitos bancos executam centenas ou milhares de pipelines diariamente sem que clientes percebam que há mudanças em produção.

  • Um único COPYBOOK compartilhado pode impactar centenas de programas diferentes.

  • Ferramentas de descoberta de aplicações, como o ADDI, ajudam equipes que nunca participaram do desenvolvimento original a compreender sistemas com décadas de evolução.

  • O movimento Open Mainframe Project acelerou a integração entre tecnologias abertas e o ecossistema IBM Z, aproximando práticas modernas de engenharia de software do ambiente corporativo tradicional.


Conclusão — O Oitavo Chevron

No último episódio de muitas temporadas de Stargate, descobrimos que o verdadeiro objetivo nunca foi apenas atravessar portais.

Era compreender uma rede inteira de civilizações.

O mesmo acontece com o IBM Z.

O programador iniciante costuma acreditar que aprender COBOL é suficiente.

Depois percebe que existe Db2.

Em seguida descobre CICS.

Depois VSAM.

Mais tarde encontra Git.

Pipeline.

DBB.

GitLab.

Jenkins.

ZUnit.

ADDI.

Deployment.

Performance.

Observabilidade.

Cada tecnologia parece um novo planeta.

Mas, pouco a pouco, surge uma revelação: todas fazem parte de uma única galáxia.

O verdadeiro arquiteto não conhece apenas uma linguagem de programação. Ele entende como cada componente conversa com os demais, como uma alteração percorre toda a cadeia de entrega e como manter sistemas que processam bilhões de transações com segurança e previsibilidade.

No fim, o maior portal nunca foi o Stargate.

Foi a mudança de mentalidade.

Quando você deixa de enxergar um simples programa COBOL e passa a visualizar todo o ecossistema que o cerca, o oitavo chevron finalmente trava... e uma nova galáxia de oportunidades se abre diante de você.

Easter Egg Bellacosa: se um dia você ouvir um veterano dizer "o programa compilou, mas a pipeline não deixou passar", lembre-se do Iris do Stargate. O código pode estar pronto para atravessar o portal, mas somente aplicações que sobreviverem a todas as verificações chegam ao destino final: a produção do IBM Z.

terça-feira, 28 de julho de 2026

IBM COBOL Elevate for z/OS: CSI Las Vegas no Laboratório do Código Legado

 

Bellacosa Mainframe apresenta o Ibm cobol elevate for zos

☕ Um Café no Bellacosa Mainframe

IBM COBOL Elevate for z/OS: CSI Las Vegas no Laboratório do Código Legado

Quando um Programador COBOL Descobre que o Verdadeiro Crime Não Está no Código Antigo — Está em Executá-lo Durante Décadas sem Investigar Onde a CPU Desaparece

Era madrugada no Data Center de Las Vegas.

As luzes do corredor piscavam sobre os corredores de armazenamento. O ruído constante da refrigeração lembrava o motor de uma aeronave que jamais poderia pousar. Milhões de transações cruzavam o ambiente enquanto quase toda a cidade dormia.

Cartões eram autorizados.

Reservas de hotéis eram confirmadas.

Pagamentos eram processados.

Apólices eram calculadas.

Contas bancárias eram atualizadas.

No centro daquele ecossistema havia um IBM Z executando programas COBOL que talvez tivessem sido escritos antes de alguns integrantes da equipe de desenvolvimento nascerem.

Tudo parecia normal.

Até que o alarme apareceu:

CPU CONSUMPTION ABOVE EXPECTED LEVEL

Gil Grissom aproximou-se do terminal 3270, observou os números e disse:

— A máquina não mente. Mas os números também não confessam sozinhos.

Ao lado dele, um jovem programador COBOL examinava um programa com 14 mil linhas e perguntava:

— Devemos recompilar tudo?

Grissom colocou os óculos, aproximou-se da tela e respondeu:

— Antes de alterar a cena do crime, precisamos descobrir o que realmente aconteceu.

É exatamente nesse ponto que entra o IBM COBOL Elevate for z/OS.

Anunciado pela IBM em 7 de julho de 2026, o produto foi apresentado como uma solução integrada para otimização, modernização, análise de desempenho e aceleração de upgrades de aplicações COBOL críticas. A primeira versão anunciada é o IBM COBOL Elevate for z/OS 1.1, com disponibilidade geral planejada para 18 de setembro de 2026. (IBM)

Mas o que isso realmente significa?

Seria apenas mais uma ferramenta de análise?

Um novo compilador?

Um profiler?

Uma solução de inteligência artificial?

Um produto de migração?

Ou uma tentativa da IBM de criar uma espécie de laboratório forense para investigar milhares de programas COBOL antes de alguém decidir alterá-los?

Coloque as luvas.

Isole a área.

Faça uma cópia do load module.

A investigação vai começar.



Capítulo 1 — A vítima não era o COBOL

Durante anos, consultorias, fabricantes e apresentações de modernização repetiram uma narrativa aparentemente irresistível:

“O problema é que o sistema foi escrito em COBOL.”

Essa afirmação soa moderna, mas frequentemente está errada.

O COBOL não é necessariamente o problema.

O verdadeiro problema pode estar em:

  • programas compilados há muitos anos;

  • versões antigas do compilador;

  • opções inadequadas de compilação;

  • módulos que consomem CPU desnecessariamente;

  • dependências que ninguém documentou;

  • chamadas repetitivas;

  • algoritmos inadequados para os volumes atuais;

  • programas recompilados parcialmente;

  • aplicações sem inventário confiável;

  • ausência de dados que mostrem onde vale a pena investir.

Imagine uma aplicação criada em 1996.

Naquele período, ela processava 100 mil registros por noite. Em 2026, executa a mesma lógica sobre 80 milhões de registros.

O código pode estar correto.

O resultado pode estar correto.

O batch pode terminar.

Mas um trecho executado uma única vez em 1996 talvez hoje seja repetido 80 milhões de vezes.

O crime não foi escrever o programa daquela forma.

O crime foi aumentar o volume por trinta anos sem voltar à cena para procurar novas evidências.


Capítulo 2 — A ficha do suspeito

Nome

IBM COBOL Elevate for z/OS

Release inicial anunciado

Versão 1.1

Data do anúncio

7 de julho de 2026

Disponibilidade geral planejada

18 de setembro de 2026

Ambiente principal

Aplicações COBOL executadas no IBM Z sob z/OS.

Missão declarada

Ajudar organizações a modernizar aplicações COBOL críticas por meio de:

  • otimização automatizada de desempenho;

  • aceleração de upgrades de compiladores;

  • análise de inventário e prontidão;

  • assistência por inteligência artificial;

  • informações de desempenho ligadas ao código-fonte;

  • redução do risco operacional;

  • aumento da produtividade das equipes.

A página oficial do produto resume a proposta como uma forma de revitalizar aplicações COBOL, obter ganhos contínuos de performance, acelerar upgrades do compilador e melhorar a qualidade do código, procurando minimizar o risco operacional. (IBM)

Portanto, o Elevate não deve ser entendido apenas como “mais uma ferramenta COBOL”.

Ele é apresentado como uma solução composta por três capacidades complementares:

  1. Accelerate

  2. Upgrade

  3. Performance Insights

Esses três componentes correspondem a três perguntas que assombram qualquer grande ambiente COBOL:

1. O que está consumindo recursos?
2. O que precisa ser atualizado?
3. Onde devemos agir primeiro?

Capítulo 3 — A cena do crime corporativa

Considere um banco fictício chamado Cassino Federal de Las Vegas.

Seu inventário contém:

42.000 programas COBOL
18 milhões de linhas de código
7.500 copybooks
12.000 jobs batch
3.800 transações CICS
2.400 módulos Db2
850 integrações MQ
Programas compilados em diferentes gerações

O diretor pergunta:

— Quanto ganharemos se atualizarmos todos os programas?

Ninguém sabe.

Em seguida, ele pergunta:

— Quais programas devemos recompilar primeiro?

Ninguém sabe.

Depois:

— Quais módulos realmente consomem mais CPU?

A equipe mostra relatórios de SMF, RMF, CICS, Db2, ferramentas de monitoramento e planilhas.

Então surge outra pergunta:

— Qual linha do programa provoca esse consumo?

Silêncio.

Esta é uma dificuldade clássica da engenharia de performance.

Os relatórios operacionais mostram que algo consumiu recursos. Entretanto, transformar a métrica operacional em uma ação concreta sobre o código pode exigir um especialista que entenda simultaneamente:

  • COBOL;

  • compiladores;

  • Language Environment;

  • CICS;

  • Db2;

  • IMS;

  • VSAM;

  • JCL;

  • SMF;

  • comportamento do processador;

  • arquitetura da aplicação;

  • regras de negócio.

Esses profissionais existem, mas são raros.

O IBM COBOL Elevate tenta reduzir essa distância entre o sintoma observado no ambiente e a ação que deve ser tomada no programa.


Capítulo 4 — Primeiro laboratório: Accelerate

O primeiro pilar recebe o nome de Accelerate.

Sua função começa com uma pergunta essencial:

Quais programas realmente precisam de otimização?

Isso parece simples, mas é uma mudança importante.

Em muitas empresas, modernização ainda é tratada como um projeto de massa:

Selecionar milhares de programas
            ↓
Recompilar tudo
            ↓
Executar testes
            ↓
Encontrar incompatibilidades
            ↓
Corrigir
            ↓
Testar novamente
            ↓
Implantar

Esse modelo pode funcionar, mas custa tempo, dinheiro e capacidade de testes.

O Accelerate propõe uma abordagem mais seletiva.

A IBM afirma que a solução realiza uma análise antecipada de performance para identificar os programas COBOL que necessitam de otimização. Depois de uma configuração inicial descrita como simples e realizada uma vez, o produto auxilia no processo de otimização. O anúncio também declara que aplicações identificadas podem ser otimizadas sem alteração do código-fonte, sem recompilação e sem extensas atividades manuais de análise de performance. (IBM)

Essa é provavelmente a afirmação mais provocativa de todo o anúncio.

Como otimizar sem modificar o fonte?

Aqui precisamos separar cuidadosamente fato confirmado de interpretação técnica.

O anúncio confirma o objetivo de otimizar determinados módulos sem modificar o fonte e sem exigir recompilação convencional. Porém, o material público inicial não descreve em detalhes toda a implementação interna utilizada para produzir essa otimização.

Portanto, não devemos inventar que o produto “reescreve o load module”, “aplica patches binários” ou “usa otimização JIT” sem documentação técnica que confirme esses mecanismos.

O que podemos afirmar é:

  • ele analisa previamente o ambiente;

  • identifica candidatos que oferecem potencial de ganho;

  • permite otimizações sem mudanças no fonte;

  • pretende reduzir a necessidade de análise manual extensa;

  • procura diminuir o esforço de testes antes da implantação.

No laboratório do CSI, isso equivale a melhorar a investigação sem obrigar alguém a reconstruir todo o edifício onde o crime ocorreu.

Por que o teste pode ser menor?

Porque existe uma diferença importante entre:

ALTERAR A REGRA DE NEGÓCIO

e:

OTIMIZAR A EXECUÇÃO DA MESMA REGRA

Quando o código-fonte é alterado, a organização precisa provar que:

  • nenhuma condição mudou;

  • nenhum cálculo foi afetado;

  • nenhum campo foi deslocado;

  • nenhum fluxo alternativo deixou de funcionar;

  • nenhum comportamento CICS, Db2 ou IMS foi modificado.

Quando a otimização preserva a lógica e não exige alteração do fonte, a estratégia de validação pode ser mais focada.

Isso não significa “não testar”.

Em sistemas críticos, qualquer mudança deve ser validada.

Significa que o escopo do teste pode potencialmente ser reduzido porque o objetivo não é alterar o comportamento funcional da aplicação.

Exemplo

Considere os seguintes programas:

PGM001 — executado 3 vezes por mês
PGM002 — executado 90 milhões de vezes por dia
PGM003 — consome 0,01 segundo
PGM004 — utiliza 17% da CPU total do batch noturno
PGM005 — será desativado em dois meses

Sem análise, uma empresa poderia tratar todos da mesma forma.

Com uma abordagem orientada por evidências, a prioridade provavelmente seria:

1. PGM004
2. PGM002
3. Investigar os demais somente se necessário

O grande ganho do Elevate pode não estar apenas em “acelerar programas”.

Pode estar em impedir que a equipe desperdice seis meses otimizando programas irrelevantes.


Capítulo 5 — Segundo laboratório: Upgrade

O segundo pilar chama-se Upgrade e trata de um dos projetos mais temidos do mundo COBOL:

atualizar o compilador.

Quem está começando pode imaginar que isso significa apenas trocar o comando de compilação.

Não é tão simples.

Um programa pode conter:

  • sintaxe antiga;

  • opções de compilação herdadas;

  • comportamentos dependentes de versões anteriores;

  • estruturas de dados mal definidas;

  • redefinições perigosas;

  • dependências com copybooks;

  • chamadas estáticas ou dinâmicas;

  • interfaces CICS;

  • SQL embutido;

  • acessos IMS;

  • bibliotecas específicas;

  • programas chamados por dezenas de outros módulos.

Por isso, atualizar um compilador não é apenas um problema tecnológico.

É também um problema de inventário.

A pergunta que ninguém deseja ouvir

— Quantos programas ainda foram compilados com versões antigas?

Em muitos ambientes, a resposta é:

— Estamos levantando.

Depois de três meses:

— Ainda estamos levantando.

Depois de seis meses:

— Encontramos outra biblioteca.

O Upgrade do COBOL Elevate foi projetado para ajudar a acelerar a adoção de níveis suportados do Enterprise COBOL. Para isso, a IBM apresenta recursos de inventário automatizado, avaliações de prontidão, remediação assistida por IA, fluxos guiados, análise de dependências, identificação de requisitos e previsão do risco do projeto. (IBM)

Isso transforma o upgrade em algo mais próximo de uma investigação estruturada.

Passo a passo conceitual

Passo 1 — Inventariar

Descobrir:

Quais programas existem?
Onde estão?
Qual compilador foi utilizado?
Quais bibliotecas participam do processo?
Quais programas chamam outros programas?

Passo 2 — Mapear dependências

Um programa raramente vive sozinho.

PGM-A
  ├── COPY CLIENTE
  ├── COPY CONTA
  ├── CALL PGM-B
  ├── EXEC SQL
  └── EXEC CICS LINK PGM-C

Modificar o PGM-A pode afetar mais do que o PGM-A.

Passo 3 — Avaliar prontidão

O sistema precisa identificar:

  • incompatibilidades;

  • padrões problemáticos;

  • opções obsoletas;

  • riscos de migração;

  • necessidades de correção.

Passo 4 — Priorizar

Os programas podem ser classificados, conceitualmente, como:

Baixo risco
Médio risco
Alto risco
Necessita investigação

Passo 5 — Remediar

A assistência de IA pode ajudar a explicar problemas e orientar correções.

Aqui existe uma diferença enorme entre:

ERRO NA LINHA 1784

e:

A construção utilizada depende de um comportamento legado.
Considere a seguinte alteração e execute estes testes.

Passo 6 — Executar ondas de migração

Em vez de uma migração caótica de 40 mil programas:

Onda 1 — baixo risco
Onda 2 — médio risco
Onda 3 — aplicações críticas
Onda 4 — casos especiais

Esse planejamento reduz o efeito “Big Bang”, no qual tudo é alterado ao mesmo tempo e ninguém consegue determinar qual mudança causou o incidente.


Capítulo 6 — Terceiro laboratório: Performance Insights

O terceiro pilar é o Performance Insights.

Talvez seja a parte mais fácil de explicar para um programador iniciante e uma das mais interessantes para um profissional experiente.

Tradicionalmente, performance no mainframe é observada por meio de dados como:

  • tempo de CPU;

  • tempo decorrido;

  • EXCP;

  • utilização de serviço;

  • contadores CICS;

  • métricas Db2;

  • estatísticas IMS;

  • informações SMF;

  • relatórios RMF;

  • medições por job, transação ou address space.

Essas informações são valiosas.

Porém, existe um problema.

Elas podem dizer:

O PROGRAMA X CONSOME MUITA CPU

mas não necessariamente:

A REGIÃO ENTRE AS LINHAS 1840 E 1880
É A PRINCIPAL RESPONSÁVEL

O Performance Insights procura conectar análise estática, análise dinâmica e dados reais de execução ao código-fonte COBOL. Com isso, a solução pretende identificar e priorizar problemas potenciais de performance, oferecendo recomendações acionáveis diretamente associadas ao fonte. (IBM)

Análise estática

É a investigação do código sem depender apenas de uma execução específica.

Ela pode observar padrões como:

  • estruturas de repetição;

  • chamadas;

  • pesquisas;

  • conversões;

  • movimentações;

  • uso de tabelas;

  • caminhos lógicos;

  • construções que merecem revisão.

Exemplo:

PERFORM 1000-PROCESSAR
   VARYING WS-INDICE FROM 1 BY 1
   UNTIL WS-INDICE > 5000000

A estrutura não é automaticamente um erro.

Mas merece atenção porque qualquer operação dentro dela pode ser repetida cinco milhões de vezes.

Análise dinâmica

É a observação da aplicação durante uma execução real ou representativa.

Ela responde:

  • quantas vezes o trecho executou;

  • quanto recurso foi consumido;

  • quais caminhos foram mais utilizados;

  • quais rotinas quase nunca foram chamadas;

  • onde o tempo ficou concentrado.

A união das duas

A análise estática diz:

“Este trecho tem potencial para ser caro.”

A dinâmica responde:

“Ele foi executado 80 milhões de vezes e representa parte relevante do consumo.”

Juntas, elas formam uma evidência muito mais forte.

No CSI, uma impressão digital isolada pode não resolver o caso.

Uma impressão digital, uma gravação, o horário e o DNA formam um conjunto muito mais convincente.


Capítulo 7 — Exemplo investigativo

Considere um programa de cálculo de tarifas:

       PERFORM VARYING WS-I FROM 1 BY 1
          UNTIL WS-I > WS-QTD-LANCAMENTOS

          MOVE SPACES TO WS-DESCRICAO

          PERFORM 3000-LOCALIZAR-TARIFA

          IF WS-TARIFA-ENCONTRADA
             COMPUTE WS-VALOR-TOTAL =
                     WS-VALOR-TOTAL + WS-TARIFA
          END-IF

       END-PERFORM.

O programa funciona.

Mas a análise revela:

Quantidade de iterações: 60.000.000
Chamadas à rotina de localização: 60.000.000
Percentual de CPU concentrado na rotina: 42%

A investigação do fonte mostra que a tabela de tarifas está ordenada, mas o programa realiza uma busca sequencial.

Um desenvolvedor poderia estudar a possibilidade de substituir uma lógica equivalente a busca linear por uma estratégia de busca binária, quando tecnicamente válida.

Por exemplo, em COBOL, uma tabela adequadamente declarada e ordenada pode permitir o uso de SEARCH ALL.

Mas aqui surge uma regra de ouro:

Nunca troque SEARCH por SEARCH ALL apenas porque alguém disse que é mais rápido.

Para utilizar SEARCH ALL, é necessário garantir, entre outros pontos:

  • tabela ordenada conforme a chave;

  • declaração compatível;

  • condição de busca adequada;

  • manutenção correta da ordenação;

  • testes que confirmem o comportamento.

Performance não é adivinhação.

É ciência baseada em medição.

O Elevate pretende ajudar justamente a mostrar onde uma mudança pode produzir impacto real, evitando a otimização baseada em superstição.


Capítulo 8 — A inteligência artificial entra na sala

A expressão “AI-assisted” aparece no anúncio, especialmente na área de remediação do upgrade.

Isso não deve ser interpretado como:

A IA substituirá todos os programadores COBOL.

O cenário é mais interessante.

A IA pode atuar como um assistente técnico capaz de:

  • interpretar resultados;

  • resumir dependências;

  • explicar incompatibilidades;

  • sugerir remediações;

  • orientar fluxos de atualização;

  • ajudar profissionais menos experientes;

  • reduzir o tempo gasto em levantamentos manuais.

Imagine o programador iniciante encontrando uma construção problemática.

Sem assistência, ele vê:

MIGRATION ISSUE 0C27

Com assistência contextual, ele poderia receber algo semelhante a:

O programa utiliza uma construção cujo comportamento
deve ser revisado na atualização do compilador.

Arquivos relacionados:
COPY-A
COPY-B

Programas dependentes:
PGM102
PGM238

Risco estimado:
Médio

Ação recomendada:
Revisar a definição do campo e executar os testes X, Y e Z.

A inteligência artificial não elimina a necessidade de julgamento humano.

Ela reduz o tempo necessário para chegar às perguntas corretas.

Grissom jamais condenaria um suspeito apenas porque um algoritmo o indicou.

Ele usaria a indicação para procurar evidências.

O mesmo vale para modernização COBOL.


Capítulo 9 — A ligação com o IBM z17

O anúncio do COBOL Elevate foi publicado no mesmo contexto da expansão da família IBM z17, incluindo configurações single frame e rack mount. A IBM posiciona o z17 como uma plataforma para aplicações críticas e relaciona o Elevate ao objetivo de extrair mais valor das aplicações COBOL existentes. A disponibilidade do COBOL Elevate foi anunciada para 18 de setembro de 2026. (IBM Newsroom)

Por que essa ligação importa?

Porque hardware e compilador evoluem juntos.

Um módulo compilado há muitos anos pode não aproveitar da melhor forma:

  • instruções mais recentes;

  • melhorias de geração de código;

  • avanços da arquitetura;

  • otimizações presentes em compiladores modernos;

  • capacidades da nova geração do IBM Z.

Isso não significa que um programa antigo deixe de funcionar.

A retrocompatibilidade é uma das forças históricas do mainframe.

Significa que:

funcionar não é necessariamente o mesmo que aproveitar todo o potencial disponível.

É como colocar um excelente piloto em um veículo moderno, mas obrigá-lo a dirigir utilizando um manual escrito para um modelo de trinta anos atrás.

O veículo anda.

Porém, vários recursos permanecem inutilizados.


Capítulo 10 — Para que o produto serve?

O IBM COBOL Elevate pode ajudar organizações que enfrentam problemas como:

1. Inventário desconhecido

A empresa não sabe exatamente quais programas existem, como se relacionam ou quais versões de compilador foram utilizadas.

2. Upgrade adiado

O projeto de atualização é constantemente postergado por medo do risco, falta de profissionais ou ausência de estimativas confiáveis.

3. CPU crescente

Os volumes aumentam, o consumo cresce e ninguém consegue relacionar facilmente a métrica operacional ao trecho de código responsável.

4. Equipe reduzida

Poucos profissionais conhecem profundamente todo o ambiente.

5. Otimização sem prioridade

Existem milhares de programas, mas não há critérios para decidir quais merecem atenção.

6. Modernização genérica

A empresa fala em modernização, mas não possui uma sequência prática de ações.

O Elevate procura oferecer uma rota mais objetiva:

Descobrir
   ↓
Medir
   ↓
Classificar
   ↓
Priorizar
   ↓
Otimizar
   ↓
Atualizar
   ↓
Validar
   ↓
Acompanhar

Capítulo 11 — O que ele não é

Também precisamos eliminar alguns suspeitos inocentes.

Não é um substituto automático do COBOL

O objetivo não é apagar o COBOL e converter tudo para outra linguagem.

Não é simplesmente um compilador novo

O Enterprise COBOL continua sendo o compilador. O Elevate trabalha em torno do processo de análise, otimização, priorização e upgrade.

Não é uma autorização para deixar de testar

Reduzir esforço de teste não significa eliminar testes.

Não é uma bola de cristal

Uma recomendação precisa ser analisada dentro do contexto da aplicação.

Não elimina especialistas

Ele pode reduzir dependências excessivas e tornar conhecimento mais acessível, mas arquitetos, desenvolvedores, engenheiros de performance, equipes de testes e especialistas de negócio continuam essenciais.

Não corrige regras de negócio erradas apenas acelerando o código

Um programa que calcula algo incorretamente continuará errado, talvez apenas mais rápido.

Essa é uma curiosidade importante:

Otimizar um erro pode transformar um erro lento em um erro de alta velocidade.


Capítulo 12 — Como um programador COBOL iniciante deve estudar o Elevate

Mesmo antes de utilizar o produto, o iniciante pode preparar a base técnica.

Passo 1 — Aprenda o ciclo de compilação

Entenda:

Fonte COBOL
   ↓
Pré-compilação, quando aplicável
   ↓
Compilação
   ↓
Objeto
   ↓
Binder
   ↓
Load module ou program object
   ↓
Execução

Sem compreender essa sequência, será difícil perceber o significado de otimizar, recompilar ou atualizar compiladores.

Passo 2 — Estude opções de compilação

Conheça conceitos como:

  • OPTIMIZE;

  • ARCH;

  • TUNE;

  • informações de debug;

  • listings;

  • mapas;

  • opções relacionadas ao comportamento do compilador.

Não é necessário decorar tudo.

O importante é perceber que dois programas com o mesmo fonte podem gerar objetos diferentes dependendo da versão e das opções utilizadas.

Passo 3 — Aprenda o básico de performance

Diferencie:

  • CPU time;

  • elapsed time;

  • espera por I/O;

  • contenção;

  • consumo de Db2;

  • tempo de serviço;

  • volume processado;

  • frequência de execução.

Um programa pode demorar muito sem consumir muita CPU, por exemplo, quando espera I/O ou algum recurso.

Passo 4 — Estude estruturas COBOL críticas

Observe:

  • loops;

  • tabelas;

  • chamadas;

  • buscas;

  • conversões;

  • campos mal definidos;

  • uso de funções;

  • movimentações repetitivas;

  • acessos a arquivos e bancos.

Passo 5 — Aprenda a medir antes de alterar

Nunca otimize apenas porque um trecho “parece feio”.

Código feio pode executar uma vez por semana.

Código elegante pode executar 500 milhões de vezes por dia.

Passo 6 — Entenda o negócio

Uma rotina pode parecer redundante, mas existir por exigência regulatória, contábil ou histórica.

Antes de removê-la, investigue.

No mainframe, muitos comentários ausentes estão escondidos na memória dos antigos membros da equipe.


Capítulo 13 — Um roteiro corporativo de adoção

Uma organização interessada no COBOL Elevate poderia estruturar uma iniciativa conceitual em fases.

Fase 1 — Definir o caso

Escolher uma aplicação com:

  • consumo relevante;

  • valor de negócio;

  • dados confiáveis;

  • equipe disponível;

  • volume representativo.

Fase 2 — Criar a linha de base

Registrar:

CPU atual
Elapsed atual
Volume processado
Versão dos módulos
Compiladores
Opções
Incidentes
Janela batch
SLA

Sem linha de base, qualquer alegação de melhoria vira opinião.

Fase 3 — Inventariar

Mapear programas, copybooks, bibliotecas e dependências.

Fase 4 — Analisar candidatos

Separar os módulos realmente relevantes.

Fase 5 — Avaliar recomendações

Reunir:

  • desenvolvimento;

  • performance;

  • produção;

  • testes;

  • negócio.

Fase 6 — Criar piloto

Começar com um conjunto controlado.

Fase 7 — Testar

Executar:

  • comparação funcional;

  • regressão;

  • análise de resultados;

  • performance;

  • recuperação;

  • rollback.

Fase 8 — Comparar

Exemplo:

ANTES
CPU: 100 unidades
Elapsed: 45 minutos

DEPOIS
CPU: 78 unidades
Elapsed: 37 minutos

Mas também verificar:

Resultados de negócio idênticos?
Registros processados idênticos?
Abends?
Diferenças?
Comportamento em pico?

Fase 9 — Expandir

Somente depois das evidências, ampliar para outras aplicações.


Capítulo 14 — Curiosidades recolhidas no laboratório

Curiosidade 1 — O nome “Elevate”

A escolha sugere elevar aplicações existentes, não descartá-las.

Não é “COBOL Replace”.

Não é “COBOL Escape”.

É “COBOL Elevate”.

O patrimônio permanece, mas deve ser levado a outro nível de eficiência e manutenção.

Curiosidade 2 — O release começa em 1.1

O produto foi anunciado publicamente como IBM COBOL Elevate for z/OS 1.1. A numeração pode refletir a estratégia de empacotamento e evolução do produto, mas não devemos inventar a existência de uma versão comercial 1.0 sem documentação específica.

Curiosidade 3 — O fonte não é a única evidência

Um programa COBOL possui várias camadas relevantes:

Fonte
Copybooks
Opções do compilador
Objeto
Program object
Runtime
Dados
Volume
Ambiente
Hardware

Analisar apenas o fonte é como analisar apenas a fotografia da cena sem examinar impressões digitais, horários e depoimentos.

Curiosidade 4 — O programa mais longo pode não ser o mais caro

Um programa de 20 mil linhas executado uma vez pode consumir menos que uma rotina de 30 linhas chamada 200 milhões de vezes.

Curiosidade 5 — A otimização pode adiar expansão de capacidade

Quando aplicações utilizam menos CPU ou terminam mais cedo, a empresa pode obter maior valor do hardware existente, liberar janela batch e acomodar crescimento.

Isso não significa que qualquer otimização automaticamente reduzirá custos, pois contratos, métricas e modelos de cobrança variam. Mas eficiência técnica aumenta as opções disponíveis para planejamento de capacidade.


Capítulo 15 — Easter eggs para veteranos

Easter egg 1 — O cadáver que se levantou

O COBOL já foi declarado morto tantas vezes que deveria possuir mais certidões de óbito que programas em uma load library.

Agora, em vez de organizar seu funeral, a IBM apresenta uma solução para fazê-lo executar melhor no z17.

Easter egg 2 — “Follow the evidence”

No CSI, Grissom dizia que as evidências contam a história.

Na performance, o equivalente é:

Follow the measurements.

Não siga a opinião.

Não siga a estética do código.

Não siga o módulo que alguém “acha” problemático.

Siga CPU, frequência, volume, tempo e impacto.

Easter egg 3 — O copybook desaparecido

Todo grande projeto de inventário encontra algum programa cuja compilação depende de um copybook guardado em uma biblioteca que ninguém conhecia.

Em Las Vegas, isso seria chamado de evidência escondida.

No mainframe, chama-se terça-feira.

Easter egg 4 — O load module sem fonte

Existe sempre aquele módulo antigo que funciona há vinte anos, mas cujo fonte correto ninguém consegue localizar.

Ele continua em produção como um suspeito sem documentos, vivendo sob identidade falsa.

Easter egg 5 — A linha inocente

Um simples:

MOVE ZERO TO WS-CONTADOR

parece inofensivo.

E geralmente é.

Mas qualquer operação multiplicada por centenas de milhões merece ser analisada no contexto correto.


Capítulo 16 — A pergunta provocativa

Durante décadas, a modernização foi vendida como uma escolha binária:

OU REESCREVEMOS TUDO
OU CONTINUAMOS PARADOS NO PASSADO

O COBOL Elevate confronta essa ideia.

Ele sugere uma terceira rota:

PRESERVAR A LÓGICA
COMPREENDER O AMBIENTE
ATUALIZAR O COMPILADOR
OTIMIZAR O QUE IMPORTA
MELHORAR CONTINUAMENTE

Isso é menos cinematográfico que uma reescrita completa.

Não produz um slide dizendo “100% transformação”.

Mas pode ser muito mais responsável.

Reescrever milhões de linhas de código não remove automaticamente a complexidade do negócio. Às vezes, apenas transporta os mesmos problemas para uma nova linguagem, adicionando novos defeitos durante o percurso.

A lógica acumulada durante décadas representa conhecimento institucional.

A modernização inteligente não começa perguntando:

“Como nos livramos do COBOL?”

Ela começa perguntando:

“O que este sistema faz, por que é importante, onde está o risco e como podemos melhorá-lo com evidências?”


Capítulo 17 — O impacto para a carreira COBOL

Para o programador iniciante, o anúncio traz uma notícia excelente.

O futuro profissional não será apenas escrever:

IF SALDO > ZERO
   PERFORM PAGAMENTO
END-IF

O novo profissional COBOL precisará compreender:

  • performance;

  • compilação;

  • dependências;

  • observabilidade;

  • análise estática;

  • análise dinâmica;

  • IA assistiva;

  • DevOps;

  • modernização;

  • arquitetura IBM Z;

  • qualidade de software.

O programador deixa de ser apenas o autor do fonte.

Torna-se investigador do comportamento da aplicação.

Essa mudança amplia a carreira.

Um desenvolvedor pode evoluir para:

  • especialista em modernização COBOL;

  • engenheiro de performance;

  • arquiteto de aplicações IBM Z;

  • especialista em upgrade de compiladores;

  • engenheiro DevOps para mainframe;

  • líder de qualidade;

  • analista de dependências;

  • consultor de otimização.

O COBOL Elevate não reduz a importância do conhecimento COBOL.

Ele torna esse conhecimento parte de uma disciplina mais ampla.


Veredito final do laboratório

O IBM COBOL Elevate for z/OS 1.1, anunciado em 7 de julho de 2026 e com disponibilidade geral planejada para 18 de setembro de 2026, representa uma tentativa ambiciosa da IBM de reunir otimização, modernização, atualização de compiladores, inteligência artificial e análise de performance em uma solução integrada. (IBM)

Seus três pilares formam uma sequência lógica:

ACCELERATE
Identificar e otimizar módulos relevantes.

UPGRADE
Inventariar, avaliar e acelerar a atualização do compilador.

PERFORMANCE INSIGHTS
Ligar evidências de execução ao código-fonte.

O maior mérito da proposta não é prometer uma substituição mágica do legado.

É reconhecer que o ambiente COBOL precisa ser investigado antes de ser transformado.

Em vez de tratar todos os programas como culpados, a solução procura:

  • localizar os verdadeiros consumidores;

  • medir o impacto;

  • identificar dependências;

  • avaliar riscos;

  • orientar correções;

  • concentrar o esforço onde existe retorno.

No final daquela madrugada em Las Vegas, o jovem programador olhou novamente para o alerta de CPU.

— Então não devemos recompilar tudo?

Grissom desligou a lanterna, colocou o relatório sobre a mesa e respondeu:

— Não até sabermos quais módulos estavam presentes, quantas vezes foram executados e o que fizeram com cada ciclo de processador.

Na tela do terminal, milhares de programas continuavam trabalhando.

Alguns estavam perfeitamente inocentes.

Outros escondiam comportamentos caros havia décadas.

E pela primeira vez, havia um novo investigador entrando no laboratório.

Seu nome era:

IBM COBOL ELEVATE FOR z/OS
RELEASE 1.1

Porque no mainframe, como no CSI, o código pode permanecer em silêncio.

Mas a CPU sempre deixa vestígios.

 Maiores informações

https://www.ibm.com/new/announcements/introducing-ibm-cobol-elevate-for-z-os

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