Translate

sexta-feira, 26 de junho de 2026

Como um Padawan COBOL Pode Entender Agentes, MLOps e IA Generativa Sem Abandonar o IBM Z

 

Bellacosa Mainframe apresenta como entender ia generativas e agentes

☕ O Holocron do Ecossistema de IA Moderna

Como um Padawan COBOL Pode Entender Agentes, MLOps e IA Generativa Sem Abandonar o IBM Z

"O Mainframe nunca esteve atrasado. Apenas esperou pacientemente que o restante da indústria redescobrisse conceitos que ele domina há cinquenta anos."

Bellacosa Mainframe

Introdução – O dia em que percebi que um GPT era apenas um programa CICS muito falante

Se você é um Padawan COBOL, provavelmente abriu o LinkedIn nos últimos meses e viu dezenas de especialistas dizendo coisas como:

"Você precisa aprender IA."

"Agentes vão substituir desenvolvedores."

"Prompt Engineering é a nova programação."

"Os modelos estão ficando commodities."

E talvez tenha pensado:

"Mas eu passei anos aprendendo COBOL, JCL, VSAM, CICS, Db2, RACF, JES2 e agora preciso jogar tudo fora para estudar agentes?"

A resposta curta é:

Não.

Na verdade, existe uma boa notícia.

Talvez você seja muito mais preparado para a era Agentic AI do que imagina.

O Grande Equívoco Sobre Inteligência Artificial

Muitas pessoas ainda acreditam que IA é isto:

Usuário

↓

ChatGPT

↓

Resposta

↓

Fim

Essa visão é tão simplificada quanto dizer que um banco consiste apenas em um programa COBOL.

Nós sabemos que não é assim.

Num banco real existem:

JES2

Control-M

RACF

Db2

MQ

CICS

VSAM

SMF

RMF

Schedulers

Catálogos

Auditoria

Backup

Monitoramento

A IA corporativa está seguindo exatamente o mesmo caminho.

Um LLM sozinho é inteligente.

Mas também é limitado.

Ele:

Não executa transações;

Não conhece dados internos;

Não lembra clientes;

Não acessa CICS;

Não consulta Db2;

Não abre chamados;

Não aprova empréstimos;

Não faz deploy.

Ele é apenas um cérebro.

O restante precisa ser construído.

O Ecossistema Moderno de IA

A indústria começou a perceber que IA não é um produto.

IA é um ecossistema.

Uma pilha arquitetural.

Podemos imaginar algo semelhante:

Agentic AI

Workflow

MLOps

Intelligence

Data Foundation

Curiosamente, um profissional IBM Z olha para isso e pensa:

"Eu já vi algo parecido antes."

Porque viu.

Durante décadas.

Primeira Camada – Data Foundation

Esta deveria ser a base absoluta.

Sem dados não existe IA.

E dados ruins produzem IA ruim.

Garbage In.

Garbage Out.

Nada mudou.

Apenas ficou mais caro.

O que existe aqui?

Db2

IMS

VSAM

Oracle

Postgres

Kafka

Data Lakes

Data Catalogs

Feature Stores

Embeddings

Vector Databases

Um exemplo bancário

Imagine um banco.

Possui:

40 milhões clientes

15 anos histórico

Cartões

PIX

Seguros

CRM

GPT não sabe nada disso.

Ele conhece apenas internet.

Precisamos ensinar.

Entra o conceito de:

RAG

Retrieval Augmented Generation

Funciona assim:

Pergunta

↓

Embeddings

↓

Busca vetorial

↓

Documentos internos

↓

LLM

↓

Resposta

Exemplo:

Cliente pergunta:

"Quanto falta para quitar meu financiamento?"

Agente consulta.

Db2.

Documentos.

Extratos.

Contratos.

Depois responde.

O paralelo Mainframe

Padawan COBOL rapidamente percebe:

RAG é quase um READ em uma memória extremamente sofisticada.

Segunda Camada – Core Intelligence

Aqui moram os modelos.

GPT

Claude

Gemini

Mistral

Llama

DeepSeek

Também existem:

Speech

Computer Vision

OCR

Recomendadores

Machine Learning

Reinforcement Learning

Generative AI

É a interface moderna.

Antigamente:

Tela verde.

PF3.

COMMAREA.

Hoje:

Chat.

Áudio.

Imagem.

Agentes.

Copilots.

Reasoning Models

Uma novidade importante.

Os modelos não apenas completam frases.

Eles planejam.

Dividem tarefas.

Analisam.

Validam.

Exemplo.

Padawan pergunta:

"Como migrar VSAM para PostgreSQL?"

Modelo:

Analisa.

Calcula.

Sugere.

Documenta.

Estima esforço.

Terceira Camada – Workflow

Aqui a mágica começa.

É a camada esquecida.

Mas talvez seja a mais importante.

Ferramentas:

n8n

LangGraph

CrewAI

AutoGen

Semantic Kernel

Temporal

Imagine um processo.

Cliente solicita empréstimo.

↓

Agente Planejador

↓

Agente Crédito

↓

Agente Fraude

↓

Agente Compliance

↓

Agente Aprovação

↓

Supervisor

↓

Resposta

Padawan COBOL imediatamente percebe:

Isso parece um scheduler.

E parece mesmo.

JES2.

Control-M.

CA7.

IWS.

Jobtrac.

São praticamente ancestrais dos workflows cognitivos.

Quarta Camada – MLOps

Se existe uma disciplina que lembra Sysprog Mainframe é MLOps.

Deploy.

Rollback.

Monitoramento.

Versionamento.

Observabilidade.

Ferramentas.

MLFlow.

Kubeflow.

Ray.

KServe.

Argo.

Exemplo.

Modelo fraude.

Janeiro.

97% acurácia.

Março.

88%.

Abril.

79%.

Por quê?

Mudou comportamento clientes.

PIX.

Golpes.

Novas técnicas.

MLOps detecta.

Treina novamente.

Padawan percebe:

É quase RUNSTATS.

REORG.

REBIND.

Statistics.

Só que para modelos.

Quinta Camada – Agentic AI

Aqui está a revolução.

E talvez a maior oportunidade profissional da década.

Um chatbot responde.

Um agente trabalha.

Agente possui:

Objetivos.

Ferramentas.

Memória.

Planejamento.

Autonomia.

Capacidade execução.

Exemplo.

Agente RH.

Recebe CV.

Classifica.

Agenda entrevista.

Consulta Teams.

Envia email.

Produz resumo.

Armazena histórico.

Tudo sozinho.

Multi-Agent Systems

Especialização.

Assim como empresas.

Agente Jurídico.

Agente Segurança.

Agente Mainframe.

Agente Cobol.

Agente Arquitetura.

Agente FinOps.

Supervisor coordena.

Como um gerente.

O Que a Imagem Não Mostra

Existem duas camadas ausentes.

Governança

Fundamental.

LGPD.

GDPR.

Auditoria.

RBAC.

IAM.

Policies.

Approval Gates.

Quem aprovou?

Quem executou?

Quem auditou?

Quem pagou?

Quem autorizou?

Infraestrutura

GPU.

TPU.

CPU.

OpenShift.

Kubernetes.

IBM z17.

LinuxONE.

Cloud.

O IBM Z Sempre Esteve Preparado

Talvez a maior surpresa seja esta.

IBM Z nunca esteve distante da IA.

Ele apenas utilizava nomes diferentes.

IA ModernaIBM Z
WorkflowJES2
ObservabilidadeRMF
LogsSMF
SegurançaRACF
APIsz/OS Connect
EventosMQ
SchedulerIWS
GovernançaSAF
CI/CDDBB
MemóriaDb2
AgentesServiços especializados
Inferênciawatsonx

O Conselho Final para um Padawan COBOL

Se você está começando agora, não tente aprender tudo.

Estude em etapas.

Etapa 1

Entenda LLMs.

GPT.

Claude.

Embeddings.

RAG.

Etapa 2

Aprenda LangGraph.

CrewAI.

n8n.

Etapa 3

Entenda MLOps.

MLFlow.

Observabilidade.

Etapa 4

Integre Mainframe.

MQ.

z/OS Connect.

Db2.

Etapa 5

Construa agentes.

Agente COBOL.

Agente JCL.

Agente Db2.

Agente CICS.

O Holocron Final

Durante anos ouvimos que o Mainframe era uma tecnologia do passado.

Em 2026 começamos a perceber algo curioso.

A indústria inteira está reconstruindo conceitos que os profissionais IBM Z já conheciam muito bem:

  • Orquestração;

  • Governança;

  • Observabilidade;

  • Segurança;

  • Processamento confiável;

  • Execução transacional;

  • Gestão de workloads;

  • Auditoria completa.

A IA moderna não está eliminando o conhecimento dos veteranos do IBM Z.

Ela está valorizando exatamente aquilo que sempre diferenciou os melhores arquitetos de mainframe: a capacidade de pensar em ecossistemas complexos, sistemas resilientes, processos críticos e plataformas que funcionam vinte e quatro horas por dia sem margem para erros.

Talvez o futuro não pertença apenas aos construtores do maior modelo de linguagem.

Talvez pertença aos velhos Jedi do IBM Z que finalmente descobriram que seus holocrons sempre falaram sobre agentes, apenas utilizando nomes diferentes.

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

quinta-feira, 25 de junho de 2026

☕ O ABEND da Migração Mágica: Quando a IA Generativa Descobre que o Mainframe Não é Apenas um Arquivo COBOL

Bellacosa Mainframe quando a magia da migração via ia do mainframe falha


☕ O ABEND da Migração Mágica: Quando a IA Generativa Descobre que o Mainframe Não é Apenas um Arquivo COBOL

O Dia em que o Mercado Percebeu que o ChatGPT Não Conhece o Batch das 02h17

Existe um momento na carreira de todo profissional de Mainframe em que ele aprende uma lição importante.

A primeira é que JCL não foi criado para ser bonito.

A segunda é que ninguém documenta adequadamente um scheduler.

A terceira é que sempre haverá alguém chegando com um PowerPoint dizendo:

— Vamos aposentar o Mainframe em doze meses.

Nos últimos vinte anos ouvi essa frase tantas vezes quanto mensagens $HASP373, IEC161I ou aquele clássico telefonema de sexta-feira às 18h:

— Bellacosa, caiu a produção.

Recentemente, entretanto, surgiu um ingrediente novo nessa antiga receita corporativa.

A Inteligência Artificial Generativa.

E, junto dela, uma nova promessa digna dos antigos alquimistas digitais:

"Nossa IA converte milhões de linhas COBOL para Java automaticamente."

"Seu CICS vira microsserviços em poucos cliques."

"Seu VSAM agora é PostgreSQL."

"Seu batch vira Kubernetes."

"Seu legado desaparece em seis meses."

Foi justamente nesse contexto que a Gartner publicou uma análise que talvez represente um dos maiores banhos de água fria já aplicados no mercado de migração de Mainframe.

Segundo a consultoria, mais de 70% dos projetos de saída do Mainframe iniciados em 2026 não entregarão os benefícios esperados.

E o motivo é simples.

As pessoas estão superestimando o que a IA realmente sabe fazer.

E subestimando brutalmente o que um ambiente IBM Z realmente é.

O Maior Equívoco da Década: Achar que Mainframe é Apenas COBOL

Quando alguém diz:

— Temos cinquenta milhões de linhas COBOL.

Meu primeiro pensamento nunca é sobre COBOL.

Meu primeiro pensamento é:

Quantos schedulers existem?

Quantos GDGs?

Quantos catálogos?

Quantos exits?

Quantos produtos ISV?

Quantos jobs dependem de um único arquivo VSAM aberto em RLS?

Porque o código é apenas a ponta visível do iceberg.

Abaixo da linha d'água vivem criaturas muito mais antigas e perigosas.

CA-7.

Control-M.

ESP.

Zeke.

NetView.

RACF.

DFSMS.

SMF.

RMF.

MQ.

WLM.

CICSplex.

IMS.

DB2 Packages.

Plan Stability.

PassTickets.

SAF.

Exit routines escritas em Assembler por alguém que se aposentou em 2009 e hoje cultiva orquídeas em Campinas.

A IA consegue interpretar um trecho como:

IF SALDO > LIMITE
   MOVE 'BLOQUEAR' TO ACAO
END-IF

Ela pode até gerar um Java elegante.

Mas dificilmente responderá perguntas como:

Por que esse programa executa apenas às terças-feiras?

Por que ele depende do fechamento do SMF?

Por que aguarda um arquivo SWIFT vindo da Bélgica?

Por que existe um passo IEBGENER aparentemente inútil?

Por que um job precisa terminar antes das 02h17?

E principalmente:

Quem será responsabilizado se o PIX parar durante duas horas?

O Conhecimento Tribal: A Tecnologia Mais Difícil de Migrar

Costumo dizer aos alunos do Bellacosa Mainframe:

O ativo mais caro de um banco não é o hardware.

Não é o software.

Nem mesmo os dados.

É o conhecimento acumulado por pessoas.

José está há trinta e dois anos na instituição.

Maria administra o RACF desde 1997.

Carlos conhece cada mensagem DFSxxxx de cabeça.

João sabe exatamente qual dataset pode ser apagado e qual causará um desastre regulatório.

Nenhum deles está em um repositório Git.

Nenhum deles está em um Wiki.

Nenhum deles aparece em um prompt.

Esse conhecimento mora na memória das pessoas.

E a IA não faz leitura telepática.

Ela apenas processa aquilo que recebeu.

Quando recebe documentação incompleta, devolve respostas incompletas.

Quando recebe caos, produz caos estatisticamente coerente.

O Marketing da Varinha Mágica Digital

Não tenho dúvidas.

Existe muita tecnologia impressionante surgindo.

Copilots.

Agentes autônomos.

Análise semântica.

Descoberta automática de dependências.

RAG.

Embeddings.

Vetorização.

Tudo isso possui enorme potencial.

Mas também estamos vivendo uma epidemia de apresentações corporativas.

Parece que alguns vendedores descobriram a Pedra Filosofal da Computação.

Basta enviar um ZIP contendo quarenta milhões de linhas COBOL.

E, algumas horas depois, nasce uma arquitetura nativa de nuvem.

Observabilidade pronta.

CI/CD configurado.

Microsserviços desacoplados.

Eventos Kafka.

Terraform.

OpenTelemetry.

Kubernetes.

Documentação impecável.

Testes automatizados.

Compliance.

Segurança.

Alta disponibilidade.

Tudo isso sem compreender uma única regra de negócio.

É quase uma versão tecnológica daquele vendedor de elixires do Velho Oeste.

Só que agora utilizando a palavra GenAI.

O Mainframe Continua Evoluindo

Enquanto parte do mercado tenta organizar funerais prematuros para o IBM Z, a IBM continua investindo bilhões de dólares na plataforma.

Hoje temos:

COBOL 6.x;

z/OS Connect;

OpenTelemetry;

Ansible;

Zowe;

Git integrado;

DevOps moderno;

API Economy;

Containers Linux on Z;

IA embarcada;

Criptografia acelerada por hardware;

Processadores especializados.

Ou seja.

O Mainframe não está parado.

O Mainframe está fazendo aquilo que sempre fez melhor.

Adaptando-se.

Em 1964 ele sobreviveu ao surgimento dos minicomputadores.

Nos anos 80 sobreviveu às workstations.

Nos anos 90 sobreviveu ao Client/Server.

Nos anos 2000 sobreviveu à internet.

Nos anos 2010 sobreviveu à cloud.

Nos anos 2020 provavelmente sobreviverá ao hype da IA Generativa.

Porque, no final das contas, bancos continuam precisando fechar o dia.

Companhias aéreas continuam emitindo passagens.

Governos continuam pagando benefícios.

Seguradoras continuam processando milhões de eventos.

E quase ninguém gosta quando esses sistemas param.

Talvez a Pergunta Esteja Errada

A pergunta nunca deveria ser:

"Como saímos do Mainframe?"

A pergunta correta talvez seja:

"Qual workload realmente precisa sair?"

Talvez um portal web de RH possa migrar.

Talvez um batch de impressão possa ser substituído.

Talvez um sistema satélite seja reescrito.

Mas talvez o motor central de compensação bancária deva permanecer exatamente onde está.

Porque engenharia não é religião.

Arquitetura não é ideologia.

Tecnologia não é torcida organizada.

A melhor plataforma é aquela que resolve o problema com menor risco, melhor disponibilidade, maior previsibilidade financeira e retorno sustentável.

Considerações Finais

Suspeito que a Gartner não esteja dizendo:

"Nunca migrem."

Também não está afirmando:

"Mainframe venceu."

A mensagem parece muito mais madura.

A IA Generativa será extraordinariamente útil para documentar, explicar, testar, modernizar e integrar aplicações existentes.

Mas ainda estamos distantes de confiar bilhões de dólares em transações financeiras a um modelo estatístico incapaz de compreender por que um velho JOB chamado FINA987 precisa começar precisamente às 02h17 da madrugada.

E talvez seja justamente aí que esteja a maior ironia desta década.

A tecnologia mais avançada da atualidade descobriu que o Mainframe nunca foi apenas COBOL.

Ele sempre foi memória institucional.

Processos.

Pessoas.

Histórias.

E algumas dezenas de milhares de linhas de JCL escritas por um Sysprog que provavelmente continua tendo razão.

https://www.gartner.com/en/newsroom/press-releases/2026-06-18-gartner-predicts-more-than-70-percent-of-mainframe-exit-projects-will-fail-due-to-overestimation-of-generative-ais-capabilities

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

Technical Debt, Chaos Engineering e Resiliência no Mundo COBOL

 

Bellacosa Mainframe e divida tecnica, engenharia do caos e resiliencia no mundo mainframe

☕ Um Café no Bellacosa Mainframe

Technical Debt, Chaos Engineering e Resiliência no Mundo COBOL

Uma viagem dos cartões perfurados à engenharia de confiabilidade moderna

Existe uma curiosidade interessante sobre o universo Mainframe.

Boa parte dos desenvolvedores mais jovens acredita que sistemas COBOL foram escritos uma única vez, colocados em produção em algum momento dos anos 80 e simplesmente ficaram funcionando até hoje, imutáveis, como fósseis tecnológicos preservados em um museu digital.

A realidade é completamente diferente.

Poucas plataformas de tecnologia evoluíram tanto quanto o ecossistema IBM Z.

O hardware mudou.

O sistema operacional mudou.

Os compiladores mudaram.

As técnicas de desenvolvimento mudaram.

A forma de entregar software mudou.

As exigências regulatórias mudaram.

E os desenvolvedores também precisaram mudar.

Hoje falamos sobre APIs REST, Git, DevOps, Inteligência Artificial, Observabilidade, Chaos Engineering e Cloud Native. Entretanto, curiosamente, os sistemas que movimentam bilhões de dólares por dia continuam sendo executados por programas COBOL escritos há décadas.

Seria isso uma contradição?

Na verdade, não.

Talvez seja justamente uma demonstração de sucesso.

O primeiro legado não foi um erro

Em 1959 nasceu o COBOL.

Naquela época não existiam metodologias ágeis.

Não existia internet.

Não existiam smartphones.

Muitos programas eram escritos em cartões perfurados.

Armazenamento era caro.

Memória era limitada.

CPU era um recurso precioso.

As equipes construíam software pensando em algo muito importante:

Confiabilidade.

A aplicação precisava funcionar.

Sempre.

Mesmo que demorasse algumas horas para processar milhares de contas bancárias durante a madrugada.

Foi nesse ambiente que nasceu uma cultura extremamente disciplinada.

Documentação.

Padrões.

Controle de mudanças.

Testes.

Auditorias.

Processos.

Talvez os desenvolvedores daquela época não soubessem, mas estavam criando alguns dos primeiros conceitos de Engenharia de Confiabilidade.

Technical Debt: a dívida que todos nós fazemos

Em 1992, Ward Cunningham criou uma analogia brilhante.

Ele comparou decisões de desenvolvimento com empréstimos bancários.

Imagine que você precise entregar um sistema até sexta-feira.

Você poderia construir uma solução perfeita.

Ou poderia desenvolver algo funcional, mais simples, entregando rapidamente.

Você ganha velocidade.

Mas assume uma dívida.

E como toda dívida, ela possui juros.

Esses juros aparecem de várias formas.

Mais bugs.

Mais incidentes.

Mais retrabalho.

Maior consumo de CPU.

Maior dificuldade de manutenção.

Menor velocidade de inovação.

No Mainframe isso acontece frequentemente.

Talvez exista um programa COBOL com 25 mil linhas.

Talvez exista um COPYBOOK criado em 1987.

Talvez apenas um profissional conheça determinada aplicação.

Tudo isso representa dívida técnica.

O problema não é possuir dívida.

O problema é não saber que ela existe.

Nem toda dívida é ruim

Muitos desenvolvedores iniciantes acreditam que Technical Debt sempre significa erro.

Não é verdade.

Às vezes ela é estratégica.

Um banco pode precisar adequar sistemas rapidamente para atender uma nova regulamentação do BACEN.

Uma seguradora pode precisar disponibilizar um novo produto imediatamente.

Uma fintech pode lançar um MVP para validar mercado.

Nesses casos, assumir dívida técnica pode ser perfeitamente aceitável.

Desde que exista um plano para pagá-la posteriormente.

E aqui encontramos uma das primeiras lições importantes para um desenvolvedor COBOL júnior:

Escreva código pensando que alguém precisará entendê-lo daqui a dez anos.

Esse alguém pode ser você mesmo.

O mito da reescrita completa

Existe uma frase bastante comum em empresas:

"Precisamos jogar tudo fora."

Geralmente essa frase surge quando o ambiente está muito complexo.

Mas a IBM apresenta uma visão diferente.

Você não precisa substituir quarenta anos de sistemas.

Você pode modernizar gradualmente.

Esse conceito ficou conhecido como Strangler Pattern.

Imagine um sistema COBOL que processa contas correntes.

Ele continua funcionando.

Mas uma nova camada é criada.

z/OS Connect.

APIs REST.

Microserviços.

Containers.

Aplicações Java.

Python.

Inteligência Artificial.

O COBOL permanece processando transações críticas.

As aplicações modernas apenas consomem seus serviços.

A dívida começa a diminuir sem que seja necessário desligar o coração operacional da empresa.

Testes automatizados são seus melhores amigos

Durante muitos anos, testar em Mainframe significava reservar uma janela de homologação.

Executar jobs.

Analisar relatórios.

Esperar dias.

Hoje isso mudou.

Ferramentas como zUnit permitem criar testes automatizados.

Jenkins integra pipelines.

GitHub Actions executa validações.

DBB facilita builds.

Zowe aproxima o mundo Mainframe das práticas DevOps modernas.

Se você está começando em COBOL, desenvolva o hábito de pensar:

"O que acontece se o CPF estiver inválido?"

"E se a data vier vazia?"

"E se houver overflow?"

Programadores experientes não escrevem apenas funcionalidades.

Eles escrevem confiança.

Code Review: aprendendo com outros desenvolvedores

Uma das melhores maneiras de evoluir tecnicamente é revisar código.

Olhar programas COBOL antigos.

Analisar SQL.

Entender JCLs.

Perguntar.

Questionar.

Aprender.

Muitos problemas são identificados antes mesmo de chegar à produção.

Um cursor esquecido.

Um COMMIT ausente.

Um SORT desnecessário.

Uma consulta DB2 sem índice adequado.

Dois pares de olhos normalmente enxergam mais do que um.

Refatoração não significa reescrever

Refatorar é melhorar.

Não é destruir.

Não é começar do zero.

Pequenas melhorias acumuladas ao longo do tempo fazem enorme diferença.

Renomear variáveis.

Extrair rotinas.

Separar módulos.

Eliminar GOTO.

Criar serviços reutilizáveis.

Transformar programas gigantes em componentes menores.

Refatoração contínua é uma das formas mais eficientes de pagar Technical Debt.

Observabilidade: enxergando o que realmente acontece

Existe uma frase bastante conhecida:

Se você não consegue medir, não consegue melhorar.

No mundo IBM Z temos ferramentas extraordinárias.

SMF.

RMF.

OMEGAMON.

Instana.

Grafana.

Elas permitem compreender:

CPU.

I/O.

Latência.

Filas.

Conexões.

Transações.

Antes de corrigir qualquer problema, precisamos enxergá-lo.

Observabilidade é a base da engenharia moderna.

Chaos Engineering: quebrando para aprender

Talvez o conceito mais surpreendente para desenvolvedores COBOL seja Chaos Engineering.

A ideia surgiu popularmente na Netflix.

Mas a IBM mostra que ela pode ser aplicada em praticamente qualquer ambiente.

O princípio é simples.

Não espere uma falha em produção.

Provoque pequenas falhas.

Aprenda.

Corrija.

Teste novamente.

Por exemplo:

O que acontece se o IMS Connect ficar indisponível?

Se a fila MQ atingir 95% de ocupação?

Se um membro do Sysplex parar?

Se o DB2 responder lentamente?

Chaos Engineering não significa desligar servidores aleatoriamente.

É ciência.

Você cria uma hipótese.

Executa um experimento controlado.

Observa.

Aprende.

Melhora.

Repete.

Resiliência é um investimento

A IBM utiliza uma analogia muito interessante.

Imagine um ciclista.

Ele pode sair apenas com a bicicleta.

Ou levar uma bomba de ar.

Kit de reparo.

Câmara reserva.

Pneu reserva.

Carro de apoio.

Mecânico.

Quanto maior a disponibilidade desejada, maior será o custo.

Em tecnologia ocorre exatamente o mesmo.

Alta disponibilidade.

Disaster Recovery.

Cyber Recovery.

Backups.

Replicação.

GDPS.

Sysplex.

Active-Active.

Tudo possui custo.

O objetivo não é atingir disponibilidade infinita.

O objetivo é encontrar equilíbrio entre risco, orçamento e necessidade do negócio.

O desenvolvedor COBOL de 2026

O profissional COBOL moderno não é apenas alguém que conhece MOVE, PERFORM e READ.

Ele entende Git.

Conhece APIs.

Aprende DevOps.

Sabe interpretar métricas.

Participa de revisões.

Automatiza testes.

Compreende observabilidade.

Conhece conceitos de segurança.

Entende resiliência.

Estuda Inteligência Artificial.

E principalmente, continua cultivando algo que sempre esteve presente no universo Mainframe:

Disciplina técnica.

Os sistemas que movimentam bilhões de transações diariamente não permanecem relevantes por acaso.

Eles permanecem relevantes porque existem profissionais dispostos a compreender o passado, melhorar continuamente o presente e testar constantemente o futuro.

E talvez seja exatamente essa a maior lição do Mainframe.

Tecnologia muda.

Ferramentas mudam.

Buzzwords mudam.

Mas excelência em engenharia continua sendo atemporal.

E isso, felizmente, nunca sai de moda.

Até o próximo café.

☕ Bellacosa Mainframe


Bellacosa Mainframe Network

Siga nossas newsletters e comunidades no LinkedIn

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

quarta-feira, 24 de junho de 2026

Os Guardiões Invisíveis do Reino IBM Z ACEE, SAF e APF – As Três Relíquias que Protegem Trilhões de Dólares Todos os Dias

 

Bellacosa Mainframe e os guardioes do reino ibm z acee saf e apf

☕💥 Um Café no Bellacosa Mainframe

Os Guardiões Invisíveis do Reino IBM Z

ACEE, SAF e APF – As Três Relíquias que Protegem Trilhões de Dólares Todos os Dias

Por Vagner Bellacosa – Bellacosa Mainframe

Existe algo curioso sobre segurança em Mainframe.

Quase todo mundo conhece RACF.

Muitos ouviram falar de SAF.

Poucos sabem explicar o que realmente é um ACEE.

E uma quantidade ainda menor entende por que o APF talvez seja um dos componentes mais importantes de toda a arquitetura do z/OS.

A verdade é que, por trás das telas verdes, dos CICS, dos IMS, dos DB2 e dos bilhões de transações financeiras processadas diariamente, existe um pequeno conjunto de tecnologias silenciosas que trabalha vinte e quatro horas por dia, sete dias por semana, há décadas, praticamente sem reconhecimento.

São os verdadeiros guardiões do Reino IBM Z.

E talvez seja hora de apresentar estes personagens aos novos Padawans do z/OS.

O Reino IBM Z

Gosto bastante de utilizar uma analogia medieval para explicar segurança no Mainframe.

Imagine um enorme castelo.

Existem bibliotecas.

Existe um tesouro.

Existem escribas.

Existem correios.

Existem soldados.

Existe um cartório.

E existe o Rei.

No Reino IBM Z, podemos imaginar algo semelhante.

CICS é a administração do castelo.

IMS é o departamento financeiro.

DB2 é a biblioteca.

MQ é o correio.

USS é o bairro moderno onde vivem os moradores Unix.

SMF é o historiador oficial.

RACF é o cartório real.

O Sysprog é o guardião das chaves.

Mas três personagens trabalham praticamente o tempo inteiro.

SAF.

ACEE.

APF.

Eles são pouco conhecidos pelos desenvolvedores COBOL.

Quase invisíveis para operadores.

E absolutamente fundamentais para os Sysprogs.

SAF – O Porteiro Invisível

Um dos maiores equívocos entre profissionais iniciantes é acreditar que CICS conversa diretamente com RACF.

Ou que DB2 consulta diretamente o RACF.

Ou ainda que MQ valida permissões diretamente no banco de dados de segurança.

Na realidade, quase todos os produtos do z/OS conversam primeiro com o SAF.

SAF significa System Authorization Facility.

Ele pode ser entendido como um grande barramento de segurança.

Ou melhor.

Um porteiro.

Imagine uma recepção sofisticada na entrada do castelo.

Toda pessoa que deseja entrar em uma sala precisa passar pela recepção.

A recepcionista não toma decisões.

Ela apenas consulta o cartório.

Recebe uma resposta.

E libera ou bloqueia a passagem.

SAF funciona exatamente assim.

Aplicação.

↓

SAF.

↓

RACF.

↓

Resposta.

Isso permite que produtos IBM e produtos terceiros utilizem um mecanismo único de autorização.

Foi uma ideia brilhante da IBM.

Caso contrário, CICS precisaria implementar seu próprio sistema de segurança.

IMS teria outro.

DB2 outro.

MQ outro.

USS outro.

Seria praticamente impossível administrar um ambiente corporativo de grande porte.

Hoje, bilhões de solicitações de segurança passam pelo SAF diariamente.

E a maioria das pessoas sequer percebe sua existência.

ACEE – O Crachá Mágico

Outro personagem pouco conhecido é o ACEE.

Access Control Environment Element.

Se o SAF é o porteiro, o ACEE é o crachá.

Imagine um funcionário chegando ao prédio.

No primeiro acesso ele apresenta documentos.

Passa por verificações.

Tem sua identidade validada.

Recebe um crachá.

A partir daquele momento não precisa mostrar documentos novamente.

Basta apresentar o crachá.

O ACEE funciona exatamente desta maneira.

Quando um usuário faz LOGON no TSO.

Ou acessa um CICS.

Ou estabelece uma sessão SSH.

O RACF executa um VERIFY.

Autentica o usuário.

Cria um ACEE.

E entrega esse contexto de segurança para a aplicação.

O ACEE contém informações extremamente importantes.

Userid.

Grupos.

UID Unix.

Certificados.

Labels.

Atributos especiais.

Contexto OMVS.

Permissões.

Flags.

Tudo armazenado em memória.

O objetivo é simples.

Evitar milhões de consultas desnecessárias ao RACF.

Imagine um banco processando cem mil transações por segundo.

Sem ACEE.

Cada autorização consultaria novamente o banco de segurança.

Seria inviável.

Com ACEE.

O sistema apenas consulta estruturas já residentes em memória.

Menos CPU.

Menos I/O.

Menos contenção.

Maior escalabilidade.

Talvez o ACEE seja um dos control blocks com melhor retorno sobre investimento da história da computação corporativa.

APF – O Selo Dourado do Reino

Mas existe algo ainda mais poderoso.

APF.

Authorized Program Facility.

Este é provavelmente o componente mais respeitado por um Sysprog experiente.

E também um dos mais perigosos.

No Reino IBM Z, podemos imaginar APF como um selo dourado concedido pelo Rei.

Nem todos recebem este selo.

Somente programas altamente confiáveis.

Programas autorizados podem executar serviços privilegiados.

Manipular armazenamento protegido.

Executar operações supervisor state.

Realizar chamadas especiais.

Interagir profundamente com o núcleo do sistema.

Mas isso possui um preço.

Um programa autorizado incorretamente pode comprometer toda a integridade do ambiente.

Por isso, APF é tratado com extremo cuidado.

Para que um módulo seja considerado autorizado normalmente dois requisitos precisam ser atendidos.

Primeiro.

O programa deve possuir AC(1).

Segundo.

A biblioteca onde reside deve estar presente na lista APF.

Caso contrário.

Nada feito.

O z/OS simplesmente não concede os privilégios especiais.

E é justamente isso que protege o sistema.

Quando Tudo Dá Errado

Todo Sysprog eventualmente recebe uma ligação de madrugada.

03:17.

Produção parada.

DB2 acusa segurança.

MQ acusa RACF.

USS apresenta Permission Denied.

CICS responde Not Authorized.

E alguém inevitavelmente diz:

"O problema é no RACF."

Talvez.

Mas talvez não.

O profissional experiente sabe que precisa investigar.

Verificar SMF80.

Consultar zSecure.

Analisar mensagens ICH408I.

Abrir IPCS.

Localizar o ACEE.

Examinar o contexto.

Conferir grupos.

Checar FASTAUTH.

Validar APF.

Verificar classes.

Observar RCs.

Interpretar RSNs.

Porque o dump raramente mente.

As pessoas podem se confundir.

Aplicações podem mascarar erros.

Logs podem induzir interpretações equivocadas.

Mas o dump normalmente conta exatamente a história que aconteceu.

O Segredo do IBM Z

A grande beleza do Mainframe não está apenas em processar milhões de transações.

Está em sua arquitetura.

IBM não criou simplesmente ferramentas.

Criou camadas.

Criou isolamento.

Criou mecanismos de desacoplamento.

Criou contexto.

Criou auditoria.

Criou proteção.

SAF desacopla aplicações do mecanismo de segurança.

ACEE desacopla autenticação das verificações constantes.

APF desacopla programas comuns de funções críticas do sistema operacional.

SMF registra tudo.

ICSF protege chaves.

RACF define regras.

E o Sysprog garante que todas essas peças continuem funcionando em perfeita harmonia.

A Lição Final do Padawan

Talvez a principal lição para um Sysprog iniciante seja entender que segurança no z/OS não é apenas RACF.

Segurança é um ecossistema.

Hardware criptográfico.

ICSF.

SAF.

RACF.

SMF.

APF.

ACEE.

Auditoria.

Processos.

Pessoas.

Boas práticas.

Governança.

Monitoramento.

E principalmente conhecimento.

Porque no fim das contas, o verdadeiro Guardião do Reino IBM Z não é aquele que apenas executa comandos.

É aquele que compreende por que cada tecnologia foi criada.

Como ela conversa com as demais.

Como diagnosticar seus problemas.

Como protegê-la.

Como evoluí-la.

E como garantir que, mesmo às três horas da manhã, quando o telefone tocar e alguém disser que o RACF está quebrado, ele consiga abrir um dump, seguir o caminho até o ACEE, verificar o contexto SAF, analisar APF e devolver ao Reino IBM Z aquilo que ele faz melhor há décadas:

Disponibilidade.

Integridade.

Confidencialidade.

E a tranquilidade de saber que trilhões de dólares continuam circulando silenciosamente pelo mundo, protegidos por tecnologias que quase ninguém vê, mas que todo Sysprog deveria conhecer profundamente.

"O RACF conhece as leis. O SAF atende as portas. O ACEE acompanha o viajante. O APF protege os segredos do castelo. E o Sysprog mantém o Reino IBM Z de pé, uma madrugada de cada vez."

Bellacosa Mainframe

 

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

terça-feira, 23 de junho de 2026

☕🚀 IBM Garage para Padawans do COBOL

 

Bellacosa Mainframe apresenta o IBM Garage

☕🚀 IBM Garage para Padawans do COBOL

Como a IBM descobriu que colocar arquitetos, desenvolvedores e usuários numa sala com Post-it era mais barato do que deixar um Comitê decidir durante 18 meses

Por Vagner Bellacosa – Bellacosa Mainframe

Introdução

Existe uma cena que provavelmente aconteceu em algum lugar do planeta Terra.

Uma grande empresa possui:

  • 40 milhões de linhas COBOL;

  • 8 regiões CICS;

  • 12 subsistemas DB2;

  • IMS desde a época em que Darth Vader ainda era funcionário da Estrela da Morte;

  • dezenas de integrações misteriosas que ninguém sabe exatamente quem fez.

Então alguém da diretoria aparece numa reunião e pergunta:

"Por que nosso aplicativo não é igual ao Nubank?"

Silêncio.

O programador COBOL olha para o sysprog.

O sysprog olha para o DBA.

O DBA olha para o arquiteto.

O arquiteto olha para o teto.

O teto continua sendo o profissional mais experiente da sala.

E foi justamente para lidar com este tipo de situação que surgiu uma metodologia chamada:

IBM Garage

E não...

Não é uma oficina mecânica da IBM.

Você não troca óleo do z16.

Não calibra pneus do CICS.

Não faz alinhamento de DB2.

Apesar de alguns ambientes precisarem desesperadamente de uma revisão completa.

A origem do IBM Garage

A IBM percebeu uma coisa importante.

Muitas empresas estavam gastando fortunas em projetos de transformação digital.

E a sequência era sempre parecida.

Fase 1

Consultoria.

Fase 2

PowerPoint.

Fase 3

Mais PowerPoint.

Fase 4

Comitê.

Fase 5

Outro comitê.

Fase 6

Projeto cancelado.

Fase 7

Novo projeto para descobrir porque o primeiro falhou.

Não parecia eficiente.

A IBM decidiu buscar inspiração em outro lugar.

Nas startups.

No Vale do Silício.

No Design Thinking.

No Agile.

No Lean Startup.

E criou algo chamado:

IBM Garage.

O objetivo era simples.

Parar de discutir ideias infinitamente.

E começar a construir.

Rapidamente.

O que significa Garage?

A inspiração vem literalmente das garagens onde várias empresas começaram.

Apple.

HP.

Google.

Amazon.

Muitas delas nasceram em espaços pequenos.

Com poucas pessoas.

Testando ideias.

Errando.

Aprendendo.

E evoluindo rapidamente.

A IBM tentou trazer esta mentalidade para empresas gigantes.

Inclusive bancos.

Seguradoras.

Governos.

Telecom.

Empresas aéreas.

Hospitais.

O problema das empresas tradicionais

Imagine um banco.

Ele possui.

COBOL

CICS

IMS

DB2

VSAM

MQ

Batch

JCL

Tudo funcionando.

Há décadas.

Milhões de transações.

99,999% disponibilidade.

Mas surge uma nova necessidade.

Aplicativo mobile.

Pix.

Open Finance.

IA.

Chatbots.

APIs.

Machine Learning.

Analytics.

A pergunta aparece.

Como modernizar?

Reescrever tudo?

Jamais.

Isso seria equivalente a desmontar um Boeing 787 em pleno voo.

E pedir para os passageiros aguardarem tranquilamente.

O IBM Garage resolve isso

A ideia é:

Não jogar fora.

Não substituir.

Não destruir.

Mas aproveitar.

Modernizar.

Expor.

Integrar.

Evoluir.

Os pilares do IBM Garage

Design Thinking

Descobrir o problema.

Não assumir soluções.

Perguntas.

Quem usa?

Como usa?

Por que usa?

O que incomoda?

Agile

Pequenas entregas.

Feedback rápido.

Melhoria contínua.

Não esperar dois anos.

Não esperar aprovação do Conselho Jedi.

DevOps

Automação.

Pipeline.

Testes.

Deploy.

Integração contínua.

Hybrid Cloud

Executar aplicações onde faz sentido.

Cloud.

OpenShift.

IBM Z.

Linux.

Containers.

Inteligência Artificial

Watsonx.

LLMs.

Assistentes.

Análise de dados.

O IBM Garage para quem trabalha com Mainframe

Aqui fica interessante.

Porque o COBOL deixa de ser visto como problema.

E passa a ser ativo estratégico.

Imagine.

Programa COBOL

↓

CICS

↓

z/OS Connect

↓

API REST

↓

Aplicativo Android

Fim.

Sem reescrever.

Sem migrar.

Sem trauma psicológico.

Exemplo real

Sistema bancário.

Programa COBOL:

CONSCLIE

Recebe:

CPF

Retorna:

Nome

Saldo

Conta

Antes.

Somente terminal 3270.

Agora.

API.

JSON.

Cliente consulta pelo celular.

COBOL continua executando.

Feliz.

Seguro.

Confortável.

Como um senhor aposentado tomando café observando jovens discutirem Kubernetes.

As quatro fases do IBM Garage

1 Descobrir

Workshop.

Usuários.

TI.

Negócio.

Arquitetos.

Desenvolvedores.

Perguntas.

O que dói?

O que demora?

O que pode melhorar?

2 Definir

Escolher MVP.

Escopo.

Backlog.

Priorização.

3 Construir

Sprint.

Desenvolvimento.

Testes.

Protótipos.

4 Escalar

Produção.

DevSecOps.

Observabilidade.

Governança.

Exemplo para um desenvolvedor COBOL Júnior

Vamos imaginar.

Seu gerente diz.

Precisamos criar uma API.

Consultar cliente.

Passo 1

Identificar programa COBOL.

CONSCLIE

Passo 2

Verificar COMMAREA.

01 DFHCOMMAREA.

   05 CPF         PIC X(11).

   05 NOME        PIC X(40).

   05 SALDO       PIC S9(9)V99.

Passo 3

Criar serviço z/OS Connect.

Mapear campos.

Passo 4

Gerar Swagger.

Passo 5

Publicar.

Passo 6

Testar.

curl http://api.banco.com/clientes/12345678901

Resposta.

{
"name":"JOAO SILVA",
"saldo":1500.50
}

Pronto.

Você participou de uma iniciativa IBM Garage.

Sem perceber.

Ferramentas utilizadas

OpenShift

Git

Jenkins

UrbanCode

Ansible

Instana

Turbonomic

watsonx

Zowe

z/OS Connect

API Connect

O papel do desenvolvedor COBOL

Muita gente acredita.

Garage é somente para arquitetos.

Errado.

COBOL Developers são fundamentais.

Porque conhecem.

Regras de negócio.

Batch.

CICS.

DB2.

Processos críticos.

Sem eles.

Modernização vira arqueologia.

Dicas para um Programador COBOL Júnior

Estude APIs

REST.

JSON.

Swagger.

OpenAPI.

Aprenda Git

Git é obrigatório.

Conheça Docker

Mesmo sem usar.

Entenda conceitos.

Aprenda OpenShift

É o Kubernetes corporativo da IBM.

Estude z/OS Connect

Talvez seja a ferramenta mais importante atualmente para integração Mainframe.

Aprenda Agile

Scrum.

Kanban.

Sprint.

Não tenha medo de IA

A IA provavelmente escreverá códigos.

Mas dificilmente entenderá cinquenta anos de regras bancárias escondidas em programas COBOL com 80 mil linhas.

Você entenderá.

E isso possui enorme valor.

Minha opinião sobre IBM Garage

Eu gosto da proposta.

Porque ela reconhece algo importante.

Mainframe não é problema.

Mainframe é patrimônio.

COBOL não está morrendo.

Está sendo conectado.

API por API.

Container por container.

Sprint por sprint.

Workshop por workshop.

Até que um sistema criado em 1989 converse naturalmente com uma aplicação React, um chatbot baseado em LLM, um aplicativo Android e um painel analítico em nuvem.

E talvez esta seja a maior lição do IBM Garage.

Transformação digital não significa jogar fora décadas de conhecimento.

Significa pegar tudo aquilo que funciona incrivelmente bem.

Colocar uma interface moderna.

Adicionar automação.

Criar APIs.

Aplicar inteligência artificial.

E permitir que a próxima geração de desenvolvedores COBOL continue escrevendo história.

Porque, no fim das contas, o COBOL continua sendo aquele veterano experiente do escritório.

Ele não usa tênis colorido.

Não fala em Web3.

Não posta frases motivacionais no LinkedIn.

Mas é ele que paga os boletos do banco.

Processa salários.

Liquida cartões.

Movimenta bolsas de valores.

Autoriza pagamentos.

E mantém o mundo funcionando enquanto a internet discute qual será o próximo framework JavaScript da semana.

E talvez seja exatamente por isso que o IBM Garage exista.

Para mostrar que inovação não é destruir o passado.

É construir uma ponte elegante entre 1960 e 2030.

E fazer isso tomando um bom café, de preferência acompanhado de um desenvolvedor COBOL, um arquiteto IBM Z, um especialista em APIs e algumas dezenas de Post-its espalhadas pela mesa.

Apenas tome cuidado.

Se alguém aparecer dizendo que vai reescrever 40 milhões de linhas COBOL em um final de semana usando Inteligência Artificial, esconda o café.

E chame imediatamente um sysprog.


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

A Saga de Vagner Bellacosa no Reino dos Mainframes

 



☕💥 A Saga de Vagner Bellacosa no Reino dos Mainframes

Ou como um jovem padawan descobriu que COBOL dá mais XP que matar dragões

Bellacosa Mainframe e historias de velhos cpds em mainframe


Salve jovem padawan.

Pegue um café.

Se for diabético, pegue sem açúcar.

Se estiver em produção, pegue dois.

Hoje vou contar uma história.

Não a história de um herói tradicional.

Nada de capa.

Nada de espada mágica.

Nada de armadura lendária.

Nosso protagonista usa crachá corporativo, camisa social amassada, óculos cansados, carrega uma mochila cheia de apostilas IBM dos anos 90 e combate criaturas muito mais perigosas que dragões.

Ele atende pelo nome de Vagner Bellacosa.

O chamado da aventura

Toda jornada começa de maneira inocente.

Alguns encontram um anel.

Outros encontram uma espada cravada numa pedra.

Bellacosa encontrou...

Um terminal 3270.

Tela preta.

Letras verdes.

Cursor piscando.

Silêncio.

Nenhum botão.

Nenhum mouse.

Nenhum TikTok.

Nenhum React.

Nenhum Kubernetes.

Apenas um campo escrito:

LOGON ===>

Naquele instante existiam apenas duas possibilidades.

Primeira:

Desligar o computador e cursar gastronomia.

Segunda:

Digitar o usuário.

Ele digitou.

E nunca mais foi o mesmo.

O primeiro ABEND

Todo herói precisa sofrer.

Luke perdeu a mão.

Frodo quase perdeu a alma.

Bellacosa ganhou seu primeiro:

S0C7.

E descobriu algo curioso.

No Mainframe ninguém fala:

"Tem bug."

Todos falam:

— Deu ABEND.

ABEND parece nome de chefe final.

Você passa oito horas procurando.

Consulta dump.

Abre SYSOUT.

Lê JESMSGLG.

Olha o compile listing.

Chama o colega.

Chama outro colega.

Chama o especialista.

Chama um padre.

E no final descobre:

O campo numérico tinha espaço em branco.

Aí você aprende humildade.

Banco Real, a Terra Média dos Dinossauros Digitais

Existiu uma época gloriosa.

A época em que o Banco Real possuía milhares de programas.

Centenas de analistas.

Adabas.

Natural.

PLI.

JCL.

Control-M.

CICS.

VSAM.

RACF.

E um exército de desenvolvedores sobrevivendo a janelas batch.

Era uma civilização inteira.

Uma espécie de Atlântida tecnológica.

Enquanto a internet ainda fazia:

Piiiiiiiiiiiii....

Krrrttttt...

Biiiiiippp...

O Mainframe já processava milhões de registros.

Sem Kubernetes.

Sem Docker.

Sem palestra motivacional.

Sem coach dizendo:

"Escalone sua vida."

O Mainframe apenas respondia:

— JOB EXECUTADO RC=0000

E seguia trabalhando.

O homem que conversava com os programas Natural

Chegou então o Bug do Milênio.

O apocalipse anunciado.

Consultorias ficaram ricas.

Executivos ficaram nervosos.

Gerentes envelheceram.

Bellacosa teve uma ideia.

Criar um extrator.

Mas não qualquer extrator.

Um monstro.

Um PLI autorecursivo.

Um pequeno T-800 em formato de JCL.

Ele lia.

Interpretava.

Gerava JCL.

Enfileirava jobs.

Chamava a si próprio.

Criava novos filhos.

Extraía fontes.

Analisava objetos.

Preenchia bibliotecas.

E continuava trabalhando.

Sozinho.

Por 48 horas.

Consumindo CPU.

Consumindo spool.

Consumindo a sanidade do operador.

Quando terminou...

Meio milhão de objetos haviam sido catalogados.

Hoje chamaríamos isso de:

Pipeline de DevOps.

Na época chamava-se:

"Coisa do Bellacosa."

O Grande Inquisidor da DAI

Mas nenhum guerreiro evolui sem enfrentar a polícia secreta.

DAI.

Três letras capazes de congelar a alma.

Ser chamado pela DAI era equivalente a ouvir:

"Precisamos conversar."

Você imediatamente pensava:

Meu RACF vazou?

Compilei em produção?

Rodei a Loteca?

Usei a transação proibida?

Não.

Queriam apenas um relatório.

Um relatório pequeno.

Só precisava analisar milhares de logs.

Consultar usuários.

Cruzar tabelas.

Gerar dezenas de milhares de páginas.

Em 72 horas.

Sem errar.

Sem testar direito.

Sem segunda chance.

Bellacosa codificou.

Revisou.

Debugou com caneta.

Rezou.

Entregou.

Funcionou.

E descobriu uma lição importante.

Programador Mainframe não envelhece.

Ele acumula PTSD de produção.

O evangelista improvável

Décadas se passaram.

Muitos colegas migraram.

Viraram arquitetos.

Gerentes.

Executivos.

Consultores.

Alguns abriram startups.

Outros abriram adegas.

Bellacosa resolveu algo diferente.

Contar histórias.

Escrever artigos.

Criar newsletters.

Ensinar COBOL.

Explicar CICS.

Falar sobre VSAM.

Defender o velho gigante preto da IBM.

Transformar dump em entretenimento.

Transformar S0C4 em meme.

Transformar SYSUDUMP em literatura fantástica.

Porque descobriu algo curioso.

O Mainframe nunca foi apenas tecnologia.

Foi amizade.

Foi mentor.

Foi Roseli.

Foi Tokunaga.

Foi auditor assustador.

Foi operador bravo.

Foi colega salvando produção às três da manhã.

Foi café requentado.

Foi pizza fria.

Foi aprender que existem pessoas que realmente se emocionam ao ver um RC=0000.

E tudo bem.

Somos poucos.

Somos estranhos.

Somos os últimos guardiões do EBCDIC.

Epílogo

Hoje existem inteligências artificiais.

Agentes autônomos.

LLMs.

Clouds infinitas.

Quantum Computing.

Promessas de substituir COBOL.

Promessas de desligar Mainframe.

Promessas de reescrever tudo.

Promessas.

Muitas promessas.

Enquanto isso...

Em algum lugar do planeta...

Um CICS iniciado em 1998 continua processando cartões.

Um DB2 continua pagando aposentadorias.

Um VSAM continua guardando informações valiosas.

Um JCL continua rodando.

E um Bellacosa continua tomando café.

Escrevendo artigos.

Chamando leitores de padawans.

Contando histórias.

E lembrando a todos nós que talvez o verdadeiro legado do Mainframe nunca tenha sido o hardware.

Mas as pessoas malucas o suficiente para dedicar a vida inteira a fazê-lo funcionar.

E sinceramente...

Ainda bem que existem esses malucos.

Esse texto ficou bem próximo do tom clássico de "Histórias do Tiozão em Mainframe", misturando autobiografia, nostalgia, cultura pop, autoironia e reverência aos velhos guerreiros do z/OS. (DIO)

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

segunda-feira, 22 de junho de 2026

☕💥 Quando um Dataset VSAM Corrompe no z/OS: Guia de Sobrevivência para Sysprogs, Desenvolvedores COBOL e Administradores CICS

 

Bellacosa Mainframe uma pequena ajudinha recuperando dataset vsam

☕💥 Quando um Dataset VSAM Corrompe no z/OS: Guia de Sobrevivência para Sysprogs, Desenvolvedores COBOL e Administradores CICS

"Há dois tipos de profissionais de Mainframe: os que já recuperaram um dataset corrompido e os que ainda vão recuperar."

Introdução

Poucas mensagens conseguem acelerar tanto os batimentos cardíacos de um profissional de Mainframe quanto estas:

IDC3302I ACTION ERROR
IDC3351I VSAM OPEN RETURN CODE 168
IEC161I
IEC070I
DFHFC0157

Ou pior ainda:

"O arquivo de clientes não abre em produção."

Silêncio.

O scheduler para.

O CICS começa a emitir mensagens.

Os jobs entram em abend.

O telefone toca.

Alguém pergunta:

"Tem backup?"

E nesse momento percebemos que existe uma grande diferença entre saber programar COBOL, conhecer VSAM e realmente entender o processo de recuperação de corrupção em datasets no z/OS.

Hoje vamos tomar um café e conversar sobre um assunto pouco ensinado em treinamentos, mas extremamente valorizado em bancos, seguradoras, companhias aéreas e órgãos governamentais:

Como recuperar um dataset VSAM corrompido no z/OS.

O que significa um Dataset Corrompido?

Nem toda falha é uma corrupção.

Às vezes é apenas um catálogo inconsistente.

Em outros casos temos problemas muito mais graves.

Exemplos:

  • EOF inconsistente

  • HURBA inválido

  • HARBA incorreto

  • Alternate Index quebrado

  • Cadeia lógica danificada

  • Control Interval inválida

  • Problemas na VTOC

  • SMSVSAM inconsistente

  • CI Split interrompido

  • Erros físicos em disco

Primeira Regra: Pare Tudo

O maior erro que vejo iniciantes cometerem é tentar "olhar rapidamente".

Não.

Pare imediatamente.

Batch

Segure scheduler.

CA7

Control-M

TWS

CICS

Fechar arquivo.

CEMT SET FILE(CUSTFILE) CLOSED

ou

CEMT SET FILE(CUSTFILE) DISABLED

IMS

/DBR CUSTOMER

Started Tasks

Encerrar consumidores.

MQ

Connectors

Replication

ETL

CDC

A regra é simples.

Dataset suspeito.

Sem acesso.

Sem exceções.

Segunda Etapa: LISTCAT

Antes de sair executando VERIFY.

Olhe o paciente.

Comando

//STEP1 EXEC PGB=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *

 LISTCAT ENT(PROD.CUST.KSDS)
 ALL

/*

O que analisar?

Cluster

Data Component

Index Component

Volume

HI-USED-RBA

Catalog

SMS Classes

Exemplo

HURBA = 000001987654
HARBA = 000001999999

Valores estranhos podem indicar inconsistências.

VERIFY

Provavelmente a ferramenta mais subestimada do IDCAMS.

Função

Sincronizar.

Catalog

Volume

EOF

RBA

Informações físicas

Exemplo

VERIFY DATASET(PROD.CUST.KSDS)

Com recuperação:

VERIFY DATASET(PROD.CUST.KSDS)
RECOVER

O VERIFY resolve

EOF incorreto

Catalog inconsistente

Discrepâncias simples

Alguns problemas em KSDS

Mas atenção.

VERIFY não é mágica.

Ele não reconstrói uma estrutura destruída.

EXAMINE

Agora começa a parte realmente interessante.

EXAMINE é quase um scanner médico do VSAM.

Data Component

EXAMINE -
NAME(PROD.CUST.KSDS)
DATATEST

Índice

EXAMINE -
NAME(PROD.CUST.KSDS)
INDEXTEST

Completo

EXAMINE -
NAME(PROD.CUST.KSDS)
DATA

O que ele encontra?

Control Interval inválida

Ponteiros quebrados

Índices inconsistentes

RBAs errados

Registros perdidos

A Grande Pergunta

Após EXAMINE surge a decisão.

Corrupção pequena?

ou

Corrupção severa?

Essa decisão define tudo.

Cenário 1 — Corrupção Leve

Exemplos.

Catalog inconsistente.

EOF errado.

Pequenos danos.

Solução.

VERIFY

REPRO

Rebuild

REPRO

Criar novo cluster.

DEFINE CLUSTER(...)

Copiar.

REPRO -
INFILE(IN1)
OUTFILE(OUT1)

Muitas vezes isso resolve.

Surpreendentemente.

Cenário 2 — Corrupção Grave

Aqui muda completamente.

Nunca seja herói.

Backup sempre vence.

Restore

Melhor prática.

Sempre.

DFSMSdss

RESTORE DATASET(...)

HSM

HRECOVER

FDR

RESTORE TYPE=DS

E se não existir backup?

Infelizmente acontece.

Mais vezes do que deveria.

Estratégia

Salvar o que for possível.

Criar novo dataset.

Tentar REPRO.

Descartar registros inválidos.

Reconstruir índices.

Alternate Index

Muitos esquecem do AIX.

Ele também pode corromper.

Rebuild

BLDINDEX

Ou.

Excluir.

Criar novamente.

Popular.

Recuperação de Catálogo

Uma área extremamente especializada.

Pouca gente domina.

Muito valorizada.

DIAGNOSE

DIAGNOSE

EXPORT

EXPORT -
CATALOG(MYCAT)
TEMPORARY

IMPORT

IMPORT CONNECT

Ambientes CICS

A situação muda bastante.

Especialmente em RLS.

SMSVSAM

Cache compartilhado.

Lock global.

Coupling Facility.

Múltiplas regiões.

Problemas comuns.

CF inconsistente.

Lock perdido.

Buffer inválido.

Procedimento

Fechar arquivos.

Verificar SMSVSAM.

Executar VERIFY.

EXAMINE.

Restore.

Abrir novamente.

Ambientes Bancários

O fluxo normalmente é.

Incidente aberto.

↓

Congelamento.

↓

Snapshot.

↓

LISTCAT.

↓

VERIFY.

↓

EXAMINE.

↓

Análise.

↓

Restore.

↓

Testes.

↓

Validação.

↓

Produção.

Testes Pós-Recovery

Nunca devolver imediatamente.

Teste.

Leia registros.

Atualize.

Delete.

Browse.

Sequencial.

Random.

Batch

Executar programas COBOL.

Validar.

Retorno.

SMF.

CPU.

EXCP.

CICS

Abrir arquivo.

Executar transações.

CRUD.

Commit.

Syncpoint.

IMS

DBOPEN.

GN.

GU.

REPL.

DLET.

Ferramentas Úteis

IDCAMS

DFSMSdss

DFSMShsm

FDR

LISTCAT

VERIFY

EXAMINE

BLDINDEX

DIAGNOSE

O que Aprendemos?

O Mainframe continua sendo uma das plataformas mais resilientes do planeta.

Mas nenhuma tecnologia é imune.

Discos falham.

Pessoas erram.

Jobs são cancelados.

Aplicações apresentam bugs.

Volumes ficam inconsistentes.

Catálogos podem sofrer danos.

A diferença entre um desastre e uma recuperação tranquila quase sempre está em três fatores.

Backup.

Procedimentos.

Conhecimento.

Um desenvolvedor COBOL que entende apenas READ, WRITE e REWRITE é valioso.

Um desenvolvedor que compreende LISTCAT, VERIFY, EXAMINE, REPRO, recuperação de catálogo e estratégias de restore torna-se um profissional muito mais próximo do universo de Sysprog, Storage e Administração z/OS.

E essa é justamente uma das características que mais diferencia especialistas Mainframe experientes.

Porque no fim do dia, quando o telefone toca e alguém diz:

"O arquivo de produção corrompeu..."

A pergunta deixa de ser:

"Quem programou isso?"

E passa a ser:

"Quem sabe trazer a base de volta?"

E, acredite, nas grandes corporações, essas pessoas são lembradas por muitos anos.

Bellacosa Mainframe

"Transformando mensagens IDCAMS em oportunidades de aprendizado, um café por vez."


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