🟦 Exemplo de Programa COBOL – Tratamento de Mensagem IBM MQ

🎯 O que este programa faz

1. Conecta ao Queue Manager

2. Abre uma fila de entrada

3. Lê uma mensagem (MQGET)

4. Trata o conteúdo

5. Atualiza dados (simulado)

6. Faz COMMIT

7. Fecha fila e desconecta

---

🧱 Premissas do exemplo

• Execução:

  • Batch ou CICS (a lógica é a mesma)

• Fila:

  • QUEUE.IN

• Queue Manager:

  • QMGR01

• Mensagem:

  • Texto simples

• Modelo:

  • MQI síncrono

  • Commit explícito

---

📦 COPYBOOKS NECESSÁRIOS

       COPY CMQC.
       COPY CMQX.

📌 Esses copybooks vêm do IBM MQ for z/OS
Normalmente ficam em SCSQCOBC.

---

🧠 Estrutura do Programa

---

🔹 IDENTIFICATION DIVISION

       IDENTIFICATION DIVISION.
       PROGRAM-ID. MQCONSUM.

---

🔹 DATA DIVISION

       DATA DIVISION.
       WORKING-STORAGE SECTION.

       01  WS-QMGR-NAME        PIC X(48) VALUE 'QMGR01'.
       01  WS-QUEUE-NAME       PIC X(48) VALUE 'QUEUE.IN'.

       01  WS-HCONN            PIC S9(9) COMP.
       01  WS-HOBJ             PIC S9(9) COMP.

       01  WS-COMPCODE         PIC S9(9) COMP.
       01  WS-REASON           PIC S9(9) COMP.

       01  WS-MSG-LEN          PIC S9(9) COMP.
       01  WS-BUFFER.
           05 WS-MSG           PIC X(1024).

       01  WS-MD               LIKE MQMD.
       01  WS-GMO              LIKE MQGMO.
       01  WS-OD               LIKE MQOD.

---

🔹 PROCEDURE DIVISION

---

1️⃣ Conectar ao Queue Manager

       CALL 'MQCONN'
            USING WS-QMGR-NAME
                  WS-HCONN
                  WS-COMPCODE
                  WS-REASON.

       IF WS-COMPCODE NOT = MQCC-OK
          DISPLAY 'ERRO MQCONN - REASON: ' WS-REASON
          GO TO FIM-PROGRAMA
       END-IF.

📌 Easter egg:
Se falhar aqui, o problema não é a fila, é ambiente.

---

2️⃣ Abrir a fila

       MOVE MQOD-DEFAULT TO WS-OD.
       MOVE WS-QUEUE-NAME TO WS-OD-OBJECTNAME.
       MOVE MQOO-INPUT-AS-Q-DEF TO WS-OD-OPTIONS.

       CALL 'MQOPEN'
            USING WS-HCONN
                  WS-OD
                  WS-HOBJ
                  WS-COMPCODE
                  WS-REASON.

       IF WS-COMPCODE NOT = MQCC-OK
          DISPLAY 'ERRO MQOPEN - REASON: ' WS-REASON
          GO TO DESCONECTA
       END-IF.

---

3️⃣ Ler a mensagem (MQGET)

       MOVE MQMD-DEFAULT TO WS-MD.
       MOVE MQGMO-DEFAULT TO WS-GMO.
       MOVE MQGMO-WAIT TO WS-GMO-OPTIONS.
       MOVE 5000 TO WS-GMO-WAITINTERVAL.

       CALL 'MQGET'
            USING WS-HCONN
                  WS-HOBJ
                  WS-MD
                  WS-GMO
                  LENGTH OF WS-BUFFER
                  WS-BUFFER
                  WS-MSG-LEN
                  WS-COMPCODE
                  WS-REASON.

       IF WS-COMPCODE = MQCC-FAILED
          IF WS-REASON = MQRC-NO-MSG-AVAILABLE
             DISPLAY 'SEM MENSAGEM NA FILA'
             GO TO FECHA-FILA
          ELSE
             DISPLAY 'ERRO MQGET - REASON: ' WS-REASON
             GO TO ROLLBACK
          END-IF
       END-IF.

📌 Regra de ouro:

MQRC 2033 não é erro. É silêncio.

---

4️⃣ Tratar a mensagem

       DISPLAY 'MENSAGEM RECEBIDA: ' WS-MSG(1:WS-MSG-LEN).

       *> Aqui você trataria o conteúdo:
       *> Parse, valida, chama DB2, CICS, etc.

---

5️⃣ Commit da transação

       CALL 'MQCMIT'
            USING WS-HCONN
                  WS-COMPCODE
                  WS-REASON.

       IF WS-COMPCODE NOT = MQCC-OK
          DISPLAY 'ERRO MQCMIT - REASON: ' WS-REASON
          GO TO ROLLBACK
       END-IF.

📌 Easter egg clássico:

90% dos “problemas de MQ” são COMMIT esquecido.

---

6️⃣ Fechar fila e desconectar

   FECHA-FILA.
       CALL 'MQCLOSE'
            USING WS-HCONN
                  WS-HOBJ
                  MQCO-NONE
                  WS-COMPCODE
                  WS-REASON.

   DESCONECTA.
       CALL 'MQDISC'
            USING WS-HCONN
                  WS-COMPCODE
                  WS-REASON.

---

7️⃣ Rollback (se algo der errado)

   ROLLBACK.
       CALL 'MQBACK'
            USING WS-HCONN
                  WS-COMPCODE
                  WS-REASON.

       DISPLAY 'ROLLBACK EXECUTADO'.
       GO TO FECHA-FILA.

---

🔚 Fim do programa

   FIM-PROGRAMA.
       STOP RUN.

---

🧠 O que este exemplo ensina (de verdade)

✔ Fluxo correto do MQ
✔ Tratamento de erros
✔ Uso de COMMIT / ROLLBACK
✔ Código legível para mainframer
✔ Pronto para:

• Batch

• CICS

• IMS

• DB2

---

📌 Dicas Bellacosa Mainframe

• Sempre trate:

  • 2033 (no message)

  • 2009 (connection broken)

• Nunca:

  • Esqueça COMMIT

  • Assuma que mensagem foi consumida

• Pense em MQ como:

  DB2 sem SQL

   

 

😈🔥 Lendo SMF do MQ como se fosse trace distribuído

Conhecimento básico sobre aplicações distribuídas para quem já confiou mais no SMF do que em qualquer dashboard

---

☕ 02:48 — Quando a fila cresce e ninguém sabe “quem começou”

No mundo cloud, alguém pergunta:

“Qual serviço está causando o problema?”

No mundo mainframe, a pergunta sempre foi melhor:

“Qual transação chegou primeiro?”

Este artigo é sobre ler SMF do IBM MQ for z/OS com a mesma lógica usada para distributed tracing moderno — só que com décadas a mais de maturidade.

---

1️⃣ Contexto histórico: antes do trace existir, o SMF já contava a história 🧬

Distributed tracing surgiu porque:

• sistemas ficaram espalhados

• ninguém sabia por onde o request passava

No z/OS:

• tudo sempre passou por um lugar auditável

• o SMF virou a linha do tempo oficial

📌 Comentário Bellacosa:
Trace é novidade.
Linha do tempo sempre foi obrigação.

---

2️⃣ O que é um trace distribuído, afinal? 🧩

Trace distribuído:

• segue um request

• de serviço em serviço

• até o resultado (ou falha)

SMF do MQ faz o mesmo:

• PUT

• fila

• GET

• consumo

• impacto em recursos

🔥 Tradução direta:
Cada mensagem no MQ é um request distribuído encapsulado.

---

3️⃣ Mapa mental: SMF do MQ ↔ Trace moderno 🗺️

SMF MQ (z/OS)	Trace distribuído	Significado
PUT MESSAGE	Span inicial	Entrada do request
Queue Name	Service name	Destino lógico
GET MESSAGE	Span consumidor	Processamento
Queue Depth	Lag	Acúmulo de trabalho
Elapsed Time	Latência	Tempo fim a fim
CPU / I/O	Resource usage	Custo do request
Aplicação	Service ID	Responsável

😈 Easter egg:
Fila crescendo é trace parado no meio do caminho.

---

4️⃣ Lendo SMF como linha do tempo (não como relatório) ⏱️

Erro comum:

• olhar SMF como estatística fria

Leitura correta:

• montar sequência temporal

• entender causa → efeito

📌 Comentário Bellacosa:
Trace não é gráfico bonito.
É história cronológica.

---

5️⃣ Passo a passo: leitura estilo “trace distribuído” 🔍

5.1 — Identifique o PUT inicial

• Quem publicou?

• Em que horário?

• Com qual volume?

👉 Equivalente ao primeiro span do trace.

---

5.2 — Observe a evolução da fila

• Crescimento constante?

• Explosão pontual?

😈 Easter egg:
Fila crescendo devagar é mais perigosa que pico.

---

5.3 — Analise o GET

• Está acontecendo?

• Está atrasado?

• Está mais lento?

📌 Tradução:
Consumidor virou gargalo.

---

5.4 — Correlacione com recursos (RMF mode) 📊

• CPU alta?

• I/O saturado?

• Espera?

🔥 Comentário Bellacosa:
Mensagem não some. Ela espera.

---

5.5 — Ache o primeiro desvio

• Antes do alerta

• Antes da reclamação

• Antes do incidente

👉 Esse é o root cause real.

---

6️⃣ Curiosidades que só mainframer percebe 😈

• MQ nunca mente

• Ele só acumula evidência

• SMF sempre esteve certo

• O erro humano vem depois

📌 Comentário ácido:
Alertas gritam. SMF sussurra — e acerta.

---

7️⃣ Erros clássicos ao analisar MQ ⚠️

❌ Aumentar depth máximo
❌ Ajustar buffers sem análise
❌ Culpar o MQ
❌ Ignorar correlação temporal

🔥 Regra imortal:
Fila cheia é consequência, não diagnóstico.

---

8️⃣ Guia de estudo prático 📚

Conceitos

• Mensageria confiável

• Backpressure

• Throughput vs Latência

• Observabilidade

• Root cause analysis

Exercício Bellacosa

👉 Pegue um relatório SMF do MQ
👉 Monte uma timeline manual
👉 Marque onde o fluxo parou

---

🎯 Aplicações práticas desse entendimento

• Integração mainframe-cloud

• Sistemas event-driven críticos

• Análise de gargalos

• Prevenção de incidentes

• Auditoria e compliance

🔥 Comentário final:
Quem entende SMF do MQ já entende tracing distribuído — só não chamava assim.

---

🖤 Epílogo — 03:19, filas sob controle

Enquanto o mundo descobre tracing,
o mainframe segue entregando história completa, com provas.

El Jefe Midnight Lunch assina:
“Mensagem não mente. E SMF nunca esquece.”

 

 💡 Mid-Week Tech Insight | IBM MQ for z/OS & SMF Data

Mensageria crítica explicada para quem já confia mais no SMF do que em dashboard bonito

---

☕ 02:22 — Quando a fila começa a crescer em silêncio

Todo mainframer já viveu esse momento:
o sistema “está no ar”, ninguém reclamou…
mas o depth da fila começa a subir.

No mundo distribuído isso vira pânico tardio.
No z/OS, isso vira SMF bem lido.

Este artigo é sobre IBM MQ for z/OS + SMF como fundação real de aplicações distribuídas críticas — sem hype, sem romantização.

---

1️⃣ Um pouco de história: quando mensageria virou espinha dorsal 🧬

Antes de “event-driven” virar buzzword:

• MQ já desacoplava sistemas

• Garantia entrega

• Preservava ordem

• Sobrevivia a falhas

📌 Comentário Bellacosa:
MQ não nasceu para “escala web”.
Nasceu para não perder mensagem.

---

2️⃣ Por que SMF é a alma do MQ no z/OS 🧠

No z/OS:

• Nada sério existe sem SMF

• Performance sem SMF é palpite

No MQ:

• SMF mostra o que realmente aconteceu

• Não o que alguém acha que aconteceu

🔥 Tradução direta:
SMF é o trace definitivo do MQ.

---

3️⃣ O que o SMF revela sobre o MQ (e ninguém vê) 🔍

Com SMF você enxerga:

• Volume de mensagens

• Taxa de PUT / GET

• Uso de CPU e I/O

• Esperas

• Gargalos por fila ou aplicação

😈 Easter egg:
Quem analisa SMF sabe que fila cheia não é causa — é sintoma.

---

4️⃣ MQ no mundo distribuído: o elo invisível 🌍

Aplicações modernas:

• Microservices

• Eventos

• APIs

Mas no core:

• MQ continua segurando o mundo

📌 Comentário ácido:
Kafka fala alto.
MQ entrega calado.

---

5️⃣ Passo a passo mental: analisando MQ via SMF 🧭

1️⃣ Observe o crescimento da fila
2️⃣ Correlacione com horário e carga
3️⃣ Analise PUT vs GET
4️⃣ Verifique latência e espera
5️⃣ Avalie consumo de CPU
6️⃣ Identifique aplicação causadora
7️⃣ Só então ajuste parâmetros

🔥 Regra de ouro:
Nunca aumente buffer antes de entender o gargalo.

---

6️⃣ SMF vs Observabilidade moderna (o encontro dos mundos) 📊

Mainframe	Mundo distribuído
SMF MQ	Traces de mensageria
RMF	Métricas de throughput
Queue Depth	Lag de consumidor
PUT/GET	Producer / Consumer
Abend	Incident

😈 Curiosidade:
O que hoje chamam de “lag” você sempre chamou de fila crescendo.

---

7️⃣ Erros comuns (e caros) ⚠️

❌ Ignorar SMF e confiar só em alertas
❌ Tratar MQ como “infra”
❌ Ajustar parâmetros sem evidência
❌ Não correlacionar com carga real

📌 Comentário Bellacosa:
Mensageria sem visibilidade vira buraco negro.

---

8️⃣ Guia de estudo prático 📚

Conceitos

• Mensageria confiável

• Desacoplamento real

• Backpressure

• Observabilidade

• Capacidade

Exercício

👉 Pegue dados SMF do MQ
👉 Monte uma linha do tempo
👉 Relacione com batch, online e APIs

---

🎯 Aplicações reais no mundo enterprise

• Core bancário

• Integração mainframe-cloud

• Sistemas regulados

• Alta disponibilidade

• Processamento assíncrono crítico

🔥 Comentário final:
Sem MQ, o distribuído cai.
Sem SMF, ninguém sabe por quê.

---

🖤 Epílogo — 03:05, filas sob controle

Enquanto alguns discutem se mensageria é “moderna”,
o MQ segue processando bilhões de mensagens… com SMF contando a verdade.

El Jefe Midnight Lunch assina:
“Mensagens podem esperar. Diagnóstico não.”

 

☕🔥 IBM Integration Bus (Broker) no Mainframe — O “Tradutor Universal” dos Sistemas Corporativos

Bellacosa Mainframe e o IBM Integration Bus (Broker)

 ☕🔥 IBM Integration Bus (Broker) no Mainframe — O “Tradutor Universal” dos Sistemas Corporativos

Quando alguém fala em Integration Bus, Broker, Message Broker ou até no antigo MQSeries Integrator… estamos falando de uma das tecnologias mais importantes da integração corporativa moderna.

E no mundo mainframe isso teve — e ainda tem — um impacto gigantesco.

---

📌 O QUE É O INTEGRATION BUS (BROKER)?

De forma simples:

O IBM Integration Bus (IIB) é um middleware de integração criado pela IBM para:

• conectar sistemas diferentes

• transformar dados

• rotear mensagens

• integrar aplicações legadas e modernas

• fazer “sistemas conversarem”

Ele funciona como um:

✅ tradutor
✅ roteador
✅ orquestrador
✅ mediador
✅ transformador de protocolos

---

📜 EVOLUÇÃO HISTÓRICA

A IBM mudou o nome várias vezes:

Nome	Época
MQSeries Integrator	anos 90
WebSphere Message Broker (WMB)	anos 2000
IBM Integration Bus (IIB)	2010+
IBM App Connect Enterprise (ACE)	atual

Muita gente no mercado ainda chama tudo de:

👉 “Broker”

Porque o nome ficou eternizado no ambiente corporativo.

---

🧠 O PROBLEMA QUE ELE RESOLVE

Imagine isso:

Sistema A

Mainframe COBOL
fala:

• EBCDIC

• Copybook COBOL

• MQ

Sistema B

Java/Linux
fala:

• JSON

• REST

• UTF-8

Sistema C

SAP
fala:

• IDoc

• XML

Sistema D

Cloud/API
fala:

• HTTPS

• OAuth

• SOAP/REST

Sem um barramento de integração…

🔥 vira caos.

Cada sistema teria que entender diretamente todos os outros.

---

🎯 O BROKER ENTRA COMO INTERMEDIÁRIO

Ele recebe dados de um lado e entrega no formato correto do outro.

Exemplo:

COBOL + MQ + EBCDIC
        ↓
   Integration Bus
        ↓
JSON + REST + UTF-8

Ou:

CICS → MQ → Broker → API REST → Cloud

---

🏦 ONDE ELE É MUITO USADO?

Principalmente:

• bancos

• seguradoras

• bolsas financeiras

• telecom

• governo

• varejo

• empresas gigantes

Porque quase todas possuem:

✅ sistemas legados
✅ mainframe
✅ aplicações distribuídas
✅ cloud
✅ APIs modernas

E alguém precisa integrar tudo isso.

---

⚙️ COMO ELE FUNCIONA?

O Integration Bus trabalha com:

📦 Message Flows

Fluxos gráficos que definem:

• entrada

• transformação

• regras

• roteamento

• saída

Visualmente parece um pipeline.

---

🧩 COMPONENTES PRINCIPAIS

🔹 Input Node

Recebe mensagens:

• MQ

• HTTP

• File

• Kafka

• SOAP

• REST

• TCP/IP

---

🔹 Compute Node

Onde fica a lógica.

Normalmente usando:

• ESQL

• Java

• Mapping

Aqui ele:

• transforma campos

• converte layouts

• altera dados

• toma decisões

---

🔹 Mapping Node

Transformação visual:

COPYBOOK COBOL
   ↓
JSON/XML

---

🔹 Output Node

Entrega para:

• MQ

• API

• banco

• arquivo

• Kafka

• SAP

• cloud

---

🧠 O QUE É O ESQL?

O ESQL é a linguagem clássica do Broker.

Parece mistura de:

• SQL

• procedural

• manipulação de mensagem

Exemplo:

SET OutputRoot.JSON.Data.nome =
    InputRoot.XMLNSC.cliente.nome;

Ele transforma estruturas de dados em tempo real.

---

🔥 O MAINFRAME E O BROKER

Aqui está o ponto interessante.

Muitos ambientes z/OS usam:

• CICS

• IMS

• DB2

• MQ

• COBOL

Mas aplicações modernas querem:

• REST

• JSON

• APIs

• microserviços

O Broker virou a ponte entre esses mundos.

---

💥 EXEMPLO REAL

Cenário bancário

Mainframe

COBOL envia:

000123JOAO      0000500

Formato fixo EBCDIC.

---

Broker recebe

Ele:

• decodifica EBCDIC

• interpreta copybook

• converte para UTF-8

• monta JSON

Resultado:

{
  "conta": 123,
  "nome": "JOAO",
  "saldo": 500
}

---

API REST recebe

Aplicação cloud consome normalmente.

Tudo transparente.

---

🚀 O QUE FEZ O BROKER FICAR GIGANTE?

Porque ele resolveu o maior problema corporativo:

integração entre mundos incompatíveis

Ele conecta:

Mundo antigo	Mundo moderno
COBOL	Java
MQ	REST
VSAM	JSON
EBCDIC	UTF-8
CICS	APIs
Batch	Cloud

---

🔥 RELAÇÃO COM IBM MQ

Muita gente confunde.

IBM MQ

transporta mensagens

Broker/IIB

processa e transforma mensagens

Exemplo:

Sistema A
   ↓ MQ
Broker
   ↓ MQ/API
Sistema B

MQ = estrada
Broker = inteligência do tráfego

---

📦 PRINCIPAIS PROTOCOLOS SUPORTADOS

O Broker suporta praticamente tudo:

• MQ

• JMS

• REST

• SOAP

• HTTP

• HTTPS

• FTP

• SFTP

• Kafka

• TCP/IP

• SAP

• JDBC

• Files

• XML

• JSON

• CSV

• FIX

• SWIFT

---

🧠 POR QUE ISSO FOI REVOLUCIONÁRIO?

Antes dele:

❌ integrações ponto a ponto
❌ spaghetti architecture
❌ milhares de interfaces manuais
❌ manutenção infernal

Depois dele:

✅ centralização
✅ transformação padronizada
✅ governança
✅ desacoplamento
✅ reutilização

---

⚠️ MAS EXISTEM DESAFIOS

Integration Bus também pode virar:

🔥 “monólito de integração”

Quando:

• tudo passa por ele

• todas regras ficam centralizadas

• ninguém documenta

• flows crescem demais

Resultado:

❌ complexidade absurda
❌ debugging difícil
❌ dependência gigante
❌ gargalos

---

🏗️ O QUE VEIO DEPOIS?

Hoje existe forte movimento para:

• microservices

• event streaming

• Kafka

• API Gateway

• cloud integration

Mas…

🔥 o Broker continua fortíssimo em empresas enterprise.

Especialmente onde:

• existe mainframe

• há MQ pesado

• integração crítica

• alto volume transacional

---

📌 NO MAINFRAME MODERNO

O Broker/ACE virou peça estratégica para:

✅ expor APIs do CICS
✅ integrar COBOL com cloud
✅ transformar copybooks em JSON
✅ integrar DB2 com REST
✅ conectar Kafka ao z/OS
✅ modernização gradual

---

🎯 RESUMO FINAL

O IBM Integration Bus/Broker é:

“o sistema que faz sistemas incompatíveis conversarem.”

Ele foi — e continua sendo — um dos pilares da integração corporativa entre:

☕ legado
🔥 middleware
🚀 cloud
🏦 mainframe
🌎 APIs modernas

Sem ele, boa parte do mundo corporativo ainda estaria presa em integrações caóticas ponto a ponto.

☕ IBM MQ – State-of-the-art Resilience

 

Bellacosa Mainframe apresenta o IBM MQ

☕ IBM MQ – State-of-the-art Resilience

Alta disponibilidade não é luxo. É sobrevivência. (e o mainframe sempre soube disso)

Vamos começar pelo óbvio — aquele óbvio que só dói quando falha.
Se o e-commerce cai, você fica irritado.
Se o banco cai, o país inteiro sente.
Se logística, pagamentos ou supply chain param… bem-vindo ao caos operacional, manchetes negativas e reuniões “quentes” com o board.

👉 Resiliência hoje não é diferencial técnico. É requisito de negócio.

E é exatamente aqui que o IBM MQ entra em modo mainframe mindset:

falhar pode até acontecer — parar, não.

---

🧠 Um pouco de história (porque nada nasce ontem)

Mensageria sempre foi o “sistema nervoso” das arquiteturas corporativas.
No mainframe, isso já era verdade quando REST ainda era só uma palavra em inglês comum.

O IBM MQ (ex-WebSphere MQ, para os old school 😏) nasceu com um princípio simples e poderoso:

mensagem persistente não se perde. ponto.

Enquanto o mundo distribuído moderno corre atrás de eventual consistency, o MQ sempre jogou no modo consistência forte + durabilidade.

E agora, com Native High Availability (NHA) e Cross Region Replication (CRR), ele elevou esse jogo para o nível cloud + geo + compliance.

---

🧱 Native High Availability (NHA)

Alta disponibilidade… sem gambiarra externa

Vamos direto ao ponto:
NHA é alta disponibilidade nativa, de verdade.

Nada de:

• storage replicado caríssimo 💸

• drivers de kernel obscuros

• cluster manager de terceiros

• dependência de “caixinhas mágicas”

👉 O próprio IBM MQ resolve.

🔑 Como funciona?

• 3 nós (leader / followers)

• Baseado no algoritmo de consenso Raft (sim, o mesmo conceito usado em sistemas distribuídos sérios)

• Quórum síncrono:

  • mensagem só é confirmada quando escrita em pelo menos 2 nós

  • resultado? RPO = zero (nenhuma mensagem perdida)

📌 Easter egg técnico:

Se você viveu o mundo de DB2 Data Sharing, isso vai soar familiar. O conceito é diferente, mas a filosofia é a mesma: consistência acima de tudo.

⚡ Recuperação em segundos

Falhou um nó?

• detecção rápida

• eleição automática

• retomada quase imediata

Tudo isso:

• em VM

• bare metal

• containers (Kubernetes / OpenShift)

Sem reescrever arquitetura. Sem dor.

🔐 Segurança e operação

• Comunicação entre nós com TLS

• Atualizações rolling upgrade

• Sem downtime relevante

👉 Operacionalmente simples.
👉 Arquiteturalmente elegante.
👉 Auditor-friendly (alô, bancos e regulados 👀).

---

🌍 Cross Region Replication (CRR)

Quando o problema não é o servidor… é o mapa

Agora vamos falar de desastre de verdade:
região inteira fora do ar.
datacenter indisponível.
zona geográfica comprometida.

É aqui que entra o CRR.

---

🎯 Objetivo do CRR

Garantir resiliência geográfica com:

• alta performance

• baixo impacto de latência

• custo otimizado

Tudo isso sem replicação de disco tradicional.

---

📉 O problema das soluções antigas

Replicação baseada em storage:

• replica log + arquivos de fila

• duplica tráfego de rede

• snapshot de 15 minutos (ou pior)

• custo alto em cloud 🌩️

📌 Tradução Bellacosa:

você paga mais, replica mais dados… e ainda perde mensagens no meio do caminho.

---

🚀 O diferencial do CRR

O CRR faz algo muito mais inteligente:

• replica somente o que é necessário

• usa compressão eficiente

• protege o primário contra lentidão do remoto (latency protection)

• permite switchover planejado com RPO zero

👉 Mesmo sendo assíncrono, um planned switchover não perde nenhuma mensagem.

Isso é ouro puro para:

• DR corporativo

• auditorias

• testes reais de contingência

• ambientes regulados

---

🔄 Active / Active? Sim, senhor.

O CRR permite:

• alternar primário ↔ secundário

• ou até operar queue managers ativos em ambos os sites

📌 Easter egg arquitetural:

aqui o MQ começa a conversar de igual para igual com arquiteturas distribuídas modernas — só que sem abrir mão da confiabilidade “old school”.

---

🧾 Persistência: o detalhe que muda tudo

Lembrete importante (e muita gente esquece):

📝 IBM MQ sempre grava mensagens persistentes no log transacional.
Se a fila estoura memória ou precisa ir para disco:

• arquivos de fila garantem durabilidade

• recuperação consistente após falha

O CRR entende isso profundamente — por isso não replica disco bruto, mas sim o estado lógico necessário para reconstrução perfeita.

Resultado?

• menos tráfego

• menos custo

• mais controle

---

🧩 NHA + CRR = mentalidade mainframe no mundo cloud

Quando você junta:

• NHA (resiliência local, RPO zero, failover rápido)

• CRR (resiliência geográfica, DR real, switchover sem perda)

Você tem algo raro hoje em dia:

resiliência enterprise sem complexidade externa

Sem Frankenstein arquitetural.
Sem depender de “mais uma ferramenta”.
Sem sustos na madrugada.

---

☕ Comentário final (estilo Bellacosa)

O mercado redescobriu agora o que o mainframe sempre soube:

alta disponibilidade não é só estar no ar — é garantir integridade, consistência e previsibilidade quando tudo dá errado.

O IBM MQ, com NHA e CRR, mostra que:

• dá pra ser moderno

• distribuído

• cloud-ready

• sem abrir mão da confiabilidade raiz

No fim do dia, não é sobre tecnologia.
É sobre confiança.

E confiança…
👉 não se replica com snapshot de 15 minutos.