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: , , , , , , , , , , , , ,

Hybrid Search no Db2: Quando SQL Encontra Inteligência Artificial (e o Banco de Dados Aprende a Entender Pessoas)

 

Bellacosa Mainframe e o hybrid search no db2

☕ Um Café no Bellacosa Mainframe

Hybrid Search no Db2: Quando SQL Encontra Inteligência Artificial (e o Banco de Dados Aprende a Entender Pessoas)

Como o Db2 12.1.5 transformou o banco relacional em uma plataforma de IA para busca semântica, RAG e aplicações inteligentes.

"Durante décadas perguntávamos ao banco de dados 'onde está este registro?'. Agora começamos a perguntar 'o que você sabe sobre este assunto?'. Essa pequena mudança muda absolutamente tudo."

Introdução

Se você programa em COBOL, trabalha com Db2, escreve SQL diariamente ou administra ambientes IBM, talvez tenha ouvido alguém dizer recentemente:

"O Db2 agora suporta Hybrid Search."

E a primeira reação costuma ser:

"Legal... mas o que exatamente isso significa?"

Se você pensou isso, prepare seu café.

Porque essa novidade representa uma das maiores mudanças conceituais do Db2 desde a chegada do suporte nativo a JSON, XML e às tecnologias modernas de integração.

Não estamos falando de mais um índice.

Nem de um novo tipo de tabela.

Estamos falando de ensinar um banco de dados a procurar significados, e não apenas palavras.

Uma pequena viagem no tempo

Durante praticamente cinquenta anos, bancos de dados responderam perguntas muito simples.

Você perguntava:

SELECT *
FROM CLIENTES
WHERE CPF='12345678900';

O banco respondia imediatamente.

Perfeito.

Depois surgiram buscas textuais.

Por exemplo:

SQLCODE -904

ou

CICS RESP 16

O banco localizava exatamente aquelas palavras.

Ainda perfeito.

Mas então chegou a IA.

E os usuários começaram a perguntar coisas como:

"Por que meu batch fica preso durante a madrugada?"

Ou:

"Existe algum programa parecido com este COBOL?"

Ou ainda:

"Onde existe documentação sobre autenticação?"

Nenhuma dessas perguntas possui uma resposta baseada apenas em igualdade de caracteres.

É aí que nasce a busca vetorial.

O problema da busca tradicional

Imagine uma documentação contendo:

Resource unavailable

Deadlock

Timeout

IRLM contention

Agora imagine que alguém pesquisa:

Meu programa trava esperando recursos.

Nenhuma palavra coincide.

Resultado?

0 documentos encontrados

Mas qualquer analista experiente sabe que provavelmente o problema é exatamente um deadlock ou contenção.

O computador não sabia.

A IA sabe.

Keyword Search

Na figura apresentada pelo autor vemos dois blocos.

O primeiro é:

Keyword Search

Essa é a busca clássica.

Ela utiliza motores especializados como:

  • OpenSearch

  • Elasticsearch

Esses motores trabalham com índices invertidos.

Em vez de procurar documento por documento, eles mantêm enormes catálogos de palavras.

Por exemplo:

SQLCODE

↓

Documento 14

Documento 39

Documento 122

ou

COBOL

↓

Documento 2

Documento 98

Documento 430

É extremamente rápido.

E extremamente preciso.

Onde ela é excelente?

Quando você procura:

  • CPF

  • CNPJ

  • Número de pedido

  • Código do produto

  • SQLCODE

  • Nome de programa

  • VSAM KSDS

  • DSNUTILB

  • IKJEFT01

Ela é praticamente imbatível.

Mas existe um limite...

Ela não entende contexto.

Para ela,

erro de conexão

é completamente diferente de

falha de comunicação

Mesmo que um ser humano saiba que são praticamente a mesma coisa.

A revolução dos Embeddings

Agora chegamos ao conceito mais importante.

Quando falamos em IA Generativa existe uma palavra que aparece o tempo inteiro:

Embedding.

Imagine duas frases.

Cliente perdeu acesso.

e

Usuário não consegue entrar.

São palavras diferentes.

Mas possuem praticamente o mesmo significado.

Como um computador entende isso?

Transformando texto em matemática.

Cada documento vira um enorme vetor.

Algo parecido com:

[0.27,
0.81,
-0.19,
...
768 números]

Ou até

1536 dimensões

dependendo do modelo utilizado.

Esses números representam o significado do texto.

Curiosidade

Quando falamos "vetor", muita gente imagina apenas três dimensões.

Como:

X

Y

Z

Na IA isso não existe.

Os vetores normalmente possuem:

  • 384 dimensões

  • 768 dimensões

  • 1024 dimensões

  • 1536 dimensões

  • 3072 dimensões

Cada dimensão captura alguma característica semântica aprendida pelo modelo.

Nenhum ser humano consegue visualizar isso.

Mas algoritmos conseguem calcular a distância entre dois vetores em microssegundos.

Db2 12.1.2: o primeiro passo

A IBM deu um passo importante com o Db2 12.1.2, quando introduziu armazenamento nativo de vetores (Vector Data Type) e busca por similaridade.

Isso permitiu guardar embeddings diretamente nas tabelas do Db2 e realizar consultas de vizinhos mais próximos (Nearest Neighbor Search), sem depender obrigatoriamente de um banco vetorial dedicado.

Na prática, o Db2 passou a ser capaz de responder perguntas como:

"Quais documentos possuem significado semelhante a este?"

Era metade do caminho para aplicações de IA.

Db2 12.1.5: nasce o Hybrid Search

A verdadeira virada acontece com o Db2 12.1.5, disponibilizado pela IBM em 2025, quando foi anunciada a integração entre o mecanismo vetorial do Db2 e motores de busca como OpenSearch e Elasticsearch.

Agora temos duas pesquisas acontecendo simultaneamente:

Keyword Search

Vector Search

E ambas convergem para um único ranking.

Esse conceito recebe o nome de:

Hybrid Search.

Unified Ranking

Talvez este seja o recurso mais inteligente de toda a arquitetura.

Imagine uma pergunta:

Como resolver SQLCODE -904?

A busca por palavras encontra:

SQLCODE -904

Já a busca vetorial localiza documentos que mencionam:

  • Resource unavailable

  • Tablespace offline

  • Dataset indisponível

  • Problemas de I/O

  • Lock de recurso

Mesmo sem citar literalmente o código.

Agora imagine que os resultados sejam combinados.

Em vez de duas listas diferentes, temos apenas uma:

1 Documento A

2 Documento B

3 Documento C

4 Documento D

Todos classificados pela relevância.

É isso que o Unified Ranking faz.

Como essa arquitetura funciona?

                 Pergunta

                     │

                     ▼

      "Como resolver timeout?"

                     │

      ┌──────────────┴──────────────┐

      ▼                             ▼

Keyword Search               Vector Search

(OpenSearch)                 (Db2 Native)

      ▼                             ▼

         Unified Ranking

                 ▼

      Documentos Relevantes

                 ▼

         Large Language Model

                 ▼

          Resposta Final

Perceba algo interessante.

O LLM não pesquisa diretamente.

Quem faz a pesquisa continua sendo o banco.

A IA apenas utiliza os documentos encontrados.

Esse é exatamente o princípio do RAG (Retrieval-Augmented Generation).

E onde entra o SQL?

A primeira coisa que muitos desenvolvedores COBOL perguntam é:

"Vou parar de usar SQL?"

A resposta é:

Não.

Na verdade, você usará ainda mais SQL.

O que muda é que agora existirão novas funções relacionadas a vetores, similaridade e integração com índices textuais.

O SQL continua sendo o coração da solução.

Exemplo prático para quem trabalha com COBOL

Imagine um repositório com:

  • 18.000 programas COBOL

  • 12.000 Copybooks

  • 4.000 Jobs JCL

  • 8.000 documentos técnicos

  • 30 anos de documentação

Um programador novo pergunta:

"Existe alguma rotina semelhante ao cálculo de juros compostos?"

Nenhum programa chama exatamente:

JUROS_COMPOSTOS

Mas diversos possuem comentários como:

Interest calculation

Financial accrual

Capitalization

A busca vetorial encontra todos eles.

A busca lexical encontra aqueles que realmente possuem a palavra "juros".

O Hybrid Search combina tudo.

Outro exemplo

Imagine pesquisar:

Problemas de autenticação RACF

Keyword encontra:

RACF

Vector encontra:

Security

Authorization

Login

Access denied

SAF

ACEE

Muito mais inteligente.

Por que OpenSearch?

Muita gente pergunta:

"Se o Db2 já possui vetor, por que usar OpenSearch?"

Porque são especialidades diferentes.

O OpenSearch continua sendo excelente para:

  • Full Text Search

  • BM25

  • Índices invertidos

  • Autocomplete

  • Facetas

  • Ranking lexical

Enquanto o Db2 faz muito bem:

  • SQL

  • Dados relacionais

  • Vetores

  • Similaridade

Cada um faz aquilo em que é especialista.

Curiosidade

O OpenSearch nasceu quando a Amazon criou um fork aberto do Elasticsearch após mudanças no licenciamento da Elastic.

Hoje ambos continuam extremamente populares.

O Db2 consegue integrar com os dois.

Easter Egg nº 1

Se você já assistiu Star Wars, pense assim.

Keyword Search é como procurar um Jedi pelo nome.

Luke Skywalker

Vector Search é usar a Força.

Você sente que alguém está ali mesmo sem saber exatamente quem é.

Hybrid Search?

É usar os dois ao mesmo tempo.

Easter Egg nº 2

Quem cresceu usando Google provavelmente nunca percebeu.

Quando você pesquisa:

carro vermelho

O Google não procura apenas essas duas palavras.

Ele tenta entender intenção.

Hybrid Search leva essa mesma filosofia para dentro do banco de dados corporativo.

Easter Egg nº 3

O famoso comando do TSO:

FIND

procura caracteres.

O Hybrid Search procura conhecimento.

É uma evolução conceitual parecida com sair de um índice telefônico para um assistente inteligente.

Onde veremos isso nos próximos anos?

Praticamente em todos os sistemas corporativos.

Imagine:

✔ Assistente para COBOL.

✔ Pesquisa inteligente em JCL.

✔ Busca em documentação CICS.

✔ Pesquisa em milhares de Stored Procedures.

✔ Localização automática de código semelhante.

✔ Descoberta de APIs relacionadas.

✔ Pesquisa em incidentes históricos.

✔ Chatbots internos.

✔ Copilotos para desenvolvedores.

O impacto para quem trabalha com Mainframe

Durante muito tempo existiu o mito de que IA e Mainframe eram mundos separados.

Hoje isso não faz mais sentido.

O Mainframe continua sendo responsável pelas informações mais críticas das empresas.

A IA precisa exatamente dessas informações.

E o Db2 está se tornando uma ponte entre esses dois universos.

Em vez de exportar tudo para outra plataforma, é possível realizar boa parte da recuperação inteligente diretamente onde os dados já estão, mantendo segurança, governança e consistência.

Dicas para o programador júnior

  • Continue estudando SQL. Ele continua sendo indispensável.

  • Aprenda conceitos de IA, mas não abandone fundamentos de banco de dados.

  • Entenda o que são embeddings, similaridade e RAG.

  • Familiarize-se com OpenSearch e Elasticsearch.

  • Estude como modelos de linguagem utilizam bases corporativas.

  • Explore as novidades do Db2 12.1.x e acompanhe os anúncios da IBM sobre recursos de IA.

Conclusão

Durante décadas, a missão do Db2 foi responder perguntas objetivas sobre dados estruturados. Com a chegada do suporte a vetores no Db2 12.1.2 e da integração com OpenSearch e Elasticsearch no Db2 12.1.5, o banco passa a participar de uma nova geração de aplicações capazes de compreender contexto e significado.

Essa evolução não substitui SQL nem elimina a importância dos índices tradicionais. Pelo contrário: combina o melhor dos dois mundos. A busca lexical continua sendo excelente para códigos, identificadores e termos exatos, enquanto a busca vetorial amplia a capacidade de encontrar conceitos relacionados, mesmo quando as palavras utilizadas pelo usuário são diferentes daquelas presentes nos documentos.

Para quem desenvolve em COBOL, administra ambientes IBM ou trabalha com arquitetura de sistemas, entender Hybrid Search significa compreender como serão construídos os copilotos, os assistentes técnicos e as soluções RAG que deverão fazer parte do ecossistema corporativo nos próximos anos.

A tecnologia muda. Os princípios permanecem. E talvez a maior lição seja esta: o Db2 continua sendo um banco de dados extraordinário, mas agora ele também começa a compreender o significado das perguntas que fazemos. Isso representa uma mudança de paradigma tão importante quanto a adoção do SQL décadas atrás e coloca o ecossistema IBM em uma posição estratégica para a era da Inteligência Artificial.


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

Tsuihou Sareta Tensei Juukishi wa Game Chishiki de Musou Suru

 

Bellacosa Mainframe apresenta tsuihou sareta tensei

☕ Um Café no Bellacosa Mainframe

Tsuihou Sareta Tensei Juukishi wa Game Chishiki de Musou Suru (追放された転生重騎士はゲーム知識で無双する)

Quando um Programador COBOL Descobre que a Classe Mais Desprezada Pode Ser a Mais Poderosa do Sistema

"No IBM Z existe uma velha lição: nunca julgue um programa pelo nome do módulo. Os maiores sistemas bancários do mundo ainda rodam em tecnologias que muitos chamam de ultrapassadas. Este anime ensina exatamente essa filosofia."

Ficha Técnica

  • Título Original: 追放された転生重騎士はゲーム知識で無双する

  • Romaji: Tsuihou Sareta Tensei Juukishi wa Game Chishiki de Musou Suru

  • Título em inglês: The Exiled Heavy Knight Knows How to Game the System

  • Autor (Light Novel): Nekoko

  • Ilustrações: Jaian

  • Mangá: Lee Brocco

  • Estúdio: GoHands

  • Direção: Katsumasa Yokomine, com Shingo Suzuki e Tetsuichi Yamagishi como diretores-chefes

  • Música: Ludvig Forssell

  • Estreia do anime: 3 de julho de 2026

  • Formato: TV

  • Temporada: Verão de 2026

  • Episódios: 26 (dois cours consecutivos)

  • Duração: cerca de 23 minutos por episódio

  • Classificação: PG-13

  • Gêneros: Ação, Fantasia, Aventura

  • Temas: Isekai, Reencarnação, RPG, Game Knowledge  

A premissa

Imagine descobrir que toda sua vida acontece dentro do MMORPG que você jogava antes de morrer.

Agora imagine conhecer absolutamente todas as regras escondidas daquele jogo.

É exatamente isso que acontece.

Elma Edvan nasce em uma tradicional família de espadachins.

Ao completar quinze anos recebe sua Classe Divina.

Todos esperam uma classe lendária.

Mas recebe:

Heavy Knight (重騎士)

Uma classe considerada inútil.

É imediatamente expulso da família.

Só que existe um detalhe.

Ele recupera as memórias da vida anterior.

E lembra perfeitamente daquele jogo.

Enquanto todos enxergam uma classe fraca...

Ele sabe que encontrou uma das builds mais absurdamente fortes já criadas.

O verdadeiro protagonista não é Elma

É o conhecimento.

A maioria dos isekais possui protagonistas que vencem porque:

  • nasceram fortes;

  • receberam poderes divinos;

  • ganharam habilidades quebradas;

  • receberam um cheat.

Aqui não.

Elma vence porque estudou.

Ele conhece:

  • árvores de habilidades;

  • atributos escondidos;

  • combinações secretas;

  • itens raros;

  • rotas alternativas;

  • chefes opcionais;

  • eventos futuros;

  • bugs;

  • mecânicas esquecidas.

Ele simplesmente joga melhor do que todo mundo.

Bellacosa Mainframe explica

Imagine um jovem programador dizendo:

COBOL morreu.

Um veterano apenas sorri.

Porque ele conhece coisas que o iniciante ainda não viu.

Conhece:

  • CICS

  • Db2

  • IMS

  • MQ

  • RACF

  • JES2

  • VSAM

  • WLM

O iniciante olha apenas para a sintaxe.

O veterano conhece toda a arquitetura.

Elma faz exatamente isso.

Todos olham para a classe.

Ele olha para o sistema.

A filosofia escondida

Este anime não fala sobre força.

Fala sobre informação.

Quem possui mais conhecimento controla o jogo.

Essa é exatamente a realidade da informática.

Um profissional comum conhece comandos.

Um especialista conhece:

  • arquitetura;

  • limitações;

  • otimizações;

  • comportamento interno.

É isso que diferencia um programador comum de um arquiteto de software.

O Estúdio GoHands

A GoHands nunca foi um estúdio comum.

Ela possui um estilo extremamente reconhecível.

Características:

  • movimentos constantes de câmera;

  • profundidade exagerada;

  • reflexos intensos;

  • iluminação cinematográfica;

  • cenários digitais muito detalhados;

  • animação bastante fluida.

Produções conhecidas:

  • K

  • Hand Shakers

  • W'z

  • The Masterful Cat Is Depressed Again Today

Seu estilo divide opiniões: alguns fãs adoram a identidade visual ousada, enquanto outros acham os movimentos de câmera excessivos. Nas primeiras semanas de exibição, essa discussão voltou a aparecer entre o público.  

Os personagens

Elma Edvan

O protagonista.

Calmo.

Analítico.

Calculista.

Nunca desperdiça recursos.

Lembra bastante um bom analista de produção.

Luce Rubis

Sua principal companheira.

Ajuda na evolução da jornada.

Também representa a confiança construída através da competência.

Maris Edvan

Ligada ao núcleo familiar.

Mostra o peso das expectativas sociais.

Ares

Um dos personagens importantes na construção política do mundo.

Aizas Edvan

Representa a antiga estrutura de poder da família. (Anime.Jepang.org)

O que torna este anime diferente?

Existem dezenas de isekais sobre:

  • herói escolhido;

  • rei demônio;

  • magia infinita;

  • espada lendária.

Este escolhe outro caminho.

Seu foco está em:

Engenharia de sistemas.

É praticamente um anime sobre engenharia reversa de um RPG.

O protagonista pensa como um desenvolvedor.

A metáfora perfeita para COBOL

Heavy Knight.

Uma classe considerada lenta.

Pesada.

Sem glamour.

Parece familiar?

Durante décadas disseram exatamente isso sobre COBOL.

Enquanto isso...

Bilhões de dólares continuam sendo processados diariamente.

Assim como o Heavy Knight, COBOL nunca precisou ser bonito.

Precisou ser eficiente.

As aventuras

Ao longo da história Elma enfrenta:

  • monstros;

  • dungeons;

  • nobres corruptos;

  • aventureiros arrogantes;

  • sistemas políticos;

  • limitações das classes.

Mas seu maior inimigo sempre é o mesmo:

o preconceito.

As pessoas acreditam conhecer o sistema.

Sem nunca estudá-lo.

Mensagens ocultas

1. A sociedade vive de consenso

Todos dizem que Heavy Knight é ruim.

Ninguém verifica.

Isso acontece diariamente na tecnologia.

"COBOL morreu."

"Mainframe acabou."

"Batch é antigo."

São frases repetidas por quem nunca abriu um ISPF.

2. Conhecimento supera talento

Elma não possui magia infinita.

Possui experiência.

É exatamente o que diferencia um profissional sênior.

3. Meta muda

O anime mostra um conceito conhecido pelos jogadores:

META.

A melhor estratégia muda.

Na tecnologia também.

Hoje temos:

  • IA

  • Cloud

  • Containers

  • Kubernetes

Mas os sistemas centrais continuam sustentando bancos, governos e seguradoras.

4. Engenharia vence improviso

Cada decisão do protagonista parece uma revisão de arquitetura.

Ele não resolve problemas.

Ele evita criá-los.

Paralelo com IBM Z

No RPG:

Classe
↓
Atributos
↓
Skills
↓
Equipamentos
↓
Build
↓
Resultado

No Mainframe:

COBOL
↓
JCL
↓
Db2
↓
CICS
↓
MQ
↓
Performance

Nenhum componente resolve tudo sozinho.

O poder está na integração.

Impacto cultural

A obra já era popular como web novel, depois ganhou light novel e mangá, impulsionando a adaptação em anime. Entre leitores e espectadores, ela costuma ser destacada por tratar as mecânicas de RPG de forma mais consistente do que muitos títulos do gênero: o protagonista vence por entender a evolução do "meta" do jogo, e não porque todos ao redor são incompetentes.  

O anime também reacendeu discussões sobre o estilo visual da GoHands, um estúdio conhecido por escolhas artísticas marcantes e pouco convencionais.  

O ensinamento para um Programador COBOL Padawan

Este anime ensina algo que vale mais do que qualquer habilidade especial.

Não existe tecnologia fraca.

Existe tecnologia mal compreendida.

Assim como o Heavy Knight escondia um potencial gigantesco sob uma reputação injusta, o COBOL e o IBM Z continuam sustentando operações críticas porque foram projetados com foco em robustez, confiabilidade e evolução contínua.

No universo Bellacosa Mainframe, a maior lição é simples:

O verdadeiro profissional não é aquele que segue a moda. É aquele que entende profundamente as regras do sistema, encontra oportunidades onde todos enxergam limitações e transforma conhecimento em vantagem competitiva.

Esse é o verdadeiro "game knowledge" — tanto no anime quanto no mundo real.

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: , , , , , , , , , , , , , ,
Subscrever: Mensagens (Atom)