☕ 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

sexta-feira, 31 de julho de 2026

👋 Boas-vindas ao IBM Bob Bootcamp

 

Bellacosa Mainframe apresenta o bootcamp DIO da IBM e seu agente BOB

👋 Boas-vindas ao IBM Bob Bootcamp

IA de Nível Empresarial para Desenvolvedores e Tech Leaders

Olá, pessoal!

Meu nome é Vagner Bellacosa, sou Analista de Sistemas IBM Mainframe, IBM Champion e, acima de tudo, um apaixonado por tecnologia, compartilhamento de conhecimento e aquele tradicional café que acompanha toda boa sessão de aprendizado.

É um enorme prazer fazer parte desta turma do IBM Bob Bootcamp.

Vivemos um momento raro na história da computação. Durante décadas ouvimos que a Inteligência Artificial era "o futuro". Pois bem... o futuro resolveu aparecer mais cedo do que imaginávamos, bater na porta e perguntar:

"Posso ajudar no seu código?"

A resposta, obviamente, foi:

"Pode... mas primeiro passa pelo Code Review!" 😄



Afinal... o que estamos fazendo aqui?

Estamos reunidos porque entendemos que IA não é moda.

É ferramenta.

É produtividade.

É aceleração.

É uma nova forma de pensar soluções.

Se você desenvolve software, administra ambientes, lidera equipes ou trabalha com arquitetura, provavelmente percebeu que a pergunta deixou de ser:

"Vou usar IA?"

e passou a ser

"Como posso utilizá-la melhor que os outros?"


Um recado para quem vem do Mainframe

Eu sou suspeito para falar...

Venho do universo IBM Z, COBOL, CICS, Db2 e z/OS.

Aquele ambiente que muitos juram que é "velho"...

...até descobrirem que movimenta boa parte do dinheiro do planeta.

Então, quando alguém pergunta:

"Mainframe combina com Inteligência Artificial?"

Minha resposta é sempre:

Combina tanto quanto café combina com madrugada de implantação.

Ou seja...

É praticamente obrigatório. ☕😂

Hoje a IA conversa com APIs REST, z/OS Connect, Watsonx, OpenShift, GitHub Copilot, Assistentes Inteligentes e, cada vez mais, com aplicações corporativas que executam justamente em IBM Z.


Minha expectativa

Espero aprender muito com todos vocês.

Cada participante chega com experiências diferentes.

Uns dominam Cloud.

Outros conhecem Kubernetes.

Alguns vivem em Java, Python ou JavaScript.

Outros, como eu, passaram anos escrevendo COBOL e fazendo milhões de transações passarem silenciosamente por um Data Center.

No fim das contas...

Todos estamos aprendendo a conversar com uma nova ferramenta.

E isso é fantástico.


Minha filosofia

Sempre gostei de uma frase simples:

Quem compartilha conhecimento nunca perde espaço; cria novos lugares para todos crescerem.

Então contem comigo durante o Bootcamp.

Se eu puder ajudar em alguma dúvida, trocar experiências ou simplesmente conversar sobre tecnologia, será um prazer.



Um pequeno aviso (com humor Bellacosa)

Caso durante o Bootcamp você apresente algum dos sintomas abaixo...

  • conversar com IA como se fosse um colega de equipe;

  • pedir para o Copilot escrever aquele método "rapidinho";

  • descobrir que um prompt bem escrito vale mais que cinquenta pesquisas;

  • começar a enxergar automação em absolutamente tudo;

...não se preocupe.

É perfeitamente normal.

Os efeitos costumam ser irreversíveis. 😄



https://web.dio.me/track/ibm-bob-ia-nivel-empresarial-para-desenvolvedores?

Boa sorte a todos!

Que este Bootcamp seja uma excelente oportunidade para aprender, compartilhar experiências, fazer novas amizades e descobrir como utilizar a Inteligência Artificial de forma prática e responsável.

Como diria o Bellacosa Mainframe:

"Prepare o café, abra a mente e mantenha o Git atualizado. Porque a IA pode até sugerir o código... mas a responsabilidade pelo commit continua sendo nossa!"

Nos vemos durante o Bootcamp!

☕🤖🚀

Do HTML ao IBM Z — Quando um Programador COBOL Descobre que o Front-end Também Faz Parte do Mainframe Moderno

 

Bellacosa Mainframe do Html ao IBM Z uma jornada classica do Heroi

☕ Um Café no Bellacosa Mainframe

Do HTML ao IBM Z — Quando um Programador COBOL Descobre que o Front-end Também Faz Parte do Mainframe Moderno

"Durante muitos anos acreditamos que existiam dois mundos completamente diferentes. De um lado, o navegador. Do outro, o mainframe. Hoje sabemos que eles nunca estiveram tão próximos."


Existe uma cena curiosa que provavelmente todo programador COBOL já viveu.

Você está trabalhando em um programa CICS há horas. Ajusta um COMMAREA, altera uma consulta DB2, recompila, faz o BIND, libera para homologação e, de repente, alguém da equipe Web aparece com uma pergunta aparentemente inocente:

"Você consegue disponibilizar isso numa API REST?"

Há alguns anos essa pergunta soaria quase como magia.

Hoje ela faz parte do cotidiano.

Foi justamente para reduzir essa distância que nasceu o APPDEV 33 – Introduction to Web Development – Part 2, expandindo os conceitos apresentados na Parte 1 e mostrando que HTML, CSS e JavaScript não competem com COBOL. Eles trabalham juntos.

Na verdade...

Eles dependem um do outro.



A grande mudança silenciosa

Existe uma falsa impressão de que o desenvolvimento Web pertence apenas ao universo JavaScript.

Não pertence.

Da mesma forma que existe a falsa impressão de que o Mainframe termina na tela verde.

Também não termina.

O navegador moderno tornou-se apenas mais um terminal.

Só que muito mais bonito.

Muito mais amigável.

Muito mais inteligente.

E atrás dele continua existindo aquilo que sempre sustentou bancos, seguradoras, governos, companhias aéreas e bolsas de valores:

IBM Z.


O que aprendemos na Parte 1

Na primeira parte aprendemos três pilares fundamentais.

HTML

A estrutura.

Assim como uma BMS MAP define onde cada campo aparecerá na tela 3270, o HTML define onde cada elemento será exibido dentro da página.

É o esqueleto.


CSS

A aparência.

Se na BMS alterávamos atributos como intensidade, cor, proteção e brilho, no navegador fazemos praticamente a mesma coisa utilizando CSS.

Mudam os nomes.

O conceito continua.


JavaScript

O comportamento.

Enquanto COBOL executa regras de negócio no servidor, JavaScript controla a experiência do usuário no navegador.

Ele responde cliques.

Atualiza informações.

Valida formulários.

Move elementos.

Sem precisar recarregar toda a página.


A analogia perfeita

Mundo WebMundo Mainframe
HTMLBMS MAP
CSSAtributos da Tela
JavaScriptInterface
COBOLRegras de Negócio

Quando essa tabela aparece pela primeira vez, muita gente faz exatamente a mesma expressão:

"Ahhh... agora fez sentido."



O navegador é apenas o começo

Quando digitamos:

https://empresa.com

Nossa mente costuma imaginar algo simples.

Mas, nos bastidores, ocorre uma verdadeira corrida de revezamento.

Usuário

↓

Browser

↓

Servidor Web

↓

HTML

↓

CSS

↓

JavaScript

↓

Página pronta

↓

REST API

↓

z/OS Connect

↓

CICS

↓

COBOL

↓

DB2

↓

Resposta

Observe algo interessante.

O navegador praticamente nunca conversa diretamente com o COBOL.

Existe uma camada intermediária.

E isso é excelente.


O guardião entre dois mundos

No ecossistema IBM Z moderno existe um verdadeiro tradutor universal.

z/OS Connect.

Ele recebe chamadas REST.

Converte JSON.

Invoca programas COBOL.

Executa CICS.

Consulta DB2.

Retorna novamente JSON.

Tudo isso escondendo completamente a complexidade do ambiente z/OS.

É quase como um intérprete simultâneo durante uma conferência internacional.

Cada lado continua falando sua própria língua.

Mas todos passam a se entender.


HTML deixou de ser apenas marcação

Quem aprendeu HTML há quinze anos provavelmente conheceu algo parecido com isto.

<div>
<div>
<div>

Funcionava.

Mas era praticamente impossível descobrir o significado daquela estrutura.

Então surgiu o HTML Semântico.

Agora passamos a utilizar elementos como:

<header>

<nav>

<main>

<section>

<article>

<footer>

Essas palavras possuem significado.

E significado muda tudo.

Motores de busca entendem melhor o conteúdo.

Leitores de tela conseguem navegar corretamente.

Ferramentas de Inteligência Artificial interpretam o contexto.

Até os próximos programadores agradecem.

Porque finalmente conseguem entender a organização da página.


CSS cresceu

Durante muito tempo criar layouts era uma atividade quase artesanal.

Tabelas.

Float.

Clear.

Margens.

Gambiarras.

Então surgiu o Flexbox.

De repente bastava escrever poucas linhas.

display:flex;

justify-content:space-between;

align-items:center;

Como mágica.

Tudo se alinhava.

Responsivamente.

Sem sofrimento.

Depois veio o CSS Grid.

E aí o navegador finalmente ganhou um verdadeiro sistema de layout bidimensional.

Header.

Menu.

Conteúdo.

Rodapé.

Tudo organizado como uma planta arquitetônica.

Curiosamente...

É exatamente assim que pensamos quando desenhamos uma aplicação CICS.

Primeiro definimos a arquitetura.

Depois os componentes.

Depois o fluxo.


JavaScript finalmente ganhou vida

No início JavaScript apenas executava comandos.

Hoje ele reage.

Clique.

Teclado.

Mouse.

Touch.

Formulário.

Mudança de valor.

Tudo é evento.

Usuário

↓

Evento

↓

JavaScript

↓

Resposta

Essa simplicidade mudou completamente a experiência da Web.

Não precisamos mais atualizar páginas inteiras.

Alteramos apenas aquilo que realmente mudou.

Essa ideia parece moderna.

Mas, curiosamente, programadores CICS fazem algo parecido há décadas.

Atualizamos apenas determinados campos da tela.

Não a aplicação inteira.



DOM — A página deixa de ser estática

Imagine que exista uma árvore invisível.

Cada botão.

Cada texto.

Cada imagem.

Cada tabela.

Cada formulário.

Tudo faz parte dessa árvore.

Ela recebe um nome.

DOM — Document Object Model.

JavaScript pode caminhar por essa árvore.

Encontrar um elemento.

Alterar seu conteúdo.

Modificar sua aparência.

Inserir novos componentes.

Tudo instantaneamente.

Sem recarregar o navegador.

É isso que transforma páginas estáticas em aplicações.

Parte II : Quando o Navegador Conversa com o Mainframe

Na primeira parte da nossa conversa percebemos algo importante: HTML, CSS e JavaScript não substituem o COBOL. Eles apenas ocupam uma camada diferente da aplicação.

Agora vem a pergunta que todo programador COBOL faz quando termina de aprender os conceitos básicos.

"Tudo bem... mas como exatamente um clique no navegador consegue executar um programa COBOL dentro do IBM Z?"

É justamente aqui que começa a mágica.

Ou melhor...

A engenharia.



A viagem de um clique

Imagine que um cliente acessa o Internet Banking.

Ele vê um botão.

Consultar Saldo

Aparentemente ele apenas clicou.

Mas esse clique inicia uma longa viagem.

Clique

↓

JavaScript

↓

REST API

↓

JSON

↓

z/OS Connect

↓

CICS

↓

Programa COBOL

↓

DB2

↓

Resposta

↓

JSON

↓

JavaScript

↓

Atualização da Tela

Em menos de um segundo tudo isso aconteceu.

Sem o usuário perceber.

Se o sistema estiver rodando em IBM Z, provavelmente essa operação ocorreu em alguns poucos milissegundos.



REST API — A língua franca da Internet

Há vinte anos cada sistema possuía seu próprio protocolo.

Cada fabricante inventava uma maneira diferente de trocar informações.

Era um verdadeiro caos.

REST mudou completamente esse cenário.

Hoje praticamente qualquer sistema consegue conversar com qualquer outro utilizando HTTP.

Isso significa que um navegador, um aplicativo Android, um iPhone, uma Smart TV ou até uma geladeira inteligente podem acessar exatamente a mesma API.

O IBM Z simplesmente tornou-se mais um participante dessa conversa.



JSON — O envelope que viaja pela Internet

Quando um navegador solicita informações, ele normalmente envia algo parecido com isto.

{
   "cliente":12345
}

Poucos milissegundos depois recebe algo semelhante.

{
   "nome":"Maria",
   "saldo":1250.90,
   "limite":5000
}

Isso é JSON.

Leve.

Organizado.

Fácil de interpretar.

Mas existe uma curiosidade.

O JSON praticamente nunca nasce no navegador.

Na maioria das aplicações corporativas ele foi produzido por um programa COBOL.

Ou seja...

Por trás daquele pequeno documento existe toda uma lógica construída durante décadas.



z/OS Connect — O tradutor universal

Imagine um diplomata durante uma reunião internacional.

Um participante fala japonês.

Outro fala português.

Outro inglês.

Outro espanhol.

Todos conseguem conversar porque existe um intérprete.

z/OS Connect faz exatamente esse papel.

Ele entende REST.

Entende HTTP.

Entende JSON.

Depois traduz tudo para o universo do IBM Z.

Do outro lado...

O programa COBOL continua exatamente igual.

Sem precisar conhecer HTML.

Sem conhecer JavaScript.

Sem conhecer navegador.

Ele apenas recebe parâmetros.

Processa.

Responde.

E volta ao trabalho.



CICS continua fazendo o que sempre fez

Muita gente acredita que REST substituiu CICS.

Na verdade aconteceu justamente o contrário.

REST fez ainda mais aplicações dependerem do CICS.

O fluxo normalmente é este.

Browser

↓

REST API

↓

z/OS Connect

↓

CICS

↓

Programa COBOL

Observe que o CICS continua sendo o gerente das transações.

Ele controla segurança.

Sincronismo.

Rollback.

Commit.

Performance.

Disponibilidade.

Nada mudou.

Apenas surgiram novos clientes.

Antes eram terminais 3270.

Hoje são navegadores.



COBOL continua sendo o cérebro

Existe uma frase que gosto muito.

JavaScript encanta. COBOL decide.

É JavaScript quem anima a tela.

É JavaScript quem valida um campo.

É JavaScript quem muda uma cor.

Mas quem realmente decide se um empréstimo será aprovado?

Quem calcula juros?

Quem verifica limite de crédito?

Quem consulta regras fiscais?

Quem processa milhões de transações diariamente?

COBOL.

Sempre ele.

O navegador apenas apresenta o resultado.



DB2 continua guardando o tesouro

Toda aplicação precisa armazenar informações.

Clientes.

Contas.

Contratos.

Apólices.

Empréstimos.

Pedidos.

Cartões.

É aqui que entra o DB2.

O programa COBOL faz consultas.

Atualiza registros.

Executa commits.

Controla integridade.

Depois transforma essas informações em JSON.

E o navegador recebe tudo pronto.

Perceba algo interessante.

O navegador nunca conversa diretamente com o banco.

Isso seria extremamente perigoso.

Existe sempre uma camada intermediária protegendo os dados.



Organização faz diferença

Quando começamos nossos primeiros programas HTML normalmente criamos apenas um arquivo.

index.html

Pouco tempo depois aparecem outros.

style.css

app.js

logo.png

Mais tarde surgem dezenas.

Depois centenas.

É exatamente nesse momento que aprendemos a organizar projetos.

Projeto

│

├── index.html

├── css

├── js

├── images

├── api

Essa organização pode parecer apenas estética.

Não é.

Ela facilita manutenção.

Facilita testes.

Facilita integração contínua.

Facilita Git.

Facilita DevOps.

Curiosamente...

É exatamente o mesmo motivo pelo qual existem COPYBOOKS.



COPYBOOKS nasceram muito antes dos Frameworks

Muitos desenvolvedores Web acreditam que reutilização nasceu com Frameworks modernos.

Na verdade...

Programadores COBOL fazem isso desde os anos 60.

Sempre que escrevemos

COPY CLIENTE.

Estamos reutilizando componentes.

Assim como um projeto Web reutiliza:

componentes

bibliotecas

frameworks

módulos

Mudam os nomes.

O princípio continua exatamente igual.


Git mudou a forma de trabalhar

Durante décadas o controle de versões no Mainframe foi responsabilidade de ferramentas como:

  • Endevor

  • ISPW

  • Librarian

  • Panvalet

Hoje Git tornou-se praticamente obrigatório.

Não importa se o código está em Java.

Python.

COBOL.

REXX.

Assembler.

Todos podem viver no mesmo repositório.

E isso abriu uma porta enorme para DevOps.



DevOps aproximou dois mundos

Antigamente existia uma divisão muito clara.

O desenvolvedor escrevia código.

Outra equipe compilava.

Outra homologava.

Outra implantava.

Hoje pipelines fazem praticamente tudo isso automaticamente.

Commit

↓

Build

↓

Testes

↓

Análise

↓

Deploy

Essa automação não substitui o programador.

Ela elimina tarefas repetitivas.

E permite que ele invista tempo onde realmente faz diferença.

Criando soluções.

Não apertando botões.



O novo profissional IBM Z

Chegamos então ao ponto mais importante de toda esta formação.

O profissional IBM Z moderno não conhece apenas COBOL.

Ele entende a jornada completa.

COBOL

↓

JSON

↓

REST

↓

HTML

↓

CSS

↓

JavaScript

↓

Git

↓

DevOps

↓

Cloud

↓

IBM Z

Isso não significa abandonar o Mainframe.

Significa ampliar horizontes.

Quanto mais camadas você compreende, maior passa a ser seu valor dentro da organização.

Você deixa de ser apenas um programador COBOL.

Passa a ser alguém capaz de conversar com equipes Web, arquitetos de soluções, especialistas em APIs, profissionais DevOps e engenheiros de Cloud.

E isso muda completamente sua carreira.



☕ Um café antes de continuar...

Existe um detalhe curioso que costuma passar despercebido.

Durante décadas ouvimos que "o futuro substituiria o Mainframe".

Mas aconteceu exatamente o contrário.

Foi o Mainframe que aprendeu a conversar com o futuro.

Hoje ele fala REST, entende JSON, integra-se com Cloud, participa de pipelines DevOps, conversa com aplicações móveis e continua executando, silenciosamente, bilhões de transações por dia.

Talvez essa seja a maior lição desta formação.

O IBM Z nunca ficou parado. Nós é que demoramos para perceber o quanto ele evoluiu.

Parte III — O Desenvolvedor IBM Z Moderno e o Futuro que Já Chegou

"O melhor momento para aprender HTML foi quando surgiu. O segundo melhor momento é hoje. Porque o IBM Z já está esperando por você."

Depois de percorrer toda a jornada desta formação, uma pergunta inevitavelmente aparece.

"O que devo aprender agora?"

Essa talvez seja a maior ansiedade de quem vem do mundo COBOL.

São tantas tecnologias...

HTML.

CSS.

JavaScript.

Git.

REST.

JSON.

Cloud.

DevOps.

Containers.

Docker.

Kubernetes.

OpenShift.

Inteligência Artificial.

À primeira vista parece impossível.

Mas existe uma boa notícia.

Você não precisa aprender tudo de uma vez.

Muito menos abandonar o conhecimento acumulado durante anos.

Na verdade, você já possui aquilo que a maioria dos desenvolvedores modernos ainda está tentando adquirir.

Conhecimento de negócio.

E isso vale ouro.


A árvore do conhecimento

Durante a apresentação utilizamos uma imagem bastante simbólica.

Uma árvore.

À primeira vista ela parece apenas um desenho bonito.

Mas existe um significado escondido.

As raízes

São invisíveis.

Pouca gente presta atenção nelas.

Mas sustentam tudo.

No IBM Z elas representam:

  • COBOL

  • JCL

  • CICS

  • DB2

  • VSAM

  • RACF

  • TSO/ISPF

Curiosamente...

São justamente as tecnologias que mais movimentam dinheiro no planeta.

Ninguém faz propaganda delas.

Mas bilhões de transações acontecem todos os dias graças a elas.


O tronco

O tronco representa aquilo que conecta todas as áreas.

Na nossa metáfora...

É o próprio IBM z17.

Não apenas como computador.

Mas como plataforma.

Segura.

Disponível.

Escalável.

Resiliente.

Enquanto centenas de tecnologias aparecem e desaparecem ao longo das décadas...

O IBM Z continua crescendo.


Os galhos

É onde surgem as novidades.

HTML.

CSS.

JavaScript.

REST.

JSON.

Git.

Cloud.

DevOps.

IA.

Todos eles crescem apoiados nas raízes.

Sem elas...

A árvore não existe.


O roadmap de evolução

Ao longo da apresentação surgiu uma estrada colorida.

Ela representa algo muito importante.

Você não aprende tudo ao mesmo tempo.

Você sobe um degrau por vez.

Primeiro passo

HTML.

Aprenda estrutura.

Nada além disso.

Não tente decorar centenas de elementos.

Entenda a lógica.


Segundo passo

CSS.

Faça páginas bonitas.

Aprenda cores.

Espaçamento.

Layouts.

Responsividade.

Não é preciso virar designer.

Apenas tornar a informação agradável.


Terceiro passo

JavaScript.

Agora a página ganha vida.

Botões passam a funcionar.

Campos são validados.

Elementos aparecem.

Desaparecem.

Mudam dinamicamente.

É nesse momento que muitos programadores COBOL começam a sorrir.

Porque finalmente enxergam lógica de programação novamente.


Quarto passo

REST.

Agora você entende que aplicações conversam.

E que praticamente toda integração moderna utiliza APIs.


Quinto passo

JSON.

Descobre que arquivos gigantes de integração deram lugar a pequenos documentos extremamente simples.


Sexto passo

Git.

Talvez seja a ferramenta que mais muda a maneira de trabalhar.

Commits.

Branches.

Merge.

Pull Request.

Code Review.

Tudo passa a fazer parte da rotina.


Sétimo passo

DevOps.

Agora o código não vive mais sozinho.

Ele entra em pipelines.

Executa testes.

É compilado automaticamente.

Implantado.

Monitorado.

Tudo praticamente sem intervenção humana.


Oitavo passo

Cloud.

Você percebe que Cloud não substituiu o Mainframe.

Ela apenas adicionou mais um ambiente de execução.

Na prática...

Os dois trabalham juntos.


Nono passo

Inteligência Artificial.

Chegamos ao presente.

Mas cuidado.

Existe um enorme equívoco acontecendo.

A IA não substitui conhecimento.

Ela acelera conhecimento.

Quanto mais experiência possui o profissional...

Melhores perguntas ele faz.

Melhores respostas recebe.


Um pequeno segredo da IBM

Existe uma curiosidade interessante.

Durante muitos anos, aprender IBM significava decorar comandos.

Hoje não.

A IBM mudou completamente sua estratégia.

Ela deseja profissionais capazes de integrar tecnologias.

É exatamente por isso que vemos cada vez mais cursos envolvendo:

  • Git

  • APIs

  • HTML

  • JavaScript

  • OpenShift

  • Red Hat

  • Linux

  • Python

  • DevOps

  • IA

Tudo convivendo naturalmente com COBOL.


Easter Egg nº 1 — O retorno da BMS

Você provavelmente achou curioso estudar HTML.

Mas observe.

Uma página HTML possui:

Header.

Body.

Campos.

Botões.

Mensagens.

Formulários.

Menus.

Parece familiar?

Porque é.

BMS fazia exatamente isso.

A diferença é que hoje existem milhões de cores.

Animações.

Responsividade.

E um mouse.

No restante...

Os conceitos continuam incrivelmente parecidos.


Easter Egg nº 2 — O navegador virou um terminal 3270

Calma...

Antes de fechar a página dizendo que enlouqueci...

Pense comigo.

O navegador:

Recebe dados.

Envia comandos.

Mostra telas.

Executa transações.

Atualiza informações.

Consulta banco.

Exatamente como um terminal.

A diferença é que o navegador ganhou superpoderes.

Renderiza vídeos.

Executa JavaScript.

Faz chamadas REST.

Mostra gráficos.

Integra mapas.

Mas continua sendo uma interface.

Assim como o 3270 sempre foi.


Easter Egg nº 3 — HTML não substitui COBOL

Esse talvez seja o maior medo de muitos iniciantes.

"Vou precisar abandonar COBOL?"

Não.

Pelo contrário.

Quanto maior a adoção de APIs...

Mais programas COBOL acabam sendo reutilizados.

Muitos sistemas escritos há quarenta anos hoje atendem aplicações Web modernas.

Mudou apenas a porta de entrada.


O maior erro dos iniciantes

Depois de ministrar diversos treinamentos, comecei a perceber um padrão.

O erro raramente é técnico.

É psicológico.

O aluno olha para a quantidade de tecnologias e conclui:

"Jamais vou aprender tudo isso."

Mas ninguém aprende.

Nem mesmo quem trabalha há trinta anos.

Todos continuam estudando.

Inclusive os IBM Fellows.

Inclusive os Distinguished Engineers.

Inclusive quem desenvolveu boa parte dessas tecnologias.

Aprender nunca termina.


O conselho que gostaria de ter ouvido em 1988

Quando comecei minha carreira, imaginava que bastava aprender COBOL.

Depois vieram CICS.

DB2.

JCL.

VSAM.

REXX.

Assembler.

TCP/IP.

MQ.

Java.

Web Services.

XML.

JSON.

REST.

Git.

Cloud.

DevOps.

IA.

No início achei que era um problema.

Hoje percebo que foi um privilégio.

Poucas profissões permitem acompanhar tantas revoluções tecnológicas sem abandonar completamente aquilo que aprendemos décadas atrás.

O programador COBOL continua reconhecendo um IF.

Um PERFORM.

Um MOVE.

Da mesma forma que reconhece hoje um IF em JavaScript.

A lógica continua sendo a mesma.

Mudam apenas as ferramentas.


O verdadeiro objetivo desta formação

Se ao terminar estas aulas você decorar todos os comandos HTML...

O curso terá sido apenas razoável.

Se aprender Flexbox.

Grid.

DOM.

Eventos.

REST.

JSON.

Também será um bom resultado.

Mas existe um objetivo muito maior.

Perder o medo da palavra "Web".

Porque ela deixou de ser um território distante.

Hoje faz parte do ecossistema IBM Z.


Uma última xícara de café...

Quando observo um IBM z17 processando milhares de transações por segundo enquanto um navegador moderno exibe gráficos, animações e respostas instantâneas, lembro-me de como essa história começou.

Lá atrás, um simples terminal verde.

Depois uma tela BMS.

Mais tarde o TCP/IP.

Vieram XML e Web Services.

Depois JSON.

REST.

Cloud.

Git.

DevOps.

Agora Inteligência Artificial.

O curioso é que, em todas essas fases, alguém decretou que o Mainframe estava ficando para trás.

E, em todas elas, o IBM Z respondeu da melhor maneira possível.

Evoluindo.

Sem perder sua essência.

Sem abandonar sua confiabilidade.

Sem deixar de ser o coração silencioso das maiores empresas do planeta.

Talvez essa seja a maior lição desta jornada.

As tecnologias mudam.

As interfaces evoluem.

As linguagens ganham novos recursos.

Mas a lógica, a arquitetura bem construída e a capacidade de resolver problemas reais continuam sendo o verdadeiro diferencial de um grande profissional.

No fim das contas, HTML, CSS, JavaScript, REST, JSON, Git, DevOps e Inteligência Artificial não são o destino.

São apenas novas ferramentas nas mãos de quem já aprendeu, há muito tempo, que um bom programa começa antes mesmo da primeira linha de código.

E enquanto houver desafios para resolver, clientes para atender e sistemas críticos para manter funcionando, sempre haverá espaço para quem estiver disposto a aprender.

Então abasteça a caneca, abra o editor de código e continue estudando.

Porque a próxima grande evolução do IBM Z provavelmente já começou.

E, quem sabe, ela será escrita por você.

Do conceito à prática: os laboratórios da Formação APPDEV

Teoria sem prática é como um programa COBOL que nunca saiu do editor: pode estar elegante, bem comentado e perfeitamente identado, mas ainda não processou uma única transação.

Por isso, a Formação APPDEV não termina quando o último slide desaparece da tela.

Ela continua nos laboratórios.

É nesses ambientes que HTML deixa de ser apenas uma sequência de tags, CSS deixa de ser decoração, JavaScript deixa de ser uma promessa e a integração com o ecossistema IBM Z começa a ganhar forma diante dos nossos olhos.

Prepare a caneca.

Abra o navegador.

E vamos colocar a mão na massa.


IBM Web Development Labs

O primeiro ponto de partida é o laboratório de desenvolvimento Web utilizado durante a formação:

IBM Web Development Labs
https://vagnerbellacosa.github.io/Lab_WebdevelopmentCoursera/

Nesse ambiente, o aluno pode revisar os fundamentos de HTML, CSS e JavaScript, observar a organização de uma aplicação Web e experimentar a construção de páginas diretamente no navegador.

É o lugar ideal para praticar:

  • estruturação de páginas com HTML;

  • aplicação de estilos com CSS;

  • criação de comportamentos com JavaScript;

  • eventos de clique e formulário;

  • manipulação do DOM;

  • organização de componentes;

  • preparação para consumo de APIs.

O objetivo não é apenas copiar códigos.

É alterar.

Quebrar.

Testar.

Corrigir.

Executar novamente.

Programação continua sendo uma ciência experimental, mesmo quando o laboratório cabe dentro de uma aba do navegador.

O endereço desse laboratório aparece diretamente na apresentação APPDEV como recurso para continuidade dos estudos.


LAB IBM IPL Mainframe

Depois de compreender o funcionamento da camada Web, vale retornar ao coração da infraestrutura:

LAB IBM IPL Mainframe
https://vagnerbellacosa.github.io/LAB_IBM_IPLMainframe/

IPL significa Initial Program Load.

É, de maneira simplificada, o processo de inicialização de um sistema IBM Z. Entretanto, compará-lo apenas ao boot de um computador pessoal seria uma simplificação quase ofensiva.

Em um ambiente corporativo, um IPL envolve planejamento, volumes, parâmetros, dispositivos, subsistemas, segurança, disponibilidade e uma sequência cuidadosamente controlada de operações.

O laboratório ajuda o estudante a enxergar o IBM Z não apenas como uma máquina que executa COBOL, mas como uma plataforma completa, composta por diversas camadas trabalhando em conjunto.

Essa visão é fundamental para o Desenvolvedor IBM Z Moderno.

Mesmo que ele não execute um IPL em produção, precisa compreender o ambiente no qual seus programas vivem.

A apresentação disponibiliza esse laboratório como uma etapa complementar da jornada.


Lab IBM Storage Management

Todo programa precisa de dados.

E todo dado precisa morar em algum lugar.

Lab IBM Storage Management
https://vagnerbellacosa.github.io/Lab_IBM_StorageManagement/

Nesse laboratório, o aluno pode ampliar a compreensão sobre armazenamento no ecossistema IBM Z.

Isso inclui conceitos relacionados a:

  • datasets;

  • volumes;

  • DASD;

  • organização de arquivos;

  • gerenciamento de espaço;

  • políticas de armazenamento;

  • disponibilidade;

  • proteção de dados;

  • relacionamento entre aplicação e infraestrutura.

No mundo Web, falamos em arquivos, pastas, objetos, buckets e bancos de dados.

No IBM Z, encontramos datasets sequenciais, PDS, PDSE, VSAM, catálogos, volumes e políticas SMS.

Novamente, mudam as ferramentas e os nomes.

A necessidade permanece a mesma:

guardar a informação correta, no lugar correto, com segurança e disponibilidade.

O link para o laboratório de Storage Management também faz parte dos materiais de continuidade presentes na apresentação.


LAB IBM Capacity

Uma aplicação pode funcionar perfeitamente para dez usuários e entrar em colapso quando o décimo primeiro aparece.

É nesse momento que descobrimos que desenvolver software não significa apenas produzir resultados corretos.

Também significa produzir resultados dentro do tempo esperado.

LAB IBM Capacity
https://vagnerbellacosa.github.io/LAB_IBM_Capacity/

O laboratório de capacidade introduz uma visão essencial para aplicações corporativas:

  • utilização de CPU;

  • consumo de memória;

  • carga de trabalho;

  • crescimento de demanda;

  • gargalos;

  • throughput;

  • tempo de resposta;

  • planejamento de recursos;

  • comportamento do ambiente em períodos de pico.

Imagine uma aplicação Web consultando uma API REST que chama z/OS Connect, entra no CICS, executa COBOL e consulta DB2.

Cada camada consome recursos.

Cada camada pode introduzir espera.

Cada componente precisa ser observado.

O usuário não está preocupado com o número de instruções executadas.

Ele apenas sabe que clicou no botão e está esperando.

Por isso, capacidade e desempenho também fazem parte da experiência do usuário.

O laboratório de Capacity aparece na apresentação como parte da trilha prática recomendada.


Lab War Room Mainframe

Alguns problemas não chegam educadamente durante o horário comercial.

Eles aparecem de madrugada.

No fechamento mensal.

Durante uma grande campanha.

Ou exatamente quando todos acreditavam que a mudança estava sob controle.

Lab War Room Mainframe
https://vagnerbellacosa.github.io/LAB_WarRoom_Mainframe/

O conceito de War Room representa a investigação coordenada de incidentes.

É o lugar — físico ou virtual — onde profissionais de diferentes áreas analisam juntos:

  • sintomas;

  • logs;

  • mensagens;

  • falhas;

  • tempos de resposta;

  • consumo de recursos;

  • dependências;

  • mudanças recentes;

  • comportamento das aplicações;

  • impacto para o negócio.

No ambiente moderno, uma falha aparentemente simples no navegador pode ter começado muito longe dele.

O botão não respondeu.

Mas a causa pode estar em:

JavaScript
    ↓
REST API
    ↓
z/OS Connect
    ↓
CICS
    ↓
COBOL
    ↓
DB2
    ↓
Storage

É por isso que o profissional capaz de compreender toda a cadeia possui enorme valor.

Ele não observa apenas a mensagem de erro.

Ele segue as pegadas.

O laboratório War Room Mainframe também está entre os recursos indicados na apresentação APPDEV.


Para ir mais longe: Bellacosa Mainframe

A formação termina.

O aprendizado, felizmente, não.

Para continuar explorando COBOL, CICS, DB2, JCL, VSAM, APIs, HTML, CSS, JavaScript, DevOps, segurança, arquitetura e cultura Mainframe, visite:

Um Café no Bellacosa Mainframe
https://eljefemidnightlunch.blogspot.com/

O blog funciona como uma grande biblioteca construída ao longo do tempo.

Há artigos para iniciantes.

Conteúdos técnicos aprofundados.

Histórias sobre a evolução da computação.

Analogias com filmes, séries, quadrinhos, ficção científica e cultura popular.

Porque aprender tecnologia também significa construir memórias.

Um conceito técnico pode ser esquecido.

Mas uma boa história costuma permanecer.

A apresentação indica o Bellacosa Mainframe como espaço para aprofundamento e continuidade dos estudos.


Projeto Coursera Web Developer no GitHub

Ler códigos é importante.

Executá-los é melhor.

Modificá-los é onde o aprendizado realmente começa.

Projeto Coursera Web Developer
https://github.com/VagnerBellacosa/Lab_WebdevelopmentCoursera

Nesse repositório, o aluno pode explorar a organização de um projeto real, comparar arquivos, analisar versões e compreender como HTML, CSS e JavaScript convivem dentro de uma estrutura profissional.

Um repositório Git não é apenas um lugar para guardar código.

Ele registra a história do projeto.

Mostra o que mudou.

Quando mudou.

Por que mudou.

E quem realizou a alteração.

Essa rastreabilidade aproxima o desenvolvimento Web das práticas modernas de DevOps utilizadas também no IBM Z.

O projeto e seu endereço no GitHub aparecem entre os materiais finais da apresentação.


Mais repositórios HTML: mão na massa

Para explorar outros exemplos, projetos e experiências relacionadas a HTML, acesse:

Repositórios HTML de Vagner Bellacosa
https://github.com/VagnerBellacosa?tab=repositories&q=html

Aqui vale seguir uma pequena rotina de laboratório:

  1. Escolha um projeto.

  2. Observe a estrutura de diretórios.

  3. Localize o index.html.

  4. Identifique os arquivos CSS.

  5. Encontre os códigos JavaScript.

  6. Execute a aplicação.

  7. Altere um elemento.

  8. Teste novamente.

  9. Quebre alguma coisa propositalmente.

  10. Descubra como corrigir.

O aprendizado verdadeiro começa quando deixamos de ser visitantes do código e passamos a ser seus investigadores.

A apresentação encerra a seção prática justamente apontando para os repositórios HTML disponíveis no GitHub.


Uma trilha prática sugerida

Para aproveitar melhor os materiais, siga esta sequência:

1. IBM Web Development Labs
              ↓
2. Projeto Web Developer no GitHub
              ↓
3. Repositórios HTML
              ↓
4. LAB IBM IPL Mainframe
              ↓
5. Lab IBM Storage Management
              ↓
6. LAB IBM Capacity
              ↓
7. Lab War Room Mainframe
              ↓
8. Bellacosa Mainframe

Começamos pela interface.

Seguimos para o código.

Entramos no controle de versões.

Descemos até a infraestrutura.

Observamos armazenamento e capacidade.

Investigamos incidentes.

E retornamos ao blog para continuar estudando.

Essa é a verdadeira jornada do Desenvolvedor IBM Z Moderno.

Ele não precisa dominar todas as áreas como especialista.

Mas precisa compreender como elas se conectam.


O diploma encerra uma etapa, não a jornada

Ao terminar a Formação APPDEV, o aluno leva muito mais do que alguns comandos HTML, propriedades CSS ou funções JavaScript.

Ele passa a compreender uma cadeia completa:

Usuário
   ↓
Browser
   ↓
HTML + CSS + JavaScript
   ↓
REST API + JSON
   ↓
z/OS Connect
   ↓
CICS
   ↓
COBOL
   ↓
DB2
   ↓
IBM z17

Essa visão integrada é o verdadeiro resultado da formação.

O certificado registra que uma etapa foi concluída.

Os laboratórios demonstram que a prática começou.

O GitHub registra a evolução.

E o conhecimento de negócio transforma tudo isso em valor.

Por isso, quando alguém perguntar o que existe entre um botão HTML e uma transação COBOL, você não precisará mais imaginar dois mundos separados.

Verá uma única arquitetura.

Uma longa linha luminosa atravessando navegador, API, middleware, transação, programa e banco de dados.

De um lado, a experiência do usuário.

Do outro, a confiabilidade do IBM Z.

No meio deles...

O Desenvolvedor IBM Z Moderno.

Com uma caneca de café sobre a mesa e muitos caminhos ainda esperando para serem explorados.


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

Big Green 2007: o Dia em que a IBM Avisou que o Data Center Ficaria sem Tomada — e Ninguém Imaginava que 19 Anos Depois Chegariam as GPUs

 

Bellacosa Mainframe e o legado do projeto Big Green de 2007

☕ Um Café no Bellacosa Mainframe

Big Green 2007: o Dia em que a IBM Avisou que o Data Center Ficaria sem Tomada — e Ninguém Imaginava que 19 Anos Depois Chegariam as GPUs

🌱 z/VM, consolidação, Linux on System z, Project Big Green, LinuxONE, z17, IA, watts, megawatts e a perturbadora descoberta de que a resposta para a vida, o universo e tudo mais talvez continue sendo 42 — mas alguém precisa descobrir quantos kWh são necessários para calculá-la


NÃO ENTRE EM PÂNICO.

Essa é provavelmente a primeira recomendação que deveria estar impressa em letras grandes e amigáveis na porta de qualquer data center moderno.

A segunda seria:

TRAGA UMA TOALHA.

A terceira, acrescentada pelo administrador do CPD:

E NÃO LIGUE MAIS NENHUM SERVIDOR SEM FALAR COM O ELETRICISTA.

Estamos em 2007.

O iPhone original acaba de aparecer.

Kubernetes não existe.

Docker não existe.

ChatGPT não existe.

Ninguém está perguntando ao computador se deve terminar o namoro.

Uma GPU ainda é, para a maioria das pessoas, aquela coisa que faz Crysis ficar bonito.

E, em algum escritório da IBM, alguém olha para milhares de servidores espalhados por data centers e percebe algo preocupante:

SERVER
SERVER
SERVER
SERVER
SERVER
SERVER
SERVER
SERVER
SERVER
SERVER
SERVER
SERVER

        ↓

       ⚡⚡⚡

A IBM então faz aquilo que empresas de tecnologia costumam fazer quando descobrem que existe um problema enorme:

dá um nome para ele.

Em 10 de maio de 2007, nasce o:

PROJECT BIG GREEN

A IBM anunciou uma iniciativa de US$ 1 bilhão por ano em tecnologias e serviços voltados a melhorar a eficiência energética dos data centers. O projeto incluía uma equipe mundial de centenas de especialistas e atacava servidores, armazenamento, refrigeração, virtualização, gerenciamento e instalações. (IBM)

O detalhe delicioso?

Dezenove anos depois estamos discutindo exatamente o mesmo problema.

Só que agora alguém estacionou um caminhão cheio de GPUs na porta.


🌌 Capítulo I — No princípio havia o mainframe

Muito antes de alguém inventar:

VMware
Docker
Kubernetes
Cloud

o mainframe já tinha descoberto uma coisa fundamental:

computador parado é computador caro.

Imagine uma máquina física utilizada por uma única aplicação:

┌────────────────────┐
│      SERVIDOR      │
│                    │
│ CPU ███░░░░░░░ 30% │
│                    │
└────────────────────┘

Setenta por cento da capacidade pode permanecer ociosa durante boa parte do tempo.

Agora multiplique:

SERVER A → 15%
SERVER B → 20%
SERVER C → 8%
SERVER D → 12%
SERVER E → 27%
SERVER F → 6%

Todos ligados.

Todos consumindo energia.

Todos ocupando rack.

Todos precisando de refrigeração.

Todos possuindo componentes.

Todos precisando ser administrados.

O mainframe desenvolveu outra filosofia:

             MAINFRAME
                 │
        ┌────────┼────────┐
        │        │        │
       VM       VM       VM
        │        │        │
      Linux    Linux    Linux
        │        │        │
      APP A    APP B    APP C

Compartilhe o monstro.


🧙 Capítulo II — z/VM, o ancestral que ninguém convidou para a festa da virtualização

Quando a indústria começou a descobrir entusiasmada a virtualização de servidores x86, havia veteranos de mainframe olhando aquilo com a mesma expressão de um elfo de 4.000 anos vendo humanos descobrirem cerveja.

— Virtualização!

— Fascinante.

— Podemos executar várias máquinas virtuais numa máquina física!

— Sim.

— Isso é revolucionário!

— Naturalmente.

— Você não parece impressionado.

— Meu avô fazia isso.

A linhagem do VM da IBM remonta aos sistemas CP/CMS dos anos 1960 e posteriormente VM/370.

Décadas depois chegamos ao z/VM.

E o conceito fundamental continuava extraordinariamente atual:

HARDWARE
   │
 z/VM
   │
   ├── Linux
   ├── Linux
   ├── Linux
   ├── Linux
   ├── Linux
   └── Linux

Em vez de possuir cem máquinas físicas para cem workloads, você poderia consolidar muitos deles.

Essa palavra — consolidação — será importantíssima para nossa história.

Porque o problema energético não é simplesmente:

Quanto uma CPU consome?

É também:

Quantas CPUs, fontes, placas-mãe, discos, interfaces, switches e ventiladores preciso manter ligados para entregar determinada quantidade de trabalho útil?


🐋 Capítulo III — Surge a epidemia do servidor pequeno

Nos anos 1990 e 2000, servidores Unix e depois x86 se multiplicaram.

Havia uma lógica perfeitamente razoável.

Uma aplicação?

Servidor.

Outra aplicação?

Outro servidor.

Banco?

Servidor.

Web?

Servidor.

E-mail?

Servidor.

Aplicação do departamento que ninguém sabe mais quem usa?

Naturalmente:

servidor.

Logo:

             DATA CENTER

 APP1 → SERVER
 APP2 → SERVER
 APP3 → SERVER
 APP4 → SERVER
 APP5 → SERVER
 APP6 → SERVER
 APP7 → SERVER
 APP8 → SERVER
 ...

Nasceu o famoso:

server sprawl.

O problema não era apenas comprar servidores.

Era alimentá-los.

Refrigerá-los.

Conectá-los.

Atualizá-los.

Monitorá-los.

Administrá-los.

E encontrar espaço físico para colocar todos.

Então alguém da IBM provavelmente contemplou aquilo e pensou:

Vocês passaram vinte anos fugindo de computadores grandes e agora construíram um computador grande utilizando cinco mil computadores pequenos.


🌱 Capítulo IV — 10 de maio de 2007: Big Green

Chegamos ao nosso momento histórico.

A IBM anuncia o Project Big Green.

O problema identificado era essencialmente:

CRESCIMENTO DA COMPUTAÇÃO
          ↓
MAIS SERVIDORES
          ↓
MAIS ELETRICIDADE
          ↓
MAIS CALOR
          ↓
MAIS REFRIGERAÇÃO
          ↓
MAIS ELETRICIDADE

Observe a perversidade.

Energia alimenta o computador.

O computador produz calor.

Você então utiliza mais energia...

para retirar o calor produzido pela primeira energia.

Douglas Adams provavelmente teria apreciado isso.

A solução Big Green não era simplesmente:

COMPRE MAINFRAME.

Era mais abrangente.

Envolvia:

            BIG GREEN
                │
 ┌──────────────┼──────────────┐
 │              │              │
COMPUTE       STORAGE       FACILITIES
 │              │              │
virtualização gerenciamento refrigeração
 │              │              │
consolidação   dados         energia

O projeto pretendia olhar para o data center como sistema.

Essa diferença é importante.


🐧 Capítulo V — 3.900 servidores entram num bar...

E apenas aproximadamente 30 mainframes saem.

Não é piada.

Em 1º de agosto de 2007, a IBM anunciou um dos experimentos mais espetaculares dessa estratégia:

consolidar aproximadamente 3.900 servidores em cerca de 30 System z.

A empresa estabeleceu como objetivo uma redução de aproximadamente 80% no consumo energético relacionado àquele ambiente ao longo de cinco anos. (IBM)

A arquitetura conceitual era:

ANTES

Unix  Unix  x86  Unix  x86
 x86  Unix  x86  x86  Unix
 x86  x86   x86  Unix x86
 ...
      ~3.900 servidores


              ↓


DEPOIS

        ~30 SYSTEM z
              │
            z/VM
              │
      Linux Linux Linux
      Linux Linux Linux
      Linux Linux Linux

Não estavam colocando 3.900 aplicações dentro de uma gigantesca imagem z/OS.

A estrela aqui era:

Linux on System z.

Isso é essencial para entender o restante da história.


🐧 Capítulo VI — “Mas mainframe não roda só COBOL?”

Não.

E aqui mora um dos mal-entendidos mais persistentes sobre IBM Z.

Você pode ter:

IBM Z
 │
 ├── z/OS
 │    ├── COBOL
 │    ├── CICS
 │    ├── Db2
 │    └── IMS
 │
 └── Linux
      ├── Java
      ├── databases
      ├── middleware
      └── aplicações open source

Portanto, a proposta Big Green podia dizer ao cliente:

Não precisa reescrever seu servidor Linux em COBOL.

O COBOLzeiro no fundo da sala:

— Pena.

O arquiteto:

— Não ajude.

Você poderia mover workloads Linux para uma plataforma altamente consolidada.

E z/VM funcionava como peça fundamental dessa equação.


⛽ Capítulo VII — O mainframe ganha marcador de combustível

Em outubro de 2007, IBM avançou ainda mais na conversa sobre energia com aquilo que ficou conhecido como:

Mainframe Gas Gauge.

A ideia era fantástica em sua simplicidade.

Se energia virou recurso de data center, precisamos medi-la como recurso operacional.

Pense:

        PAINEL DO MAINFRAME

CPU      ███████░░░ 70%

MEMORY   ██████░░░░ 60%

I/O      █████░░░░░ 50%

POWER    ███████░░░ 70%

Isso representa uma mudança conceitual enorme.

O capacity planner tradicionalmente perguntava:

Quantos MIPS?

Quantos MSUs?

Quanto DASD?

Quanto storage?

Quanto CPU?

Agora precisava acrescentar:

Quantos WATTS?

E essa pequena pergunta de 2007 acabaria virando uma pergunta monstruosa em 2026:

QUANTOS MEGAWATTS?

🪐 Capítulo VIII — Enquanto isso, nasce outra criatura: cloud

Agora nossa história sofre uma reviravolta digna do Restaurante no Fim do Universo.

IBM tinha diagnosticado corretamente:

SERVIDORES SUBUTILIZADOS
        =
DESPERDÍCIO

Mas o mercado encontrou outra solução.

Em vez de:

MEUS 5.000 SERVIDORES
        ↓
      IBM Z

surgiu:

MEUS 5.000 SERVIDORES
        ↓
 NÃO SÃO MAIS MEUS
        ↓
      CLOUD

Genial.

O servidor desapareceu!

Exceto...

não desapareceu.

Mudou de endereço.

EMPRESA

 servidor servidor servidor

          ↓ CLOUD

HYPERSCALER

 servidor servidor servidor
 servidor servidor servidor
 servidor servidor servidor
 servidor servidor servidor

A cloud pegou vários princípios economicamente semelhantes:

consolidação, virtualização, compartilhamento, automação e melhor utilização da infraestrutura.

Só os aplicou numa escala completamente diferente.


☁️ Capítulo IX — Someone Else's Computer

A famosa piada diz:

The cloud is just someone else's computer.

É uma simplificação, mas contém uma verdade física maravilhosa.

Quando você executa:

CREATE INSTANCE

não ocorre:

☁️
✨
COMPUTADOR
✨

Em algum lugar existe:

DATA CENTER
    │
   RACK
    │
 SERVER
    │
 CPU
 RAM
 NIC
 SSD
    │
    ⚡

A cloud tornou capacidade programável.

Não tornou capacidade infinita.

Essa distinção nos traz diretamente de volta ao Big Green.


🐧 Capítulo X — 2015: LinuxONE aparece

Agora avance oito anos.

17 de agosto de 2015.

A IBM lança oficialmente:

LinuxONE

Os dois nomes originais eram deliciosamente grandiosos:

LinuxONE Emperor

LinuxONE Rockhopper

O Emperor era destinado a grandes organizações; o Rockhopper, a configurações menores. A IBM dizia que o Emperor poderia escalar para milhares de máquinas virtuais ou containers e destacava compatibilidade com software aberto. (Investing.com)

A mensagem era clara.

Você diz:

— Quero Linux.

IBM:

— Certo.

— Open source.

— Certo.

— PostgreSQL.

— Certo.

— Containers.

— Certo.

— Então não quero mainframe.

IBM:

— Temos uma surpresa sobre a caixa onde tudo isso está rodando.

😄


🌱 Capítulo XI — Big Green não morreu; sofreu um RENAME

Esta é minha interpretação histórica favorita.

Não existe uma linha simples:

PROJECT BIG GREEN
        ↓
     SUCESSO

nem:

PROJECT BIG GREEN
        ↓
     FRACASSO

O que aconteceu foi mais interessante.

O branding Big Green desapareceu gradualmente.

Mas seus princípios foram absorvidos.

              BIG GREEN
                  │
                  ↓
           CONSOLIDAÇÃO
                  │
                  ↓
          LINUX ON SYSTEM z
                  │
                  ↓
              LinuxONE
                  │
                  ↓
            HYBRID CLOUD
                  │
                  ↓
          IBM Z + LinuxONE
                  │
                  ↓
                 IA

A campanha morreu.

A pergunta permaneceu:

Quanto trabalho útil conseguimos realizar utilizando determinada quantidade de infraestrutura?


🧮 Capítulo XII — O erro de medir apenas preço por servidor

Imagine:

Arquitetura A

1.000 servidores baratos

Arquitetura B

10 máquinas extremamente caras

Perguntar:

Qual servidor é mais barato?

é quase inútil.

Precisamos calcular:

CUSTO TOTAL
────────────
TRANSAÇÕES

E também:

TRANSAÇÕES / WATT

TRANSAÇÕES / RACK

TRANSAÇÕES / m²

TRANSAÇÕES / ADMINISTRADOR

Além de:

software
licenciamento
networking
storage
backup
energia
refrigeração
operações
downtime
segurança

É o famoso:

TCO — Total Cost of Ownership.

O servidor barato pode gerar arquitetura cara.

O servidor caro pode gerar arquitetura barata.

Ou vice-versa.

A resposta correta da engenharia é aquela frase profundamente irritante:

Depende.


🤖 Capítulo XIII — Então chegou a IA

E agora nossa história enlouquece.

Durante anos, Big Green estava preocupado com:

CPU
CPU
CPU
CPU

Então chegaram os aceleradores.

GPU GPU GPU GPU
GPU GPU GPU GPU
GPU GPU GPU GPU

Modelos modernos de IA podem exigir enormes clusters de aceleradores para treinamento. A própria infraestrutura de desenvolvimento de IA generativa da IBM descreve cenários nos quais milhares de GPUs precisam cooperar em um único treinamento. (arXiv)

De repente:

WATTS
  ↓
kW
  ↓
MW
  ↓
GW?

E alguém na sala diz:

— Precisamos escalar o cluster.

O eletricista pergunta:

— Quanto?

O cientista de dados responde:

— Muito.

— Isso não é unidade.

— Então... absurdamente muito.


⚡ Capítulo XIV — O último megawatt

Agora ligamos este artigo à nossa investigação anterior sobre data centers brasileiros.

O limite computacional moderno começa a envolver:

CPU
GPU
RAM
STORAGE
NETWORK
    │
    ↓
POWER
    │
    ↓
COOLING
    │
    ↓
SUBSTATION
    │
    ↓
TRANSMISSION
    │
    ↓
GENERATION

Eis o detalhe quase filosófico:

quanto mais abstrata ficou a computação...

mais importante voltou a ficar a infraestrutura física.

SERVER
   ↓
VM
   ↓
CONTAINER
   ↓
KUBERNETES
   ↓
CLOUD
   ↓
AI
   ↓
...
   ↓
USINA ELÉTRICA

Parabéns.

Depois de cinquenta anos subindo camadas de abstração, encontramos a tomada.


🧠 Capítulo XV — 8 de abril de 2025: z17 encontra a IA

Agora chegamos ao IBM z17.

A IBM anunciou o sistema em 8 de abril de 2025, descrevendo-o como seu primeiro mainframe inteiramente projetado para a era da IA.

No coração está o:

Telum II.

Acelerador de IA integrado ao processador.

A IBM afirma, para uma configuração e modelo de referência específicos, capacidade superior a 450 bilhões de operações de inferência em um dia, com resposta de aproximadamente 1 ms. O z17 foi anunciado com 50% mais capacidade diária de inferência de IA que o z16. (IBM Brasil Newsroom)

Anúncio oficial do IBM z17 — 8 de abril de 2025

Isso representa uma estratégia muito interessante.

Em vez de:

TRANSAÇÃO
    │
    ↓
MAINFRAME
    │
    ↓
NETWORK
    │
    ↓
GPU FARM
    │
    ↓
AI
    │
    ↓
NETWORK
    │
    ↓
MAINFRAME

certos modelos de inferência podem operar muito próximos da própria transação:

TRANSAÇÃO
    │
    ├── BUSINESS LOGIC
    │
    └── AI INFERENCE
            │
            ↓
         DECISION

Fraude é um exemplo perfeito.


💳 Capítulo XVI — IA perto do dinheiro

Imagine uma compra:

R$ 7.850
03:17
local incomum
dispositivo novo
comportamento estranho

O sistema tradicional pode executar regras:

IF VALOR > LIMITE
   PERFORM ANALISE-FRAUDE
END-IF.

Agora podemos adicionar modelos:

TRANSACTION
     │
     ↓
AI MODEL
     │
     ├── normal → APPROVE
     │
     └── anomalous → REVIEW/BLOCK

Quanto menor a latência entre:

TRANSAÇÃO

e:

INFERÊNCIA

melhor.

Portanto, IA no mainframe não significa necessariamente:

treinar o próximo GPT no z/OS.

Esse seria um entendimento errado.

A proposta mais interessante é:

inferência empresarial próxima dos dados e das transações.


🐬 Capítulo XVII — E as GPUs não vão embora

Isso também precisa ficar claro.

z17 não matou GPU.

LinuxONE não matou x86.

Cloud não matou mainframe.

Mainframe não matou cloud.

A arquitetura futura provavelmente será:

                   WORKLOAD

                      │
       ┌──────────────┼──────────────┐
       │              │              │
       ↓              ↓              ↓
     IBM Z          GPU FARM       CLOUD
       │              │              │
transactional AI   training      elastic compute
core banking       huge models   applications
low latency        HPC           analytics

O segredo será:

colocar cada workload onde ele faz mais sentido.


🏗️ Capítulo XVIII — 7 de julho de 2026: o mainframe entra no rack

E chegamos a um acontecimento recentíssimo.

Em 7 de julho de 2026, IBM anunciou novas configurações compactas para z17 e LinuxONE 5, incluindo single-frame e rack-mount em toda a família.

Pela primeira vez, IBM oferece rack mount ao lado das opções tradicionais em todo o portfólio Z/LinuxONE. (IBM Newsroom)

IBM z17 e LinuxONE 5 compactos — anúncio de 7 de julho de 2026

E leia o contexto escolhido pela própria IBM.

O anúncio fala explicitamente sobre organizações enfrentando baixa disponibilidade de espaço em data centers e altos custos por capacidade elétrica. (IBM Newsroom)

É quase possível ouvir um fantasma de 2007 dizendo:

— Big Green.


🌱 Capítulo XIX — O círculo fecha

Agora podemos montar nossa linha do tempo.

1960s
CP/CMS
   │
   ↓
1970s
VM/370
   │
   ↓
z/VM
   │
   ↓
LINUX ON MAINFRAME
   │
   ↓
2007
PROJECT BIG GREEN
   │
   ↓
CONSOLIDAÇÃO
EFICIÊNCIA
ENERGIA
   │
   ↓
2015
LinuxONE
   │
   ↓
HYBRID CLOUD
   │
   ↓
2025
z17 + TELUM II
   │
   ↓
2026
z17 / LinuxONE 5
RACK MOUNT
   │
   ↓
AI + DATACENTERS
   │
   ↓
MEGAWATTS

Essa não é uma evolução linear planejada desde os anos 1960.

Seria absurdo afirmar isso.

Mas existe uma continuidade conceitual extraordinária:

aumentar utilização e consolidar trabalho.


🧪 Capítulo XX — O grande teste: realidade versus marketing

Agora precisamos fazer aquilo que todo COBOLzeiro deveria aprender cedo:

IF MARKETING
   PERFORM VALIDATE-CLAIM
END-IF

Quando IBM diz:

80% menos energia

ou:

milhares de servidores consolidados

pergunte:

comparado com quê?

Depois:

qual workload?

Depois:

qual utilização?

Depois:

qual configuração?

Depois:

inclui storage?

Depois:

inclui refrigeração?

Depois:

inclui software?

Depois:

qual período?

Isso vale para IBM.

AWS.

Microsoft.

Google.

NVIDIA.

Qualquer fabricante.

Um benchmark sem contexto é como:

DISPLAY "42".

Pode ser a resposta para a vida, o universo e tudo mais.

Mas continuamos sem saber qual era a pergunta.


🌍 Capítulo XXI — Big Green estava certo?

Agora podemos finalmente julgar.

Previsão:

Energia se tornará restrição importante dos data centers.

Correta.

Previsão:

Consolidação será importante.

Correta.

Previsão:

Virtualização aumentará utilização.

Correta.

Previsão:

Precisaremos medir energia como recurso computacional.

Corretíssima.

Previsão implícita:

Mainframe absorverá enormes quantidades do server sprawl mundial.

Não aconteceu na dimensão que aquela narrativa comercial poderia sugerir.

O mercado escolheu também:

x86
+
virtualization
+
hyperscale
+
cloud

E depois:

containers
+
Kubernetes

Mas isso não refutou o problema.

Encontrou outra maneira de administrá-lo.


☁️ Capítulo XXII — Cloud é o Big Green do outro lado do espelho?

Existe uma provocação interessante aqui.

IBM dizia:

CONSOLIDE
MUITOS SERVIDORES
EM MENOS SISTEMAS.

Hyperscalers disseram:

ENTREGUE OS SERVIDORES
PARA NÓS.

NÓS CONSOLIDAMOS.

São arquiteturas radicalmente diferentes.

Mas existe parentesco econômico:

EVITAR OCIOSIDADE
       +
COMPARTILHAR RECURSOS
       +
AUTOMATIZAR
       +
AUMENTAR UTILIZAÇÃO

A cloud não destruiu necessariamente a tese do Big Green.

Em certo sentido, industrializou parte dela.


🧑‍🚀 Capítulo XXIII — Guia do Mochileiro para o programador COBOL

Se você está começando agora, grave estas regras.

1. Não confunda máquina virtual com máquina imaginária.

Existe hardware embaixo.

2. Não confunda elasticidade com infinito.

AUTO-SCALING != MAGIC

3. Aprenda virtualização.

Entender z/VM ajuda enormemente a compreender cloud.

4. Aprenda capacity planning.

CPU continua existindo.

Memória continua acabando.

5. Acrescente energia ao modelo mental.

O capacity planner moderno precisa entender:

COMPUTE
+
POWER
+
COOLING

6. Não transforme arquitetura em religião.

Mainframe não é resposta para tudo.

Cloud não é resposta para tudo.

GPU não é resposta para tudo.

Kubernetes definitivamente não precisa rodar sua torradeira.

Ainda.

7. Sempre procure o custo sistêmico.

Não compare simplesmente:

CPU A vs CPU B

Compare:

SERVIÇO ENTREGUE
────────────────
CUSTO TOTAL

🐳 Capítulo XXIV — O elefante, a baleia e o mainframe

Douglas Adams escreveu sobre criaturas gigantescas surgindo em lugares improváveis.

Nossa indústria também possui algumas.

Durante décadas disseram que o mainframe desapareceria.

Ele viu:

client/server
Unix
Windows NT
Java
x86
VMware
cloud
containers
Kubernetes
serverless
AI

passarem pela porta.

Em 2026 ele continua sentado no CPD.

Agora alguém pergunta:

— Você ainda está aqui?

IBM Z responde:

— Sim.

— Mas agora temos IA.

— Também.

— Linux?

— Sim.

— Containers?

— Sim.

— APIs?

— Sim.

— Cloud híbrida?

— Sim.

— Eficiência energética?

O mainframe olha para uma pasta empoeirada:

PROJECT BIG GREEN
2007

— Engraçado você perguntar.


⚡ Capítulo XXV — O paradoxo final da abstração

A história da computação moderna parece uma tentativa constante de esconder a física.

Primeiro escondemos hardware com:

OPERATING SYSTEM

Depois:

VIRTUAL MACHINE

Depois:

CONTAINER

Depois:

ORCHESTRATOR

Depois:

CLOUD

Depois:

SERVERLESS

Serverless!

O próprio nome é maravilhoso.

É como chamar restaurante de:

KITCHENLESS

porque você não consegue ver a cozinha.

🤣

Então chegou IA consumindo tanta infraestrutura que fomos obrigados a seguir a abstração ao contrário:

AI
 ↓
MODEL
 ↓
GPU
 ↓
SERVER
 ↓
RACK
 ↓
DATA CENTER
 ↓
SUBSTATION
 ↓
POWER GRID
 ↓
POWER PLANT

Encontramos novamente a física.


🌌 Capítulo XXVI — E finalmente descobrimos a pergunta cuja resposta é 42

Deep Thought levou 7,5 milhões de anos para calcular:

42.

Infelizmente ninguém sabia exatamente qual era a pergunta.

Em 2026 finalmente descobrimos.

Um arquiteto entra no data center.

Pergunta:

— Quantas GPUs ainda posso instalar nesse rack?

O facility manager consulta o painel.

Olha a alimentação elétrica.

Consulta refrigeração.

Volta.

42.

O arquiteto fica emocionado.

— A resposta para a vida, o universo e tudo mais!

— Não.

— Não?

— Depois da quadragésima segunda derruba o disjuntor.


☕ Epílogo — O Restaurante no Fim do Data Center

São 23h59.

Em algum lugar do universo, existe um restaurante construído ao lado do último data center ainda com capacidade elétrica disponível.

Sentados à mesa estão:

um programador COBOL de 1978;

um administrador VM de 1985;

um especialista Linux de 2000;

um engenheiro Big Green de 2007;

um arquiteto cloud de 2017;

um engenheiro Kubernetes de 2020;

e um cientista de IA de 2026.

O garçom aproxima-se.

— O que desejam?

O COBOLzeiro:

— Café.

O administrador VM:

— Café.

O arquiteto cloud:

— Café serverless.

O garçom:

— Senhor, alguém ainda precisa fazer o café.

— Estragou a arquitetura.

O cientista de IA abre o notebook.

— Vou executar um modelo de 400 bilhões de parâmetros para decidir o que pedir.

As luzes piscam.

Todos olham para ele.

WARNING

DATA CENTER POWER
98%

O engenheiro Big Green lentamente tira uma pasta da mochila.

Na capa:

IBM
PROJECT BIG GREEN

10 MAY 2007

O cientista de IA pergunta:

— O que é isso?

— Uma mensagem do passado.

— Sobre inteligência artificial?

— Não.

— Cloud?

— Não.

— GPUs?

— Também não.

— Então sobre o quê?

O engenheiro abre o documento.

Tomadas.

Silêncio.

O veterano do z/VM começa a rir.

O COBOLzeiro levanta sua caneca.

Porque finalmente percebe a extraordinária circularidade daquela história:

z/VM
   │
   ↓
VIRTUALIZAÇÃO
   │
   ↓
CONSOLIDAÇÃO
   │
   ↓
BIG GREEN
   │
   ↓
LINUX ON SYSTEM z
   │
   ↓
LinuxONE
   │
   ↓
HYBRID CLOUD
   │
   ↓
z17
   │
   ↓
IA
   │
   ↓
MEGAWATTS
   │
   ↓
...

E depois de sessenta anos de engenharia:

        ┌───────────────┐
        │               │
        │    TOMADA     │
        │      ⚡       │
        │               │
        └───────────────┘

Voltamos ao início.

O velho engenheiro IBM fecha a pasta.

— Em 2007 chamamos isso de Big Green.

O engenheiro Kubernetes pergunta:

— E hoje?

Ele olha para o painel:

POWER CAPACITY: 99%

Pensa alguns segundos.

— Hoje chamamos de terça-feira.


🌱 A moral do Guia do Mochileiro do Mainframe

O Project Big Green de 2007 não venceu o mundo como marca comercial. Cloud e hyperscale acabaram seguindo caminhos diferentes daqueles que uma estratégia centrada no System z poderia sugerir.

Mas sua tese central envelheceu extraordinariamente bem:

Computação não deve ser medida apenas pela potência do processador, mas pelo trabalho útil entregue em relação aos recursos físicos necessários para sustentá-la.

A IBM passou daquela discussão para Linux on System z, depois LinuxONE — lançado em 2015 — e hoje chega ao z17, anunciado em 8 de abril de 2025 com Telum II e aceleração de IA integrada. (Investing.com)

Em julho de 2026, quando a IBM anunciou versões compactas e rack-mount de z17 e LinuxONE 5, voltou a mencionar explicitamente um mundo no qual espaço e capacidade elétrica dos data centers tornaram-se recursos cada vez mais preciosos. (IBM Newsroom)

Portanto:

2007

IBM:
"PRECISAMOS PENSAR
EM COMPUTAÇÃO POR WATT."


2026

IA:
"PRECISO DE OUTRO
CLUSTER DE GPUs."


DATA CENTER:
"PRECISO DE OUTRA
SUBESTAÇÃO."


REDE ELÉTRICA:
"PRECISO DE OUTRA
LINHA DE TRANSMISSÃO."


IBM BIG GREEN:
        ☕

Talvez a maior piada cósmica seja justamente essa.

Passamos décadas discutindo se o futuro seria mainframe, Unix, x86, cloud, Kubernetes ou IA.

E esquecemos que todos eles pertencem à mesma arquitetura fundamental:

//UNIVERSE JOB

//STEP01 EXEC PGM=COMPUTE

//POWER   DD *
          ELECTRICITY
/*

Sem POWER:

IEF450I
UNIVERSE - ABEND=S0WATT

E se isso acontecer...

NÃO ENTRE EM PÂNICO.

Pegue sua toalha.

Pegue seu café.

E, antes de pedir mais 10.000 GPUs,

pergunte ao pessoal do Facilities.

Fim do café — e lembre-se: 42 continua sendo uma excelente resposta, desde que o disjuntor aguente.

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