☕ 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

terça-feira, 7 de julho de 2026

Capítulo 7 — The New York Times (1993)

Bellacosa Mainframe rumo a extincao baboseira de 1993

☕ Um Café no Bellacosa Mainframe

Capítulo 7 — The New York Times (1993)

"Rumo à Extinção"... ou Apenas Mudando de Forma?

Análise da reportagem publicada pelo The New York Times em 1993, que afirmava que o mainframe caminhava para a extinção, e como a evolução do IBM Z demonstrou que inovação e continuidade podem caminhar lado a lado.

Por

Reportagem do The New York Times de 1993 prevendo a extinção do Mainframe
Em 1993, novas previsões indicavam que o Mainframe caminhava para a extinção. A história mostrou um resultado bem diferente.

"A tecnologia raramente desaparece porque outra nasceu. Ela desaparece quando deixa de resolver problemas. Em 1993, o Mainframe continuava resolvendo os maiores problemas da computação corporativa."

— Bellacosa Mainframe

Contexto histórico

No início da década de 1990, a expansão das redes, do modelo Client/Server e dos computadores pessoais reforçou a percepção de que os grandes sistemas centralizados desapareceriam em poucos anos.

Entretanto, bancos, seguradoras, governos e grandes empresas continuavam dependendo do processamento transacional oferecido por COBOL, CICS, Db2 e z/OS.

A lição de 1993

A previsão ignorava décadas de regras de negócio, compatibilidade, escalabilidade, disponibilidade e confiabilidade acumuladas pelos mainframes IBM.

Em vez de desaparecer, a plataforma continuou evoluindo até chegar ao IBM z17, incorporando Linux, APIs, DevOps, cloud híbrida e Inteligência Artificial.


Fevereiro de 1993

Quatro anos haviam se passado desde a primeira reportagem do The New York Times.

O mundo já era outro.

O muro de Berlim havia caído.

A Guerra Fria terminara.

A internet começava a sair dos laboratórios.

O Windows 3.1 conquistava milhões de usuários.

O UNIX continuava crescendo.

As workstations da Sun Microsystems eram o sonho de muitos desenvolvedores.

Os servidores Intel evoluíam rapidamente.

A arquitetura Client/Server dominava praticamente todas as conferências de tecnologia.

E o clima era de euforia.

Parecia que tudo seria reinventado.

Foi nesse ambiente que o The New York Times, em 9 de fevereiro de 1993, voltou ao assunto.

Desta vez utilizando uma expressão ainda mais forte.

Segundo a reportagem, o mainframe estava:

"Hurtling toward extinction."

Ou, em português:

"Correndo em direção à extinção."

A mensagem era clara.

Agora não se tratava apenas de um dinossauro envelhecido.

Tratava-se de uma espécie que caminhava rapidamente para desaparecer. Essa manchete foi posteriormente preservada por Wolfgang Spruth em The Death of the Mainframe como um dos exemplos mais representativos do pensamento dominante da época.


O auge do Client/Server

Se 1989 marcou o nascimento da narrativa...

1993 marcou seu auge.

Era praticamente impossível participar de um congresso de informática sem ouvir dezenas de palestras prometendo o mesmo futuro.

Tudo seria distribuído.

Cada departamento teria seus próprios servidores.

Os grandes CPDs desapareceriam.

A palavra da moda era:

Downsizing.

Na prática significava:

"Vamos trocar um computador enorme por centenas de computadores menores."

A ideia parecia brilhante.

Até que chegaram as primeiras contas de manutenção.


A década em que tudo seria "Open"

Outra característica marcante daquela época era a obsessão por sistemas "abertos".

Parecia que qualquer produto precisava carregar a palavra Open para ser considerado moderno.

Open Systems.

Open Architecture.

Open Computing.

Open Network.

Open Platform.

Open Software.

Era quase uma lei do marketing.

Se fosse "Open", era inovador.

Se fosse IBM, era "legado".

O curioso é que a própria IBM participava ativamente da padronização de tecnologias abertas, apoiava TCP/IP, POSIX, UNIX (AIX) e diversas iniciativas de interoperabilidade.

Mas isso raramente aparecia nas manchetes.


O que ninguém queria admitir

Existe uma característica curiosa do mercado de tecnologia.

Todo vendedor gosta de falar sobre instalação.

Pouquíssimos gostam de falar sobre migração.

Porque instalar um sistema novo é relativamente simples.

Migrar quarenta anos de operação é outra história.

Imagine um grande banco em 1993.

Ele possuía:

  • milhares de programas COBOL;

  • centenas de tabelas Db2;

  • aplicações CICS;

  • processamento batch;

  • integração com terminais 3270;

  • interfaces com caixas eletrônicos;

  • sistemas de compensação bancária;

  • processamento de cartões;

  • folhas de pagamento;

  • contabilidade;

  • auditoria.

Agora imagine um consultor dizendo:

"Vamos reescrever tudo."

A primeira pergunta de um diretor experiente provavelmente seria:

"Quanto custa?"

A segunda:

"Quanto tempo?"

E a terceira:

"Quem assume o risco?"

Essas três perguntas costumavam encerrar muitas reuniões.


A grande confusão

A reportagem do New York Times refletia um erro extremamente comum.

Confundir:

Evolução da arquitetura

com

Substituição da arquitetura.

Essas duas coisas são completamente diferentes.

Sim.

As empresas passaram a utilizar mais servidores.

Sim.

Aplicações departamentais migraram para outras plataformas.

Sim.

PCs transformaram o ambiente corporativo.

Mas isso nunca significou que os sistemas centrais deixariam automaticamente de existir.

Na verdade...

Eles passaram a conversar com muito mais sistemas do que antes.


Bellacosa Mainframe e o iceberg invisivel

O iceberg invisível

Imagine um enorme iceberg.

A parte visível representa:

  • computadores pessoais;

  • servidores;

  • interfaces gráficas;

  • aplicações de escritório.

A parte submersa representa:

  • regras de negócio;

  • processamento financeiro;

  • consistência transacional;

  • auditoria;

  • integração;

  • disponibilidade;

  • segurança.

A imprensa olhava principalmente para a parte visível.

Os arquitetos corporativos precisavam cuidar da parte submersa.

E todos sabemos qual parte sustenta o iceberg.


O COBOL não recebeu o memorando

Vamos imaginar uma situação curiosa.

Na manhã de 9 de fevereiro de 1993...

Um programa COBOL inicia sua execução.

Lê um arquivo VSAM.

Consulta o Db2.

Atualiza uma conta corrente.

Executa um COMMIT.

Encerra normalmente.

Horas depois alguém comenta:

— Você ficou sabendo?

— Do quê?

— O New York Times disse que você está caminhando para a extinção.

O programa responde:

— Interessante...

Mas antes preciso processar mais oito milhões de registros.


O humor da engenharia

Existe uma piada entre veteranos de mainframe.

"COBOL nunca lê jornais."

CICS também não.

Db2 muito menos.

JCL definitivamente não.

Enquanto analistas discutiam o futuro...

Os sistemas continuavam executando exatamente aquilo para o qual foram projetados.

Com estabilidade.

Previsibilidade.

Consistência.

Essas características nunca foram manchetes.

Mas sempre foram extremamente valiosas.


O mercado começou a descobrir a realidade

Curiosamente...

Foi justamente em meados da década de 1990 que muitas empresas começaram a perceber que migrar aplicações críticas era muito mais complexo do que parecia.

Projetos previstos para dois anos levavam cinco.

Orçamentos dobravam.

Alguns triplicavam.

Diversas iniciativas eram canceladas.

Outras terminavam funcionando...

Mas com desempenho inferior.

Os consultores descobriram uma verdade que os programadores COBOL já conheciam havia décadas.

Negócio é mais complicado do que tecnologia.


Enquanto isso... nos laboratórios da IBM

É interessante observar o contraste.

Enquanto jornais discutiam a possível extinção do mainframe...

A IBM trabalhava na próxima geração de sua plataforma.

Novos processadores.

Mais memória.

Mais canais.

Melhor gerenciamento de workload.

Mais virtualização.

Maior integração.

Os engenheiros pareciam ignorar completamente o funeral organizado pela imprensa.

Talvez porque estivessem ocupados demais desenvolvendo o futuro.


O verdadeiro patrimônio

Existe uma frase muito conhecida entre arquitetos de sistemas:

"As empresas não compram computadores. Elas compram continuidade do negócio."

Essa talvez seja a maior diferença entre um laboratório e um banco.

Entre uma universidade e uma seguradora.

Entre uma startup e um governo.

Tecnologia muda.

O negócio precisa continuar funcionando.

Todos os dias.

Sem exceção.

Essa exigência nunca saiu de moda.


Trinta e três anos depois

Agora olhe para 2026.

O IBM z17 processa Inteligência Artificial diretamente na plataforma.

O watsonx integra modelos de IA corporativa.

O COBOL continua evoluindo.

O Db2 incorpora recursos modernos.

O CICS expõe APIs REST.

O z/OS automatiza operações com Ansible.

O BOB integra pipelines DevOps.

O Zowe aproxima o mundo open source do IBM Z.

A plataforma que estaria "correndo rumo à extinção"...

Na verdade estava correndo rumo à modernização.

Existe uma diferença enorme entre essas duas trajetórias.


A terceira grande lição

A reportagem de 1993 ensina algo extremamente atual.

Toda vez que surge uma inovação importante...

Existe a tentação de transformar crescimento em exclusividade.

Foi assim com:

Client/Server.

Internet.

Cloud.

Microservices.

Blockchain.

Metaverso.

Agora acontece com Inteligência Artificial.

Mas a História mostra outra coisa.

A computação raramente substitui completamente suas fundações.

Ela constrói novos andares sobre elas.

Hoje uma aplicação pode começar em um smartphone.

Passar por APIs.

Atravessar Kubernetes.

Conversar com microsserviços.

Chegar ao CICS.

Consultar Db2.

Executar COBOL.

E responder ao usuário em poucos milissegundos.

Esse é o verdadeiro retrato da computação moderna.

Não uma guerra entre tecnologias.

Mas uma colaboração entre décadas de engenharia.


Um último conselho ao Padawan

Quando encontrar uma manchete afirmando:

"A tecnologia X está caminhando para a extinção."

Lembre-se de uma pergunta simples.

Ela ainda resolve um problema importante?

Se a resposta for "sim"...

Talvez ela esteja apenas evoluindo de maneira silenciosa.

Porque, na engenharia, quem faz mais barulho nem sempre é quem entrega mais resultados.

E talvez essa seja a maior ironia da reportagem do New York Times de 1993.

Enquanto o jornal enxergava um fim próximo...

Os engenheiros da IBM estavam preparando o caminho que, décadas depois, levaria ao IBM z17, ao watsonx, ao OpenShift, ao BOB, ao Zowe e a uma plataforma capaz de unir o legado das aplicações COBOL com a Inteligência Artificial corporativa.

O "dinossauro" não caminhava para a extinção.

Estava apenas iniciando mais uma etapa de sua evolução.


Fonte histórica

The New York Times, 9 de fevereiro de 1993, citado pelo Professor Wolfgang Spruth em The Death of the Mainframe. A reportagem utilizou a expressão "hurtling toward extinction" ("correndo rumo à extinção"), tornando-se um dos exemplos mais conhecidos do entusiasmo da imprensa com o movimento Client/Server e com as previsões de substituição dos grandes sistemas corporativos. Décadas depois, ela permanece como um importante registro histórico sobre os desafios de prever a evolução da tecnologia.

Bellacosa Mainframe e o Funeral que nunca aconteceu

C:\BELLACOSA\COBOL\FUNERAL_QUE_NUNCA_ACONTECEU.HTML
★ BELLACOSA MAINFRAME APRESENTA ★

A MORTE DO COBOL

O Funeral que Nunca Aconteceu

Uma investigação histórica em 14 capítulos sobre as previsões, reportagens, buzzwords e profetas que anunciaram repetidamente o fim do COBOL — enquanto bilhões de transações continuavam sendo processadas silenciosamente.

SISTEMA ONLINE — 14 CAPÍTULOS DISPONÍVEIS
DIRETÓRIO DE CAPÍTULOS

README.TXT

Esta série investiga uma das narrativas mais repetidas da história da tecnologia: a suposta morte do COBOL. Durante décadas, revistas, jornais, consultorias e especialistas anunciaram seu desaparecimento. Entretanto, o COBOL permaneceu processando bancos, seguradoras, governos, cartões, pagamentos e sistemas críticos.

Os títulos e links acima são elementos HTML reais, permitindo que mecanismos de busca encontrem e rastreiem todos os capítulos. Os iframes funcionam apenas como previews visuais.

C:\> RUN BELLACOSA.EXE /COBOL /HISTORY /NO-FUNERAL _

★ BELLACOSA MAINFRAME ★ COBOL ★ IBM Z ★ HISTÓRIA DA COMPUTAÇÃO ★

Melhor visualizado em qualquer navegador com café disponível.

Como um Programador COBOL Padawan Pode Aprender Engenharia de Prompt e Conversar com IA Como um Arquiteto IBM Z

 

Bellacosa Mainframe dicas para criar prompts de ia melhores e mais abrangentes

☕ Um Café no Bellacosa Mainframe

Muito Além do "Escreva um Artigo"

Como um Programador COBOL Padawan Pode Aprender Engenharia de Prompt e Conversar com IA Como um Arquiteto IBM Z

"A diferença entre um programador júnior e um especialista raramente está na linguagem que ele conhece. Está na qualidade das perguntas que ele faz."


Imagine a seguinte situação.

São 8h30 da manhã.

Você acabou de entrar no TSO.

Depois de alguns segundos aparece a velha tela verde.

Você abre o SDSF.

Olha a fila.

Mais de 5.000 jobs.

Centenas de programas COBOL.

DB2.

IMS.

CICS.

MQ.

VSAM.

JCL para todos os lados.

Então alguém chega e pergunta:

— "Você conhece COBOL?"

Você responde:

— "Conheço."

Mas alguns minutos depois a mesma pessoa faz outra pergunta.

— "Como o sistema inteiro funciona?"

É aí que muitos programadores percebem que escrever código é apenas uma pequena parte da profissão.

Com Inteligência Artificial acontece exatamente a mesma coisa.

Quase todo mundo sabe escrever:

Escreva um artigo sobre COBOL.

Pouquíssimos sabem construir um pensamento.

E é justamente isso que diferencia quem apenas usa IA de quem trabalha lado a lado com ela.

Hoje vamos conversar sobre isso.

Pegue seu café.


O maior erro de um Padawan

Quando começamos em COBOL fazemos perguntas assim.

Como faço um READ?

Depois evoluímos.

Como funciona um VSAM KSDS?

Mais tarde.

Quando devo utilizar ESDS ao invés de DB2?

Depois.

Qual arquitetura suporta melhor processamento distribuído mantendo consistência ACID?

Percebeu?

As perguntas ficaram maiores.

Mais inteligentes.

Mais completas.

Com IA acontece exatamente igual.


A IA não lê pensamentos

Este talvez seja o maior Easter Egg deste artigo.

A IA possui bilhões de parâmetros.

Conhece milhões de livros.

Documentações.

Artigos.

Normas.

Código.

Mas existe uma coisa que ela nunca saberá.

O que você realmente queria.

Ela precisa inferir.

Quanto menos contexto você fornece...

Mais ela precisa adivinhar.

E adivinhações nunca são boas em engenharia.


Pense como um Sysprog

Um Sysprog nunca instala um produto IBM digitando apenas

INSTALL

Existe documentação.

Pré-requisitos.

SMP/E.

PTFs.

HOLDDATA.

CSI.

Libraries.

Parâmetros.

Porque sistemas complexos exigem contexto.

A IA também.


Um Prompt é Igual a um JCL

Esse é um paralelo que quase ninguém faz.

Observe.

Um JOB possui:

JOB

EXEC

DD

SYSIN

PARM

COND

REGION

CLASS

MSGCLASS

Cada linha informa uma intenção ao sistema.

Agora veja um prompt moderno.

ROLE

OBJECTIVE

AUDIENCE

CONTEXT

CONSTRAINTS

OUTPUT

STYLE

Não é muito diferente.

Na verdade...

É praticamente um JCL para um cérebro artificial.

Easter Egg #1

Sempre que pensar em Prompt Engineering imagine que você está escrevendo um JOB para executar um programa chamado GPT.

A analogia funciona incrivelmente bem.


Bellacosa Mainframe e a lista de frameworks para ampliar seu prompt

Frameworks são PROCs do pensamento

Quem trabalha com JCL sabe o poder de um PROC.

Você reutiliza padrões.

Evita erros.

Padroniza execução.

Frameworks fazem exatamente isso.

Eles são PROCs para organizar ideias.

Ao invés de reinventar a forma de escrever...

Você reutiliza um modelo que já foi validado durante décadas.


AIDA — O Job de Marketing

Imagine que você criou um curso COBOL.

Você escreve:

Meu curso ensina COBOL.

Fim.

Agora usando AIDA.

Attention

"O PIX brasileiro movimenta bilhões todos os dias utilizando tecnologias que nasceram décadas atrás."

Interest

"Você sabia que provavelmente existe COBOL em alguma etapa dessa transação?"

Desire

"Imagine fazer parte desse mundo."

Action

"Comece estudando COBOL no IBM Z."

Perceba.

As informações são praticamente iguais.

O caminho psicológico mudou completamente.


FAB — O erro clássico do iniciante

Quase todo programador apresenta tecnologia assim.

"COBOL possui COMP-3."

Legal.

E daí?

FAB ensina.

Feature

COMP-3.

Advantage

Ocupa menos espaço.

Benefit

Seu processamento Batch movimenta menos bytes, reduzindo I/O e aumentando desempenho.

O benefício sempre responde:

"Por que eu deveria me importar?"


PEEL — Escrevendo como um Arquiteto

Um arquiteto nunca despeja informações.

Ele organiza.

Cada parágrafo possui.

Point

Evidence

Explanation

Link

Observe qualquer documentação IBM.

Quase todas seguem essa lógica.

Nada está ali por acaso.


KISS — Um dos maiores segredos da IBM

Existe uma frase famosa.

Complexidade gera defeitos.

No Mainframe isso vale ouro.

Os melhores programas COBOL que conheci tinham milhares de linhas.

Mas eram fáceis de ler.

Nomes claros.

Fluxo simples.

Poucos IFs aninhados.

Poucos GO TO.

A IA também gosta disso.

Prompt enorme não significa prompt melhor.

Prompt organizado significa prompt melhor.


SOAPSTONE — Quem está falando?

Este framework é um verdadeiro Easter Egg.

Imagine pedir:

"Explique CICS."

Agora compare.

Você é um IBM Distinguished Engineer.

Explique CICS para um programador COBOL Júnior.

Tom inspirador.

Utilize exemplos bancários.

Use analogias.

Explique em português.

Pronto.

Você praticamente contratou um professor.


STAR — O framework escondido das entrevistas

Muitos usam STAR apenas para RH.

Erro enorme.

STAR é excelente para ensinar tecnologia.

Situação

Batch demorava 8 horas.

Tarefa

Reduzir para quatro.

Ação

RUNSTATS.

REORG.

Novo Access Path.

Resultado

2 horas.

Perceba como contar histórias facilita o aprendizado.


SWOT não serve apenas para empresas

Faça SWOT da sua carreira.

Forças

Conhece COBOL.

Fraquezas

Não conhece APIs.

Oportunidades

Modernização IBM Z.

Ameaças

Parar de estudar.

Você acabou de criar um plano de carreira.


OAR — O framework favorito do Bellacosa

Se eu tivesse que ensinar apenas um...

Seria OAR.

Objective.

Audience.

Research.

Toda vez que conversar com IA diga.

Objetivo.

Quem vai ler.

Quanto aprofundar.

Você ficará impressionado com a diferença.


O Easter Egg que ninguém comenta

Todos esses frameworks parecem diferentes.

Mas escondem um padrão.

Observe.

Todos respondem três perguntas.

O que?

Por quê?

Como?

É só isso.

Alguns acrescentam emoção.

Outros acrescentam evidências.

Outros acrescentam contexto.

Mas todos organizam pensamento.


O framework invisível da IBM

Depois de décadas lendo Redbooks percebi algo interessante.

A IBM raramente escreve utilizando apenas INTRO.

Ou apenas PEEL.

Ou apenas AIDA.

Ela mistura vários.

Introdução.

Contexto.

Problema.

Arquitetura.

Implementação.

Boas práticas.

Resumo.

É um framework híbrido.

E isso inspira um conceito poderoso para prompts.


O Framework Bellacosa Mainframe

Depois de muitos artigos, cursos e apresentações, gosto de organizar um prompt técnico em nove camadas:

1. Papel (Role)
Quem a IA deve representar: um arquiteto IBM Z, um especialista em CICS, um DBA Db2 ou um Sysprog.

2. Público (Audience)
Um Padawan de COBOL? Um desenvolvedor Java? Um gerente? A mesma explicação muda completamente conforme a audiência.

3. Objetivo (Objective)
Ensinar, convencer, revisar código, criar uma aula, produzir um laboratório ou escrever um artigo.

4. Contexto (Context)
Qual ambiente? Banco? Seguradora? IBM Z? z/OS 3.2? CICS TS 6.2? Db2 13? Quanto mais contexto, menos a IA precisa adivinhar.

5. Restrições (Constraints)
O que deve evitar? Qual o tamanho? Deve usar exemplos? Pode usar analogias? Deve citar documentação oficial?

6. Estrutura (Framework)
AIDA, PEEL, STAR, SWOT, INTRO... escolha conscientemente a estrutura que melhor atende ao objetivo.

7. Exemplos (Examples)
Mostre o estilo desejado. Um pequeno exemplo vale mais do que dezenas de instruções abstratas.

8. Formato de Saída (Output)
Artigo, slides, tabela comparativa, FAQ, quiz, roteiro de vídeo, laboratório prático ou infográfico.

9. Revisão (Quality Check)
Peça para a IA verificar coerência, consistência técnica, clareza e possíveis melhorias antes de finalizar.

Essa sequência transforma um pedido simples em uma conversa estruturada, muito parecida com a preparação de uma mudança em produção no ambiente IBM Z.


Easter Eggs para quem quer ir muito além

Se você chegou até aqui, aqui estão alguns "segredos" que costumam fazer diferença.

Easter Egg 1 — Dê identidade à IA

Em vez de pedir:

Explique VSAM.

Experimente:

Você é um IBM Fellow especialista em armazenamento. Explique VSAM para um programador COBOL com seis meses de experiência.

A qualidade costuma aumentar porque você definiu um papel, um público e um nível de profundidade.


Easter Egg 2 — Peça comparações

A IA explica muito melhor quando compara conceitos.

Exemplos:

  • VSAM × Db2

  • COMMAREA × Channels & Containers

  • RACF × ACF2 × Top Secret

  • Batch × Online

  • CICS × IMS TM

Comparações obrigam o raciocínio a destacar diferenças importantes.


Easter Egg 3 — Peça analogias

Analogia é uma ferramenta extraordinária para aprender.

"Explique WLM como se fosse um controlador de tráfego aéreo."

"Explique RACF como se fosse um sistema de portaria de um condomínio."

Você criará conexões mentais muito mais fortes.


Easter Egg 4 — Trabalhe em camadas

Não peça tudo de uma vez.

Prefira uma sequência como:

  1. Explique o conceito.

  2. Mostre a arquitetura.

  3. Apresente um exemplo COBOL.

  4. Explique os erros comuns.

  5. Mostre um caso real.

  6. Crie um laboratório.

  7. Elabore um quiz.

  8. Sugira leituras adicionais.

É exatamente assim que um bom curso é construído.


Easter Egg 5 — Transforme a IA em mentora

Em vez de pedir respostas prontas, peça orientação.

"Faça perguntas que me levem a descobrir a solução."

Esse método desenvolve autonomia e pensamento crítico.


Easter Egg 6 — Use múltiplos frameworks

Um artigo pode começar com INTRO, desenvolver cada seção com PEEL, ilustrar experiências usando STAR, analisar tendências com SWOT e concluir com AIDA. Frameworks não competem entre si; eles se complementam.


Easter Egg 7 — Aprenda observando

Leia Redbooks da IBM, RFCs, artigos técnicos e documentação oficial tentando identificar a estrutura utilizada.

Você começará a enxergar padrões que antes passavam despercebidos.


A maior lição de todas

Existe uma frase muito conhecida na área de desenvolvimento:

Garbage In, Garbage Out.

Ela continua verdadeira na era da Inteligência Artificial.

Uma pergunta superficial tende a produzir uma resposta superficial.

Uma pergunta rica em contexto, objetivos e estrutura abre espaço para uma resposta muito mais útil.

Curiosamente, isso também vale para um programador COBOL. Os profissionais mais respeitados que conheci não eram necessariamente aqueles que memorizavam mais comandos do TSO ou mais instruções COBOL. Eram aqueles que faziam as perguntas certas antes de escrever a primeira linha de código.

No fim das contas, Prompt Engineering não é sobre aprender dezenas de siglas. É sobre desenvolver uma forma organizada de pensar, comunicar objetivos e resolver problemas. Os frameworks apresentados neste artigo — AIDA, PEEL, STAR, SWOT, OAR, FAB, SOAPSTONE, KISS e tantos outros — são ferramentas para isso.

Assim como um Padawan aprende primeiro a dominar os fundamentos da linguagem COBOL antes de enfrentar um sistema bancário de milhões de linhas, quem deseja extrair o máximo da IA precisa dominar os fundamentos da comunicação estruturada. A tecnologia muda, os modelos evoluem e novas siglas surgem todos os meses, mas a capacidade de organizar ideias com clareza continua sendo uma habilidade atemporal.

Da próxima vez que abrir o ChatGPT, não pense apenas em "escrever um prompt". Pense que você está preparando um JCL para executar o maior ambiente de processamento de linguagem natural já criado. Defina o papel, o contexto, o objetivo, a estrutura e o formato da saída. Você descobrirá que conversar com uma IA pode ser tão elegante e previsível quanto construir um bom JOB para o z/OS.

E talvez esse seja o maior aprendizado para um COBOL Padawan: antes de dominar a máquina, aprenda a organizar o próprio pensamento. Afinal, os melhores programas, os melhores projetos e os melhores prompts sempre começam da mesma forma: com uma pergunta bem formulada.


segunda-feira, 6 de julho de 2026

Capítulo 6 — InfoWorld (1991)

Bellacosa Mainframe e a infoworld com a morte do mainframe em 1991

☕ Um Café no Bellacosa Mainframe

Capítulo 6 — InfoWorld (1991)

O Dia em que Marcaram a Data da Morte do Mainframe... e Esqueceram de Avisar o Mainframe

Uma análise histórica da previsão atribuída a Stewart Alsop, publicada pela InfoWorld, segundo a qual o último mainframe seria desligado em 15 de março de 1996. O capítulo mostra por que a previsão falhou e como COBOL, CICS, Db2, z/OS e IBM Z continuaram evoluindo.

Por




``` InfoWorld e a previsão de que o último mainframe seria desligado em 15 de março de 1996
Em 1991, uma previsão publicada pela InfoWorld marcou 15 de março de 1996 como a data do desligamento do último mainframe. A data chegou, mas os sistemas continuaram funcionando.

“Prever o futuro já é difícil. Colocar data e hora no futuro é um convite para virar capítulo de livro de História.”

— Bellacosa Mainframe


Existe uma previsão que entrou para a História

Ao longo deste artigo vimos jornalistas dizendo que o mainframe era um dinossauro.

Vimos revistas afirmando que estava ultrapassado.

Outras sugeriam que sua importância diminuiria rapidamente.

Mas em 1991 aconteceu algo diferente.

Muito diferente.

Alguém resolveu fazer aquilo que engenheiros normalmente evitam fazer.

Marcar uma data.

Não um período.

Não "alguns anos".

Não "até o final da década".

Uma data exata.

Dia.

Mês.

Ano.

Uma espécie de prazo de validade para o IBM Mainframe.

Foi aí que nasceu uma das frases mais famosas — e mais lembradas — da história da computação.


Bellacosa Mainframe e as previsoes erradas na historia da informatica
Stewart Alsop

O protagonista desta história era Stewart Alsop.

Na época, Alsop era um dos jornalistas e analistas de tecnologia mais influentes dos Estados Unidos.

Escrevia para a InfoWorld.

Suas colunas eram lidas por executivos, arquitetos, CIOs e fabricantes de tecnologia.

Quando Stewart Alsop publicava uma opinião...

O mercado prestava atenção.

Era uma época em que revistas especializadas moldavam decisões de investimento de bilhões de dólares.

Não existia YouTube.

Não existia LinkedIn.

Não existiam influenciadores digitais.

As revistas técnicas eram uma das principais fontes de informação da indústria.

E foi exatamente nelas que apareceu uma das previsões mais ousadas da história da TI.


A frase que atravessou três décadas

Em sua coluna, Stewart Alsop escreveu:

"On March 15, 1996, someone will unplug the last mainframe."

Em tradução livre:

"No dia 15 de março de 1996 alguém desligará o último mainframe."

Não era uma metáfora.

Não era uma figura de linguagem.

Era uma previsão literal.

Uma data específica.

O último mainframe seria desligado.

Fim da história.

Essa frase foi posteriormente preservada pelo professor Wolfgang Spruth em The Death of the Mainframe e acabou se tornando uma das citações mais conhecidas sobre previsões tecnológicas equivocadas.


Um exercício de imaginação

Vamos imaginar o mundo naquela sexta-feira.

15 de março de 1996.

Nosso Padawan COBOL acorda cedo.

Olha o calendário.

Sorri.

Pensa consigo mesmo:

"Então hoje é o grande dia..."

Enquanto toma café...

Em algum lugar do planeta...

Segundo a previsão...

Um operador deveria caminhar lentamente até um enorme IBM Mainframe.

Respirar fundo.

Olhar para o painel.

Apertar o botão de desligamento.

Apagar a última luz.

Fechar a porta do CPD.

Ir para casa.

Fim da era dos mainframes.

Bonita cena.

Daria um excelente filme.

Existe apenas um pequeno problema.

Nada disso aconteceu.


O que realmente aconteceu em 15 de março de 1996?

Enquanto a previsão dizia que o último mainframe seria desligado...

Milhares deles continuavam funcionando normalmente.

Bancos abriram suas agências.

Companhias aéreas venderam passagens.

Seguradoras emitiram apólices.

Governos arrecadaram impostos.

Operadoras de cartão autorizaram milhões de compras.

Empresas pagaram funcionários.

O mundo simplesmente continuou girando.

Os mainframes também.


O humor involuntário da História

Existe algo fascinante sobre previsões muito específicas.

Elas envelhecem rapidamente.

Imagine alguém dizendo hoje:

"No dia 12 de agosto de 2031 desaparecerá a última aplicação Java."

Ou:

"Em 18 de fevereiro de 2034 ninguém mais utilizará bancos relacionais."

Provavelmente riríamos.

Foi exatamente isso que aconteceu com a frase de Alsop.

Ela deixou de ser uma previsão.

Transformou-se em um símbolo.

Hoje ela aparece em livros, palestras e cursos de arquitetura corporativa como um lembrete de que entusiasmo tecnológico não substitui análise técnica.


Por que tanta confiança?

A pergunta mais interessante não é:

"Como ele errou?"

A pergunta correta é:

"Por que tanta gente acreditou que ele acertaria?"

A resposta está no contexto da época.

Client/Server crescia rapidamente.

Windows NT aparecia como alternativa corporativa.

UNIX dominava universidades e centros de pesquisa.

RISC parecia imbatível.

As redes TCP/IP se expandiam.

O custo dos servidores diminuía ano após ano.

Tudo parecia caminhar para uma descentralização completa.

O erro foi imaginar que descentralização significava abandono da computação central.

Na prática...

As duas evoluíram juntas.


Enquanto isso... na IBM

Existe uma diferença curiosa entre marketing e engenharia.

Marketing faz anúncios.

Engenharia entrega versões.

Enquanto a indústria discutia o funeral do mainframe...

Os laboratórios da IBM continuavam trabalhando.

Mais desempenho.

Mais memória.

Mais canais de I/O.

Mais virtualização.

Mais confiabilidade.

Mais escalabilidade.

Sem responder às manchetes.

Sem entrar em debates públicos.

A IBM simplesmente fez aquilo que engenheiros costumam fazer.

Continuou desenvolvendo tecnologia.


O maior erro da previsão

Curiosamente...

O erro não foi subestimar o hardware.

Foi subestimar o software.

Na década de 1990 já existiam milhões de linhas de código COBOL executando operações críticas.

Centenas de milhões.

Depois bilhões.

Esses programas não eram apenas código.

Eram décadas de conhecimento empresarial.

Legislação.

Contabilidade.

Tributação.

Seguros.

Operações bancárias.

Regras de crédito.

Logística.

Folha de pagamento.

Não existia botão mágico chamado:

"Converter quarenta anos de experiência para outra plataforma."

Essa parte raramente aparecia nas apresentações de marketing.


O Padawan encontra Stewart Alsop

Vamos imaginar uma conversa impossível.

Nosso Padawan COBOL viaja no tempo.

Encontra Stewart Alsop.

Pergunta educadamente:

— Senhor Alsop...

Posso fazer uma pergunta?

— Claro.

— Quantas linhas de COBOL existem hoje nos bancos americanos?

Silêncio.

— Quantas delas serão reescritas até março de 1996?

Mais silêncio.

— Quantos testes serão necessários?

Outro silêncio.

Então o Padawan conclui:

— Talvez o hardware mude mais rápido do que as regras de negócio.


A elegância da retratação

Ao contrário do que muitas pessoas imaginam, Stewart Alsop não fingiu que nada aconteceu.

Anos depois, ele reconheceu publicamente que sua previsão havia falhado.

Admitiu que havia subestimado a importância dos sistemas corporativos centralizados e a preferência das empresas por plataformas extremamente confiáveis para cargas críticas. Essa postura é frequentemente lembrada como um exemplo raro de humildade intelectual na indústria de tecnologia.

Isso merece respeito.

Errar faz parte da ciência.

Reconhecer o erro faz parte da honestidade intelectual.


Trinta anos depois...

Agora olhe ao redor.

Estamos em 2026.

O IBM Z executa cargas de Inteligência Artificial.

O IBM z17 incorpora recursos avançados de aceleração para IA.

O watsonx integra modelos corporativos.

O BOB (Build Open Builder) automatiza pipelines modernos.

O Enterprise COBOL continua evoluindo.

O Db2 13 recebe melhorias constantes.

O CICS TS conversa com APIs REST.

O z/OS integra ambientes híbridos.

O Ansible automatiza operações.

O Zowe aproxima o mundo open source do IBM Z.

O sistema que deveria ter sido desligado em março de 1996...

Hoje conversa com Kubernetes.

É difícil imaginar um desfecho mais irônico.


O verdadeiro vencedor

Muitas pessoas dizem que o mainframe venceu.

Na verdade...

Não houve vencedor.

O que venceu foi uma ideia muito maior.

A ideia de que arquiteturas sólidas evoluem.

O IBM Z incorporou Linux.

Depois Java.

Depois Web Services.

Depois APIs.

Depois DevOps.

Depois containers.

Depois OpenShift.

Depois Inteligência Artificial.

Sem abandonar aquilo que fazia desde os anos 1960.

Processar transações críticas com confiabilidade extraordinária.


A maior lição da história

Existe uma frase muito conhecida entre historiadores:

"Datas são perigosas."

Quando alguém afirma:

"Isso acontecerá algum dia..."

Talvez esteja certo.

Quando afirma:

"Acontecerá exatamente neste dia..."

O risco aumenta enormemente.

Foi exatamente isso que tornou a previsão de Stewart Alsop tão inesquecível.

Ela ganhou uma data.

E a História adora testar previsões com datas.


O conselho do velho mestre ao Padawan

Sempre que você ouvir alguém dizendo:

"Essa tecnologia desaparecerá até o ano X."

Respire.

Pegue um café.

Faça três perguntas.

  • Quem depende dela?

  • Quanto custa substituí-la?

  • Ela continua resolvendo problemas reais?

Se a resposta para a última pergunta for "sim"...

Talvez ela ainda tenha uma longa vida pela frente.

Foi exatamente isso que aconteceu com o IBM Mainframe.

No dia 15 de março de 1996 ninguém desligou o último IBM Z.

Na verdade...

Trinta anos depois...

O "último mainframe" virou IBM z17, executando Inteligência Artificial, DevOps, cloud híbrida, COBOL moderno, Db2, CICS, Linux e milhões de transações por segundo.

O único equipamento realmente desligado naquele dia foi a previsão.


Fonte histórica

InfoWorld, coluna de Stewart Alsop (1991), preservada pelo Professor Wolfgang Spruth em The Death of the Mainframe. A previsão de que "o último mainframe seria desligado em 15 de março de 1996" tornou-se uma das citações mais emblemáticas da história da computação, sendo lembrada até hoje como um exemplo clássico dos riscos de extrapolar tendências tecnológicas sem considerar a realidade operacional e o valor das aplicações de missão crítica.

Contexto histórico

No início da década de 1990, o crescimento do modelo Client/Server, dos servidores UNIX, das redes locais e dos computadores pessoais criou a percepção de que os grandes sistemas centralizados seriam rapidamente substituídos.

A previsão ignorava, entretanto, o valor acumulado em aplicações COBOL, regras de negócio, processamento transacional, segurança, disponibilidade, auditoria e integração corporativa.

A lição da previsão

A data de 15 de março de 1996 tornou-se um símbolo dos riscos de transformar tendências tecnológicas verdadeiras em conclusões absolutas. O Client/Server cresceu, mas o mainframe também evoluiu.

Em 2026, o ecossistema IBM Z reúne COBOL moderno, CICS, Db2, z/OS, Linux, APIs, DevOps, automação e inteligência artificial.

Bellacosa Mainframe e o Funeral que nunca aconteceu


 
C:\BELLACOSA\COBOL\FUNERAL_QUE_NUNCA_ACONTECEU.HTML
★ BELLACOSA MAINFRAME APRESENTA ★

A MORTE DO COBOL

O Funeral que Nunca Aconteceu

Uma investigação histórica em 14 capítulos sobre as previsões, reportagens, buzzwords e profetas que anunciaram repetidamente o fim do COBOL — enquanto bilhões de transações continuavam sendo processadas silenciosamente.

SISTEMA ONLINE — 14 CAPÍTULOS DISPONÍVEIS
DIRETÓRIO DE CAPÍTULOS

README.TXT

Esta série investiga uma das narrativas mais repetidas da história da tecnologia: a suposta morte do COBOL. Durante décadas, revistas, jornais, consultorias e especialistas anunciaram seu desaparecimento. Entretanto, o COBOL permaneceu processando bancos, seguradoras, governos, cartões, pagamentos e sistemas críticos.

Os títulos e links acima são elementos HTML reais, permitindo que mecanismos de busca encontrem e rastreiem todos os capítulos. Os iframes funcionam apenas como previews visuais.

C:\> RUN BELLACOSA.EXE /COBOL /HISTORY /NO-FUNERAL _

★ BELLACOSA MAINFRAME ★ COBOL ★ IBM Z ★ HISTÓRIA DA COMPUTAÇÃO ★

Melhor visualizado em qualquer navegador com café disponível.

No COBOL e no Futebol : A Distância Entre a Besta e o Bestial é Mínima

 

Bellacosa Mainframe a distancia entre a besta e o bestial é minima

☕ Um Café no Bellacosa Mainframe

A Distância Entre a Besta e o Bestial é Mínima

O Que Todo Programador COBOL Padawan Precisa Saber Sobre Futebol, Carreira, Derrotas, Excelência e Como Não Repetir os Erros da Seleção Brasileira

Existe uma frase que sempre gostei:

A distância entre a besta e o bestial é mínima.

Ela vale para o futebol.

Vale para o mercado financeiro.

Vale para IBM Z.

Vale para COBOL.

Vale para qualquer profissão onde a excelência é construída durante anos e pode desaparecer em apenas alguns minutos.

A derrota da Seleção Brasileira em uma Copa do Mundo costuma gerar um fenômeno curioso. Durante meses ou anos, jogadores são tratados como gênios absolutos. São vendidos por centenas de milhões. Ganham Champions League, Libertadores, Bola de Ouro, títulos nacionais, reconhecimento mundial.

Então chega um único jogo.

Noventa minutos.

Uma eliminação.

E, de repente...

"Não prestam."

"São superestimados."

"Nunca decidiram."

Mas será mesmo?

A resposta é não.

E exatamente aqui existe uma enorme lição para quem trabalha com tecnologia.



Bellacosa Mainframe glorias passadas nao entram em campo

O currículo não entra em campo

Imagine um desenvolvedor COBOL.

Vinte anos de carreira.

Milhares de programas escritos.

Centenas de milhões de transações processadas diariamente.

Zero incidentes graves.

Então...

Em uma madrugada...

Um JOB falha.

Uma alteração gera um ABEND.

O banco fica indisponível.

O cliente vê apenas aquele momento.

Ninguém lembra dos vinte anos anteriores.

O mercado funciona exatamente assim.

Você vale muito...

...até cometer um erro enorme.

Isso parece cruel.

Mas também ensina algo extremamente importante:

Reputação demora décadas para ser construída e segundos para ser questionada.


O futebol não perdoa.

A tecnologia também não.

Grandes craques encerraram a carreira sem conquistar o maior título do futebol.

Zico.

Cruyff.

Puskás.

Di Stéfano.

George Best.

E tantos outros.

Eles deixaram de ser gênios?

Claro que não.

O problema é que o mundo costuma resumir carreiras complexas em um único indicador.

No futebol:

"Copa do Mundo."

Na tecnologia:

"Conhece Cloud?"

"Sabe IA?"

"Tem Kubernetes?"

"Programa em Python?"

Como se décadas de experiência desaparecessem por causa da moda do momento.

Não desaparecem.

Mas também não bastam.


O maior erro da Seleção

Quando analisamos diversas eliminações brasileiras ao longo dos anos, aparece um padrão.

Não foi falta de talento.

Nunca foi.

Talento sempre existiu.

O problema quase sempre esteve em outros fatores.

Planejamento.

Organização.

Adaptação.

Controle emocional.

Leitura do adversário.

Tomada de decisão.

Humildade.

Tudo aquilo que também diferencia um excelente profissional de um profissional apenas talentoso.


COBOL também possui "seleções brasileiras"

Você provavelmente conhece alguém assim.

Sabe tudo de COBOL.

Tudo de JCL.

Tudo de CICS.

Tudo de Db2.

Resolve qualquer dump.

Mas...

Não sabe explicar uma solução.

Não documenta.

Não compartilha conhecimento.

Não conversa com outras equipes.

Não aprende novas tecnologias.

Não entende APIs.

Não conhece Git.

Nunca abriu um VS Code.

Nunca estudou IA.

Nunca aprendeu OpenTelemetry.

Nunca ouviu falar de MCP.

Resultado?

Continua sendo excelente...

...mas apenas dentro de um pequeno espaço.

Enquanto isso, outro profissional talvez saiba menos COBOL.

Muito menos.

Mas entende arquitetura.

Comunicação.

Negócio.

Cloud.

Integração.

Observabilidade.

Automação.

Esse segundo profissional acaba crescendo mais rápido.

Não porque programa melhor.

Mas porque resolve problemas maiores.


O ego derrota muito mais carreiras que a falta de conhecimento

No futebol existe uma frase antiga.

"Time ganha campeonato."

Não estrelas.

No Mainframe isso é ainda mais verdadeiro.

Nenhum sistema bancário sobrevive graças a um único programador.

Existe uma enorme equipe.

Arquitetos.

DBAs.

Operadores.

Analistas.

Segurança.

Infraestrutura.

Storage.

Redes.

Middleware.

Desenvolvimento.

Negócio.

Quando alguém acredita ser indispensável...

Começa sua decadência.


A tecnologia muda o campo

Imagine um craque dos anos 1980 jogando exatamente da mesma maneira hoje.

Provavelmente sofreria.

Não porque ficou ruim.

Mas porque o jogo mudou.

Com COBOL acontece exatamente isso.

Programar COBOL em 2026 não é o mesmo que programar em 1996.

Hoje existe:

  • APIs REST

  • JSON

  • XML

  • Git

  • DevOps

  • CI/CD

  • IA Generativa

  • RAG

  • MCP

  • OpenTelemetry

  • Kafka

  • IBM MQ

  • z/OS Connect

  • Containers

  • VS Code

  • Zowe

  • GitHub Copilot

Quem ignora isso...

Está treinando para um campeonato que já terminou.


O maior adversário nunca foi o concorrente

Sempre fomos nós mesmos.

A seleção brasileira muitas vezes entrou acreditando que venceria apenas pela camisa.

Na tecnologia acontece igual.

"Tenho trinta anos de COBOL."

Ótimo.

E agora?

O mercado pergunta outra coisa.

"O que você aprendeu este ano?"

Essa pergunta separa veteranos relevantes de veteranos nostálgicos.


O verdadeiro craque nunca para de treinar

Cristiano Ronaldo continua treinando.

Messi continua treinando.

LeBron continua treinando.

Djokovic continua treinando.

Nenhum deles diz:

"Já sei tudo."

Então por que um desenvolvedor faria isso?


A derrota também ensina

Existe uma enorme diferença entre fracassar...

...e desperdiçar um fracasso.

Toda derrota entrega dados.

Toda falha produz métricas.

Todo incidente ensina.

Todo ABEND conta uma história.

O problema é quando o profissional apenas procura culpados.

Os melhores fazem outra pergunta.

"O que esse erro está tentando me ensinar?"

Essa pergunta muda completamente uma carreira.


O profissional bestial

Existe um momento em que o conhecimento deixa de ser apenas técnico.

O profissional passa a enxergar padrões.

Antes resolvia problemas.

Agora evita que eles aconteçam.

Antes corrigia JOBs.

Agora melhora processos.

Antes escrevia código.

Agora desenha arquitetura.

Antes respondia chamados.

Agora elimina categorias inteiras de chamados.

Esse é o salto.

Não é escrever mais linhas.

É produzir menos problemas.


A distância entre besta e bestial

Ela realmente é mínima.

A diferença normalmente está em pequenas decisões repetidas durante anos.

Ler um capítulo por dia.

Fazer um laboratório por semana.

Estudar inglês.

Escrever artigos.

Compartilhar conhecimento.

Documentar soluções.

Participar de comunidades.

Ensinar iniciantes.

Aceitar críticas.

Aprender algo novo todos os meses.

Parece pouco.

Mas multiplique isso por dez anos.

Você terá duas pessoas completamente diferentes.


Como não repetir os erros da Seleção

Se eu pudesse deixar alguns conselhos para um COBOL Padawan, seriam estes.

Nunca confie apenas no talento.

Talento sem disciplina desaparece.

Nunca pare de estudar.

Seu maior concorrente talvez ainda esteja na faculdade.

Aprenda negócios.

Programas existem para resolver problemas de empresas.

Quem entende o negócio sempre entrega mais valor.

Aprenda comunicação.

Grandes carreiras raramente são construídas apenas digitando código.

Domine o legado.

Mas converse com o futuro.

COBOL continuará importante.

Mas ele faz parte de um ecossistema muito maior.

Documente tudo.

Sua memória falha.

A documentação permanece.

Automatize tarefas repetitivas.

Tempo economizado vira tempo de aprendizado.

Ensine.

Quem ensina aprende duas vezes.

Aceite feedback.

Orgulho custa caro.

Humildade rende dividendos durante décadas.


O próximo campeonato já começou

Enquanto muitos discutem apenas o último resultado...

Os campeões já estão treinando para o próximo.

No mercado de tecnologia acontece exatamente isso.

Enquanto alguns reclamam da IA...

Outros aprendem a utilizá-la.

Enquanto alguns dizem que COBOL morreu...

Outros integram COBOL com modelos de linguagem.

Enquanto alguns criticam APIs...

Outros conectam sistemas escritos há cinquenta anos com aplicações modernas.

Enquanto alguns vivem do passado...

Outros constroem o futuro.


O verdadeiro título

Talvez você nunca seja o programador mais famoso.

Talvez nunca apareça em uma conferência internacional.

Talvez nunca escreva um livro.

Talvez nunca ganhe um prêmio.

E tudo bem.

Seu verdadeiro título pode ser outro.

Ser aquele profissional em quem todos confiam.

Aquele que mantém milhões de brasileiros utilizando bancos, cartões, seguros, hospitais e serviços públicos sem sequer imaginar que existe um IBM Z trabalhando silenciosamente nos bastidores.

Existe uma enorme beleza nisso.

Porque os melhores sistemas são exatamente aqueles que ninguém percebe que estão funcionando.


Um café antes do apito final

No futebol, um detalhe muda uma Copa.

Na tecnologia, um detalhe muda uma carreira.

A diferença entre a "besta" e o "bestial" raramente está no QI, na faculdade ou no talento nato. Ela está na disciplina silenciosa de quem decide melhorar 1% todos os dias.

Não transforme uma derrota em sentença. Transforme-a em combustível.

Não permita que um sucesso vire acomodação. Faça dele apenas o ponto de partida para o próximo desafio.

A Seleção Brasileira ainda voltará a disputar Copas. Alguns jogadores conquistarão títulos, outros encerrarão a carreira sem levantar a taça mais importante do mundo. Isso faz parte do esporte.

Da mesma forma, você terá projetos brilhantes e projetos difíceis. Terá noites resolvendo ABENDs, incidentes e integrações improváveis. Terá momentos em que será reconhecido e outros em que seu trabalho passará despercebido.

Continue evoluindo.

Continue curioso.

Continue humilde.

Porque, no fim das contas, o mercado não procura apenas quem sabe COBOL.

Procura profissionais capazes de aprender, adaptar-se, colaborar e construir o futuro sem esquecer as lições do passado.

E talvez essa seja a maior definição de excelência.

Não vencer sempre.

Mas nunca parar de evoluir.

Nos encontramos no próximo café.


PS: Não foi de virada a Noruega dominou o tempo todo o jogo, mas com licensa poetica, fica essa errata, somente nos ultimos minutos o Neymar diminuiu o marcador. Vamos ver quantos vão notar e comentar.



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