Translate

Mostrar mensagens com a etiqueta processamento transacional. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta processamento transacional. Mostrar todas as mensagens

domingo, 7 de dezembro de 2025

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

 

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

terça-feira, 7 de outubro de 2025

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

sexta-feira, 31 de maio de 2024

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

 

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?”


 

sexta-feira, 16 de agosto de 2013

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

 



☕🔥 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:

CategoriaExemplos
Arquivo VSAMNOTFND, DUPKEY, ENDFILE
ComunicaçãoTERMERR, SYSIDERR
StorageNOSTG
SegurançaNOTAUTH
QueueQZERO, QBUSY
MAP/BMSMAPFAIL
ProgramasPGMIDERR
TransaçõesTRANSIDERR
SyncpointROLLEDBACK
InterSystemISCINVREQ

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

segunda-feira, 19 de fevereiro de 2007

O que é Database IMS em Mainframe?

 

Bellacosa Mainframe o que é database IMS

O que é IMS em Mainframe?

IMS significa:

Information Management System

É um dos softwares mais importantes da história da IBM e um dos pilares do ambiente Mainframe.

Criado em 1968 para apoiar o programa Apollo da NASA, o IMS continua em produção em milhares de empresas ao redor do mundo.


Definição Simples

O IMS é uma plataforma que fornece:

✅ Banco de Dados (IMS DB)

✅ Processamento de Transações (IMS TM)

Em outras palavras:

IMS = Banco de Dados + Monitor Transacional

História Curiosa

A IBM desenvolveu o IMS para ajudar a NASA a controlar milhões de componentes do foguete Saturno V usado nas missões Apollo.

Por isso, o IMS é frequentemente chamado de:

O banco de dados que ajudou a levar o homem à Lua


Componentes Principais

IMS DB

Banco de dados hierárquico.


IMS TM

Transaction Manager.

Responsável pelo processamento online.


Arquitetura Simplificada

Usuário
    ↓
IMS TM
    ↓
Programa COBOL
    ↓
IMS DB
    ↓
Resposta

O que é IMS DB?

É um banco de dados hierárquico.

Diferente do DB2, que é relacional.


Exemplo DB2

Tabela CLIENTES

IDNOME
1JOÃO
2MARIA

Exemplo IMS

EMPRESA
   │
   ├── CLIENTE
   │      │
   │      ├── CONTA
   │      │      │
   │      │      ├── MOVIMENTO
   │      │      ├── MOVIMENTO
   │
   └── CLIENTE

Conceito de Segmento

No IMS os registros são chamados de:

Segmentos


Exemplo

CLIENTE

Segmento Pai


CONTA

Segmento Filho


MOVIMENTO

Segmento Neto


Estrutura Hierárquica

CLIENTE
   ↓
CONTA
   ↓
MOVIMENTO

O que é DL/I?

Data Language I.

É a linguagem utilizada para acessar bancos IMS.

Equivale ao SQL do DB2.


Comandos DL/I

GU

Get Unique

Busca um segmento específico.


GN

Get Next

Busca próximo segmento.


GNP

Get Next Within Parent

Busca próximo filho.


ISRT

Insert

Inclui segmento.


REPL

Replace

Atualiza segmento.


DLET

Delete

Remove segmento.


Exemplo DL/I

CALL 'CBLTDLI'

USING
      GU
      PCB
      AREA
      SSA.

O que é PCB?

Program Communication Block.

Define como o programa acessa o banco.


O que é PSB?

Program Specification Block.

Define:

  • bancos acessados;

  • permissões;

  • PCBs.


O que é DBD?

Database Description.

Descreve:

  • segmentos;

  • relacionamentos;

  • estrutura física.


Estrutura IMS DB

DBD
 ↓
PSB
 ↓
PCB
 ↓
Programa COBOL

O que é IMS TM?

Transaction Manager.

Funciona de forma semelhante ao CICS.


Responsabilidades

  • receber transações;

  • controlar usuários;

  • chamar programas;

  • gerenciar filas;

  • garantir integridade.


Fluxo Online

Terminal
   ↓
IMS TM
   ↓
Programa COBOL
   ↓
IMS DB
   ↓
Resposta

Exemplo de Transação

Usuário digita:

CONS

IMS executa:

CONS
  ↓
Programa COBOL
  ↓
Consulta IMS
  ↓
Resposta

IMS x CICS

IMS TMCICS
IBMIBM
TransacionalTransacional
Muito usado em bancosMuito usado em bancos
Integração IMS DBIntegração DB2
Altíssimo desempenhoAltíssimo desempenho

IMS x DB2

IMS

Hierárquico

CLIENTE
 ↓
CONTA
 ↓
MOVIMENTO

DB2

Relacional

CLIENTES
CONTAS
MOVIMENTOS

Relacionadas por chaves.


Linguagens Utilizadas

  • COBOL

  • PL/I

  • Assembler

  • Java


IMS e COBOL

Combinação clássica.


Exemplo

CALL 'CBLTDLI'

Praticamente todo programa IMS utiliza esse comando.


Vantagens do IMS

✅ Altíssima performance

✅ Excelente escalabilidade

✅ Segurança

✅ Baixo consumo de recursos

✅ Confiabilidade extrema


Onde é Utilizado?

  • Bancos

  • Cartões

  • Seguradoras

  • Governo

  • Telecomunicações

  • Companhias aéreas


Curiosidades

1. O IMS foi criado para o Projeto Apollo

2. Continua sendo utilizado mais de 50 anos depois

3. Alguns dos maiores bancos do mundo usam IMS

4. Processa bilhões de transações diariamente

5. É considerado um dos sistemas mais confiáveis já criados


Principais Objetos IMS

ObjetoFunção
DBDDescrição do Banco
PSBEspecificação Programa
PCBComunicação Programa
SegmentoRegistro IMS
SSACritério Pesquisa
DL/ILinguagem de acesso
IMS DBBanco Hierárquico
IMS TMGerenciador Transacional

Resumo Rápido

IMS
 │
 ├── IMS DB
 │      ↓
 │ Banco Hierárquico
 │
 └── IMS TM
        ↓
     Transações Online

Conclusão

O IMS (Information Management System) é uma plataforma da IBM composta por um poderoso banco de dados hierárquico (IMS DB) e um monitor transacional (IMS TM). Presente em grandes bancos, seguradoras e órgãos governamentais, ele continua sendo uma das tecnologias mais robustas e confiáveis do ecossistema Mainframe IBM Z, processando milhões de transações críticas todos os dias.


terça-feira, 13 de fevereiro de 2007

O que é DB2 Mainframe?

 

Bellacosa Mainframe  o que é DB2 Mainframe

O que é DB2 Mainframe?

O DB2 for z/OS é o principal sistema gerenciador de banco de dados relacional (RDBMS) da IBM para o ambiente Mainframe IBM Z.

Quando você faz:

  • um PIX;

  • uma transferência bancária;

  • uma consulta de saldo;

  • uma compra com cartão;

há uma grande chance de existir um banco DB2 armazenando ou consultando essas informações.


Definição simples

DB2 é:

um banco de dados relacional corporativo de alta performance.

Ele armazena:

  • clientes;

  • contas;

  • contratos;

  • apólices;

  • transações;

  • produtos;

  • históricos.


Analogia simples

Imagine um enorme arquivo de fichas organizado.

O DB2 permite:

  • guardar informações;

  • localizar rapidamente;

  • atualizar dados;

  • remover registros;

  • relacionar tabelas.


História

O DB2 surgiu na IBM no início da década de 1980.

Foi um dos primeiros bancos comerciais baseados nos conceitos relacionais propostos por:

Edgar F. Codd


O que significa DB2?

Originalmente:

Database 2

Hoje a IBM usa oficialmente:

IBM Db2 for z/OS


Onde o DB2 roda?

Principalmente em:

  • IBM Z

  • z/OS

Mas também existem versões para:

  • Linux

  • Unix

  • Windows


Arquitetura simplificada

Aplicação COBOL
        ↓
SQL
        ↓
DB2
        ↓
Tablespaces
        ↓
Disco

O que é uma tabela?

Local onde os dados são armazenados.


Exemplo

Tabela CLIENTES

IDNOMESALDO
1JOÃO1000
2MARIA5000

Criando uma tabela

CREATE TABLE CLIENTES
(
   ID      INTEGER,
   NOME    VARCHAR(50),
   SALDO   DECIMAL(9,2)
);

O que é SQL?

Structured Query Language.

Linguagem usada para conversar com o DB2.


Comandos mais comuns

SELECT

Consulta dados.

SELECT *
FROM CLIENTES;

INSERT

Inclui registros.

INSERT INTO CLIENTES
VALUES (1,'JOAO',1000);

UPDATE

Atualiza registros.

UPDATE CLIENTES
SET SALDO = 2000
WHERE ID = 1;

DELETE

Remove registros.

DELETE
FROM CLIENTES
WHERE ID = 1;

DB2 e COBOL

Uma das combinações mais famosas da história da computação.


Exemplo

EXEC SQL

   SELECT NOME
   INTO :WS-NOME

   FROM CLIENTES

   WHERE ID = :WS-ID

END-EXEC.

O que é SQL embutido?

SQL escrito dentro do COBOL.

Chamado de:

Embedded SQL


Processo de compilação

COBOL + SQL
      ↓
Precompiler DB2
      ↓
Compilador COBOL
      ↓
Bind
      ↓
Execução

O que é BIND?

Processo que cria:

Package

e

Plan

necessários para execução SQL.


Objetos principais do DB2


Database

Container lógico.


Tablespace

Local físico onde as tabelas ficam.


Table

Armazena dados.


Index

Acelera pesquisas.


View

Consulta virtual.


Synonym / Alias

Nome alternativo.


Exemplo simplificado

DATABASE
   ↓
TABLESPACE
   ↓
TABLE

O que é Tablespace?

Área física onde o DB2 grava os dados.


O que é Index?

Estrutura que acelera consultas.


Sem índice

1
2
3
4
5
...

Procura sequencial.


Com índice

Índice
 ↓
Registro encontrado

Muito mais rápido.


O que é Cursor?

Usado quando um SELECT retorna várias linhas.


Exemplo

DECLARE C1 CURSOR FOR
SELECT NOME
FROM CLIENTES;

Operações com Cursor

DECLARE
   ↓
OPEN
   ↓
FETCH
   ↓
CLOSE

FETCH

Lê uma linha por vez.


SQLCODE

Código de retorno do DB2.

Muito importante.


Exemplos

SQLCODESignificado
0Sucesso
+100Registro não encontrado
-305Valor nulo
-803Chave duplicada
-904Recurso indisponível
-911Deadlock/Rollback

SQLCA

Área de comunicação SQL.


Exemplo

EXEC SQL
   INCLUDE SQLCA
END-EXEC.

O que é COMMIT?

Confirma alterações.


Exemplo

COMMIT;

O que é ROLLBACK?

Desfaz alterações.


Exemplo

ROLLBACK;

Fluxo transacional

UPDATE
   ↓
COMMIT

ou

UPDATE
   ↓
ERRO
   ↓
ROLLBACK

DB2 Online e Batch

Online

Normalmente:

  • CICS

  • IMS TM


Batch

Normalmente:

  • COBOL

  • JCL

  • Scheduler


Ferramentas comuns

  • SPUFI

  • DSNTEP2

  • QMF

  • Data Studio

  • Db2 Admin Tool


Como o DB2 aparece no dia a dia?

Praticamente em:

  • PIX

  • cartões

  • internet banking

  • seguros

  • e-commerce

  • governo


Curiosidades

1. Alguns bancos possuem bancos DB2 com dezenas de terabytes

2. O DB2 processa bilhões de transações diariamente

3. Muitas aplicações COBOL acessam DB2 há mais de 30 anos

4. O DB2 é considerado um dos bancos mais confiáveis do mundo


Erros comuns de iniciantes

Ignorar SQLCODE


Esquecer COMMIT


Não fechar CURSOR


Fazer SELECT sem índice


Não entender SQLCA


Resumo rápido

ConceitoFunção
DB2Banco de dados relacional
SQLLinguagem do DB2
TableArmazena dados
IndexAcelera consultas
CursorPercorre linhas
SQLCARetorno SQL
SQLCODECódigo de retorno
COMMITConfirma
ROLLBACKDesfaz
BINDGera Package/Plan

Conclusão

O DB2 for z/OS é um dos pilares do ecossistema Mainframe IBM Z. Ele fornece armazenamento relacional de alta disponibilidade, segurança e desempenho para aplicações COBOL, CICS, IMS e batch que processam milhões de transações críticas diariamente.