 |
| Bellacosa Mainframe e o Mainframe Evolution |
☕ Um Café no Bellacosa Mainframe
🧟 Mainframe Evolution — O Pesadelo Open Source que Entrou na LPAR
Segurança, observabilidade e escala no IBM Z, investigadas sob a ótica de Dylan Dog, o Investigador do Pesadelo
Há casos que chegam ao escritório de Dylan Dog embrulhados em jornais velhos, acompanhados por fotografias borradas e pelo depoimento de alguma testemunha dizendo ter visto uma criatura impossível atravessar a parede à meia-noite.
Este caso chegou de maneira ainda mais suspeita.
Em uma apresentação apareceu a frase:
Mainframe Evolution: Securing, Monitoring, and Scaling with Next-Gen Open Source
Dylan olhou para o papel.
Groucho olhou para Dylan.
— Chefe, acho que descobriram algo mais antigo que os vampiros.
— O quê?
— COBOL.
Silêncio.
Em algum lugar distante, uma fita magnética girou sozinha.
Bem-vindo a mais uma investigação do Bellacosa Mainframe.
Desta vez nosso cliente afirma que existe open source dentro do mainframe.
Para muitos programadores, isso parece perfeitamente normal em 2026.
Para outros, principalmente aqueles que ainda imaginam o mainframe como uma fortaleza isolada onde todos entram pelo TSO e qualquer alteração precisa de três formulários, dois CABs e o sangue de um analista de produção, a afirmação parece paranormal.
Dylan Dog foi chamado.
Vamos investigar.
🕵️ CAPÍTULO 1 — O cadáver que se recusava a morrer
A primeira coisa que chamou a atenção de Dylan foi a idade da vítima.
O mainframe já havia sido declarado morto tantas vezes que seu prontuário parecia uma coleção de obituários.
Client/server iria matá-lo.
Depois Unix.
Depois Windows.
Depois servidores x86.
Depois Java.
Depois a Web.
Depois cloud.
Depois containers.
Depois Kubernetes.
Agora inteligência artificial.
Dylan abriu o arquivo.
STATUS: EXECUTING.
— Estranho — comentou ele.
Muito estranho.
Talvez estivéssemos procurando o cadáver errado.
Porque o IBM Z moderno não é simplesmente um computador gigantesco escondido no porão executando programas COBOL escritos quando os Beatles ainda tocavam juntos.
Ele é uma plataforma capaz de reunir tecnologias de gerações muito diferentes.
Podemos encontrar algo parecido com:
IBM Z
│
┌──────────┼──────────┐
│ │ │
z/OS Linux z/VM
│ │ │
COBOL Python Virtualização
CICS Java
IMS Open Source
Db2 Containers
MQA primeira pista estava diante de Dylan.
Talvez evolução do mainframe não significasse substituição.
Significasse incorporação.
🧟 CAPÍTULO 2 — Frankenstein não precisava morrer
Existe uma velha tentação em tecnologia.
Quando encontramos algo antigo, imediatamente pensamos:
"Precisamos substituir isso."
Imagine um banco possuindo milhões de linhas COBOL responsáveis por contas, cartões, pagamentos, empréstimos e liquidação financeira.
Alguém entra na reunião e anuncia:
— Temos uma ideia revolucionária! Vamos reescrever tudo!
Dylan provavelmente perguntaria:
— Por quê?
Essa é uma excelente pergunta.
Modernização não significa obrigatoriamente:
COBOL
↓
JavaMuito menos:
MAINFRAME
↓
CLOUDPodemos modernizar ao redor da aplicação:
Git
│
VS Code ───► COBOL ◄─── CI/CD
│
Testing
│
Security Scan
│
APIs
│
ObservabilityO programa continua COBOL.
A lógica continua executando no z/OS.
CICS continua administrando transações.
Db2 continua guardando dados.
RACF continua controlando acessos.
Mas a maneira como desenvolvemos, testamos, implantamos, observamos e integramos essas aplicações pode mudar radicalmente.
Nosso monstro de Frankenstein não precisava ser destruído.
Precisávamos apenas entender como ele funcionava.
🔐 CAPÍTULO 3 — SECURING: alguém abriu novas portas no castelo
Dylan chegou à primeira cena do crime.
Uma enorme fortaleza.
Sobre o portão estava escrito:
RACFNada particularmente assustador.
O mainframe conhece controle de acesso há décadas.
Usuários possuem identidades.
Recursos possuem regras.
Datasets podem ser protegidos.
Transações CICS podem ser protegidas.
Recursos do sistema podem ser protegidos.
Aplicações podem ser protegidas.
Então apareceu o open source.
Depois vieram APIs.
CLI.
VS Code.
Git.
Jenkins.
Zowe.
Containers.
OpenShift.
Linux.
Cloud.
Service accounts.
Automação.
De repente, nosso castelo ganhou dezenas de portas.
IBM Z
│
┌────────────────┼────────────────┐
│ │ │
API CLI IDE
│ │ │
Jenkins Zowe VS Code
│
CI/CDNenhuma dessas tecnologias é inerentemente um problema.
O problema aparece quando adicionamos conectividade sem adicionar governança.
👻 CAPÍTULO 4 — O fantasma das credenciais
Groucho apareceu segurando um papel.
— Dylan, encontrei a senha.
— Onde?
— No script.
Isso é exatamente o tipo de fantasma que ninguém quer encontrar.
Imagine:
USER=DEPLOY01
PASSWORD=SUPERSECRET123dentro de um script versionado.
Ou um token esquecido em um arquivo de configuração.
Ou uma service account com privilégios maiores que o necessário.
Automação multiplica produtividade.
Mas também pode multiplicar erros.
Um humano pode cometer um erro uma vez.
Um pipeline consegue cometer o mesmo erro automaticamente quinhentas vezes antes do café.
Por isso modernização exige pensar em:
Identity
Authentication
Authorization
Certificates
TLS
Secrets
Tokens
Audit
Least Privilege
API Security
LoggingO velho princípio continua válido:
Quem é você, o que você pode fazer e quem registrará que você fez?
RACF não ficou obsoleto porque apareceu DevOps.
Na verdade, DevOps torna essas perguntas ainda mais importantes.
🧪 CAPÍTULO 5 — Zowe entra na investigação
Dylan encontrou outra inscrição:
ZOWE
Aqui encontramos uma das pontes mais interessantes entre o mainframe tradicional e ferramentas modernas.
Imagine nosso jovem programador COBOL.
Ele conhece:
Git
VS Code
Terminal
REST
JSON
CLIEntão alguém apresenta:
TSO
ISPF
SDSF
JCL
3270Nada disso é ruim.
Mas existe uma curva de aprendizagem.
Uma proposta importante do Zowe é permitir interfaces familiares ao desenvolvedor moderno para interação com o ecossistema z/OS.
Simplificando bastante:
VS Code ──────┐
│
CLI ──────────┤
│
REST ─────────┼──► Zowe ───► z/OS
│
Scripts ──────┤
│
Automation ───┘Isso não significa abolir ISPF.
Nem significa transformar z/OS em Linux.
Significa criar novas maneiras de conversar com a plataforma.
Dylan anotou:
O suspeito não destruiu a porta antiga. Construiu outra entrada.
👁️ CAPÍTULO 6 — MONITORING: o mainframe sempre esteve olhando
Aqui nossa investigação fica especialmente interessante.
O mundo distribuído descobriu recentemente uma palavra maravilhosa:
observability.
Logs!
Metrics!
Traces!
Dashboards!
Alertas!
Dylan quase sorriu.
Porque no porão do mainframe encontrou arquivos muito mais antigos:
SMF
RMF
SYSLOG
OPERLOG
WLM
CICS Statistics
Db2 Accounting
IMS Logs
MQ StatisticsO mainframe sempre produziu uma quantidade extraordinária de informações operacionais.
Então qual é a novidade?
Correlação.
🔎 CAPÍTULO 7 — O cliente não sabe o que é uma LPAR
Imagine Maria pagando R$100 usando o celular.
Para ela:
CELULAR
↓
PAGAMENTOSimples.
Agora acompanhemos o que pode acontecer por trás:
Mobile App
↓
Internet
↓
API Gateway
↓
OpenShift
↓
Java
↓
MQ
↓
z/OS Connect
↓
CICS
↓
COBOL
↓
Db2Maria liga:
— Meu pagamento demorou.
Ela não diz:
"Observei um aumento no response time da transaction class associada ao CICS."
Seria fantástico se dissesse.
Mas não diz.
Ela quer saber por que o botão demorou.
A empresa precisa investigar a transação inteira.
Esse é o grande salto entre simplesmente monitorar componentes e observar serviços distribuídos.
🔦 CAPÍTULO 8 — A lanterna chamada Trace ID
Dylan coloca uma etiqueta na vítima:
TRACE-ID: BELLACOSA-0317Agora imagine essa identificação acompanhando a solicitação:
APP
│
│ 0317
▼
API
│
│ 0317
▼
OPENSHIFT
│
│ 0317
▼
MQ
│
│ 0317
▼
CICS
│
│ 0317
▼
COBOL
│
│ 0317
▼
DB2Agora temos uma investigação de verdade.
Podemos descobrir:
APP 120 ms
API 80 ms
OPENSHIFT 90 ms
MQ 40 ms
CICS 70 ms
COBOL 20 ms
DB2 3.900 msA aplicação demorou aproximadamente 4,3 segundos.
E finalmente encontramos o suspeito.
Não era COBOL.
Era uma consulta no banco.
O pobre COBOL estava sendo acusado porque morava no bairro errado.
🩸 CAPÍTULO 9 — OpenTelemetry encontra SMF
Aqui existe uma possibilidade particularmente fascinante.
De um lado temos o universo tradicional:
SMF
RMF
WLM
CICS
Db2
IMS
MQDo outro:
OpenTelemetry
Prometheus
Grafana
Elastic
OpenSearch
JaegerHistoricamente eles podem parecer dois mundos.
Mas uma aplicação empresarial moderna pode atravessar ambos.
Portanto, o verdadeiro objetivo passa a ser:
BUSINESS TRANSACTION
│
┌─────────────┴─────────────┐
│ │
DISTRIBUTED WORLD MAINFRAME
│ │
OpenTelemetry SMF
Prometheus RMF
Containers WLM
Kubernetes CICS
APIs Db2
│ │
└─────────────┬─────────────┘
│
OBSERVABILITYAgora podemos começar a responder não apenas:
"A CPU está boa?"
Mas:
"Por que o cliente não conseguiu concluir a compra?"
Essa segunda pergunta vale dinheiro.
📈 CAPÍTULO 10 — SCALING: o monstro começou a crescer
Nosso terceiro mistério é escala.
Alguém poderia dizer:
— Finalmente Kubernetes ensinará mainframe a escalar!
Nesse momento talvez Dylan pedisse para Groucho retirar a pessoa da sala.
Mainframes foram construídos justamente para executar workloads enormes.
z/OS possui uma longa história de administração sofisticada de workloads.
Temos conceitos como:
LPAR
WLM
Parallel Sysplex
Coupling Facility
Capacity
Workload ManagementO que mudou foi o ambiente ao redor.
Imagine:
INTERNET
│
LOAD BALANCER
│
┌────────┼────────┐
│ │ │
POD POD POD
│ │ │
└────────┼────────┘
│
MQ
│
CICS
│
COBOL
│
DB2Kubernetes pode aumentar pods.
Ótimo.
Mas isso não significa capacidade infinita.
☠️ CAPÍTULO 11 — O horror do autoscaling cego
Aqui mora um monstro interessante.
Suponhamos:
3 PODSO sistema detecta carga elevada.
Então:
3 → 6 → 12 → 24 → 48 PODSFantástico!
Exceto que todos atacam o mesmo backend.
48 PODS
│
│
▼
MQ
│
▼
CICS
│
▼
DB2Escalar frontend sem compreender backend pode simplesmente produzir um ataque DDoS patrocinado pela própria empresa.
Essa é uma das grandes lições de arquitetura híbrida.
Precisamos compreender:
throughput;
concorrência;
filas;
limites;
CPU;
I/O;
locks;
conexões;
response time;
prioridades;
capacidade do backend.
Escalabilidade não significa "crie mais coisas".
Significa administrar capacidade do sistema completo.
🐧 CAPÍTULO 12 — Há um pinguim no porão
Dylan ouviu um barulho.
Desceu mais um andar.
Encontrou Linux.
Sim, Linux no mainframe.
Essa confusão ainda existe:
MAINFRAME = z/OSNão exatamente.
IBM Z pode hospedar diferentes ambientes e workloads.
Podemos pensar conceitualmente em:
IBM Z
│
├── z/OS
│ ├── COBOL
│ ├── CICS
│ ├── IMS
│ └── Db2
│
├── Linux on Z
│ ├── Java
│ ├── Python
│ └── Open Source
│
└── Virtualização
├── z/VM
└── outros ambientes suportadosIsso muda completamente a imagem mental de "computador antigo".
O hardware permanece centralizado e extremamente robusto.
O ecossistema de software, entretanto, tornou-se bastante heterogêneo.
🔧 CAPÍTULO 13 — DevOps encontra COBOL
Nosso programador iniciante agora recebe uma missão.
Modificar:
CUSTOMER.cblNo fluxo tradicional poderia acontecer:
ISPF
↓
EDIT
↓
JCL
↓
COMPILE
↓
LINK
↓
TESTEsse fluxo continua perfeitamente válido em muitos ambientes.
Mas podemos criar:
VS Code
↓
Git
↓
Commit
↓
Pull Request
↓
Automated Build
↓
Unit Test
↓
Security Scan
↓
Deploy
↓
MonitoringObserve o detalhe.
Em nenhum momento fomos obrigados a escrever:
rm CUSTOMER.cblO COBOL continua lá.
Mudamos o software delivery lifecycle.
Essa diferença é fundamental.
🧠 CAPÍTULO 14 — O erro clássico: confundir modernização com linguagem
Dylan encontra finalmente uma testemunha.
— Eu vi tudo! Modernizaram o sistema!
— Como?
— Converteram COBOL para Java!
Dylan fecha o bloco de notas.
Isso pode ser modernização.
Mas não é a definição de modernização.
Um programa COBOL pode estar integrado a:
Git
CI/CD
Automated Tests
APIs
Modern IDE
Observability
Security Automation
AI AssistanceEnquanto um programa Java pode viver em:
FTP
manual deployment
no tests
hardcoded passwords
no monitoring
no documentationQual dos dois é realmente "legado"?
A linguagem não responde sozinha.
Processo, arquitetura, governança e manutenibilidade importam enormemente.
🕸️ CAPÍTULO 15 — O verdadeiro monstro é a complexidade
Depois de horas investigando, Dylan percebe algo.
Não existe apenas um assassino.
Existe uma teia.
USER
│
APP
│
API
│
KUBERNETES
│
MQ
│
z/OS CONNECT
│
CICS
│
COBOL
│
DB2Cada camada possui:
Security
Monitoring
Configuration
Capacity
Networking
Logging
Authentication
Authorization
Versioning
DependenciesÉ aqui que open source pode ajudar muito.
Mas também é onde ele pode criar problemas se for adotado simplesmente porque "todo mundo usa".
Open source não elimina complexidade.
Às vezes ele democratiza ferramentas para administrá-la.
E às vezes adiciona outra camada.
Arquitetura continua exigindo engenharia.
🧰 CAPÍTULO 16 — O arsenal do Investigador do Pesadelo
Se Dylan Dog fosse engenheiro de plataforma IBM Z, sua mala talvez tivesse:
┌─────────────────────────────┐
│ DYLAN DOG TOOLBOX │
├─────────────────────────────┤
│ RACF → Security │
│ SMF → Evidence │
│ RMF → Performance │
│ WLM → Workloads │
│ SDSF → Operations │
│ Zowe → Integration │
│ Git → Versioning │
│ CI/CD → Automation │
│ OTel → Tracing │
│ Grafana → Visualization │
│ Linux → Open ecosystem │
└─────────────────────────────┘Mas ferramentas não resolvem crimes sozinhas.
Precisamos saber que pergunta fazer.
🎓 CAPÍTULO 17 — O novo programador mainframe
Talvez esta seja a maior transformação.
Durante décadas uma trilha de formação poderia começar assim:
3270
↓
TSO
↓
ISPF
↓
JCL
↓
COBOL
↓
VSAM
↓
CICS
↓
DB2Eu ainda ensinaria essa base.
Porque abstração sem fundamento produz profissionais que sabem apertar botões, mas não entendem o que acontece quando o botão falha.
Porém acrescentaria outra coluna:
MAINFRAME CLÁSSICO ENGENHARIA MODERNA
TSO/ISPF VS Code
JCL Pipelines
COBOL Git
CICS APIs
Db2 Observability
RACF IAM concepts
SDSF Automation
SMF Telemetry
USS Open SourceNão são inimigos.
São camadas de conhecimento.
O profissional interessante do futuro sabe atravessar essa ponte.
🧟 CAPÍTULO 18 — E a inteligência artificial?
Naturalmente nosso monstro mais recente aparece.
IA pode ajudar a:
explicar COBOL
gerar documentação
analisar dependências
sugerir testes
interpretar mensagens
auxiliar debugging
explicar JCL
produzir scripts
examinar código legadoFantástico.
Mas existe uma regra Dylan Dog para isso:
Não confie no monstro apenas porque ele fala educadamente.
Código gerado precisa ser revisado.
JCL precisa ser entendido.
Sugestões precisam ser validadas.
Segurança precisa permanecer sob controle.
Imagine uma IA sugerindo:
PERMIT * CLASS(DATASET) ACCESS(ALTER)e alguém respondendo:
"A inteligência artificial recomendou."
Nesse momento o verdadeiro terror começou.
IA deve aumentar a capacidade do engenheiro.
Não abolir julgamento técnico.
🕯️ CAPÍTULO 19 — O Easter Egg das 03:17
Às 03:17, todos os dashboards ficaram vermelhos.
CPU?
Normal.
Storage?
Normal.
CICS?
UP.
Db2?
UP.
MQ?
UP.
Kubernetes?
Healthy.
O operador escreveu:
03:17:22 - USERS REPORTING PAYMENT TIMEOUTDylan olhou para o dashboard.
Tudo verde.
Olhou novamente para o cliente.
Tudo quebrado.
E finalmente percebeu o verdadeiro pesadelo:
Todos monitoravam componentes. Ninguém monitorava a experiência completa.
O sistema poderia estar tecnicamente saudável enquanto o serviço estava funcionalmente morto.
Essa talvez seja a melhor explicação de por que observabilidade tornou-se tão importante.
🧩 CAPÍTULO 20 — Security + Monitoring + Scaling
Finalmente podemos retornar ao título:
Securing
Garantir que as novas portas abertas pela modernização não destruam décadas de controles.
Monitoring
Sair da visão isolada do componente e compreender a transação ponta a ponta.
Scaling
Fazer ambientes distribuídos e mainframe responderem à demanda sem simplesmente transferir o gargalo de uma camada para outra.
E existe um quarto elemento escondido:
Integrating
Porque todos os anteriores dependem dele.
MAINFRAME EVOLUTION
│
┌──────────────┼──────────────┐
│ │ │
SECURITY OBSERVABILITY SCALE
│ │ │
└──────────────┼──────────────┘
│
INTEGRATION
│
OPEN SOURCE
│
AUTOMATION
│
IBM Z☕ EPÍLOGO — Dylan fecha o caso
O sol começava a nascer.
Groucho trouxe café.
Dylan fechou a pasta.
Na capa escreveu:
CASE CLOSED?
Depois riscou o ponto de interrogação.
E tornou a colocá-lo.
Porque sistemas nunca ficam realmente prontos.
Eles evoluem.
O ponto central de Mainframe Evolution: Securing, Monitoring, and Scaling with Next-Gen Open Source não precisa ser interpretado como uma guerra entre dois mundos.
Não é:
MAINFRAME
VS
OPEN SOURCETambém não é:
OLD
↓
DELETE
↓
NEWÉ algo muito mais interessante:
60+ ANOS DE ENGENHARIA
│
▼
IBM Z
│
┌─────────┼─────────┐
│ │ │
z/OS Linux Open Source
│ │ │
COBOL/CICS Apps Tools
Db2/IMS/MQ Cloud Automation
│ │ │
└─────────┼─────────┘
│
APIs
│
Git
│
CI/CD
│
Observability
│
Security
│
AI
│
▼
MODERN ENTERPRISEE isso nos conduz a uma conclusão deliciosa para alguém que trabalha com mainframe.
Durante décadas perguntaram:
"Quando o mainframe vai morrer?"
Talvez a pergunta estivesse errada.
A pergunta mais interessante em 2026 é:
"Quantas tecnologias novas o mainframe ainda conseguirá absorver sem deixar de ser mainframe?"
Até agora, a resposta parece ser:
muitas.
Talvez seja exatamente isso que explique sua longevidade.
O mainframe não sobreviveu apesar das mudanças.
Em boa medida, sobreviveu porque aprendeu a incorporá-las.
Dylan Dog saiu do data center.
As luzes se apagaram.
Uma última mensagem apareceu no console:
IEF404I BELLACOSA - ENDED - TIME=04.17.00Groucho olhou para a tela.
— Então o monstro morreu?
Dylan vestiu o casaco.
— Não.
— E agora?
Ao fundo, outra mensagem apareceu:
$HASP100 BELLACOSA ON READERO JOB seguinte acabara de entrar.
☕ Bellacosa Mainframe — porque no mainframe até os fantasmas têm retrocompatibilidade.
