Translate

sexta-feira, 19 de junho de 2026

🚀 CICS BMS para Padawans: Do Primeiro MAP ao Mundo Real dos Sistemas Bancários

Selecione um artigo ☕





quinta-feira, 18 de junho de 2026

Git, GitHub e DevOps para Profissionais IBM Z Por que COBOL Developers, Sysprogs e Sysadmins precisam dominar Git em 2026

 

Bellacosa Mainframe e o Git Github e DevOps para Mainframers

☕🚀 Um Café no Bellacosa Mainframe

Git, GitHub e DevOps para Profissionais IBM Z

Por que COBOL Developers, Sysprogs e Sysadmins precisam dominar Git em 2026

"Deleted your code by mistake? Without Git, it's gone forever."

Confesso que, ao observar aqueles infográficos coloridos sobre Git e DevOps, senti algo curioso.

Em poucos segundos eles conseguiram condensar uma transformação tecnológica que levou quase quarenta anos para acontecer.

Para muitos jovens desenvolvedores, Git sempre existiu.

Para nós, veteranos do Mainframe, sabemos que não foi assim.

Nós vivemos outra realidade.

Vivemos a era dos datasets PDS.

Vivemos a era dos backups manuais.

Vivemos a era do Panvalet.

Do Librarian.

Do Endevor.

Do Changeman.

Do SCLM.

Do ISPW.

Do membro COBOL001.

Do COBOL001.BKP.

Do COBOL001.OLD.

Do COBOL001.TESTE.

Do COBOL001.NOVO.

Do COBOL001.NOVO2.

Do COBOL001.NOVO3.

E, inevitavelmente, do lendário:

COBOL001.FINAL

COBOL001.FINAL2

COBOL001.FINAL_DEFINITIVO

COBOL001.FINAL_DEFINITIVO_OK

COBOL001.AGORA_VAI

Parece piada.

Mas muitos de nós trabalhamos exatamente dessa maneira.

E foi justamente para resolver esse caos que surgiu uma das ferramentas mais importantes da história da Engenharia de Software.

Git.

E não estou exagerando.

Git talvez seja tão revolucionário para o desenvolvimento moderno quanto o JES2 foi para processamento batch, quanto o CICS foi para processamento online ou quanto o DB2 foi para persistência transacional.

Git mudou a maneira como produzimos software.

Bellacosa Mainframe e a evolucao da gestao dos fontes

A primeira geração do controle de versões

Antes do Git existiam várias abordagens.

RCS.

SCCS.

CVS.

Visual SourceSafe.

Subversion.

ClearCase.

Perforce.

Cada um tentou resolver o mesmo problema.

Como permitir que múltiplas pessoas trabalhem no mesmo código sem destruir o trabalho umas das outras?

No Mainframe, resolvemos isso de forma diferente.

Panvalet.

Librarian.

Endevor.

ISPW.

Changeman.

Essas ferramentas foram brilhantes.

E continuam sendo.

Especialmente em ambientes regulados.

Bancos.

Seguradoras.

Governo.

Utilities.

Mas havia uma diferença.

Grande parte delas era centralizada.

Tudo dependia de um servidor.

Git mudou isso.

Git é distribuído.

E isso altera completamente a arquitetura do desenvolvimento.

O que realmente é Git?

A maioria dos cursos ensina:

Git é um sistema de versionamento.

Tecnicamente está correto.

Mas é uma definição pobre.

Git é muito mais.

Git é um banco de dados.

Git é uma máquina do tempo.

Git é um mecanismo de auditoria.

Git é uma ferramenta de colaboração.

Git é um sistema de rastreabilidade.

Git é um gatilho para automação.

Git é praticamente o sistema nervoso central do DevOps moderno.

Cada commit registra:

Quem alterou.

Quando alterou.

Por que alterou.

Qual requisito atendeu.

Qual incidente corrigiu.

Qual sprint participou.

Qual história de usuário foi implementada.

Qual vulnerabilidade foi mitigada.

Git não apenas salva arquivos.

Git preserva conhecimento organizacional.

O segredo escondido do Git

Poucos profissionais conhecem sua arquitetura interna.

Git não armazena arquivos.

Git armazena objetos.

Blob.

Tree.

Commit.

Tag.

Blob representa dados.

Tree representa diretórios.

Commit representa estados.

Tag representa marcos.

Cada commit possui um hash.

Durante muitos anos SHA-1.

Hoje caminhando para SHA-256.

Um commit não é uma diferença.

Ele é uma fotografia completa.

Um snapshot.

É por isso que Git consegue voltar meses no passado.

Como um SMF para código-fonte.

Aliás...

Talvez essa seja a analogia perfeita para um sysprog.

Git é quase um SMF de desenvolvimento.

Cada alteração gera um registro permanente.

O Sysprog e o Git

Talvez alguns sysprogs pensem:

"Mas Git é coisa de desenvolvedor."

Não.

Não mais.

Hoje praticamente toda infraestrutura está migrando para Infrastructure as Code.

Parmlibs.

Policies.

WLM.

NetView.

SA z/OS.

Ansible.

Terraform.

Scripts REXX.

Procedures.

JCL.

USS scripts.

Tudo pode estar em Git.

Imagine uma alteração em uma política WLM.

Antigamente:

Editar.

Salvar.

Copiar.

Torcer.

Hoje:

Criar branch.

Modificar.

Commit.

PR.

Review.

Merge.

Deploy automatizado.

Rollback imediato.

A governança melhora absurdamente.

O Sysadmin moderno também virou desenvolvedor

Existe uma transformação interessante acontecendo.

Sysadmins estão programando.

Desenvolvedores estão automatizando infraestrutura.

DBAs escrevem pipelines.

Sysprogs utilizam APIs REST.

Todos começam a convergir.

A linha entre operações e desenvolvimento desaparece.

Foi exatamente isso que criou DevOps.

DevOps não é ferramenta

Essa talvez seja a maior confusão do mercado.

DevOps não é Jenkins.

Não é GitHub.

Não é Kubernetes.

Não é Docker.

Não é Ansible.

DevOps é cultura.

É reduzir silos.

Eliminar burocracias.

Aproximar pessoas.

Automatizar processos.

Aumentar feedback.

Reduzir tempo de entrega.

No Mainframe isso é extremamente relevante.

Porque o Mainframe sempre teve uma cultura muito compartimentalizada.

Equipe COBOL.

Equipe DB2.

Equipe CICS.

Equipe Storage.

Equipe RACF.

Equipe Sysprog.

Equipe Operações.

Equipe Middleware.

Equipe Rede.

Equipe Segurança.

DevOps propõe outra visão.

Todos trabalham pelo mesmo objetivo.

Entregar valor ao negócio.

GitHub não é Git

Muitos iniciantes confundem.

Git é tecnologia.

GitHub é plataforma.

GitLab é plataforma.

Bitbucket é plataforma.

Azure DevOps é plataforma.

Git continua sendo Git.

Independentemente da hospedagem.

GitHub adicionou uma camada extremamente poderosa.

Issues.

Actions.

Codespaces.

Security.

Dependabot.

Packages.

Container Registry.

Wiki.

Pull Requests.

Tudo integrado.

Pull Request: a maior revolução social do desenvolvimento

Eu particularmente considero Pull Request uma das melhores invenções da engenharia moderna.

Porque ela resolve algo difícil.

Compartilhar conhecimento.

Imagine um desenvolvedor COBOL júnior.

Ele escreve:

MOVE WS-CPF TO WS-TEMP

Um desenvolvedor sênior comenta:

"Poderíamos validar antes."

Outro comenta:

"Talvez usar EVALUATE seja melhor."

Outro:

"Precisamos mascarar LGPD."

Resultado?

O código melhora.

O profissional melhora.

A equipe melhora.

A empresa melhora.

PR é mentoria embutida.

O medo do merge conflict

Todo desenvolvedor já sentiu frio na barriga.

git pull

CONFLICT

Automatic merge failed.

Para iniciantes parece um desastre.

Para equipes maduras é rotina.

Conflitos indicam colaboração.

Duas pessoas trabalharam na mesma área.

Git apenas pede ajuda.

Ele não consegue decidir sozinho.

Você decide.

Git apenas documenta.

Git Flow versus GitHub Flow

Durante anos utilizamos Git Flow.

Main.

Develop.

Feature.

Release.

Hotfix.

Funciona muito bem.

Especialmente em bancos.

Porém empresas modernas começaram simplificar.

GitHub Flow.

Main.

Feature.

PR.

Merge.

Deploy.

Google foi além.

Trunk Based Development.

Branches curtíssimas.

Commits pequenos.

Integração contínua.

Menos divergência.

Menos conflitos.

Mais velocidade.

Git para COBOL Developers

Aqui entramos em um ponto fascinante.

Durante muito tempo dizia-se:

COBOL não combina com Git.

Hoje isso é completamente falso.

IBM DBB.

IBM Dependency Based Build.

zAppBuild.

Z Open Editor.

Rocket Git.

Git Integration for Endevor.

ISPW Git Integration.

IDz.

Wazi Developer.

VS Code.

Tudo isso mudou o cenário.

Hoje um desenvolvedor COBOL pode trabalhar assim.

Abrir VS Code.

Editar programa COBOL.

Executar testes.

Commit.

Push.

Criar PR.

Executar pipeline.

Compilar.

Linkedit.

DB2 Bind.

Newcopy CICS.

Deploy.

Exatamente como Java.

Exatamente como Python.

Exatamente como Node.

Jenkins: o operador automático

Se Git é o cérebro.

Jenkins é o operador.

Ele observa commits.

Dispara builds.

Executa testes.

Compila COBOL.

Gera relatórios.

Aciona SonarQube.

Publica artefatos.

Executa deploy.

Notifica equipes.

No fundo, Jenkins faz o papel que muitos operadores humanos executavam.

Só que 24 horas por dia.

Sem esquecer etapas.

Sem distrações.

GitOps: talvez a próxima revolução

GitOps é simples.

Tudo é Git.

Deseja mudar um cluster Kubernetes?

Commit.

Deseja alterar firewall?

Commit.

Deseja atualizar pipeline?

Commit.

Deseja modificar política?

Commit.

Git torna-se a fonte única da verdade.

Single Source of Truth.

Isso é extremamente poderoso.

Porque elimina configurações manuais.

Elimina servidores "snowflake".

Elimina ambientes misteriosos.

Tudo fica reproduzível.

E a segurança?

Segurança também mudou.

DevSecOps nasceu justamente aqui.

SAST.

DAST.

Dependency Scan.

Secrets Detection.

SBOM.

Tudo integrado ao pipeline.

O desenvolvedor faz commit.

Ferramentas verificam.

Bibliotecas vulneráveis.

Credenciais expostas.

Falhas conhecidas.

Antes de chegar em produção.

No Mainframe isso pode incluir:

RACF reviews.

JCL analysis.

CICS security checks.

DB2 privilege validation.

SMF auditing.

O papel do Sysprog em 2026

Antigamente o Sysprog era apenas administrador.

Hoje é arquiteto.

Automatizador.

Consultor.

Especialista em APIs.

Especialista em observabilidade.

Especialista em pipelines.

Especialista em integração.

Especialista em segurança.

Sysprog moderno entende:

Git.

GitHub.

GitLab.

Ansible.

Python.

REXX.

Jenkins.

OpenShift.

Containers.

z/OSMF.

Zowe.

REST APIs.

Porque o Mainframe deixou de ser uma ilha.

Ele tornou-se parte do ecossistema corporativo.

O novo profissional IBM Z

Acredito que o profissional IBM Z de maior valor em 2026 possui uma característica interessante.

Ele pensa como um desenvolvedor.

Age como um administrador.

Automatiza como um engenheiro DevOps.

Protege como um especialista em segurança.

E governa como um arquiteto.

Ele consegue conversar com:

Desenvolvedor Java.

Equipe Cloud.

Kubernetes.

Segurança.

Storage.

Networking.

Data Science.

IA.

Sem abandonar aquilo que torna o Mainframe único.

Confiabilidade.

Escalabilidade.

Disponibilidade.

Integridade transacional.

Processamento massivo.

Pensando durante o café

Talvez a grande mensagem escondida por trás daqueles simpáticos desenhos coloridos seja esta:

Git não substitui o conhecimento Mainframe.

Git potencializa o conhecimento Mainframe.

Ele não aposenta COBOL.

Ele amplia o alcance do COBOL.

Ele não elimina o Sysprog.

Ele transforma o Sysprog em um engenheiro de plataforma.

Ele não mata operações.

Ele automatiza operações repetitivas.

A próxima geração de profissionais IBM Z provavelmente não conhecerá Panvalet.

Talvez nunca utilize Librarian.

Possivelmente jamais veja um Changeman clássico.

Mas certamente abrirá um Pull Request.

Criará uma branch.

Executará uma pipeline.

Fará deploy automatizado.

E continuará processando bilhões de transações por dia em um IBM Z.

Porque, no final das contas, o objetivo nunca foi Git.

Nunca foi GitHub.

Nunca foi Jenkins.

Nunca foi Kubernetes.

O objetivo sempre foi o mesmo desde os tempos do System/360.

Entregar software confiável.

Mais rápido.

Mais seguro.

Mais auditável.

Mais sustentável.

E, se possível, com uma boa xícara de café ao lado do teclado 3270.

quarta-feira, 17 de junho de 2026

☕🏠☁️ CLOUD REPATRIATION — QUANDO AS EMPRESAS DESCOBREM QUE NEM TUDO DEVERIA TER IDO PARA A NUVEM

 

Bellacosa Mainframe e a tecnica de cloud repatriation

☕🏠☁️ CLOUD REPATRIATION — QUANDO AS EMPRESAS DESCOBREM QUE NEM TUDO DEVERIA TER IDO PARA A NUVEM

Se você é uma Analista COBOL Júnior, provavelmente cresceu ouvindo uma frase que parecia uma verdade absoluta:

"O futuro está na nuvem."

Durante mais de uma década, empresas do mundo inteiro migraram aplicações, bancos de dados, sistemas corporativos e ambientes inteiros para AWS, Azure e Google Cloud.

As apresentações dos fornecedores mostravam um cenário quase perfeito.

Tudo seria:

  • mais rápido;

  • mais moderno;

  • mais simples;

  • mais seguro;

  • mais barato.

Executivos ficaram encantados.

Arquitetos embarcaram na jornada.

Consultorias venderam projetos bilionários.

E milhares de empresas iniciaram aquilo que ficou conhecido como:

Cloud Migration.

Mas alguns anos depois algo inesperado começou a acontecer.

Empresas gigantes passaram a fazer o caminho inverso.

Sim.

O movimento contrário.

Retirar sistemas da nuvem.

Trazer aplicações de volta para datacenters próprios.

Mover cargas para ambientes especializados.

Consolidar plataformas.

Esse fenômeno ganhou um nome que talvez você escute cada vez mais nos próximos anos:

Cloud Repatriation.

Ou simplesmente:

Repatriação da Nuvem.

E para quem trabalha com Mainframe, COBOL e sistemas corporativos, entender esse conceito é fundamental.

Porque ele está mudando a forma como as empresas enxergam tecnologia.


O sonho da nuvem

Vamos voltar alguns anos.

Imagine uma empresa tradicional.

Ela possui:

  • servidores físicos;

  • storage;

  • rede;

  • datacenter;

  • equipe de infraestrutura.

Tudo precisa ser comprado.

Tudo precisa ser instalado.

Tudo precisa ser mantido.

Quando a nuvem chegou, a promessa parecia revolucionária.

Ao invés de comprar:

  • você alugaria.

Ao invés de esperar semanas:

  • criaria recursos em minutos.

Ao invés de investir milhões:

  • pagaria apenas pelo uso.

Parecia perfeito.

E para muitas situações realmente era.


O nascimento do "Cloud First"

Entre 2015 e 2022 surgiu uma expressão muito popular.

Cloud First.

Ou seja:

"A nuvem primeiro."

Toda nova solução deveria nascer em cloud.

Muitas organizações foram além.

Não apenas criaram sistemas novos.

Também migraram sistemas antigos.

Tudo virou candidato à nuvem.

ERP.

CRM.

Banco de dados.

Analytics.

Arquivos.

Aplicações críticas.

Em muitos casos sem uma análise profunda de custo-benefício.


A pergunta que ninguém fazia

Durante a fase de entusiasmo existia uma pergunta que poucos executivos faziam:

"Quanto isso custará daqui a cinco anos?"

A maioria analisava apenas:

  • velocidade;

  • facilidade;

  • inovação.

Mas ignorava:

  • crescimento;

  • consumo;

  • escalabilidade financeira.

A conta parecia pequena no início.

Mas crescia silenciosamente.


A armadilha do sucesso

Imagine uma fintech.

Primeiro ano:

100 mil clientes.

Segundo ano:

1 milhão.

Terceiro ano:

10 milhões.

Quarto ano:

50 milhões.

Tudo parece ótimo.

Mas existe um detalhe.

Cada cliente gera:

  • armazenamento;

  • processamento;

  • logs;

  • backups;

  • monitoramento;

  • tráfego de rede.

Quanto mais sucesso a empresa tem, maior fica a fatura.

O paradoxo é interessante.

O crescimento do negócio aumenta também o custo operacional da nuvem.


Quando chega a conta

É nesse momento que começa a repatriação.

Os diretores financeiros começam a fazer perguntas.

Por exemplo:

  • Estamos usando tudo que pagamos?

  • Precisamos realmente dessa configuração?

  • Existe alternativa mais barata?

  • O custo por transação está aumentando?

  • O retorno continua justificando o investimento?

E muitas vezes a resposta é surpreendente.

Nem toda carga de trabalho se beneficia economicamente da nuvem.


A analogia da casa

Uma das formas mais simples de entender Cloud Repatriation é imaginar um imóvel.

No começo você mora de aluguel.

Faz sentido.

Você ainda está começando.

Precisa de flexibilidade.

Não quer investir muito.

Mas imagine que passaram vinte anos.

Você continua pagando aluguel.

Todo mês.

Sem parar.

Em algum momento surge a pergunta:

"Não seria melhor comprar?"

A repatriação nasce exatamente dessa reflexão.


O caso do Dropbox

Um dos exemplos mais famosos ocorreu com o Dropbox.

Durante anos a empresa utilizou cloud pública.

Mas conforme cresceu percebeu algo importante.

O volume de armazenamento era gigantesco.

A escala era enorme.

A previsibilidade era alta.

O resultado?

Passou a investir fortemente em infraestrutura própria.

A economia foi medida em centenas de milhões de dólares ao longo dos anos.

Isso chamou a atenção do mercado.


O caso da 37signals

Outro exemplo muito discutido foi a empresa por trás do Basecamp.

Após anos utilizando cloud pública, seus executivos anunciaram um movimento de retorno para infraestrutura própria.

O argumento principal?

Economia.

Segundo eles, a redução de custos seria enorme.

A notícia gerou debates em toda a indústria.


O que isso ensina para uma Analista COBOL?

Ensina algo extremamente importante.

Tecnologia não é religião.

Não existe:

  • Mainframe bom.

  • Cloud ruim.

Nem o contrário.

Existe apenas:

o ambiente correto para a carga correta.

Essa é uma das maiores lições da arquitetura moderna.


Nem toda carga é igual

Imagine duas aplicações.

Primeira aplicação:

  • Website promocional.

  • Acessos variáveis.

  • Crescimento imprevisível.

Cloud faz sentido.

Agora imagine:

  • processamento de contas bancárias;

  • liquidação financeira;

  • batch noturno;

  • milhões de transações previsíveis.

Talvez a análise econômica seja diferente.

Talvez uma plataforma especializada seja mais eficiente.

Talvez um mainframe seja mais competitivo.

Tudo depende do contexto.


O papel do Mainframe nessa história

É aqui que muitos jovens profissionais ficam surpresos.

Durante anos ouviram que o Mainframe estava desaparecendo.

Mas a realidade mostrou algo curioso.

Enquanto algumas empresas tentavam migrar tudo para cloud, outras perceberam que certas cargas continuavam extremamente eficientes no IBM Z.

Por quê?

Porque o Mainframe foi construído justamente para:

  • alta escala;

  • alta disponibilidade;

  • processamento transacional;

  • confiabilidade extrema.

Essas características continuam valiosas.

Muito valiosas.


O custo invisível da nuvem

Uma Analista COBOL costuma enxergar claramente os custos de CPU e disco em ambientes tradicionais.

Na cloud surgem custos menos óbvios.

Por exemplo:

  • transferência de dados;

  • snapshots;

  • logs;

  • replicação;

  • monitoramento;

  • APIs;

  • tráfego entre regiões.

Cada item parece pequeno.

Somados podem se tornar gigantescos.

É por isso que tantas empresas passaram a adotar práticas de FinOps.


O nascimento do FinOps

FinOps significa:

Financial Operations.

Ou seja:

Operações financeiras aplicadas à tecnologia.

Hoje muitas empresas possuem equipes inteiras dedicadas a responder perguntas como:

  • Quem está consumindo recursos?

  • Quanto custa cada aplicação?

  • Qual é o custo por cliente?

  • Qual é o custo por transação?

Isso praticamente não existia no início da corrida para a nuvem.


A verdade que ninguém gosta de ouvir

Existe uma verdade que incomoda muitos vendedores de tecnologia.

Nem toda inovação reduz custos.

Algumas aumentam custos.

Mas aumentam receita.

E isso pode ser perfeitamente aceitável.

Cloud frequentemente se encaixa nesse cenário.

A empresa paga mais.

Mas cresce mais rápido.

Lança produtos mais rapidamente.

Conquista clientes mais cedo.

Portanto o custo adicional pode valer a pena.


Então por que repatriar?

Porque chega um momento em que determinadas cargas se tornam:

  • previsíveis;

  • estáveis;

  • maduras.

Nesse ponto a elasticidade da cloud perde parte do valor.

E a eficiência operacional começa a ganhar importância.

A pergunta muda.

Deixa de ser:

"Como crescer?"

E passa a ser:

"Como operar com eficiência?"


O futuro é híbrido

Talvez essa seja a maior conclusão.

O futuro não parece ser:

  • tudo na cloud;

  • tudo no mainframe;

  • tudo on-premises.

O futuro parece híbrido.

Cada carga de trabalho executada no ambiente mais adequado.

É exatamente isso que vemos nos grandes bancos.

Itaú.

Bradesco.

Banco do Brasil.

Santander.

Caixa.

Todos operam ambientes mistos.

Cloud.

Linux.

Containers.

APIs.

Mainframe.

Tudo convivendo.

Tudo integrado.


O que você deve aprender como profissional

Se você está começando em COBOL, não caia na armadilha de pensar que sua carreira está presa ao passado.

Pelo contrário.

O mercado está procurando profissionais que entendam integração.

Profissionais que consigam conversar sobre:

  • COBOL;

  • APIs;

  • Cloud;

  • Mensageria;

  • Kubernetes;

  • IBM Z;

  • Arquitetura distribuída.

Porque a verdadeira transformação digital não consiste em destruir o legado.

Consiste em conectá-lo ao futuro.


Conclusão: O Retorno da Maturidade Tecnológica

Cloud Repatriation não significa fracasso da nuvem.

Também não significa vitória do Mainframe.

Significa algo muito mais interessante.

Significa maturidade.

O mercado finalmente começou a entender que tecnologia não deve ser escolhida por moda.

Nem por marketing.

Nem por tendências.

Ela deve ser escolhida por critérios objetivos:

  • custo;

  • desempenho;

  • segurança;

  • disponibilidade;

  • escalabilidade.

A nuvem continuará crescendo.

Os datacenters continuarão existindo.

Os mainframes continuarão processando bilhões de transações.

E as arquiteturas híbridas se tornarão cada vez mais comuns.

Para uma Analista COBOL Júnior, essa é uma excelente notícia.

Porque mostra que o conhecimento de sistemas corporativos continua extremamente relevante.

O profissional do futuro não será aquele que conhece apenas uma tecnologia.

Será aquele que entende quando usar cada uma delas.

E talvez essa seja a maior lição da Cloud Repatriation.

Às vezes a inovação não está em mover tudo para a nuvem.

Às vezes a inovação está em descobrir o que nunca deveria ter saído de casa.

terça-feira, 16 de junho de 2026

IBM 115 Anos: A Empresa que Ajudou a Construir o Mundo Digital


Bellacosa Mainframe e historia da IBM em resumo


IBM 115 Anos: A Empresa que Ajudou a Construir o Mundo Digital

Uma viagem pela história, curiosidades, desafios e segredos da gigante que ainda move bilhões de transações por dia

16 de junho.

Para muitos, apenas mais um dia no calendário.

Para quem trabalha com Mainframe, COBOL, z/OS, CICS, DB2 e tecnologia corporativa, é uma data especial: o aniversário da IBM, uma das empresas mais influentes da história da humanidade.

Em 16 de junho de 1911 nasceu uma organização que sobreviveria a duas guerras mundiais, à Grande Depressão, à Guerra Fria, ao surgimento do computador pessoal, à internet, ao smartphone, à computação em nuvem e agora à Inteligência Artificial.

Poucas empresas conseguem permanecer relevantes durante cinco anos.

Algumas sobrevivem vinte.

Raríssimas chegam aos cinquenta.

A IBM chegou aos 115 anos.

E continua ajudando a processar boa parte do dinheiro que circula no planeta.

Para um Desenvolvedor COBOL Jr., compreender a história da IBM é entender a própria história da computação.


Bellacosa Mainframe e os 115 anos da IBM

Antes da IBM Existia um Problema

Imagine o mundo em 1890.

Não havia computadores.

Não havia bancos de dados.

Não havia internet.

Não havia sequer calculadoras eletrônicas.

Governos precisavam contar milhões de pessoas manualmente.

Empresas precisavam processar montanhas de documentos em papel.

Folhas de pagamento eram calculadas à mão.

Erros eram frequentes.

Processos demoravam meses.

Foi nesse cenário que apareceu Herman Hollerith.


O Homem que Criou o Conceito de Processamento de Dados

Herman Hollerith era um engenheiro americano que observou um problema gigantesco:

O censo dos Estados Unidos de 1880 demorou quase oito anos para ser concluído.

Se nada mudasse, o próximo censo demoraria mais do que o intervalo entre censos.

Era matematicamente impossível continuar daquele jeito.

Sua solução foi revolucionária.

Ele criou cartões perfurados capazes de armazenar informações.

Cada furo representava um dado.

Máquinas eletromecânicas liam esses cartões e realizavam contagens automaticamente.

Pela primeira vez na história, uma máquina processava dados em larga escala.

Nascia o conceito que décadas depois evoluiria para os computadores modernos.


O Verdadeiro Nascimento da IBM

Em 1911 várias empresas se fundiram para formar a:

Computing-Tabulating-Recording Company (CTR)

O nome era enorme.

Pouco elegante.

Pouco memorável.

Em 1924, Thomas J. Watson decidiu mudar tudo.

A empresa passou a se chamar:

International Business Machines

Ou simplesmente:

IBM

Uma mudança que parece simples, mas que carregava uma visão ousada.

Watson acreditava que as máquinas de processamento de dados teriam alcance mundial.

Na década de 1920 isso parecia exagero.

Hoje sabemos que ele estava certo.


O Primeiro Easter Egg da IBM

A famosa frase:

"THINK"

foi criada por Thomas Watson Sr.

Ela surgiu em uma reunião onde um executivo perguntou:

"Como resolveremos este problema?"

Watson respondeu:

"Think."

A palavra virou slogan oficial.

Décadas depois inspirou o nome do notebook ThinkPad.

Até hoje a cultura IBM incentiva seus profissionais a pensarem antes de agir.

Uma filosofia simples.

Mas extremamente poderosa.


A IBM e a Segunda Guerra Mundial

Durante os anos 1940 a IBM cresceu enormemente.

Suas máquinas de tabulação eram usadas para processar informações em velocidade inédita para a época.

A guerra acelerou a necessidade de automação.

Governos precisavam controlar:

  • Estoques

  • Logística

  • Produção industrial

  • Recursos militares

A IBM tornou-se referência mundial em processamento de informações.

Mas a verdadeira revolução ainda estava por vir.


O Computador Entra em Cena

Na década de 1950 o mundo testemunhou o nascimento dos computadores eletrônicos.

Grandes máquinas ocupavam salas inteiras.

Consumiam energia absurda.

Possuíam menos capacidade computacional que um relógio inteligente moderno.

Mesmo assim representavam um salto gigantesco.

A IBM rapidamente percebeu que o futuro estava nos computadores.

Surgiram máquinas históricas como:

IBM 650

IBM 701

IBM 704

IBM 7070

Cada uma delas ajudou a criar os alicerces da computação corporativa.


A Maior Aposta da História da Computação

Em 1964 a IBM tomou uma decisão considerada loucura por muitos analistas.

Ela investiu aproximadamente 5 bilhões de dólares no desenvolvimento de uma nova arquitetura.

A aposta recebeu um nome simples:

System/360

Hoje parece apenas mais um produto.

Na época foi uma revolução.


Bellacosa Mainframe e a evolução historica do logotipo IBM

Por Que o System/360 Mudou o Mundo?

Antes do System/360 cada computador era praticamente incompatível com os demais.

Trocar de equipamento significava reescrever programas.

Refazer processos.

Treinar equipes novamente.

A IBM propôs algo radical.

Uma família inteira de computadores compatíveis entre si.

O programa escrito para um modelo poderia funcionar em outro.

Esse conceito influenciou praticamente toda a indústria.

Windows.

Linux.

Unix.

Cloud.

Todos herdaram, direta ou indiretamente, ideias introduzidas pelo System/360.


O Nascimento do Mainframe Moderno

Quando um profissional fala em Mainframe hoje, está falando do descendente direto do System/360.

A linha evoluiu:

System/360

System/370

390

zSeries

System z

IBM Z

z16

z17

Existe uma linha evolutiva contínua de mais de sessenta anos.

Pouquíssimas tecnologias possuem essa continuidade.


Onde Entra o COBOL?

Em 1959 surgiu o COBOL.

Seu objetivo era simples:

Permitir que pessoas de negócios compreendessem programas.

Por isso comandos como:

ADD

SUBTRACT

MOVE

READ

WRITE

são tão próximos da linguagem humana.

A IBM adotou COBOL massivamente.

Bancos.

Seguradoras.

Governos.

Empresas aéreas.

Todos começaram a construir sistemas corporativos usando COBOL.

Muitos desses sistemas continuam funcionando até hoje.


O Grande Mito Sobre COBOL

Você provavelmente já ouviu:

"COBOL está morto."

Curiosamente essa frase existe desde os anos 1980.

Mas o COBOL continua processando:

  • Folhas de pagamento

  • Cartões de crédito

  • PIX

  • TED

  • DOC

  • Seguros

  • Aposentadorias

  • Impostos

Na prática, ele sobrevive porque resolve muito bem problemas de negócios.

Tecnologia não vence porque é nova.

Vence porque funciona.


A Curiosidade Que Surpreende Todo Iniciante

Muitos aplicativos modernos dependem de COBOL sem que seus usuários saibam.

Quando alguém usa:

  • Aplicativo bancário

  • Caixa eletrônico

  • Portal de investimentos

  • Sistema de previdência

Existe uma chance enorme de uma transação COBOL estar participando do processo.

O aplicativo bonito do smartphone frequentemente é apenas a ponta do iceberg.

A parte invisível muitas vezes roda em Mainframe.


O Mainframe Nunca Foi Embora

Existe uma narrativa popular de que Mainframes desapareceram.

Isso nunca aconteceu.

O que aconteceu foi algo diferente.

Eles ficaram invisíveis.

Ninguém vê o Mainframe.

Mas todos usam.

Quando você passa um cartão.

Quando faz PIX.

Quando compra uma passagem aérea.

Quando consulta um seguro.

Quando paga impostos.

Existe uma grande probabilidade de um Mainframe estar envolvido.


O Desafio dos Anos 2000

Um dos maiores momentos da história da IBM foi o famoso Bug do Milênio.

Muitos sistemas armazenavam anos usando apenas dois dígitos.

Exemplo:

99

00

Quando chegasse o ano 2000, milhões de programas poderiam interpretar:

00

como 1900.

O mundo inteiro entrou em pânico.

Governos contrataram milhares de programadores COBOL.

Muitos profissionais construíram carreiras inteiras trabalhando nesse projeto.

O curioso?

Grande parte do sucesso ocorreu justamente porque Mainframes eram sistemas extremamente bem documentados.


O Segundo Easter Egg

Existe uma brincadeira antiga no mundo Mainframe:

"Mainframe é a única tecnologia que os jornais só mencionam quando para."

Quando tudo funciona, ninguém fala.

Quando um banco fica indisponível por dez minutos, vira manchete nacional.

Isso mostra o quanto esses sistemas se tornaram essenciais.


A Era da Internet

Quando a internet surgiu, muitos especialistas declararam o fim do Mainframe.

Aconteceu exatamente o contrário.

A internet aumentou a demanda por processamento.

Mais acessos.

Mais transações.

Mais clientes.

Mais integrações.

O Mainframe tornou-se ainda mais importante.


O Nascimento do DB2

Outro capítulo fundamental da IBM foi o DB2.

Criado a partir das pesquisas de Edgar F. Codd sobre bancos relacionais.

O DB2 ajudou a transformar a forma como empresas armazenam dados.

Hoje conceitos como:

SELECT

JOIN

INDEX

TABLE

são comuns.

Mas houve uma época em que tudo isso era revolucionário.


A Revolução do CICS

Outro herói pouco conhecido é o CICS.

Customer Information Control System.

Ele permitiu que sistemas deixassem de ser exclusivamente batch.

Agora usuários podiam interagir online.

Em tempo real.

Caixas eletrônicos.

Terminais bancários.

Consultas instantâneas.

Tudo isso foi potencializado pelo CICS.


O Que Um COBOL Jr Deve Aprender Com a História da IBM?

Primeira lição:

Tecnologia é uma maratona.

Não uma corrida de cem metros.

A IBM não sobreviveu 115 anos perseguindo modismos.

Ela sobreviveu resolvendo problemas reais.


Segunda lição:

Confiabilidade vale ouro.

Uma aplicação pode ser bonita.

Pode usar a linguagem da moda.

Pode ter milhões de downloads.

Mas se não for confiável, não sobrevive.


Terceira lição:

Fundamentos importam.

COBOL.

JCL.

VSAM.

DB2.

CICS.

Datasets.

Esses conceitos parecem antigos.

Mas continuam sustentando operações críticas.


O Futuro Chegou

Hoje a IBM investe pesadamente em:

  • Inteligência Artificial

  • WatsonX

  • Quantum Computing

  • Cloud Híbrida

  • OpenShift

  • Red Hat

  • Automação

Mas existe algo interessante.

Ela não abandonou o Mainframe.

Pelo contrário.

Ela o integrou ao futuro.

O IBM Z moderno executa:

  • Containers

  • APIs REST

  • Java

  • Python

  • Node.js

  • COBOL

  • IA

Tudo no mesmo ecossistema.


O Maior Easter Egg de Todos

Existe uma ironia divertida na história da tecnologia.

Muitos desenvolvedores passam anos tentando criar sistemas escaláveis.

Altamente disponíveis.

Seguros.

Auditáveis.

Transacionais.

E acabam redescobrindo conceitos que o Mainframe já utilizava há décadas.

Controle transacional.

Alta disponibilidade.

Particionamento.

Segurança centralizada.

Recuperação automática.

Observabilidade.

Governança.

Tudo isso já fazia parte do universo IBM muito antes da maioria das plataformas modernas existir.


Conclusão

Quando comemoramos os 115 anos da IBM, não estamos celebrando apenas uma empresa.

Estamos celebrando uma parte importante da história da computação.

Dos cartões perfurados de Hollerith ao IBM z17.

Do COBOL ao WatsonX.

Do System/360 à Inteligência Artificial.

A IBM ajudou a construir a infraestrutura invisível que move a economia global.

E para você, Desenvolvedor COBOL Jr., existe uma mensagem importante nessa história:

Aprenda as tecnologias modernas.

Explore IA.

Conheça Cloud.

Estude APIs.

Mas nunca subestime os fundamentos.

Porque enquanto o mundo muda de linguagem a cada poucos anos, os sistemas críticos continuam exigindo aquilo que sempre importou:

Confiabilidade.

Performance.

Segurança.

Disponibilidade.

E é exatamente nesse ponto que o Mainframe e a IBM construíram um legado que atravessa gerações.

Parabéns, IBM.

115 anos conectando passado, presente e futuro.