☕💾🔥 CICS DATA SETS — O “SUBSOLO INVISÍVEL” QUE MANTÉM BANCOS VIVOS NO MAINFRAME IBM Z

O programador COBOL vê EXEC CICS.

O sysprog vê sobrevivência transacional.

Quando um programador iniciante começa no CICS, normalmente ele enxerga apenas:

EXEC CICS READ
EXEC CICS WRITE
EXEC CICS RETURN

Mas existe um universo gigantesco escondido por trás disso.

Um universo formado por:

• recovery,

• tracing,

• logging,

• observabilidade,

• filas,

• rollback,

• dumps,

• persistência operacional,

• orchestration.

E é exatamente isso que os datasets do CICS representam.

Neste artigo vamos mergulhar profundamente no “lado invisível” do CICS.

Porque:

entender datasets do CICS é começar a pensar como um verdadeiro sysprog.

---

☕ O CICS NÃO É Apenas Um Transaction Monitor

Essa é uma das maiores descobertas que um profissional faz quando amadurece no mundo mainframe.

O CICS:

• não é apenas EXEC CICS,

• não é apenas COBOL online,

• não é apenas tela verde.

Ele é:

• transaction manager,

• recovery engine,

• queue manager,

• observability platform,

• tracing framework,

• runtime orchestrator.

E os datasets são literalmente:

os órgãos internos dessa criatura.

---

🔥 DFHCSD — O DNA Operacional do CICS

O primeiro dataset que um sysprog precisa entender profundamente é:

DFHCSD

O famoso:

CICS System Definition File.

---

☕ O Que o CSD Realmente Faz?

Ele funciona como:

• catálogo mestre,

• banco de definições,

• repositório operacional.

Tudo o que o CICS precisa conhecer:

• PROGRAM,

• TRANSACTION,

• FILE,

• TERMINAL,

• TCPIPSERVICE,

• URIMAP,

• TDQUEUE,

• JVMSERVER,

• PIPELINE,

fica definido no CSD.

---

🔥 O CICS NÃO “DESCUBRE” Recursos Automaticamente

Esse é um ponto fundamental.

No mundo cloud moderno muita gente está acostumada com:

• service discovery,

• auto registration,

• dynamic orchestration.

Mas o CICS nasceu em um mundo onde:

previsibilidade e controle eram mais importantes do que automação descontrolada.

Tudo precisa ser explicitamente definido.

---

☕ O Grande Segredo Arquitetural

O runtime do CICS:

NÃO trabalha diretamente no CSD.

Durante startup ocorre:

DFHCSD
   ↓
INSTALL
   ↓
Control Blocks em memória
   ↓
Runtime CICS

Isso é extremamente sofisticado.

---

🔥 O Que São Control Blocks?

São estruturas internas contendo:

• atributos,

• endereços,

• localização dos programas,

• flags,

• status operacional.

Quando um programa executa:

EXEC CICS LINK PROGRAM('PGM001')

O CICS consulta:

control blocks em memória.

Não o CSD.

---

☕ Isso Explica a Velocidade do CICS

Tudo fica:

• pré-carregado,

• indexado,

• organizado,

• otimizado em memória.

Décadas antes do conceito moderno de:

• metadata caching,

• in-memory orchestration,

• runtime repositories.

---

🔥 O CSD Revolucionou o CICS

Antes dele existiam:

• PPT,

• PCT,

• FCT,

• TCT.

Control tables extremamente rígidas.

Alterações exigiam:

• assemble,

• link-edit,

• restart.

O CSD trouxe:

• definição dinâmica,

• administração online,

• menos downtime,

• maior agilidade.

---

☕ DFHLOG — O Coração da Integridade Transacional

Agora chegamos no componente mais crítico de todos:

o system log.

Sem ele:

• bancos quebrariam,

• saldos ficariam inconsistentes,

• transações seriam perdidas.

---

🔥 O Que o DFHLOG Faz?

Ele registra:

• before images,

• syncpoints,

• rollback records,

• updates,

• UOWs.

Tudo necessário para:

recovery transacional.

---

☕ Before Image — Conceito Fundamental

Antes de alterar um dado:

o CICS grava o estado anterior.

Exemplo:

Saldo = 1000
↓
Tentativa de update para 800

Antes disso:

o valor antigo é registrado no log.

---

🔥 Dynamic Transaction Backout (DTB)

Agora imagine:

Debita conta A
↓
ABEND
↓
Crash

O CICS:

• consulta o DFHLOG,

• identifica updates incompletos,

• executa rollback,

• restaura integridade.

Isso é:

DTB — Dynamic Transaction Backout.

---

☕ Warm Start e Emergency Restart

Quando o CICS reinicia:

ele escaneia o log inteiro.

Para descobrir:

• quais tasks estavam ativas,

• quais UOWs precisam rollback,

• quais recursos devem ser restaurados.

---

🔥 Primary e Secondary Streams

O system log lógico é composto por:

• Primary stream

• Secondary stream

Ambos são vistos como:

um único logical log stream.

Isso mostra uma arquitetura extremamente madura.

---

☕ DFHSHUNT — O Mundo das Shunted UOWs

Quando uma Unit of Work:

• não consegue completar recovery,

• possui recurso indisponível,

• encontra erro persistente,

ela pode ficar:

shunted.

O CICS NÃO perde a integridade.

Ele preserva a UOW para recuperação posterior.

Isso é engenharia mission-critical real.

---

🔥 Dumps — A Forense do CICS

O CICS possui dois níveis principais de dump.

---

☕ System Dump

Captura:

• região inteira,

• memória,

• address spaces,

• control blocks,

• storage global.

Vai normalmente para:

SYS1.DUMPnn

É usado em:

• falhas severas,

• storage corruption,

• kernel problems.

---

🔥 Transaction Dump

Mais focado.

Captura:

• task específica,

• COMMAREA,

• EIB,

• storage da transação.

Usa:

DFHDMPA
DFHDMPB

Muito usado em:

• ASRA,

• S0C7,

• AICA,

• debugging aplicativo.

---

☕ Trace — O Gravador de Voo do CICS

O tracing do CICS é uma obra-prima da engenharia enterprise.

---

🔥 CETR — O Painel de Controle do Trace

A transação:

CETR

permite:

• ativar trace,

• parar trace,

• selecionar domains,

• ajustar níveis,

• controlar GTF,

• configurar auxiliary trace.

---

☕ GTF — Generalized Trace Facility

O GTF integra:

• CICS,

• z/OS,

• VTAM,

• DB2,

• TCP/IP.

Permitindo tracing sistêmico.

Muito antes do conceito moderno de:

• distributed tracing,

• observability pipelines,

• telemetry frameworks.

---

🔥 Auxiliary Trace — Evitando o Wrapping

Trace em memória é circular.

Quando enche:

sobrescreve dados antigos.

Para evitar isso:

DFHAUXT
DFHBUXT

permitem:

• persistência,

• grandes volumes,

• rotação automática.

Isso é praticamente:

rolling logs décadas antes do Linux popularizar isso.

---

☕ SMF — O Big Data Operacional do Mainframe

O CICS também produz telemetria enterprise.

---

🔥 O Que o CICS Grava no SMF?

• CPU usage,

• elapsed time,

• transaction counts,

• waits,

• VSAM activity,

• DB2 usage,

• storage consumption.

Especialmente via:

SMF Type 110

---

☕ Muito Antes da “Observabilidade Moderna”

Enquanto muita gente fala hoje sobre:

• Prometheus,

• Grafana,

• OpenTelemetry,

• observability,

O z/OS já fazia isso:

há décadas.

---

🔥 TSQ — Temporary Storage Queue

O CICS frequentemente precisa guardar dados temporários.

Para isso existem:

TSQs.

---

☕ Características da TSQ

• criação dinâmica,

• leitura por item,

• releitura,

• update.

Exemplo:

EXEC CICS WRITEQ TS
     QUEUE('TEMP001')
END-EXEC

---

🔥 Main TS vs Auxiliary TS

Main TS

• memória,

• rápido,

• temporário.

Auxiliary TS

• VSAM,

• persistente,

• maior capacidade.

Muito usado via:

DFHTEMP

---

☕ TDQ — Transient Data Queue

Agora chegamos em um clássico absoluto do CICS.

---

🔥 TDQ vs TSQ

Essa diferença derruba muitos iniciantes.

---

☕ TSQ

Mais flexível.

---

🔥 TDQ

Mais orientada a fluxo:

• leitura sequencial,

• destrutiva,

• pré-definida.

Ideal para:

• impressão,

• integração batch,

• pipelines assíncronos.

---

☕ Intrapartition vs Extrapartition

Intrapartition

Usada:

dentro da região CICS.

Controlada pelo próprio CICS.

---

Extrapartition

Usada:

dentro e fora do CICS.

Muito comum em:

• integração batch,

• JES,

• exportação,

• geração de arquivos.

---

🔥 O CICS Já Fazia Mensageria Muito Antes do Kafka

Observe algo impressionante.

Décadas antes de:

• Kafka,

• RabbitMQ,

• Event Streaming,

• Message Brokers modernos,

O CICS já implementava:

• filas,

• desacoplamento,

• processamento assíncrono,

• integração enterprise.

---

☕ Global Catalog — A Memória Persistente do Runtime

O global catalog:

• salva recursos instalados,

• guarda localização do system log,

• ajuda no warm start,

• auxilia recovery.

---

🔥 Installed ≠ Defined

Esse conceito é importantíssimo.

Defined

Existe no CSD.

Installed

Está ativo no runtime.

---

☕ O CICS Separa Configuração de Runtime

Isso é extremamente moderno.

Mesmo conceito atual de:

• configuration repositories,

• runtime metadata,

• orchestration state.

---

🔥 O Que Um Sysprog Junior Deve Entender?

Se você está começando em sysprog CICS:

pare de enxergar apenas EXEC CICS.

Comece a enxergar:

• recovery,

• rollback,

• observabilidade,

• logs,

• tracing,

• queues,

• startup orchestration,

• runtime control blocks.

Porque:

é isso que mantém bancos funcionando sem parar.

---

☕ O Grande Insight Final

O mais impressionante do CICS é perceber que:

muito antes da computação distribuída moderna existir,

o mainframe já havia resolvido problemas extremamente complexos.

Como:

• observabilidade,

• tracing,

• rollback automático,

• crash recovery,

• filas assíncronas,

• persistência runtime,

• transaction management.

---

🔥 Pensamento Final ao Estilo Bellacosa Mainframe

O programador iniciante vê:

EXEC CICS READ

O sysprog experiente vê:

• DFHLOG,

• SMF,

• CETR,

• GTF,

• recovery manager,

• syncpoints,

• UOWs,

• auxiliary trace,

• control blocks,

• startup orchestration.

E entende que:

o CICS não é apenas um monitor transacional.

Ele é uma das arquiteturas mais sofisticadas já construídas na história da computação enterprise.

☕💾🔥

 

Cics filas TSQ e TDQ passagem de dados

🔥 Understanding QUEUE, TSQ e TDQ no CICS

 

---

☕ Midnight Lunch, fila cheia e CICS aberto

Todo mainframer já passou por isso: programa CICS travado, usuário reclamando, operador olhando o CEMT, e alguém solta a clássica pergunta:

“Isso aí não é fila? TSQ ou TDQ?”

E o silêncio toma conta do data center.
Vamos resolver isso de vez, no estilo Bellacosa: com história, conceito, prática, fofoca técnica e alguns easter eggs de quem já levou AEI0 na testa.

---

🏛️ Um pouco de história: filas antes da nuvem

Antes de Kafka, Redis, RabbitMQ e afins, o CICS já sabia lidar com filas.
Desde os anos 70, IBM introduziu mecanismos simples, rápidos e extremamente eficientes para armazenar dados temporários ou sequenciais durante a execução de transações online.

Esses mecanismos são chamados genericamente de QUEUE, mas na prática se dividem em:

• TSQ – Temporary Storage Queue

• TDQ – Transient Data Queue

Ambos são filas, mas com propósitos, comportamentos e riscos bem diferentes.

---

🧠 Conceito-chave (guarde isso como mantra)

TSQ = memória temporária, aleatória, flexível
TDQ = fluxo sequencial, estilo arquivo/log, orientado a eventos

Se você entendeu isso, já está 50% certificado CICS 😄

---

📦 TSQ – Temporary Storage Queue

O que é?

Uma fila temporária de armazenamento usada por programas CICS para guardar dados durante ou entre transações.

Ela pode residir:

• Em memória (MAIN)

• Em disco (AUX – VSAM)

Características

✔ Acesso direto por item
✔ Pode ler, escrever, atualizar e apagar
✔ Pode sobreviver ao fim da transação
✔ Pode ser compartilhada entre programas

Comandos principais

EXEC CICS WRITEQ TS
EXEC CICS READQ TS
EXEC CICS DELETEQ TS

Exemplo mental (Bellacosa way)

Imagine um post-it compartilhado entre programas CICS:

• Programa A escreve dados

• Programa B lê

• Programa C atualiza

• Programa D apaga

Tudo rápido, sem I/O pesado.

---

⚠️ Armadilhas clássicas (easter eggs)

• TSQ esquecida = vazamento de storage

• Nome dinâmico mal feito = fila órfã

• Volume alto em MAIN = SOS no CEMT I TASK

📌 Dica de ouro: sempre pense em DELETEQ TS.

---

🧾 TDQ – Transient Data Queue

O que é?

Uma fila sequencial, orientada a eventos, muito usada como:

• Log

• Interface com batch

• Comunicação com sistemas externos

Tipos de TDQ

1. Intrapartition TDQ

   • Dentro do CICS

   • Uma única partição

2. Extrapartition TDQ

   • Fora do CICS

   • Geralmente associada a um dataset sequencial

---

Características

✔ Escrita sequencial
✔ Leitura normalmente sequencial
✔ Ideal para log e integração
❌ Não permite acesso aleatório
❌ Não é feita para update

Comandos principais

EXEC CICS WRITEQ TD
EXEC CICS READQ TD

---

Exemplo prático

• Transação online grava eventos em TDQ

• Job batch lê essa TDQ depois

• Processamento assíncrono elegante, old school e eficiente

📌 Isso é o avô espiritual do streaming moderno.

---

🥊 TSQ vs TDQ – Luta no octógono

Critério	TSQ	TDQ
Tipo	Temporária	Sequencial
Acesso	Aleatório	Sequencial
Uso típico	Work area, cache	Log, interface
Performance	Muito alta	Alta
Persistência	Configurável	Depende do tipo
Risco comum	Storage leak	Fila parada

---

🛠️ Passo a passo mental (como escolher)

1️⃣ Preciso acessar dados fora de ordem? → TSQ
2️⃣ Preciso registrar eventos/logs? → TDQ
3️⃣ Comunicação com batch? → TDQ extrapartition
4️⃣ Compartilhar estado entre transações? → TSQ

---

📚 Guia de estudo para mainframers

Se você quer dominar filas no CICS, estude:

• Storage Management (MAIN vs AUX)

• CEMT I TSQUEUE / TDQUEUE

• Recovery e rollback

• CICS Logging e Journals

• Integração TSQ + MQ (sim, isso acontece)

📖 Manual-chave: CICS Application Programming Guide

---

🤓 Curiosidades de boteco mainframe

🍺 TSQ já foi usada como cache improvisado antes de DB2
🍺 TDQ era chamada de “log dos pobres” nos anos 80
🍺 Muitos sistemas críticos ainda rodam com TDQ + batch noturno
🍺 Já existiram sistemas bancários inteiros baseados em TSQ (não recomendado 😅)

---

💬 Comentário El Jefe Midnight Lunch

“Enquanto o mundo redescobre filas com nomes modernos,
o CICS continua servindo café quente, confiável e previsível
desde antes de você nascer.”

---

🚀 Aplicações modernas (sim, ainda hoje)

• Core bancário

• Sistemas de cartão

• Logs de auditoria

• Integração com MQ e APIs

• Work areas de alta performance

---

🎯 Conclusão Bellacosa

TSQ e TDQ não são relíquias.
São armas cirúrgicas, feitas para problemas específicos.

Quem sabe usar:

• Escreve código mais rápido

• Evita gargalos

• Dorme tranquilo quando o CICS sobe

🔥 CICS não é velho. Velho é quem não entende fila.