☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

segunda-feira, 31 de janeiro de 2011

🔥 Aprender COBOL com DB2 — o caminho do programador mainframer de verdade

 

Aprenda COBOL com DB2 ao estilo Bellacosa Mainframe

🔥 Aprender COBOL com DB2 — o caminho do programador mainframer de verdade



🧠 Introdução: por que COBOL + DB2 ainda manda no jogo

Se você quer ser programador mainframe COBOL com DB2, precisa entender uma verdade simples:

COBOL processa.
DB2 guarda.
SQL conecta o cérebro à memória do negócio.

Não estamos falando de tecnologia “antiga”.
Estamos falando da infraestrutura que processa bilhões por dia, com ACID, consistência e auditoria que muita stack moderna ainda tenta copiar.

Esse artigo é um mapa de estrada, do zero até o código profissional, misturando:

  • técnica

  • história

  • prática

  • fofoca de data center

  • e aquela sabedoria que só mainframer velho passa no café ☕


DB2 o banco de dados do Mainframe


🧱 PARTE 1 — Conhecendo o DB2 (o coração dos dados)

📜 Um pouco de história

O DB2 nasce na IBM nos anos 80, baseado no modelo relacional proposto por Edgar F. Codd.

👉 Conceito revolucionário:

  • dados em tabelas

  • relações lógicas

  • SQL como linguagem declarativa

Enquanto o mundo brigava com arquivos VSAM:

“Me diga o que você quer, não como buscar.”


🧩 Modelo Relacional (base de tudo)

  • Tabela → entidade de negócio

  • Linha (row) → registro

  • Coluna (column) → atributo

  • Primary Key → identidade

  • Foreign Key → relacionamento

💬 Bellacosa comenta:

“Se você não entende modelo relacional, não adianta saber COBOL.”


🧾 Tipos de Dados DB2 (o casamento com COBOL)

DB2COBOL
CHAR / VARCHARPIC X
INTEGERPIC S9
DECIMALPIC S9V
DATEPIC X(10)
TIMESTAMPPIC X(26)

🥚 Easter egg:
DB2 guarda DECIMAL melhor do que muito banco moderno guarda FLOAT 😏


Queries SQL no DB2 

🧑‍💻 PARTE 2 — Linguagem SQL no DB2

🗣️ SQL: a língua franca dos dados

SQL não é procedural.
SQL é declarativa.

🔹 DDL — Data Definition Language

CREATE TABLE CLIENTE ( ID_CLIENTE INTEGER NOT NULL, NOME VARCHAR(50), SALDO DECIMAL(9,2), PRIMARY KEY (ID_CLIENTE) );
  • CREATE

  • DROP

  • ALTER


🔹 DCL — Data Control Language

GRANT SELECT ON CLIENTE TO USER01;

Controle de acesso.
Segurança raiz de banco.


🔹 DML — Data Manipulation Language

INSERT INTO CLIENTE VALUES (1, 'JOÃO', 1500.00); SELECT * FROM CLIENTE; UPDATE CLIENTE SET SALDO = SALDO + 100 WHERE ID_CLIENTE = 1; DELETE FROM CLIENTE WHERE ID_CLIENTE = 1;

💬 Bellacosa:

“DELETE sem WHERE é como RM -RF /”


🔍 SELECT, JOIN e afins (onde o bicho pega)

SELECT C.NOME, P.VALOR FROM CLIENTE C JOIN PEDIDO P ON C.ID_CLIENTE = P.ID_CLIENTE;

👉 JOIN mal feito = batch lento = gente te ligando às 3 da manhã.


🛠️ SPUFI e QMF

  • SPUFI → SQL direto no TSO

  • QMF → consultas, relatórios, análise

💡 Dica Bellacosa:

“Todo mundo começa no SPUFI.
Quem fica bom, aprende QMF.”



🧩 PARTE 3 — COBOL com DB2 (onde nasce o profissional)

🏛️ História rápida do COBOL

  • Criado em 1959

  • Foco: negócio

  • Legibilidade

  • Estabilidade

👉 Não é bonito.
👉 É confiável.


🧠 Estrutura de um programa COBOL

  • IDENTIFICATION DIVISION

  • ENVIRONMENT DIVISION

  • DATA DIVISION

  • PROCEDURE DIVISION

📌 Árvore programática é fundamental para não virar macarrão lógico.


🔗 Host Variables (a ponte COBOL ↔ DB2)

EXEC SQL SELECT SALDO INTO :WS-SALDO FROM CLIENTE WHERE ID_CLIENTE = :WS-ID END-EXEC.
  • Sempre com :

  • Tipagem correta

  • Conversão consciente


📊 SQLCA — seu melhor amigo

IF SQLCODE = 0 CONTINUE ELSE DISPLAY 'ERRO DB2 ' SQLCODE END-IF
SQLCODESignificado
0OK
+100NOT FOUND
< 0ERRO

💬 Bellacosa:

“Quem ignora SQLCODE vira operador sem saber.”


📚 DCLGEN — o BOOK sagrado

  • Gera layout da tabela

  • Gera host variables

  • Evita erro humano

//STEP01 EXEC PGM=DSNTEP2

👉 Nunca escreva layout DB2 na mão. Nunca.


Consulta pagina via cursor no DB2

🌀 PARTE 4 — Cursores (nível profissional)

🔄 Cursor para leitura

EXEC SQL DECLARE C1 CURSOR FOR SELECT ID_CLIENTE, NOME FROM CLIENTE END-EXEC.
EXEC SQL FETCH C1 INTO :WS-ID, :WS-NOME END-EXEC.

📌 Sempre:

  • OPEN

  • FETCH

  • CLOSE


✍️ Inserindo, alterando e excluindo via COBOL

  • INSERT → novo registro

  • UPDATE → alteração controlada

  • DELETE → cuidado máximo

💡 Boa prática:

“Nunca DELETE direto sem histórico.”


🧠 PARTE 5 — Boas práticas Bellacosa Mainframe

✔ Use DCLGEN
✔ Sempre trate SQLCODE
✔ Evite SELECT *
✔ Documente regra de negócio
✔ Separe lógica de acesso a dados
✔ Teste com volume real
✔ Pense em performance desde o SELECT

🥚 Easter egg clássico:

“O batch estava lento porque alguém esqueceu o índice.”


🧪 Exercícios de fixação (mentalidade correta)

  1. Criar tabela DB2

  2. Gerar DCLGEN

  3. Programa COBOL com:

    • INSERT

    • SELECT

    • UPDATE

    • DELETE

  4. Programa com CURSOR

  5. Programa com JOIN

  6. Analisar SQLCODE

  7. Ajustar performance

👉 Isso forma programador, não copiador de código.


🧠 Comentário final Bellacosa

Aprender COBOL com DB2 não é aprender uma linguagem.
É aprender:

  • como dados movem o mundo

  • como sistemas críticos pensam

  • como escrever código que não pode falhar

🔥 COBOL + DB2 não é passado.
É o núcleo silencioso do presente.

Enquanto modas passam,
o batch fecha o dia.

 

terça-feira, 11 de janeiro de 2011

Normalcy Bias: Doctor Who, COBOL e o Dia em que Tudo Já Estava Dando Errado — Mas Todo Mundo Achou que Ia Passar

Bellacosa Mainframe e o normalcy bias

☕ Um Café no Bellacosa Mainframe

Normalcy Bias: Doctor Who, COBOL e o Dia em que Tudo Já Estava Dando Errado — Mas Todo Mundo Achou que Ia Passar

Uma viagem pela TARDIS dos incidentes para entender por que, diante de sinais anormais, nosso cérebro insiste em acreditar que o mundo continuará funcionando como sempre funcionou

09:04.

Segunda-feira.

Café quente.

Mainframe acordado.

Usuários trabalhando.

Tudo normal.

Então aparece:

WARNING
PAYMENT RESPONSE TIME ABOVE BASELINE

O operador olha.

— Deve ser pico de volume.

09:11.

QUEUE DEPTH +40%

— Segunda-feira.

09:18.

TIMEOUT RATE +180%

— Deve estabilizar.

09:26.

Primeiras reclamações.

— Usuário sempre reclama antes de a coisa ficar normal.

09:34.

FAILED TRANSACTIONS: 417

O gerente pergunta:

— Precisamos abrir incidente?

Alguém responde:

— Vamos esperar mais dez minutos.

09:41.

Mais falhas.

09:46.

Mais reclamações.

09:49.

O sistema não está estabilizando.

Mas a mente coletiva ainda trabalha com uma convicção silenciosa:

“Provavelmente vai voltar ao normal.”

VWORP.

VWORP.

VWORP.

A TARDIS surge no corredor.

A porta abre.

O Doctor sai.

Olha para o painel.

Depois para os operadores.

— Há quanto tempo isso está piorando?

— Quarenta minutos.

— E o que vocês estão esperando?

— Que normalize.

O Doctor inclina a cabeça.

— Com base em quê?

Silêncio.

— Bem... normalmente normaliza.

Ele olha novamente para o gráfico.

— Ah.

Pausa.

— Então vocês estão usando o fato de ontem ter terminado bem como evidência de que hoje também terminará?

Mais silêncio.

— Isso é encantador.

Outra pausa.

— E profundamente perigoso.

Bem-vindo ao:



Normalcy Bias

Ou:

Viés de Normalidade

A tendência de subestimar sinais de perigo e assumir que, mesmo diante de eventos anormais, a situação provavelmente continuará parecida com aquilo que conhecemos.


🌀 Nossa TARDIS já viu muita coisa

Até aqui encontramos:

Swiss Cheese Model — várias defesas imperfeitas podem falhar juntas.

Normalization of Deviance — desvios podem virar rotina.

Hindsight Bias — depois do evento tudo parece óbvio.

Confirmation Bias — buscamos o que confirma nossas crenças.

Anchoring Bias — a primeira explicação pesa demais.

Groupthink — grupos convergem cedo demais.

Authority Gradient — hierarquia pode silenciar quem percebe risco.

Plan Continuation Bias — continuamos planos que já deveriam ser revistos.

Alarm Fatigue — alertas demais viram ruído.

Automation Bias — confiamos demais na máquina.

Drift Into Failure — pequenas decisões e perda de margem levam o sistema para a borda.

Diffusion of Responsibility — todo mundo vê e ninguém assume.

Agora o problema é diferente:

o perigo está visível, mas não parece real o bastante.


🧠 O que é Normalcy Bias?

Normalcy Bias é a tendência de acreditar que as coisas continuarão aproximadamente como sempre foram, mesmo quando surgem evidências de mudança séria.

O cérebro trabalha com modelos.

Ele aprende:

segunda-feira tem pico.

fila cresce.

depois cai.

Então, quando vê outra fila crescendo, tenta encaixar no padrão conhecido.

Isso é útil.

Sem esse mecanismo ficaríamos em pânico a cada pequena variação.

Mas em uma emergência real, essa mesma tendência pode atrasar resposta.

Representando:

SINAL ANORMAL
     ↓
“ISSO JÁ ACONTECEU”
     ↓
“DEVE PASSAR”
     ↓
ESPERA
     ↓
SINAL PIORA
     ↓
“AINDA DEVE PASSAR”
     ↓
ATRASO NA REAÇÃO

☕ Bellacosa Mainframe: “isso acontece no fechamento”

Imagine:

CPU: 91%

Operador:

— No fechamento sempre sobe.

Depois:

CPU: 95%
QUEUE: +120%

— Ainda dentro do esperado.

Depois:

CPU: 97%
QUEUE: +300%
TIMEOUTS: 870

— Deve ser o volume.

Talvez seja.

Mas a pergunta correta é:

“Em que ponto deixamos de estar dentro do comportamento conhecido?”

Normalcy Bias prospera quando não existe esse ponto definido.


📈 Baseline novamente salva o dia

Se você apenas pensa:

“isso costuma acontecer”

fica sujeito à memória.

Melhor:

BASELINE DE SEGUNDA-FEIRA

CPU normal: 72–84%
Queue normal: até 2.500
Timeout normal: < 20/min

Hoje:

CPU: 96%
Queue: 18.000
Timeout: 310/min

Agora fica difícil dizer:

“segunda-feira normal.”

Dados ajudam a quebrar o viés de normalidade.


🧠 “Já aconteceu antes” pode significar duas coisas

Frase:

“Já aconteceu antes.”

Pode significar:

  1. conhecemos esse comportamento e sabemos por que é seguro;

ou:

  1. sobrevivemos a ele antes e estamos presumindo que sobreviveremos novamente.

Essas coisas não são iguais.

A segunda se conecta diretamente com:

Normalization of Deviance.


🧩 Normalcy Bias versus Normalization of Deviance

Os nomes parecem parentes.

São.

Mas não são a mesma coisa.

Normalization of Deviance

O desvio se torna aceito ao longo do tempo.

“Esse warning é normal.”

Normalcy Bias

Diante de uma situação potencialmente grave, presumimos que ela não será tão grave e que a rotina continuará.

“Isso deve melhorar sozinho.”

Uma fala sobre:

o que aceitamos como normal.

A outra:

o que esperamos que continue normal.

As duas juntas podem ser perigosíssimas.


🚨 Exemplo

Warning diário.

Normalizamos.

Um dia o warning aparece com intensidade muito maior.

Normalcy Bias:

“É aquele warning de sempre.”

Mas não é mais o mesmo comportamento.

A familiaridade mascara mudança de escala.


👻 Easter Egg nº 1 — “Sempre volta”

Imagine uma estação espacial.

Luzes piscando.

Um técnico diz:

— A energia sempre volta.

Doctor:

— E voltou?

— Nas outras vezes.

— E desta?

— Ainda não.

— Então talvez devêssemos parar de usar as outras vezes como plano de recuperação.

Essa frase vale para produção.


🧠 Por que fazemos isso?

Porque admitir que existe emergência é caro.

Psicologicamente.

Organizacionalmente.

Operacionalmente.

Se dissermos:

“Temos incidente”

precisamos:

abrir War Room;

escalar;

interromper mudança;

avisar negócio;

talvez chamar diretor;

talvez perder SLA.

Esperar é mais confortável.

Talvez resolva sozinho.

Então Normalcy Bias pode ser reforçado por incentivos.


💰 Declarar incidente tem custo social

Imagine uma cultura onde abrir Severity 1 gera:

reuniões;

relatórios;

cobrança;

culpa;

PowerPoint para diretoria.

O que acontece?

Pessoas retardam declaração.

Não necessariamente conscientemente.

Pensam:

“Vamos esperar mais cinco minutos.”

Isso é perigoso.

A cultura tornou reconhecimento da realidade caro.


🚦 Better safe than embarrassed

Uma organização madura prefere:

falso positivo controlado;

a incidente reconhecido tarde.

Se alguém declara incidente e depois descobre que era menor:

ótimo.

Se for ridicularizado:

da próxima vez esperará.

Normalcy Bias ganha ajuda da cultura.


🧀 Swiss Cheese + Normalcy Bias

Imagine barreira:

detecção humana.

O alerta aparece.

Mas humano pensa:

“não é grave.”

Mais um buraco.

Depois barreira:

escalation.

Não escalamos porque:

“vai passar.”

Outro buraco.

Depois:

rollback.

Não rollbackamos porque:

“ainda deve estabilizar.”

Terceiro buraco.

O queijo vai alinhando.


🌀 Drift Into Failure prepara o terreno

Durante anos:

mais volume;

menos margem;

mais warning.

A operação vai se adaptando.

Então chega o dia em que sistema cruza a fronteira.

Mas todos ainda possuem modelo mental antigo:

“ele sempre aguenta.”

Isso é Normalcy Bias sustentado por memória histórica.

O sistema mudou.

O modelo mental não.


🧠 Model Drift humano

Falamos de drift em sistemas.

Mas também existe drift entre:

realidade;

modelo mental.

Exemplo:

2021:

batch aguenta 20 milhões.

2026:

processa 80 milhões.

Operador ainda pensa:

“Esse job é muito robusto.”

Talvez fosse.

Sob condições antigas.


🤖 Automation Bias piora

Dashboard:

OVERALL: GREEN

Usuários reclamam.

Normalcy Bias:

“provavelmente ruído.”

Automation Bias:

“o painel diz verde.”

Agora os dois se reforçam.

A realidade perde votação.


🔔 Alarm Fatigue também ajuda

Se alertas aparecem constantemente:

novo alerta grave parece só mais um.

Normalcy Bias diz:

“igual aos anteriores.”

Alarm Fatigue diz:

“não quero olhar.”

Excelente combinação.


👥 Groupthink cria normalidade coletiva

Uma pessoa diz:

— Não parece grave.

Outra:

— Concordo.

Terceira:

— Já vimos antes.

Agora o grupo constrói uma narrativa:

“está tudo sob controle.”

A pessoa mais preocupada começa a duvidar.

Groupthink transforma Normalcy Bias individual em percepção coletiva.


🪜 Authority Gradient silencia o desconfortável

Júnior:

— Isso está pior que o normal.

Sênior:

— Relaxa. Já vi isso várias vezes.

O júnior se cala.

Talvez esteja certo.

Authority Gradient protege o modelo mental antigo.


▶️ Plan Continuation Bias

Mudança em andamento.

Métricas pioram.

Equipe:

— Deve estabilizar depois do próximo passo.

Continua.

Normalcy Bias:

isso ainda não é emergência.

Plan Continuation Bias:

não pare.

E lá vamos nós.


👥 Diffusion of Responsibility

Todo mundo observa.

Ninguém declara incidente porque presume que:

se fosse realmente grave, alguém já teria declarado.

Perfeito.

Agora a ausência de ação das outras pessoas vira evidência de normalidade.

Esse mecanismo é assustadoramente elegante.


🧠 Social Proof em crise

Humano observa os outros.

Se ninguém corre:

talvez não haja fogo.

Isso é útil em situações ambíguas.

Mas se todos estão olhando uns para os outros:

o grupo inteiro pode ficar parado.


🔥 “Se fosse grave, alguém faria alguma coisa”

Essa frase deveria disparar alerta mental.

Porque talvez todas as pessoas estejam usando exatamente o mesmo raciocínio.


🏢 O caso do cheiro de queimado

Imagine data center.

Alguém sente cheiro de queimado.

Olha para outros.

Ninguém parece preocupado.

Pensa:

ar-condicionado.

Outro também sente.

Vê primeiro calmo.

Pensa:

deve ser normal.

Todos detectaram.

Nenhum validou.

Essa é uma versão perfeita.


💻 No COBOL: retorno estranho

Programa normalmente retorna:

REJECTS: 10–30

Hoje:

REJECTS: 490

Operador:

— Final de mês.

Depois:

REJECTS: 1.870

— Volume alto.

Pergunta:

qual limite separa explicação razoável de racionalização?

Precisa existir.


🚨 Thresholds de reconhecimento

Além de thresholds técnicos, precisamos de thresholds de decisão.

Exemplo:

IF REJECT RATE > 1%
    DECLARE DEGRADED

IF > 3%
    OPEN INCIDENT

IF > 5%
    STOP PROCESSING

Agora a mente não negocia infinitamente.


🧠 Precommitment retorna

Antes da crise:

definimos:

se X ocorrer, agimos.

Durante:

menos espaço para:

“vamos esperar.”

Precommitment combate Normalcy Bias.


🛑 Trigger Action Response Plan

Uma abordagem poderosa:

TRIGGER:
Queue > 10k por 5 min

ACTION:
abrir incidente

TRIGGER:
Timeout > 5%

ACTION:
HOLD mudança

TRIGGER:
Reconciliação != 0

ACTION:
STOP

O gatilho conecta diretamente a ação.

Reduz ambiguidade.


🧠 Não espere certeza absoluta

Outra armadilha.

Pessoas esperam:

“prova de desastre.”

Mas segurança trabalha com evidência suficiente.

Se esperar certeza total:

talvez já seja tarde.

A pergunta é:

“qual nível de incerteza aceitamos antes de agir?”


📊 Confidence Thresholds

Exemplo:

não sabemos causa.

Mas sabemos:

impacto subindo;

tendência negativa;

margem caindo.

Já pode ser suficiente para:

abrir incidente.

Você não precisa saber causa raiz para reconhecer emergência.


🔥 Incidente primeiro, explicação depois

Às vezes pessoas pensam:

“Não podemos declarar incidente porque ainda não sabemos a causa.”

Errado.

Incidente é sobre impacto e risco.

Causa vem depois.

Se prédio está queimando, não precisamos saber origem do fogo antes de evacuar.


☕ Bellacosa Mainframe: RC=00 e negócio quebrado

Job:

RC=0000

Tudo normal?

Talvez.

Mas reconciliação:

EXPECTED: 3.450.000
POSTED:   3.210.000

Normalcy Bias:

“talvez atraso de atualização.”

Investigue.

RC=00 só fala sobre o que o programa considerou sucesso.

Não sobre o universo.


🧠 Technical Normal vs Business Abnormal

Essa distinção é muito importante.

Infra:

normal.

Negócio:

anormal.

Se você escuta apenas infraestrutura, pode ignorar clientes.

Sempre valide impacto ponta a ponta.


📞 Usuário pode ser o primeiro sensor

Usuário reclama.

Dashboard verde.

Não presuma:

usuário está errado.

Ele pode estar enxergando uma camada não monitorada.

Normalcy Bias adora desqualificar sinal externo porque não cabe no painel.


🎯 Pergunta Bellacosa nº 1

Quando alguém disser:

“Deve normalizar.”

Pergunte:

“Qual evidência mostra tendência de normalização?”

Se resposta:

“normalmente acontece”

temos memória.

Não evidência atual.


🎯 Pergunta Bellacosa nº 2

Outra:

“Qual comportamento distinguiria ‘pico normal’ de ‘incidente começando’?”

Defina.


🎯 Pergunta Bellacosa nº 3

Outra:

“Quanto tempo estamos dispostos a esperar antes de agir?”

Sem isso:

espera vira infinita.


🎯 Pergunta Bellacosa nº 4

E:

“Se isso piorar duas vezes, nossa decisão muda?”

Planeje antes.


🧪 Passo a passo para combater Normalcy Bias

Passo 1 — Tenha baseline objetivo

Não dependa de sensação.


Passo 2 — Defina triggers claros

Quando deixa de ser normal?


Passo 3 — Diferencie variação de tendência

Um pico isolado pode ser ruído.

Três métricas piorando juntas contam história.


Passo 4 — Defina tempo de observação

“Esperar” precisa ter relógio.

Exemplo:

OBSERVE FOR 5 MIN
THEN REASSESS

Não:

“vamos vendo.”


Passo 5 — Use escalonamento progressivo

Warning.

Degraded.

Incident.

Critical.


Passo 6 — Permita declaração precoce

Sem punição social.


Passo 7 — Use fresh eyes

Pessoa nova pode perceber que o “normal” já mudou.


Passo 8 — Compare com cenários históricos corretos

Não apenas:

“já aconteceu.”

Pergunte:

“nas mesmas condições?”


Passo 9 — Registre decisões

Por que optamos por esperar?

Qual sinal mudaria isso?


Passo 10 — Faça retrospectiva sobre atrasos de reconhecimento

Não apenas causa raiz.

Pergunte:

quando tivemos informação suficiente para perceber que era incidente?


🕰️ Time to Declare

Podemos medir:

MTTD.

MTTR.

Mas também:

Time to Declare

Quanto tempo entre sinais suficientes e declaração formal?

Exemplo:

09:10 primeiro sinal forte
09:47 incidente declarado

37 minutos.

Talvez recuperação tenha levado 20.

Então maior problema foi reconhecimento tardio.


🧠 Recognition Latency

Atraso cognitivo importa.

Sistema pode detectar às 09:10.

Humano reconhecer às 09:40.

Organização agir às 09:50.

Três tempos diferentes.


📊 Timeline cognitiva novamente

09:04 metric abnormal
09:11 queue growing
09:18 timeouts
09:26 users report
09:34 failures
09:49 incident declared

Pergunte:

em qual ponto já tínhamos evidência suficiente?

Isso produz aprendizado.


🧠 Hindsight Bias cuidado!

Depois:

— Era claramente incidente às 09:11.

Talvez.

Ou talvez não.

Não use futuro para julgar.

Mas podemos perguntar:

quais critérios teriam permitido reconhecer antes?

Isso transforma retrospectiva em engenharia.


🏥 Normalcy Bias fora da TI

Esse viés aparece em desastres naturais, emergências e situações em que pessoas demoram a reagir porque eventos extremos parecem improváveis.

É justamente por isso que alertas públicos precisam ser:

claros;

acionáveis;

específicos.

“Pode haver risco” é diferente de:

“Evacue agora.”

Em TI também.


🚨 Mensagens vagas alimentam viés

WARNING:
SYSTEM MAY BE DEGRADED

Pessoa:

— Talvez não.

Melhor:

PAYMENT FAILURE RATE 12%
NORMAL < 0.2%
IMPACT CONFIRMED
OPEN INCIDENT NOW

Ação clara.


🧠 Linguagem importa

Evite:

“parece alguma instabilidade.”

Se dados mostram:

35% das transações falhando,

diga isso.

Eufemismo pode reforçar Normalcy Bias.


🏢 Cultura do “não dramatiza”

Algumas equipes valorizam calma.

Ótimo.

Mas calma não significa minimizar.

Você pode dizer:

“Temos impacto crítico confirmado”

sem pânico.

Precisão não é dramatização.


🧯 British calm versus denial

Aqui nosso humor britânico fica perfeito.

Existem duas atitudes:

Calma britânica:

“O prédio está pegando fogo. Vamos evacuar de forma ordenada.”

Normalcy Bias:

“Há apenas uma quantidade incomum de fumaça. Talvez seja o chá.”

Não confunda compostura com negação.


👻 Easter Egg nº 2 — chá e Daleks

Companion:

— Doctor, há Daleks na recepção.

— Quantos?

— Quatorze.

— E o segurança?

— Disse que provavelmente é uma convenção.

Doctor:

— Normalcy Bias.

— O quê?

— Depois explico. Corra.


🔁 Continuous Reassessment

Uma prática central:

reavalie.

Se decidiu:

esperar cinco minutos,

depois de cinco:

nova decisão.

Não deixe decisão temporária virar permanente.


⏰ Timer explícito

Use:

DECISION:
Observe.

EXPIRES:
09:30.

Às 09:30:

decida novamente.

Isso impede inércia.


🧠 “No decision” é uma decisão

Esperar também é ação.

Ela possui risco.

Pergunte:

qual é o custo de esperar?

Às vezes esperar é correto.

Mas deve ser escolha consciente.


📉 Cost of Delay

Se fila cresce 1.000/minuto:

esperar 10 minutos:

+10.000 backlog.

O tempo possui custo mensurável.

Isso ajuda a combater:

“vamos esperar mais.”


💻 COBOL e batches

Batch começa atrasar.

Ainda dentro da janela.

Normalcy Bias:

dá tempo.

Mas calcule:

ritmo atual.

tempo restante.

volume restante.

Agora talvez descubra matematicamente que não dá.

Projeção supera esperança.


📈 Forecast operacional

Em vez de:

“ainda está rodando.”

Use:

CURRENT RATE: 20k/min
REMAINING: 2M
ESTIMATED END: 05:12
SLA: 04:00

Agora futuro provável fica visível.


🤖 IA pode ajudar — e atrapalhar

IA pode detectar anomalias.

Ótimo.

Mas Automation Bias:

IA diz normal.

Ou Normalcy Bias:

IA não sinalizou, então não é incidente.

Use IA como mais uma fonte.

Não substituto de realidade.


🔍 Anomaly Detection não é oráculo

Se modelo treinou com histórico onde sistema já estava degradando, pode considerar degradação “normal”.

Interessante, não?

O modelo também pode normalizar desvio estatisticamente.

Por isso baseline precisa ser saudável, não apenas frequente.


🧠 “Normal” estatístico versus “normal” seguro

Esse é um ponto magnífico.

Se sistema vive 95% do tempo com warning:

estatisticamente:

warning é normal.

Operacionalmente:

talvez seja péssimo.

Não confunda frequência com segurança.


🧬 Regeneração organizacional

Como uma organização se regenera depois de identificar Normalcy Bias?

Ela:

define baseline;

define gatilhos;

mede tempo de reconhecimento;

treina escalonamento;

reduz custo social de declarar incidentes;

usa dados objetivos;

cria temporizadores;

faz reavaliação periódica;

valoriza sinais externos;

e ensina:

“Familiar não significa seguro.”


📋 Checklist anti-Normalcy Bias

Quando algo parece estranho:

[ ] Isso está realmente dentro do baseline?

[ ] A tendência está melhorando ou piorando?

[ ] Estamos usando memória ou dados?

[ ] Condições são iguais às vezes anteriores?

[ ] Existe impacto confirmado?

[ ] Quanto custa esperar?

[ ] Qual é nosso trigger de incidente?

[ ] Quando reavaliamos?

[ ] Alguém está minimizando sem evidência?

[ ] O silêncio do grupo está sendo tratado como prova?

[ ] Se isso dobrar, o que faremos?

[ ] Já deveríamos estar agindo?

📓 Diário do Doctor

Se guardar apenas algumas ideias desta viagem, guarde estas:

Normalcy Bias é a tendência de presumir que a realidade continuará parecida com o normal conhecido, mesmo diante de sinais anormais.

“Já aconteceu antes” não prova que a situação atual seja segura.

Familiaridade pode atrasar reconhecimento de emergência.

Baseline objetivo é melhor que memória.

Esperar precisa ter prazo e critério.

Não é necessário conhecer causa raiz para declarar incidente.

Automation Bias e Alarm Fatigue podem reforçar Normalcy Bias.

Groupthink e Authority Gradient podem transformar minimização individual em consenso.

Normalization of Deviance muda o que chamamos de normal.

Drift Into Failure muda o sistema enquanto nosso modelo mental permanece antigo.

E principalmente:

O fato de o mundo ter voltado ao normal ontem não obriga o mundo a repetir a gentileza hoje.


🕰️ De volta às 09:04

A TARDIS retorna.

Primeiro alerta:

PAYMENT RESPONSE TIME ABOVE BASELINE

Operador:

— Deve ser pico.

Nosso programador responde:

— Pode ser. Vamos comparar com baseline.

09:08.

Fila 60% acima do normal.

09:10.

Timeout 4%.

Trigger definido:

TIMEOUT > 3%
FOR 3 MIN
→ DECLARE DEGRADED

09:13.

Ainda 4,5%.

Ele diz:

— Estamos em degraded.

O gerente pergunta:

— Já?

— Sim. O critério foi definido antes.

09:16.

Impacto aumenta.

Trigger:

FAILURE RATE > 5%
→ OPEN INCIDENT

Incidente aberto.

Owner atribuído.

MQ investigado.

Consumer degradado.

09:24.

Causa encontrada.

09:29.

Serviço restaurado.

Backlog controlado.

Nenhuma crise de duas horas.

O gerente pergunta:

— Não abrimos cedo demais?

Nosso programador olha para o gráfico.

— Talvez.

— E isso não é ruim?

O Doctor responde antes dele:

— Comparado a quê?

Silêncio.

— Ao privilégio de descobrir tarde demais que deveriam ter aberto antes?

O gerente sorri.

— Justo.


🥚 Easter Egg final

Horas depois surge:

BELLACOSA.BIAS(NORMAL)

Dentro:

       IF CURRENT-STATE NOT = BASELINE
           PERFORM INVESTIGATE
       END-IF.

       IF ONLY-REASON-TO-WAIT =
          'IT-USUALLY-GETS-BETTER'
           PERFORM SET-TIMER
       END-IF.

       IF IMPACT-CONFIRMED
           PERFORM ACT
       END-IF.

Comentário:

* FAMILIAR IS NOT THE SAME AS SAFE.

Outro:

* HOPE IS NOT A MONITORING STRATEGY.

E, naturalmente:

* BAD WOLF LEFT BEFORE THE ALARM.

Nosso jovem fecha o membro.

Pouco depois alguém diz:

— Esse erro costuma sumir sozinho.

Ele responde:

— Ótimo.

— Ótimo?

— Sim. Então sabemos o que esperar.

Abre um timer.

— Se não sumir em cinco minutos, sabemos que não estamos mais no caso normal.

Essa resposta é simples.

Mas representa uma mudança profunda.

Ele não rejeitou experiência.

Transformou experiência em critério testável.

Não entrou em pânico.

Também não negou realidade.

Em algum lugar:

VWORP.

VWORP.

VWORP.

A TARDIS desaparece.

No quadro permanece uma frase:

Calma é observar os fatos sem pânico. Normalcy Bias é observar os fatos e esperar que eles parem de ser fatos.

☕🌀

Next stop: Survivorship Bias — quando estudamos apenas os sistemas, projetos e equipes que sobreviveram e esquecemos de perguntar quantos fizeram exatamente a mesma coisa e desapareceram no caminho.

segunda-feira, 10 de janeiro de 2011

ECHELON — O Fantasma que Escutava o Mundo

 

Bellacosa Mainframe e echelon o fantasma que executava o mundo

☕ Um Café no Bellacosa Mainframe

ECHELON — O Fantasma que Escutava o Mundo

Memórias de um Hackerativismo Inocente, de uma Internet Livre e da Máquina que Parecia Ouvir Tudo

"Houve um tempo em que bastava escrever uma palavra em um canal de IRC para alguém perguntar: 'Será que o Echelon acabou de registrar isso?'"

No final da década de 1990 existia um tipo de internet que praticamente desapareceu.

Não havia redes sociais.

Não existia Facebook.

Não havia WhatsApp.

O Google ainda engatinhava.

A maioria das pessoas usava ICQ, mIRC, IRC, listas de discussão, Usenet, e-mail e páginas pessoais hospedadas no Geocities.

Era uma internet mais lenta.

Mas, curiosamente, era uma internet muito mais misteriosa.

Foi nessa época que uma palavra começou a circular quase como uma entidade sobrenatural:

ECHELON.

Para alguns era apenas um sistema militar.

Para outros, era o maior sistema de espionagem já criado.

Havia quem acreditasse que qualquer e-mail contendo determinadas palavras era automaticamente lido por agentes da NSA.

E existiam milhares de jovens hackers, curiosos, administradores de BBS e usuários de IRC que resolveram brincar justamente com essa possibilidade.

Você mesmo comentou que participou, em 1999, da chamada Brigada Anti-Echelon, quando grupos ao redor do mundo combinavam "a palavra do dia" e inundavam IRCs, e-mails e listas de discussão com termos considerados sensíveis para gerar milhares de falsos positivos. É uma lembrança muito representativa daquele momento histórico: uma mistura de ativismo digital, curiosidade técnica e humor típico da internet daquela época.

Hoje aquilo parece quase folclore.

Mas, durante alguns anos, parecia que estávamos vivendo dentro de um romance de espionagem.


O nascimento de um gigante invisível

A história do Echelon não começa com computadores.

Ela começa muito antes.

Na Segunda Guerra Mundial.

Enquanto Alan Turing ajudava a quebrar a máquina Enigma, ingleses e americanos perceberam algo revolucionário:

Informação vale mais que bombas.

Depois da guerra, essa cooperação continuou.

Em 1946 surgiu o acordo secreto UKUSA, reunindo inicialmente Estados Unidos e Reino Unido e, posteriormente, Canadá, Austrália e Nova Zelândia — o grupo que mais tarde ficou conhecido como Five Eyes. (Wikipedia)

O objetivo era simples:

Compartilhar inteligência.

Interceptar comunicações.

Dividir o planeta em áreas de monitoramento.

Décadas depois surgiria aquilo que receberia o codinome:

ECHELON.


A Guerra Fria mudou tudo

Durante os anos 60 e 70, quase toda comunicação internacional importante passava por satélites.

Isso facilitava enormemente a interceptação.

Em vez de grampear milhões de telefones individualmente, bastava instalar enormes antenas parabólicas apontadas para satélites de telecomunicações.

Foi exatamente isso que aconteceu.

Bases como:

  • Menwith Hill (Reino Unido)

  • Yakima (EUA)

  • Pine Gap (Austrália)

  • Waihopai (Nova Zelândia)

passaram a capturar enormes volumes de comunicações internacionais. (Duncan Campbell)

As famosas cúpulas brancas (radomes) vistas em fotografias protegiam gigantescas antenas direcionais.

Pareciam cenários de filme de ficção científica.

E eram reais.


Como o ECHELON funcionava?

Ao contrário do que muitos imaginavam, ele não era um "supercomputador único".

Era uma enorme rede distribuída.

Imagine um funil.

Milhões de comunicações entram.

O sistema tenta identificar quais podem ter interesse.

Entre elas:

  • ligações telefônicas

  • fax

  • rádio

  • satélite

  • telex

  • posteriormente e-mails

Tudo isso era processado por sistemas automáticos de SIGINT (Signals Intelligence). (Telepolis)


As famosas palavras-chave

Aqui nasceu a maior lenda da internet dos anos 90.

Dizia-se que existia uma lista secreta contendo milhares de palavras.

Exemplos imaginados pela comunidade da época:

  • bomb

  • plutonium

  • missile

  • anthrax

  • assassination

  • nuclear

Se qualquer comunicação contivesse essas palavras...

O sistema destacaria aquela mensagem.

Na prática, havia mecanismos automatizados de filtragem por critérios definidos pelas agências de inteligência, mas a ideia popular de uma simples "lista mágica" que acionava automaticamente agentes humanos foi bastante exagerada. (Telepolis)

Mesmo assim...

A imaginação coletiva fez o resto.


A internet respondeu com humor

Foi aí que nasceu um movimento curioso.

A chamada Anti-Echelon Brigade.

Milhares de usuários passaram a colocar listas enormes de palavras "suspeitas" em:

  • assinaturas de e-mail

  • páginas pessoais

  • IRC

  • newsletters

  • fóruns

O objetivo?

Gerar tanto ruído que o sistema ficasse sobrecarregado.

Hoje sabemos que isso dificilmente teria impacto operacional significativo.

Mas a ideia era brilhante como forma de protesto simbólico.

Era uma espécie de "negação de serviço" filosófica.


Eu lembro daquela internet...

Se você viveu aquela época...

Talvez também se lembre de coisas como:

ICQ fazendo "Uh-oh!"

mIRC colorido.

Scripts em TCL.

Eggdrop.

Bots.

BNC.

XDCC.

Napster.

IRCnet.

Brasnet.

DALnet.

EFnet.

Undernet.

E, claro...

As intermináveis discussões sobre:

"Será que o Echelon está lendo isso?"

Era quase um personagem invisível.


Quando a conspiração encontrou a realidade

Durante muitos anos governos simplesmente negavam tudo.

Até que jornalistas começaram a juntar peças.

O britânico Duncan Campbell foi um dos primeiros a investigar publicamente o sistema, ainda nos anos 1980. Depois vieram pesquisas como o livro Secret Power, de Nicky Hager, e estudos para o Parlamento Europeu, que consolidaram o debate público. (Duncan Campbell)

Durante anos...

Muita gente dizia:

"Isso é teoria da conspiração."

Depois...

Vieram documentos.

Relatórios.

Investigações.

E, em 2013, as revelações de Edward Snowden ampliaram a compreensão pública sobre a vigilância eletrônica em larga escala, mostrando programas modernos da NSA e de seus parceiros e reforçando que sistemas de interceptação global realmente existiam, embora nem sempre exatamente como descritos pelas lendas urbanas. (Wikipédia)

Foi um daqueles raros momentos em que parte do que era tratado como conspiração revelou ter um núcleo real — ainda que muitos detalhes populares fossem incorretos ou exagerados.


O maior mito

O maior mito era acreditar que:

"Um agente da NSA lia todos os e-mails."

Isso nunca fez sentido.

Nem tecnicamente.

Nem operacionalmente.

O verdadeiro poder estava na automação.

Os computadores faziam a triagem.

Os analistas humanos examinavam apenas uma pequena fração do material considerado relevante.


Easter Eggs da época

Algumas curiosidades quase esquecidas:

🥚 Muitos sites tinham um botão chamado:

"Anti-Echelon"

que automaticamente adicionava centenas de palavras-chave no rodapé.


🥚 Existiam plugins para Outlook.


🥚 Alguns assinavam TODOS os e-mails com dezenas de termos militares.


🥚 Havia até listas atualizadas com a "palavra da semana".


🥚 Alguns provedores proibiam esse tipo de assinatura.


🥚 No IRC existiam bots que inseriam automaticamente listas enormes de palavras em canais públicos.


A evolução

O mundo mudou.

Os satélites deixaram de ser o principal meio de comunicação.

Vieram:

fibra óptica

Internet

Cloud Computing

Smartphones

Redes sociais

Streaming

Hoje grande parte da inteligência eletrônica envolve muito mais do que comunicações via satélite: cabos submarinos, infraestrutura de internet, metadados, cooperação internacional e, em alguns casos, dados obtidos legalmente por diferentes mecanismos previstos em cada país. (Wikipedia)

O espírito do ECHELON evoluiu.

O nome ficou famoso.

Mas a tecnologia seguiu adiante.


O legado

O curioso é que ECHELON acabou se tornando muito maior como símbolo do que como nome técnico.

Hoje falamos muito mais sobre:

  • privacidade

  • criptografia ponta a ponta

  • VPN

  • Signal

  • Matrix

  • Tor

  • proteção de metadados

Esses debates nasceram, em parte, porque histórias como a do ECHELON despertaram a atenção do público para o poder da vigilância eletrônica.


Bellacosa Memories

Às vezes sinto saudades daquela internet.

Não porque fosse melhor.

Ela era lenta.

Barulhenta.

Caótica.

Caía quando alguém levantava o telefone.

Mas havia algo mágico.

Éramos exploradores.

Entrávamos em canais obscuros do IRC apenas para conversar com pessoas do outro lado do planeta.

Aprendíamos TCP/IP lendo RFCs.

Montávamos servidores em casa.

Descobríamos Linux compilando kernels.

E, entre uma conversa e outra, alguém aparecia dizendo:

"A palavra da semana do Echelon saiu."

Então dezenas de pessoas começavam a repetir aquelas palavras em canais públicos.

Hoje sabemos que provavelmente aquilo jamais abalou um sistema de inteligência global.

Mas talvez esse nunca tenha sido o verdadeiro objetivo.

O que importava era a mensagem.

Era uma geração inteira dizendo:

"A internet também pertence aos seus usuários."

Talvez tenha sido um gesto ingênuo.

Talvez tenha sido inútil.

Mas também foi um dos primeiros movimentos espontâneos em defesa da privacidade digital, quando a maioria das pessoas sequer imaginava que, décadas depois, carregaria no bolso um smartphone produzindo continuamente dados sobre localização, hábitos, contatos e comunicações.

O ECHELON desapareceu das manchetes.

Mas a discussão que ele iniciou continua viva.

E talvez esse seja o seu maior legado.

Porque algumas máquinas envelhecem.

Alguns programas são aposentados.

Mas uma pergunta continua ecoando desde aqueles dias de IRC, ICQ e modems de 56 kbps:

"Quem está ouvindo?"

domingo, 9 de janeiro de 2011

☕💣🦅 FULLMETAL ALCHEMIST: THE SACRED STAR OF MILOS — O JOB QUE DESCOBRIU UM DATACENTER ESQUECIDO ENTRE DUAS NAÇÕES E REVELOU UM SISTEMA OPERANDO FORA DA GOVERNANÇA CENTRAL

 

Bellacosa Mainfrmae e o filme The Sacred Star of Milos uma aventura Fullmetal Alchemist

☕💣🦅 FULLMETAL ALCHEMIST: THE SACRED STAR OF MILOS — O JOB QUE DESCOBRIU UM DATACENTER ESQUECIDO ENTRE DUAS NAÇÕES E REVELOU UM SISTEMA OPERANDO FORA DA GOVERNANÇA CENTRAL


Dados Técnicos

Título Original: 鋼の錬金術師 嘆きの丘の聖なる星
(Hagane no Renkinjutsushi: Milos no Sei-Naru Hoshi)

Título Internacional: Fullmetal Alchemist: The Sacred Star of Milos

Autor Original: Hiromu Arakawa

Baseado em: Fullmetal Alchemist: Brotherhood

Estúdio: Bones

Direção: Kazuya Murata

Roteiro: Yūichi Shinpo

Lançamento: 2 de julho de 2011

Duração: 110 minutos

Classificação Indicativa: 13 a 16 anos

Gêneros:

  • Ação

  • Aventura

  • Fantasia

  • Drama

  • Steampunk

  • Ficção Política

  • Shounen


O Filme Mais Subestimado da Franquia

Quando alguém fala sobre Fullmetal Alchemist, normalmente surgem dois assuntos:

  • Brotherhood

  • Conqueror of Shamballa

E Milos?

Muitas vezes é esquecido.

O que é uma injustiça.

Porque este filme entrega uma das aventuras mais clássicas da franquia.

É praticamente um grande arco de exploração transformado em longa-metragem.


Onde o Filme se Encaixa?

Uma dúvida comum.

Milos não é continuação.

Milos não é prequel.

Milos não é linha temporal alternativa.

A história acontece durante os eventos de Brotherhood.

Pode ser visto como uma missão paralela.

Algo semelhante a um projeto especial executado enquanto o sistema principal continua processando normalmente.


A Grande Sinopse

Tudo começa quando um misterioso prisioneiro escapa da prisão central de Amestris.

Edward e Alphonse iniciam uma perseguição.

A investigação os leva até a região de Milos.

Uma área montanhosa localizada entre nações rivais.

Ali eles descobrem uma população explorada, conflitos políticos, segredos históricos e uma poderosa fonte de energia ligada à alquimia.

O que parecia um simples incidente de segurança rapidamente se transforma em uma crise internacional.


A História

Milos é uma região ocupada por potências estrangeiras.

Seu povo perdeu autonomia.

Recursos naturais são explorados.

A cultura local está desaparecendo.

A população vive entre revoltas e repressão.

Em outras palavras:

Um ambiente inteiro funcionando sob administração externa.

O filme utiliza esse cenário para construir uma narrativa sobre identidade nacional e autodeterminação.


Os Personagens Principais

Edward Elric

Aqui ele está em seu modo clássico.

Impulsivo.

Corajoso.

Teimoso.

Mas também extremamente humano.

O filme aproveita bem sua capacidade de inspirar pessoas.


Alphonse Elric

Continua sendo a consciência moral da dupla.

Em vários momentos é ele quem percebe os riscos das decisões mais radicais.


Julia Crichton

A verdadeira protagonista emocional do filme.

Sua jornada envolve:

  • vingança

  • esperança

  • identidade

  • responsabilidade

Ela carrega grande parte da carga dramática da história.


Ashleigh Crichton

Um dos personagens mais interessantes.

Representa o velho dilema:

O fim justifica os meios?

Questão que aparece constantemente em Fullmetal Alchemist.


O Que Torna Milos Diferente?

Aqui encontramos uma diferença importante.

Brotherhood é uma grande conspiração nacional.

Milos é um conflito regional.

A escala é menor.

Mas justamente por isso se torna mais pessoal.


Menos Filosofia Cósmica

Não existe um plano para remodelar a humanidade.

Não existe uma entidade quase divina manipulando tudo.


Mais Política

O foco está em:

  • ocupação territorial

  • identidade cultural

  • independência

  • exploração econômica

Temas surpreendentemente maduros para um filme shounen.


Mais Aventura

Milos possui ritmo acelerado.

Perseguições.

Combates.

Fugas.

Exploração de ruínas.

Viagens por montanhas.

É um dos filmes mais "aventureiros" da franquia.


A Temática Central

Quem Tem Direito ao Próprio Destino?

Essa é a pergunta principal.

O povo de Milos deseja controlar sua própria história.

Mas isso exige enfrentar poderes muito maiores.

A questão lembra diversos conflitos históricos reais.


O Perigo do Nacionalismo Extremado

O filme toma cuidado para não romantizar nenhum lado.

Ele mostra que tanto dominadores quanto revolucionários podem cometer abusos.


O Legado dos Antepassados

Outra mensagem forte.

Muitos personagens vivem presos às decisões de gerações anteriores.

Algo extremamente comum em Fullmetal Alchemist.


As Aventuras

O filme funciona quase como um RPG clássico.

Os irmãos:

  • investigam conspirações

  • atravessam fronteiras

  • exploram ruínas antigas

  • enfrentam soldados

  • descobrem tecnologias esquecidas

  • desvendam segredos históricos

Tudo isso mantendo o clima característico da franquia.


As Mensagens Ocultas

Poder Não Resolve Tudo

Diversos personagens acreditam que uma força extraordinária resolverá seus problemas.

O filme mostra exatamente o contrário.


Liberdade Tem Custo

Milos demonstra que independência exige sacrifícios.

Não existe solução simples.


Heróis Não São Salvadores

Edward não chega para resolver todos os problemas.

Ele ajuda.

Mas a transformação verdadeira precisa partir dos próprios habitantes.

Essa é uma mensagem extremamente madura.


A Qualidade Técnica

Visualmente o filme impressiona.

O Studio Bones investiu pesado.

As cenas de ação possuem:

  • animação fluida

  • efeitos de alquimia detalhados

  • excelente direção de câmera

  • design de cenário muito rico

Alguns fãs consideram certas sequências superiores às vistas na série de TV.


Houve Censura?

Pouca.

O filme foi lançado em uma época em que a franquia já possuía reconhecimento internacional.

As principais adaptações ocorreram em algumas distribuições locais envolvendo:

  • violência

  • sangue

  • cenas de execução

  • temas políticos sensíveis

Mas o conteúdo principal permaneceu intacto.


Impacto Cultural

Embora não tenha alcançado a fama de Brotherhood, Milos consolidou a força da marca Fullmetal Alchemist.

O filme mostrou que o universo criado por Hiromu Arakawa era rico o suficiente para sustentar histórias paralelas relevantes.

Com o tempo, muitos fãs passaram a reavaliá-lo de forma mais positiva.


Curiosidades Interessantes

Hiromu Arakawa Participou do Projeto

A autora colaborou com conceitos e supervisão.


É o Único Grande Filme Ligado Diretamente à Era Brotherhood

Por isso ocupa um lugar especial dentro da franquia.


O Design de Milos Foi Inspirado em Regiões Europeias

Especialmente áreas montanhosas e territórios historicamente disputados.


Veredito Bellacosa Mainframe

Se Brotherhood é o sistema corporativo principal...

E Shamballa é a migração entre ambientes incompatíveis...

Sacred Star of Milos é o projeto esquecido que revelou uma filial inteira operando fora das políticas centrais de governança.

É uma história sobre povos tentando recuperar controle sobre o próprio destino.

Sobre heranças históricas.

Sobre exploração.

Sobre liberdade.

E sobre o perigo de acreditar que existe uma tecnologia capaz de resolver problemas humanos complexos.

A grande lição permanece extremamente atual:

☕💣 "Nem toda crise é técnica."

🦅⚙️ "Às vezes o sistema funciona exatamente como foi projetado. O problema é que o projeto era injusto desde o início."

E é justamente essa reflexão que transforma The Sacred Star of Milos em muito mais do que um simples filme derivado: ele é um estudo sobre poder, identidade e a eterna busca por autonomia.


sábado, 8 de janeiro de 2011

🔥 JCL no z/OS V1R1 — quando o “antigo” ganhou sobrenome moderno

 

Bellacosa Mainframe apresenta JCL Job Control Language


🔥 JCL no z/OS V1R1 — quando o “antigo” ganhou sobrenome moderno



📅 Datas importantes

  • Release (GA): outubro de 2000

  • Final de suporte (EoS/EoM): entre 2004 e 2005 (dependendo do nível de suporte IBM e migração para V1R2+)

O z/OS V1R1 marcou oficialmente a transição do OS/390 para z/OS, e o JCL veio junto — o mesmo DNA dos anos 60, agora rodando num sistema “novo em folha”.


🧬 Contexto histórico

Quando a IBM lançou o z/OS V1R1, o JCL já era um veterano respeitado. Ele não nasceu no z/OS — nasceu lá atrás, no OS/360 (1964) — mas sobreviveu a tudo: MVT, MVS, ESA, OS/390… e chegou ao z/OS sem pedir licença.

O que muda aqui não é a linguagem, mas o ambiente, o poder da máquina, a integração com UNIX System Services, TCP/IP nativo e workloads híbridos.

👉 Moral da história:

“Troca o sistema, troca o nome, troca o marketing… mas o JCL continua mandando no turno da noite.”


JCL V1R1

✨ O que há de “novo” no JCL do z/OS V1R1

Tecnicamente, o JCL é compatível para trás, mas o z/OS V1R1 trouxe melhorias indiretas importantes:

🆕 1. Integração total com o z/OS

  • JCL agora orquestra:

    • Batch tradicional

    • Utilitários do DFSMS

    • Programas que acessam USS (OMVS)

    • Processos ligados a TCP/IP e middleware

🆕 2. JES2/JES3 mais maduros

  • Melhor gerenciamento de:

    • Spool

    • Classes

    • Prioridades

    • Restart de jobs

🆕 3. DFSMS mais forte

  • JCL passa a explorar melhor:

    • SMS-managed datasets

    • Storage Groups

    • Management Classes

    • Data Classes

👉 O JCL continua simples, mas o ecossistema ao redor ficou muito mais poderoso.


🔧 Melhorias e mudanças percebidas no dia a dia

✔ Melhor estabilidade no processamento batch
✔ Melhor convivência entre online (CICS) e batch
✔ Menos “abend misterioso” por problemas de storage
✔ Maior previsibilidade de execução noturna

Nada de comandos novos mirabolantes — o ganho foi operacional.


🥚 Easter Eggs (para mainframer raiz)

  • 🥚 JCL que funcionava no OS/390 funcionava igual no z/OS V1R1
    Isso facilitou migrações gigantes sem reescrever milhares de jobs.

  • 🥚 Muitos shops migraram para z/OS sem mudar uma linha de JCL
    Só recompilaram programas e ajustaram SMS.

  • 🥚 O //STEPLIB DD * continuava sendo usado… mesmo sendo má prática 😅


💡 Dicas Bellacosa para quem viveu (ou estuda) essa época

🔹 Aprenda JCL como linguagem de orquestração, não só como “script batch”
🔹 Entenda bem:

  • DISP

  • SPACE

  • UNIT

  • COND vs IF/THEN/ELSE
    🔹 Leia syslog e JESMSGLG como quem lê log de produção moderna
    🔹 Lembre-se:

JCL errado não falha — ele executa errado.


📈 Evolução a partir do V1R1

Depois do z/OS V1R1, o JCL seguiu firme:

  • V1R3+ → IF/THEN/ELSE mais usado

  • V1R6+ → Melhor integração com ferramentas modernas

  • V2.x → JCL convivendo com DevOps, schedulers e automação

Mas a base?
👉 Exatamente a mesma.


📜 Exemplo clássico de JCL (estilo raiz)

//BELLJOB  JOB (ACCT),'BELLACOSA',CLASS=A,MSGCLASS=X
//STEP01   EXEC PGM=IEFBR14
//OUTFILE  DD  DSN=BELLACOSA.TESTE.JCL,
//             DISP=(NEW,CATLG,DELETE),
//             SPACE=(TRK,(1,1)),
//             UNIT=SYSDA

💬 Comentário Bellacosa:

“Se você entende esse JCL, você entende 70% do batch do mainframe.”


🧑‍🔧O que é DFSMS?

Na verdade, o DFSMS (Data Facility Storage Management Subsystem) não é apenas um utilitário único, mas sim uma suíte poderosa de componentes da IBM para o ambiente z/OS.

Em termos simples: ele é o "gerente de logística" do seu mainframe. Ele automatiza e centraliza a gestão de onde os dados são gravados, por quanto tempo ficam guardados e como são protegidos.


Os 4 Pilares do DFSMS

Para entender o DFSMS no dia a dia do JCL, é preciso conhecer seus principais componentes:

  1. DFSMSdfp (Data Facility Product): O coração do sistema. Gerencia o acesso aos dados e a movimentação básica. É aqui que mora o famoso utilitário IDCAMS.

  2. DFSMSdss (Data Sets Services): Focado em cópia, movimentação e backup de alta performance. O programa principal chamado via JCL é o ADRDSSU.

  3. DFSMShsm (Hierarchical Storage Manager): Responsável por "limpar a casa". Ele migra dados pouco usados para mídias mais baratas (como fita ou discos lentos) e faz o backup automático.

  4. DFSMSrmm (Removable Media Manager): Gerencia suas fitas (físicas ou virtuais), controlando quem pode usá-las e quando podem ser apagadas.


Como ele aparece no seu JCL?

No passado, você precisava dizer exatamente em qual disco (UNIT e VOL=SER) seu arquivo deveria morar. Com o DFSMS (especificamente o componente SMS), o sistema faz isso sozinho através de três parâmetros principais no comando DD:

  • DATACLAS (Data Class): Define os atributos físicos (organização, formato de registro, tamanho).

  • STORCLAS (Storage Class): Define o nível de serviço (em qual disco ele vai morar, se precisa ser um disco rápido ou SSD).

  • MGMTCLAS (Management Class): Define o "prazo de validade" (quando o HSM deve deletar ou migrar o arquivo para fita).

Exemplo de DD com SMS:

Snippet de código
//ARQUIVO  DD DSN=USER.TESTE.DADOS,
//            DISP=(NEW,CATLG,DELETE),
//            DATACLAS=DCPADRAO,
//            STORCLAS=SCFAST,
//            MGMTCLAS=MGT030D

🛠️ Principais Utilitários que você usará

Se você está procurando o "programa" para rodar, os mais comuns vinculados ao DFSMS são:

UtilitárioPara que serve?
IDCAMSCriar, deletar, listar e gerenciar VSAM e catálogos.
ADRDSSUCopiar volumes inteiros ou datasets específicos em alta velocidade.
IEBCOPY(Gerenciado pelo DFP) para copiar e comprimir bibliotecas (PDS/PDSE).

🧠 Comentário final

O JCL no z/OS V1R1 prova uma verdade que todo mainframer aprende cedo:

Tecnologia boa não morre — ela evolui sem fazer barulho.

Enquanto linguagens vêm e vão, o JCL segue lá, silencioso, confiável, rodando milhões de jobs por noite…
…e garantindo que o mundo acorde com banco, energia, avião e folha de pagamento funcionando.

🔥 Longa vida ao JCL.


Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...