☕💾🔥 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.
☕💾🔥
