Translate

Mostrar mensagens com a etiqueta cloud. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta cloud. 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: , , , , , , , , , , , , , ,

sexta-feira, 10 de julho de 2026

Kubernetes sem Mistérios : Os 50 Erros que Derrubam Clusters em Produção (e que um Profissional IBM Z já Aprendeu a Evitar Há Décadas)

Bellacosa Mainframe apresenta kubernetes sem misterios


☕ Um Café no Bellacosa Mainframe

Kubernetes sem Mistérios 

Os 50 Erros que Derrubam Clusters em Produção (e que um Profissional IBM Z já Aprendeu a Evitar Há Décadas)

Existe uma curiosidade interessante.

Muitos profissionais enxergam Kubernetes como uma tecnologia revolucionária.

Ela realmente é.

Mas existe outra forma de enxergá-la.

Para quem trabalhou anos em Mainframe, Kubernetes parece muito mais uma redescoberta de conceitos que IBM já aplicava há décadas.

Disponibilidade.

Balanceamento.

Isolamento.

Escalonamento.

Segurança.

Observabilidade.

Recuperação.

Controle de acesso.

Versionamento.

Rollback.

Tudo isso sempre existiu.

A diferença é que hoje esses conceitos aparecem usando containers, pods e YAML.

No IBM Z eles aparecem como:

  • JES2

  • WLM

  • RACF

  • Sysplex

  • CICS

  • Db2

  • GDG

  • VSAM

  • SMF

  • RMF

O objetivo continua exatamente o mesmo:

Fazer sistemas críticos permanecerem funcionando.

O grande problema

Criar um cluster Kubernetes é extremamente fácil.

Rodar um cluster durante cinco anos, sem interrupções relevantes, é extremamente difícil.

Quase todos os grandes incidentes em produção acontecem por pequenas decisões aparentemente inocentes.

É exatamente isso que o infográfico demonstra.

BLOCO 1

Cluster & Infrastructure

Erro 1

Um único Worker Node

Imagine um banco inteiro rodando em apenas um IBM Z.

Parece absurdo.

No Kubernetes isso acontece o tempo inteiro.

Node A

APP1
APP2
APP3
APP4

Se esse servidor falhar...

Tudo cai.

No Mainframe isso seria equivalente a:

  • um único CPC

  • sem Parallel Sysplex

  • sem GDPS

  • sem redundância

Alta disponibilidade simplesmente deixa de existir.

Erro 2

Não proteger o Control Plane

O Control Plane é o cérebro.

Ele contém:

  • API Server

  • Scheduler

  • Controller Manager

  • ETCD

Sem ele...

O cluster fica "cego".

Os containers podem continuar rodando por algum tempo.

Mas nada novo consegue ser criado.

É parecido com perder o JES2 Master.

Erro 3

Não fazer backup do ETCD

O ETCD guarda praticamente todo o estado do cluster.

É equivalente ao:

  • catálogo do sistema

  • SYS1

  • repositórios de configuração

Sem ETCD...

Você perdeu:

  • Deployments

  • Services

  • Secrets

  • ConfigMaps

  • RBAC

  • Namespaces

Ou seja...

Perdeu o cluster.

Erro 4

Misturar Desenvolvimento e Produção

Esse é um erro clássico.

Imagine colocar:

PIX
Internet Banking
Folha de Pagamento

junto com

Sistema de Testes

No mesmo cluster.

Um teste mal executado pode consumir:

CPU

Memória

IO

Rede

e afetar produção.

Mainframe resolveu isso há décadas.

LPARs.

WLM.

Classes de serviço.

Ambientes isolados.

BLOCO 2

Resource Management

Aqui aparece um dos assuntos mais importantes.

Recursos.

No Kubernetes nada funciona "no automático".

Requests

Requests significam:

"O mínimo que preciso."

Exemplo

CPU: 500m

Memory: 1GB

O Scheduler utiliza isso para decidir onde colocar o Pod.

Sem requests...

Ele simplesmente chuta.

É semelhante ao WLM tentando distribuir workload sem conhecer prioridades.

Limits

Agora vem outra história.

Limits representam o máximo permitido.

CPU

2 cores

RAM

4GB

Se ultrapassar...

O processo sofre throttling.

Ou pode ser encerrado.

OOMKilled

Talvez o erro mais famoso.

Quando um container usa mais memória que o permitido.

O Kernel Linux faz:

OOM Killer

e encerra o processo.

No Mainframe seria parecido com:

Storage exhaustion

ou

S878

HPA

Horizontal Pod Autoscaler.

Ele aumenta o número de Pods.

Mas cuidado.

Escalar uma aplicação ruim apenas cria mais instâncias lentas.

É parecido com colocar mais CICS Regions para um programa que possui SQL ruim.

O gargalo continua existindo.

BLOCO 3

Deployment

Aqui surgem alguns erros extremamente comuns.

Nunca usar latest

Jamais.

image: latest

Parece prático.

Mas amanhã...

"latest"

é outra versão.

Você perdeu reprodutibilidade.

Sempre utilize

1.2.7

2.1.0

5.8.12

ou melhor ainda

Digest SHA256.

Isso lembra muito o mundo Mainframe.

Nunca executamos:

PROD.COBOL

Sabemos exatamente qual Load Module foi promovido.

Readiness Probe

O Pod iniciou.

Mas será que ele está pronto?

Não necessariamente.

Uma aplicação Java pode precisar:

30 segundos.

Sem Readiness.

O Kubernetes envia tráfego imediatamente.

Resultado:

Erro.

Liveness Probe

Verifica se o processo continua vivo.

Se travar...

O Kubernetes reinicia.

É semelhante ao Automation do SA z/OS detectando um address space congelado.

Startup Probe

Ideal para aplicações pesadas.

Sem ela...

O Kubernetes mata a aplicação antes dela terminar de iniciar.

Rolling Update

Jamais atualizar todos os Pods simultaneamente.

Sempre:

1
2
3
4

Nunca:

100%

de uma vez

É exatamente o conceito de deploy gradual utilizado por bancos.

BLOCO 4

Networking

Aqui muitos iniciantes sofrem.

Network Policies

Sem elas...

Todo Pod conversa com qualquer Pod.

Isso é perigosíssimo.

Imagine um malware chegando.

Ele consegue acessar praticamente tudo.

É equivalente a um RACF onde todos possuem ALTER em todos os datasets.

Impensável.

DNS

Muitos problemas parecem ser de aplicação.

Na verdade são DNS.

service

↓

CoreDNS

↓

IP

Uma falha aqui afeta milhares de Pods.

NodePort

Expor NodePort diretamente para Internet.

Nunca.

Use:

Ingress

Load Balancer

API Gateway

WAF

TLS

Sem TLS.

Todo tráfego pode ser interceptado.

No Mainframe isso seria equivalente a utilizar TN3270 sem criptografia.

BLOCO 5

Storage & Security

Aqui aparecem erros gravíssimos.

Rodar como Root

Nunca.

Um container comprometido ganha acesso privilegiado.

Use:

runAsNonRoot

readOnlyRootFilesystem

drop capabilities

Secrets em ConfigMaps

Erro extremamente comum.

ConfigMap não criptografa.

Secrets devem permanecer em:

Secret

Vault

KMS

External Secrets

RBAC

Sem RBAC.

Todos administram tudo.

Imagine um operador podendo:

Excluir produção.

Criar usuários.

Modificar políticas.

É por isso que RACF existe.

RBAC é o RACF do Kubernetes.

BLOCO 6

Observabilidade

Talvez o capítulo mais importante.

Sem logs...

Não existe troubleshooting.

Sem métricas...

Não existe capacity planning.

Sem tracing...

Não existe análise distribuída.

Sem dashboards...

Não existe visão operacional.

Ferramentas normalmente utilizadas

Logs

  • ELK

  • OpenSearch

  • Loki

Métricas

  • Prometheus

Dashboards

  • Grafana

Tracing

  • Jaeger

  • Tempo

  • Zipkin

Alertas

  • Alertmanager

Isso lembra muito:

RMF

SMF

OMEGAMON

NetView

Tivoli

Z APM Connect

BLOCO 7

Operação

Aqui aparecem erros humanos.

E a maioria dos grandes incidentes nasce justamente deles.

Deploy manual

Nunca.

Sempre:

Git

Pipeline

Automação

GitOps

O Git torna-se a verdade absoluta.

Toda alteração passa por:

Commit

↓

Review

↓

Pipeline

↓

Deploy

↓

Rollback

É semelhante ao ChangeMan, ISPW ou Endevor.

Nada muda diretamente na produção.

Não testar recuperação

Backup sem restore não vale nada.

Todo DR precisa ser testado.

No IBM Z isso sempre foi obrigatório.

GDPS.

Recovery.

Image Copy.

Log Apply.

Não auditar segurança

Novas vulnerabilidades surgem diariamente.

Imagens precisam ser continuamente escaneadas.

Os "novos" erros 

Os últimos slides ampliam ainda mais a lista.

Entre eles destacam-se:

  • Não definir ResourceQuota.

  • Não usar LimitRange.

  • Ignorar Namespaces.

  • Expor aplicações diretamente.

  • Não realizar backup periódico do ETCD.

  • Não otimizar custos.

  • Não separar ambientes.

  • Não validar probes continuamente.

  • Não monitorar consumo financeiro do cluster.

Esses erros normalmente não derrubam o ambiente no primeiro dia, mas aumentam gradualmente a complexidade operacional e o risco de incidentes.

O grande paralelo com IBM Z

O aspecto mais interessante desse material é perceber que praticamente todos os "50 erros do Kubernetes" já possuem um equivalente consolidado no ecossistema IBM Z:

KubernetesIBM Z / Mainframe
RBACRACF
SchedulerWLM
Rolling UpdatePromoção controlada (Endevor/ISPW/ChangeMan)
ReplicaSetParallel Sysplex
ETCDCatálogos e repositórios críticos do sistema
ObservabilidadeRMF, SMF, OMEGAMON
Health ChecksSA z/OS, NetView
GitOpsGestão de configuração e promoção de software
SecretsRACF + ICSF + cofres corporativos
AutoscalingBalanceamento e classes de serviço do WLM

A tecnologia mudou, mas os princípios permanecem.

A maior lição para um Padawan COBOL

Quem está começando em Kubernetes costuma imaginar que dominar YAML, Pods e Deployments basta para operar um ambiente de produção. Na realidade, isso representa apenas uma pequena parte do trabalho.

Os profissionais mais experientes pensam primeiro em engenharia operacional. Antes de criar um único Deployment, eles definem como recuperar o cluster após uma falha, como limitar recursos para evitar que uma aplicação afete outra, como monitorar métricas, como proteger segredos, como automatizar implantações, como auditar mudanças e como garantir que qualquer alteração possa ser revertida rapidamente.

Essa é exatamente a mentalidade que sempre existiu no IBM Z. Durante décadas, bancos, seguradoras e governos construíram sistemas que precisavam permanecer disponíveis 24 horas por dia. Kubernetes não substitui esses princípios; ele os reapresenta em uma nova arquitetura baseada em containers.

No Bellacosa Mainframe, essa é talvez a maior mensagem deste material: um bom engenheiro de Kubernetes não é aquele que conhece mais comandos kubectl, mas aquele que projeta plataformas resilientes, observáveis, seguras e previsíveis. A verdadeira maturidade está menos na tecnologia utilizada e muito mais na disciplina de engenharia aplicada a ela.

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

quarta-feira, 1 de julho de 2026

Java na Stack Mainframe: O Roteiro Definitivo para um Programador COBOL Padawan Entrar no Mundo Java, IA, Cloud e Modernização do IBM Z

 

Bellacosa Mainframe e o Java na Stack Mainframe

☕ Um Café no Bellacosa Mainframe

Java na Stack Mainframe: O Roteiro Definitivo para um Programador COBOL Padawan Entrar no Mundo Java, IA, Cloud e Modernização do IBM Z

Imagine que você acabou de entrar em um grande banco.

Você conhece COBOL.

Sabe fazer um PERFORM UNTIL.

Entende JCL.

Já escreveu programas para CICS.

Conhece Db2, VSAM e talvez IMS.

Mas, em uma reunião, alguém diz:

"Vamos desenvolver essa nova API em Java, publicar pelo z/OS Connect, automatizar o deploy com Ansible e integrar um agente de IA."

Você pensa:

"Será que vou precisar esquecer tudo o que aprendi em Mainframe?"

A resposta é uma das melhores notícias que um profissional IBM Z pode receber:

Não.

Na verdade, tudo o que você aprendeu continua extremamente valioso.

O Java não veio substituir o COBOL.

Ele veio conversar com ele.

Hoje, o IBM Z é uma plataforma híbrida, onde aplicações COBOL escritas há décadas convivem com microsserviços Java, APIs REST, containers, LinuxONE, automação, inteligência artificial e cloud híbrida.

Neste artigo vamos construir um roteiro completo para que um COBOL Padawan evolua para um desenvolvedor Java dentro da Stack Mainframe.

O maior mito sobre Java no Mainframe

O erro mais comum é procurar um curso chamado:

  • Java para Mainframe

  • Java para z/OS

  • Java para COBOL

antes mesmo de aprender Java.

Isso é equivalente a querer aprender CICS antes de entender COBOL.

Primeiro aprendemos a linguagem.

Depois aprendemos onde ela roda.

Essa é exatamente a recomendação feita por Ian Burnett, engenheiro da equipe de desenvolvimento do IBM CICS:

"Java continua sendo Java. Salvo quando você utiliza recursos específicos do IBM Z, o mesmo código roda em diversas plataformas."

Essa frase resume toda a filosofia da plataforma Java.

Esqueça a ideia de "Java Mainframe"

Não existe uma linguagem chamada Java Mainframe.

Existe apenas Java.

O mesmo Java roda em:

  • Windows

  • Linux

  • macOS

  • LinuxONE

  • z/OS UNIX System Services (USS)

  • OpenShift

  • Cloud

A mágica acontece graças à JVM.

O que é a JVM?

JVM significa:

Java Virtual Machine

Ela é responsável por executar o bytecode produzido pelo compilador Java.

O processo funciona assim:

Código Java (.java)

        │

      javac

        │

Bytecode (.class)

        │

        JVM

        │

Sistema Operacional

No mundo IBM Z acontece exatamente a mesma coisa.

A diferença é que existe uma JVM otimizada para o processador IBM Z.

Hoje a IBM utiliza principalmente o IBM Semeru Runtime, baseado no OpenJDK, otimizado para z/OS e LinuxONE.

Isso significa que o mesmo programa Java pode executar em:

  • LinuxONE

  • USS

  • Open Liberty

  • CICS JVM Server

  • Batch Java

sem precisar ser reescrito.

É o famoso conceito:

Write Once, Run Anywhere.

O COBOL continua vivo?

Mais vivo do que nunca.

Os maiores bancos do mundo ainda executam bilhões de linhas de COBOL.

Esses programas representam décadas de regras de negócio.

Por exemplo:

  • cálculo de juros

  • empréstimos

  • cartões

  • PIX

  • investimentos

  • seguros

  • previdência

O Java não veio substituir essas aplicações.

Ele veio criar novas formas de utilizá-las.

O legado não é o problema

Existe uma frase muito repetida no Bellacosa Mainframe:

O legado não é um peso. É um patrimônio.

Imagine um programa COBOL que calcula crédito há trinta anos.

Ele funciona.

Foi testado milhões de vezes.

Então surge um aplicativo Android.

O aplicativo não precisa reescrever a lógica.

Ele apenas precisa conversar com esse programa.

É aí que entra a modernização.

Java como ponte entre o mundo moderno e o legado

Hoje uma aplicação bancária pode seguir este fluxo:

Aplicativo Android

↓

REST API

↓

Java Spring Boot

↓

z/OS Connect

↓

CICS

↓

Programa COBOL

↓

Db2

Observe quem está no meio da conversa.

O Java.

Ele conecta o mundo digital ao legado corporativo.

O papel do z/OS Connect

O z/OS Connect EE é uma das tecnologias mais importantes da modernização IBM Z.

Sua missão é simples.

Transformar programas COBOL em APIs REST.

Imagine um programa CICS chamado:

CONSULTA_CLIENTE

Antes, somente aplicações CICS conseguiam chamá-lo.

Com o z/OS Connect:

GET

/clientes/12345

vira automaticamente:

Programa COBOL

↓

COMMAREA

↓

Resposta JSON

Sem reescrever o COBOL.

Sem alterar décadas de negócio.

Essa talvez seja a maior revolução do IBM Z nos últimos anos.

JSON substituiu a COMMAREA?

Não.

Cada um possui sua função.

Dentro do CICS continua existindo:

  • COMMAREA

  • Containers

  • Channels

Fora do Mainframe:

  • JSON

  • REST

  • OpenAPI

O z/OS Connect faz a tradução entre esses mundos.

Java conversa naturalmente com o Db2

Outro ponto importante.

O Java utiliza JDBC.

Java

↓

JDBC

↓

Db2 for z/OS

Para quem conhece SQL em COBOL, aprender JDBC costuma ser bastante natural.

LinuxONE: onde o Java brilha

Quando falamos de Java no IBM Z, é impossível não falar do LinuxONE.

O LinuxONE é uma plataforma Linux construída sobre a mesma arquitetura IBM Z.

Ele oferece:

  • alta disponibilidade

  • criptografia

  • escalabilidade

  • virtualização

  • containers

  • Kubernetes

  • OpenShift

Para aplicações Java, é um ambiente extremamente eficiente.

Muitos microsserviços modernos executam em LinuxONE enquanto continuam acessando o legado z/OS.

Open Liberty

Outro componente importante é o Open Liberty.

Ele é um servidor Java moderno, extremamente leve e compatível com Jakarta EE e MicroProfile.

Nele podemos executar:

  • APIs REST

  • aplicações corporativas

  • microsserviços

  • autenticação

  • integração

Tudo isso podendo acessar COBOL via z/OS Connect ou IBM MQ.

IBM MQ

Nem toda integração precisa ser REST.

Muitos bancos utilizam filas.

Java

↓

IBM MQ

↓

COBOL

As mensagens ficam armazenadas até serem processadas.

Isso aumenta confiabilidade e desacopla sistemas.

Ansible no mundo Mainframe

Durante muitos anos administrar Mainframe significava executar comandos manualmente.

Hoje isso mudou.

O Ansible automatiza tarefas como:

  • criação de ambientes

  • deploy

  • configuração

  • instalação

  • atualização

  • coleta de informações

  • execução de scripts

Imagine precisar atualizar cinquenta servidores.

Em vez de acessar um por um, basta executar um Playbook.

Exemplo simplificado:

- Atualizar Open Liberty
- Reiniciar serviço
- Validar aplicação

Tudo automaticamente.

No IBM Z existem coleções específicas para:

  • z/OS

  • USS

  • CICS

  • RACF

  • datasets

  • JCL

  • operações administrativas

O DevOps chegou definitivamente ao Mainframe.

Cloud no mundo Mainframe

Quando falamos em Cloud, muitas pessoas imaginam abandonar o Mainframe.

A realidade é outra.

Hoje predominam arquiteturas híbridas.

Um exemplo:

Cloud

↓

API Gateway

↓

Java

↓

z/OS Connect

↓

COBOL

Parte da aplicação roda na nuvem.

Parte continua no IBM Z.

Cada ambiente faz aquilo em que é melhor.

Inteligência Artificial no IBM Z

Outro tema que deixou de ser futuro.

Hoje encontramos IA aplicada em:

  • detecção de fraudes

  • análise de crédito

  • observabilidade

  • automação operacional

  • atendimento inteligente

  • copilotos de desenvolvimento

  • geração de código

  • documentação

  • análise de logs

Modelos como IBM Granite e watsonx podem trabalhar lado a lado com aplicações Java e COBOL.

O objetivo não é substituir o programador.

É aumentar sua produtividade.

O roteiro Bellacosa para aprender Java

Fase 1 — Pensar como programador Java

Aprenda:

  • variáveis

  • classes

  • objetos

  • métodos

  • encapsulamento

  • herança

  • interfaces

  • exceções

  • Collections

  • Generics

Ainda não pense em Mainframe.

Fase 2 — Ferramentas modernas

Aprenda:

  • Git

  • Maven

  • Gradle

  • JUnit

  • Mockito

  • VS Code

  • IntelliJ IDEA

Fase 3 — Desenvolvimento Web

Estude:

  • HTTP

  • REST

  • JSON

  • XML

  • Servlets

  • APIs

Fase 4 — Spring Boot

Aprenda a criar:

  • microsserviços

  • APIs REST

  • autenticação

  • integração com bancos de dados

Fase 5 — Java Enterprise

Conheça:

  • Open Liberty

  • Jakarta EE

  • MicroProfile

Fase 6 — Java na Stack Mainframe

Agora sim, entre no universo IBM Z:

  • JVM no z/OS

  • USS

  • LinuxONE

  • JDBC para Db2

  • IBM MQ

  • CICS JVM Server

  • JCICS

  • JZOS

  • z/OS Connect EE

  • RACF

  • Open Liberty

  • Batch Java

  • OpenShift

O maior diferencial do programador COBOL

Muitos desenvolvedores Java sabem criar APIs.

Poucos entendem regras de negócio bancárias.

Você já conhece:

  • consistência transacional

  • processamento em lote

  • auditoria

  • integridade

  • alta disponibilidade

  • segurança

Esses conhecimentos não desaparecem.

Eles tornam você um profissional muito mais completo.

Recursos para continuar estudando

Além dos fundamentos de Java, vale explorar materiais específicos sobre Java no ecossistema IBM Z.

Java no CICS

Artigos técnicos

Open Liberty

IBM Semeru Runtime

IBM z/OS Connect

LinuxONE

Automação

IA para IBM Z

Um café antes de partir...

Se existe uma mensagem que todo Padawan COBOL deve levar deste artigo, é esta:

Você não está mudando de profissão. Está ampliando sua stack.

O COBOL continua sendo o coração de milhares de sistemas críticos. O Java tornou-se a ponte que conecta esse legado ao mundo das APIs, aplicativos móveis, microsserviços, cloud híbrida e inteligência artificial. Tecnologias como z/OS Connect, LinuxONE, Open Liberty, Ansible e watsonx não substituem décadas de conhecimento acumulado; elas o potencializam.

O profissional mais disputado da próxima década não será apenas o especialista em COBOL nem apenas o especialista em Java. Será aquele capaz de unir os dois mundos, preservando a confiabilidade do legado enquanto entrega inovação com velocidade. Esse é o verdadeiro espírito da Stack Mainframe: tradição e modernização trabalhando lado a lado. E essa jornada começa aprendendo Java, mas nunca esquecendo as lições que o Mainframe ensinou.

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

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.


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

sexta-feira, 24 de abril de 2026

💣🔥 API REST no Mainframe — QUANDO O COBOL VIROU BACKEND DE APLICATIVO SEM PEDIR LICENÇA

Bellacosa Mainframe um pequeno exemplo de API REST no Mainframe


💣🔥 API REST no Mainframe — QUANDO O COBOL VIROU BACKEND DE APLICATIVO SEM PEDIR LICENÇA

Se você ainda acha que COBOL só roda batch, prepara o choque:
com z/OS Connect, seu programa vira API REST consumida por mobile, web e cloud.

🚀 O que é o z/OS Connect (explicado sem enrolação)

👉 É o “tradutor oficial” entre:

  • 🌐 Mundo moderno (REST / JSON)
  • 🏦 Mundo legado (COBOL / CICS / IMS)

Ele roda no z/OS e conversa direto com:

  • CICS
  • IMS

💣 Tradução Bellacosa:

“Ele pega um GET/POST da internet e transforma em chamada de programa COBOL… e volta como JSON.”

🧠 Arquitetura (visão de guerra)

Fluxo real:

📱 Mobile / Web
        ↓
🌐 API REST (HTTP/JSON)
        ↓
🔌 z/OS Connect
        ↓
🧠 CICS / IMS
        ↓
💾 COBOL
        ↓
📦 Dados (Db2 / VSAM / EzNoSQL)

🧪 Exemplo prático (nível COBOL júnior)

🎯 Cenário

Você tem um programa COBOL que consulta saldo.

🧩 1. COBOL (legado)

       IDENTIFICATION DIVISION.
       PROGRAM-ID. SALDO01.

       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01 WS-CONTA    PIC 9(10).
       01 WS-SALDO    PIC 9(10)V99.

       PROCEDURE DIVISION.
           MOVE 12345 TO WS-CONTA
           MOVE 1500.75 TO WS-SALDO
           DISPLAY "SALDO: " WS-SALDO
           STOP RUN.

🌐 2. API REST exposta

GET /api/saldo/12345

🔁 3. Resposta JSON

{
  "conta": "12345",
  "saldo": 1500.75
}

💣 Sem reescrever COBOL
💣 Sem migrar sistema
💣 Só expondo via z/OS Connect

⚙️ Como funciona por dentro (o pulo do gato)

O z/OS Connect usa:

  • Service Definition (SAR) → define entrada/saída
  • Data Mapping → JSON ↔ estrutura COBOL
  • Runtime Liberty (Java) → engine REST

👉 Ele faz o binding automático entre:

JSON ↔ Copybook COBOL

🔐 Segurança nível banco

Tudo integrado com:

  • RACF
  • TLS / HTTPS
  • Controle de identidade

💣 Diferente de API na cloud:
👉 aqui segurança já nasce pronta

🚀 Vantagens (o que faz isso ser absurdo)

⚡ Modernização instantânea

Seu COBOL vira backend REST

💰 Economia brutal

Sem reescrever sistema legado

🔗 Integração total

Funciona com:

  • mobile
  • fintech
  • cloud
  • parceiros

🧩 Plugável com EzNoSQL

Sim, o combo fica insano:

👉 API REST + JSON + mainframe
👉 💣 arquitetura híbrida real

⚠️ Desvantagens (real talk)

❌ Setup inicial não é trivial

Precisa entender:

  • contratos
  • mapping
  • deploy

❌ Debug pode confundir iniciante

Problema pode estar em:

  • JSON
  • mapping
  • COBOL
  • CICS

🧠 Curiosidades (nível insider)

💡 Muitas fintechs usam isso escondido
👉 API moderna… backend COBOL

💡 Você pode versionar APIs
👉 v1, v2 sem quebrar legado

💡 Integra com Swagger/OpenAPI
👉 documentação automática

🥚 Easter Egg

💣 O maior hack corporativo:

Empresas dizem:

👉 “Somos cloud-native”

Mas o core…

👉 ainda é COBOL exposto via z/OS Connect 😎

🧠 Insight que muda carreira

👉 Aprender isso te coloca à frente de 90% dos devs COBOL

Porque você passa a ser:

💣 Dev de integração + legado + API

🚀 Conclusão

O z/OS Connect é a ponte definitiva:

👉 passado (COBOL)
👉 presente (REST)
👉 futuro (cloud híbrida)

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