Mostrar mensagens com a etiqueta dados. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta dados. Mostrar todas as mensagens

domingo, 18 de janeiro de 2026

Single Source of Truth (SSOT): a verdade nua, crua… e versionada

 

Bellacosa Mainframe e o conceito de single source of truth

Single Source of Truth (SSOT): a verdade nua, crua… e versionada

Se existe um conceito que todo arquiteto, analista, DBA, operador e até estagiário já ouviu — e todo mundo acha que já tem — esse conceito é o tal do Single Source of Truth.
Spoiler: quase ninguém tem de verdade. E no mainframe isso é ainda mais sagrado (e mais difícil).

Senta que lá vem história.


🧠 Origem: quando a verdade ainda cabia em um arquivo VSAM

Antes de buzzwords, cloud, data mesh e dashboards coloridos, o SSOT já existia — só não tinha nome chique.

Nos anos 60/70, no mundo IBM Mainframe, a regra era simples:

“Existe um dado oficial. O resto é cópia, relatório ou dor de cabeça.”

  • Um master file VSAM

  • Um DB2 table owner bem definido

  • Um CICS que mandava na regra de negócio

Se o saldo do cliente estava no arquivo X, qualquer outro valor estava errado, não “divergente”.

👉 Isso era SSOT by design, não por moda.


📜 Definição curta (para colar na parede da sala)

Single Source of Truth é a fonte única, autorizada e confiável de um dado, regra ou estado de negócio.

  • Não é só onde o dado está

  • É quem manda nele

  • É quem pode mudar

  • É quem responde quando dá problema

No mainframe, isso sempre foi levado a sério porque…
💸 erro de dado = dinheiro real sumindo.


🏗️ SSOT no Mainframe: raiz forte, galhos controlados

No mundo IBM Mainframe, o SSOT normalmente assume estas formas:

  • 📦 DB2 → verdade transacional

  • 📁 VSAM KSDS/ESDS → registros mestres históricos

  • 🧠 CICS → verdade das regras online

  • 📊 SMF/RMF → verdade operacional

  • 🔐 RACF → verdade de segurança (e ponto final)

E aqui vai a regra de ouro, estilo Bellacosa:

Se dois sistemas “mandam” no mesmo dado… nenhum manda.


⚠️ O problema moderno: todo mundo quer sua própria verdade

Com a chegada de:

  • Data Lakes

  • BI Self-Service

  • Microservices

  • Replicações near-real-time

  • APIs para tudo

Nasceu o monstro de três cabeças:

🧟 A Verdade Paralela
🧟 A Verdade de Cache
🧟 A Verdade do PowerPoint

Cada área passa a ter:

  • “Meu dado”

  • “Meu relatório”

  • “Minha métrica”

E quando os números não batem…

👉 a culpa é do mainframe, claro 😏


🧩 Formatos de SSOT (sim, existem vários)

1️⃣ SSOT Transacional

  • Fonte: DB2 / CICS

  • Uso: sistemas core

  • Alta integridade

  • Baixa tolerância a erro

💡 Mainframe é rei aqui.


2️⃣ SSOT Analítico

  • Fonte: DW / Lakehouse

  • Uso: BI, KPIs

  • Risco: latência e transformação

⚠️ Não confundir com verdade operacional.


3️⃣ SSOT de Configuração

  • Fonte: repositórios únicos

  • Ex: parâmetros, tabelas de domínio

🧨 Dica: tabela “copiada” em cada sistema não é SSOT.


4️⃣ SSOT de Governança

  • Catálogos de dados

  • Data lineage

  • Glossário corporativo

📚 Onde a verdade é documentada, não só armazenada.


🛠️ Dicas práticas (da trincheira, não do slide)

✔️ Defina ownership real

“Quem acorda às 3h da manhã se der erro?”

✔️ Separe dado de consumo

  • Origem ≠ réplica ≠ cache

✔️ Documente a verdade

  • Se não está escrito, vira lenda urbana.

✔️ Controle quem escreve

  • Ler é democrático. Escrever não.

✔️ Mainframe como âncora

  • Sistemas modernos orbitam. O core não flutua.


💣 Riscos clássicos (a lista da vergonha)

  • ❌ Duas bases “oficiais”

  • ❌ ETL que “corrige” dado

  • ❌ BI explicando divergência em reunião

  • ❌ Regra de negócio fora do core

  • ❌ “É só um relatório…”

⚠️ Relatório nunca é inocente.


🧪 Curiosidades & Easter Eggs

🥚 Easter Egg #1

Muitos sistemas “modernos” recriam SSOT… e descobrem 30 anos depois o que o CICS já fazia.

🥚 Easter Egg #2

RACF é um dos SSOTs mais respeitados da empresa — ninguém questiona.

🥚 Easter Egg #3

O termo SSOT ficou famoso com BI, mas nasceu no batch noturno.


🧠 Reflexão final (El Jefe mode ON)

SSOT não é tecnologia.
É disciplina organizacional.

Você pode ter:

  • Cloud

  • Kafka

  • Lakehouse

  • AI

  • Dashboard bonito

Mas se não souber qual dado é o oficial

👉 Você só tem várias mentiras bem organizadas.


☕🌙 Midnight Lunch Thought
No fim do dia (ou da madrugada):
quem controla a verdade controla o sistema.
E historicamente…
o mainframe sempre soube disso.


sábado, 6 de abril de 2024

O que é um Diagrama de Fluxo de Dados.

Um olho no passado, dois olhos no futuro: Diagrama de Fluxo de Dados. Salve jovem padawan, mais uma vez faremos uma viagem no tempo, para os primórdios da informática, onde as grandes ideias surgiram, sementes foram semeadas e gradualmente o sistema foi sendo criado. Leia na Integra

terça-feira, 16 de janeiro de 2024

🔥 IBM 3592 JF – O cartucho que carrega impérios de dados

 


🔥 IBM 3592 JF – O cartucho que carrega impérios de dados




🧠 Introdução – quando o dado dorme em fita, mas sonha em petabytes

Se você acha que fita magnética é coisa de museu, é porque nunca encarou um IBM 3592 JF rodando em um TS1140/TS1150 dentro de um data center que parece mais uma nave espacial do que uma sala fria.
O 3592 JF não é “backup”. Ele é arquivo corporativo, retenção legal, seguro contra ransomware e, em muitos bancos, a última linha de defesa da civilização digital.

Bem-vindo ao mundo onde dados não são deletados — são arquivados com honra.


📜 História – da fita de rolo ao JF

A linhagem do IBM 3592 nasce no início dos anos 2000 como sucessor espiritual das 3490/3480.
O sufixo JF marca uma geração madura, refinada, feita para:

  • Ambientes z/OS heavy-duty

  • Integração com DFSMS/HSM

  • Coexistência com VTS, TS7700 e GDPS

📼 O JF é o tipo de mídia que sobrevive a mudanças de diretoria, ERPs, fusões e três modas de cloud.


🧱 Arquitetura do cartucho IBM 3592 JF

Características físicas e lógicas:

  • 📏 Formato proprietário IBM (não confundir com LTO)

  • 💾 Capacidade nativa: ~700 GB

  • 🗜️ Capacidade com compressão: até ~2–3 TB (dependendo do workload)

  • 🔐 Suporte a criptografia por hardware

  • 🧬 Servo tracking de altíssima precisão

💡 Easter egg: a densidade da fita é tão alta que um cartucho mal acondicionado “grita” no log do drive antes mesmo de falhar.


🏗️ Onde ele vive no mundo real

Normalmente você encontra o 3592 JF em:

  • 🗄️ IBM TS3500 / TS4500 Tape Library

  • 🧠 TS7700 (Virtual Tape Server) como mídia física de backend

  • 🧾 Ambientes regulados: bancos, seguradoras, governos

Ele conversa intimamente com:

  • z/OS DFSMS

  • HSM (Hierarchical Storage Manager)

  • DFSMShsm Migration / Recall


🔄 Workflow clássico no mainframe

📌 Passo a passo “vida de fita”

  1. Dataset criado (PS ou GDG)

  2. Política de SMS decide: disk hoje, fita amanhã

  3. HSM migra o dataset para fita

  4. Catalog aponta para volume JF

  5. Recall on-demand traz o dado de volta

  6. Dataset volta ao disco como se nada tivesse acontecido

🧙‍♂️ Magia negra mainframe: a aplicação nunca sabe que o dado dormiu em fita.


📊 Logs, SMF e rastros

O 3592 JF deixa pegadas elegantes:

  • SMF 14/15 – uso de fita

  • SMF 42 – atividades de DFSMS

  • SMF 94 – criptografia

  • Logs do TS7700 (se virtualizado)

📎 Dica Bellacosa: fita não mente. Se algo sumiu, o SMF sabe onde foi parar.


🧩 Curiosidades que só quem viveu sabe

  • ☕ Drives 3592 “acordam” antes do operador terminar o café

  • 🔁 Uma fita JF pode sobreviver 30 anos se bem armazenada

  • 🧯 Ransomware odeia fita — ela não monta sozinha

  • 🎩 Cartucho com label mal escrito vira lenda urbana no CPD


🛠️ Dicas práticas de sobrevivência

✔️ Padronize nomenclatura de volumes
✔️ Nunca misture JF com JE/JB sem planejamento
✔️ Use criptografia nativa, não “caseira”
✔️ Monitore recalls excessivos (sinal de má política de HSM)
✔️ Tape não é lenta — lento é acesso mal desenhado


📚 Guia de estudo para mainframers

📖 Leia e domine:

  • DFSMS Storage Administration

  • DFSMShsm Implementation

  • IBM TS11xx Drive Redbooks

  • SMF 14/15 deep dive

🧠 Exercício clássico:

Simule migração, expiração, recall e auditoria de um dataset crítico sem que a aplicação perceba.


🧪 Aplicações reais do IBM 3592 JF

  • 📜 Retenção legal (7–30 anos)

  • 🏦 Histórico financeiro imutável

  • 🧬 Dados médicos arquivados

  • 🛰️ DR offline (air gap real)

  • 📦 Data lake pré-cloud que ainda funciona


🧨 Comentário final – El Jefe Style

Enquanto o mundo discute se “cloud é o futuro”, o IBM 3592 JF continua fazendo o que sempre fez:
guardar o passado para proteger o futuro.

No mainframe, fita não é legado.
É estratégia.

🔥 Midnight Lunch aprovado. A fita gira, o dado dorme, o mainframer sorri.


quarta-feira, 12 de outubro de 2011

🔥 COMMAREA vs CHANNEL/CONTAINER no CICS

 


🔥 COMMAREA vs CHANNEL/CONTAINER no CICS



☕ Midnight Lunch, COMMAREA gigante e o CICS olhando feio

Todo mainframer já viveu esse momento:

“Só aumentei a COMMAREA… de 2K pra 32K.”

Minutos depois:

  • ASRA misterioso

  • Storage estourando

  • Performance caindo

  • E alguém sussurra:
    👉 “Por que não usaram CHANNEL?”

Hoje vamos resolver essa treta histórica: COMMAREA vs CHANNEL/CONTAINER, com números, boas práticas, cicatrizes e filosofia Bellacosa.


🏛️ História: do bloco único ao container moderno

COMMAREA

  • Nasceu nos primórdios do CICS

  • Simples, direta, rápida

  • Pensada para pequenos volumes de dados

  • Era “o suficiente” nos anos 70/80

CHANNEL/CONTAINER

  • Introduzido no CICS TS 3.x

  • Resposta à complexidade crescente

  • Feito para dados grandes, estruturados e flexíveis

  • Arquitetura mais próxima de “mensageria moderna”

📌 Não é moda. É evolução arquitetural.


🧠 Conceito essencial (guarde isso)

COMMAREA = um bloco fixo de memória
CHANNEL/CONTAINER = coleção flexível de blocos independentes

Isso muda tudo.


📦 COMMAREA – o clássico confiável (e perigoso)

O que é?

Um único bloco contínuo de memória, passado entre programas via LINK/XCTL.

📏 Tamanho máximo

  • Até 32.767 bytes (~32 KB)

Sim. Esse é o limite duro.
Passou disso? Nem adianta insistir.


👍 Pontos fortes

✔ Simples
✔ Rápido
✔ Fácil de debugar
✔ Ideal para estruturas pequenas

👎 Limitações

❌ Tamanho limitado
❌ Forte acoplamento entre programas
❌ Layout rígido
❌ Difícil evoluir sem impacto


❌ Erros comuns com COMMAREA (easter eggs)

🐣 COMMAREA gigante “só por garantia”
🐣 Layout diferente entre programas
🐣 Reutilizar COMMAREA sem limpar
🐣 Usar COMMAREA como “dump de dados”

📌 COMMAREA não é mala de viagem.


📦 CHANNEL/CONTAINER – o adulto da sala

O que é?

Um CHANNEL é um agrupador lógico.
Um CONTAINER é um bloco individual de dados dentro do channel.

📦 Channel
└── Container A
└── Container B
└── Container C

Cada um com:

  • Tamanho próprio

  • Tipo próprio

  • Vida própria


📏 Tamanho máximo

  • Praticamente ilimitado (dependente de storage)

  • Containers podem ter megabytes

  • Muito além do limite da COMMAREA

📌 Aqui o gargalo deixa de ser o CICS e passa a ser o bom senso.


👍 Pontos fortes

✔ Estrutura flexível
✔ Baixo acoplamento
✔ Ideal para dados grandes
✔ Melhor para evolução de sistemas
✔ Integra bem com Web Services e MQ

👎 Cuidados

❌ Mais verboso
❌ Exige disciplina
❌ Overkill para casos simples


🥊 COMMAREA vs CHANNEL/CONTAINER

CritérioCOMMAREACHANNEL/CONTAINER
Tamanho máx~32 KBMuito grande
EstruturaFixaFlexível
EvoluçãoDifícilFácil
PerformanceExcelenteMuito boa
AcoplamentoAltoBaixo
ModernidadeClássicoAtual

📌 Não existe melhor. Existe mais adequado.


🛠️ Passo a passo: como escolher

1️⃣ Dados pequenos e estáveis? → COMMAREA
2️⃣ Muitos campos opcionais? → CHANNEL
3️⃣ Dados grandes (XML, JSON)? → CHANNEL
4️⃣ Sistema legado crítico? → COMMAREA (com cuidado)
5️⃣ Integração moderna? → CHANNEL/CONTAINER


⚡ Boas práticas Bellacosa

✅ COMMAREA

  • Use o menor tamanho possível

  • Documente o layout

  • Inicialize sempre

  • Evite “COMMAREA universal”

✅ CHANNEL/CONTAINER

  • Um container = um conceito

  • Nomeie containers claramente

  • Evite “container Frankenstein”

  • Libere quando não precisar

📌 Arquitetura também é educação.


🧪 Exemplo mental de otimização

Antes (COMMAREA)

  • Estrutura única de 30 KB

  • Metade dos campos nunca usados

  • Cada mudança quebra alguém

Depois (CHANNEL)

  • Container CLIENTE

  • Container PRODUTO

  • Container CONTROLE

  • Cada programa lê só o que precisa

🔥 Resultado:

  • Menos impacto

  • Mais clareza

  • Menos bug fantasma


📚 Guia de estudo recomendado

Para dominar o tema:

  • CICS Program Control

  • Storage Management

  • COMMAREA lifecycle

  • CHANNEL/CONTAINER APIs

  • Performance tuning em CICS

📖 Manual essencial: CICS Application Programming Guide


🤓 Curiosidades de boteco mainframe

🍺 CHANNEL foi criado porque COMMAREA virou “caixa de Pandora”
🍺 Há sistemas que simulam JSON dentro de COMMAREA (não faça isso)
🍺 Web Services no CICS usam CHANNEL por baixo dos panos
🍺 Muitos ainda usam COMMAREA por medo, não por necessidade


💬 Comentário El Jefe Midnight Lunch

“COMMAREA resolve rápido.
CHANNEL resolve certo.
O mainframe não perdoa preguiça arquitetural.”


🚀 Aplicações reais hoje

  • Core bancário moderno

  • APIs CICS

  • Integração com MQ

  • Processamento XML/JSON

  • Sistemas híbridos (CICS + Cloud)


🎯 Conclusão Bellacosa

COMMAREA não morreu.
CHANNEL não é bala de prata.

O mainframer experiente:

  • Sabe quando usar cada um

  • Respeita limites

  • Pensa no futuro

🔥 Arquitetura boa não dá abend. Dá orgulho.