Bellacosa Mainframe explorando o CICS TS

💥 O SISTEMA QUE NUNCA PODE PARAR: CICS TS no IBM z17 e o Segredo das Transações que Movem o Mundo

Se você é um dev COBOL sênior e ainda escuta que seu código é “legado”… já passou da hora de virar o jogo.

Porque a verdade é outra:

💎 Você trabalha na plataforma que move bancos, governos e bilhões de transações por dia — o CICS Transaction Server rodando em IBM Z (como o z17).

Este artigo não é básico.
É uma visão de quem quer entender de verdade o coração do processamento transacional.

---

🏛️ Um pouco de história (e um choque de realidade)

CICS nasceu nos anos 60.

Sim… mais antigo que muita linguagem moderna.

Mas aqui está o plot twist:

👉 Ele nunca parou de evoluir.

Hoje o CICS:

• Fala REST/JSON
• Roda Java e Node.js
• Integra com cloud
• Expõe APIs
• Suporta milhões de usuários simultâneos

Enquanto muita tecnologia “moderna” luta para resolver problemas que o CICS resolve há décadas.

---

⚡ O que é CICS TS (sem romantizar)

💎 CICS é um Transaction Processing Monitor (TP Monitor)

Traduzindo:

👉 Um sistema que garante que operações críticas aconteçam com segurança, velocidade e consistência.

---

🧠 O papel real do CICS

Ele é responsável por:

• Executar programas (COBOL, Java, etc.)
• Gerenciar milhares de usuários simultâneos
• Controlar acesso a dados
• Garantir integridade (ACID)
• Coordenar commits e rollbacks
• Recuperar falhas automaticamente

👉 Você escreve lógica de negócio.
👉 O CICS garante que ela não quebre o mundo.

---

💳 O conceito mais importante: TRANSAÇÃO

Uma transação é:

💎 Uma unidade lógica de trabalho que deve ser executada completamente ou não executada

---

🏦 Exemplo clássico (mas real)

Transferência de R$ 1.000:

1. Debitar conta A
2. Creditar conta B

Simples? Só na superfície.

---

💥 Se algo falhar no meio?

Sem CICS:

❌ Dinheiro some
❌ Sistema inconsistente

Com CICS:

👉 Tudo é desfeito (rollback)

---

⚖️ ACID no CICS — onde o jogo fica sério

🔹 Atomicidade

Tudo ou nada.

🔹 Consistência

Regras nunca são violadas.

🔹 Isolamento

Concorrência controlada.

🔹 Durabilidade

Após commit → permanente.

---

💡 Easter egg profissional:

“CICS não garante que sua transação vai terminar.
Ele garante que seu sistema nunca ficará inconsistente.”

---

🧩 Transaction vs Task vs Unit of Work (o trio que derruba entrevistas)

🏷️ Transaction

O pedido (ex: TRANSFERIR)

🧑‍💻 Task

A execução real para um usuário

🧩 Unit of Work

O conjunto de operações que devem ser concluídas juntas

---

🧠 Forma de lembrar

👉 Transaction = intenção
👉 Task = execução
👉 UOW = integridade

---

🔄 Passo a passo de uma transação CICS

Vamos simular algo real:

💳 Compra com cartão

1️⃣ Request chega (API, terminal, app)

2️⃣ CICS cria uma TASK

3️⃣ Programa COBOL é carregado

4️⃣ Locks são aplicados

5️⃣ DB2/VSAM são acessados

6️⃣ Logs são gravados

7️⃣ Syncpoint (commit ou rollback)

8️⃣ Resposta enviada

Tudo isso em milissegundos.

---

🔒 Concorrência — onde o CICS brilha

Milhões de usuários simultâneos?

Sem problema.

---

⚡ Multitasking

👉 Várias tasks rodando ao mesmo tempo

---

🧵 Multithreading

👉 Mesmo programa sendo usado por vários usuários

---

💎 Reentrância

👉 Código único + dados isolados

Sem isso, o mainframe colapsaria.

---

💥 Deadlock — quando o sistema entra em “briga”

🧠 Cenário clássico

Transação A segura recurso X e quer Y
Transação B segura Y e quer X

👉 Impasse total

---

🧯 Solução do CICS

• Detecta o deadlock
• Cancela uma transação
• Libera recursos
• Preserva integridade

---

💡 Curiosidade:

Deadlock não é erro — é efeito natural da concorrência.

---

🏗️ CICS como “SO dentro do SO”

Você não chama o z/OS diretamente.

Você chama o CICS:

EXEC CICS READ FILE(...)
EXEC CICS WRITEQ TS(...)
EXEC CICS LINK PROGRAM(...)

👉 O CICS fala com o sistema por você.

---

🌐 CICS moderno — muito além do 3270

Se você ainda pensa em tela verde, está atrasado.

Hoje o CICS:

• Expõe APIs REST via z/OS Connect
• Roda Java (Liberty JVM)
• Executa Node.js
• Integra com cloud
• Participa de arquiteturas híbridas

---

📱 Exemplo real moderno

App mobile → API → z/OS Connect → CICS → DB2

Usuário nem imagina que existe um mainframe ali.

---

☁️ Cloud + CICS

Sim, isso existe.

CICS hoje suporta:

• Bundles de aplicação
• Deploy automatizado
• Políticas de recursos
• CICSPlex para escala

👉 Conceitos de cloud dentro do mainframe.

---

🧠 Curiosidades que poucos sabem

💡 CICS pode processar milhões de transações por segundo
💡 Muitos bancos nunca desligam CICS (uptime absurdo)
💡 Grande parte das transações financeiras globais passam por CICS
💡 Node.js roda dentro do CICS (sim, JavaScript no mainframe 😄)
💡 Seu COBOL pode virar API REST sem reescrever nada

---

🔥 Insight final (nível arquiteto)

💎 CICS não é legado — é infraestrutura invisível da economia mundial

Ele resolve problemas que arquiteturas modernas ainda tentam resolver:

• Consistência forte
• Alta concorrência
• Recuperação automática
• Baixa latência
• Escala absurda

---

🚀 Conclusão — para dev COBOL sênior

Se você domina CICS:

👉 Você não é “dev legado”
👉 Você é especialista em sistemas de missão crítica

🔥☕ O MAINFRAME JÁ ERA CLOUD ANTES DA CLOUD EXISTIR 💾🏛️🌐

 

Bellacosa Mainframe apresenta o CICS Structure Intercomunication

🔥☕ O MAINFRAME JÁ ERA CLOUD ANTES DA CLOUD EXISTIR — A VERDADE QUE TODO SYSprog JUNIOR DESCOBRE QUANDO ENTENDE CICS STRUCTURE & INTERCOMMUNICATION 💾🏛️🌐

---

Durante anos, muita gente ouviu frases como:

• “Mainframe é centralizado”

• “CICS é legado”

• “IBM Z é tecnologia antiga”

• “Cloud substituiu o mainframe”

E então o padawan começa a estudar:

🔥 CICS Structure and Intercommunication.

Nesse momento acontece algo curioso.

Ele percebe:

💣 o IBM CICS já fazia computação distribuída enterprise MUITO antes da internet moderna, dos microsserviços, do Kubernetes e da cloud híbrida virarem moda.

E isso muda completamente sua visão sobre o mundo IBM Z.

---

☕ O ERRO CLÁSSICO DE QUEM ESTÁ COMEÇANDO

O iniciante normalmente imagina o CICS assim:

Usuário → COBOL → VSAM

Algo simples.
Linear.
Monolítico.

Mas o ambiente enterprise real é mais próximo disso:

Usuário
   ↓
TOR
   ↓
MRO / IRC
   ↓
AORs distribuídos
   ↓
Db2 / MQ / VSAM
   ↓
CICSPlex
   ↓
Sysplex
   ↓
Recovery / Routing / Balancing

E nesse instante o sysprog junior percebe:

🔥 o CICS é um ecossistema distribuído monstruosamente sofisticado.

---

🏛️ O CICS NÃO É “UM PROGRAMA”

Esse é o primeiro choque.

O CICS moderno:

💣 não é uma única região.

Ele pode possuir:

• dezenas de regiões

• múltiplos hosts

• múltiplas LPARs

• workloads distribuídos

• failover automático

• roteamento dinâmico

Tudo funcionando:

⚡ simultaneamente.

---

☕ O QUE É UMA REGIÃO CICS?

Uma região CICS:

🔥 é um address space do z/OS.

Ou seja:

• possui memória própria

• tasks próprias

• recursos próprios

• controle próprio

E roda:

💾 como Started Task ou Batch Job.

---

☕ O SYSprog JUNIOR DESCOBRE UMA VERDADE IMPORTANTE

O CICS:

❌ não é o sistema operacional.

Ele roda:

🏛️ SOBRE o z/OS.

Assim como:

• Db2

• MQ

• JES2

• VTAM

• TCP/IP

---

💾 O CICS É “APENAS” MAIS UM WORKLOAD DO z/OS

Só que esse “workload”:

💣 movimenta o planeta financeiro.

---

🔥 TOR, AOR E FOR — A SEPARAÇÃO QUE MUDOU TUDO

Aqui começa a engenharia enterprise de verdade.

---

☕ TOR — TERMINAL OWNING REGION

Responsável por:

• receber conexões

• controlar sessões

• entrada de usuários

• roteamento

O TOR funciona como:

🚦 controlador de tráfego.

---

☕ AOR — APPLICATION OWNING REGION

Aqui mora:

• COBOL

• regras de negócio

• Db2

• MQ

• VSAM

O AOR:

⚡ executa o trabalho pesado.

---

☕ FOR — FILE OWNING REGION

Especializada em:

• VSAM

• locking

• controle de arquivos

• integridade

---

💣 ISSO É GENIAL

Porque:

• workload pode ser distribuído

• funções podem ser separadas

• gargalos podem ser evitados

• escalabilidade aumenta absurdamente

---

🌐 MRO — O “SERVICE MESH INVISÍVEL” DO CICS

Quando o padawan aprende MRO:

🔥 sua mente explode.

---

☕ O QUE É MRO?

🌐 Multiregion Operation

Permite:

• comunicação entre regiões CICS

• dentro do mesmo z/OS

• ou dentro do mesmo Sysplex

---

💾 O MAIS IMPRESSIONANTE

O MRO usa:

⚡ IRC — Interregion Communication.

---

☕ O IRC É A JOIA ESCONDIDA DO CICS

Porque:

• comunicação é interna

• não precisa TCP/IP

• não precisa SNA

• não precisa VTAM

---

💣 RESULTADO?

✅ baixa latência

✅ throughput monstruoso

✅ comunicação ultra rápida

✅ escalabilidade massiva

---

☕ O MRO É BASICAMENTE:

🔥 um “service bus interno” criado décadas antes da cloud moderna.

---

🌎 ISC — QUANDO O CICS APRENDEU A FALAR COM O MUNDO

Depois vem:

🌐 ISC — Intersystem Communication.

---

☕ O ISC CONECTA:

• hosts diferentes

• sistemas remotos

• datacenters

• ambientes distribuídos

Usando:

🔥 SNA / APPC / LU6.2

---

💾 ISSO ERA A “INTERNET IBM”

Muito antes:

• APIs REST

• HTTP moderno

• cloud hybrid

---

☕ O ISC PERMITIU:

✅ ATMs nacionais

✅ agências distribuídas

✅ bancos globais

✅ processamento remoto

✅ integração CICS ↔ IMS

---

💣 COMPUTAÇÃO DISTRIBUÍDA REAL

Nos anos 80 e 90.
Quando muita gente ainda nem entendia redes corporativas direito.

---

🌐 IPIC — O CICS ENTRA NA ERA TCP/IP

O mundo mudou.
O TCP/IP venceu.
E o CICS evoluiu.

Nasce:

🔥 IPIC — IP Interconnectivity.

---

☕ AGORA O CICS CONVERSA VIA:

✅ TCP/IP

✅ APIs

✅ Linux

✅ OpenShift

✅ cloud

✅ microsserviços

---

💾 O CICS NÃO MORREU

Ele:

⚡ se modernizou.

---

🌉 CICS TRANSACTION GATEWAY — A PONTE ENTRE O PASSADO E O FUTURO

Agora entra:

🔥 CTG — CICS Transaction Gateway.

---

☕ O CTG É O “TRADUTOR”

Entre:

• Java

• .NET

• aplicações web

• APIs REST

e:

💾 o mundo CICS/COBOL.

---

☕ FLUXO MODERNO REAL

App Mobile
   ↓
API REST
   ↓
Java Spring
   ↓
CTG
   ↓
CICS
   ↓
COBOL
   ↓
Db2

---

💣 O USUÁRIO NÃO FAZ IDEIA

Que:

• um COBOL de décadas atrás

• respondeu sua operação bancária em milissegundos.

---

🏛️ CICSPLEX — O “KUBERNETES” QUE EXISTIA ANTES DO KUBERNETES

Quando o ambiente cresce absurdamente:

• dezenas de regiões

• múltiplos hosts

• milhões de transações

entra:

🌐 CICSPlex.

---

☕ O CICSPLEX TRANSFORMA:

Múltiplos CICS:

⚡ em um único ambiente lógico.

---

💾 O CPSM FAZ:

✅ workload balancing

✅ failover

✅ gerenciamento centralizado

✅ roteamento dinâmico

✅ monitoramento

---

💣 ISSO É ORQUESTRAÇÃO ENTERPRISE

Muito antes:

• Kubernetes

• OpenShift

• cloud orchestration

---

☕ O SYSprog JUNIOR COMEÇA A ENTENDER

Que o IBM Z:

❌ nunca foi “parado no tempo”.

Na verdade:

🔥 ele estava anos à frente.

---

🌐 O CICS JÁ FAZIA:

✅ clusterização

✅ workload balancing

✅ comunicação distribuída

✅ middleware enterprise

✅ failover automático

✅ integração híbrida

✅ service orchestration

✅ APIs corporativas

Décadas antes:

• da cloud moderna

• dos microsserviços

• do service mesh

• do Kubernetes

---

💾 O GRANDE SEGREDO DO MAINFRAME

O mundo moderno reinventou conceitos que:

🏛️ o IBM Z já dominava há décadas.

---

☕ ENQUANTO MUITOS SISTEMAS MODERNOS:

• quebram facilmente

• perdem consistência

• sofrem downtime

• escalam mal

O CICS continua:

⚡ processando bilhões de transações silenciosamente.

---

💣 O PADAWAN FINALMENTE ENTENDE

O CICS:

❌ não é apenas EXEC CICS SEND MAP.

Ele é:

🌐 uma plataforma transacional distribuída de missão crítica.

---

🏛️ CONCLUSÃO BELLACOSA MAINFRAME™

Quando um sysprog junior realmente entende:

• MRO

• IRC

• ISC

• IPIC

• CTG

• CICSPlex

• regiões CICS

ele percebe algo impressionante:

🔥 o mainframe nunca ficou para trás.

Na verdade:

💾 o restante da indústria passou décadas tentando reinventar conceitos que o IBM Z já utilizava silenciosamente desde muito antes da explosão da computação cloud moderna.

 

Bellacosa Mainframe e a migraçao que falhou

☕🔥 “A MODERNIZAÇÃO QUE DERRETEU US$ 170 MILHÕES”:

O DIA EM QUE A BOLSA DA AUSTRÁLIA DESCOBRIU QUE SUBSTITUIR MAINFRAME NÃO É BRINCADEIRA

Existe uma narrativa quase religiosa no mercado de tecnologia:

“Legacy é ruim. Mainframe é antigo. Blockchain resolve. Microserviços escalam tudo.”

A Australian Securities Exchange (ASX) resolveu apostar exatamente nisso.

E o resultado virou um dos maiores desastres modernos de migração de sistemas críticos financeiros.

---

📅 O CASO ASX — A LINHA DO TEMPO DO FRACASSO

2016 — O anúncio revolucionário

A ASX anunciou ao mercado que substituiria o CHESS:

• sistema de clearing e liquidação da bolsa australiana

• construído nos anos 1990

• baseado em COBOL e mainframe

• altamente estável

• crítico para o mercado financeiro australiano

pela “nova geração”:

✅ Blockchain
✅ Distributed Ledger Technology (DLT)
✅ arquitetura moderna
✅ liquidação mais rápida
✅ redução de custos
✅ transparência distribuída

Na época, o mercado aplaudiu.

A imprensa chamou de:

“a primeira bolsa do mundo movida por blockchain”.

---

🏛 O QUE ERA O CHESS?

O CHESS não era “só um sistema antigo”.

Era literalmente o coração operacional da bolsa australiana.

Ele:

• controlava custódia

• liquidação financeira

• ownership de ativos

• sincronização entre participantes

• integridade transacional do mercado

E fazia isso com:

• ~2,5 milhões de transações/dia

• capacidade de pico acima de 10 milhões

• disponibilidade de 99,95%

• consistência transacional rígida

Tudo em mainframe.

---

⚠ O ERRO CONCEITUAL QUE MUITA GENTE NÃO ENTENDE

Muitos executivos olham para um sistema COBOL e enxergam:

“software velho”.

Mas sistemas financeiros antigos são frequentemente:

✅ extremamente otimizados
✅ previsíveis
✅ resilientes
✅ deterministicamente consistentes
✅ refinados por décadas de incidentes reais

Cada regra esquisita do sistema normalmente existe porque:

algum desastre já aconteceu antes.

Sistemas financeiros são cemitérios de exceções históricas.

---

🚨 2018 — O PRIMEIRO SINAL DE DESASTRE

O go-live estava planejado para 2018.

Mas começaram os adiamentos.

Depois vieram:

• problemas de performance

• problemas de sincronização

• dificuldades de escalabilidade

• inconsistência operacional

• dúvidas sobre throughput

• dúvidas sobre latência

E isso é importante:

Blockchain funciona MUITO melhor em cenários onde:

• confiança é distribuída

• latência não é crítica

• consistência eventual é aceitável

Mercado financeiro NÃO aceita isso.

---

💥 O GRANDE PROBLEMA: CONSISTÊNCIA FORTE SOB ALTÍSSIMA CONCORRÊNCIA

O inferno começou aqui.

Em bolsa de valores:

• uma transação não pode “talvez acontecer”

• um ativo não pode aparecer duplicado

• uma liquidação não pode entrar em eventual consistency

• não existe “vamos sincronizar depois”

O sistema precisa garantir propriedades ACID:

ACID = {Atomicidade,\ Consist\hat{e}ncia,\ Isolamento,\ Durabilidade}

E garantir isso em arquitetura distribuída é brutalmente difícil.

---

⚡ O PROBLEMA QUE POWERPOINT NÃO MOSTRA: LATÊNCIA

Arquiteturas distribuídas introduzem:

• comunicação entre nós

• consenso

• replicação

• sincronização

• validação distribuída

Tudo isso adiciona:

VARIABILIDADE

E mercado financeiro odeia variabilidade.

Porque:

• microssegundos importam

• previsibilidade importa

• jitter importa

• filas importam

• lock contention importa

Mainframes foram literalmente desenhados para esse cenário.

---

📉 2022 — A AUDITORIA DA ACCENTURE

A situação ficou tão crítica que a ASX chamou a Accenture para revisar o projeto.

O relatório foi devastador.

Problemas encontrados:

🔴 Deficiências graves de design

🔴 Complexidade operacional subestimada

🔴 Riscos de escalabilidade

🔴 Falhas de governança

🔴 Cronogramas irreais

🔴 Problemas de engenharia estrutural

Pouco depois:

💣 Novembro de 2022 — PROJETO CANCELADO

Após quase 7 anos:

✅ cancelamento total
✅ prejuízo de ~240–255 milhões AUD
✅ perda de credibilidade
✅ impacto regulatório
✅ desgaste institucional gigantesco

---

⚖ 2024 — O ESCÂNDALO REGULATÓRIO

A situação piorou.

A ASIC (regulador australiano) processou a ASX alegando:

• comunicação enganosa ao mercado

• relatórios excessivamente otimistas

• ocultação do verdadeiro estado do projeto

Isso é gravíssimo em mercado financeiro.

Porque investidores tomam decisões baseadas nessas comunicações.

---

🧠 A LIÇÃO MAIS IMPORTANTE

O fracasso NÃO significa:

❌ “Blockchain é inútil”
❌ “Tecnologia moderna não presta”
❌ “Mainframe vence tudo”

A lição real é muito mais profunda:

Sistemas críticos têm propriedades invisíveis.

E essas propriedades:

• não aparecem no backlog Agile

• não aparecem no PowerPoint

• não aparecem no pitch de consultoria

Mas aparecem violentamente em produção.

---

☠ OUTROS CASOS FAMOSOS DE MIGRAÇÃO QUE FALHARAM REDONDAMENTE

---

🇬🇧 TSB Bank (Reino Unido) — 2018

“O banco migrou… e os clientes perderam acesso às contas”

O TSB tentou migrar da plataforma Lloyds para uma nova infraestrutura.

Resultado:

• milhões de clientes sem acesso

• contas erradas

• saldos inconsistentes

• pagamentos falhando

• caos operacional

Impacto estimado:

💸 mais de £330 milhões em prejuízos.

O CEO acabou renunciando.

---

🇺🇸 Knight Capital — 2012

“45 minutos quase destruíram a empresa”

Não foi exatamente migração completa, mas atualização de sistema crítico.

Erro de deploy:

• algoritmo antigo ativado por acidente

• ordens disparadas descontroladamente

Resultado:

💥 US$ 440 milhões perdidos em 45 minutos.

A empresa praticamente morreu.

---

🇺🇸 Healthcare.gov — 2013

“O portal de saúde dos EUA colapsou no lançamento”

Problemas:

• integração entre fornecedores

• arquitetura complexa

• testes insuficientes

• escalabilidade ruim

O sistema entrou em colapso quase imediato.

---

🇬🇧 British Airways — 2017

“Uma falha derrubou operações globais”

Falha durante mudança operacional/data center.

Resultado:

• voos cancelados

• caos mundial

• sistemas indisponíveis

• prejuízo enorme

Muitos especialistas apontaram que simplificações excessivas na arquitetura contribuíram para o desastre.

---

🇩🇪 Deutsche Bank — tentativas de modernização

O Deutsche Bank passou anos tentando reduzir dependência de sistemas legados.

O problema?

Décadas de fusões criaram um “Frankenstein bancário”.

Em vários momentos, executivos admitiram que:

• ninguém entendia totalmente o ecossistema

• existiam dependências invisíveis

• havia lógica de negócio enterrada no legado

---

☕ O QUE O MUNDO ENTERPRISE APRENDEU (E REAPRENDE TODO ANO)

Mainframe não sobreviveu por nostalgia.

Ele sobreviveu porque:

• downtime custa bilhões

• inconsistência destrói mercados

• throughput real é difícil

• previsibilidade vale ouro

---

🏛 O PARADOXO DO MAINFRAME

Quanto menos você ouve falar do sistema…

maior a chance de ele estar funcionando perfeitamente.

Porque sistemas realmente críticos:

• não podem viralizar

• não podem falhar bonito

• não podem “iterar em produção”

Eles simplesmente precisam funcionar.

Todos os dias.

Por décadas.

---

🔥 A VERDADE QUE MUITA CONSULTORIA EVITA DIZER

Migrar sistema crítico não é:

✅ “reescrever código”

É:

• migrar comportamento emergente

• migrar décadas de exceções

• migrar semântica operacional

• migrar timing implícito

• migrar cultura

• migrar conhecimento tribal

• migrar integrações invisíveis

E muitas vezes…

ninguém mais entende completamente tudo isso.

---

☕ A CONCLUSÃO MAIS INCÔMODA

Talvez a pergunta correta não seja:

“Por que ainda usam COBOL?”

Mas sim:

“Por que sistemas escritos há 40 anos continuam mais confiáveis do que muitas arquiteturas modernas?”

 

 

☕🔥 EIBRESP no CICS — O “DNA” dos Erros e Respostas do Mainframe

No universo CICS, existe uma verdade absoluta:

“Se você não trata RESP e RESP2… o CICS tratará você.”

O campo EIBRESP é um dos mecanismos mais importantes do ambiente transacional IBM Mainframe.

Ele informa:

• se o comando executou corretamente

• qual erro ocorreu

• qual condição excepcional aconteceu

• se houve problema de terminal

• erro de VSAM

• problema de comunicação

• rollback

• timeout

• lock

• storage

• autorização

• spool

• task

• map

• TSQ

• TDQ

• intersystem

• e dezenas de outros cenários

---

☕ O que é EIBRESP?

O EIBRESP pertence ao:

EXEC CICS HANDLE CONDITION

e principalmente ao:

RESP()
RESP2()

Exemplo clássico:

EXEC CICS READ
     FILE('CLIENTE')
     INTO(WS-REGISTRO)
     RIDFLD(WS-CHAVE)
     RESP(WS-RESP)
     RESP2(WS-RESP2)
END-EXEC

Após o comando:

• WS-RESP recebe o código principal

• WS-RESP2 traz detalhes adicionais

---

☕ Por que isso é tão importante?

Porque no CICS:

Nem todo erro gera ABEND.

Na verdade:

• a maioria dos problemas retorna EIBRESP

• e o programa CONTINUA

Ou seja:

se você não tratar…

o sistema segue em frente silenciosamente.

Isso é perigosíssimo.

---

☕ Exemplo clássico de desastre

Imagine:

EXEC CICS READ FILE('CLIENTE')
END-EXEC

Registro não existe.

O CICS retorna:

RESP = 13 (NOTFND)

Mas o programador ignorou.

Resultado:

• dados inválidos

• tela lixo

• cálculos incorretos

• SQL errado

• corrupção lógica

Sem abend.
Sem dump.
Sem aviso.

O erro fica “fantasma”.

---

☕ Arquitetura Interna do EIB

O EIB é:

EXEC Interface Block

Área automática criada pelo CICS para cada task.

Contém:

• EIBRESP

• EIBRESP2

• EIBTRNID

• EIBTASKN

• EIBTIME

• EIBDATE

• EIBAID

• EIBCALEN

• EIBFN

• etc.

É literalmente o “contexto vivo” da transação.

---

☕ O fluxo REAL do CICS

Internamente:

Programa envia comando EXEC CICS
↓
Translator converte para CALL DFHEI1
↓
Kernel EXEC Interface processa
↓
Resource Manager executa
↓
Retorno é gravado em EIBRESP
↓
Programa decide o que fazer

Ou seja:

EIBRESP é praticamente o “status code” do kernel CICS.

---

☕ As categorias dos EIBRESP

Os códigos podem ser agrupados em:

Categoria	Exemplos
Arquivo VSAM	NOTFND, DUPKEY, ENDFILE
Comunicação	TERMERR, SYSIDERR
Storage	NOSTG
Segurança	NOTAUTH
Queue	QZERO, QBUSY
MAP/BMS	MAPFAIL
Programas	PGMIDERR
Transações	TRANSIDERR
Syncpoint	ROLLEDBACK
InterSystem	ISCINVREQ

---

☕ Os códigos MAIS IMPORTANTES do mundo real

---

🔥 01 — ERROR

Erro genérico.

Normalmente significa:

• comando falhou

• condição inesperada

• sem tratamento específico

Exemplo:

IF WS-RESP = DFHRESP(ERROR)

Curiosidade:

Muitos dumps antigos de CICS começam aqui.

---

🔥 13 — NOTFND

O mais famoso de todos.

Registro não encontrado.

Exemplo:

EXEC CICS READ
     FILE('CLIENTE')
     RIDFLD(WS-ID)
     RESP(WS-RESP)
END-EXEC

Se chave não existir:

RESP = 13

---

☕ Analogia real

É o equivalente mainframe de:

SELECT * FROM TABELA
WHERE ID=999

Sem linhas retornadas.

---

☕ Dica profissional

TODO READ deveria tratar:

EVALUATE WS-RESP
   WHEN DFHRESP(NORMAL)
      CONTINUE

   WHEN DFHRESP(NOTFND)
      MOVE 'N' TO WS-EXISTE

   WHEN OTHER
      PERFORM 9000-ERRO
END-EVALUATE

---

🔥 14 — DUPREC

Registro duplicado.

Muito comum em ESDS/RRDS.

---

🔥 15 — DUPKEY

Chave duplicada no KSDS.

Clássico de cadastro.

Exemplo:

EXEC CICS WRITE
     FILE('CLIENTE')

Tentou inserir chave já existente.

---

☕ Curiosidade

Em muitos bancos:

• o COBOL captura DUPKEY

• e transforma em mensagem amigável:

CLIENTE JÁ CADASTRADO

Sem o usuário perceber que foi um erro VSAM.

---

🔥 16 — INVREQ

“Invalid Request”.

Talvez o erro MAIS traiçoeiro do CICS.

Significa:

“Você pediu algo inválido para ESTE contexto.”

Exemplos:

• READ sem arquivo aberto

• START inválido

• LINK incorreto

• COMMAREA errada

• comando proibido

---

☕ Easter Egg técnico

Grande parte dos:

AEI*

internamente começa com INVREQ.

---

🔥 17 — IOERR

Erro físico/lógico de I/O.

Pode indicar:

• VSAM corrompido

• CI quebrado

• erro disco

• problema buffer

• catálogo inconsistente

Quando aparece:

⚠️ operadores começam a ficar nervosos.

---

🔥 18 — NOSPACE

Sem espaço.

Pode ocorrer em:

• TSQ

• TDQ

• datasets

• spool

• buffers

Muito comum em ambientes mal dimensionados.

---

🔥 22 — LENGERR

Erro de tamanho.

Lenda absoluta do CICS.

Exemplo clássico:

EXEC CICS RECEIVE
     MAP('TELA1')
     INTO(WS-AREA-100)
END-EXEC

Mas o mapa possui 120 bytes.

Boom:

LENGERR

---

☕ O terror do COBOL antigo

Copys desatualizadas.

O mapa mudou.
O programa não recompilou.

Resultado:

RESP=22

---

🔥 25 — QBUSY

Queue ocupada.

Muito comum em concorrência pesada.

---

🔥 27 — PGMIDERR

Programa não encontrado.

Causas:

• PPT errado

• programa não instalado

• nome incorreto

• loadlib ausente

Exemplo:

EXEC CICS LINK
     PROGRAM('PGMXYZ')

Se não existir:

PGMIDERR

---

☕ Curiosidade histórica

Nos anos 80:

PGMIDERR era um dos erros mais comuns em produção noturna.

Especialmente após promotes manuais.

---

🔥 28 — TRANSIDERR

Transação inexistente.

Exemplo:

EXEC CICS START
     TRANSID('ABCD')

Se não existir no PCT:

TRANSIDERR

---

🔥 29 — ENDDATA

Fim de dados.

Muito comum em:

• TSQ

• TDQ

• browse

Equivalente ao EOF lógico.

---

🔥 36 — MAPFAIL

Talvez o mais famoso do BMS.

Ocorre quando:

• usuário pressionou ENTER sem dados

• MDT desligado

• campo vazio

• RECEIVE não trouxe informação

---

☕ Exemplo REAL

Usuário entra na tela:

CPF: ________

Pressiona ENTER vazio.

CICS:

MAPFAIL

---

☕ Dica profissional importantíssima

Nunca trate MAPFAIL como erro fatal.

É fluxo normal de tela.

---

🔥 40 — OVERFLOW

Overflow de armazenamento/dados.

Pode ocorrer em:

• TSQ

• COMMAREA

• buffers

---

🔥 42 — NOSTG

Sem storage.

Extremamente sério.

O CICS está sem memória suficiente.

Operações podem começar a degradar rapidamente.

---

☕ Bastidores

Quando NOSTG aparece em sequência:

• SOS condition

• short-on-storage

• risco de região cair

É situação crítica.

---

🔥 44 — QIDERR

Queue inexistente.

Muito comum em TSQ/TDQ.

---

🔥 53 — SYSIDERR

Erro de sistema remoto.

Clássico em:

• MRO

• ISC

• IPIC

• APPC

O sistema remoto:

• caiu

• não respondeu

• não existe

• sessão falhou

---

🔥 70 — NOTAUTH

Falha de autorização.

O RACF disse:

NO.

---

☕ Integração CICS + RACF

Aqui ocorre:

• verificação de transação

• FILE

• TDQ

• TSQ

• PROGRAM

• SURROGAT

• resources

---

🔥 73 — WRONGSTAT

Estado inválido.

Muito comum em sessões/APPC.

---

🔥 76 — CCERROR

Erro de controle de comunicação.

---

🔥 77 — MAPERROR

Erro estrutural de mapa.

Diferente de MAPFAIL.

MAPERROR normalmente significa:

• definição inconsistente

• estrutura inválida

• problema BMS

---

🔥 80 — NOSPOOL

Sem spool.

Muito comum em ambientes JES saturados.

---

🔥 81 — TERMERR

Erro terminal/dispositivo.

Pode indicar:

• sessão caiu

• VTAM problemático

• LU desconectada

• timeout terminal

---

🔥 82 — ROLLEDBACK

Rollback executado.

Um dos mais importantes do mundo transacional.

Significa:

SUAS ALTERAÇÕES FORAM DESFEITAS

---

☕ Cenário clássico

UPDATE CONTA A
UPDATE CONTA B
ERRO NO FINAL
SYNCPOINT ROLLBACK

CICS:

ROLLEDBACK

---

🔥 84 — DISABLED

Recurso desabilitado.

Pode ser:

• FILE

• TRANSACTION

• TERMINAL

• PROGRAM

• CONNECTION

---

☕ A diferença entre RESP e RESP2

RESP:

erro genérico

RESP2:

detalhamento interno

Exemplo:

RESP  = INVREQ
RESP2 = 8

Cada RESP2 possui significado específico.

É aí que mora o troubleshooting avançado.

---

☕ Exemplo profissional completo

EXEC CICS READ
     FILE('CLIENTE')
     RIDFLD(WS-CHAVE)
     INTO(WS-REG)
     RESP(WS-RESP)
     RESP2(WS-RESP2)
END-EXEC

EVALUATE WS-RESP

   WHEN DFHRESP(NORMAL)
      CONTINUE

   WHEN DFHRESP(NOTFND)
      MOVE 'CLIENTE INEXISTENTE'
        TO WS-MSG

   WHEN DFHRESP(NOTAUTH)
      MOVE 'SEM AUTORIZACAO'
        TO WS-MSG

   WHEN OTHER
      DISPLAY 'RESP=' WS-RESP
      DISPLAY 'RESP2=' WS-RESP2
      PERFORM 9999-ABEND

END-EVALUATE

---

☕ Dica de arquiteto CICS

Os melhores sistemas enterprise:

✅ tratam TODOS os RESP
✅ logam RESP2
✅ possuem tabelas de tradução
✅ transformam erro técnico em mensagem funcional
✅ evitam abends desnecessários

---

☕ Curiosidade histórica

Antes do uso massivo de:

RESP()

muitos programas dependiam de:

HANDLE CONDITION

Isso tornava o fluxo:

• difícil de rastrear

• cheio de GO TO

• quase impossível de debugar

RESP revolucionou o tratamento moderno.

---

☕ Easter Egg Mainframe

Veteranos conseguem identificar problemas olhando apenas:

AEI9
AEY9
ASRA
MAPFAIL
INVREQ
PGMIDERR

É quase uma linguagem secreta do CICS.

---

☕ Regra de ouro do CICS

“O comando EXEC CICS nunca deve ser confiado cegamente.”

Sempre:

• RESP

• RESP2

• HANDLE CONDITION

• HANDLE ABEND

Porque no mundo transacional:

o programa pode continuar funcionando…

mesmo completamente errado.