 |
| Bellacosa Mainframe e o ibm mq em velocidade maxima |
☕ Um Café no Bellacosa Mainframe
IBM MQ em Velocidade Máxima
Quando um Programador COBOL Descobre que a Mensagem Não Pode Parar, a Fila Não Pode Estourar e o Canal Precisa Permanecer Acima de 50 Milhas por Hora
Existe uma bomba dentro do ônibus.
Ela não está ligada a fios vermelhos, relógios digitais ou explosivos cinematográficos. Está ligada a algo muito mais perigoso para uma grande empresa:
uma fila IBM MQ que cresce sem parar.
O painel de monitoração mostra:
QUEUE NAME: PAGAMENTOS.ENTRADA
CURRENT DEPTH: 197.842
MAX DEPTH: 200.000
O consumidor parou.
O canal está instável.
A fila continua recebendo mensagens.
O telefone da produção toca.
O gerente pergunta:
— Quanto tempo temos?
O especialista MQ olha para a tela, respira fundo e responde:
— Se a fila atingir o MAXDEPTH, os próximos MQPUT poderão falhar. Temos poucos minutos.
Em algum lugar do ambiente corporativo, milhares de aplicações continuam enviando pagamentos, pedidos, atualizações cadastrais, reservas, autorizações e eventos.
A mensagem não pode parar.
O IBM MQ precisa continuar em movimento.
Bem-vindo a mais uma sessão de Um Café no Bellacosa Mainframe, onde hoje entraremos no mundo do IBM MQ como se estivéssemos dentro de um thriller tecnológico em velocidade máxima.
A missão é simples:
Entender como o IBM MQ transporta mensagens com confiabilidade, mesmo quando aplicações, redes e servidores não estão vivendo o seu melhor dia.
Para um programador COBOL iniciante, o MQ pode parecer uma coleção assustadora de filas, canais, listeners, Queue Managers, códigos de retorno e comandos misteriosos.
Mas, depois que compreendemos sua lógica, percebemos que ele resolve um dos problemas mais antigos da computação empresarial:
Como permitir que dois sistemas troquem informações sem depender de estarem disponíveis exatamente no mesmo instante?
Coloque o café no suporte.
Aperte o cinto.
E não deixe a profundidade da fila cair abaixo de… bem, neste caso, queremos justamente que ela caia.
1. O passageiro invisível dos sistemas corporativos
O IBM MQ raramente aparece para o usuário final.
Ninguém abre o aplicativo do banco e vê uma mensagem dizendo:
Seu pagamento está sendo transportado pelo IBM MQ.
O cliente apenas espera que a operação funcione.
Quando ele faz uma transferência, compra uma passagem aérea ou confirma um pedido, várias aplicações podem participar do processo:
Aplicativo móvel
↓
Sistema de autenticação
↓
Sistema de pagamentos
↓
Antifraude
↓
Contabilidade
↓
Notificações
Esses sistemas podem estar em tecnologias completamente diferentes:
COBOL em z/OS;
Java em Linux;
aplicações .NET em Windows;
microsserviços em Kubernetes;
bancos de dados;
serviços em nuvem;
sistemas antigos que ninguém ousa desligar.
O IBM MQ funciona como uma camada intermediária de comunicação.
Ele não precisa executar as regras do pagamento.
Ele não decide se o cliente possui saldo.
Ele não calcula os juros.
Sua principal missão é transportar a mensagem de forma confiável.
É como o ônibus do filme: ele pode não ser o protagonista humano da história, mas toda a tensão depende de mantê-lo em movimento.
2. O problema da comunicação direta
Imagine dois programas:
PROGRAMA-A
PROGRAMA-B
O Programa A precisa enviar uma informação ao Programa B.
A solução mais simples seria uma chamada direta:
PROGRAMA-A → PROGRAMA-B
Porém, o que acontece quando o Programa B está indisponível?
A chamada falha.
O Programa A precisa decidir:
Agora multiplique isso por centenas de aplicações.
Sem uma camada de mensageria, cada sistema começa a implementar sua própria tentativa de entrega.
O resultado é um ambiente frágil e fortemente acoplado.
Se o destino muda de endereço, o remetente precisa ser alterado.
Se o destino fica indisponível, o remetente sofre.
Se o tráfego aumenta, ambos podem entrar em colapso juntos.
É como colocar todos os passageiros no mesmo veículo sem freio de emergência.
O IBM MQ introduz uma fila entre os sistemas:
PROGRAMA-A
↓
FILA MQ
↓
PROGRAMA-B
Agora, o Programa A entrega a mensagem ao MQ.
O Programa B pode consumi-la depois.
Os dois programas não precisam estar ativos ao mesmo tempo.
Esse é o coração da comunicação assíncrona.
3. O Queue Manager: o centro de controle da operação
O principal componente do IBM MQ é o Queue Manager.
Ele administra os objetos do ambiente MQ:
filas;
canais;
listeners;
tópicos;
assinaturas;
processos;
segurança;
logs;
persistência;
conexões.
Uma analogia útil é imaginar o Queue Manager como o centro de controle de tráfego de uma grande cidade.
Os veículos são mensagens.
As filas são áreas de espera.
Os canais são estradas.
Os listeners são portões de entrada.
Os logs são as caixas-pretas que registram o que aconteceu.
O Queue Manager garante que cada elemento funcione segundo uma configuração conhecida.
Dois Queue Managers podem se comunicar pela rede:
QUEUE MANAGER A
│
│ Canal MQ
│
QUEUE MANAGER B
O Queue Manager A pode estar em um mainframe no Brasil.
O Queue Manager B pode estar em um servidor Linux em outro país.
Para o IBM MQ, essa diferença de plataforma é apenas parte da rota.
4. Local Queue: o lugar onde a mensagem realmente espera
A Local Queue é uma fila que pertence ao Queue Manager atual e pode armazenar mensagens.
Exemplo:
PAGAMENTOS.ENTRADA
Uma aplicação produtora executa um MQPUT.
A mensagem é colocada na fila.
Uma aplicação consumidora executa um MQGET.
A mensagem é retirada.
O fluxo básico é:
Aplicação produtora
↓ MQPUT
Local Queue
↓ MQGET
Aplicação consumidora
No COBOL com MQ, os verbos mais importantes da API são chamados por meio de rotinas como:
CALL 'MQCONN'
CALL 'MQOPEN'
CALL 'MQPUT'
CALL 'MQGET'
CALL 'MQCLOSE'
CALL 'MQDISC'
Em uma visão simplificada:
CALL 'MQPUT' USING
HCONN
HOBJ
MQMD
MQPMO
MESSAGE-LENGTH
MESSAGE-BUFFER
COMPLETION-CODE
REASON-CODE.
Não é necessário decorar tudo imediatamente.
Para o iniciante, o mais importante é compreender a sequência:
Conectar
Abrir a fila
Colocar ou retirar a mensagem
Fechar a fila
Desconectar
Parece com o tratamento de arquivos:
OPEN
READ ou WRITE
CLOSE
A diferença é que agora estamos lidando com mensageria transacional.
5. Remote Queue: uma placa apontando para outro lugar
A Remote Queue Definition costuma confundir iniciantes.
Apesar do nome, ela não é uma fila que guarda mensagens.
Ela é uma definição local que aponta para uma fila existente em outro Queue Manager.
Imagine uma placa:
DESTINO: FILA.PEDIDOS
LOCALIZAÇÃO: QM-B
ROTA: XMITQ.QM-B
Quando a aplicação coloca uma mensagem nessa definição remota, o Queue Manager identifica que o destino não está localmente disponível.
A mensagem precisa viajar.
Para isso, ela será colocada em uma Transmission Queue.
A Remote Queue é mais parecida com um endereço lógico do que com uma caixa postal real.
6. Transmission Queue: a pista de aceleração
A Transmission Queue, normalmente chamada de XMITQ, armazena temporariamente mensagens destinadas a outro Queue Manager.
Fluxo:
Aplicação
↓
Remote Queue
↓
Transmission Queue
↓
Sender Channel
↓
Rede
↓
Receiver Channel
↓
Fila local no destino
Imagine que o canal esteja parado.
As mensagens não desaparecem.
Elas permanecem na Transmission Queue.
Quando o canal volta a funcionar, o transporte continua.
Essa capacidade é fundamental para a resiliência.
Em uma integração direta, uma interrupção de rede pode provocar erro imediato.
No MQ, a indisponibilidade temporária pode ser absorvida pela fila.
Entretanto, existe um detalhe importante:
Uma Transmission Queue crescendo continuamente é um sinal de que algo na rota precisa ser investigado.
Possíveis causas:
Sender Channel parado;
Receiver Channel indisponível;
falha de rede;
erro de segurança;
Queue Manager remoto desligado;
configuração incorreta;
problema de certificado TLS.
No mundo de velocidade máxima, a XMITQ é a pista onde os veículos se acumulam quando a ponte à frente está fechada.
7. Sender e Receiver Channel: a dupla que atravessa a rede
Os canais de mensagem transportam dados entre Queue Managers.
Uma configuração clássica utiliza:
SDR — Sender Channel
RCVR — Receiver Channel
O Sender Channel inicia o envio.
O Receiver Channel aceita as mensagens no destino.
Exemplo:
QM-A QM-B
XMITQ.QM-B
↓
CANAL.A.B SDR ───────────────▶ CANAL.A.B RCVR
↓
FILA.DESTINO
Os nomes normalmente precisam corresponder.
O Sender pode conter informações como:
endereço do host remoto;
porta;
nome da XMITQ;
parâmetros de retry;
configuração TLS;
opções de batch;
sequência de mensagens.
O Receiver define o lado que recebe a conexão.
Uma diferença importante:
O canal não é a fila.
A fila armazena.
O canal transporta.
Confundir esses conceitos é como confundir a garagem com a estrada.
8. SVRCONN: o portão usado pelas aplicações clientes
Muitas aplicações não estão instaladas na mesma máquina do Queue Manager.
Elas se conectam remotamente usando o IBM MQ Client.
Para isso, normalmente utilizam um canal do tipo:
SVRCONN
ou Server-Connection Channel.
Fluxo:
Aplicação Java, COBOL, .NET ou Python
↓ TCP/IP
SVRCONN
↓
Queue Manager
A aplicação precisa saber dados como:
Host
Porta
Queue Manager
Nome do canal SVRCONN
Exemplo conceitual:
Host: mqempresa.exemplo
Porta: 1414
Canal: APP.PAGAMENTOS.SVRCONN
QMGR: QMPROD01
O SVRCONN não transporta mensagens entre Queue Managers.
Ele permite que uma aplicação cliente acesse um Queue Manager.
Esse é outro ponto onde iniciantes frequentemente se confundem.
SDR/RCVR → comunicação entre Queue Managers
SVRCONN → conexão de aplicações clientes
9. Listener: alguém precisa atender a porta
O Listener fica aguardando conexões de rede em uma porta TCP.
Uma porta muito conhecida no universo MQ é a 1414, embora cada ambiente possa utilizar outra.
Sem Listener ativo, uma aplicação remota pode receber erro de conexão.
Fluxo:
Cliente
↓
TCP/IP
↓
Listener
↓
Canal
↓
Queue Manager
No diagnóstico, é necessário verificar:
o Listener está iniciado?
a porta está correta?
existe firewall bloqueando?
o endereço está acessível?
o canal está definido?
o Queue Manager está ativo?
O canal pode estar perfeitamente configurado, mas, se ninguém estiver ouvindo na porta, não haverá conexão.
É como chegar ao ponto combinado e descobrir que a porta do ônibus está trancada.
10. Dead-Letter Queue: o destino das mensagens problemáticas
A Dead-Letter Queue, ou DLQ, recebe mensagens que não puderam ser entregues corretamente.
Ela não deve ser vista como uma lixeira.
É mais adequado considerá-la uma área de quarentena.
Uma mensagem pode ir para a DLQ por vários motivos:
fila destino inexistente;
fila cheia;
erro de autorização;
nome de destino incorreto;
rota não encontrada;
Queue Manager desconhecido;
falha durante encaminhamento.
Quando o MQ coloca uma mensagem na DLQ, normalmente adiciona um cabeçalho chamado:
MQDLH
O MQ Dead-Letter Header contém informações sobre o motivo da falha e o destino original.
Isso permite investigar e, em alguns casos, reprocessar a mensagem.
Uma DLQ crescendo sem monitoração é perigosa.
As mensagens continuam existindo, mas o negócio pode estar parado.
Imagine mensagens de pedidos chegando à DLQ enquanto os clientes acreditam que suas compras estão sendo processadas.
A tecnologia preservou os dados.
A operação, porém, precisa responder ao alerta.
11. Persistência: a mensagem sobrevive ao acidente
Uma mensagem MQ pode ser persistente ou não persistente.
Mensagem persistente foi criada para sobreviver a falhas do Queue Manager, desde que o ambiente esteja corretamente configurado.
Ela utiliza mecanismos de log e armazenamento.
Conceitualmente:
MQPUT
↓
Registro em log
↓
Armazenamento
↓
Confirmação
Se o servidor for reiniciado, a mensagem persistente pode ser recuperada.
Uma mensagem não persistente oferece melhor desempenho em alguns cenários, mas pode não sobreviver a determinadas falhas.
A escolha depende do valor de negócio da informação.
Para uma telemetria descartável, perder uma mensagem pode ser aceitável.
Para uma transação financeira, provavelmente não.
Regra Bellacosa:
Antes de escolher persistência, pergunte qual seria o impacto de perder aquela mensagem.
Não escolha apenas pensando em velocidade.
Escolha pensando em risco.
12. Unidade de trabalho e syncpoint
O IBM MQ pode participar de transações.
Imagine o seguinte fluxo:
Retirar mensagem de uma fila;
atualizar uma tabela Db2;
colocar mensagem de confirmação em outra fila;
confirmar tudo junto.
Se algo falhar, queremos evitar este desastre:
Mensagem retirada da fila
Banco não atualizado
Mensagem perdida
Com controle transacional, é possível utilizar syncpoint.
Conceitualmente:
MQGET sob syncpoint
↓
UPDATE Db2
↓
MQPUT resposta
↓
COMMIT
Se ocorrer erro:
ROLLBACK
A mensagem pode voltar a ficar disponível na fila.
Em COBOL, CICS e ambientes transacionais, essa integração é extremamente importante.
No CICS, o MQ pode participar da unidade lógica de trabalho administrada pelo próprio CICS.
É uma das razões pelas quais IBM MQ, CICS e Db2 formam uma combinação tão forte no mainframe.
13. A armadilha do “exactly once”
Muitas pessoas dizem:
O MQ entrega exatamente uma vez.
Essa frase exige cuidado.
O IBM MQ oferece mecanismos robustos de entrega e transação, mas a arquitetura da aplicação também precisa estar correta.
Imagine:
consumidor retira uma mensagem;
atualiza um sistema externo;
falha antes de confirmar o MQ;
a mensagem fica disponível novamente;
consumidor processa de novo.
Agora temos possível duplicidade.
Por isso, aplicações críticas utilizam técnicas como:
Idempotência significa que processar a mesma solicitação duas vezes produz o mesmo resultado final.
Exemplo:
Definir saldo para R$ 100,00
é idempotente.
Já:
Adicionar R$ 100,00 ao saldo
não é necessariamente idempotente.
Se a mensagem for repetida, o valor poderá ser adicionado duas vezes.
O MQ fornece a estrada segura.
A aplicação ainda precisa dirigir corretamente.
14. Message ID e Correlation ID
Cada mensagem pode possuir um identificador chamado:
MSGID
Também existe o:
CORRELID
O Correlation ID é útil em padrões de requisição e resposta.
Exemplo:
Aplicação A
↓
Mensagem de requisição
MSGID = ABC123
↓
Aplicação B
↓
Mensagem de resposta
CORRELID = ABC123
A aplicação A pode procurar a resposta associada ao pedido original.
Isso é especialmente útil quando várias requisições estão sendo processadas ao mesmo tempo.
Sem correlação, seria como receber dezenas de respostas sem saber a qual pergunta cada uma pertence.
15. Reply-to Queue: para onde a resposta deve voltar?
Uma mensagem pode indicar:
ReplyToQ
ReplyToQMgr
Esses campos informam ao consumidor onde colocar a resposta.
Exemplo:
Pedido:
Processar pagamento
ReplyToQ:
PAGAMENTO.RESPOSTA.APP01
O consumidor processa e devolve:
Pagamento aprovado
Esse padrão permite requisição e resposta sem criar uma conexão síncrona tradicional.
No entanto, deve-se tomar cuidado para não transformar o MQ em uma falsa chamada REST, bloqueando a aplicação por muito tempo.
A mensageria brilha especialmente quando aceitamos seu modelo assíncrono.
16. Backout Queue: quando a mensagem volta muitas vezes
Imagine uma mensagem inválida.
O consumidor tenta processar.
Falha.
Executa rollback.
A mensagem volta para a fila.
O consumidor tenta novamente.
Falha outra vez.
Isso pode criar um ciclo infinito.
GET
↓
ERRO
↓
ROLLBACK
↓
GET
↓
ERRO
↓
ROLLBACK
Esse comportamento é conhecido como mensagem venenosa, ou poison message.
Para lidar com isso, podemos utilizar:
BOTHRESH, o limite de backout;
BOQNAME, a fila de backout;
lógica na aplicação para verificar o contador.
Depois de determinado número de falhas, a mensagem pode ser movida para uma fila específica:
PAGAMENTOS.BACKOUT
Assim, o fluxo normal continua e a mensagem problemática pode ser analisada separadamente.
Easter egg para os veteranos:
Quando a mesma mensagem retorna pela terceira vez, ela já não é mais passageira. Ela está tentando dirigir o ônibus.
17. Profundidade da fila: o velocímetro do ambiente
Um dos indicadores mais observados é o CURDEPTH.
Ele mostra quantas mensagens estão atualmente na fila.
Também existe o MAXDEPTH, que define o limite máximo.
Exemplo:
CURDEPTH: 75.000
MAXDEPTH: 100.000
Uma profundidade alta não significa automaticamente problema.
Pode ser normal durante uma janela batch.
O importante é observar comportamento e contexto.
Perguntas úteis:
a profundidade cresce continuamente?
o consumidor está ativo?
a taxa de entrada é maior que a de saída?
o aumento ocorre sempre no mesmo horário?
existe atraso aceitável?
quanto tempo falta para atingir o limite?
as mensagens são antigas?
É necessário monitorar não apenas quantidade, mas também idade.
Uma fila com dez mensagens paradas há seis horas pode ser mais crítica do que uma fila com cinquenta mil mensagens processadas em segundos.
18. Quando o consumidor fica mais lento que o produtor
Considere:
Produtor: 1.000 mensagens por segundo
Consumidor: 800 mensagens por segundo
A cada segundo:
200 mensagens ficam acumuladas.
Em uma hora:
200 × 3.600 = 720.000 mensagens
O MQ está funcionando corretamente.
A fila está apenas revelando um desequilíbrio da arquitetura.
Possíveis soluções:
otimizar o consumidor;
aumentar o número de consumidores;
dividir o processamento;
utilizar múltiplas instâncias;
ajustar conexões;
rever commits;
remover gargalos de banco;
melhorar o modelo de mensagens.
O IBM MQ não cria capacidade infinita.
Ele absorve diferenças temporárias.
Se o consumidor permanecer permanentemente mais lento, a fila acabará atingindo algum limite físico ou operacional.
19. O perigo dos commits muito frequentes
Imagine um consumidor que processa uma mensagem e faz commit.
Depois processa outra e faz commit novamente.
Mensagem 1 → COMMIT
Mensagem 2 → COMMIT
Mensagem 3 → COMMIT
Isso oferece excelente isolamento, mas pode aumentar o custo de log e I/O.
Outra opção é processar lotes:
100 mensagens → COMMIT
O desempenho pode melhorar.
Porém, se ocorrer falha, até cem mensagens poderão ser reapresentadas, dependendo da unidade de trabalho.
A escolha precisa equilibrar:
Não existe número mágico universal.
Teste com carga realista.
20. Segurança: ninguém entra no ônibus sem autorização
IBM MQ oferece vários níveis de segurança.
É possível controlar:
Em z/OS, a integração com RACF é particularmente importante.
Em outras plataformas, o Object Authority Manager participa do controle de acesso.
Um erro muito conhecido é:
MQRC_NOT_AUTHORIZED
Reason Code 2035
O código 2035 é praticamente um personagem recorrente nas histórias de IBM MQ.
Ele indica que a operação não foi autorizada.
Ao investigar, verifique:
Nunca resolva permanentemente um 2035 concedendo acesso total sem entender a causa.
Isso seria como remover todas as portas do ônibus para facilitar a entrada.
21. TLS: protegendo a mensagem durante a viagem
Canais MQ podem utilizar TLS para proteger a comunicação.
TLS oferece:
A configuração pode envolver:
Uma causa frequente de incidentes é certificado expirado.
O canal funcionou durante meses.
Então, em uma madrugada aparentemente tranquila:
CHANNEL STATUS: RETRYING
A investigação revela:
Certificate expired.
Dica operacional:
Certificados devem ser monitorados antes do vencimento, não depois da interrupção.
Não espere o ônibus chegar à ponte quebrada para procurar o manual.
22. MQ Cluster: várias rotas para o mesmo destino
Um cluster MQ facilita a conectividade entre Queue Managers.
Sem cluster, cada relação pode exigir definições explícitas.
Com cluster, objetos e rotas podem ser divulgados entre participantes.
Canais típicos:
CLUSSDR
CLUSRCVR
Um cluster pode ajudar em:
Entretanto, cluster não é magia.
Ele precisa de:
Uma mensagem enviada para uma fila clusterizada pode ser distribuída entre diferentes instâncias.
Mas, se a aplicação depende de todas as mensagens do mesmo cliente chegarem ao mesmo consumidor, será necessário considerar afinidade, agrupamento e ordenação.
23. Alta disponibilidade não é o mesmo que recuperação de desastre
Esses conceitos frequentemente são misturados.
Alta disponibilidade busca reduzir interrupções locais.
Disaster Recovery trata da recuperação diante de perda mais ampla do ambiente.
Soluções MQ podem envolver:
Queue Manager multi-instance;
RDQM;
clusters;
replicação;
armazenamento compartilhado;
IBM MQ Appliance;
Sysplex e Shared Queues no z/OS;
ambientes alternativos de recuperação.
Mas possuir dois servidores não significa automaticamente possuir alta disponibilidade.
É preciso testar:
O melhor plano de recuperação é aquele que já foi executado em teste.
Um documento perfeito que nunca foi testado é apenas literatura de suspense.
24. IBM MQ no z/OS
No mainframe, o IBM MQ se integra profundamente ao ecossistema IBM Z.
Pode trabalhar com:
CICS;
IMS;
Db2;
RACF;
Sysplex;
Coupling Facility;
batch COBOL;
aplicações Java;
serviços de integração.
No z/OS, filas compartilhadas podem utilizar estruturas na Coupling Facility.
Isso permite que diferentes Queue Managers de um Queue Sharing Group acessem filas compartilhadas.
Conceitualmente:
QM1 ─┐
├── Shared Queue
QM2 ─┤ na Coupling Facility
│
QM3 ─┘
Essa arquitetura oferece alta disponibilidade e escalabilidade excepcionais.
Se um Queue Manager ficar indisponível, outro pode continuar processando mensagens da fila compartilhada.
Para organizações financeiras, governamentais e de telecomunicações, isso pode ser decisivo.
25. Um exemplo completo: pagamento de cartão
Vamos acompanhar uma mensagem.
O cliente compra um produto de R$ 250,00.
A aplicação de vendas cria uma solicitação:
{
"transacao": "984532",
"cliente": "4711",
"valor": 250.00,
"moeda": "BRL"
}
A aplicação envia para:
PAGAMENTO.REQUISICAO
O MQ grava a mensagem.
O consumidor de pagamentos está temporariamente ocupado.
A mensagem espera.
Alguns segundos depois, o consumidor faz MQGET.
Ele consulta o sistema financeiro.
Depois envia uma resposta:
{
"transacao": "984532",
"status": "APROVADA",
"autorizacao": "AZ9182"
}
A resposta é colocada em:
PAGAMENTO.RESPOSTA
A aplicação de vendas recebe a confirmação.
Durante todo o processo, o MQ forneceu:
O IBM MQ não aprovou a compra.
Ele garantiu que o pedido e a resposta viajassem de forma controlada.
26. Passo a passo para investigar uma fila crescendo
Quando uma fila começa a acumular mensagens, não entre diretamente no modo pânico.
Siga uma sequência.
Passo 1 — Identifique a fila
Verifique:
CURDEPTH
MAXDEPTH
IPPROCS
OPPROCS
IPPROCS indica quantos processos possuem a fila aberta para entrada.
OPPROCS indica quantos possuem a fila aberta para saída.
Se IPPROCS for zero, talvez não exista consumidor conectado.
Passo 2 — Observe a tendência
A fila está:
crescendo;
estabilizada;
diminuindo;
oscilando?
Faça medições em intervalos.
Passo 3 — Verifique o consumidor
O processo está ativo?
Existem erros?
Ele está conectado ao Queue Manager correto?
Está lendo a fila correta?
Passo 4 — Verifique mensagens antigas
Qual é a idade da mensagem mais antiga?
Mensagens antigas podem indicar paralisação silenciosa.
Passo 5 — Verifique dependências
O consumidor pode estar ativo, porém preso em:
Db2;
API externa;
arquivo;
lock;
timeout;
serviço remoto.
Passo 6 — Avalie a taxa
Entrada:
1.500 mensagens/s
Saída:
900 mensagens/s
A fila continuará crescendo mesmo com consumidor ativo.
Passo 7 — Planeje a intervenção
Possibilidades:
Nunca remova mensagens de produção sem compreender seu valor de negócio.
27. Passo a passo para investigar um canal parado
Quando um canal Sender não está transmitindo:
1. Consulte o status
Estados comuns:
RUNNING
RETRYING
STOPPED
INACTIVE
BINDING
2. Verifique o Queue Manager remoto
Ele está ativo?
3. Teste a rede
O host responde?
A porta está aberta?
Existe firewall?
4. Verifique o Listener
O Listener remoto está iniciado?
5. Analise os logs
Procure erros de:
TLS;
autenticação;
sequência;
conexão;
autorização;
nome de canal.
6. Verifique a XMITQ
Ela está crescendo?
7. Evite reiniciar cegamente
Reiniciar pode mascarar o problema.
Primeiro capture evidências.
Depois execute a ação.
A diferença entre troubleshooting e superstição é a coleta de evidências.
28. Modernização não significa remover o MQ
Muitas empresas confundem modernização com substituição total.
Elas imaginam:
Legado = ruim
Cloud = bom
Fila = antiga
API = moderna
A realidade é muito mais sofisticada.
IBM MQ pode integrar:
mainframes;
microsserviços;
APIs;
nuvem híbrida;
containers;
sistemas SaaS;
eventos corporativos.
Modernizar pode significar:
automatizar deploy;
melhorar observabilidade;
atualizar versões;
usar REST Administration API;
integrar com Ansible;
adotar containers onde fizer sentido;
fortalecer segurança;
padronizar objetos;
implementar Infrastructure as Code;
reduzir configurações manuais.
O MQ não precisa desaparecer para a empresa se modernizar.
Em muitos casos, ele é justamente a camada que permite modernizar sem interromper sistemas críticos.
29. MQ versus REST
REST costuma ser síncrono.
Cliente → Requisição → Servidor
Cliente ← Resposta ← Servidor
O cliente espera.
Se o servidor estiver indisponível, a requisição pode falhar.
MQ é frequentemente assíncrono.
Produtor → Fila
→ Consumidor
O produtor entrega a mensagem e pode continuar.
Nenhuma tecnologia é universalmente melhor.
REST é excelente para:
consultas imediatas;
interação de usuário;
operações simples;
APIs públicas;
resposta rápida.
MQ é excelente para:
Uma arquitetura moderna pode utilizar os dois:
Aplicativo
↓ REST
API
↓ MQ
Processamento corporativo
A API recebe a solicitação.
O MQ garante o processamento interno.
30. MQ versus Kafka
Kafka e MQ também não são equivalentes.
IBM MQ é tradicionalmente orientado à entrega confiável de mensagens e filas.
Kafka é orientado a logs distribuídos e eventos retidos.
No MQ, normalmente uma mensagem é consumida e removida da fila.
No Kafka, eventos permanecem por um período configurado e podem ser relidos.
MQ é muito forte em:
transações;
point-to-point;
integração empresarial;
garantia de entrega;
controle fino;
sistemas críticos.
Kafka é muito forte em:
Empresas maduras podem usar ambos.
O erro está em transformar uma escolha arquitetural em disputa de torcida.
31. Dicas Bellacosa para o programador COBOL iniciante
Primeira dica:
Aprenda a diferença entre fila, canal e Queue Manager.
Segunda:
Sempre examine COMP-CODE e REASON-CODE.
Exemplo:
IF COMPLETION-CODE NOT = MQCC-OK
DISPLAY 'ERRO MQ'
DISPLAY 'COMP CODE: ' COMPLETION-CODE
DISPLAY 'REASON: ' REASON-CODE
END-IF
Terceira:
Não trate toda ausência de mensagem como erro.
Um MQGET pode retornar:
MQRC_NO_MSG_AVAILABLE
2033
Em muitos programas, isso apenas significa que não havia mensagem naquele momento.
Quarta:
Defina timeout conscientemente.
Um consumidor pode:
esperar indefinidamente;
esperar alguns segundos;
retornar imediatamente.
Quinta:
Compreenda syncpoint antes de processar mensagens financeiras.
Sexta:
Não grave mensagens sensíveis em logs sem mascaramento.
Sétima:
Documente o caminho completo.
Aplicação → Fila → Canal → Queue Manager → Fila → Consumidor
O mapa da mensagem é essencial durante incidentes.
32. Curiosidades do universo IBM MQ
O produto surgiu originalmente como MQSeries, no início da década de 1990.
Depois foi conhecido como:
WebSphere MQ
e voltou a ser chamado de:
IBM MQ
O nome mudou.
A missão permaneceu.
O MQ suporta múltiplas plataformas, como:
z/OS;
Linux;
Windows;
AIX;
IBM i;
containers;
appliances.
Uma mensagem pode nascer em um programa COBOL de décadas atrás e terminar em um microsserviço criado nesta semana.
Esse é um dos superpoderes silenciosos da mensageria empresarial.
Outro detalhe curioso é que os códigos de razão se tornam parte do vocabulário dos especialistas.
Você poderá ouvir frases como:
“Deu 2035.”
“Temos 2059.”
“A aplicação recebeu 2085.”
Para quem está de fora, parece uma conversa de agentes secretos.
Para quem trabalha com MQ:
2035 = não autorizado
2059 = Queue Manager indisponível
2085 = nome de objeto desconhecido
Easter egg:
Quando você começa a reconhecer códigos MQ antes mesmo de ler a descrição, oficialmente recebeu sua carteira de motorista da mensageria corporativa.
33. A grande lição
IBM MQ não é apenas um software de filas.
Ele representa uma filosofia de arquitetura.
Essa filosofia diz:
aplicações não precisam estar disponíveis ao mesmo tempo;
falhas temporárias podem ser absorvidas;
mensagens importantes não devem desaparecer;
produtores e consumidores podem evoluir separadamente;
picos podem ser amortecidos;
transações precisam de controle;
integração deve ser observável e segura.
O MQ aceita uma verdade que muitos sistemas modernos tentam ignorar:
Tudo falha em algum momento.
A rede falha.
O servidor reinicia.
A aplicação trava.
O certificado expira.
O banco fica lento.
O consumidor para.
A arquitetura resiliente não é aquela que acredita que nada falhará.
É aquela que sabe o que fazer quando a falha chegar.
Conclusão: mantenha a mensagem em movimento
No filme Velocidade Máxima, a tensão nasce porque o ônibus precisa continuar andando.
No IBM MQ, a mensagem precisa continuar avançando, mas não necessariamente sem parar.
Essa é a genialidade.
Se a estrada estiver bloqueada, ela pode esperar na Transmission Queue.
Se o consumidor estiver indisponível, ela pode permanecer na Local Queue.
Se o destino estiver errado, ela pode ser preservada na Dead-Letter Queue.
Se o processamento falhar, ela pode retornar por rollback.
Se a aplicação cliente estiver distante, ela pode entrar por um SVRCONN.
Se dois Queue Managers estiverem separados pela rede, Sender e Receiver Channels podem construir a ponte.
O MQ não promete que servidores nunca cairão.
Ele promete oferecer mecanismos para que a informação sobreviva às quedas.
Para o programador COBOL iniciante, estudar IBM MQ é aprender que integração não significa apenas chamar outro programa.
Significa pensar em:
Na próxima vez que alguém disser que o IBM MQ é apenas uma fila, olhe novamente para a arquitetura.
Ali existem rotas, depósitos, postos de controle, registros, certificados, mecanismos de recuperação e centros de comando.
Tudo trabalhando silenciosamente para que uma transação atravesse sistemas, plataformas e continentes.
O usuário pressiona um botão.
A aplicação executa um MQPUT.
A mensagem entra na fila.
O canal inicia a viagem.
O destino recebe.
O consumidor processa.
O commit confirma.
E, em algum centro de operações, um analista olha para o painel e percebe que o CURDEPTH finalmente começou a cair.
197.842
154.990
92.400
21.870
0
O ônibus está seguro.
A fila foi drenada.
A transação chegou.
E o café, embora já esteja frio, ainda está sobre a mesa do Bellacosa Mainframe.
