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

Translate

Mostrar mensagens com a etiqueta client server. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta client server. Mostrar todas as mensagens

sábado, 11 de julho de 2026

Capítulo 11 — O Cemitério dos Buzzwords

Bellacosa Mainframe e o cemiterio dos Buzzwords

☕ Um Café no Bellacosa Mainframe

Capítulo 11 — O Cemitério dos Buzzwords

Enquanto Enterravam o Mainframe, os Modismos É que Foram Desaparecendo

Uma viagem bem-humorada pelos grandes modismos da indústria de TI que, em diferentes épocas, prometeram substituir completamente o mainframe, mas acabaram tornando-se apenas mais um capítulo da história da computação.

Por


Cemitério dos buzzwords e a continuidade da evolução do IBM Mainframe
Client/Server, Downsizing, Rightsizing, Cloud, Blockchain, Metaverso e outros modismos passaram. O IBM Mainframe continuou evoluindo e integrando cada uma dessas tecnologias.

"Na Tecnologia da Informação existem duas certezas: sempre surgirá um novo buzzword e alguém dirá que ele acabará com tudo o que veio antes."

— Bellacosa Mainframe

O ciclo dos buzzwords

Ao longo das últimas décadas, diversos conceitos ganharam enorme popularidade: Client/Server, Downsizing, Rightsizing, SOA, BPM, Virtualização, Cloud Computing, Containers, Blockchain, Metaverso e, mais recentemente, Inteligência Artificial.

Todos trouxeram contribuições importantes para a indústria. O erro não foi sua existência, mas a crença recorrente de que cada novidade eliminaria completamente tudo o que existia antes.

A estratégia vencedora

Enquanto o mercado frequentemente falava em substituição, o ecossistema IBM Z seguiu outro caminho: integração. Linux, Java, APIs REST, containers, OpenShift, Git, DevOps, Ansible, watsonx e IA passaram a conviver naturalmente com COBOL, CICS, Db2 e z/OS.

A grande lição

A História mostra que tecnologias realmente bem-sucedidas raramente eliminam completamente as anteriores. Elas evoluem, coexistem e se integram para resolver problemas de negócio de forma cada vez mais eficiente.

Bellacosa Mainframe e o museu da computação

Bem-vindo ao Museu da Computação

Imagine que exista um enorme museu.

Não um museu de computadores.

Um museu de previsões.

Cada sala possui um cartaz.

Um slogan.

Uma promessa.

Uma tecnologia revolucionária.

Ao lado...

Uma frase.

"Agora o Mainframe acabou de verdade."

Você entra na primeira sala.

Depois na segunda.

Na terceira.

Na décima.

Na vigésima.

E começa a perceber um padrão curioso.

Os nomes mudam.

A promessa continua exatamente a mesma.

Sala 1 — Client/Server

Ano: 1990.

A promessa:

"Agora tudo ficará distribuído."

O que realmente aconteceu?

Sim.

Aplicações distribuídas conquistaram o mercado.

Mas os grandes sistemas transacionais continuaram centralizados.

Hoje praticamente toda grande empresa utiliza ambos.

Resultado:

✔ Client/Server venceu.

✔ Mainframe também.

Empate por integração.

Sala 2 — RISC vai acabar com CISC

Ano: 1992.

Naquela época parecia que a arquitetura RISC resolveria todos os problemas da computação.

PowerPC.

SPARC.

MIPS.

Alpha.

PA-RISC.

Cada fabricante prometia o mesmo.

Mais desempenho.

Mais simplicidade.

Mais futuro.

Enquanto isso...

Os engenheiros da IBM continuavam evoluindo a arquitetura do mainframe.

Resultado?

RISC tornou-se extremamente importante.

Mas o IBM Z continuou evoluindo em paralelo.

Mais uma previsão que confundiu inovação com substituição.

Sala 3 — Windows NT dominará os datacenters

Quem viveu os anos 90 certamente se lembra.

Windows NT era apresentado como o sucessor natural dos grandes sistemas.

O marketing era gigantesco.

As demonstrações impressionavam.

As revistas adoravam.

O problema apareceu alguns anos depois.

Administrar milhares de servidores individuais revelou-se muito mais complexo do que muitos imaginavam.

Windows NT tornou-se uma plataforma importante.

Mas nunca substituiu o processamento crítico realizado pelos grandes sistemas corporativos.

Sala 4 — Java vai matar COBOL

Essa talvez seja uma das histórias mais divertidas.

Final da década de 1990.

Java dominava as conferências.

A frase mais comum era:

"Agora ninguém mais escreverá COBOL."

A IBM respondeu de maneira extremamente elegante.

Colocou Java dentro do mainframe.

Em vez de lutar contra Java...

Resolveu executá-lo.

Hoje Java e COBOL convivem naturalmente no IBM Z.

Mais uma vez...

Integração venceu.

Sala 5 — ERP elimina sistemas legados

Lembra dessa?

Bastaria instalar um grande ERP.

Pronto.

Todos os sistemas antigos desapareceriam.

Na prática...

Milhares de empresas descobriram que seus diferenciais competitivos estavam justamente naqueles sistemas chamados de "legado".

Resultado.

Os ERPs foram integrados aos sistemas existentes.

Não o contrário.

Sala 6 — SOA vai reescrever tudo

No início dos anos 2000 surgiu outro grande entusiasmo.

SOA.

Service-Oriented Architecture.

A promessa parecia familiar.

Tudo seria reescrito como serviços.

O que aconteceu?

Os serviços realmente apareceram.

Mas muitos deles passaram simplesmente a chamar programas COBOL já existentes.

CICS ganhou Web Services.

Depois REST.

Depois APIs modernas.

Mais uma vez...

O velho código apenas ganhou uma nova porta de entrada.

Sala 7 — Cloud vai acabar com os Datacenters

Essa previsão ainda aparece de tempos em tempos.

Segundo muitos especialistas...

Tudo iria para a nuvem.

Os datacenters desapareceriam.

Chegamos a 2026.

O que vemos?

Cloud.

Cloud híbrida.

Cloud privada.

Edge Computing.

IBM Z.

LinuxONE.

Todos convivendo.

A realidade novamente preferiu integração.

Sala 8 — Blockchain vai substituir bancos

Lembra de 2018?

Tudo seria Blockchain.

Contratos.

Documentos.

Identidade.

Cartórios.

Pagamentos.

Governos.

Algumas aplicações realmente prosperaram.

Outras desapareceram.

Os bancos?

Continuaram utilizando COBOL.

Db2.

CICS.

Mainframe.

E, curiosamente, várias soluções Blockchain passaram a integrar sistemas tradicionais.

Sala 9 — O Metaverso Corporativo

Talvez um dos buzzwords mais efêmeros.

Por algum tempo parecia que todas as reuniões aconteceriam em ambientes virtuais tridimensionais.

Empresas correram.

Investidores também.

Hoje...

As videoconferências continuam dominando.

O metaverso encontrou nichos específicos, mas não substituiu a forma como o mercado corporativo trabalha.

Mais uma previsão grandiosa que encontrou uma realidade bem mais pragmática.

Sala 10 — A Inteligência Artificial substituirá todos os programadores

Chegamos ao presente.

Agora o discurso mudou novamente.

A manchete da vez é:

"A IA escreverá todo o código."

Será?

A IA certamente mudou a forma como desenvolvemos software.

Produz documentação.

Sugere algoritmos.

Explica código.

Auxilia em testes.

Aumenta produtividade.

Mas alguém ainda precisa:

Entender o negócio.

Projetar arquitetura.

Validar regras.

Garantir segurança.

Tomar decisões.

Assim como aconteceu em 1990...

Existe uma enorme diferença entre automatizar tarefas e substituir conhecimento.

O padrão finalmente aparece

Observe todas essas previsões.

Client/Server.

RISC.

Windows NT.

Java.

ERP.

SOA.

Cloud.

Blockchain.

Metaverso.

IA.

Todas seguem praticamente o mesmo roteiro.

Primeiro aparece uma inovação verdadeira.

Depois surgem expectativas enormes.

Em seguida alguém anuncia:

"Agora acabou para o Mainframe."

Alguns anos passam.

A inovação permanece.

O Mainframe também.

A maior ironia de todas

Enquanto dezenas de tecnologias tentavam substituir o IBM Mainframe...

O IBM Mainframe fazia exatamente o contrário.

Incorporava cada uma delas.

Linux?

Venha.

Java?

Pode entrar.

REST?

Sem problema.

Containers?

Ótimo.

OpenShift?

Também.

Git?

Claro.

Python?

Bem-vindo.

Ansible?

Excelente.

Inteligência Artificial?

Vamos integrar.

Essa talvez seja a característica mais impressionante da plataforma IBM Z.

Ela raramente rejeita uma inovação.

Ela procura descobrir como utilizá-la.

O Padawan visita o cemitério

Nosso Padawan encontra um enorme portão.

Na entrada está escrito:

Cemitério dos Buzzwords

Ele começa a caminhar.

Primeira lápide.

"Client/Server substituirá tudo."

Segunda.

"COBOL acabou."

Terceira.

"O último mainframe será desligado."

Quarta.

"Cloud elimina os datacenters."

Quinta.

"IA elimina os programadores."

Ele continua andando.

Chega ao final do cemitério.

Olha para trás.

Percebe algo curioso.

Nenhuma lápide pertence ao IBM Mainframe.

Então escuta uma voz.

É o velho mestre.

— Está vendo?

— O quê?

— Buzzwords normalmente têm prazo de validade.

Arquiteturas bem projetadas costumam durar muito mais.

O segredo nunca foi resistir

Existe uma ideia equivocada.

Algumas pessoas imaginam que o IBM Mainframe sobreviveu porque resistiu às mudanças.

Não.

Ele sobreviveu justamente porque mudou.

Muito.

O System/360 de 1964 é completamente diferente do IBM z17 de 2026.

Mudaram:

Processadores.

Memória.

Compiladores.

Linguagens.

Virtualização.

Ferramentas.

Integração.

Observabilidade.

Automação.

DevOps.

Cloud.

IA.

O que permaneceu foi a filosofia.

Compatibilidade.

Disponibilidade.

Confiabilidade.

Escalabilidade.

O verdadeiro "dinossauro"

No primeiro capítulo vimos o mainframe ser chamado de dinossauro.

Chegamos agora ao final desta jornada.

E talvez possamos fazer uma pergunta provocativa.

Quem realmente envelheceu mal?

O IBM Mainframe?

Ou a ideia de que toda tecnologia nova precisa destruir completamente a anterior?

Porque o z17 continua evoluindo.

O COBOL continua recebendo novos recursos.

O Db2 continua inovando.

O CICS continua processando bilhões de transações.

O z/OS continua sendo atualizado.

Muitos dos buzzwords que prometeram acabar com eles...

Hoje aparecem apenas em livros de História da Computação.

A última aula para o Padawan

Sempre que surgir um novo modismo...

Não pergunte:

"Isso vai matar o Mainframe?"

Pergunte:

"Como o Mainframe vai incorporar isso?"

Essa pergunta possui muito mais chances de acertar o futuro.

Foi assim com:

Internet.

Java.

Linux.

Web Services.

Open Source.

Containers.

Cloud.

OpenShift.

DevOps.

E agora...

Inteligência Artificial.

Talvez a maior habilidade do IBM Mainframe nunca tenha sido processar bilhões de transações.

Sua maior habilidade foi outra.

Aprender continuamente sem abandonar aquilo que já funcionava.

Essa é uma lição que vale não apenas para computadores.

Vale também para arquitetos.

Para desenvolvedores.

Para empresas.

E, principalmente, para cada novo Padawan COBOL que inicia sua jornada.

Porque buzzwords vêm e vão.

Mas engenharia bem construída continua escrevendo a História.

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.

Publicada por à(s) Sem comentários:
Etiquetas: , , , , , , , , , , , , , ,

quinta-feira, 2 de julho de 2026

Capítulo 2 — A Década dos Buzzwords

Bellacosa Mainframe invente um nome um jargao e mate o mainframe

☕ Um Café no Bellacosa Mainframe

Capítulo 2 — A Década dos Buzzwords

Quando Bastava Inventar um Nome Bonito para Declarar a Morte do Mainframe

Uma análise histórica e bem-humorada dos buzzwords dos anos 1990, como Client/Server, Downsizing, Open Systems, RISC e Windows NT, que prometiam substituir o mainframe enquanto COBOL, CICS, Db2, JCL, z/OS e IBM Z continuavam evoluindo.

Por

A Década dos Buzzwords e as previsões sobre a morte do mainframe 

"Toda geração acredita ter inventado a computação. Toda geração descobre, alguns anos depois, que ainda existe um COBOL pagando salários."
— Bellacosa Mainframe

Bem-vindo aos anos 90

Se você é um Padawan COBOL e nasceu depois dos anos 2000, talvez seja difícil imaginar o clima que existia na indústria de tecnologia durante a década de 1990.

Hoje estamos acostumados a ouvir expressões como:

  • IA Generativa

  • LLM

  • Agentic AI

  • RAG

  • MCP

  • AI Native

  • Platform Engineering

  • Data Mesh

  • Cloud Native

Mas, naquela época, esses nomes ainda nem existiam.

Em compensação...

Os corredores das empresas eram inundados por outra coleção de palavras mágicas.

Client/Server.

Open Systems.

Downsizing.

Distributed Computing.

Workgroups.

LAN Computing.

Enterprise Networking.

Network Computing.

Object-Oriented.

Visual Programming.

Windows NT.

RISC.

Cada uma dessas expressões era apresentada como a solução definitiva para todos os problemas da computação corporativa.

Se um fabricante queria vender um servidor...

Colocava "Open" no nome.

Se queria vender uma ferramenta...

Chamava de "Client/Server".

Se queria convencer o diretor financeiro...

Prometia "Downsizing".

Se queria impressionar investidores...

Falava em "Distributed Computing".

Era a época em que o marketing tecnológico descobriu que uma boa buzzword podia vender mais do que um bom benchmark.

A religião do Client/Server

Nenhum termo foi tão poderoso quanto Client/Server.

Hoje ele parece apenas uma arquitetura comum.

Mas, no início dos anos 90, era quase uma religião.

Consultores viajavam o mundo inteiro mostrando diagramas semelhantes.

          [PC]
            |
          [Servidor]

Depois olhavam para um desenho de um mainframe.

          [IBM Mainframe]

E diziam:

— Está vendo?

Esse modelo é antigo.

Centralizado.

Monolítico.

O futuro é distribuído.

A ideia parecia excelente.

Dividir a carga.

Comprar servidores menores.

Dar autonomia às áreas.

Substituir um computador gigantesco por centenas de máquinas menores.

Na teoria...

Tudo fazia sentido.

Na prática...

As empresas descobriram algo curioso.

Um servidor pequeno é barato.

Quinhentos servidores pequenos...

Nem tanto.

Downsizing: a promessa de economizar milhões

Outra palavra extremamente popular era Downsizing.

O discurso era sedutor.

"Por que comprar um computador enorme quando podemos comprar dezenas de computadores baratos?"

A lógica parecia impecável.

O problema era um pequeno detalhe.

Ninguém havia calculado o custo de administrar centenas de computadores.

De repente apareceram problemas novos.

Mais backups.

Mais discos.

Mais sistemas operacionais.

Mais patches.

Mais licenças.

Mais administradores.

Mais falhas.

Mais consumo de energia.

Mais refrigeração.

Mais monitoramento.

Mais suporte.

O CPD não desapareceu.

Ele apenas ficou espalhado por vários racks.

Open Systems

Outra expressão quase obrigatória era:

Open Systems

Era impossível abrir uma revista técnica sem encontrar esse termo.

O curioso é que poucas pessoas conseguiam definir exatamente o que significava.

Na prática, "Open" podia significar qualquer coisa.

UNIX.

POSIX.

TCP/IP.

X/Open.

Padrões.

Interoperabilidade.

Ou simplesmente...

Marketing.

Parecia existir uma regra informal:

Se o produto fosse chamado de "Open", automaticamente ficava moderno.

Enquanto isso...

O IBM já executava protocolos abertos, TCP/IP, UNIX (AIX), SNA, APPC e diversas tecnologias de interoperabilidade, embora raramente recebesse esse crédito.

O medo do "grande computador"

Havia também um componente psicológico.

Mainframes eram enormes.

Caros.

Impressionantes.

Ficavam em salas refrigeradas.

Tinham operadores.

Consoles.

Fitas magnéticas.

Grandes discos.

Para muitos executivos, aquilo parecia representar uma tecnologia "do passado".

Os servidores menores transmitiam outra sensação.

Modernidade.

Agilidade.

Liberdade.

Só havia um problema.

A física não liga para marketing.

Nem a teoria das filas.

Nem a consistência transacional.

Nem o CAPEX.

Nem o OPEX.

Nem a Lei de Amdahl.

O nascimento da guerra comercial

Pouca gente comenta isso.

Mas boa parte daquela narrativa foi impulsionada por uma disputa extremamente agressiva entre fabricantes.

IBM.

DEC.

Sun Microsystems.

HP.

Compaq.

Silicon Graphics.

Data General.

Tandem.

Se uma empresa conseguisse convencer o mercado de que o mainframe estava morrendo...

Automaticamente venderia mais servidores.

Não havia nada de ilegal nisso.

Era competição.

Mas muitas análises técnicas começaram a misturar engenharia com marketing.

E essa mistura quase nunca produz boas previsões.

A guerra das arquiteturas

Outro grande "vilão" da época era o processador CISC.

Segundo muitos especialistas, o futuro pertencia aos processadores RISC.

As apresentações eram quase sempre iguais.

RISC era simples.

Elegante.

Rápido.

CISC era complexo.

Antigo.

Lento.

O detalhe curioso?

Enquanto essa discussão acontecia, os engenheiros da IBM continuavam evoluindo silenciosamente sua arquitetura, introduzindo novas gerações de processadores, cache, canais de I/O e mecanismos sofisticados de paralelismo.

No mundo real...

O cliente queria saber apenas uma coisa.

"Meu banco continua funcionando?"

Quando o PowerPoint venceu a engenharia

Existe uma piada antiga entre arquitetos.

"Quanto mais bonito o slide, maior a chance de esconder um benchmark incompleto."

Nos anos 90 isso acontecia frequentemente.

Os gráficos mostravam:

⬆️ Crescimento dos PCs.

⬆️ Crescimento das LANs.

⬆️ Crescimento do UNIX.

⬇️ Queda do preço dos servidores.

E então aparecia a conclusão inevitável:

"O mainframe acabou."

Só que os gráficos raramente mostravam:

  • disponibilidade;

  • MTBF;

  • MTTR;

  • throughput;

  • custo operacional ao longo de dez anos;

  • consistência transacional;

  • segurança;

  • auditoria;

  • produtividade por administrador;

  • custo de migração.

Era como comparar um caminhão com uma motocicleta apenas pelo preço de compra.

O Padawan COBOL observa tudo isso...

Imagine nosso Padawan viajando no tempo.

Ele entra em uma feira de tecnologia de 1993.

Escuta uma palestra.

"COBOL acabou."

Ele sorri.

Passa em outro estande.

"CICS morreu."

Ele continua andando.

Mais adiante.

"Db2 será substituído."

Ele pega um café.

Mais um corredor.

"O futuro é sem mainframe."

Ele olha discretamente para o relógio.

Naquele exato momento...

Milhões de cartões de crédito estão sendo autorizados.

Bilhões de dólares estão sendo transferidos.

Companhias aéreas continuam emitindo passagens.

Governos processam impostos.

Seguradoras calculam riscos.

Tudo em plataformas que, segundo os palestrantes, já deveriam estar mortas.

Nosso Padawan apenas pensa:

— "Esse defunto trabalha bastante..."

Buzzwords envelhecem. Engenharia permanece.

Existe uma diferença fundamental entre uma moda e uma arquitetura.

A moda vende expectativa.

A arquitetura entrega resultado.

Durante mais de cinquenta anos, dezenas de buzzwords apareceram prometendo substituir completamente o mainframe.

Algumas realmente trouxeram avanços importantes.

Outras desapareceram tão rapidamente quanto surgiram.

A computação distribuída venceu?

Sim.

Cloud existe?

Claro.

Containers revolucionaram o desenvolvimento?

Sem dúvida.

Mas nenhuma dessas tecnologias eliminou automaticamente a necessidade de plataformas transacionais altamente confiáveis.

Elas passaram a coexistir.

E o IBM Z evoluiu para integrar-se a esse novo ecossistema.

A primeira lição para um Padawan COBOL

Quando você ouvir alguém afirmar que uma tecnologia "vai morrer em dois anos", faça três perguntas simples:

  1. Quem está dizendo isso?

  2. Quem ganha dinheiro se isso acontecer?

  3. Os maiores bancos do mundo concordam?

Se a terceira resposta for "não"...

Talvez seja apenas mais uma buzzword.

O verdadeiro inimigo nunca foi o mainframe

O maior erro da década de 1990 não foi apostar em novas arquiteturas.

Elas eram necessárias e transformaram a indústria.

O erro foi acreditar que inovação exige destruição completa do que veio antes.

A história mostrou exatamente o contrário.

Os sistemas corporativos evoluíram por integração, não por substituição.

O IBM Z incorporou Linux, Java, APIs REST, OpenShift, DevOps, Zowe, watsonx, IA embarcada, COBOL moderno, Db2 13 e CICS TS, enquanto as arquiteturas distribuídas amadureceram ao seu redor.

O resultado não foi a vitória de um lado sobre o outro.

Foi um ecossistema híbrido, onde cada tecnologia ocupa o espaço em que entrega mais valor.

E talvez essa seja a maior ironia da década dos buzzwords:

Enquanto muitos gastavam energia tentando enterrar o mainframe, os engenheiros da IBM estavam ocupados fazendo algo muito menos chamativo...

Preparando a próxima geração.

Bellacosa Mainframe e a serie 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.

 


Publicada por à(s) Sem comentários:
Etiquetas: , , , , , , , , , , , , , ,

domingo, 15 de maio de 2022

🧙‍♂️ YUJI E A DUNGEON DOS SISTEMAS ABERTOS — QUANDO O MAINFRAME DESCOBRIU QUE O UNIX NÃO ERA O CHEFÃO FINAL

 

Bellacosa Mainframe e uma visão sobre sistemas e arquiteturas

☕ Um Café no Bellacosa Mainframe

🧙‍♂️ YUJI E A DUNGEON DOS SISTEMAS ABERTOS — QUANDO O MAINFRAME DESCOBRIU QUE O UNIX NÃO ERA O CHEFÃO FINAL

COBOL, mainframe, microinformática, Unix, RISC, cliente-servidor, sistemas abertos, padrões, 4GL, TCO, auditoria, Shadow IT — e o dia em que Yuji descobriu que o servidor barato podia sair muito caro.


🎬 PRÓLOGO — YUJI ENCONTROU UM COMPUTADOR DEBAIXO DA MESA

Yuji entrou silenciosamente no Departamento Financeiro.

Como sempre, ninguém percebeu sua chegada.

Atrás dele caminhavam alguns slimes.

— Puru puru.

Yuji olhou para uma mesa.

Havia um computador.

Olhou para outra.

Outro computador.

Mais adiante encontrou mais seis.

Então um dos slimes apareceu trazendo uma informação:

Detectado aplicativo desconhecido.

Yuji parou.

— Aplicativo desconhecido?

O slime respondeu:

FINANCEIRO_FINAL.XLS

Outro slime apareceu.

FINANCEIRO_FINAL2.XLS

Mais um:

FINANCEIRO_FINAL_AGORA_VAI.XLS

Yuji ficou alguns segundos olhando para aquilo.

Finalmente perguntou:

— Qual deles fecha o balanço da empresa?

Silêncio.

Era o final dos anos 1990.

Durante décadas, a empresa conhecera perfeitamente seu grande computador central. Programas COBOL eram desenvolvidos, compilados, testados e colocados em produção seguindo procedimentos relativamente controlados.

Então chegaram os computadores pessoais.

Baratos.

Fáceis de instalar.

Espalharam-se pelas mesas.

Depois vieram redes locais, servidores departamentais, Unix, arquiteturas RISC, cliente-servidor, bancos de dados distribuídos e Internet.

A capacidade computacional escapara do castelo.

E ninguém sabia exatamente quantos monstros havia agora na floresta.

Yuji acabara de encontrar uma nova dungeon:

a microinformática corporativa.


🏰 CAPÍTULO 1 — QUANDO O COMPUTADOR MORAVA NO CASTELO

Programador COBOL iniciante, antes de falarmos sobre Unix, RISC ou sistemas abertos, precisamos voltar algumas décadas.

Durante grande parte da história da computação empresarial, processamento era algo centralizado.

Imagine uma empresa possuindo um grande computador:

TERMINAL ─┐
TERMINAL ─┤
TERMINAL ─┤
TERMINAL ─┼──── MAINFRAME ──── DADOS
TERMINAL ─┤
TERMINAL ─┤
TERMINAL ─┘

Os usuários trabalhavam em terminais.

O terminal frequentemente tinha pouca capacidade de processamento local. Ele permitia ao usuário interagir com aplicações executadas no computador central.

É daí que aparece uma palavra importantíssima naquele período:

HOST.

Host é o sistema que hospeda e executa serviços ou workloads utilizados por outros sistemas ou usuários.

No mundo corporativo clássico, o mainframe era frequentemente esse host.

Centenas ou milhares de pessoas poderiam compartilhar recursos da mesma máquina.

Um bancário consultava uma conta.

Outro registrava uma transferência.

Um programa batch processava arquivos.

Outro atualizava banco de dados.

Tudo acontecia sobre uma infraestrutura centralizada.

Para quem está começando em COBOL, pense em:

COBOL
  ↓
CICS
  ↓
Db2 / IMS / VSAM 
  ↓
z/OS
  ↓
IBM Z

Naturalmente, essa é uma simplificação, mas ela ajuda a visualizar a ideia.

O mainframe não significa apenas "computador grande".

Sua importância está na capacidade de administrar grandes quantidades de trabalho compartilhado de maneira controlada.


🖥️ CAPÍTULO 2 — O PC ESCAPOU DO CPD

Então aconteceu algo revolucionário.

Computadores ficaram menores e baratos.

O processamento começou a sair do CPD e chegar às mesas.

Era uma transformação profunda porque a informação deveria estar:

onde as pessoas precisavam dela para tomar decisões.

Imagine o Departamento Financeiro.

Antes, alguém poderia solicitar um relatório ao CPD.

Depois teria que esperar sua execução.

Com um PC e uma planilha, o gerente podia manipular informações imediatamente.

Isso era fantástico.

Mas havia um efeito colateral.

Antes:

USUÁRIO
   │
   ▼
SISTEMA CORPORATIVO
   │
   ▼
MAINFRAME

Agora:

USUÁRIO
   │
   ├── planilha
   ├── banco local
   ├── aplicativo comprado
   ├── programa feito pelo departamento
   └── arquivos locais

O poder computacional estava sendo democratizado.

E toda democratização tecnológica cria novas possibilidades — inclusive novas maneiras de fazer besteira.


👻 CAPÍTULO 3 — YUJI DESCOBRE O ANCESTRAL DO SHADOW IT

Um slime apareceu diante de Yuji.

Detectada aplicação crítica.

Yuji perguntou:

— Está no mainframe?

— Não.

— Servidor Unix?

— Não.

— Sistema oficial?

— Não.

— Quem desenvolveu?

O slime respondeu:

Carlos, do Financeiro.

— Carlos é programador?

Não.

— Documentação?

Não encontrada.

— Backup?

Talvez.

Yuji suspirou.

Bem-vindo ao ancestral do Shadow IT.

Shadow IT é tecnologia utilizada dentro de uma organização sem conhecimento, aprovação ou governança adequada da área responsável.

Hoje podemos imaginar:

  • SaaS contratado sem autorização;

  • armazenamento em cloud pessoal;

  • aplicações low-code;

  • ferramentas de IA;

  • bancos de dados externos;

  • APIs não autorizadas.

Nos anos 1990, poderia ser algo muito mais simples:

  • Access;

  • Excel;

  • Lotus 1-2-3;

  • dBase;

  • FoxPro;

  • Visual Basic;

  • programas shareware;

  • bancos de dados locais.

Uma planilha começava ajudando uma pessoa.

Depois ajudava cinco.

Depois cinquenta.

Até que alguém descobria:

“Sem aquela planilha não conseguimos fechar o mês.”

Acabamos de criar um sistema crítico sem Change Management, documentação ou governança.


🔎 CAPÍTULO 4 — NASCE A NECESSIDADE DE AUDITAR A MICROINFORMÁTICA

Quando existem dez computadores, talvez alguém saiba onde estão.

Quando existem dez mil, temos outro problema.

Auditoria de microinformática começou a ganhar enorme importância justamente porque empresas acumulavam grandes quantidades de equipamentos e software distribuídos.

O auditor precisava responder perguntas básicas.

Quantos computadores existem?

Onde estão?

Quem utiliza cada equipamento?

Qual configuração possuem?

Que software está instalado?

Existem licenças?

Existe antivírus?

Existe backup?

Quem possui privilégios administrativos?

Existem programas não autorizados?

Existem dados corporativos armazenados localmente?

Observe que a auditoria não estava procurando simplesmente "computadores".

Estava tentando descobrir riscos.

Imagine um PC contendo dados financeiros críticos.

Se o disco falhar amanhã, o que acontece?

Essa pergunta vale muito mais que saber a marca do computador.

🧙 CAPÍTULO 5 — O MAINFRAME ENCONTRA O UNIX

Enquanto PCs conquistavam as mesas, outro personagem ganhava espaço nos data centers:

Unix.

Unix tinha uma longa história acadêmica e empresarial e tornou-se extremamente importante em workstations e servidores.

Nos anos 1990, Unix frequentemente aparecia associado às arquiteturas RISC.

RISC significa:

Reduced Instruction Set Computer.

A filosofia RISC buscava trabalhar com conjuntos de instruções relativamente simples e eficientes, favorecendo determinadas estratégias de implementação e pipeline.

Entre as arquiteturas que se tornaram importantes estavam:

IBM POWER
Sun SPARC
HP PA-RISC
DEC Alpha
MIPS

Imagine nosso mundo de fantasia.

Vários reinos surgiram dizendo:

“Não precisamos daquele castelo gigantesco. Podemos construir fortalezas menores.”

Era o começo de uma mudança significativa na distribuição da capacidade computacional.

⚔️ CAPÍTULO 6 — MERCEDES-BENZ CONTRA FUSCA

Em determinado debate daquela época surgiu uma comparação maravilhosa.

Representantes do mundo mainframe compararam:

MAINFRAME = MERCEDES-BENZ
UNIX      = FUSCA

Segundo o argumento, ambos poderiam levar você ao destino.

Mas a Mercedes ofereceria mais:

  • conforto;

  • segurança;

  • confiabilidade;

  • qualidade dos componentes.

É uma metáfora interessante.

Mas existe um problema.

Yuji provavelmente perguntaria:

— Qual é a missão?

Porque não faz sentido discutir qual veículo é melhor sem perguntar para quê ele será usado.

Se você precisa transportar uma pessoa alguns quilômetros, talvez o veículo simples seja suficiente.

Agora imagine:

“Precisamos processar milhões de transações financeiras, continuamente, com controles rígidos e altíssima disponibilidade.”

A conversa muda.

Tecnologia empresarial deve ser analisada pelo workload.

Essa é uma palavra que você deve guardar.

Workload

É a carga de trabalho computacional que um sistema precisa executar.

Pode ser:

transações CICS
batch COBOL
consultas Db2
servidor Web
analytics
IA
processamento científico
mensageria
APIs

Portanto:

Não existe plataforma universalmente melhor. Existe plataforma mais adequada para determinado conjunto de requisitos.

💰 CAPÍTULO 7 — O SERVIDOR BARATO QUE FICOU CARO

Unix tinha uma vantagem comercial poderosa.

Servidores menores podiam custar significativamente menos que grandes sistemas centralizados.

Então alguém fazia a comparação:

MAINFRAME
US$ $$$$$$$$

UNIX
US$ $$$

Pronto.

Unix venceu?

Calma.

Yuji mandaria seus slimes procurar o restante da conta.

Porque preço de aquisição não é igual a custo total.

Surge então uma ideia fundamental:

TCO — Total Cost of Ownership

TCO significa custo total de propriedade.

Imagine um servidor custando:

US$ 20.000

Mas durante cinco anos você precisará pagar por:

administradores
energia
storage
backup
rede
licenciamento
monitoramento
suporte
patching
segurança
downtime
migrações

Agora multiplique isso por 100 servidores.

O servidor barato pode gerar uma infraestrutura cara.

Essa discussão dos anos 1990 reapareceria décadas depois com cloud.

🌐 CAPÍTULO 8 — CLIENTE-SERVIDOR MUDA A DUNGEON

Uma das grandes arquiteturas daquele período foi o modelo client/server.

Em vez de concentrar praticamente todo processamento no host, distribuímos responsabilidades.

Exemplo:

CLIENTE
   │
   │ solicitação
   ▼
SERVIDOR
   │
   ▼
BANCO DE DADOS

O cliente poderia cuidar da interface.

O servidor executaria regras ou serviços.

O banco armazenaria dados.

Isso possibilitava distribuir capacidade computacional.

Imagine uma aplicação COBOL tradicional:

3270
 │
 ▼
CICS
 │
 ├── COBOL
 │
 ▼
Db2

No mundo distribuído poderíamos encontrar:

Windows Client
      │
      ▼
Unix Server
      │
      ▼
Database

Mas cuidado.

Distribuir processamento também distribui complexidade.

Agora precisamos administrar:

rede
protocolos
clientes
servidores
versões
drivers
bancos
autenticação
compatibilidade

Toda camada adicionada resolve alguma coisa e potencialmente cria outra dungeon.

🔌 CAPÍTULO 9 — SISTEMAS ABERTOS E O PODER DOS PADRÕES

Chegamos a uma das ideias mais importantes daquela transformação:

sistemas abertos.

Um sistema aberto não significa necessariamente que absolutamente tudo nele seja open source.

A questão central está em utilizar interfaces, protocolos e padrões que facilitem interoperabilidade.

Imagine três fornecedores criando três equipamentos.

Sem padrões:

A ── protocolo A
B ── protocolo B
C ── protocolo C

Integrá-los é complicado.

Com padrões:

A ─┐
B ─┼── PADRÃO
C ─┘

Os produtos continuam diferentes.

Mas existe uma linguagem comum.

Pense na Internet.

Equipamentos completamente diferentes conseguem conversar usando protocolos padronizados.

Isso reduz dependência tecnológica e facilita integração.

🧩 CAPÍTULO 10 — PADRÃO NÃO MATA CRIATIVIDADE

Uma preocupação daquela época era:

“Se tudo for padronizado, produtos serão iguais?”

Não.

Um padrão normalmente determina como determinados componentes devem interagir, não como todo produto precisa ser construído.

Considere USB.

Fabricantes podem criar milhares de dispositivos diferentes.

O padrão define determinadas regras de comunicação.

O mesmo raciocínio aparece em:

TCP/IP
HTTP
SQL
POSIX
REST
JSON
Unicode

Padronização cria uma fronteira de interoperabilidade.

Dentro dessa fronteira ainda existe enorme espaço para inovação.

Em outras palavras:

o padrão define a porta; não determina como você deve decorar a casa.

🧬 CAPÍTULO 11 — O MAINFRAME COMEÇA A ABSORVER O MUNDO ABERTO

Aqui está uma ironia histórica maravilhosa.

Naquele período, sistemas abertos eram frequentemente apresentados como alternativa ao mainframe.

Mas o mainframe não ficou congelado.

Ele começou a incorporar tecnologias e interfaces associadas ao mundo aberto.

Décadas depois encontramos no ecossistema IBM Z:

COBOL
CICS
IMS
Db2
VSAM
JCL

convivendo com:

Unix
Java
Python
REST
JSON
Git
APIs
containers
Linux
DevOps
OpenShift

O resultado não foi simplesmente:

NOVO substitui VELHO

Foi frequentemente:

NOVO integra VELHO

Essa diferença é essencial para entender modernização de mainframe.

Modernizar não significa necessariamente jogar tudo fora.

🐉 CAPÍTULO 12 — O UNIX ESCONDIDO DENTRO DO MAINFRAME

Para um programador COBOL iniciante isso pode parecer estranho.

Mas o z/OS possui UNIX System Services — USS.

Isso significa que o ambiente z/OS incorpora um ambiente Unix compatível com padrões relevantes.

Podemos pensar conceitualmente em dois mundos convivendo:

        z/OS
 ┌───────────────────┐
 │ TSO / ISPF        │
 │ JCL               │
 │ COBOL             │
 │ CICS              │
 │ Db2               │
 │                   │
 │ UNIX System       │
 │ Services          │
 │ shell             │
 │ filesystem        │
 └───────────────────┘

Imagine explicar isso para alguém no meio da guerra comercial dos anos 1990:

“Um dia você poderá encontrar ferramentas Unix convivendo dentro do ambiente do mainframe IBM.”

Yuji provavelmente apenas responderia:

— Skill adquirida.

🧠 CAPÍTULO 13 — O HARDWARE FICOU BARATO; O HUMANO NÃO

Outra observação extremamente importante daquele debate dizia, aproximadamente:

O custo do programador aumentava enquanto o custo do hardware despencava.

Os percentuais específicos podem variar conforme período e metodologia, mas o princípio econômico é importante.

Nos primórdios:

CPU     = caríssima
memória = caríssima
disco   = caríssimo

Portanto programadores economizavam recursos obsessivamente.

Com a redução do preço do hardware, outra variável ganhou enorme importância:

produtividade humana.

Imagine economizar US$ 5.000 em hardware e criar uma arquitetura que exige mais US$ 200.000 em manutenção.

Você economizou?

Não.

Apenas deslocou o custo.

E aqui entram as linguagens de quarta geração.

🪄 CAPÍTULO 14 — AS 4GL PROMETEM MAGIA

As chamadas 4GL — Fourth Generation Languages buscavam aumentar produtividade.

A ideia geral era permitir que o desenvolvedor descrevesse mais e programasse menos detalhes.

Entre tecnologias associadas ao universo 4GL estavam ferramentas como:

Natural
FOCUS
Informix-4GL
Progress
Oracle Forms

O objetivo econômico era simples:

menos código
   ↓
menos esforço
   ↓
maior produtividade
   ↓
menor custo

Natural, por exemplo, tornou-se particularmente conhecido em grandes ambientes corporativos e frequentemente apareceu junto do banco Adabas.

Para um programador COBOL, a comparação é interessante.

COBOL tende a ser bastante explícito.

Uma ferramenta de nível mais alto pode abstrair detalhes.

Mas abstração não elimina complexidade.

Ela apenas a desloca.

Esse princípio continua válido em 2026 com:

low-code
no-code
frameworks
cloud services
IA generativa

Cada geração promete:

“Agora qualquer pessoa poderá desenvolver.”

E algum tempo depois aparece outra profissão dizendo:

“Precisamos governar tudo isso.”

💾 CAPÍTULO 15 — A GUERRA DOS DISCOS

Durante a discussão histórica aconteceu um momento quase digno de anime.

O representante da HP defendia a tecnologia Unix/RISC.

Surgiu então a questão de problemas relacionados a discos.

A resposta foi aproximadamente:

Tecnologia nova sempre possui problemas.

Então veio a IBM:

“Roupa suja se lava em casa.”

Critical hit.

A IBM defendia que investia enormes recursos em pesquisa e testes para garantir confiabilidade.

Por trás da provocação comercial existe uma discussão séria.

Quanto vale confiabilidade?

Imagine dois discos:

DISCO A = R$ 1.000
DISCO B = R$ 4.000

Qual é mais barato?

Você ainda não sabe.

Precisamos descobrir:

taxa de falha
performance
redundância
suporte
tempo de recuperação
impacto da indisponibilidade

Se a falha do disco A provoca uma interrupção de R$ 5 milhões, aquela economia inicial torna-se irrelevante.

Por isso, em sistemas críticos:

confiabilidade possui valor econômico.

⚙️ CAPÍTULO 16 — COBOL ENSINA UMA LIÇÃO SOBRE CUSTO

Imagine este programa:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. CLIENTE.

       PROCEDURE DIVISION.
           DISPLAY 'PROCESSANDO CLIENTE'.
           STOP RUN.

Compilar e executar esse programa é fácil.

Mas um sistema empresarial não é apenas seu código.

Ele depende de:

dados
segurança
JCL
bibliotecas
interfaces
procedimentos
monitoramento
documentação
operações
backup
recuperação

Essa é uma das razões pelas quais substituir aplicações legadas pode ser muito mais complicado do que alguém imagina.

O código talvez tenha 30 anos.

Mas durante esses 30 anos a empresa acumulou milhares de regras de negócio.

O programa não é simplesmente software velho.

Pode ser conhecimento empresarial executável.

☁️ CAPÍTULO 17 — VINTE ANOS DEPOIS, CLOUD REPETE A DISCUSSÃO

Troque algumas palavras:

1998                 2026

Mainframe            Data Center
Unix/RISC            Cloud
Client/server        Microservices
Servidor             Container
4GL                   Low-code/IA

E várias discussões retornam.

Alguém diz:

“Cloud é mais barata.”

Yuji pergunta:

— Para qual workload?

Outro diz:

“Microservices são melhores.”

— Para qual problema?

Outro:

“IA vai substituir todo desenvolvimento.”

Yuji olha para seus slimes.

— Requisitos?

Silêncio.

A grande lição é que tecnologia empresarial precisa ser analisada economicamente e tecnicamente.

📊 CAPÍTULO 18 — PASSO A PASSO PARA COMPARAR DUAS TECNOLOGIAS

Se amanhã alguém disser:

“Precisamos sair do mainframe porque X é mais barato.”

Não comece uma guerra religiosa.

Pegue café.

Abra uma planilha.

E siga os slimes de Yuji.

Passo 1 — Identifique o workload

Pergunte:

O que está sendo executado?

Batch?

CICS?

Db2?

Web?

Analytics?

Passo 2 — Meça volume

Quantas transações?

Quantos usuários?

Quanto armazenamento?

Qual crescimento anual?

Passo 3 — Determine SLA

Quanto tempo o sistema pode ficar indisponível?

1 hora?
10 minutos?
1 minuto?
praticamente nunca?

Passo 4 — Analise integração

Com quantos sistemas ele conversa?

Passo 5 — Analise segurança

Quem acessa?

Quais dados existem?

Há requisitos regulatórios?

Passo 6 — Calcule TCO

Não compare apenas hardware.

Inclua:

software
licenças
pessoas
infraestrutura
suporte
energia
migração
treinamento
backup
segurança
downtime

Passo 7 — Calcule risco de migração

Migrar também custa.

E falhar na migração custa ainda mais.

🔥 CAPÍTULO 19 — A GRANDE LIÇÃO PARA O PROGRAMADOR COBOL

Você provavelmente ouvirá muitas vezes:

“COBOL morreu.”

“Mainframe morreu.”

“Servidor morreu.”

“Data center morreu.”

“Programador morreu.”

Tecnologia adora anunciar funerais.

Curiosamente, vários cadáveres continuam processando folha de pagamento.

O programador COBOL não deveria defender mainframe simplesmente porque trabalha com mainframe.

Isso seria torcida.

O profissional deve compreender:

requisito
workload
custo
risco
SLA
arquitetura
integração

Se Unix resolver melhor determinado problema, use Unix.

Se cloud resolver melhor, use cloud.

Se IBM Z resolver melhor, use IBM Z.

A pergunta profissional não é:

“Qual tecnologia eu amo?”

É:

“Qual problema preciso resolver?”

🥚 EASTER EGG — INCIDENTE 03:17

Às 03:17 da madrugada, Yuji recebeu uma mensagem.

JOB ABEND

Ele abriu o log.

IEF450I
PAYROLL STEP01
ABEND=S0C7

Um slime perguntou:

— Devemos migrar para Unix?

Yuji respondeu:

— Não. Primeiro descubra quem colocou caracteres alfanuméricos naquele campo numérico.

O slime desapareceu.

Alguns minutos depois:

ROOT CAUSE FOUND.

Moral da história:

arquitetura moderna não corrige dado ruim.

🧭 CAPÍTULO 20 — A PREVISÃO MAIS IMPORTANTE DOS ANOS 1990

No final daquele debate surgiu uma conclusão:

Mainframe e Unix terão que conviver.

E talvez essa tenha sido a previsão mais lúcida de todas.

Porque o futuro não se tornou:

MAINFRAME
    X
   UNIX

VENCEDOR: ???

Tornou-se:

             INTERNET
                 │
               APIs
                 │
      ┌──────────┴──────────┐
      │                     │
    CLOUD                 IBM Z
      │                     │
containers              CICS
Linux                   COBOL
Java                    Db2
Python                  IMS
      │                     │
      └──────── EVENTOS ────┘

A palavra fundamental passou a ser:

INTEGRAÇÃO.

🧙‍♂️ EPÍLOGO — YUJI NÃO ESCOLHEU UM REINO

Ao terminar a auditoria, Yuji reuniu seus slimes.

Um encontrou mainframes.

Outro encontrou Unix.

Outro encontrou PCs.

Outro encontrou bancos de dados.

E aquele slime particularmente curioso voltou carregando:

FINANCEIRO_FINAL_DEFINITIVO_V7.XLS

Yuji olhou para ele.

— Isso é importante?

O slime respondeu:

Responsável pelo fechamento financeiro mensal da empresa.

— Backup?

Não.

— Documentação?

Não.

— Controle de acesso?

Não.

— Quem criou?

Funcionário aposentado em 1997.

Yuji ficou em silêncio.

Finalmente pronunciou:

— Esta é a aplicação mais perigosa que encontramos.

Não estava no mainframe.

Não estava no Unix.

Não custara milhões.

Provavelmente ninguém sequer sabia oficialmente que existia.

E essa talvez seja a maior lição desta dungeon.

A história da computação empresarial não é simplesmente uma sequência na qual tecnologias novas matam tecnologias antigas.

É uma história de redistribuição de responsabilidades.

O mainframe centralizou.

O PC descentralizou.

Unix distribuiu.

Cliente-servidor separou responsabilidades.

Sistemas abertos conectaram plataformas.

Padrões reduziram barreiras.

4GLs aumentaram produtividade.

Internet conectou organizações.

Cloud abstraiu infraestrutura.

Containers abstraíram ambientes.

IA começou a abstrair parte do trabalho intelectual.

Mas cada nova abstração também criou novos riscos.

Por isso aquela frase aparentemente simples dos anos 1990 continua extraordinariamente moderna:

Tecnologia não tem concorrência. Ela existe porque tem função.

Para o programador COBOL iniciante, eu acrescentaria uma segunda:

Nunca compare tecnologias pelo nome. Compare workloads, requisitos, riscos e custos.

E uma terceira, aprendida depois de décadas entrando em war rooms:

Se alguém disser que encontrou uma solução simples para substituir um sistema de 30 anos, pergunte primeiro se ele já encontrou todas as dependências.

Yuji levantou-se.

Os slimes começaram a abandonar a dungeon.

Um deles voltou correndo.

— Puru puru!

Nova skill detectada:

SHADOW_IT_DETECTION

Yuji observou a tela.

Havia agora uma aplicação chamada:

CONTROLE_CLIENTES_IA_FINAL_V3.xlsx

Ele suspirou.

Vinte e oito anos haviam passado.

A tecnologia mudara completamente.

O problema de auditoria continuava praticamente o mesmo.

☕ Bem-vindo ao Bellacosa Mainframe.

Aqui o COBOL pode ter décadas de idade, o Unix pode morar dentro do mainframe, o servidor barato pode custar uma fortuna e o arquivo mais perigoso da empresa talvez ainda esteja escondido debaixo da mesa de alguém.

E, se o incidente começar exatamente às 03:17, procure o slime.

Ele provavelmente já encontrou o log.

Publicada por à(s) Sem comentários:
Etiquetas: , , , , , , , , , ,
Subscrever: Mensagens (Atom)
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
☕ Um Café no Bellacosa Mainframe
Conhecimento legado preparando o futuro.
Conheça minha trajetória
Autor Contato Política de Privacidade Política de Cookies
GitHub LinkedIn
Inicializando conteúdo...