Bellacosa Mainframe e o IBM MQ

☕ Um Café no Bellacosa Mainframe

**IBM MQ — Quando The Postman Encontrou um Queue Manager, Viu Igor Tentando Mandar um PIX por E-mail e Decidiu Reconstruir a Civilização**

Ou: Kevin Costner atravessou uma América quebrada com uma sacola de cartas, um jovem padawan COBOL descobriu que uma fila não é apenas uma espera, CICS encontrou Db2 no meio da estrada — e o carteiro ensinou que “mensagem entregue” é uma promessa séria demais para depender de sorte

Prólogo — A carta que não podia sumir

No filme The Postman (1997), Kevin Costner interpreta um sobrevivente num Estados Unidos pós-colapso. Em certo momento, ele veste o uniforme de um antigo carteiro e começa a levar cartas entre comunidades isoladas. Não são só papéis: aquelas mensagens transportam notícias, esperança, pedidos, vínculos e a prova de que ainda existe algum tipo de ordem naquele mundo quebrado.

IBM MQ é, guardadas as devidas proporções e sem o cavalo, o carteiro de sistemas corporativos.

Ele não entrega cartas manuscritas. Entrega uma solicitação de transferência, uma ordem de pagamento, uma reserva de voo, uma confirmação de compra, um aviso de fraude, um comando para atualizar estoque ou o pedido para emitir uma apólice. E sua grande missão é simples de dizer, difícil de cumprir e caríssima quando falha:

Receber a mensagem, guardá-la com segurança e entregá-la ao destino certo mesmo quando parte do mundo tecnológico está tendo um ataque de nervos.

Para quem está começando em COBOL, IBM MQ parece inicialmente “mais uma sopa de letras corporativa”. Temos JCL, CICS, Db2, VSAM, RACF, MQ, JES2, IMS e, em algum corredor escuro, Igor tentando resolver integração distribuída com um PERFORM UNTIL WS-TUDO-FUNCIONE.

Mas a ideia básica é muito humana: se eu preciso mandar algo importante e o destinatário não está disponível agora, não jogo a carta fora. Eu a deixo sob a responsabilidade de um serviço confiável.

E esse serviço é o IBM MQ.

1. O problema: sistemas não vivem no mesmo horário

Imagine um banco. O aplicativo móvel recebe um pedido:

Transferir R$ 500,00 da conta A para a conta B.

A aplicação do celular está na cloud. A validação antifraude pode estar em Kubernetes. O core bancário pode rodar COBOL, CICS e Db2 no z/OS. A notificação ao cliente pode estar em outra plataforma.

Se tudo fosse uma chamada síncrona, a história seria assim:

Aplicativo → chama serviço → chama outro serviço → chama CICS → espera

Agora imagine que o sistema de liquidação está em manutenção, a rede oscila ou uma região inteira reinicia. Se cada componente precisar estar vivo, rápido e de bom humor no mesmo instante, a operação vira uma torre de dominós.

A chamada síncrona tem seu lugar. Quando o cliente pergunta “qual é meu saldo?”, normalmente espera uma resposta agora. Mas uma instrução importante — “registre esta transferência” — pode ser tratada de outro modo:

Aplicativo → IBM MQ → fila segura → sistema processador

O aplicativo entrega a mensagem ao MQ e o MQ assume a responsabilidade de conservá-la até o consumidor poder trabalhar.

Essa separação é chamada de desacoplamento temporal. Produtor e consumidor deixam de precisar respirar no mesmo ritmo.

2. Afinal, o que é IBM MQ?

IBM MQ é um middleware de mensageria empresarial. “Middleware” é aquele software que vive entre aplicações e impede que elas precisem saber demais umas das outras.

Ele não é banco de dados. Não é API REST. Não é CICS. Não é Kafka. Não é uma planilha com uma coluna chamada “pendências”, embora algumas empresas tenham chegado perigosamente perto disso.

Ele é uma infraestrutura para troca confiável de mensagens.

Os principais personagens são:

Personagem	O que faz
Aplicação produtora	Cria e envia uma mensagem
Mensagem	Carrega dados e metadados da operação
Fila	Espera organizada para mensagens
Aplicação consumidora	Retira e processa a mensagem
Queue Manager	Administra filas, logs, segurança e recuperação
Canal	Rota controlada entre Queue Managers

O Queue Manager é o carteiro-chefe, o gerente do correio e o sujeito que sabe onde cada carta está. Ele cria e gerencia filas, grava mensagens persistentes, controla acessos, conversa com outros Queue Managers e tenta evitar que uma falha técnica se transforme em perda de negócio.

3. Fila não é atraso; fila é proteção

Muita gente ouve “fila” e pensa: “então meu sistema ficou lento”.

Nem sempre.

Uma fila pode funcionar como amortecedor. Pense na Black Friday: o site recebe 20 mil pedidos por minuto, mas o faturamento legado consegue tratar 2 mil por minuto com segurança. Sem uma fila, o site pressiona o sistema de faturamento até ambos caírem de mãos dadas, como dois personagens de filme-catástrofe.

Com MQ:

Pedidos chegam rápido
        ↓
Fila IBM MQ absorve o pico
        ↓
Faturamento processa no ritmo seguro

A operação continua registrada. Pode haver espera, sim, mas espera controlada é muito melhor que pedido perdido, duplicado ou uma tela dizendo “Erro inesperado. Tente novamente” — frase que, no idioma do cliente, significa “o que aconteceu com meu dinheiro?”.

No mundo real, a profundidade de uma fila é um sinal de saúde. Uma fila crescendo pode indicar aumento legítimo de demanda, lentidão do consumidor, indisponibilidade, erro de conexão ou uma aplicação que resolveu entrar em meditação transcendental às 03h17.

4. Persistência: a carta entrou no cofre

Uma mensagem pode ser persistente ou não persistente.

Mensagens não persistentes servem para situações em que perder alguma informação é tolerável: telemetria, indicadores passageiros, dados de baixa criticidade. Já uma transferência financeira, uma ordem de compra ou uma emissão de bilhete precisa sobreviver a queda de processo, servidor ou conexão.

Quando configurada como persistente, a mensagem é registrada de forma recuperável pelo MQ. Se o Queue Manager cair depois de receber a mensagem, ele usa seus logs para recuperar um estado consistente no retorno.

Em português de boteco:

Não é “deixei um bilhete na mesa”. É “depositei a carta no cofre, peguei recibo e agora o carteiro responde por ela”.

Exemplo:

Um programa COBOL coloca uma solicitação na fila.
O MQ confirma que aceitou a mensagem.
O sistema consumidor fica indisponível.
A mensagem continua guardada.
O consumidor volta.
A operação é processada.

Isso é ouro em ambientes críticos.

5. O detalhe que separa demo de produção: commit e rollback

O padawan COBOL precisa guardar esta lição no bolso do uniforme do carteiro: MQ e Db2 precisam conversar direito.

Imagine que um programa CICS recebe uma mensagem para efetuar uma transferência. Ele precisa:

debitar a conta;
creditar a outra;
registrar auditoria;
talvez enviar uma mensagem de confirmação.

Se ele atualizar o Db2 e cair antes de confirmar o consumo da mensagem, ela pode reaparecer. Se mandar a mensagem e cair antes de atualizar o Db2, a integração pode contar uma história diferente do banco.

É aqui que entram unidades de trabalho e syncpoint.

A sequência saudável é:

GET da mensagem
↓
Atualizações no Db2
↓
Validações de negócio
↓
COMMIT
↓
Mensagem é definitivamente confirmada

Se algo falhar antes do COMMIT, pode ocorrer ROLLBACK: as atualizações são desfeitas e a mensagem permanece disponível para nova tentativa.

Mas atenção: “exactly once” não é feitiço de Hogwarts. MQ fornece mecanismos robustos de entrega e processamento transacional; ainda assim, a aplicação deve ser idempotente.

Idempotência significa que, se uma mesma instrução chegar de novo, o efeito de negócio não pode ser repetido indevidamente.

Exemplo: a mensagem possui um identificador único de transferência. Antes de debitar, o programa consulta uma tabela de controle. Se aquele identificador já foi liquidado, ele não debita novamente.

Porque uma fila confiável protege o transporte. Quem protege a regra “não cobrar duas vezes” é o desenho completo da solução.

6. Como COBOL conversa com MQ?

Em COBOL, o programa chama a API MQ. Os nomes clássicos aparecem como personagens de uma velha peça:

MQCONN — conecta ao Queue Manager;
MQOPEN — abre uma fila;
MQPUT — coloca uma mensagem;
MQGET — retira uma mensagem;
MQCLOSE — fecha a fila;
MQDISC — desconecta.

Um esqueleto conceitual de envio seria:

MOVE 'TRANSFERENCIA|000123|500.00' TO WS-MENSAGEM

CALL 'MQPUT'
  USING HCONN
        HOBJ
        MD
        PMO
        WS-TAMANHO
        WS-MENSAGEM
        COMPLETION-CODE
        REASON-CODE
END-CALL

Na vida real há estruturas, opções, códigos de retorno e cuidados com charset, tamanho, transação e tratamento de erro. Mas o conceito é simples: seu COBOL prepara uma mensagem e pede ao MQ que a coloque numa fila.

O consumidor faz o caminho inverso com MQGET.

Eis um bom conselho de mestre Jedi: não enfie regra de negócio inteira dentro do texto da mensagem. Defina contratos claros. Use campos identificáveis, versões de layout e documentação. Uma mensagem que ninguém entende seis meses depois é só um VSAM emocional.

7. Mensagem não é só conteúdo

Uma mensagem MQ tem corpo e metadados. O corpo pode trazer JSON, XML, texto delimitado, cópia COBOL, bytes binários ou outro formato acordado.

Os metadados ajudam muito:

MsgId: identificador da mensagem;
CorrelId: relaciona uma resposta ao pedido original;
prioridade;
data de expiração;
persistência;
formato;
identificador de aplicação;
contexto de segurança.

O CorrelId é especialmente útil em request-reply. Uma aplicação manda uma solicitação e espera uma resposta associada àquele pedido, não à resposta de algum outro cliente que estava passeando pela fila.

É o equivalente a escrever o número do protocolo na carta. Sem isso, o carteiro Kevin Costner entrega a resposta da sua transferência para o sujeito da reserva aérea, e logo Igor propõe “um ajuste manual temporário”.

8. Ordem, retries e as filas onde moram os monstros

MQ pode preservar ordem em uma fila, mas o arquiteto precisa perguntar: ordem de quê?

Com vários consumidores paralelos, prioridades, reprocessamentos e múltiplos caminhos, a ordem global pode não ser a mesma. Para uma reserva aérea, talvez seja necessário respeitar a sequência dos eventos daquela reserva específica:

RESERVA-CRIADA
PAGAMENTO-APROVADO
BILHETE-EMITIDO

Não é preciso impedir que outras reservas sejam processadas em paralelo. O segredo é usar chaves de correlação, identificadores de negócio e desenho consciente.

E quando a mensagem falha?

Ela não deve ser reprocessada eternamente como funcionário tentando autenticar num ambiente RACF com senha expirada. É preciso prever:

tentativas controladas;
fila de backout;
dead-letter queue;
monitoramento;
alertas de profundidade e idade da fila;
procedimento de investigação e reprocessamento.

A dead-letter queue não é o cemitério onde se joga a culpa. É uma caixa postal especial que diz: “esta mensagem não chegou ao destino; alguém precisa entender por quê”.

9. Segurança: o carteiro não entrega a carta para qualquer um

IBM MQ pode trabalhar com autenticação, autorização, TLS e integração com controles corporativos. Em z/OS, RACF pode definir quem conecta, quem abre uma fila, quem põe mensagens, quem lê e quem administra.

Uma boa configuração inclui:

canais protegidos por TLS;
certificados adequadamente geridos;
contas técnicas com privilégio mínimo;
regras por fila;
auditoria;
proteção contra dados sensíveis em logs;
monitoramento de acessos anormais.

MQ não torna uma arquitetura segura por telepatia. Ele oferece mecanismos para isso. Deixar uma fila financeira aberta para qualquer usuário técnico é como Kevin Costner entregar o saco de cartas ao primeiro miliciano de passagem e esperar boas práticas.

10. MQ, REST e Kafka: ninguém precisa sair na porrada

REST é ótimo quando alguém precisa perguntar e receber resposta imediata. MQ é ótimo quando uma instrução crítica precisa sobreviver a indisponibilidades. Kafka costuma ser poderoso para fluxos de eventos e múltiplos consumidores, especialmente em análise e streaming.

Uma empresa madura pode usar os três.

App chama API
↓
API valida pedido
↓
MQ entrega instrução ao core COBOL/CICS
↓
Db2 registra o estado
↓
Evento alimenta analytics

Modernização não significa jogar COBOL pela janela e substituir tudo por microsserviços com nomes de planetas. Significa conectar o que já é sólido ao que precisa evoluir.

O mainframe continua excelente onde consistência, escala, transação e disponibilidade importam. MQ é uma das pontes mais elegantes entre essa fortaleza e o resto do universo.

11. Roteiro de estudo para o padawan COBOL

Comece nesta ordem:

Entenda produtor, consumidor, mensagem, fila e Queue Manager.
Aprenda a diferença entre MQPUT e MQGET.
Estude persistência e unidades de trabalho.
Entenda COMMIT, ROLLBACK e idempotência.
Pratique MsgId e CorrelId.
Descubra o que são channels e comunicação entre Queue Managers.
Estude segurança, TLS e autorização.
Aprenda a monitorar filas, backout e dead-letter queue.
Monte um laboratório simples: programa envia pedido, outro consome e registra resultado.
Depois conecte isso a CICS e Db2.

O objetivo não é decorar siglas. É olhar para uma arquitetura e enxergar o caminho da mensagem: quem a criou, onde ela espera, quem a consome, o que acontece se algo cair e como provar que o negócio ficou consistente.

Epílogo — A república reconstruída por mensagens

No filme, o uniforme de carteiro vira símbolo de reconstrução. As pessoas voltam a acreditar que uma mensagem pode atravessar distância, caos e medo para alcançar alguém.

IBM MQ faz algo parecido no mundo corporativo. Ele não deixa sistemas conversarem apenas quando o céu está azul e todos os servidores estão felizes. Ele cria um mecanismo para que informações importantes resistam a falhas, picos, reinícios, lentidão e à inevitável criatividade humana em produção.

Para o programador COBOL iniciante, a lição é poderosa: você não escreve apenas programas que movem campos de uma área para outra. Em muitos ambientes, você escreve parte de uma cadeia que transporta decisões de negócio pelo mundo.

E, entre o MQPUT, o COMMIT, o Db2 e o consumidor do outro lado, existe um velho carteiro atravessando a estrada:

“A mensagem chegou ao MQ. Agora ela não está mais perdida. Ela tem destino, recibo, guarda e história.”

Porque nem todo problema precisa virar um ABEND — mas toda mensagem crítica merece um bom carteiro.

Translate

sábado, 13 de julho de 2024