Translate

Mostrar mensagens com a etiqueta IBM Db2. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta IBM Db2. Mostrar todas as mensagens

quinta-feira, 25 de junho de 2026

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.


sexta-feira, 3 de abril de 2026

💀 Seu COBOL ainda manda no mundo — e o IBM Db2 é o cérebro invisível por trás de bilhões de transações

 

Bellacosa Mainframe introduz o DB2

💀 “Seu COBOL ainda manda no mundo — e o IBM Db2 é o cérebro invisível por trás de bilhões de transações”

Se você acha que banco de dados é só “guardar informação”… prepare-se: no mundo corporativo pesado — bancos, seguradoras, governos — quem reina é a dupla COBOL + Db2.
E não, isso não é legado morto. Isso é infraestrutura crítica global.


🧬 Origem: quando dados viraram ciência

Antes do Db2, existia caos.

  • arquivos flat
  • duplicação
  • dificuldade de acesso

Então surge o modelo relacional, criado por Edgar F. Codd na IBM.

👉 Resultado:

  • tabelas
  • chaves
  • SQL

E nos anos 80 nasce o Db2, trazendo isso para o mundo enterprise.


🏛️ Db2 no Mainframe: onde o jogo é sério

O Db2 roda no z/OS, lado a lado com:

  • COBOL
  • CICS
  • IMS

💀 Tradução:

Isso aqui processa dinheiro de verdade


☕ O Dev COBOL Sênior (vida real)

Imagine um sistema bancário:

Cliente faz transferência → COBOL → Db2 → commit

💡 Exemplo COBOL + Db2

EXEC SQL
UPDATE CONTA
SET SALDO = SALDO - 100
WHERE ID = :ORIGEM
END-EXEC.

EXEC SQL
UPDATE CONTA
SET SALDO = SALDO + 100
WHERE ID = :DESTINO
END-EXEC.

EXEC SQL
COMMIT
END-EXEC.

👉 Simples? Sim.
👉 Crítico? ABSURDAMENTE.


🔄 Transações: o coração do sistema

Você viu isso no módulo — aqui é onde ganha vida:

START → UPDATE → COMMIT

Se falhar:

ROLLBACK

💀 Isso evita:

  • dinheiro sumir
  • inconsistência

📜 Logging: a caixa preta do banco

Db2 registra TUDO:

  • INSERT
  • UPDATE
  • DELETE

👉 Isso permite:

  • auditoria
  • recovery
  • rastreamento

💡 Insight

Sem log… você está cego
Com log… você reconstrói o passado


🔄 Recovery: sobrevivência do sistema

Cenário:

  • backup às 6:00
  • falha às 11:00

👉 solução:

Backup + Logs = estado correto

💾 Backup no mundo real

❄️ Cold

  • banco parado

🌡️ Warm

  • leitura apenas

🔥 Hot

  • banco online (produção)

💀 No banco:

parar sistema não é opção → usa hot backup


🔒 Locking: guerra silenciosa

3 programas acessando o mesmo registro:

App1 → lock
App2 → espera
App3 → leitura controlada

👉 Locks evitam corrupção


💡 Regra de ouro

Lock só é liberado no COMMIT


⚡ Performance: onde o DBA brilha

📦 Buffers

  • memória → rápido

📚 Index

  • busca instantânea

⚙️ Optimizer

  • escolhe melhor plano

👉 Exemplo:

Sem índice:

SELECT * FROM CLIENTE WHERE NOME='JOÃO';

Com índice:

CREATE INDEX IDX_NOME ON CLIENTE(NOME);

⚡ diferença absurda


🌐 Integração moderna (sim, Db2 evoluiu)

Hoje Db2 conversa com:

  • APIs
  • Java (JDBC)
  • ODBC
  • microservices

👉 Não é mais só terminal verde 😄


🧠 Stored Procedures: lógica dentro do banco

CREATE PROCEDURE TRANSFERIR(...)

👉 roda dentro do Db2
👉 menos rede
👉 mais performance


🧬 Easter Eggs & Curiosidades

💡 Db2 nasceu dentro da IBM Research
💡 COBOL ainda processa ~70% das transações financeiras mundiais
💡 Muitos sistemas críticos têm décadas sem downtime significativo


💀 Easter Egg raiz:

“If it ain’t broken, don’t migrate it”
(tradução: se está rodando há 30 anos… NÃO mexe 😄)


🔥 Insight nível Bellacosa

Mainframe não é legado…
é infraestrutura estável, segura e absurda em escala


🧠 Visão final (arquitetura)

Usuário → Aplicação (COBOL) → Db2 → Dados

Logs / Backup / Recovery

🚀 Conclusão

Você começou aprendendo:

  • o que é banco
  • modelos
  • DBMS
  • transações
  • logs
  • backup
  • performance

👉 E chegou aqui:

💀 Entendendo como o mundo financeiro roda


💥 Frase final

Enquanto todo mundo fala de cloud…
o dinheiro do mundo continua passando por COBOL + Db2

 

quarta-feira, 28 de agosto de 2024

IBM Z Resiliência : 30 Laboratórios Práticos Do "Meu Primeiro Sysplex" até "Meu Datacenter Nunca Para"

Bellacosa Mainframe e o laboratorio pratico em IBM Z Resiliencia




☕ O Holocron da Resiliência IBM Z

30 Laboratórios Práticos

Do "Meu Primeiro Sysplex" até "Meu Datacenter Nunca Para"

A Resiliência no IBM Z vai muito além de conhecer siglas como HA, DR, Parallel Sysplex ou GDPS. Ela representa uma filosofia de engenharia construída ao longo de décadas para garantir que aplicações críticas permaneçam disponíveis mesmo diante de falhas de hardware, software, rede ou até desastres naturais. O objetivo deste guia é conduzir o Programador COBOL, Analista de Sistemas ou futuro Sysprog por uma jornada progressiva, mostrando como cada componente da plataforma contribui para a continuidade do negócio e como todos trabalham em conjunto para entregar disponibilidade praticamente ininterrupta.

A melhor forma de aprender é evoluir em etapas. Comece dominando os conceitos fundamentais de SLA, RPO, RTO, RAS e Single Point of Failure. Em seguida, compreenda a arquitetura do IBM Z, estudando CPC, LPARs, HMC e o papel do LIC. Depois avance para Parallel Sysplex, Coupling Facility, WLM e GDPS, entendendo como múltiplos sistemas operam como um único ambiente resiliente. Na sequência, aprofunde-se em DFSMS, Storage, CICS, Db2, IMS, MQ e estratégias de recuperação e continuidade dos negócios.

Procure sempre relacionar teoria com prática. Analise mensagens do sistema, consulte o SDSF, estude relatórios RMF e SMF, desenhe arquiteturas, simule cenários de falha e questione como sua aplicação reagiria a cada situação. O profissional que compreende Resiliência deixa de enxergar apenas programas COBOL e passa a entender todo o ecossistema que mantém milhões de transações funcionando com segurança, desempenho e confiabilidade. Esse é o caminho para evoluir de Padawan a Mestre no universo IBM Z.



🟢 NÍVEL 1 — PADAWAN (Labs 1–10)

Lab 1 – Descobrindo a Arquitetura IBM Z

Objetivo

Identificar todos os componentes físicos do ambiente.

Atividades

  • Localizar CPC

  • Identificar LPARs

  • Ver HMC

  • Identificar Storage

Solução

O aluno deve desenhar a arquitetura mostrando como todos os componentes se conectam.


Lab 2 – Identificando SPOFs

Objetivo

Encontrar Single Points of Failure.

Atividades

Analisar:

  • Rede

  • Storage

  • CICS

  • MQ

  • Db2

Solução

Criar uma tabela

ComponenteExiste redundância?
StorageSim
SwitchNão
Servidor DNSNão

Lab 3 – Calculando SLA

Dado:

99,5%

99,9%

99,99%

99,999%

Calcule:

  • indisponibilidade anual

  • mensal

  • diária

Solução

Utilizar tabela oficial de SLA.


Lab 4 – Descobrindo o RPO

Uma empresa aceita perder:

  • nenhuma transação

  • cinco minutos

  • uma hora

Classifique o RPO.

Solução

Relacionar cada cenário ao objetivo de recuperação.


Lab 5 – Descobrindo o RTO

Mesmo exercício.

Agora considerando tempo de recuperação.


Lab 6 – CFIA

Escolha um ambiente.

Analise:

"O que acontece se..."

  • Storage parar

  • CPU parar

  • Switch parar

Solução

Construir matriz de impacto.


Lab 7 – Conhecendo o WLM

No SDSF identificar:

  • Service Classes

  • Importance

  • Velocity

Solução

Explicar porque um Job Batch ficou esperando.


Lab 8 – Explorando RMF

Consultar:

CPU

I/O

Paging

Storage

Solução

Gerar relatório resumido.


Lab 9 – Health Checker

Executar

F HZSPROC

Interpretar avisos.


Lab 10 – Runtime Diagnostics

Executar Runtime Diagnostics.

Interpretar:

  • Loop

  • Espera

  • Deadlock


🟡 NÍVEL 2 — JEDI (Labs 11–20)


Lab 11 – Criando um Sysplex

Desenhar:

2 LPARs

1 Coupling Facility

Storage compartilhado

Solução

Apresentar diagrama.


Lab 12 – Entendendo a Coupling Facility

Identificar:

  • Lock Structure

  • Cache Structure

  • List Structure

Explicar função de cada uma.


Lab 13 – Simulando Falha de um Membro

Desligar uma LPAR (ambiente de laboratório).

Observar:

  • usuários continuam?

  • aplicações continuam?


Lab 14 – ARM

Parar uma região CICS.

Verificar reinício automático.


Lab 15 – DVIPA

Mover uma aplicação entre membros.

Confirmar:

IP continua igual.


Lab 16 – Sysplex Distributor

Monitorar distribuição de sessões.

Verificar balanceamento.


Lab 17 – LBA

Analisar recomendações do Load Balancing Advisor.


Lab 18 – Capacity on Demand

Criar cenário:

Black Friday.

Qual recurso ativar?

CBU?

CUoD?

OOCoD?

Justifique.


Lab 19 – DFSMS

Criar:

Storage Group

Management Class

Storage Class

Data Class

Associar Dataset.


Lab 20 – DFSMShsm

Migrar um dataset.

Recuperá-lo.

Verificar tempo.


🔴 NÍVEL 3 — MESTRE (Labs 21–30)


Lab 21 – CICSplex

Desenhar:

TOR

AOR

FOR

DOR

Fluxo completo.


Lab 22 – MQ

Criar:

Queue

Sender

Receiver

Enviar mensagens.

Simular parada do receptor.

Confirmar persistência.


Lab 23 – Db2

Executar:

RUNSTATS

REORG

Comparar Access Path.


Lab 24 – IMS

Criar fluxo:

Terminal

TM

Programa

IMS DB

Resposta.


Lab 25 – Metro Mirror

Desenhar:

Site A

Site B

Replicação síncrona.

Explicar RPO.


Lab 26 – Global Mirror

Mesmo exercício.

Agora com longa distância.

Explicar diferenças.


Lab 27 – Business Continuity

Escreva um BCP contendo:

  • responsáveis

  • comunicação

  • ordem de recuperação

  • testes


Lab 28 – Simulação Completa

O cenário:

🔥 Incêndio no Data Center Principal.

O aluno deve decidir:

  • ativa GDPS?

  • ativa CBU?

  • usa Metro Mirror?

  • muda DNS?

  • inicia ARM?

Justificar todas as decisões.


Lab 29 – Projeto de Arquitetura

Receba:

Banco Digital

20 milhões de clientes

PIX

Cartão

Internet Banking

Desenhe:

  • Hardware

  • Sysplex

  • CICSplex

  • MQ

  • Db2

  • Storage

  • DR


Lab 30 – O Desafio Final do Mestre

A empresa deseja atingir:

  • 99,999% de disponibilidade

  • RPO = Zero

  • RTO = Menor que 5 minutos

  • Dois datacenters ativos

  • 50 milhões de transações por dia

  • Atualizações sem parada

  • Crescimento de capacidade sem desligamento

Missão

Projetar toda a arquitetura IBM Z.

O projeto deve incluir:

  • IBM Z (CPCs e LPARs)

  • Parallel Sysplex

  • Coupling Facility

  • WLM

  • SFM

  • ARM

  • CICSplex (TOR, AOR, FOR e DOR)

  • IBM MQ

  • Db2 for z/OS

  • IMS (quando aplicável)

  • DFSMS

  • IBM Copy Services Manager

  • Metro Mirror ou Global Mirror

  • GDPS

  • Business Continuity Plan

  • Capacity on Demand (CBU, CUoD ou OOCoD)

Solução esperada

O aluno entrega um documento de arquitetura contendo:

  • diagrama completo da solução;

  • justificativa técnica para cada componente;

  • estratégia de alta disponibilidade;

  • estratégia de recuperação de desastres;

  • cálculo de SLA, RPO e RTO;

  • análise de Single Points of Failure e respectivas eliminações;

  • plano de testes de contingência;

  • plano de crescimento para os próximos cinco anos.


🏆 Certificação Bellacosa Mainframe

Ao concluir os 30 laboratórios, o aluno terá praticado os principais conceitos de resiliência do IBM Z, passando da compreensão dos fundamentos até o desenho de arquiteturas corporativas. Essa sequência é adequada tanto para um Programador COBOL Júnior que deseja entender a plataforma onde suas aplicações executam quanto para profissionais que pretendem evoluir para funções de Analista de Infraestrutura IBM Z, Sysprog, Especialista em Alta Disponibilidade ou Arquiteto Mainframe. Ela também pode servir como base para um curso completo de aproximadamente 40 horas, com exercícios, estudos de caso e desafios progressivos. 

segunda-feira, 27 de maio de 2024

Resiliência IBM Z – O Coração das Aplicações Resilientes: Como CICS, Db2, MQ e IMS - Parte V

 

Bellacosa Mainframe e a resiliencia ibm z parte v

☕ Um Café no Bellacosa Mainframe

O Holocron da Resiliência IBM Z

Parte V – O Coração das Aplicações Resilientes: Como CICS, Db2, MQ e IMS Mantêm Milhões de Transações Sempre Disponíveis

"Hardware poderoso impressiona. Mas são as aplicações que entregam valor ao negócio. O verdadeiro desafio é garantir que elas continuem funcionando mesmo quando tudo ao redor muda."

Até aqui nossa jornada mostrou que a Resiliência no IBM Z não depende apenas de computadores robustos.

Conhecemos conceitos como RAS, SLA e Disaster Recovery.

Descobrimos como o hardware foi projetado para detectar falhas antes mesmo que elas aconteçam.

Vimos como o Parallel Sysplex permite que vários mainframes trabalhem como um único sistema.

Também aprendemos que o armazenamento IBM Z é inteligente, automatizado e capaz de crescer sem interromper o negócio.

Mas falta responder uma pergunta.

Quem realmente atende o cliente?

Quem responde uma consulta bancária?

Quem realiza uma transferência PIX?

Quem grava um pagamento?

Quem consulta uma apólice de seguro?

Quem processa uma compra no cartão de crédito?

A resposta está no conjunto de tecnologias conhecido como middleware.

São elas que transformam toda aquela infraestrutura invisível em serviços utilizados diariamente por milhões de pessoas.

Os conceitos desta parte abrangem IBM MQ, IBM Db2 for z/OS, CICS, CICS Transaction Server (CICS TS), z/OS Workload Manager Health API, Automatic Restart Manager (ARM), CICSplex, TOR, AOR, DOR, FOR, IMS, IMS DB, Transaction Manager, HALDB, Fast Database Recovery (FDBR) e IMS Database Recovery Control (DBRC). Esses componentes aparecem na seção final do glossário IBM Z Resiliency.


O Que é Middleware?

Imagine uma cidade.

Existe energia elétrica.

Existe abastecimento de água.

Existe internet.

Existe transporte.

Tudo isso representa a infraestrutura.

Mas quem realmente atende o cidadão?

Os hospitais.

Os bancos.

Os supermercados.

As escolas.

No IBM Z acontece exatamente a mesma coisa.

Hardware, Storage e Sysplex representam a infraestrutura.

CICS, Db2, MQ e IMS representam os serviços utilizados pelo negócio.

É ali que mora a aplicação COBOL.


CICS – O Grande Atendente do Mainframe

Poucas tecnologias marcaram tanto a história da computação quanto o Customer Information Control System, mais conhecido como CICS.

Imagine uma agência bancária.

Cada cliente chega ao caixa.

Faz uma solicitação.

Recebe uma resposta.

Sai.

O próximo cliente é atendido.

O CICS faz exatamente isso.

Milhares de usuários enviam requisições simultaneamente.

O CICS organiza tudo.

Distribui recursos.

Executa programas COBOL.

Gerencia transações.

Controla segurança.

Coordena acesso aos dados.

Sem ele, grande parte das aplicações online simplesmente não existiria.


CICS Transaction Server

O CICS TS representa a evolução moderna do CICS.

Hoje ele suporta:

  • APIs REST;

  • JSON;

  • Web Services;

  • Java;

  • Eventos;

  • Integração com Cloud;

  • Containers e Channels;

  • Threadsafe;

  • OpenTelemetry;

  • Segurança moderna.

Muita gente imagina que o CICS ficou preso aos terminais verdes.

Na realidade ele conversa diariamente com aplicativos Android, iPhones, internet banking, caixas eletrônicos e sistemas distribuídos.

O COBOL continua executando.

A tecnologia ao redor evoluiu.


Db2 for z/OS – O Guardião dos Dados

Toda empresa possui seu patrimônio.

No banco...

São as contas.

Na seguradora...

São as apólices.

Na companhia aérea...

São as reservas.

Quem protege essas informações?

O Db2.

Ele garante:

  • consistência;

  • concorrência;

  • recuperação;

  • integridade;

  • desempenho.

Quando dois milhões de pessoas consultam saldo simultaneamente, o Db2 coordena milhares de operações concorrentes sem comprometer a integridade dos dados.


IBM MQ – O Carteiro que Nunca Dorme

Imagine uma empresa gigantesca.

Nem todos os departamentos trabalham no mesmo horário.

Mesmo assim as mensagens precisam chegar.

O IBM MQ resolve exatamente esse problema.

Ele entrega mensagens com segurança.

Mesmo que o destinatário esteja temporariamente indisponível.

Isso desacopla aplicações.

Aumenta a disponibilidade.

Facilita integrações.

É por isso que tantas arquiteturas modernas utilizam filas.


Quando Tudo Acontece ao Mesmo Tempo

Imagine um PIX.

Em poucos segundos acontecem dezenas de operações.

O aplicativo envia a solicitação.

O CICS recebe a transação.

O COBOL valida regras de negócio.

O Db2 consulta contas.

O MQ envia notificações.

Outro sistema recebe a mensagem.

Tudo precisa acontecer praticamente em tempo real.

Se qualquer componente falhar...

Toda a experiência do cliente será afetada.

É por isso que a Resiliência é tão importante.


CICSplex – Um CICS Nunca Vem Sozinho

Assim como existe o Parallel Sysplex...

Também existe o CICSplex.

Ele reúne diversos ambientes CICS trabalhando em conjunto.

Para o usuário...

Existe apenas um sistema.

Na realidade podem existir dezenas de regiões distribuindo carga automaticamente.


TOR – Terminal Owning Region

Imagine a recepção de um grande hospital.

Ela recebe os pacientes.

Mas não realiza cirurgias.

O TOR funciona assim.

Ele recebe as conexões dos usuários.

Depois encaminha cada solicitação para outra região responsável pelo processamento.


AOR – Application Owning Region

Agora chegamos ao verdadeiro coração da aplicação.

É na AOR que executam os programas COBOL.

Toda lógica de negócio vive aqui.

Quanto mais regiões AOR existirem...

Maior poderá ser a capacidade de processamento.


FOR – File Owning Region

Algumas aplicações acessam milhares de arquivos VSAM.

Em vez de cada região abrir esses arquivos individualmente...

Existe a FOR.

Ela centraliza esse acesso.

Reduz conflitos.

Melhora desempenho.

Simplifica administração.


DOR – Data Owning Region

A DOR segue filosofia semelhante.

Ela concentra determinados recursos de dados compartilhados entre diversas aplicações.

Essa separação facilita manutenção e escalabilidade.


WLM Health API

Lembra do Workload Manager?

Agora imagine que o próprio middleware possa informar ao WLM seu estado de saúde.

É exatamente essa a função da Health API.

O WLM deixa de observar apenas consumo de CPU.

Ele passa a considerar também a qualidade do serviço entregue pelas aplicações.


Automatic Restart Manager

Na Parte III conhecemos o ARM.

Agora podemos entender seu impacto real.

Se uma região CICS terminar inesperadamente...

O ARM pode reiniciá-la automaticamente.

Sem operadores.

Sem intervenção humana.

Sem perda significativa de disponibilidade.


IMS – O Veterano Que Continua Jovem

Muito antes da internet existir...

O IMS já processava milhões de transações.

Hoje continua fazendo exatamente isso.

O Information Management System permanece como um dos ambientes transacionais mais rápidos do mundo.

Muitas aplicações financeiras ainda dependem dele diariamente.


IMS DB

O banco de dados IMS possui características próprias.

Sua organização hierárquica oferece desempenho extremamente elevado para determinadas cargas de trabalho.

Quando corretamente modelado, consegue responder consultas com velocidade impressionante.


Transaction Manager

O IMS TM coordena o processamento online.

Recebe requisições.

Controla filas.

Executa programas.

Gerencia recuperação.

Mantém a integridade das transações.

É o equivalente, dentro do universo IMS, ao papel desempenhado pelo CICS em inúmeras aplicações.


HALDB – Crescendo Sem Limites

Com o passar dos anos, algumas bases IMS tornaram-se gigantescas.

O High Availability Large Database foi criado para resolver esse desafio.

Ele divide grandes bancos de dados em partições.

Assim é possível:

  • aumentar capacidade;

  • reduzir tempo de manutenção;

  • melhorar disponibilidade;

  • facilitar reorganizações.

Tudo isso mantendo o sistema online.


Fast Database Recovery

Imagine um acidente.

Quanto mais rápido a recuperação...

Menor o impacto.

O FDBR acelera a recuperação das bases IMS após falhas.

Isso reduz significativamente o RTO.


IMS Database Recovery Control

Toda recuperação precisa ser coordenada.

O DBRC registra informações fundamentais sobre backups, logs e processos de recuperação.

Ele garante que as bases sejam restauradas corretamente.

Sem perda de consistência.


O Que um Programador COBOL Deve Aprender?

Muitos iniciantes acreditam que basta dominar a linguagem COBOL.

Na prática...

O código representa apenas uma parte da aplicação.

Um profissional IBM Z moderno precisa compreender:

  • como o CICS gerencia transações;

  • como o Db2 protege dados;

  • como o MQ integra sistemas;

  • como o IMS processa grandes volumes;

  • como a infraestrutura garante disponibilidade.

Quanto maior essa visão...

Maior será sua capacidade de construir aplicações resilientes.


O Legado do IBM Z

Existe um motivo pelo qual bancos processam bilhões de transações utilizando tecnologias criadas há décadas.

Elas nunca pararam de evoluir.

O CICS conversa com APIs REST.

O Db2 trabalha com analytics e inteligência artificial.

O MQ conecta aplicações distribuídas.

O IMS continua ampliando desempenho e disponibilidade.

Nada permaneceu parado no tempo.

O legado do IBM Z não é tecnologia antiga.

É tecnologia que amadureceu continuamente sem abandonar aquilo que sempre fez melhor: processar transações críticas com confiabilidade, desempenho e resiliência.

No próximo capítulo do Holocron da Resiliência IBM Z, concluiremos nossa jornada explorando IBM Copy Services Manager (CSM), Metro Mirror, Global Mirror, XRC, Zero Data Loss (ZDL), Coupling Data Sets (CDS), Business Continuity Plan (BCP) e as estratégias que permitem proteger informações mesmo diante de desastres de grande escala, fechando o ciclo completo da Resiliência no IBM Z.