Translate

domingo, 14 de julho de 2019

O Caso das Duas Filas Fantasmas : Descobriu que uma Delas Guardava Segredos... e a Outra Fazia as Evidências Desaparecerem

 

Bellacosa Mainframe e o caso das duas filas fantasmas

☕ Um Café no Bellacosa Mainframe

O Caso das Duas Filas Fantasmas

Quando um Jovem Programador COBOL Descobriu que uma Delas Guardava Segredos... e a Outra Fazia as Evidências Desaparecerem

"Naquela madrugada, o silêncio do CPD era interrompido apenas pelo zumbido constante dos refrigeradores do IBM Z. Em algum lugar, milhões de transações cruzavam o sistema financeiro do país. Nenhum cliente imaginava que duas estruturas invisíveis decidiam, a cada milissegundo, o destino de seus dados. Elas eram conhecidas apenas por três letras: TSQ e TDQ."


Prólogo — O Mistério das Filas Invisíveis

Existe um momento na vida de todo programador COBOL em que ele percebe que escrever programas é apenas metade do trabalho.

A outra metade consiste em responder uma pergunta aparentemente simples:

"Onde vou guardar meus dados enquanto ainda não terminei de processá-los?"

Parece uma questão banal.

Mas ela já provocou perdas financeiras, sistemas travados, filas gigantescas de processamento, auditorias intermináveis e incontáveis noites sem dormir para programadores de bancos.

Foi justamente para resolver esse problema que o CICS criou duas ferramentas extraordinárias:

  • TSQ (Temporary Storage Queue)

  • TDQ (Transient Data Queue)

À primeira vista, ambas parecem fazer exatamente a mesma coisa.

As duas armazenam dados temporários.

As duas trabalham com filas.

As duas existem há décadas.

Mas basta observá-las um pouco mais de perto para perceber que estamos diante de duas personalidades completamente diferentes.

Como dois investigadores de uma história policial.

Um arquiva provas.

O outro as encaminha imediatamente para o laboratório.


Capítulo 1 — O CICS Nunca Faz Nada por Acaso

Existe uma frase muito conhecida entre veteranos de mainframe:

"Se o CICS possui dois comandos diferentes, existe um excelente motivo para isso."

Essa regra vale praticamente para tudo.

READ e READNEXT.

LINK e XCTL.

SYNCPOINT e ROLLBACK.

ENQ e DEQ.

TSQ e TDQ.

Nada foi criado por acaso.

Na década de 1970, memória era absurdamente cara.

Discos eram lentos.

CPU custava milhões de dólares.

Era impossível desperdiçar recursos.

Por isso os engenheiros da IBM criaram estruturas especializadas.

Cada uma fazia apenas aquilo em que era excelente.

E continua funcionando assim cinquenta anos depois.


Capítulo 2 — O Arquivo Secreto da Investigação

Imagine um detetive investigando um grande roubo.

Todos os dias ele recebe novas informações.

Fotografias.

Depoimentos.

Mapas.

Digitais.

Relatórios.

Ele não pode simplesmente jogar tudo fora após ler.

Muito menos enviar imediatamente ao juiz.

Ele precisa voltar inúmeras vezes.

Comparar evidências.

Adicionar observações.

Modificar hipóteses.

Esse arquivo secreto é exatamente uma TSQ.

Ela guarda informações temporárias.

Permite consultas infinitas.

Aceita alterações.

Nada desaparece até que alguém mande apagar.


TSQ é uma memória temporária extremamente inteligente

Ela permite:

✔ escrever

✔ ler

✔ alterar

✔ reler

✔ apagar

Quantas vezes forem necessárias.

Ela funciona quase como um pequeno banco de dados temporário.


Capítulo 3 — A Esteira da Delegacia

Agora imagine outra cena.

Chegam milhares de boletins de ocorrência.

Cada um precisa seguir imediatamente para outro departamento.

Ninguém volta para consultá-los.

Ninguém altera o conteúdo.

Ninguém lê novamente.

Eles entram.

São processados.

Desaparecem.

Essa é exatamente a filosofia da TDQ.

Ela não existe para guardar.

Ela existe para transportar.

É praticamente uma esteira de produção.


O Grande Segredo

Muitos iniciantes acreditam que a diferença entre TSQ e TDQ é apenas técnica.

Na verdade...

A diferença é filosófica.

TSQ pergunta:

"Você ainda precisará desta informação?"

TDQ pergunta:

"Você terminou de usá-la?"

Essas duas perguntas definem praticamente toda a arquitetura de inúmeras aplicações bancárias.


Capítulo 4 — A Anatomia da TSQ

Vamos abrir essa caixa preta.

Uma TSQ é composta por uma sequência de registros.

Algo parecido com isto:

ITEM 1
CPF

ITEM 2
Nome

ITEM 3
Saldo

ITEM 4
Limite

ITEM 5
Agência

Cada registro recebe um número chamado ITEM.

E aqui aparece uma enorme vantagem.

Você pode pedir diretamente:

Leia o ITEM 4

Sem precisar ler:

1

2

3

4

Isso é chamado de:

Random Access

(acesso aleatório)

É parecido com abrir um livro diretamente na página 218.


TSQ também lê em sequência

Ela também consegue fazer:

1

↓

2

↓

3

↓

4

↓

5

Ou seja...

Possui os dois mundos.

Acesso direto.

Ou sequencial.

Essa flexibilidade explica por que ela é tão utilizada em aplicações interativas.


Capítulo 5 — Como Funciona uma TDQ

Agora imagine uma fila de embarque em um aeroporto.

A pessoa entra.

Chega sua vez.

Passa pelo portão.

Nunca mais volta para a fila.

É exatamente isso.

Registro 1

↓

Registro 2

↓

Registro 3

↓

Registro 4

Quando um registro é lido...

Ele desaparece.

Não existe UPDATE.

Não existe REWRITE.

Não existe ITEM.

Não existe voltar.


Curiosidade Bellacosa ☕

Você sabia que muitos sistemas bancários antigos geravam milhões de registros de auditoria diariamente usando TDQs?

Se utilizassem TSQs para isso...

O armazenamento do CICS cresceria continuamente, consumindo recursos preciosos.

Foi justamente para evitar esse desperdício que a TDQ nasceu.

Ela "come" os registros conforme eles são processados.


Capítulo 6 — O Empréstimo Bancário

Vamos acompanhar uma situação real.

Carlos deseja financiar um automóvel.

Tela 1

Dados pessoais.

Tela 2

Endereço.

Tela 3

Renda.

Tela 4

Garantias.

Tela 5

Confirmação.

Enquanto Carlos navega...

Nada vai para o Db2.

Nada vai para VSAM.

Tudo permanece em uma TSQ.

Se ele voltar da tela cinco para a dois...

Os dados continuam lá.

Inclusive podendo ser modificados.

É exatamente por isso que aplicações de múltiplas telas adoram TSQs.


Capítulo 7 — O Caixa Eletrônico

Agora outro cenário.

São duas horas da manhã.

Milhares de caixas eletrônicos continuam funcionando.

Cada saque gera um registro.

ATM

↓

TDQ

↓

Batch Noturno

↓

Sistema Contábil

Quando o batch lê...

O registro desaparece.

Acabou.

Não faz sentido mantê-lo.

Ele cumpriu sua missão.


Easter Egg Nº 1 🕵️

Nas histórias policiais dos anos 1950 existia sempre uma sala chamada:

Arquivo Morto.

A TDQ seria exatamente isso.

Depois que o investigador utiliza uma informação...

Ela sai definitivamente da mesa.

Já a TSQ é a pasta que continua aberta sobre o escritório durante toda a investigação.


Capítulo 8 — A Diferença que Decide Arquiteturas

Imagine construir um sistema de internet banking.

Se você usar TDQ para guardar dados das telas...

O cliente aperta "Voltar".

Os dados sumiram.

Desastre.

Agora imagine utilizar TSQ para registrar milhões de logs.

Todos ficarão armazenados.

O consumo de armazenamento crescerá rapidamente.

Outro desastre.

Percebe?

Não existe estrutura melhor.

Existe estrutura correta.


Capítulo 9 — A Relação com Outros Comandos do CICS

Nenhum comando vive sozinho.

TSQ conversa naturalmente com:

  • LINK

  • XCTL

  • COMMAREA

  • HANDLE CONDITION

  • HANDLE ABEND

  • SYNCPOINT

Imagine:

Programa A

LINK

Programa B

TSQ

Programa C

LINK

TSQ

Diversos programas podem consultar a mesma informação temporária enquanto a lógica da aplicação continua.


Já TDQ normalmente aparece ligada a:

  • processamento batch

  • geração de logs

  • auditoria

  • interfaces

  • integração entre sistemas

É quase uma ponte entre o mundo online e o mundo batch.


Capítulo 10 — Os Dois Tipos de TDQ

Poucos livros explicam isso para iniciantes.

Existem duas categorias.

Intra-partition

Tudo acontece dentro do próprio CICS.

É extremamente rápida.

Ideal para comunicação interna.


Extra-partition

Conecta o CICS ao mundo externo.

Pode gravar em:

  • datasets

  • impressoras

  • arquivos

  • sistemas externos

É como uma porta de saída do CICS.


Curiosidade Histórica

Antes do IBM MQ dominar muitos ambientes corporativos, inúmeras integrações eram realizadas utilizando TDQs.

Durante décadas elas foram verdadeiras "mensageiras" do processamento batch.

Muitos bancos ainda utilizam esse mecanismo hoje.


Capítulo 11 — Performance

Uma pergunta frequente.

Qual é mais rápida?

A resposta correta é:

Depende do problema.

TSQ faz muito mais.

Ela:

  • altera

  • regrava

  • relê

Logo...

Possui mais operações.

TDQ é mais simples.

Escreveu.

Leu.

Removeu.

Por isso consegue ser extremamente eficiente para fluxos sequenciais.


Capítulo 12 — O Que Acontece em Caso de Erro?

Aqui aparece outro detalhe interessante.

Imagine:

Programa gravou informações na TSQ.

Ocorreu um ABEND.

Dependendo da forma como a fila foi definida (recoverable ou não), ela pode participar da Unidade de Trabalho (UOW) do CICS e ser afetada por um SYNCPOINT ROLLBACK.

Esse comportamento é controlado pela configuração do ambiente e é um tema importante para arquiteturas críticas.

O mesmo vale para TDQs: o comportamento de recuperação varia conforme o tipo da fila e sua definição administrativa.

É por isso que arquitetos CICS sempre conversam com administradores antes de decidir qual fila utilizar.


Capítulo 13 — Os Erros que Todo Iniciante Comete

Erro 1

Guardar sessão do usuário em TDQ.

Resultado:

Nada funciona ao voltar de tela.


Erro 2

Guardar logs em TSQ.

Resultado:

Consumo enorme de armazenamento.


Erro 3

Nunca apagar TSQs.

Resultado:

Acúmulo desnecessário de filas temporárias.


Erro 4

Esperar alterar um registro da TDQ.

Não existe UPDATE.

Nem REWRITE.


Erro 5

Achar que COMMAREA substitui TSQ.

Não substitui.

COMMAREA é excelente para transportar dados entre programas na mesma transação.

TSQ é melhor quando a informação precisa permanecer disponível durante várias etapas ou quando seu volume excede o que é conveniente manter na COMMAREA.


Dicas de Ouro para Entrevistas

Quando o entrevistador perguntar:

"Quando usar TSQ?"

Nunca responda apenas:

"Quando preciso guardar dados."

Diga:

"Quando preciso manter informações temporárias disponíveis para múltiplas leituras, possíveis atualizações e acesso por item durante o processamento da aplicação."


Quando perguntarem:

"Quando usar TDQ?"

Responda:

"Quando os dados representam um fluxo de processamento sequencial e devem ser consumidos apenas uma vez, como logs, auditorias e interfaces batch."

Essa resposta demonstra que você compreendeu a filosofia por trás de cada estrutura, não apenas a sintaxe.


Easter Egg Nº 2 ☕

Observe as iniciais:

Temporary Storage Queue

TSQ

A palavra importante não é Queue.

É Storage.

Ela nasceu para armazenar.

Já em:

Transient Data Queue

TDQ

A palavra importante é Transient.

Ela nasceu para passar, transitar, seguir viagem.

Os próprios nomes entregam sua verdadeira natureza.


Curiosidade IBM

Nos grandes bancos é comum encontrar milhares de TSQs e TDQs sendo utilizadas simultaneamente por aplicações diferentes. O CICS gerencia tudo isso de forma transparente, mantendo isolamento entre transações e garantindo alto desempenho mesmo sob cargas gigantescas.


Bellacosa Insight ☕

Existe uma frase que poderia estar gravada na porta de todo CPD:

"Dados que ainda contam uma história pertencem à TSQ. Dados que já cumpriram sua missão pertencem à TDQ."

Essa simples ideia resume décadas de experiência em arquitetura CICS.


O Veredito Final

No fim da investigação, o jovem programador percebeu que o verdadeiro mistério nunca foi descobrir como gravar dados em uma fila, mas entender por que o CICS oferece duas filas com comportamentos tão distintos.

A TSQ é o caderno do investigador: guarda pistas, aceita anotações, permite voltar páginas e revisar hipóteses até que o caso seja encerrado. Ela representa o estado temporário da aplicação, preservando contexto, formulários, cálculos intermediários e informações que ainda podem mudar.

A TDQ, por outro lado, é a esteira do departamento de evidências: cada registro segue seu caminho, é analisado uma única vez e então desaparece. É a ferramenta ideal para logs, auditorias, integração com processamento batch e qualquer fluxo em que a informação deve ser consumida sem possibilidade de retorno.

Dominar essa diferença é um dos ritos de passagem de todo desenvolvedor COBOL/CICS. Afinal, escrever um programa que funciona é importante; escrever um programa que escolhe a estrutura correta para cada tipo de dado é o que separa o iniciante do profissional capaz de manter aplicações que movimentam bilhões de reais todos os dias.

E, como em toda boa história noir dos anos 1950, o maior segredo estava escondido à vista de todos: as duas filas sempre estiveram lado a lado, mas apenas quem compreende sua natureza sabe qual delas abrir quando uma nova transação bate à porta do CICS.


Sem comentários:

Enviar um comentário

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988