Bellacosa Mainframe dominando Datasets no CICS

💥 SEU COBOL NÃO É LEGADO — É UM MOTOR TRANSACIONAL: O GUIA DEFINITIVO DE CICS DATA SETS NO IBM z17 PARA QUEM QUER DOMINAR PRODUÇÃO

Se você trabalha com COBOL em CICS e ainda enxerga “dataset” como apenas um arquivo… você está perdendo o jogo.

No IBM z17, CICS não é só um runtime — é um orquestrador de estado, consistência e observabilidade em escala absurda.
E os CICS Data Sets são o sistema nervoso disso tudo.

Este artigo é direto ao ponto — com história, prática, pegadinhas de prova, exemplos reais e aquele nível de detalhe que só quem vive produção entende. ☕🔥

---

🧠 Antes de tudo: o que realmente são CICS Data Sets?

Não são apenas arquivos.

👉 São mecanismos especializados para:

• Garantir integridade (ACID)
• Permitir restart seguro
• Registrar tudo que importa
• Isolar falhas
• Sustentar milhões de transações

---

🏛️ Origem histórica — por que isso existe?

Nos anos 60/70, com sistemas bancários crescendo:

• Não dava pra perder dados
• Não dava pra parar sistemas
• Não dava pra “reprocessar depois”

Então o CICS nasceu com uma obsessão:

🔥 Nunca deixar o sistema inconsistente

E daí surgem:

• Logs (para desfazer)
• Dumps (para entender)
• Catálogos (para lembrar)
• Filas (para desacoplar)

👉 Tudo isso ainda vive — e no z17 roda em escala insana.

---

🧩 O ecossistema dos Data Sets (visão de arquiteto)

Pense em 4 pilares:

Pilar	Data Sets
Configuração	CSD
Execução	TS / TD
Diagnóstico	Dump / Trace / SMF
Recuperação	DFHLOG / DFHSHUNT / Catalog

---

📜 CSD — Onde o CICS “aprende a existir”

O CICS System Definition (CSD) é o DNA do sistema.

💡 O que ele guarda?

• PROGRAM
• TRANSACTION
• FILE
• TDQ
• CONNECTION
• URIMAP

---

⚙️ Passo a passo real

1. DEFINE no CSD (CEDA)
2. INSTALL no runtime
3. EXEC CICS usa o recurso

---

🧠 Easter egg de prova

👉 Alterar CSD NÃO afeta região ativa

Se você esqueceu disso em produção…
👉 já passou vergonha 😅

---

💾 System Log — O que salva sua carreira

Se você tivesse que escolher um dataset pra nunca perder:

👉 seria o DFHLOG / DFHSHUNT

---

💥 O que ele faz?

• Guarda alterações antes do commit
• Permite rollback
• Sustenta recovery
• Garante integridade

---

🧑‍💻 Exemplo real (clássico)

EXEC CICS WRITE FILE('ACCT')

Sistema cai antes do syncpoint.

👉 Log entra em ação
👉 Backout acontece
👉 Dados ficam consistentes

🔥 Magia? Não. Engenharia.

---

🧠 Frase de guerra

👉 “Sem log, não existe CICS — existe caos.”

---

📚 Global Catalog — O CICS “não esquece quem era”

Durante shutdown:

👉 O CICS salva o estado

Durante startup:

👉 Ele reconstrói o ambiente

---

💡 O que ele guarda?

• Recursos instalados
• Local do system log
• Estado operacional

---

⚠️ Pegadinha clássica

👉 NÃO guarda definições (isso é o CSD)

👉 Guarda o que estava ativo

---

🧯 Dumps — Quando tudo dá errado

🔥 Tipos

1) Transaction Dump

→ DFHDMPA / DFHDMPB

👉 erro de programa

---

2) System Dump

→ SYS1.DUMPnn

👉 erro do sistema inteiro

---

🧠 Diferença de ouro

Tipo	Uso
Transaction dump	Debug COBOL
System dump	IBM Support

---

💡 Easter egg

ASRA + dump + offset
👉 é onde nasce o dev sênior de verdade

---

📊 SMF — O “Big Brother” do CICS

Se você quer entender performance:

👉 é aqui.

---

🔥 SMF Type 110

Contém:

• Tempo de resposta
• CPU
• Waits
• Volume
• Uso de recursos

---

🧑‍💻 Caso real

Sistema lento…

SMF mostra:

👉 aumento de wait em VSAM

Problema:

👉 CI split + dataset mal definido

---

🔍 Trace — O microscópio do CICS

Tipos:

• Internal → rápido, volátil
• Auxiliary → persistente
• GTF → nível sistema

---

💣 Problema clássico

Trace enche → WRAP → perde dados

---

💾 Solução

👉 Auxiliary Trace com switching automático

---

🧠 Frase de especialista

👉 “Se não coletou o trace antes… já era.”

---

🧩 Temporary Storage (TS)

Armazena dados temporários.

---

Tipos

🔹 Main storage

• rápido
• volátil

🔹 Auxiliary

• persistente
• recuperável

---

🧑‍💻 Exemplo

• Conversational transaction
• Dados intermediários

---

📨 Transient Data (TD)

Fila sequencial.

---

🏢 Intrapartition

👉 Dentro do CICS

• workflow interno
• pode ter trigger

---

🌐 Extrapartition

👉 Fora do CICS

• arquivos
• batch
• impressão

---

🧠 Diferença chave

TS	TD
Aleatório	Sequencial
Dinâmico	Pré-definido

---

⚡ Cenário completo (vida real)

Imagine:

1️⃣ Usuário executa transação COBOL
2️⃣ Dados temporários → TS
3️⃣ Mensagens → TD
4️⃣ Atualização → LOG
5️⃣ Métricas → SMF

💥 Falha ocorre

6️⃣ Dump captura estado
7️⃣ Log executa backout
8️⃣ Catalog ajuda restart

👉 Sistema volta consistente

---

🧠 Curiosidades que poucos sabem

• DFHSHUNT = “log secundário” (nome curioso 😄)
• CICS já fazia rollback automático décadas antes de “microservices”
• Muitos bancos ainda usam VSAM + CICS como core
• TS pools podem rodar em Coupling Facility (quase memória compartilhada)
• SMF é usado até para cobrança interna em empresas

---

🏆 Mental Model definitivo

🔥 CSD → define
🔥 Catalog → lembra
🔥 Log → protege
🔥 Dump → explica
🔥 SMF → mede
🔥 TS/TD → executa

---

🧠 Frase final (nível arquiteto)

👉 CICS não processa transações — ele gerencia consistência em escala global.

---

🚀 Se você chegou até aqui…

Você não é mais só um dev COBOL.

👉 Você está pensando como sysprog + arquiteto CICS.

 

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

☕💾🔥