☕ 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 transformacao digital. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta transformacao digital. Mostrar todas as mensagens

domingo, 12 de julho de 2026

Capítulo 12 — O Legado dos Profetas e a Grande Lição para 2026

Bellacosa Mainframe e o legado dos profetas do apocalipse mainframe

☕ Um Café no Bellacosa Mainframe

Capítulo 12 — O Legado dos Profetas e a Grande Lição para 2026

O Mainframe Nunca Venceu a Guerra. Porque Ela Nunca Existiu.

Uma reflexão sobre quatro décadas de previsões, mostrando que a verdadeira evolução da computação ocorreu pela integração de tecnologias, e não pela substituição completa das anteriores.

Por

A evolução do IBM Mainframe até o IBM z17 simbolizando o legado da engenharia
A história do mainframe demonstra que inovação não significa destruir o passado, mas incorporar novas tecnologias preservando décadas de engenharia e conhecimento.

"A melhor previsão sobre tecnologia é construída observando décadas de engenharia, não meses de marketing."

— Bellacosa Mainframe

A guerra que nunca existiu

Durante décadas, parte da indústria apresentou a evolução tecnológica como uma sequência de substituições definitivas: mainframe versus Client/Server, servidores versus cloud, cloud versus edge, IA versus programação tradicional.

Na prática, a história mostrou que as plataformas bem-sucedidas coexistem, integram-se e evoluem continuamente para atender às necessidades do negócio.

O verdadeiro diferencial

A permanência do IBM Z decorre da combinação entre inovação constante e compatibilidade com décadas de aplicações críticas. Recursos modernos como Linux, OpenShift, APIs, DevOps, containers, automação e watsonx foram incorporados sem abandonar COBOL, CICS, Db2 e z/OS.

A grande lição para 2026

A computação corporativa não evolui por rupturas absolutas, mas pela capacidade de integrar novas ideias preservando segurança, disponibilidade, desempenho e regras de negócio construídas ao longo de muitas décadas.


Chegamos ao fim da jornada...

Ou talvez...

Ao começo de outra.

Durante este artigo viajamos quase quarenta anos pela História da Computação.

Visitamos redações.

Conferências.

Centros de pesquisa.

CPDs.

Datacenters.

Conhecemos jornalistas.

Analistas.

Consultores.

Professores.

Arquitetos.

E acompanhamos uma sequência impressionante de manchetes anunciando, repetidamente, o fim do IBM Mainframe.

Forbes.

New York Times.

InfoWorld.

Business Week.

Todas refletiam um momento específico da história.

Nenhuma delas foi escrita com má intenção.

Todas tentavam responder à mesma pergunta.

Como será a computação do futuro?

Essa continua sendo uma das perguntas mais difíceis da Engenharia.


Bellacosa Mainframe agradece ao professor Wolfgang Spruth

O maior personagem desta história

Curiosamente...

O protagonista deste artigo nunca foi a IBM.

Nem o COBOL.

Nem o CICS.

Nem o Db2.

Muito menos o z17.

O verdadeiro protagonista foi algo muito maior.

A evolução da Engenharia.

Porque, enquanto manchetes mudavam de direção a cada nova tendência...

A Engenharia seguia outro ritmo.

Mais lento.

Mais cuidadoso.

Mais pragmático.

Mais responsável.

Enquanto alguns prometiam revoluções anuais...

Os engenheiros pensavam em plataformas capazes de durar décadas.

E essa diferença explica praticamente toda esta história.


O professor que nos deixou um espelho

Se hoje podemos revisitar todas essas previsões, devemos isso ao Professor Wolfgang Spruth.

Seu trabalho The Death of the Mainframe não foi uma crítica à imprensa.

Foi um presente para as futuras gerações.

Spruth poderia simplesmente ter respondido aos artigos.

Não fez isso.

Preferiu arquivá-los.

Organizá-los.

Contextualizá-los.

Transformá-los em História.

Foi uma atitude tipicamente acadêmica.

Porque pesquisadores sabem que a memória também é uma forma de conhecimento.

Sem aquele pequeno conjunto de slides...

Grande parte dessas manchetes estaria perdida em arquivos esquecidos.

Graças a ele, hoje podemos estudá-las com calma, entender seu contexto e aprender com seus acertos e seus erros.


2026 é muito diferente de 1993

Imagine mostrar a um jornalista de 1993 um IBM z17.

Provavelmente ele perguntaria:

— Onde está o terminal verde?

Você responderia:

— Ainda existe.

Mas agora também existem:

  • APIs REST;

  • JSON;

  • OpenAPI;

  • Linux;

  • Containers;

  • Kubernetes;

  • OpenShift;

  • Git;

  • GitHub;

  • VS Code;

  • Python;

  • Java;

  • Node.js;

  • Go;

  • Zowe;

  • Ansible;

  • DevOps;

  • CI/CD;

  • watsonx;

  • Inteligência Artificial embarcada.

Talvez ele olhasse novamente para a máquina.

Depois perguntasse:

— Então isso ainda é um mainframe?

Você sorriria.

— Sim.

E talvez seja exatamente isso que torna essa plataforma tão fascinante.

Ela mudou completamente...

Sem deixar de ser ela mesma.


O COBOL também não ficou parado

Existe outra injustiça histórica.

Muitos imaginam COBOL como uma linguagem congelada em 1974.

Nada poderia estar mais distante da realidade.

O COBOL moderno conversa com:

JSON.

XML.

UTF-8.

APIs.

Serviços REST.

C.

Java.

Db2.

CICS.

MQ.

Git.

Pipelines DevOps.

Compiladores inteligentes.

Análise estática.

Testes automatizados.

Performance extremamente otimizada.

O COBOL não permaneceu vivo porque ficou parado.

Permaneceu vivo porque evoluiu.

Exatamente como qualquer tecnologia saudável deveria fazer.


O Db2, o CICS e o z/OS seguiram o mesmo caminho

O mesmo vale para todo o ecossistema IBM Z.

O Db2 evoluiu para um banco de dados altamente otimizado para cargas analíticas e transacionais.

O CICS transformou-se em uma plataforma moderna de serviços, APIs e integração.

O z/OS incorporou automação, segurança avançada, observabilidade, cloud híbrida e ferramentas abertas.

O BOB simplificou pipelines de build.

O Zowe aproximou novos desenvolvedores.

O Ansible levou automação moderna para o ambiente IBM Z.

O watsonx colocou Inteligência Artificial dentro da estratégia corporativa.

Nada disso existia quando aquelas manchetes foram escritas.


O maior erro continua acontecendo

Talvez a parte mais interessante desta história seja perceber que ela continua se repetindo.

Hoje o discurso mudou.

Não ouvimos mais:

"O Client/Server acabará com o Mainframe."

Agora ouvimos:

"A Inteligência Artificial acabará com os programadores."

Ou:

"LLMs substituirão arquitetos."

Ou:

"Ninguém mais precisará aprender linguagens de programação."

Será?

Talvez.

Talvez não.

Mas depois de estudar quarenta anos de História...

Aprendemos uma lição importante.

Desconfie sempre das previsões absolutas.

Principalmente quando elas envolvem palavras como:

"Nunca."

"Sempre."

"Definitivamente."

"Até 2030."

"A última."

A História da Computação costuma ser muito mais criativa do que qualquer cronograma.


O velho Jedi explica o segredo

Nosso Padawan encontra novamente o velho mestre.

Depois de toda essa jornada ele faz apenas uma pergunta.

— Mestre...

Qual foi o segredo do Mainframe?

O velho engenheiro permanece alguns segundos em silêncio.

Depois responde.

— O segredo nunca foi o hardware.

— Então foi o COBOL?

— Também não.

— O CICS?

— Não.

— O Db2?

— Ainda não.

— Então o que foi?

O mestre sorri.

Aponta para uma palavra escrita em um quadro branco.

Compatibilidade.

Depois escreve outra.

Evolução.

E mais uma.

Confiabilidade.

Por fim conclui.

— O Mainframe nunca obrigou seus clientes a jogar fora quarenta anos de investimento para aproveitar uma inovação.

Ele carregou o passado junto com o futuro.

Essa talvez tenha sido sua maior invenção.


A verdadeira Estrela da Morte

Como todo bom Bellacosa Mainframe...

Precisamos terminar com uma referência a Star Wars.

Durante anos o mercado enxergou o IBM Mainframe como se fosse a Estrela da Morte.

Gigante.

Antigo.

Centralizado.

Imponente.

Mas talvez a comparação correta seja outra.

O IBM Mainframe nunca foi a Estrela da Morte.

Ele sempre foi o Mestre Yoda.

Enquanto todos corriam atrás da próxima moda...

Ele permanecia em silêncio.

Aprendendo.

Evoluindo.

Adaptando-se.

Observando gerações inteiras de tecnologias nascerem.

Algumas brilharem intensamente.

Outras desaparecerem.

No final...

Ainda estava lá.

Mais experiente.

Mais moderno.

Mais forte.


Uma carta ao Padawan COBOL

Se você chegou até aqui...

Talvez esteja começando sua carreira.

Talvez já tenha décadas de experiência.

Não importa.

Existe uma única mensagem que gostaria que permanecesse com você.

Nunca estude uma tecnologia apenas porque ela está na moda.

Estude porque ela resolve um problema.

Nunca abandone uma tecnologia apenas porque alguém a chamou de "legado".

Descubra primeiro se ela continua gerando valor.

Nunca confunda marketing com arquitetura.

Nunca confunda novidade com inovação.

Nunca confunda interface bonita com engenharia sólida.

E, acima de tudo...

Nunca deixe de aprender.

Porque foi exatamente isso que permitiu ao IBM Mainframe atravessar mais de seis décadas.


A História escreveu seu próprio final

Em 1989 disseram que era um dinossauro.

Em 1991 marcaram a data de sua morte.

Em 1993 afirmaram que caminhava para a extinção.

Em 1994 começaram a perceber que talvez estivessem enganados.

Em 2026...

O IBM z17 executa Inteligência Artificial.

O watsonx auxilia empresas em escala global.

O COBOL continua movimentando trilhões de dólares.

O Db2 continua protegendo informações críticas.

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

O z/OS continua sendo referência em disponibilidade e segurança.

E milhares de novos Padawans continuam aprendendo essa plataforma extraordinária.

A História foi generosa.

Ela não humilhou quem errou.

Apenas mostrou que prever o futuro é muito mais difícil do que construir um bom sistema.


Epílogo

Quando terminar este café...

Feche o navegador.

Abra seu editor.

Entre no TSO.

Compile um programa COBOL.

Execute um JCL.

Faça um SELECT no Db2.

Chame uma transação CICS.

Observe tudo funcionando.

Então lembre-se de uma frase.

O Mainframe nunca sobreviveu porque resistiu ao futuro.

Ele sobreviveu porque aprendeu a evoluir junto com ele.

Essa talvez seja a maior lição deixada por Wolfgang Spruth.

E certamente é a maior herança que podemos transmitir para a próxima geração de Programadores COBOL Padawans.

Que a Engenharia esteja com você.

Sempre.

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.

sexta-feira, 5 de junho de 2026

☕💣 OPERADOR, TEM ALGUÉM NO TERMINAL! — O Dia em Que um Assistente de IA Pediu Acesso ao Seu Mainframe

 

Bellacosa Mainframe e o assistente de IA LLM RAG

☕💣 OPERADOR, TEM ALGUÉM NO TERMINAL! — O Dia em Que um Assistente de IA Pediu Acesso ao Seu Mainframe

"Primeiro ele responde perguntas. Depois organiza tarefas. Em seguida consulta sistemas. Quando você percebe, existe uma inteligência trabalhando ao seu lado 24 horas por dia."


🚀 Afinal, o que é um Assistente de IA?

Imagine um operador de computador que:

✅ Nunca dorme
✅ Nunca tira férias
✅ Nunca esquece um procedimento
✅ Aprende com documentação
✅ Conversa em linguagem natural

Um Assistente de Inteligência Artificial é um software capaz de compreender perguntas, interpretar contexto, acessar informações e executar tarefas para auxiliar pessoas em suas atividades.

Diferente de um chatbot tradicional, que segue roteiros pré-definidos, um assistente moderno utiliza modelos de linguagem (LLMs) para raciocinar sobre problemas e gerar respostas dinâmicas.

Na prática, ele pode:

  • Responder dúvidas técnicas

  • Gerar código

  • Criar documentos

  • Automatizar processos

  • Consultar bancos de dados

  • Executar fluxos de negócio

  • Integrar sistemas corporativos

  • Apoiar decisões operacionais

Pense nele como uma mistura de:

  • Analista de Sistemas

  • Operador

  • DBA

  • Documentador

  • Programador

  • Professor

Tudo em uma única interface.


🏛️ O Assistente de IA no Mundo Mainframe

Imagine um assistente treinado com:

  • JCL

  • COBOL

  • CICS

  • DB2

  • IMS

  • RACF

  • TSO/ISPF

  • JES2

  • z/OS

Você poderia perguntar:

"Por que este JOB deu ABEND S0C7?"

ou

"Monte um JCL para copiar um VSAM KSDS."

ou

"Explique a diferença entre EXEC CICS LINK e XCTL."

Em segundos ele produziria:

  • Explicações

  • Diagnósticos

  • Exemplos

  • Sugestões de correção

É como ter um especialista Bellacosa Mainframe disponível 24x7.


🔧 Como Construir um Assistente de IA?

Hoje existem vários caminhos.

Caminho 1 — O Mais Simples

Utilizar plataformas prontas:

  • GPTs personalizados

  • Assistants

  • Copilots

  • No-Code AI Builders

Você fornece:

  • Documentação

  • PDFs

  • Manuais

  • Procedimentos

E o assistente aprende aquele contexto.

Ideal para:

  • Empresas

  • Equipes de suporte

  • Times de treinamento


Caminho 2 — Assistente com Base de Conhecimento

Arquitetura típica:

Usuário
   │
   ▼
Assistente IA
   │
   ▼
Base de Conhecimento
   │
   ├── PDFs
   ├── Manuais
   ├── Wikis
   ├── Procedimentos
   └── Documentação Técnica

O modelo consulta documentos antes de responder.

Chamamos isso de:

RAG (Retrieval Augmented Generation)

É uma das arquiteturas mais populares atualmente.


Caminho 3 — Assistente Corporativo

Aqui a brincadeira fica séria.

Usuário
   │
   ▼
Assistente IA
   │
   ├── SAP
   ├── Mainframe
   ├── Banco de Dados
   ├── ServiceNow
   ├── Jira
   ├── APIs
   └── Sistemas Legados

O assistente deixa de apenas responder.

Ele passa a:

  • Consultar sistemas

  • Abrir chamados

  • Executar processos

  • Atualizar registros

Estamos entrando no território dos Agentes de IA.


🎯 O Que Eu Ganho Construindo Um?

Muito mais do que parece.

1. Produtividade

Tarefas que demoravam horas passam a levar minutos.


2. Documentação Viva

Em vez de procurar em centenas de PDFs:

CTRL+F
CTRL+F
CTRL+F
CTRL+F

Você simplesmente pergunta.


3. Treinamento Acelerado

Novatos aprendem mais rápido.

Um júnior pode consultar o assistente constantemente.


4. Preservação do Conhecimento

Quando especialistas se aposentam, muito conhecimento desaparece.

O assistente pode ajudar a preservar:

  • Procedimentos

  • Boas práticas

  • Lições aprendidas


5. Disponibilidade 24x7

Não importa:

  • Madrugada

  • Feriado

  • Final de semana

O assistente continua disponível.


⚠️ As Desvantagens

Nem tudo é magia.

Alucinações

O maior problema atual.

A IA pode responder com enorme confiança algo completamente errado.

Exemplo:

"Qual parâmetro resolve esse ABEND?"

Ela pode inventar uma solução inexistente.


Dependência Excessiva

Algumas pessoas param de pensar.

Começam a copiar respostas sem validar.

Isso é extremamente perigoso.


Custo

Modelos avançados podem gerar custos relevantes.

Especialmente em grandes empresas.


Segurança

Documentos enviados para modelos externos podem conter:

  • Dados sensíveis

  • Segredos corporativos

  • Informações confidenciais

Governança é obrigatória.


☠️ Os Caminhos Tenebrosos

Agora entramos na sala escura do datacenter.

Luzes piscando.

Ar-condicionado rugindo.

Alarmes ao fundo.


Caminho Tenebroso #1

Confiar Cegamente na IA

A IA não é uma autoridade.

Ela é uma ferramenta.

Quem assina a decisão continua sendo o humano.


Caminho Tenebroso #2

Alimentar a IA com Dados Incorretos

Existe uma regra antiga:

Garbage In
Garbage Out

Se o treinamento estiver errado:

As respostas estarão erradas.


Caminho Tenebroso #3

Expor Informações Sigilosas

Jamais envie para modelos públicos:

  • Senhas

  • Chaves de API

  • Dumps confidenciais

  • Dados de clientes

Uma única falha pode gerar consequências enormes.


Caminho Tenebroso #4

Automatizar Sem Controle

Um assistente que apenas responde é uma coisa.

Um assistente que executa comandos é outra completamente diferente.

Imagine:

DELETE PRODUCAO

executado automaticamente.

Nem preciso explicar o restante da história...


Caminho Tenebroso #5

Substituir Conhecimento Humano

O objetivo não é eliminar especialistas.

É amplificar sua capacidade.

O melhor cenário é:

Humano + IA

e não

Humano OU IA

🎓 O Futuro

Estamos caminhando para uma era onde cada profissional terá seu próprio assistente especializado.

Um desenvolvedor terá um assistente de programação.

Um médico terá um assistente clínico.

Um advogado terá um assistente jurídico.

E um profissional de Mainframe poderá ter algo como:

"Bellacosa Mainframe Assistant"

Capaz de explicar:

  • JES2

  • RACF

  • CICS

  • DB2

  • COBOL

  • JCL

  • z/OS

com exemplos, laboratórios e diagnósticos.


☕💣 Conclusão Bellacosa Mainframe

O assistente de IA não é o fim do operador.

Não é o fim do programador.

Não é o fim do analista.

Ele é uma nova camada de abstração, assim como:

  • Assembly evoluiu para COBOL

  • Cartões perfurados evoluíram para terminais

  • Terminais evoluíram para interfaces gráficas

  • Interfaces evoluíram para a Web

Agora estamos entrando na era da conversa.

A pergunta não é mais:

"Como faço isso?"

Mas sim:

"Como explico para a IA o que eu preciso?"

Quem dominar essa habilidade terá uma vantagem semelhante à de quem aprendeu internet nos anos 90 ou computação em nuvem nos anos 2000.

Porque, no fim das contas, o maior poder da IA não está em responder perguntas.

Está em transformar conhecimento em ação.

E isso, meu amigo operador, é algo que merece um café forte antes do próximo IPL. ☕🚀💣


quinta-feira, 4 de junho de 2026

A DÍVIDA TÉCNICA QUASE PAROU OS BANCOS — A COVID APERTOU ENTER E O SISTEMA REVELOU 40 ANOS DE PROBLEMAS ESCONDIDOS

 

Bellacosa Mainframe e o covid expondo problemas da divida tecnica

☕💣📋 A DÍVIDA TÉCNICA QUASE PAROU OS BANCOS — A COVID APERTOU ENTER E O SISTEMA REVELOU 40 ANOS DE PROBLEMAS ESCONDIDOS


O DIA EM QUE UM PROGRAMADOR COBOL JÚNIOR DESCOBRIU QUE O MAIOR BUG DO BANCO NÃO ESTAVA NO CÓDIGO

Imagine a seguinte situação.

Você acabou de entrar em um grande banco.

Recebe seu primeiro programa COBOL para manutenção.

Abre o membro no ISPF.

O programa possui:

  • 28.000 linhas

  • 134 COPYBOOKS

  • 742 parágrafos

  • Comentários da época do Plano Real

  • Um PERFORM THRU que ninguém entende

  • Um campo chamado WK-AREA1

  • Outro chamado WK-AREA2

  • Outro chamado WK-AREA3

E você pensa:

"Quem foi o maluco que escreveu isso?"

Então um analista veterano olha para você e responde:

— Eu.

E completa:

— Em 1998 aquilo era considerado moderno.

Nesse momento você acabou de conhecer um dos conceitos mais importantes da engenharia de software:

Dívida Técnica


O QUE É DÍVIDA TÉCNICA?

A melhor definição é simples.

Dívida técnica é quando uma decisão que economiza tempo hoje gera custos maiores amanhã.

Funciona exatamente como um empréstimo bancário.

Você pega dinheiro hoje.

Mas depois paga:

  • principal

  • juros

  • correção

  • multas

No software acontece a mesma coisa.

Você ganha velocidade agora.

Mas perde produtividade no futuro.


EXEMPLO COBOL CLÁSSICO

Imagine que em 1998 alguém criou:

IF AGENCIA = 1234
   MOVE 'SANTOS' TO CIDADE
END-IF

Parecia inofensivo.

Hoje existem:

  • 3.000 agências

  • dezenas de fusões

  • múltiplas marcas

Agora o código virou:

IF AGENCIA = 1234
...
ELSE IF AGENCIA = 2345
...
ELSE IF AGENCIA = 3456
...

O que era uma solução virou um problema.


COMO A DÍVIDA TÉCNICA NASCE?

Normalmente através de frases famosas.

Frase 1

"Depois a gente melhora."

Mentira.

Ninguém melhora.


Frase 2

"É só uma correção rápida."

Nunca é.


Frase 3

"O projeto fecha sexta-feira."

A dívida nasce quinta.


Frase 4

"Não mexe porque funciona."

O terror dos bancos.


OS TIPOS DE DÍVIDA TÉCNICA

1. Código

Programas difíceis de entender.

Exemplos:

  • GOTO excessivo

  • PERFORM THRU gigantes

  • variáveis sem significado

  • duplicação


2. Arquitetura

Problemas maiores.

Exemplos:

  • sistemas monolíticos

  • dependências excessivas

  • integrações frágeis


3. Dados

Muito comum em bancos.

Exemplos:

  • arquivos VSAM redundantes

  • tabelas DB2 duplicadas

  • dados inconsistentes


4. Processos

Pouco discutida.

Mas extremamente perigosa.

Exemplos:

  • deploy manual

  • testes manuais

  • documentação inexistente


COMO IDENTIFICAR DÍVIDA TÉCNICA?

Um júnior costuma perguntar:

"Como sei que existe dívida?"

Observe sintomas.


Sintoma 1

Mudanças simples levam semanas.


Sintoma 2

Toda alteração gera incidente.


Sintoma 3

Poucas pessoas entendem o sistema.


Sintoma 4

Ninguém quer mexer.


Sintoma 5

A frase mais perigosa:

"Esse programa é do fulano."

Quando o sistema tem dono humano, existe dívida.


MÉTRICAS IMPORTANTES

Agora entramos em uma área que diferencia profissionais comuns de profissionais de elite.

Você não gerencia aquilo que não mede.


1. COMPLEXIDADE CICLOMÁTICA

Criada por Thomas McCabe.

Mede quantos caminhos lógicos existem.

Exemplo:

IF A
   ...
ELSE
   ...
END-IF

Complexidade = 2

Agora imagine 300 IFs.

O número explode.

Quanto maior:

  • mais difícil testar

  • mais difícil manter

  • maior risco

Meta saudável:

  • abaixo de 10 excelente

  • até 20 aceitável

  • acima de 30 perigoso


2. LINHAS DE CÓDIGO

LOC (Lines of Code)

Não mede qualidade.

Mas mede tamanho.

Programa COBOL:

  • 500 linhas → simples

  • 5.000 linhas → atenção

  • 20.000 linhas → investigação


3. DUPLICAÇÃO DE CÓDIGO

Quanto código está repetido?

Exemplo:

Mesma regra de cálculo em:

  • cadastro

  • empréstimo

  • cartão

  • investimentos

Quando muda uma regra:

quatro programas precisam mudar.


4. COBERTURA DE TESTES

Quanto do sistema é validado?

Métrica:

Cobertura = código testado / código total

Quanto maior, melhor.


5. TEMPO MÉDIO DE CORREÇÃO

MTTR

Mean Time To Repair.

Quanto tempo leva para corrigir problemas.

Quanto menor:

melhor maturidade.


6. DEFEITOS POR RELEASE

Muito utilizada em bancos.

Pergunta simples:

Quantos incidentes surgem após implantação?


FERRAMENTAS QUE AJUDAM

Vamos ao arsenal.


IBM APPLICATION DISCOVERY

Conhecida como AD.

Excelente para:

  • dependências

  • impacto

  • análise de código

Mostra relacionamentos invisíveis.


IBM APPLICATION DELIVERY FOUNDATION

Ajuda em:

  • DevOps

  • testes

  • integração


SONARQUBE

Uma das mais famosas.

Analisa:

  • complexidade

  • duplicação

  • vulnerabilidades

Possui suporte para COBOL.


TOPAZ

Muito utilizada em ambientes Compuware/BMC.

Excelente para:

  • visualização

  • debugging

  • análise


ENDEVOR

Ajuda no controle de versões.

Embora não seja ferramenta de dívida técnica, ajuda a evitar que ela cresça.


GIT

Sim.

Programadores COBOL modernos usam Git.

O mundo mudou.


COMO REDUZIR DÍVIDA TÉCNICA?

Agora chegamos à parte prática.


PASSO 1

MAPEAR

Nunca saia corrigindo.

Primeiro descubra:

  • onde está

  • quanto existe

  • qual impacto


PASSO 2

CLASSIFICAR

Separe em:

Alta prioridade

Afeta negócio.

Média prioridade

Afeta produtividade.

Baixa prioridade

Apenas estética.


PASSO 3

ATACAR O TOPO

Use a regra 80/20.

Normalmente:

20% dos programas geram 80% dos problemas.

Comece por eles.


PASSO 4

REFATORAR

Refatorar significa:

melhorar sem alterar comportamento.

Exemplo:

Antes

MOVE 'S' TO WS-FLAG1

Depois

MOVE 'S' TO WS-CLIENTE-ATIVO

Mesmo resultado.

Melhor compreensão.


PASSO 5

REMOVER DUPLICAÇÃO

Regra de ouro.

Se existe em cinco lugares.

Transforme em um.


PASSO 6

DOCUMENTAR

A documentação mais barata é aquela escrita hoje.

A mais cara é aquela que será escrita daqui cinco anos.


PASSO 7

CRIAR APIs

Aqui entra a modernização.

Não destrua o COBOL.

Encapsule.

Exemplo:

Mobile
   |
API
   |
CICS
   |
COBOL
   |
DB2

O COBOL continua funcionando.

Mas agora conversa com o mundo moderno.


O PAPEL DA CLOUD

Muitos profissionais acreditam:

"Cloud substitui Mainframe."

Não.

A realidade é:

Cloud complementa Mainframe.

O mercado está migrando para:

Mainframe + APIs + Cloud + IA

Não:

Mainframe versus Cloud

EASTER EGG DA INDÚSTRIA

Você sabia?

Grande parte dos sistemas bancários mais críticos do planeta possui código executando há décadas.

Alguns módulos possuem mais idade que muitos programadores que fazem manutenção neles.


CURIOSIDADE

Em muitos bancos existem programas COBOL executados diariamente há mais de 30 anos sem interrupção significativa.

Pouquíssimas tecnologias no mundo podem afirmar isso.


A REGRA DOS ESCOTEIROS

Uma das melhores técnicas contra dívida técnica.

Conhecida como:

Boy Scout Rule

"Deixe o código mais limpo do que encontrou."

Você corrige um bug.

Aproveite para:

  • melhorar nomes

  • remover comentários obsoletos

  • eliminar duplicações

Pequenas melhorias acumulam enormes resultados.


O ERRO QUE TODO JÚNIOR COMETE

Querer reescrever tudo.

Não faça isso.

Sistemas bancários existem para:

  • processar pagamentos

  • movimentar bilhões

  • atender clientes

Não para serem bonitos.

Primeiro entenda.

Depois melhore.

Por último modernize.


O CAMINHO DE EVOLUÇÃO PROFISSIONAL

Júnior:

"Como funciona?"

Pleno:

"Como melhorar?"

Sênior:

"Como evitar que o problema volte?"

Arquiteto:

"Como impedir que o problema exista?"


☕🦠💣 QUANDO A COVID FEZ O IPL DO PLANETA E REVELOU TODOS OS ABENDS ESCONDIDOS DOS BANCOS

Até 2020 muitos bancos acreditavam que estavam preparados para o futuro.

Possuíam:

  • Internet Banking

  • Aplicativos móveis

  • Chatbots

  • APIs

  • Transformação Digital nos PowerPoints

Então chegou a COVID.

E a realidade apareceu.


O TESTE DE STRESS QUE NINGUÉM PLANEJOU

Durante décadas os bancos planejavam crescimento gradual.

De repente aconteceu:

Milhões de clientes
tentando acessar
os sistemas ao mesmo tempo

O equivalente em mainframe seria:

100.000 jobs
entrando na fila
simultaneamente

O QUEBROU?

Curiosamente, muitas vezes não foi o COBOL.

Nem o CICS.

Nem o DB2.

Foi a camada moderna.

Por exemplo:

  • Portais Web

  • Gateways API

  • Aplicativos móveis

  • Centrais de atendimento

Os sistemas core continuavam funcionando.

Mas os canais de acesso colapsaram.


O DIA EM QUE O BANCO DESCOBRIU SUA DÍVIDA TÉCNICA

Muitas instituições descobriram:

  • Processos manuais escondidos

  • Dependência excessiva de funcionários específicos

  • Sistemas sem escalabilidade

  • Arquiteturas ultrapassadas

A pandemia funcionou como um scanner de vulnerabilidades em escala mundial.


☁️ A NUVEM NÃO É UMA MÁQUINA. É UMA ESTRATÉGIA.

Um dos maiores erros dos iniciantes é pensar:

Cloud = Servidor em outro lugar

Não.

Cloud é uma mudança de modelo operacional.


O QUE A NUVEM OFERECE?

Imagine que amanhã o banco precise processar:

10 vezes mais transações

No modelo tradicional:

  • Comprar servidores

  • Instalar servidores

  • Configurar servidores

Meses de trabalho.


NA NUVEM

Precisa de mais capacidade?

Adiciona.

Precisa de menos?

Remove.


A NUVEM REDUZ DÍVIDA TÉCNICA?

Resposta curta:

Não.


RESPOSTA LONGA

A nuvem não elimina dívida técnica.

Mas torna muito mais fácil combatê-la.

Exemplo:

Antes:

Sistema monolítico
30.000 programas

Depois:

Microserviços
APIs
Containers

Agora você consegue modernizar partes isoladas.


O PADRÃO QUE ESTÁ DOMINANDO OS BANCOS

O mercado financeiro está migrando para:

Cloud
    |
APIs
    |
Mainframe
    |
DB2

Não:

Cloud substituindo Mainframe

Mas:

Cloud consumindo Mainframe

Essa diferença é gigantesca.


O STRANGLER PATTERN

Um dos segredos da modernização bancária.

Ao invés de destruir:

Sistema COBOL

Você faz:

Nova API

Depois:

Novo serviço

Depois:

Novo canal digital

E o legado vai sendo cercado gradualmente.


👨‍💼 O PROBLEMA QUE NINGUÉM GOSTA DE DISCUTIR: RH

A parte mais interessante da entrevista da IBM talvez seja esta:

A maior dívida técnica não é financeira.

É humana.


O PROGRAMA COBOL QUE APOSENTOU O FUNCIONÁRIO

Imagine:

Programa:

PAGBOL01

Criado em:

1994

Quem entende?

Uma pessoa.


O DIA DO DESASTRE

Essa pessoa:

  • aposenta

  • muda de empresa

  • entra em férias

Pronto.

Agora existe um risco operacional.


O FATOR ÔNIBUS

Métrica famosa.

Pergunta:

Quantas pessoas precisam desaparecer para que o projeto pare?

Se a resposta for:

1

Você possui um problema grave.


O QUE OS JOVENS DESENVOLVEDORES PROCURAM?

A nova geração busca:

  • Git

  • APIs

  • DevOps

  • Cloud

  • Automação

  • CI/CD

Não necessariamente porque são modismos.

Mas porque aumentam produtividade.


O ERRO DOS GESTORES

Muitos acreditam:

"Os jovens não querem aprender COBOL."

Errado.

O que eles não querem é:

Trabalhar em caos.

Existe uma enorme diferença.


UM COBOL MODERNO É ATRAENTE

Imagine um ambiente com:

  • Git

  • VS Code

  • Zowe

  • APIs REST

  • Jenkins

  • SonarQube

E atrás disso:

COBOL
CICS
DB2

O profissional moderno trabalha feliz.


UM COBOL ANTIGO É REPELENTE

Agora imagine:

  • documentação inexistente

  • deploy manual

  • FTP

  • planilhas Excel

  • mudanças sem controle

O problema não é COBOL.

É a cultura.


O CUSTO INVISÍVEL DA DÍVIDA TÉCNICA

Os gestores normalmente medem:

  • hardware

  • software

  • licenças

Mas esquecem:

  • turnover

  • treinamento

  • conhecimento perdido

Esses custos podem superar os custos tecnológicos.


O CICLO VICIOSO

A dívida técnica cria:

Sistema ruim
      ↓
Pouca produtividade
      ↓
Mais pressão
      ↓
Mais atalhos
      ↓
Mais dívida técnica
      ↓
Mais pessoas saem
      ↓
Menos conhecimento
      ↓
Mais dívida técnica

É um círculo destrutivo.


O CICLO VIRTUOSO

A modernização cria:

Melhor arquitetura
       ↓
Mais produtividade
       ↓
Menos incidentes
       ↓
Mais inovação
       ↓
Mais satisfação
       ↓
Melhor retenção
       ↓
Mais conhecimento
       ↓
Menos dívida técnica

A GRANDE LIÇÃO PARA O PROGRAMADOR COBOL JÚNIOR

Quando você ouvir a expressão:

"Precisamos migrar para a nuvem."

Não pense em servidores.

Pense em:

  • agilidade

  • automação

  • integração

  • APIs

  • escalabilidade

  • experiência do desenvolvedor

Quando ouvir:

"Precisamos reduzir dívida técnica."

Não pense apenas em código.

Pense em:

  • pessoas

  • conhecimento

  • processos

  • documentação

  • cultura

E quando ouvir:

"Precisamos modernizar o mainframe."

Lembre-se:

Os maiores bancos do mundo não estão abandonando COBOL.

Eles estão cercando COBOL com tecnologias modernas para que ele continue entregando valor pelos próximos 30 anos.


CONCLUSÃO

A maior lição sobre dívida técnica é surpreendente.

O problema raramente é COBOL.

O problema quase sempre é falta de gestão.

Um programa COBOL de 1985 pode ser extremamente moderno se possuir:

  • documentação

  • testes

  • APIs

  • observabilidade

  • versionamento

  • arquitetura bem definida

Da mesma forma, uma aplicação criada ontem pode nascer cheia de dívida técnica.

Lembre-se sempre:

Dívida técnica não é idade.

Dívida técnica é descuido acumulado.

E existe uma enorme diferença entre um sistema antigo e um sistema mal cuidado.

O programador COBOL que entender essa diferença deixa de ser apenas um mantenedor de código legado e passa a ser um verdadeiro engenheiro responsável por preservar, modernizar e evoluir alguns dos sistemas mais importantes do planeta.


quarta-feira, 30 de julho de 2025

Época de mudanças no Mainframe e a possível derrocada da BIG BLUE. Será?

 

Bellacosa Mainframe e as mudanças no Mundo Mainframe

Época de mudanças no Mainframe e a possível derrocada da BIG BLUE. Será?

4,424 followers


  • #Informática Básica
  • #Arquitetura de Sistemas
  • #Soft Skill

114 Anos da IBM!!! Hip Hip Hurra

Derrocada da IBM, quando executivos erram.

Uma historia cheia de idas e vindas

Salve jovem padawan, graças a positiva repercussão do artigo sobre Cobol, resolvi ir um pouco mais além e falar despretensiosamente sobre tendências e estratégias, que nos simples desenvolvedores devemos saber e aprender ao longo da carreira, lembrando que esta nao é um visão executiva afinal somos pequenos programadores a mercê do mercado, vivendo do salário e dependemos dos projetos.

Article content

Existe risco ao adotarmos uma tecnologia, um simples erro em nossa escolha na área de tecnologia, poderá significar o fracasso de nossas vidas profissionais e empregabilidade futura, como exemplo vide a quantidade de ex-programadores das dezenas de LPs que nao sobreviveram a prova TEMPO e hoje estão atuando em outras áreas profissionais.

Meu testemunho é um exemplo destas escolhas e caminhos, minha carreira de DEV (programador até pouco tempo atrás), iniciou-se no século passado, época que o Mainframe dominava o mundo dos computadores, a IBM era a empregadora dos sonhos, dona de uma carreira desafiadora, o estado da arte em IT, produzindo obras de arte em softwares e dominando a imprensa, conquistando corações. Todo jedi de cabecinha branca de hoje, com certeza um dia sonhou em ter um crachá da Big Blue e fazer parte da equipe Harlem Globetrotters dos computadores..

Article content

Naquela época todo Analista PROGRAMADOR aspirava trabalhar em um dos grandes laboratórios informáticos da IBM, ou melhor C.P.D. com maquinas fabulosas saídas de um cenário de filme HI, até hoje ainda sonho com unidade leitoras de fita magnética e robots manipulando cartridges para inicializar unidades de disco, e os leds acendendo e apagando em maquinas e seus terminais 3270 conectados por modens trocando dados.

Saiba que o modulo Drácula, muito em voga atualmente, nada mais é que um retorno às origens, uma singela homenagem das novas gerações as telas negras dos terminais com suas 24 linhas com 80 colunas de texto caps lock em fosforo verde.

Falando sobre o porquê da DERROCADA do Mainframe.

Article content

O prego no caixão do Mainfame/Cobol foi a mania do bug do milênio, onde milhares de empresas gastaram a rodo, sacos e mais sacos de recursos financeiros e humanos, para “consertar” o Bug Y2k, um problema originado nos anos 70 e perpetuados ao longo de décadas por programadores preguiçosos e usuários zelosos, nao sei se era, mas o consenso geral acreditava que 2 bytes a mais era muito dispendioso.

So sei que isso acabou enriquecendo consultorias inescrupulosas que jogavam mais e mais querosene no incêndio, com artigos catastróficos, assustadores e altamente criativos, criados para criar gerar  pânico nos stakeholders, originando um estouro de manada generalizado, que obrigava a necessidade de ações rápidas e impensadas.

Article content

Vendo com olhos experiente, essa mania acabou causando grandes danos à imagem dos Computadores e analistas programadores, derrubando a credibilidade e confiança do mercado em computação e softwares legados. Verdade seja dita, o preço foi pago com as centenas de diretores de informática mandados a guilhotina nos anos seguintes.

Mas isso não foi o pai de todos os males, a tempestade perfeita estava se formando no horizonte, para ajudar esse período confuso, ainda tivemos o colapsos no Sistema Financeiro Mundial, iniciados pela crise financeira de 2001, que apôs a derrocada do World Trade Center, adicionaram um pouco de caos, ao processo em curso do estouro da bolha das DotCom, empresas de internet, que prometiam lucros pornográficos, mas não tinham pé nem cabeça.

Para concluir o cenário de caos apocalíptico, fomos vítimas da crise do subprime de 2008 em que erros de Acadêmicos de prestigiosas Universidade em suas teorias de portfólio, aliada a gestores gananciosos e suas carteiras de investimentos com fraudes em processos estocásticos, definitivamente concluíram um ciclo econômico com a destruição dos mercados financeiros mundiais.

Article content

Estes eventos aleatórios que enterraram centenas de grandes empresas e conjuntamente a turbulência gerada no mercado laboral, foram responsáveis pela destruição dos postos de trabalhos, gerando desemprego a milhões de trabalhadores de do setor financeiro e da informática, no caso do IT pessoas altamente especializadas em Mainframe, que de um momento para outro, se viram sem chão.

Agora pare um pouco e pense nessas pessoas, muitos delas estando próximo da aposentadoria e acostumados a ter um padrão confortável de vida, que inesperadamente foram jogados para o desemprego e devido aos elevados salários recebidos na época áurea, tiveram grande dificuldade em se realocar e retornarem ao mercado laborativo, principalmente pela queda abrupta em novos projetos e falência de inúmeras pequenas softhouses, que empregavam terceirizados, quarteirizados e afins.

Um dia gostaria de ler um estudo ou artigo acadêmico que contabilizasse os milhões de linhas de código, que foram parar no fundo da lata de lixo da história empresarial, pensar em bom código que nunca chegaram ao potencial previsto, produtos únicos e inovadores, que não tiveram a chance de debutar e gerarem riquezas.

Migração dos sistemas legados.

Article content

Os gestores de IT estão desesperados com o rumo do mercado, com cortes frequentes de orçamento, com a perda de prestigio e diminuição do mercado, bem que tentaram reinventar a Roda, criando monstros informáticos e em consequência desta anomalia, acabaram destruindo ainda mais empregos, prova disso, basta perguntarmos aos inúmeros jedi renegados, que foram dispersados após o final da Guerra Subprime.

Neste turbulento momento histórico, com inúmeros jedi dispersados pelo mercado, coletaremos inúmeras histórias tragicômicas sobre migração de sistemas legados, erps vistosos mas incompletos e com aquisição de packages de software para migração que falharam catastroficamente, uma das mais recentes tragédias foi o TSB Bank com 300 milhões de libras esterlinas em multas e menos 80.000 clientes.

Por mais que as novas tecnologias e as linguagens de programação moderna atendam a parte de front-end, criando maravilhas do design UI e UX, o back-end continua a ser o lugar onde a magia realmente acontece, todas as regras do negócio e seus meandros, a inteligência de processos, a máquina de gerar lucros continua sendo os softwares antigos.

O big data existe ? Sua razão de ser principal é processar grandes quantidades de dados, bits e bytes na casa dos milhões, quiçá bilhões de registros, mas quando necessitamos de alta performance, segurança, continuidade, uso inteligente de recursos limitados, nisso a IBM ainda é a líder absoluta, por mais que surja o cloude computer, o custo de alocar mais maquinas (espaço, cpu e ram), acaba ultrapassando os custos com equipamento IBM Mainframe, o Azure e o AWS são jovens nesse mercado, somente o tempo dirá quem será o vencedor..

Onde a IBM errou, então?

Article content

Abandonando as pessoas, esse foi o erro, mas antes temos que agradecer a Linux Torvalds e a derrocada da Microsoft, calma ai, está pensando que surtei? Estou falando bobagens e fazendo-o perder tempo precioso? Calma, vamos por partes, que explicarei melhor.

A Microsoft nos anos 90 tomou de assalto o mundo da informática, abocanhando grande fatias de mercado da IBM, graças a pirataria de informática, em pouco tempo todos os trabalhadores do mundo foram treinados gratuitamente no pacote MS Office, dominando o Word, Excel , Access e Power Point, em detrimento do WordStar, Lotus, Dbase IV e similares.

Nesse meio do caminho existia um movimento barulhento, alimentado com famosas consultorias, que convidava executivos de informatica para jantares, viagens e passeios. Onde aproveitavam para catequizar e vender as boas novas dos Servers, dos celeiros com centenas de servidores, muito mais economicos que o Mainframe, era o inicio do Downsize e posteriormente o Rightsite.

Voltando a Microsoft madura e com mão de obra qualificada e treinada foi fácil, obrigar as empresas a comprarem as licenças e investir em treinamentos empresariais caríssimos e suas certificações, enquanto isso a IBM dormia, dificultando a reciclagem nos estudos e construindo uma muralha maior que a da China, cheia de barreiras de acesso a novos e jovens profissionais, mas também era o inicio de uma revolução silenciosa, nos bastidores insatisfeitos criavam uma via alternativa: surgia o Python, o Java e o Javascript, antes chamado Actionscript.

Um maxima jedi: "No People No Program", afinal toda linguagem de programação necessita sempre de reciclagem, sangue novo para inovar e criar novas formas de fazer, padawans aprendendo os fundamentos da linguagem e evoluindo com novos conhecimentos e técnicas, ao mesmo tempo repassando novos conhecimentos aos velhos jedis, numa via de mão dupla de aprimoramento continuo.

Onde Linux Torvalds entra nessa

Article content

História?

A Microsoft sendo uma cria da IBM, acabou herdando alguns vícios e mesmo a arrogância da BIG Blue, ao dominar o mercado da baixa plataforma, foi consumida pelo lado negro da força, e tornou-se uma ditadora suprema. Perpetuando os erros da IBM com cursos caríssimos e barreira de acesso a novos programadores. Criando uma geração de DEVs que odiavam a gigante de Redmond.

Após a morte do Clipper, o Visual Basic virou a linguagem do povo, mas era limitada, enquanto o C era complexo, difícil e pouco intuitivo, em pouco tempo a odiada MS, começou a ser hostilizada pelos DEVs do software livre e empresas concorrentes, que aproveitaram para imitar Brutus e apunhalar Caesar.

Article content

.

Com isso o jovem jedi Linux, seguindo o mesmo caminho do Gates e o CPM e Jobs nos IOS, mergulhou no Unix e criou seu Linux, porém sendo altamente inovativo, ele abriu a caixa preta e convidou a comunidade DEV e jovens universitários do mundo a participarem da festa e criarem suas próprias versões, compartilhando ideias e projetos na aldeia global interligada pela WEB e suas primordiais redes sociais IRC e ICQ.

Nessa onda de mudança do software aberto a Microsoft sentiu a dor, perdeu mercado, amargou perda financeiras e acabou sendo a empresa mais odiada pelo mundo dos programadores jedis, o JAVA e o Linux viraram os queridinhos e em menos de uma década dominaram o mercado de baixa plataforma.

Enquanto isso, a IBM altamente entrincheirada na Alta Plataforma, pouco mudou, mesmo vendo que a cada vez haviam menos DEVs treinados em Alta Plataforma, encarecendo a mão de obra e inviabilizando novos projetos, afinal quem se arriscaria a desenvolver um software onde não encontraria profissionais para darem sustentação ou manutenção evolutiva?

Para piorar o cenário da Big Blue, o advento dos ERPs tendo o SAP como seu maior expoente e a tentativa falhada do Navision da Microsoft criaram mais caos no turbulento e agitado mercado de IT, dividindo ainda mais os DEVS, seguindo a máxima dividir para reinar.

Veja que coisa agora tínhamos jedis em Mainframe, jedis em SAP, jedis em Microsoft e os jedis renegados em JAVA, sendo que muitos descontentes das outras tribos migraram para o JAVA enriquecendo esta linguagem, debugando, sugerindo inovações, evoluindo e criando novos padrões.

O império contra-ataca.

Article content

A Microsoft pressionada pelo mercado, acuada pela Google de um lado e no fronte das comunidades livres JAVA e sofrendo ataques sucessivos pelo IOS no altamente elitizado mercado de TOPs computers, perdendo o universo universitário para os squads Linux. Reinventou-se e escreveu um novo capítulo na história, diferentemente da IBM, que morosamente engatinha os primeiros passos, a reinvenção da MS deu um passo além, democratizou o acesso a informação e ofereceu um nova gama de serviços e oportunidades aos DEVs criando uma academia de padawans mundial.

O primeiro passo foi criar uma rede social (comprou e reformulou o Linkedin), segundo passo educar e difundir o conhecimento (comprou e reformulou o GitHUb) e terceiro passo cursos e formações gratuitas (abriu o código fonte de tudo e deu para o mercado), a cada dia vemos mais e mais DEVs tornando-se jedis Microsoft, a comunidade acadêmica utilizando maciçamente o Azure e o VS Code, abocanhando fatias de mercado da AWS da Amazon e o C Sharp debutando e conquistando fans.

A IBM assistindo todos estes eventos, entrou tardiamente nesta corrida, mas a lição foi aprendida, correndo contra o relógio, desenvolveu uma plataforma de ensino e divulgação do Mainframe, conhecida como projeto ZOWE e modestamente vem educando uma nova geração de jedis em Mainframe. Inclusive tentando atrair os descontentes do Linux / Java, visando reforçar suas linhas e criar novas estratégias.

Hoje temos o LinuxOne rodando em um Mainframe IBM Z e todas as linguagens que estavam fora do Mainframe, agora estão dentro convivendo em harmonia e complementando as diversas frentes.

Minha visão do Mundo IBM Mainframe.

Article content

Enquanto o ensino de PL/I e Cobol forem elitizados o Mainframe está condenado a morte e obsolência, pois o Peopleware é que dão vida ao sistema, sem eles não adianta ter os melhores e mais rápidos computadores do mundo, as linguagens mais performáticas, seguras e a prova de bugs estrupidos, se não há humanos para operar e criar novas soluções e venderem-nas para o mercado.

Acredito que as grandes consultoras de informática deveriam criar pools de treinamento usando plataformas existentes, indico a Digital Innovation One e criarem bootcamps de Mainframe, na tentativa de atrair jovens talentos para o mundo da Alta Plataforma e através dessa iniciativa darem sobrevida e quem sabe evoluir novos mercados criando um novo tempo.

Nelson Blecher e a morte do IBM

Article content

Passado s quase 30 anos do inspirador artigo e reportagem de Blecher sobre a morte da IBM, a BIG BLUE continua viva e ativa, apesar das cisões, perdas de mercados, diminuição de prestígios, continua vendendo e lucrando.

Seus algozes caíram um a um, Xerox quase sumiu, HP e Compac são sombras do que eram, SUN foi incorporada e as fabulosas e fantásticas DotCom, viraram estudos de caso, ilustrando o grande risco do efeito manada e os vieses dos investidores.

Para quem gosta de uma boa historia deixo os links de antigos artigos, muito obrigado Nelson Blecher, me inspirei neles para escrever estas linhas.

https://www1.folha.uol.com.br/fsp/1994/9/18/mais!/30.html

https://www1.folha.uol.com.br/fsp/1994/9/18/mais!/29.html

Conclusão

No artigo de hoje, jovem padawan fizemos um giro pelo Império, vimos como o mercado é mutável, como tecnologias e empresas surgem e somem, paradigmas computacionais caem por terra, antigos vilões se reciclam e viram heróis.

Mas por trás de todas as evoluções e involuções vemos a figura do SER HUMANO como agente de mudança, o trabalhador que precisa pagar o arroz feijão, que uma vez analista extinto, necessita se reinventar e adquirir novos conhecimentos, estudar novas tecnologias e procurar novos senhores feudais para defender.

Meu conselho a ti, jovem e iniciante padawan, estude, escolha a sua tecnologia preferida e torne-se um jedi, porem fique atento as ondas da evolução, prepara-se para migrar no tempo certo, não pare de estudar nunca, evolua, participe e defenda a sua LP preferida.

Espero ter ajudado ate o próximo artigo.

Article content
Article content

Mais momento jabá, para distrair, visite meu vídeo e veja para onde fui desta vez: https://www.youtube.com/watch?v=C5olTn9Dczw

Bom curso a todos.

Article content

https://www.linkedin.com/in/vagnerbellacosa/

Article content

https://github.com/VagnerBellacosa/

Pode me dar uma ajudinha no YouTube?

Article content

https://www.youtube.com/user/vagnerbellacosa

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