☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta IBM Champion. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta IBM Champion. Mostrar todas as mensagens

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

terça-feira, 23 de junho de 2026

A Saga de Vagner Bellacosa no Reino dos Mainframes

 



☕💥 A Saga de Vagner Bellacosa no Reino dos Mainframes

Ou como um jovem padawan descobriu que COBOL dá mais XP que matar dragões

Bellacosa Mainframe e historias de velhos cpds em mainframe


Salve jovem padawan.

Pegue um café.

Se for diabético, pegue sem açúcar.

Se estiver em produção, pegue dois.

Hoje vou contar uma história.

Não a história de um herói tradicional.

Nada de capa.

Nada de espada mágica.

Nada de armadura lendária.

Nosso protagonista usa crachá corporativo, camisa social amassada, óculos cansados, carrega uma mochila cheia de apostilas IBM dos anos 90 e combate criaturas muito mais perigosas que dragões.

Ele atende pelo nome de Vagner Bellacosa.


O chamado da aventura

Toda jornada começa de maneira inocente.

Alguns encontram um anel.

Outros encontram uma espada cravada numa pedra.

Bellacosa encontrou...

Um terminal 3270.

Tela preta.

Letras verdes.

Cursor piscando.

Silêncio.

Nenhum botão.

Nenhum mouse.

Nenhum TikTok.

Nenhum React.

Nenhum Kubernetes.

Apenas um campo escrito:

LOGON ===>

Naquele instante existiam apenas duas possibilidades.

Primeira:

Desligar o computador e cursar gastronomia.

Segunda:

Digitar o usuário.

Ele digitou.

E nunca mais foi o mesmo.


O primeiro ABEND

Todo herói precisa sofrer.

Luke perdeu a mão.

Frodo quase perdeu a alma.

Bellacosa ganhou seu primeiro:

S0C7.

E descobriu algo curioso.

No Mainframe ninguém fala:

"Tem bug."

Todos falam:

— Deu ABEND.

ABEND parece nome de chefe final.

Você passa oito horas procurando.

Consulta dump.

Abre SYSOUT.

Lê JESMSGLG.

Olha o compile listing.

Chama o colega.

Chama outro colega.

Chama o especialista.

Chama um padre.

E no final descobre:

O campo numérico tinha espaço em branco.

Aí você aprende humildade.


Banco Real, a Terra Média dos Dinossauros Digitais

Existiu uma época gloriosa.

A época em que o Banco Real possuía milhares de programas.

Centenas de analistas.

Adabas.

Natural.

PLI.

JCL.

Control-M.

CICS.

VSAM.

RACF.

E um exército de desenvolvedores sobrevivendo a janelas batch.

Era uma civilização inteira.

Uma espécie de Atlântida tecnológica.

Enquanto a internet ainda fazia:

Piiiiiiiiiiiii....

Krrrttttt...

Biiiiiippp...

O Mainframe já processava milhões de registros.

Sem Kubernetes.

Sem Docker.

Sem palestra motivacional.

Sem coach dizendo:

"Escalone sua vida."

O Mainframe apenas respondia:

— JOB EXECUTADO RC=0000

E seguia trabalhando.


O homem que conversava com os programas Natural

Chegou então o Bug do Milênio.

O apocalipse anunciado.

Consultorias ficaram ricas.

Executivos ficaram nervosos.

Gerentes envelheceram.

Bellacosa teve uma ideia.

Criar um extrator.

Mas não qualquer extrator.

Um monstro.

Um PLI autorecursivo.

Um pequeno T-800 em formato de JCL.

Ele lia.

Interpretava.

Gerava JCL.

Enfileirava jobs.

Chamava a si próprio.

Criava novos filhos.

Extraía fontes.

Analisava objetos.

Preenchia bibliotecas.

E continuava trabalhando.

Sozinho.

Por 48 horas.

Consumindo CPU.

Consumindo spool.

Consumindo a sanidade do operador.

Quando terminou...

Meio milhão de objetos haviam sido catalogados.

Hoje chamaríamos isso de:

Pipeline de DevOps.

Na época chamava-se:

"Coisa do Bellacosa."


O Grande Inquisidor da DAI

Mas nenhum guerreiro evolui sem enfrentar a polícia secreta.

DAI.

Três letras capazes de congelar a alma.

Ser chamado pela DAI era equivalente a ouvir:

"Precisamos conversar."

Você imediatamente pensava:

Meu RACF vazou?

Compilei em produção?

Rodei a Loteca?

Usei a transação proibida?

Não.

Queriam apenas um relatório.

Um relatório pequeno.

Só precisava analisar milhares de logs.

Consultar usuários.

Cruzar tabelas.

Gerar dezenas de milhares de páginas.

Em 72 horas.

Sem errar.

Sem testar direito.

Sem segunda chance.

Bellacosa codificou.

Revisou.

Debugou com caneta.

Rezou.

Entregou.

Funcionou.

E descobriu uma lição importante.

Programador Mainframe não envelhece.

Ele acumula PTSD de produção.


O evangelista improvável

Décadas se passaram.

Muitos colegas migraram.

Viraram arquitetos.

Gerentes.

Executivos.

Consultores.

Alguns abriram startups.

Outros abriram adegas.

Bellacosa resolveu algo diferente.

Contar histórias.

Escrever artigos.

Criar newsletters.

Ensinar COBOL.

Explicar CICS.

Falar sobre VSAM.

Defender o velho gigante preto da IBM.

Transformar dump em entretenimento.

Transformar S0C4 em meme.

Transformar SYSUDUMP em literatura fantástica.

Porque descobriu algo curioso.

O Mainframe nunca foi apenas tecnologia.

Foi amizade.

Foi mentor.

Foi Roseli.

Foi Tokunaga.

Foi auditor assustador.

Foi operador bravo.

Foi colega salvando produção às três da manhã.

Foi café requentado.

Foi pizza fria.

Foi aprender que existem pessoas que realmente se emocionam ao ver um RC=0000.

E tudo bem.

Somos poucos.

Somos estranhos.

Somos os últimos guardiões do EBCDIC.


Epílogo

Hoje existem inteligências artificiais.

Agentes autônomos.

LLMs.

Clouds infinitas.

Quantum Computing.

Promessas de substituir COBOL.

Promessas de desligar Mainframe.

Promessas de reescrever tudo.

Promessas.

Muitas promessas.

Enquanto isso...

Em algum lugar do planeta...

Um CICS iniciado em 1998 continua processando cartões.

Um DB2 continua pagando aposentadorias.

Um VSAM continua guardando informações valiosas.

Um JCL continua rodando.

E um Bellacosa continua tomando café.

Escrevendo artigos.

Chamando leitores de padawans.

Contando histórias.

E lembrando a todos nós que talvez o verdadeiro legado do Mainframe nunca tenha sido o hardware.

Mas as pessoas malucas o suficiente para dedicar a vida inteira a fazê-lo funcionar.

E sinceramente...

Ainda bem que existem esses malucos.

Esse texto ficou bem próximo do tom clássico de "Histórias do Tiozão em Mainframe", misturando autobiografia, nostalgia, cultura pop, autoironia e reverência aos velhos guerreiros do z/OS. (DIO)

quinta-feira, 2 de abril de 2026

☕ O Holocron do Agente IBM Bob Como um Padawan COBOL Pode Aprender com um Companheiro de IA Criado pela IBM

 

Bellacosa Mainframe e o ibm bob

☕ O Holocron do Agente IBM Bob

Como um Padawan COBOL Pode Aprender com um Companheiro de IA Criado pela IBM para Entender, Modernizar e Construir Sistemas Empresariais

"Os antigos Mestres decoravam milhares de comandos. Os novos Mestres ensinam agentes a trabalhar ao seu lado."


Introdução

Durante décadas, um desenvolvedor IBM Z precisava carregar consigo uma espécie de biblioteca mental.

Era necessário conhecer:

  • COBOL

  • JCL

  • DB2

  • VSAM

  • CICS

  • RACF

  • SDSF

  • ISPF

  • MQ

  • Java

  • APIs REST

  • Git

  • Jenkins

  • Ansible

  • OpenShift

Além disso, precisava compreender regras de negócio escritas há quarenta anos por analistas aposentados, interpretar copybooks obscuros e descobrir por tentativa e erro qual programa atualiza determinada tabela.

Em 2025 a IBM decidiu mudar essa história.

Nascia o Project Bob.

Em 2026 ele finalmente se tornou disponível como produto.

O objetivo é bastante ambicioso:

Ter um agente inteligente capaz de acompanhar todo o ciclo de vida do software corporativo.

Não apenas sugerir linhas de código.

Mas pensar junto.

Planejar.

Explicar.

Refatorar.

Gerar testes.

Documentar.

Modernizar aplicações.

Encontrar defeitos.

Auditar segurança.

Criar APIs.

Auxiliar equipes inteiras.

Para um Padawan COBOL, Bob talvez seja a ferramenta mais interessante surgida desde o lançamento do Enterprise COBOL 6.x.


O que é IBM Bob?

IBM Bob é um AI Coding Agent desenvolvido pela IBM.

Diferentemente dos copilotos tradicionais, Bob trabalha como um agente de desenvolvimento.

Ele atua durante praticamente todo SDLC.

SDLC significa:

Software Development Life Cycle.

Bob pode ajudar em:

Planejamento

↓

Análise

↓

Codificação

↓

Testes

↓

Documentação

↓

Segurança

↓

Modernização

↓

Entrega

Em vez de apenas responder perguntas, Bob executa fluxos completos de trabalho.

IBM chama isso de:

Agentic Development

ou

Agentic SDLC


A origem do Projeto

Bob não apareceu do nada.

Ele é resultado da convergência de vários projetos IBM.

Watsonx Code Assistant for Z

Lançado em 2023.

Objetivo:

Auxiliar modernização COBOL.

Funções:

Explicar código

COBOL → Java

Gerar documentação

Analisar aplicações


Code Assistant for RPG

Criado pelo laboratório Rochester.

Focado em IBM i.


Granite

LLM desenvolvido pela IBM.


Anthropic Claude

IBM anunciou parceria para ampliar capacidades de engenharia.


Em outubro de 2025, durante o TechXchange, surgiu oficialmente:

Project Bob

Em março de 2026 surgiu a primeira versão pública.

Versão:

Bob 1.0

Data aproximada de disponibilidade:

24 Março 2026.

Atualmente existe inclusive um pacote denominado:

IBM Bob Premium Package for Z.


Por que o nome Bob?

IBM nunca divulgou oficialmente uma explicação definitiva.

Mas existe uma curiosidade interessante.

Muitos desenvolvedores brincam dizendo:

Bob é o "Bob The Builder" corporativo.

Ele não destrói aplicações.

Ele conserta.

Moderniza.

Documenta.

Amplia.

Protege.

Algo extremamente alinhado ao universo IBM Z.

Em vez de substituir programadores, Bob funciona como um companheiro.


O que Bob consegue fazer?

1 — Explicar COBOL

Prompt:

Explique este programa COBOL.

Bob responde:

Regras de negócio

Arquivos usados

Campos

Dependências

Fluxos

Excelente para sistemas bancários.


2 — Criar documentação

/document

Pode gerar:

Markdown

README

Diagramas

Comentários

Arquitetura


3 — Testes

Exemplo:

/unit-test

Pode produzir:

JUnit

PyTest

Testes Java

Estruturas automatizadas


4 — Revisão de código

Pergunta:

Existem problemas neste programa COBOL?

Bob pode apontar:

PERFORM incorreto

GO TO excessivo

dead code

duplicação

bugs


5 — Segurança

Detecta:

SQL Injection

credenciais

falhas


6 — Modernização

Talvez seja a parte mais interessante.

Bob consegue auxiliar:

COBOL

↓

Serviços COBOL

↓

APIs

↓

Java


Onde usar Bob?

Atualmente Bob trabalha principalmente integrado ao:

Visual Studio Code

CLI

Ambientes SaaS

IBM Cloud

Sistemas:

Windows

Linux

MacOS


Como testar gratuitamente

Passo 1

Criar conta IBM.

Passo 2

Solicitar Trial.

Acesse:

IBM Bob

ou

bob.ibm.com


Passo 3

Instalar VSCode


Passo 4

Instalar extensão

IBM Bob


Passo 5

Login

IBM ID


Passo 6

Abrir projeto

COBOL

Python

Java


Passo 7

Conversar

Exemplo:

Explique este COPYBOOK

Documente este programa

Crie testes

Faça refatoração

Sugira API REST


Primeiro laboratório para um Padawan COBOL

Pegue um programa antigo.

Exemplo:

CALCSAL.cbl

Pergunte:

Explique este programa.

Depois:

Crie documentação Markdown.

Depois:

Gere casos de teste.

Depois:

Sugira melhoria COBOL 6.5.

Depois:

Transforme em serviço REST.

Você verá praticamente um assessment sendo realizado em minutos.


Comandos interessantes

Embora Bob esteja evoluindo, comandos similares aos usados no WCA aparecem frequentemente.

/document

Documentação


/unit-test

Testes


/review

Code review


/explain

Explicação


/refactor

Refatoração


/security

Auditoria


/plan

Planejamento


/generate

Código novo


Exemplo prático

Pergunta:

Tenho um programa COBOL que atualiza saldo de conta.

Bob pode responder:

Programa principal identificado.

Copybooks encontrados.

Tabela DB2 utilizada.

Transação CICS relacionada.

Dependências localizadas.

Sugestão de API:

GET /saldo

POST /debito

POST /credito

Em alguns minutos.

Algo que antigamente levava dias.


Curiosidades

Bob utiliza arquitetura multi-modelo.

Pode combinar:

Granite

Claude

Llama

Mistral

Dependendo da tarefa.


Mais de seis mil desenvolvedores IBM já utilizavam Bob internamente antes do lançamento público.


Bob é considerado sucessor natural do:

Watsonx Code Assistant for Z


Existe forte foco em:

COBOL

PL/I

RPG

Java

JCL

Mainframe


Dicas para começar

Dica 1

Não tente gerar sistemas inteiros.

Comece pequeno.


Dica 2

Use programas COBOL simples.

100 linhas.

200 linhas.


Dica 3

Peça explicações.

Aprenda observando.


Dica 4

Valide tudo.

IA erra.

Sempre.


Dica 5

Construa biblioteca própria.

Prompts úteis:

Explique para um iniciante.

Mostre fluxograma.

Identifique regras.

Crie README.

Faça ZUnit.

Gerar OpenAPI.

Criar testes.

Migrar para COBOL 6.5.


Como aprofundar conhecimentos

Estude:

Enterprise COBOL 6.5

VSCode

Zowe

Git

OpenAPI

REST

JUnit

Ansible

Watsonx

Granite

RAG

MCP Servers

Agentic AI

Leia documentação IBM.

Assista TechXchange.

Teste diariamente.

Uma hora por dia é suficiente.


Considerações Finais

O IBM Bob representa uma mudança semelhante à chegada do ISPF para quem programava apenas com editores lineares.

Ele não substitui experiência.

Não conhece sozinho todas as regras de negócio.

Não entende automaticamente quarenta anos de exceções bancárias.

Mas reduz drasticamente o tempo gasto procurando informações espalhadas em milhares de programas.

Para o Padawan COBOL, Bob pode ser visto como um novo Holocron.

Um Holocron que não apenas guarda conhecimento, mas conversa, explica, ensina, sugere melhorias e ajuda a transformar aplicações legadas em ativos preparados para a próxima década.

E talvez esta seja a maior lição deixada pelo agente da IBM:

O futuro do desenvolvedor Mainframe não será escrever menos COBOL. Será aprender a trabalhar ao lado de agentes capazes de compreender COBOL tão profundamente quanto nós aprendemos a compreendê-lo ao longo dos anos.


quinta-feira, 3 de abril de 2025

Inspetor Clouseau Entra no Dashboard IBM Z — O Caso dos 400 Advocates, dos 100 Mil Membros e do Denominador Desaparecido

 

Bellacosa Mainframe e advocates 

☕ Um Café no Bellacosa Mainframe

Inspetor Clouseau Entra no Dashboard IBM Z — O Caso dos 400 Advocates, dos 100 Mil Membros e do Denominador Desaparecido

Ou: por que 50 mil seguidores não são 50 mil especialistas, por que 400 pessoas também não são “o ecossistema”, e como ensinar mainframe em português pode ser mais importante do que outro foguete no PowerPoint

“Chefe, temos uma grande notícia!”, disse o agente da comunidade, entrando apressado na sala.

O Inspetor Clouseau levantou os olhos da xícara de café, que por algum motivo estava equilibrada sobre um manual de RACF.

“Ah, sim. Encontraram o assassino?”

“Melhor: conseguimos 400 Advocates! E mais de mil atos de advocacy no trimestre!”

Clouseau bateu palmas, tropeçou na cadeira, derrubou a pasta de relatórios, quase prendeu a mão na gaveta e, depois de alguns segundos fingindo que aquilo era parte da investigação, perguntou:

“Magnífico. E quatrocentos… de quantos?”

Silêncio.

Um silêncio de data center às três da manhã depois de alguém dizer: “mas eu só alterei um parâmetro”.

É aí que começa o caso.

Não é um caso sobre pessoas ruins, programas inúteis, Champions sem mérito ou estudantes que não deveriam celebrar certificados. É um caso sobre uma criatura perigosa, muito comum em apresentações corporativas, relatórios de comunidade e dashboards coloridos:

o número absoluto que foi solto na rua sem seu denominador.

Para um programador COBOL iniciante, isso pode parecer conversa de estatístico de gravata borboleta. Mas é assunto de sobrevivência profissional. Afinal, no mainframe nós aprendemos cedo que um número sozinho nunca explica a história.

CPU média de 30% parece ótima. Até você descobrir que, no fechamento, a CPU bate 100%, o batch estoura a janela, o CICS começa a sofrer e alguém pergunta por que o relatório mensal não mencionou o detalhe.

Um job terminou com RC=0. Excelente. Mas processou todos os registros? Atualizou o Db2? Gerou o arquivo de remessa? Ou simplesmente não encontrou nada para fazer e saiu feliz como um gato que derrubou um copo e fingiu que não foi ele?

O número não mente necessariamente. Mas pode estar respondendo a uma pergunta diferente daquela que a apresentação quer que você faça.



1. O primeiro suspeito: “Temos 400 Advocates!”

Vamos começar pela matemática que o Inspetor Clouseau encontrou atrás da cortina.

A IBM divulgou, em seus próprios materiais, que a comunidade IBM Z possui mais de 100 mil membros. Depois, em relatórios de advocacy, celebrou números como 197 participantes no lançamento, mais de 400 Advocates em um trimestre e mais de mil “atos de advocacy”.

Todos esses números podem ser verdadeiros.

Mas a pergunta é: o que eles provam?

Se houver 400 Advocates em uma comunidade declarada de 100 mil pessoas, temos:

400100.000=0,4%\frac{400}{100.000} = 0,4\%

Isso equivale a uma pessoa em cada 250.

Imagine uma cidade com 100 mil habitantes. Quatrocentas pessoas se encontram no auditório de uma escola. Há entusiasmo, palestras, café, networking, gente talentosa e talvez um banner azul muito bonito no fundo.

A reunião é válida? Claro.

Mas se alguém disser que aquela plateia prova que “a cidade inteira está mobilizada”, o Inspetor Clouseau deveria levantar a lupa e perguntar onde estão os outros 99.600 moradores.

No mainframe, seria como dizer que um único LPAR representa toda a empresa. Ele pode ser importante, crítico, cheio de aplicações relevantes e com carga monstruosa. Ainda assim, não é automaticamente o retrato do data center inteiro.

A crítica, portanto, não é: “400 é pouco”.

A crítica correta é:

“400 pode ser um excelente resultado para um programa especializado; não é evidência suficiente, por si só, de engajamento amplo de um ecossistema com mais de 100 mil pessoas.”

Essa diferença parece pequena. Mas muda toda a investigação.



2. O denominador não é inimigo da celebração

Há quem ouça essa discussão e pense: “Então não podemos comemorar nada?”

Podemos e devemos.

Se um programa reuniu 400 pessoas dispostas a ensinar, escrever, falar, testar produtos, mentorar alunos e promover conhecimento técnico, isso merece reconhecimento. Existem comunidades menores que fazem milagres com dez pessoas e uma cafeteira que só funciona quando o ar-condicionado está desligado.

O problema aparece quando a comemoração troca de tamanho no meio da frase.

Veja a diferença:

  • “Temos 400 Advocates ativos em nosso Hub.”

  • “Temos 400 Advocates, portanto o ecossistema IBM Z está fortemente engajado.”

A primeira frase informa um fato.

A segunda exige prova de representatividade.

É como medir a temperatura de uma sala de CPD e concluir que o clima do Brasil inteiro está controlado. Pode estar fresquinho perto do mainframe; do lado de fora, o termômetro pode estar fritando ovo no asfalto.

3. A sala pode encolher — mas o discurso também precisa encolher

Talvez 100 mil seja um denominador amplo demais. Afinal, “comunidade” pode incluir estudantes, pessoas que assistiram a um evento, perfis inativos, curiosos, parceiros, professores, clientes, ex-clientes e pessoas que se cadastraram numa época em que ainda usávamos CD-ROM para instalar software.

Se usarmos um grupo IBM Z mais específico, com aproximadamente 26.900 membros, 197 Advocates representariam perto de 0,73%.

Ainda não chega a 1%.

Se reduzirmos a sala até um Hub especializado de cerca de 1.500 pessoas, então 400 Advocates equivaleriam a quase 27%.

Aí sim temos uma adoção bastante bonita.

Só que há uma regra de ouro que Clouseau escreveria com caneta azul, erraria a grafia de “denominador” e pisaria no próprio casaco:

Você pode usar o denominador pequeno ou a missão enorme. Não pode usar o pequeno para fazer a porcentagem parecer gigante e o enorme para fazer o programa parecer representativo.

Um Hub de fãs e multiplicadores pode ser uma excelente ferramenta de advocacy. Mas não deve ser apresentado, sem ressalvas, como espelho completo de todos os especialistas que mantêm bancos, seguradoras, governos, indústrias, companhias aéreas e varejistas funcionando.

Porque muita gente essencial simplesmente não aparece nesse tipo de fotografia.

4. O especialista invisível também existe

O Champion, o Advocate e o criador de conteúdo geralmente são pessoas visíveis. Falam em eventos, escrevem, produzem vídeos, participam de comunidades, respondem dúvidas e compartilham conhecimento.

Isso é ótimo. É trabalho real. É generosidade profissional.

Mas o ecossistema mainframe também é formado por pessoas que nunca serão vistas em um palco.

Existe a especialista RACF de um banco que não pode falar publicamente sobre o ambiente. Existe o operador que conhece os sintomas de um incidente antes de o dashboard perceber. Existe a pessoa de storage que carrega na cabeça quarenta anos de decisões estranhas, datasets críticos e procedimentos de recovery que ninguém ousa testar numa segunda-feira.

Existe o programador COBOL que não publica artigo, não participa de rede social e talvez nem tenha foto no LinkedIn — mas sabe que alterar uma definição de copybook sem mapear os programas consumidores pode criar um pequeno apocalipse de produção.

Um processo de Champion seleciona muito bem quem demonstra advocacy visível. Não foi feito para ser um censo da força de trabalho técnica.

É como fazer uma seleção de grandes cozinheiros observando quem posta receitas no Instagram. Você encontrará gente excelente. Mas talvez nunca encontre a tia que alimenta 200 pessoas numa festa de família e sabe exatamente quando o feijão vai queimar sem olhar a panela.

A vitrine pode ser bonita. Mas não é o estoque inteiro.

5. “Atos de advocacy”: quando uma unidade mede muitas coisas diferentes

Agora vamos ao segundo suspeito: o contador de “atos”.

Um programa pode registrar como advocacy:

  • criar um perfil;

  • compartilhar uma publicação;

  • divulgar um evento;

  • assistir ou participar de uma sessão;

  • escrever um artigo;

  • publicar vídeo;

  • dar palestra;

  • mentorar alguém;

  • testar beta;

  • participar de conselho técnico;

  • contribuir para open source;

  • produzir material educacional.

Tudo isso pode ter valor. Mas não é a mesma coisa.

Não se mede o mesmo impacto quando alguém:

  1. preenche o perfil;

  2. compartilha o convite para um evento;

  3. escreve um tutorial que ajuda 500 iniciantes a entender JCL;

  4. testa uma função de produto e encontra um problema antes de ele chegar ao cliente;

  5. orienta um aluno que depois consegue seu primeiro emprego na área.

Misturar tudo em um contador único é útil para gamificação. Ajuda a motivar participação, distribuir badges e criar uma sensação de movimento.

Mas não basta para afirmar que a capacidade técnica do ecossistema aumentou.

No jargão Bellacosa, é como somar SUBMIT, RC=0, RC=8, ABEND, RESTART, CANCEL e PURGE em uma métrica chamada “eventos do batch” e depois concluir: “A produção foi muito ativa esta semana.”

Foi ativa? Possivelmente.

Foi saudável? Ninguém sabe.

Foi útil? Depende.

Foi melhor do que a semana anterior? Cadê os dados?

6. Alcance, participação, contribuição e impacto não são sinônimos

Esta é uma das lições mais importantes para qualquer pessoa que trabalha com comunidade, educação ou tecnologia.

CamadaPergunta certa
AlcanceQuantas pessoas tiveram contato com o conteúdo?
ParticipaçãoQuantas voltaram e interagiram?
ContribuiçãoQuantas produziram algo útil para outras pessoas?
AprendizagemQuantas desenvolveram conhecimento verificável?
ResultadoQuantas aplicaram isso no trabalho, carreira ou produto?
ImpactoO que melhorou de forma mensurável no ecossistema?

Uma live com 50 mil visualizações é alcance.

Um grupo com 1.500 membros é comunidade potencial.

400 pessoas registrando atividades é participação.

Um artigo técnico, uma palestra ou uma mentoria podem ser contribuição.

Uma pessoa que conclui uma trilha e entende o assunto demonstra aprendizagem.

Uma pessoa que entra em uma função, ajuda a manter um ambiente, reduz um incidente ou substitui conhecimento que estava indo embora com uma aposentadoria demonstra resultado.

O “skills gap” não é fechado no momento em que alguém ganha um badge. Ele começa a ser fechado quando uma organização ganha capacidade técnica sustentável.

E isso é difícil de medir. Muito mais difícil do que contar visualizações ou pontos.

7. O caso Bellacosa: aqui a fotografia muda

Agora entra uma evidência prática de como advocacy pode ser mais profundo do que uma campanha trimestral.

Um educador técnico que mantém aproximadamente 50 mil seguidores somados em LinkedIn, YouTube, X/Twitter, Instagram, Blogspot, WhatsApp, Telegram e Facebook possui alcance potencial. Isso, sozinho, não significa 50 mil especialistas IBM Z — e seria desonesto dizer que significa.

Mas o alcance não está sozinho.

Há milhares de postagens, dezenas de vídeos, um blog com conteúdo técnico acessível a qualquer hora, histórias de CPD, explicações de COBOL, CICS, Db2, JCL, VSAM, RACF e z/OS, além de uma narrativa que não trata o mainframe como relíquia empoeirada nem como panfleto corporativo.

Há também ensino formal.

Desde 2022, mais de 500 alunos passaram por aulas de pós-graduação e cursos livres no INEFE. Como SME em um programa IBM Brasil, há atuação direta com um público estimado em aproximadamente 100 profissionais e clientes — estimativa honesta, pois o consolidado oficial não foi disponibilizado pela IBM.

Somam-se 60 horas de webaulas ao vivo, 30 horas de conteúdo gravado e materiais de apoio criados para os alunos.

Isso é uma diferença enorme.

Uma postagem pode ser vista e esquecida.

Uma aula ao vivo permite dúvida, contexto, conversa, correção de rota e aquele momento em que alguém finalmente entende por que DISP=(NEW,CATLG,DELETE) não é feitiçaria, mas também não é coisa para copiar sem pensar.

Uma aula gravada é ainda mais interessante: ela transforma horas de professor em capacidade educacional reutilizável.

O professor deixa de ser apenas uma CPU atendendo uma turma em tempo real e passa a criar uma espécie de “batch educacional”: o conteúdo continua processando novos alunos mesmo quando a aula original já acabou.

Clouseau chamaria isso de “automação pedagógica de alto risco”, derrubaria a câmera e depois ficaria satisfeito com a definição.

8. O poder do português: a porta de entrada que muita gente esquece

A maior vantagem desse modelo está na língua portuguesa.

Para quem está começando, mainframe já chega com uma coleção de barreiras:

  • conceitos antigos e profundamente técnicos;

  • documentação extensa;

  • inglês técnico;

  • siglas em toda frase;

  • ferramentas que parecem menos amigáveis que um terminal de aeroporto dos anos 1980;

  • histórias de produção que assustam mais do que animam;

  • a sensação de que tudo é “para gente que já nasceu sabendo”.

Se o aluno precisa primeiro vencer o inglês técnico para depois descobrir o que é um dataset, o funil fica cruel:

ingleˆs teˊcnico→entendimento da documentac¸a˜o→entendimento de mainframe\text{inglês técnico} \rightarrow \text{entendimento da documentação} \rightarrow \text{entendimento de mainframe}

Quando alguém explica em português, com analogias, exemplos, humor e contexto local, o caminho fica mais humano:

entendimento inicial em portugueˆs→confianc¸a→vocabulaˊrio teˊcnico→documentac¸a˜o oficial em ingleˆs→autonomia\text{entendimento inicial em português} \rightarrow \text{confiança} \rightarrow \text{vocabulário técnico} \rightarrow \text{documentação oficial em inglês} \rightarrow \text{autonomia}

A meta não é substituir a documentação IBM. Ela continua fundamental. Mensagens de erro, manuais, Redbooks, documentação de produto, certificações e debates globais continuarão usando muito inglês.

A meta é evitar que o inglês seja uma catraca na entrada.

Uma pessoa pode começar entendendo em português por que um S0C7 acontece, por que um VSAM tem organização própria, por que um RC=8 não é necessariamente fim do mundo e por que RACF não foi colocado ali apenas para irritar desenvolvedores.

Depois, com confiança, ela lê o manual oficial e reconhece os conceitos. A língua deixa de ser muro e vira ferramenta.

9. Como provar impacto sem cair na própria armadilha do denominador

Aqui vem a parte prática.

Se você quer demonstrar impacto em uma candidatura Champion 2027, não precisa alegar que representa todo o mainframe brasileiro. Nem precisa transformar seguidor em aluno, aluno em profissional e profissional em “caso de sucesso” sem evidência.

O caminho mais forte é montar um dossiê honesto, com números em camadas.

Passo 1 — Registre alcance

Anote os números por canal:

  • seguidores;

  • visualizações;

  • alcance mensal;

  • acessos do blog;

  • vídeos publicados;

  • artigos produzidos;

  • crescimento ao longo do ano.

Mas não pare aí. Alcance é a porta, não a casa.

Passo 2 — Registre participação educacional

Aqui entram os dados que já possuem muito peso:

  • mais de 500 alunos no INEFE desde 2022;

  • aproximadamente 100 participantes e clientes no programa IBM Brasil, como estimativa;

  • 60 horas de aulas ao vivo;

  • 30 horas de aulas gravadas;

  • materiais de apoio produzidos;

  • assuntos cobertos;

  • turmas e períodos de atuação.

Isso já permite dizer algo muito mais sólido que “publiquei bastante”.

Passo 3 — Separe conteúdo de transformação

Tente guardar mensagens e evidências, sempre respeitando a privacidade dos alunos, de pessoas que digam coisas como:

  • “Comecei a estudar COBOL depois do seu artigo.”

  • “Entendi JCL depois da sua aula.”

  • “Usei seu material para me preparar para uma entrevista.”

  • “Consegui concluir uma trilha.”

  • “Entrei em estágio, projeto ou função relacionada.”

  • “Passei a entender melhor o ambiente da empresa.”

Não é preciso fabricar grandes histórias heroicas. Cinco depoimentos concretos e autorizados podem valer mais que cem frases genéricas de “conteúdo incrível”.

Passo 4 — Mostre permanência

O conteúdo público, especialmente no blog, possui uma qualidade que a campanha momentânea não tem: ele permanece.

Um artigo sobre Db2 publicado hoje pode ser encontrado por alguém daqui a dois anos. Uma explicação sobre GDG pode salvar uma tarde de estudo. Uma história sobre CPD pode fazer o estudante perceber que mainframe não é uma tecnologia morta, mas uma infraestrutura com memória, responsabilidade e consequências reais.

O seu acervo é patrimônio educacional em construção.

Passo 5 — Conte a história com precisão

Uma apresentação forte para Champion 2026 poderia dizer:

Desde 2022, atuo na formação de profissionais em mainframe e tecnologias IBM, alcançando mais de 500 alunos em programas de pós-graduação e cursos livres no INEFE. Como Subject Matter Expert em iniciativa da IBM Brasil, contribuí com aproximadamente 60 horas de webaulas ao vivo, 30 horas de conteúdo gravado e materiais de apoio para um público estimado em cerca de 100 profissionais e clientes.

Paralelamente, mantenho uma presença educacional independente em português, com aproximadamente 50 mil seguidores somados em múltiplos canais, milhares de publicações e dezenas de vídeos. Meu trabalho reduz a barreira inicial do inglês técnico e torna conceitos de IBM Z, COBOL, z/OS, CICS, Db2, JCL, RACF, VSAM e operação mais acessíveis a estudantes e profissionais brasileiros.

Meu objetivo é criar uma ponte sustentável entre a experiência prática acumulada no mainframe e a próxima geração de profissionais que precisará manter, modernizar e evoluir essas plataformas.

Isso não é fumaça de marketing. É um caso documentável.

10. Easter egg: a pergunta que Clouseau finalmente acertou

No final da investigação, o Inspetor Clouseau encontra uma sala cheia de dashboards, badges e gráficos com setas apontando para cima.

Ele olha para o responsável e pergunta:

“Então vocês têm 1.000 atos de advocacy?”

“Sim, inspetor!”

“E quantas pessoas aprenderam algo que conseguem usar?”

“Bem…”

“E quantas entraram no mercado?”

“Bem…”

“E quantas continuam na área um ano depois?”

Silêncio.

Clouseau sorri, esbarra no cabo do projetor, apaga a apresentação inteira e diz:

“Aha! O criminoso não era o número. Era a conclusão que ele estava tentando esconder.”

É essa a lição.

Advocacy não é quantidade de posts, badges ou palmas. É capacidade de abrir portas, explicar o que parecia impossível, dar contexto, criar confiança e ajudar alguém a avançar.

Quando isso acontece em português, com conteúdo público, ensino estruturado, experiência prática e continuidade, o impacto deixa de caber em um leaderboard.

Ele aparece no aluno que entende.

E, anos depois, talvez apareça no profissional que está diante de uma tela verde às duas da manhã, vê um RC=8, respira fundo e pensa:

“Calma. Eu sei por onde começar.”

Nesse momento, sem foguete, sem confete e sem precisar de outra medalha digital, o ecossistema ficou um pouco mais forte.




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...