 |
| Bellacosa Mainframe uma visao do ibm mq 10 |
☕ Um Café no Bellacosa Mainframe
IBM MQ sem Mistérios: da Primeira Fila ao Salto Quântico da Integração Corporativa
O guia do Programador COBOL Padawan para compreender mensagens, filas, Queue Managers, canais, segurança, clusters, containers e a evolução do MQSeries ao IBM MQ 10.0
Existe uma cena clássica em praticamente todo ambiente corporativo: de um lado, temos um programa COBOL executando tranquilamente no z/OS; do outro, uma aplicação Java, um aplicativo bancário, uma API escrita em Python, um sistema Linux, um serviço na nuvem ou algum microsserviço perdido dentro de um cluster Kubernetes.
Todos precisam conversar.
O problema é que eles não falam necessariamente a mesma língua, não estão ligados no mesmo horário, não possuem a mesma velocidade e, pior ainda, podem ficar indisponíveis justamente no momento em que a mensagem precisa ser entregue.
É aí que entra o IBM MQ.
O MQ funciona como uma espécie de Central de Comunicações da Frota Estelar. A USS Enterprise não precisa pousar em cada planeta para entregar uma ordem. Ela transmite a mensagem por uma infraestrutura preparada para transportar, proteger, armazenar e encaminhar a comunicação.
No mundo corporativo, o IBM MQ desempenha uma missão semelhante.
Ele permite que aplicações diferentes troquem informações com segurança, confiabilidade e independência. Um programa envia uma mensagem; o MQ armazena essa mensagem; outro programa a recebe quando estiver pronto.
A ideia parece simples.
Mas é justamente essa simplicidade que sustenta bancos, seguradoras, companhias aéreas, governos, varejistas, indústrias, sistemas de pagamento e inúmeras operações críticas ao redor do planeta.
Prepare sua caneca de café, ajuste o uniforme da Frota e ligue o terminal 3270. Nossa missão será atravessar mais de três décadas de evolução do IBM MQ, começando no antigo MQSeries e chegando ao IBM MQ 10.0.
Capítulo I — Antes do MQ: quando as aplicações precisavam esperar umas pelas outras
Imagine que um programa chamado PGMPED01 precise enviar um pedido para outro programa chamado PGMFAT01.
Sem mensageria, o primeiro programa poderia chamar diretamente o segundo:
PGMPED01 ───────────────► PGMFAT01
chamada direta
Essa arquitetura pode funcionar enquanto tudo estiver perfeitamente disponível.
Mas o que acontece quando:
o segundo programa está parado;
a rede caiu;
o servidor remoto está em manutenção;
o processamento demora;
há milhares de solicitações simultâneas;
uma das aplicações é atualizada;
o sistema consumidor precisa ser transferido para outra plataforma?
Na comunicação direta, o produtor e o consumidor ficam fortemente acoplados.
O programa produtor precisa conhecer:
o endereço do consumidor;
o protocolo utilizado;
o formato esperado;
o tempo de resposta;
a condição de disponibilidade.
É como se o capitão de uma nave precisasse localizar pessoalmente cada tripulante para entregar uma ordem. Se o oficial estivesse dormindo, em missão externa ou preso no Holodeck, toda a operação ficaria bloqueada.
O MQ introduz um intermediário:
PGMPED01 ───► FILA.PEDIDOS ───► PGMFAT01
O produtor não entrega diretamente ao consumidor. Ele coloca a mensagem em uma fila.
O consumidor não precisa estar funcionando naquele instante. Quando estiver disponível, poderá retirar e processar a mensagem.
Esse é o coração da comunicação assíncrona.
Capítulo II — O que significa MQ?
MQ tornou-se associado a Message Queueing, ou enfileiramento de mensagens.
O produto começou como MQSeries em 1993, depois foi renomeado WebSphere MQ em 2002 e passou a se chamar IBM MQ em 2014. A solução cresceu de uma plataforma de filas para um conjunto completo de recursos de mensageria corporativa, disponível em z/OS, sistemas distribuídos, appliances, nuvem e containers. (Wikipedia)
Uma mensagem é uma unidade de informação enviada por uma aplicação.
Ela pode conter:
uma transação bancária;
um pedido de compra;
os dados de um cliente;
uma solicitação de pagamento;
uma notificação;
um evento de estoque;
um documento JSON;
um registro COBOL;
uma instrução para outro sistema;
até mesmo dados binários.
A fila é o local lógico onde essa mensagem aguarda processamento.
Pense em uma estação ferroviária.
Os passageiros são as mensagens.
A plataforma é a fila.
O trem é o canal de transporte.
A estação central é o Queue Manager.
Os fiscais são as regras de segurança.
O sistema de sinalização representa os mecanismos de confirmação, controle e recuperação.
No universo da Frota Estelar, podemos fazer outra analogia:
Mensagem = ordem da missão
Fila = caixa de comunicações
Queue Manager = computador central da nave
Canal = frequência de transmissão
Aplicação = tripulante remetente ou destinatário
Capítulo III — A criatura mais importante: o Queue Manager
O Queue Manager, ou gerenciador de filas, é o coração operacional do IBM MQ.
Ele administra:
filas;
mensagens;
conexões;
canais;
segurança;
recuperação;
logs;
persistência;
transações;
entrega entre ambientes.
Um Queue Manager pode ser imaginado como uma agência central dos Correios. Ele conhece as caixas postais, controla o armazenamento e encaminha as mensagens para outros locais.
Exemplo conceitual:
+---------------------------------------+
| QUEUE MANAGER QMZOS01 |
| |
| FILA.PEDIDOS |
| FILA.PAGAMENTOS |
| FILA.RESPOSTAS |
| FILA.ERROS |
| |
| Canais, logs, segurança e controle |
+---------------------------------------+
Um programa pode abrir uma fila e colocar uma mensagem usando uma chamada MQPUT.
Outro programa pode abrir a mesma fila e obter a mensagem usando MQGET.
Fluxo básico:
Programa produtor
|
| MQPUT
v
FILA.PEDIDOS
|
| MQGET
v
Programa consumidor
No mundo COBOL, essas operações podem ser efetuadas por meio da interface MQI, a Message Queue Interface.
Uma sequência lógica simplificada seria:
MQCONN → conectar ao Queue Manager
MQOPEN → abrir uma fila
MQPUT → colocar uma mensagem
MQCLOSE → fechar a fila
MQDISC → desconectar
Para consumir:
MQCONN → conectar
MQOPEN → abrir
MQGET → obter a mensagem
MQCLOSE → fechar
MQDISC → desconectar
Esse ciclo é quase um ritual de embarque:
entrar na nave;
abrir o canal;
transmitir ou receber;
fechar o canal;
desembarcar.
Capítulo IV — 1993: nasce o MQSeries
A década de 1990 foi um período de enorme fragmentação tecnológica.
Empresas possuíam:
mainframes;
servidores Unix;
PCs;
bancos de dados diferentes;
sistemas departamentais;
aplicações cliente-servidor;
redes heterogêneas.
A comunicação entre essas plataformas era complicada.
O MQSeries surgiu para fornecer mensageria confiável entre sistemas distribuídos.
A grande inovação não era apenas transportar dados. Era permitir que a aplicação produtora continuasse trabalhando sem precisar esperar que a aplicação consumidora terminasse.
Veja a diferença.
Comunicação síncrona
Aplicação A chama Aplicação B
Aplicação A fica esperando
Aplicação B processa
Aplicação B responde
Aplicação A continua
Comunicação assíncrona
Aplicação A envia mensagem
Aplicação A continua trabalhando
Aplicação B processa quando puder
Esse desacoplamento oferece quatro liberdades importantes:
Liberdade de tempo
Produtor e consumidor não precisam estar ativos simultaneamente.
Liberdade de plataforma
Um pode estar no z/OS; o outro, no Linux.
Liberdade de velocidade
O produtor pode enviar rapidamente, enquanto o consumidor processa no próprio ritmo.
Liberdade de evolução
Uma aplicação pode ser modificada sem exigir alteração imediata na outra, desde que o contrato da mensagem seja preservado.
Essa filosofia permanece válida mesmo depois de três décadas.
Capítulo V — Mensagens persistentes: o diário de bordo que não pode desaparecer
Nem toda mensagem possui a mesma importância.
Uma notificação de temperatura pode eventualmente ser descartada.
Uma transferência bancária, não.
Por isso, o MQ diferencia mensagens persistentes e não persistentes.
Mensagem não persistente
É normalmente utilizada quando desempenho é mais importante e uma eventual perda pode ser tolerada.
Exemplos:
telemetria temporária;
atualização visual;
evento sem valor transacional;
informação que pode ser recriada.
Mensagem persistente
É protegida pelos mecanismos de log e recuperação do Queue Manager.
Exemplos:
pagamento;
transferência;
pedido;
alteração de conta;
movimentação contábil;
reserva de passagem.
Se o sistema falhar, a mensagem persistente pode ser recuperada.
É o equivalente ao diário de bordo da Enterprise. Mesmo que a nave sofra uma pane, as informações essenciais da missão não podem simplesmente evaporar no espaço.
Capítulo VI — Commit e Backout: quando o MQ entra na transação
O MQ também pode participar de unidades de trabalho.
Imagine que um programa COBOL:
leia uma mensagem da fila;
atualize uma tabela Db2;
grave um registro;
confirme a transação.
Se tudo funcionar:
COMMIT
A mensagem é definitivamente removida da fila e a atualização do banco é confirmada.
Se ocorrer um erro:
ROLLBACK ou BACKOUT
A atualização é desfeita e a mensagem pode retornar à fila para nova tentativa.
Esse comportamento é fundamental para evitar o pior cenário de integração:
Mensagem removida
+
Banco não atualizado
=
Transação perdida
Quando MQ e Db2 estão coordenados corretamente, o processamento pode obedecer ao princípio:
Ou tudo acontece, ou nada acontece.
É a famosa atomicidade transacional.
Nenhum oficial da Frota gostaria de registrar “torpedo disparado” sem que o torpedo tivesse realmente sido lançado — ou lançar o torpedo sem atualizar o diário da batalha.
Capítulo VII — Canais: as rotas interestelares do MQ
Quando dois Queue Managers precisam conversar, normalmente utilizam canais.
Exemplo:
QMZOS01 ───────────────► QMLNX01
canal emissor
Em uma configuração distribuída clássica, podemos encontrar:
Sender Channel;
Receiver Channel;
Server Connection Channel;
Client Connection Channel;
Cluster Sender;
Cluster Receiver.
Um Sender Channel envia mensagens.
Um Receiver Channel recebe.
Um Server Connection Channel permite que uma aplicação cliente se conecte remotamente a um Queue Manager.
Para o Programador COBOL iniciante, a distinção essencial é:
Aplicação local
usa o Queue Manager próximo
Queue Manager
usa canais para conversar com outro Queue Manager
A aplicação não precisa conhecer todos os detalhes da rota.
Ela coloca a mensagem em uma fila. O MQ resolve o transporte segundo a configuração existente.
É como pedir ao computador da nave:
“Entregue esta mensagem à Base Estelar 12.”
O tripulante não precisa calcular cada dobra espacial, cada repetidor subespacial ou cada salto intermediário.
Capítulo VIII — Filas locais, remotas e de transmissão
Uma fila local armazena mensagens dentro do Queue Manager.
FILA.LOCAL.PEDIDOS
Uma definição de fila remota representa um destino existente em outro Queue Manager.
FILA.REMOTA.FATURAMENTO
Uma fila de transmissão armazena temporariamente mensagens destinadas a outro Queue Manager.
Fluxo simplificado:
Aplicação
|
v
Definição remota
|
v
Fila de transmissão
|
v
Sender Channel
|
v
Receiver Channel
|
v
Fila local no destino
Você pode imaginar a fila remota como o endereço da Base Estelar, enquanto a fila de transmissão funciona como o compartimento de carga onde as mensagens aguardam a próxima nave de transporte.
Capítulo IX — Final dos anos 1990: agrupamento e clustering
À medida que o MQ crescia, surgiram necessidades mais sofisticadas.
Uma delas era transportar conjuntos de mensagens relacionadas.
Imagine um pedido composto por:
cabeçalho;
cliente;
dez itens;
pagamento;
entrega.
Essas partes podem ser enviadas como mensagens separadas, mas precisam ser processadas como um grupo lógico.
Outro avanço importante foi o clustering.
Sem cluster:
Aplicação
|
v
Queue Manager único
Se esse Queue Manager sofrer uma interrupção, o caminho pode ficar indisponível.
Com um cluster:
┌──► QM01
Aplicação ────────┼──► QM02
└──► QM03
O cluster oferece mecanismos para distribuir mensagens entre instâncias de filas disponíveis em diferentes Queue Managers.
Mas atenção, Padawan: cluster não é sinônimo automático de alta disponibilidade completa.
Ele ajuda na conectividade e distribuição de carga, mas o projeto ainda precisa considerar:
disponibilidade do Queue Manager;
armazenamento;
aplicações consumidoras;
rede;
recuperação de desastre;
persistência;
afinidade de mensagens;
monitoramento.
Essa é uma armadilha frequente.
Cluster não é magia Jedi. É arquitetura.
Capítulo X — 2002: a era WebSphere MQ
Em 2002, o produto passou a integrar a família WebSphere e recebeu o nome WebSphere MQ. A mudança refletia o período em que arquiteturas Java, J2EE, serviços Web e integração corporativa ganhavam enorme importância. (Wikipedia)
Era a era da SOA: Service-Oriented Architecture.
A empresa deixava de pensar apenas em programas isolados e passava a organizar funcionalidades como serviços.
Exemplo:
Serviço de Cliente
|
v
MQ
|
v
Serviço de Crédito
|
v
MQ
|
v
Serviço de Faturamento
O MQ tornou-se um elemento essencial para conectar serviços sem criar dependências rígidas.
Muito antes de expressões como “microsserviços” e “cloud native” dominarem as conferências, o MQ já praticava princípios que permanecem modernos:
desacoplamento;
comunicação assíncrona;
contratos de mensagem;
tolerância a falhas;
processamento distribuído;
segurança;
rastreabilidade.
Curiosidade: vários conceitos vendidos hoje como novidades absolutas já frequentavam os corredores do mainframe quando muito desenvolvedor moderno ainda usava conexão discada.
Capítulo XI — Publish/Subscribe: uma mensagem para muitos ouvintes
No modelo tradicional de fila, uma mensagem é normalmente consumida por um consumidor.
Produtor ───► Fila ───► Consumidor
No modelo Publish/Subscribe, o produtor publica uma informação em um tópico.
Vários assinantes podem recebê-la.
┌──► Assinante A
Publicador ──► Tópico ───┼──► Assinante B
└──► Assinante C
Exemplo: uma transação de venda foi concluída.
O evento pode interessar a:
estoque;
faturamento;
logística;
análise de fraude;
programa de fidelidade;
data lake;
sistema de notificações.
Em vez de o sistema de vendas chamar seis aplicações diferentes, ele publica um evento:
VENDA.CONCLUIDA
Cada assinante recebe e processa a informação segundo sua finalidade.
Essa arquitetura reduz acoplamento e facilita a inclusão de novos consumidores.
A ponte da Enterprise anuncia:
“Alerta vermelho!”
Segurança, Engenharia, Enfermaria e Comando recebem o mesmo evento, mas cada departamento toma uma ação diferente.
Isso é Publish/Subscribe explicado pela Frota Estelar.
Capítulo XII — WebSphere MQ 7 e a abertura para JMS, MQTT e alta disponibilidade
A evolução do MQ acompanhou Java, dispositivos conectados e arquiteturas distribuídas.
JMS facilitou a integração com aplicações Java.
MQTT tornou-se especialmente importante em cenários de dispositivos leves e telemetria.
Imagine:
Sensor industrial
|
| MQTT
v
Gateway ou infraestrutura de mensageria
|
v
IBM MQ
|
v
Sistema corporativo
Um sensor não precisa executar um cliente pesado. Ele pode publicar dados usando um protocolo enxuto, enquanto a infraestrutura corporativa recebe, converte, distribui e processa as informações.
O MQ começou como um mensageiro entre sistemas corporativos e evoluiu para participar de ecossistemas com:
dispositivos;
aplicações móveis;
sistemas web;
Java;
integração empresarial;
serviços externos.
Capítulo XIII — Segurança: não basta entregar, é preciso proteger
Em mensageria corporativa, temos pelo menos cinco perguntas fundamentais:
Quem está se conectando?
A pessoa ou aplicação está autenticada?
Ela tem autorização para acessar a fila?
A comunicação está criptografada?
A mensagem pode ser auditada?
A segurança pode envolver:
TLS;
certificados;
autenticação;
autorização;
CHLAUTH;
CONNAUTH;
RACF no z/OS;
proteção de filas;
identidades de usuários;
políticas de Advanced Message Security;
registros e monitoramento.
No z/OS, o RACF pode controlar o acesso aos recursos do MQ.
Exemplo conceitual:
Usuário APPPED01
pode PUT em FILA.PEDIDOS
Usuário APPFAT01
pode GET em FILA.PEDIDOS
Usuário DESCONHECIDO
não pode acessar
Uma boa prática é seguir o princípio do menor privilégio.
O produtor não precisa necessariamente retirar mensagens.
O consumidor não precisa necessariamente colocar mensagens.
O operador não precisa ler o conteúdo comercial.
O auditor não precisa alterar configurações.
Cada tripulante deve possuir apenas os acessos necessários para a própria missão.
Dar autoridade total a todas as aplicações seria como distribuir códigos de autodestruição da Enterprise para qualquer cadete recém-chegado.
Capítulo XIV — Advanced Message Security e Managed File Transfer
O Advanced Message Security permite aplicar proteção à própria mensagem.
Isso é diferente de proteger somente o canal.
TLS protege a comunicação durante o transporte:
Aplicação A ===== canal protegido ===== MQ
A proteção no nível da mensagem pode manter o conteúdo protegido mesmo enquanto ele passa por intermediários.
É a diferença entre:
transportar uma carta dentro de um túnel seguro;
colocar a carta em um envelope que somente o destinatário pode abrir.
O Managed File Transfer utiliza a infraestrutura e os controles de MQ para transferências de arquivos gerenciadas.
Isso pode oferecer:
auditoria;
rastreabilidade;
automação;
segurança;
confirmação;
integração com processos;
tratamento de falhas.
Em muitas empresas, mover um arquivo não significa simplesmente executar FTP. É preciso saber:
quem enviou;
quando enviou;
qual era o tamanho;
se chegou;
se foi processado;
se houve erro;
se ocorreu nova tentativa.
O MFT transforma a transferência em uma operação governada.
Capítulo XV — 2014: nasce oficialmente o nome IBM MQ
Em 2014, o produto deixou a identidade WebSphere e passou a chamar-se IBM MQ. (Wikipedia)
A mudança simbolizou sua independência e amplitude.
O MQ já não era apenas uma peça de um conjunto de ferramentas web. Era uma plataforma de mensageria com identidade própria, presente em múltiplos sistemas operacionais e arquiteturas.
Nessa fase ganharam destaque recursos como:
interfaces administrativas modernas;
console web;
conectividade aprimorada;
appliances;
maior integração operacional.
O IBM MQ Appliance ofereceu uma forma integrada de executar mensageria em equipamento dedicado, reduzindo parte do trabalho de montagem da pilha de infraestrutura.
Para algumas organizações, isso significava receber uma espécie de “nave pronta para voar”, em vez de montar motor, casco, computador, escudos e sistema de dobra separadamente.
Capítulo XVI — LTS e Continuous Delivery
A partir da família 9, compreender os modelos de entrega tornou-se essencial.
LTS — Long Term Support
Destinado a organizações que priorizam estabilidade e permanência em uma linha de manutenção por um período prolongado.
A IBM define o LTS como o nível recomendado para ambientes que exigem máxima estabilidade. Atualizações LTS recebem correções de defeitos e segurança, enquanto novas capacidades chegam por novas bases LTS ou são incorporadas a partir da evolução do fluxo CD. (IBM)
CD — Continuous Delivery
Entrega funcionalidades com maior frequência.
Exemplos de numeração:
9.4.0 = base LTS
9.4.1 = CD
9.4.2 = CD
9.4.3 = CD
A IBM explica que versões LTS utilizam normalmente o nível de modificação zero, enquanto as entregas CD utilizam níveis subsequentes. (IBM)
A escolha depende da missão.
Um banco com processos rígidos pode preferir LTS.
Um laboratório, uma equipe de inovação ou um ambiente que necessita rapidamente de determinada capacidade pode adotar CD.
Não existe “melhor” universal.
Existe o modelo adequado ao risco, governança e velocidade da organização.
Capítulo XVII — IBM MQ 9.1, 9.2, 9.3 e 9.4: o MQ entra definitivamente na era híbrida
A família 9 consolidou o MQ dentro do novo universo tecnológico:
containers;
Docker;
Kubernetes;
OpenShift;
REST;
JSON;
autenticação moderna;
observabilidade;
automação;
integração híbrida.
O IBM MQ 9.4 LTS tornou-se disponível em junho de 2024. Entre suas capacidades estavam melhorias administrativas, ampliação de escalabilidade no channel initiator do z/OS, aprimoramentos nos registros SMF, evolução do console e mensageria remota por REST API. (IBM)
Observe o que isso representa.
Um produto nascido em 1993 consegue operar em um ambiente com:
COBOL + CICS + Db2 + z/OS
|
v
MQ
|
v
Java + Spring Boot + OpenShift + Kubernetes
Não foi necessário jogar fora o mainframe.
Não foi necessário reescrever todos os programas COBOL.
Foi criada uma ponte.
Essa é uma das maiores lições do MQ: modernização não significa necessariamente substituição.
Muitas vezes, modernizar significa expor, integrar, proteger, automatizar e observar melhor aquilo que já funciona.
Capítulo XVIII — 2026: IBM MQ 10.0 entra em cena
O IBM MQ 10.0 LTS foi anunciado em abril de 2026 e disponibilizado em junho de 2026, sucedendo o IBM MQ 9.4.0 LTS e a última entrega CD da linha 9.4, a versão 9.4.5. (IBM)
A versão reforça uma mensagem importante:
O MQ não está sendo mantido apenas por compatibilidade. Ele continua evoluindo para enfrentar novos problemas corporativos.
Entre os avanços documentados para o MQ 10.0 aparecem recursos ligados a:
conectividade simplificada com a nuvem;
melhorias de console;
recuperação de site alternativo;
monitoramento de Native HA;
tracing integrado com OpenTelemetry;
aprimoramentos administrativos;
segurança;
containers;
resiliência. (IBM)
No campo da segurança, o MQ 10.0 também trouxe suporte a mecanismos de troca de chaves quantum-safe baseados em FIPS 203 e ML-KEM para canais TLS 1.3 em plataformas compatíveis. A finalidade é ajudar a proteger comunicações contra o cenário conhecido como “coletar agora e descriptografar depois”. (IBM)
Aqui está o grande salto histórico:
1993: transportar mensagens entre aplicações
2026: transportar mensagens com integração híbrida,
observabilidade, automação, segurança moderna,
containers e preparação criptográfica para o futuro
A missão original permaneceu.
A nave ganhou novos motores.
Capítulo XIX — Exemplo completo: um pagamento processado por COBOL
Considere um aplicativo de pagamento.
O cliente realiza uma transferência.
Etapa 1 — Aplicativo envia a solicitação
{
"contaOrigem": "12345",
"contaDestino": "98765",
"valor": 150.00
}
Etapa 2 — API valida o formato
A API verifica token, campos obrigatórios e limites básicos.
Etapa 3 — API publica no MQ
FILA.PAGAMENTOS.ENTRADA
Etapa 4 — Programa COBOL consome
Um programa CICS ou batch executa MQGET.
Etapa 5 — Regra de negócio é aplicada
O programa verifica:
saldo;
situação da conta;
limite;
bloqueios;
antifraude;
dados cadastrais.
Etapa 6 — Db2 é atualizado
UPDATE CONTA
SET SALDO = SALDO - :VALOR
WHERE NUM_CONTA = :ORIGEM
Etapa 7 — Transação é confirmada
Se tudo funcionar:
COMMIT
Etapa 8 — Resposta é publicada
FILA.PAGAMENTOS.RESPOSTA
Etapa 9 — Aplicativo recebe a confirmação
{
"status": "APROVADO",
"codigo": "TX458902"
}
Agora suponha que o programa COBOL esteja indisponível durante três minutos.
A API não precisa perder o pagamento.
A mensagem pode permanecer na fila até que o consumidor retorne.
Esse é o verdadeiro poder do desacoplamento temporal.
Capítulo XX — Dead-letter queue: o cemitério que precisa ser investigado
Quando uma mensagem não consegue chegar ao destino, ela pode ser encaminhada para a Dead-Letter Queue.
Mas cuidado com o nome.
Ela não deve ser tratada como um lixão.
Uma mensagem na DLQ representa uma anomalia:
destino inexistente;
fila cheia;
erro de roteamento;
configuração incorreta;
autorização;
canal indisponível;
definição remota errada.
Uma DLQ ignorada é como uma cápsula de fuga à deriva. Pode parecer apenas um ponto luminoso no radar, mas talvez contenha informações vitais.
Boas práticas:
monitore a DLQ;
investigue o motivo;
corrija a causa;
reencaminhe quando apropriado;
mantenha trilha de auditoria;
evite simplesmente apagar.
Capítulo XXI — Backout Queue: a mensagem Klingon indestrutível
Imagine que uma mensagem defeituosa seja lida por um programa.
O programa falha.
A transação executa rollback.
A mensagem retorna à fila.
O programa lê novamente.
Falha novamente.
Isso pode criar um loop:
GET
erro
ROLLBACK
GET
erro
ROLLBACK
GET
erro
ROLLBACK
Para evitar esse ciclo, é possível utilizar mecanismos de backout.
Após determinada quantidade de tentativas, a mensagem pode ser movida para uma fila de exceção:
FILA.PAGAMENTOS.BACKOUT
Essa mensagem é frequentemente chamada de poison message.
Ela não é literalmente venenosa, mas provoca falha repetitiva no consumidor.
Dica de campo: sempre trate o contador de backout e projete uma estratégia para mensagens problemáticas. Não deixe o programa lutar eternamente contra o mesmo Klingon em um loop temporal.
Capítulo XXII — Passo a passo para o COBOL Padawan começar a estudar
Passo 1 — Domine os conceitos
Antes de instalar qualquer coisa, compreenda:
mensagem;
fila;
Queue Manager;
canal;
persistência;
commit;
rollback;
produtor;
consumidor;
cluster;
Publish/Subscribe.
Passo 2 — Desenhe um fluxo simples
PRODUTOR → FILA → CONSUMIDOR
Depois acrescente:
PRODUTOR → QM1 → CANAL → QM2 → CONSUMIDOR
Passo 3 — Conheça as chamadas MQI
Estude inicialmente:
MQCONN
MQOPEN
MQPUT
MQGET
MQCLOSE
MQDISC
Depois avance para:
MQBEGIN
MQCMIT
MQBACK
MQINQ
MQSET
Passo 4 — Aprenda MQSC
MQSC é a linguagem administrativa usada para definir e controlar objetos.
Exemplos conceituais:
DEFINE QLOCAL(FILA.TESTE)
DISPLAY QLOCAL(FILA.TESTE)
ALTER QLOCAL(FILA.TESTE)
DELETE QLOCAL(FILA.TESTE)
Passo 5 — Crie um laboratório produtor/consumidor
O produtor envia:
USS ENTERPRISE NCC-1701
O consumidor lê e exibe.
Esse será nosso primeiro Easter egg.
Depois envie:
RESISTANCE IS FUTILE
Caso a mensagem pare na Dead-Letter Queue, saberemos que os Borg assumiram o canal.
Passo 6 — Teste persistência
Envie uma mensagem persistente, interrompa o Queue Manager de forma controlada e confirme a recuperação após a reinicialização.
Passo 7 — Teste transação
Faça o consumidor:
obter a mensagem;
provocar um erro;
executar rollback;
verificar o retorno da mensagem.
Passo 8 — Estude segurança
Crie usuários com permissões distintas.
Teste quem pode:
conectar;
colocar;
retirar;
consultar;
administrar.
Passo 9 — Adicione um segundo Queue Manager
Configure uma rota entre dois ambientes.
Observe:
fila remota;
transmission queue;
sender channel;
receiver channel.
Passo 10 — Monitore
Acompanhe:
profundidade da fila;
mensagens antigas;
canais parados;
erros;
DLQ;
desempenho;
logs;
consumo;
tentativas de autenticação.
Capítulo XXIII — Dez dicas do engenheiro-chefe
1. Não use uma fila como banco de dados
Fila é mecanismo de transporte e desacoplamento, não repositório permanente de consulta histórica.
2. Defina contratos de mensagem
Documente:
formato;
campos;
versão;
codificação;
tamanho;
obrigatoriedade;
tratamento de erro.
3. Pense em idempotência
O consumidor deve, quando possível, tolerar o recebimento repetido de uma mensagem sem executar duas vezes um efeito indevido.
4. Use identificadores de correlação
Eles ajudam a relacionar uma resposta à solicitação original.
5. Monitore idade, não apenas quantidade
Uma fila com dez mensagens antigas pode ser mais grave que uma fila com mil mensagens processadas rapidamente.
6. Planeje mensagens inválidas
Toda arquitetura precisa responder:
O que faremos quando o conteúdo não puder ser processado?
7. Proteja os canais
Não exponha canais administrativos ou permissões excessivas.
8. Evite mensagens gigantes sem necessidade
Mensagens muito grandes aumentam consumo de rede, armazenamento, log e tempo de processamento.
9. Conheça a semântica da entrega
“Coloquei na fila” não significa necessariamente “o negócio foi concluído”.
Significa que a responsabilidade foi transferida para outra etapa.
10. Documente o caminho completo
Não basta saber o nome da fila.
Registre:
produtor;
consumidor;
Queue Manager;
canais;
regras de segurança;
formato;
retentativas;
DLQ;
backout;
alertas;
responsáveis.
Capítulo XXIV — MQ versus chamadas REST
REST e MQ não são inimigos.
REST funciona muito bem quando:
a resposta imediata é necessária;
o consumidor está disponível;
o fluxo é simples;
a interação é síncrona.
MQ funciona muito bem quando:
o consumidor pode estar indisponível;
a operação precisa ser armazenada;
há grande volume;
os sistemas possuem velocidades diferentes;
retentativa e recuperação são necessárias;
o processamento pode ser assíncrono.
Uma arquitetura real pode usar ambos:
Aplicativo
|
| REST
v
API
|
| MQ
v
COBOL/CICS
REST recebe a solicitação.
MQ protege e desacopla o processamento.
COBOL executa a regra crítica.
É uma aliança entre planetas, não uma guerra entre tecnologias.
Capítulo XXV — O maior ensinamento da linha do tempo
O IBM MQ atravessou:
cliente-servidor;
Internet;
Java;
SOA;
Web Services;
integração empresarial;
cloud;
containers;
Kubernetes;
OpenShift;
observabilidade;
segurança pós-quântica.
E, apesar de toda essa evolução, sua ideia central continua reconhecível:
Uma aplicação produz uma mensagem.
Outra aplicação consome.
O MQ garante a travessia.
Essa permanência ensina algo precioso ao Programador COBOL Padawan.
Uma tecnologia não permanece relevante porque recusa mudanças.
Ela permanece relevante porque preserva seus princípios fundamentais enquanto adapta sua implementação ao novo mundo.
O COBOL também sobreviveu seguindo lógica semelhante.
O z/OS também.
O Db2 também.
O CICS também.
Eles não ficaram congelados em uma fotografia de 1970. Evoluíram, ganharam APIs, segurança moderna, integração, automação e novos modelos operacionais.
O IBM MQ tornou-se uma ponte entre gerações.
De um lado:
COBOL
CICS
IMS
Db2
z/OS
Do outro:
Java
Python
REST
JSON
Containers
Kubernetes
Cloud
IA
No centro:
IBM MQ
Conclusão — A mensagem precisa chegar
No final de nossa missão, percebemos que IBM MQ não é apenas uma ferramenta para criar filas.
Ele é uma filosofia de arquitetura.
Uma filosofia baseada em:
desacoplamento;
resiliência;
segurança;
persistência;
transações;
integração;
confiabilidade.
Para o Programador COBOL iniciante, aprender MQ é descobrir como o mainframe conversa com o restante da galáxia digital.
Seu programa COBOL não precisa compreender cada detalhe de uma aplicação móvel, de um container ou de uma API em nuvem.
Ele precisa conhecer o contrato da mensagem.
Precisa saber onde recebê-la.
Precisa processá-la corretamente.
Precisa confirmar ou desfazer a transação.
O restante fica sob responsabilidade da infraestrutura de mensageria.
Talvez essa seja a verdadeira genialidade do MQ: permitir que sistemas de épocas, linguagens e plataformas diferentes cooperem sem exigir que todos se transformem na mesma coisa.
Na Frota Estelar, vulcanos, humanos, andorianos, klingons e inúmeras espécies trabalham lado a lado. Cada uma mantém sua identidade, mas utiliza protocolos comuns para colaborar.
No ambiente corporativo, COBOL, Java, Python, Linux, z/OS, containers e APIs fazem exatamente isso.
E o IBM MQ permanece no meio da ponte de comando, silencioso, transportando milhões de mensagens enquanto quase ninguém percebe.
Até o dia em que ele para.
Nesse instante, todos descobrem que o mensageiro discreto era, na verdade, um dos sistemas mais importantes da nave.
Vida longa e próspera às filas.
E lembre-se do código secreto escondido no log da missão:
MSGID: NCC1701
CORRELID: BELLACOSA
REASON: 00000000
STATUS: MESSAGE DELIVERED
A transmissão foi concluída. ☕🖖
