☕ 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

sexta-feira, 13 de janeiro de 2012

Framing Effect: Doctor Who, COBOL e o Dia em que 90% de Sucesso Pareceu Muito Melhor que 10% de Falha

 

Bellacosa Mainframe e o framing effect

☕ Um Café no Bellacosa Mainframe

Framing Effect: Doctor Who, COBOL e o Dia em que 90% de Sucesso Pareceu Muito Melhor que 10% de Falha

Uma viagem pela TARDIS dos incidentes para entender por que a mesma informação pode provocar decisões diferentes dependendo apenas da forma como é apresentada

09:03.

Segunda-feira.

Sala de mudança.

Projetor ligado.

Café ainda quente.

Na tela:

PROPOSTA DE MUDANÇA

PROBABILIDADE DE SUCESSO:
90%

O gerente olha.

— Parece ótimo.

O especialista concorda.

— Noventa por cento é bastante alto.

Nosso jovem programador COBOL anota.

Pouco depois, outra pessoa apresenta exatamente o mesmo estudo.

Mas o slide agora diz:

PROPOSTA DE MUDANÇA

PROBABILIDADE DE FALHA:
10%

O clima muda.

O gerente franze a testa.

— Dez por cento de falha?

O especialista cruza os braços.

— Talvez seja arriscado demais.

Nosso programador olha para a primeira tela.

Depois para a segunda.

Volta a calcular mentalmente.

90% de sucesso.

10% de falha.

A mesma coisa.

Ele levanta a mão.

— Desculpe... mudou alguma coisa nos dados?

— Não.

— Então por que agora parece mais perigoso?

Silêncio.

VWORP.

VWORP.

VWORP.

A TARDIS materializa-se ao lado do projetor.

A porta abre.

O Doctor sai.

Olha para as duas telas.

Depois para o gerente.

— Qual versão prefere?

— A de 90% de sucesso.

— Por quê?

— Parece mais segura.

— E matematicamente?

— É igual.

O Doctor sorri.

— Ah.

Pausa.

— Então vocês não estão reagindo apenas aos números.

Aponta para o projetor.

— Estão reagindo à moldura.

Bem-vindo ao:



Framing Effect

Ou:

Efeito de Enquadramento

A tendência de tomar decisões diferentes diante da mesma informação dependendo da forma como essa informação é apresentada.

Em linguagem Bellacosa:

10% de falha e 90% de sucesso podem ser matematicamente iguais — mas não parecem iguais para o cérebro.


🌀 Nossa TARDIS dos incidentes já conhece uma bela coleção

Até aqui vimos:

Swiss Cheese Model — várias barreiras podem falhar juntas.

Normalization of Deviance — desvios viram rotina.

Hindsight Bias — depois do desastre tudo parece óbvio.

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

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

Groupthink — grupos podem convergir cedo demais.

Authority Gradient — hierarquia pode silenciar quem percebe risco.

Plan Continuation Bias — continuamos planos que perderam sentido.

Alarm Fatigue — alertas demais deixam de ser ouvidos.

Automation Bias — confiamos demais na máquina.

Drift Into Failure — sistemas derivam lentamente para a borda.

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

Normalcy Bias — esperamos que tudo volte ao normal.

Survivorship Bias — estudamos apenas quem sobreviveu.

Base Rate Neglect — esquecemos frequências reais.

Availability Heuristic — aquilo que lembramos facilmente parece mais provável.

Outcome Bias — resultado bom parece provar decisão boa.

Overconfidence Bias — acreditamos saber mais do que realmente sabemos.

Planning Fallacy — subestimamos tempo e complexidade.

Sunk Cost Fallacy — investimentos passados prendem decisões futuras.

Status Quo Bias — o atual parece mais seguro porque já existe.

Present Bias — o conforto de hoje vence o custo de amanhã.

Optimism Bias — acreditamos que o resultado provavelmente será favorável para nós.

Action Bias — agir parece melhor que esperar.

Omission Bias — não agir pode parecer menos culpável que agir.

Loss Aversion — perder dói mais do que ganhar alegra.

Agora chegamos a um viés que conversa fortemente com quase todos eles:

a maneira como contamos a história altera a maneira como sentimos o risco.


🧠 O que é Framing Effect?

Imagine duas frases:

Frame A

“Este tratamento salva 90 de cada 100 pessoas.”

Frame B

“Este tratamento falha em 10 de cada 100 pessoas.”

Mesmos números.

Mas as reações podem ser diferentes.

Por quê?

Porque nossa mente não processa apenas:

quantidade.

Ela processa também:

palavras;

referências;

ganho;

perda;

ameaça;

segurança.

A informação nunca chega completamente neutra.

Ela chega dentro de uma moldura.


🖼️ Frame é literalmente uma moldura

Pense numa fotografia.

A imagem é a mesma.

Mas a moldura pode destacar:

beleza;

melancolia;

perigo;

nostalgia.

Na comunicação operacional:

99,5% DISPONIBILIDADE

soa excelente.

Agora:

3h39 DE INDISPONIBILIDADE POR MÊS

Talvez pareça diferente.

Os dados podem representar aproximadamente a mesma realidade.

Mas o significado percebido muda.


☕ Bellacosa Mainframe: disponibilidade

Gerente recebe:

AVAILABILITY:
99.9%

— Excelente!

Nosso programador converte.

Aproximadamente:

~43 minutos de indisponibilidade/mês

Agora negócio pergunta:

— Quarenta e três minutos?

Se cada minuto interromper liquidação financeira crítica, a moldura muda completamente.

Nem:

99,9%

nem:

43 minutos

está errado.

Mas cada frame mostra um aspecto diferente.


🧠 Percentuais escondem pessoas

Imagine:

ERROR RATE:
0.1%

Parece pequeno.

Mas sistema processa:

10 milhões de transações.

Então:

10.000 transações com erro

De repente 0,1% ganhou rosto.

Isso é importante:

uma porcentagem pequena pode esconder um número absoluto enorme.


🎯 Regra Bellacosa nº 1

Sempre que alguém apresentar percentual:

pergunte pelo número absoluto.

E vice-versa.


👻 Easter Egg nº 1 — os Daleks e a estatística

Companion:

— Doctor, só 0,5% das pessoas estão em risco.

Doctor:

— Quantas pessoas existem no planeta?

— Oito bilhões.

Silêncio.

— Ah.

O percentual ficou pequeno.

O problema não.


🧠 Gain Frame versus Loss Frame

Um dos enquadramentos mais poderosos é:

ganho versus perda.

Exemplo:

Ganho

“Se fizermos a modernização, economizaremos R$ 3 milhões.”

Perda

“Se não modernizarmos, perderemos R$ 3 milhões.”

Mesma magnitude.

Mas Loss Aversion nos ensinou:

perdas tendem a pesar mais.

Logo, o segundo frame pode gerar reação mais forte.


🧠 Framing Effect + Loss Aversion

Essa combinação é fundamental.

Se eu digo:

“Você pode ganhar R$ 1 milhão.”

é uma oportunidade.

Se digo:

“Você pode evitar perder R$ 1 milhão.”

parece urgência.

Mesmo valor.

Em comunicação corporativa:

quem escolhe o frame pode influenciar decisão.


☕ Segurança

Compare:

“O patch reduz o risco em 80%.”

versus:

“Se não aplicarmos, permanecemos expostos a 20% do risco.”

A percepção muda.

Por isso profissionais precisam desconfiar não apenas dos dados...

mas da forma de apresentá-los.


🧠 Framing não é necessariamente manipulação

Importante.

Toda informação precisa ser apresentada de algum modo.

Não existe relatório completamente sem frame.

Escolher:

percentual;

valor absoluto;

tempo;

frequência

já cria contexto.

O problema não é enquadrar.

O problema é:

esconder que existe enquadramento.


📊 Bons relatórios mostram múltiplos frames

Em vez de:

SUCCESS RATE: 99.8%

mostre:

SUCCESS RATE: 99.8%

FAILED TRANSACTIONS:
20.000 / 10.000.000

BUSINESS IMPACT:
R$ X

Agora decisão fica mais rica.


🧠 Dashboard é uma máquina de framing

Isso é fascinante.

Dashboard não apenas mostra dados.

Ele decide:

  • o que entra;

  • o que não entra;

  • qual cor;

  • qual escala;

  • qual período;

  • qual agregação.

Tudo isso cria frame.


📈 Escala do gráfico engana

Imagine duas séries.

Valor sobe de:

90 para 95.

Gráfico A começa em zero.

Parece pequena mudança.

Gráfico B começa em 89.

Parece uma explosão.

Mesmos dados.

Moldura visual diferente.


☕ Bellacosa Mainframe: gráfico assustador

War Room.

Dashboard:

CPU

94%
95%
96%

Eixo:

93–97%.

Linha parece subir como foguete.

Gerente:

— Estamos explodindo!

Outro gráfico:

0–100%.

Agora parece quase estável.

Nenhum gráfico é necessariamente mentira.

Mas cada um cria sensação diferente.


🧠 Sempre cheque o eixo

Uma das melhores dicas básicas:

Antes de interpretar um gráfico, leia os eixos.

Especialmente:

baseline;

intervalo;

período.


⏱️ Janela temporal também é frame

CPU hoje:

95%.

Últimos 5 minutos:

crescendo.

Últimas 24 horas:

normal para horário.

Últimos 6 meses:

tendência preocupante.

Qual é a verdade?

Todas podem ser.

A pergunta é:

qual janela responde à decisão que precisamos tomar?


🧠 Availability Heuristic + framing temporal

Se dashboard mostra só última hora:

evento recente domina.

Se mostra 30 dias:

padrão histórico domina.

A interface pode alimentar Availability Heuristic.


⚓ Anchoring Bias + Framing

Primeiro slide:

“Projeto economizará R$ 10 milhões.”

Pronto.

R$ 10 milhões vira âncora.

Depois aparecem:

custos;

riscos;

dependências.

Mas toda discussão gira em torno do primeiro frame.

A ordem da apresentação importa.


👥 Groupthink

Diretor apresenta:

“Temos 95% de chance de sucesso.”

Sala concorda.

Se tivesse dito:

“Temos 1 chance em 20 de falhar.”

talvez perguntas aparecessem.

O frame do líder influencia clima coletivo.


🪜 Authority Gradient

Frame vindo de autoridade ganha força extra.

Consultor:

“Migração tem 90% de sucesso.”

Júnior pensa:

“Mas 10% de falha parece alto.”

Não fala.

Authority Gradient protege o frame inicial.


🤖 Automation Bias

Dashboard IA:

SYSTEM HEALTH:
97/100

Usuário:

— Excelente.

Mas o que significa 97?

Talvez:

CPU;

memória;

rede.

Não inclui:

reconciliação financeira.

O score produz frame de saúde.

Automation Bias transforma em realidade.


🧠 Composite Scores são perigosos

Uma única nota:

HEALTH = 92

é confortável.

Mas esconde componentes.

Talvez:

CPU: 99
NETWORK: 99
DB2: 98
DATA INTEGRITY: 20

Média ainda pode parecer boa.

Mas integridade está pegando fogo.


☕ Média é frame

Outro clássico.

Salário médio.

Tempo médio.

Latência média.

Média pode esconder distribuição.

Se:

99% das transações = 50ms

1% = 30 segundos

latência média talvez pareça aceitável.

Clientes no 1% discordam.


📊 Percentis

P50.

P95.

P99.

Eles mudam frame.

Para operações:

P99 frequentemente conta história que média esconde.


🧠 Framing Effect + Base Rate Neglect

Um alerta diz:

“95% accuracy.”

Parece maravilhoso.

Mas Base Rate Neglect pergunta:

qual prevalência?

Framing Effect pergunta:

por que escolheram accuracy?

Talvez precision seja 20%.

Escolher a métrica certa também é enquadramento.


🔐 Segurança e estatísticas

Fornecedor:

“Bloqueamos 99,9% dos ataques.”

Quantos ataques?

Como classificados?

Quantos falsos negativos?

Qual impacto dos 0,1%?

O frame “99,9% bloqueado” pode esconder justamente o risco mais importante.


🧠 Marketing adora framing

Natural.

Produto:

“Até 80% mais rápido.”

Pergunta:

em quê?

contra quê?

em qual cenário?

Framework comercial escolhe frame mais favorável.

Engenharia precisa converter promessa em condição testável.


☕ “Até”

Uma palavrinha mágica.

“Até 80%.”

Pode significar:

1% em muitos casos;

80% em um caso.

Leia com café.


🧠 Framing Effect + Optimism Bias

Apresente:

“90% de sucesso.”

Optimism Bias diz:

estaremos nos 90%.

Apresente:

“10% de falha.”

Agora talvez Loss Aversion domine.

O mesmo indivíduo pode mudar de posição.


🎯 Pergunta Bellacosa nº 2

Quando alguém apresenta uma decisão:

“Como essa mesma informação seria apresentada pelo lado oposto?”

Exemplo:

90% sucesso.

Pergunte:

10% falha.

Economia R$ 3M.

Pergunte:

custo de não agir R$ 3M.


🧠 Reframing

Essa técnica é extremamente útil.

Pegue a mesma decisão e mude a moldura conscientemente.

Isso ajuda a detectar se nossa preferência depende demais da linguagem.


💻 COBOL: defect rate

Equipe apresenta:

TEST PASS RATE: 98%

Gerente:

— Excelente.

Nosso programador pergunta:

— Quantos falharam?

2% de 15.000 testes
=
300 falhas

Agora precisamos saber:

quais 300?

Se incluem pagamento e reconciliação:

98% talvez não seja confortável.


🧠 Nem todo teste pesa igual

Outra armadilha de framing.

999 testes cosméticos passam.

1 teste de integridade financeira falha.

Success rate:

99,9%.

Excelente?

Não.

A severidade precisa entrar.


📊 Weighted Risk

Em sistemas críticos:

não conte apenas quantidades.

Considere:

impacto;

criticidade.

Uma falha crítica pode pesar mais que cem pequenos sucessos.


🧀 Swiss Cheese + Framing

Imagine relatório:

“5 de 6 barreiras funcionaram.”

Parece ótimo.

Mas a sexta era:

última proteção contra perda de dados.

Então:

5/6

pode ser um frame enganoso.

Pergunta:

qual barreira falhou?


🧠 Outcome Bias

Resultado:

bom.

Frame:

“Mudança bem-sucedida.”

Mas houve:

near miss;

intervenção manual;

rollback parcial.

Talvez sucesso seja frame superficial.

Uma classificação binária:

SUCCESS / FAILURE

pode apagar complexidade.


☕ “Green” é um frame poderoso

Dashboard verde.

Mas:

green de quê?

Disponibilidade?

SLA?

Integridade?

Cliente?

Um sistema pode estar tecnicamente verde e comercialmente vermelho.


🧠 Technical Green vs Business Red

Exemplo:

CICS: GREEN
DB2: GREEN
MQ: GREEN
JOB: RC=00

Cliente:

pagamento duplicado.

Excelente exemplo de frame técnico incompleto.


🌀 Drift Into Failure e framing

Indicadores ainda dentro de limites.

Dashboard:

GREEN.

Mas margem:

40% → 30% → 20% → 10%

Se frame mostra apenas:

“dentro do threshold”,

o drift desaparece.

Tendência precisa aparecer.


📈 Threshold frame versus trend frame

Frame 1:

CPU < 95%, tudo bem.

Frame 2:

CPU cresceu de 60 para 94 em três meses.

Muito diferente.

Mesma CPU atual.


🧠 Status Quo Bias + framing

Descrever mudança como:

“substituir o sistema atual”

ativa sensação de perda.

Descrever como:

“evoluir gradualmente a arquitetura”

pode reduzir resistência.

Isso pode ser comunicação legítima...

ou manipulação.

A diferença:

transparência.


☕ Palavras carregam frame

“Legacy.”

Pode soar:

ruim.

“Mission-critical platform.”

Pode soar:

valioso.

Talvez estejam descrevendo a mesma coisa.

Engenharia precisa escapar dos rótulos.


🧠 Legacy framing

Fornecedor querendo vender:

“Sistema legado obsoleto.”

Equipe interna:

“Plataforma madura e comprovada.”

Qual é?

Talvez:

algumas partes maduras;

outras obsoletas.

Rótulo binário esconde análise.


🎯 Pergunta Bellacosa nº 3

“Se removermos os adjetivos, quais fatos permanecem?”

Excelente contra framing emocional.


🧪 Exemplo

Em vez de:

“Sistema legado antiquado.”

Use:

IDADE: 28 anos
DISPONIBILIDADE: 99,99%
CUSTO: X
SKILLS: Y
CHANGE LEAD TIME: Z
SECURITY SUPPORT: OK

Agora decida.


🧠 Sunk Cost Fallacy + framing

Projeto:

“Cancelar significa perder R$ 10M.”

Frame alternativo:

“Continuar exige investir mais R$ 7M.”

Ambos relevantes.

Mas o primeiro ativa Loss Aversion.

O segundo olha para cost-to-go.

Decisão muda.


☕ “Perder investimento” versus “evitar investimento ruim”

Mesma realidade.

Frame radicalmente diferente.

Por isso Sunk Cost adora linguagem.


🧠 Present Bias + framing

“Refactor custa 40 horas.”

Frame imediato.

Alternativa:

“Sem refactor gastaremos 10 horas/mês.”

Agora futuro fica visível.

40 horas parece grande.

120 horas/ano parece maior.


🧠 Planning Fallacy + framing

Projeto apresentado como:

“Só três módulos.”

Parece pequeno.

Outro frame:

“Três módulos, 17 interfaces, 11 datasets, 2 sistemas externos.”

Mesma mudança.

Muito mais realista.


☕ A palavra “só”

Já falamos dela.

“Só alterar um campo.”

“Só uma tabela.”

“Só um restart.”

“Só 10%.”

Palavras pequenas criam frames perigosos.


🧠 Action Bias e framing de urgência

War Room:

“Sistema está falhando!”

Action Bias.

Outro frame:

“Failure rate está em 1,2%, baseline 0,8%, tendência estável.”

Ainda merece atenção.

Mas talvez não restart imediato.

Precisão reduz frame emocional.


🧠 Omission Bias e framing

“Se fizermos rollback, perderemos uma hora.”

Dói.

Outro:

“Se não fizermos rollback, podemos perder quatro horas e integridade de dados.”

Agora comparação melhora.


🔥 Risk Communication

Em incidentes, comunicação precisa equilibrar:

clareza;

urgência;

precisão.

Evite:

“Tudo quebrado!”

Mas também:

“Pequena instabilidade”

quando 40% falha.

Linguagem inadequada distorce decisão.


☕ Eufemismos operacionais

“Intermitência.”

“Degradação.”

“Comportamento inesperado.”

Às vezes correto.

Às vezes:

produção pegando fogo com dicionário corporativo.


🧠 Framing e incident severity

Severity 1 versus “degradação significativa”.

O label muda comportamento.

Se sistema de classificação é ruim:

o frame institucional pode atrasar resposta.


📢 Comunicação executiva

Executivos precisam frame resumido.

Mas cuidado para não resumir demais.

Melhor:

IMPACT:
12% das transações de pagamento falhando

TREND:
piorando

CUSTOMERS:
~18k afetados

CURRENT ACTION:
traffic reduced

NEXT DECISION:
rollback em 10 min se >15%

Isso é um frame útil.


🧠 Framing não é só linguagem — é seleção

O que você omite também enquadra.

Relatório mostra:

sucessos.

Não mostra:

near misses.

Survivorship Bias + Framing.


📊 Dashboard greenwashing

Não precisa haver má intenção.

Um dashboard pode selecionar métricas que mostram saúde.

Porque foram as métricas históricas.

Enquanto novas fragilidades surgiram.

Drift + frame antigo.


🧠 Metric Framing

Taxa:

ERROR RATE: 0.01%

Número absoluto:

1.000 clientes/dia.

Tempo:

30.000 clientes/mês.

Cada representação cria impacto diferente.

Mostre as três quando importa.


🎯 Pergunta Bellacosa nº 4

“Qual versão da métrica faz o risco parecer menor? Qual faz parecer maior?”

Depois procure a visão equilibrada.


🧪 Natural Frequencies

Base Rate Neglect volta.

Em vez de:

“0,1%.”

Diga:

“1 em cada 1.000.”

Muitas pessoas entendem melhor.

Ou:

“1.000 casos em 1 milhão.”

Natural frequencies são úteis.


🧠 1 em 100 soa diferente de 1%

Mesmo sendo igual.

Exatamente o tema.

Por isso devemos conhecer o efeito.


🔐 Risk framing

“99% seguro.”

Parece ótimo.

“1 em 100 casos falha.”

Talvez não.

Em escala:

milhões de transações.

Contexto decide.


🧠 Positive Frame versus Negative Frame

Exemplo de projeto:

Positivo

“Temos 80% de chance de terminar no prazo.”

Negativo

“1 em cada 5 cenários atrasa.”

Mesma previsão.

Uma boa governança deveria analisar ambos.


👥 Steering Committee

Um sponsor pode escolher frame que favorece aprovação.

Talvez inconscientemente.

“80% sucesso.”

Uma equipe de risco pode escolher:

“20% falha.”

Ambos podem exagerar emocionalmente.

Resposta:

mostrar os dois.


🧠 Adversarial Reframing

Uma técnica excelente:

alguém apresenta decisão.

Outra pessoa precisa reformulá-la no frame oposto sem alterar fatos.

Exemplo:

“Economia de R$5M.”

Reframe:

“Não executar custa R$5M adicionais.”

Ou:

“10% risco.”

Reframe:

“90% não apresenta esse risco.”

Depois discuta.


☕ Bellacosa Two-Sided Slide

Todo slide de decisão importante poderia ter:

FRAME A:
GANHO

FRAME B:
PERDA

DADOS ABSOLUTOS

DADOS RELATIVOS

RISCO

Isso reduz persuasão acidental.


🧠 Framing Effect e IA

Agora fica especialmente interessante.

Você pergunta à IA:

“Explique por que esta migração é uma boa ideia.”

Ela busca argumentos favoráveis.

Pergunte:

“Explique por que esta migração é perigosa.”

Ela produz outro frame.

Mesmos fatos podem gerar narrativas distintas.


🤖 Prompt framing

O próprio prompt enquadra resposta.

“Quais benefícios?”

versus:

“Quais riscos?”

Isso não é bug.

É contexto.

Mas usuário precisa saber.


🎯 Pergunta Bellacosa para IA

“Agora reavalie a mesma decisão pelo frame oposto.”

Excelente hábito.

Depois:

“Quais fatos permanecem verdadeiros nos dois frames?”

Esses fatos são ouro.


🧠 Confirmation Bias + Prompt Framing

Usuário já acredita em X.

Pergunta à IA:

“Por que X é melhor?”

Recebe resposta.

Confirmation Bias ganha reforço tecnológico.

Melhor:

Argumente a favor.
Argumente contra.
Liste premissas.
Identifique dados faltantes.

🧠 Automation Bias

Resposta elegante da IA pode fazer frame parecer objetivo.

Não é necessariamente.

Toda síntese escolhe prioridade.

IA também produz enquadramento.


📋 Checklist anti-Framing Effect

[ ] A informação está em ganho ou perda?

[ ] Qual é o frame oposto?

[ ] Temos números absolutos e percentuais?

[ ] Qual é o denominador?

[ ] O período analisado está claro?

[ ] O eixo do gráfico começa onde?

[ ] Estamos usando média ou distribuição?

[ ] Existe tendência escondida pelo threshold?

[ ] Há métricas importantes fora do dashboard?

[ ] O título do slide já sugere conclusão?

[ ] Existem adjetivos desnecessários?

[ ] Como a decisão parece sem os adjetivos?

[ ] O mesmo dado foi apresentado sob dois frames?

[ ] O frame está ativando Loss Aversion?

[ ] Quem escolheu a forma de apresentação?

🧪 Como combater Framing Effect — passo a passo

Passo 1 — Identifique a moldura

Qual história está sendo contada?


Passo 2 — Reframe

Apresente o oposto.


Passo 3 — Use números absolutos e relativos

Sempre que possível.


Passo 4 — Mostre denominadores

10 falhas de quantas?


Passo 5 — Verifique período

Uma hora?

Um ano?


Passo 6 — Veja distribuição

Não apenas média.


Passo 7 — Retire linguagem emocional

Primeiro fatos.


Passo 8 — Mostre risco dos dois lados

Agir e não agir.


Passo 9 — Faça análise independente

Antes da narrativa executiva.


Passo 10 — Decida com critérios pré-definidos

Não com qual slide parece mais confortável.


🧠 Facts First

Antes do slide bonito:

FACTS:
- failure rate 10%
- 100k tx/day
- expected affected = 10k/day
- rollback 30min

Depois interpretação.

Isso ajuda.


☕ Não mate storytelling

Histórias são ótimas.

Bellacosa Mainframe inteiro é construído em histórias.

O problema não é storytelling.

É esquecer:

história é uma representação da realidade, não a realidade inteira.

Use histórias para ensinar.

Use dados para decidir.


🧠 Framing é inevitável

Esse é um ponto profundo.

Até dizer:

“Vamos mostrar apenas fatos.”

já exige selecionar fatos.

Logo, não existe neutralidade absoluta.

O objetivo é:

transparência e múltiplas perspectivas.


🧩 Same Facts, Different Questions

CPU 90%.

Pergunta 1:

estamos dentro da capacidade?

Sim.

Pergunta 2:

temos margem para Black Friday?

Talvez não.

O frame depende da pergunta.

Nem sempre um é “enganoso”.


🧠 Decision Context matters

Um mesmo número pode ser bom para:

operação normal.

Ruim para:

janela de crescimento.

Logo, frame correto precisa corresponder ao contexto decisório.


🎯 Pergunta Bellacosa nº 5

“Qual decisão estamos tentando tomar com este dado?”

Se ninguém sabe:

o dashboard talvez seja decoração.


📊 Information Design

Uma boa visualização deveria ajudar:

comparar;

detectar;

priorizar.

Não impressionar.

Em War Room:

clareza > beleza.

Embora beleza ajude.


☕ Sem velocímetro de avião em Comic Sans

Talvez uma regra universal.


🧠 Framing em post-mortem

Título:

“Erro humano causou outage.”

Frame criado.

Agora investigação procura pessoa.

Outro:

“Outage ocorreu durante processo manual vulnerável a erro.”

Mesma sequência.

Frame sistêmico.

A segunda abre mais possibilidades.


🔍 Blame Frame versus System Frame

Blame:

“Operador digitou errado.”

System:

“Uma única entrada manual não validada podia interromper serviço.”

Qual produz ação preventiva melhor?

Normalmente a segunda.


🧠 Just Culture

Framing afeta cultura.

Se incident reports enquadram:

pessoa como causa,

organização aprende:

“tenha mais cuidado.”

Se enquadram sistema:

aprende:

“como tornar erro menos provável e menos perigoso?”


🧀 Swiss Cheese volta

Uma pessoa errou.

Mas:

quantas barreiras existiam?

Se nenhuma:

frame “erro humano” é incompleto.

Swiss Cheese fornece frame mais rico.


🧠 Hindsight Bias

Depois:

“Era claramente arriscado.”

Mas se decisão original foi apresentada como:

“95% sucesso”,

talvez clima fosse diferente.

Post-mortem deve reconstruir o frame disponível na época.


📝 Preserve Original Decision Materials

Guarde:

slides;

dashboards;

mensagens;

estimativas.

Eles mostram como informação foi enquadrada.

Isso ajuda a entender decisões.


🌀 Drift Into Failure e relatórios verdes

Sistema deriva.

Mas relatório mensal:

SLA MET: YES

Todos verdes.

Frame:

saudável.

Enquanto:

margem cai.

intervenções sobem.

turnover aumenta.

Precisamos indicadores que mostrem trajetória.


📈 Leading + Lagging frames

Lagging:

incidentes.

Leading:

margem.

retries.

manual work.

Mostrar ambos evita frame otimista demais.


🧠 Loss Aversion + projetos

Projeto apresentado como:

“Se cancelarmos, perderemos R$ 20M.”

Reframe:

“Continuar exige arriscar outros R$ 10M para recuperar no máximo R$ 4M.”

Agora Sunk Cost fica visível.


🧠 Omission Bias + segurança

“Aplicar patch pode causar outage.”

Reframe:

“Não aplicar mantém vulnerabilidade conhecida por X dias.”

Agora risco da inação entra.


🧠 Action Bias + incidentes

“Precisamos agir agora.”

Reframe:

“Temos evidência suficiente para justificar intervenção agora?”

A linguagem muda comportamento.


🧠 Optimism Bias + planejamento

“Temos 85% de confiança.”

Reframe:

“Em 15 de cada 100 cenários semelhantes, falhamos.”

Talvez exija contingência.


☕ Essa série inteira é sobre reframing

Perceba.

Quase cada viés que estudamos pode ser combatido mudando a pergunta:

Hindsight:

“O que sabíamos antes?”

Sunk Cost:

“Vale gastar o próximo real?”

Status Quo:

“Qual o risco de não mudar?”

Present Bias:

“Quanto custa isso em um ano?”

Action Bias:

“Qual problema a ação resolve?”

Omission Bias:

“Qual custo de não agir?”

Loss Aversion:

“O que perdemos mantendo?”

Framing Effect é quase:

o capítulo sobre como as perguntas constroem o pensamento.


🧠 Perguntas são frames

Essa talvez seja a parte mais importante.

Pergunta:

“Quem errou?”

produz investigação.

Pergunta:

“Como o sistema permitiu o erro?”

produz outra.

Ambas podem ser válidas.

Mas levam a lugares diferentes.


🎯 O poder de uma boa pergunta

War Room madura não pergunta apenas:

“O que aconteceu?”

Também:

  • o que mudou?

  • qual baseline?

  • qual tendência?

  • o que não estamos vendo?

  • qual hipótese alternativa?

Cada pergunta muda frame.


🧪 Framing Drill

Treine equipes.

Pegue uma decisão.

Apresente:

Frame positivo.

Frame negativo.

Frame financeiro.

Frame técnico.

Frame cliente.

Pergunte:

a escolha mudou?

Se sim:

por quê?

Excelente exercício.


👥 Multi-perspective Review

Uma mudança pode ser vista por:

aplicação;

infra;

segurança;

negócio;

cliente.

Cada um possui frame parcial.

Combine.

Isso reduz cegueira.


🧠 Local Rationality

No Drift Into Failure vimos racionalidade local.

Cada equipe otimiza seu frame.

DBA:

banco verde.

MQ:

fila verde.

Negócio:

cliente falhando.

O sistema inteiro precisa de frame ponta a ponta.


☕ End-to-End Frame

Pergunta:

“O cliente conseguiu concluir a jornada?”

Às vezes essa métrica derrota uma sala cheia de dashboards verdes.


📓 Diário do Doctor

Se guardar algumas ideias desta viagem, guarde estas:

Framing Effect é a tendência de reagir de forma diferente à mesma informação dependendo da forma como ela é apresentada.

90% de sucesso e 10% de falha podem gerar emoções diferentes apesar de serem equivalentes.

Loss Aversion torna frames de perda especialmente poderosos.

Percentuais precisam de denominadores e números absolutos.

Médias podem esconder caudas.

Dashboards também enquadram a realidade.

Escalas, cores, períodos e métricas influenciam percepção.

Palavras como “legacy”, “seguro”, “instável” e “simples” já carregam frames.

Mostrar o frame oposto é uma defesa poderosa.

IA também responde ao enquadramento do prompt.

Em post-mortems, o frame escolhido pode direcionar culpa ou aprendizado sistêmico.

E principalmente:

Nunca pergunte apenas “o que os dados dizem?”. Pergunte também “como estamos escolhendo mostrá-los?”.


🕰️ De volta à reunião das 09:03

Primeiro slide:

90% SUCCESS

O gerente:

— Parece bom.

Nosso programador acrescenta:

10% FAILURE

A sala fica menos confortável.

Depois acrescenta:

10 EM CADA 100 MUDANÇAS

Depois:

HISTÓRICO:
2 incidentes graves em 20 mudanças

Depois:

ROLLBACK:
TESTADO

BLAST RADIUS:
LIMITADO

STOP TRIGGERS:
DEFINIDOS

Agora a discussão muda.

Não é:

“90% é bom?”

É:

“10% de risco é aceitável dadas as proteções existentes?”

Muito melhor.

O gerente pergunta:

— Então o risco mudou?

— Não.

— O que mudou?

Nosso jovem sorri.

— Nossa maneira de enxergá-lo.

O Doctor guarda o sonic screwdriver.

— Excelente.

— De novo essa palavra?

— Sim. É raro humanos perceberem a moldura antes de baterem o martelo.


🥚 Easter Egg final

Na manhã seguinte aparece:

BELLACOSA.BIAS(FRAME)

Dentro:

       IF FRAME = '90-PERCENT-SUCCESS'
           MOVE '10-PERCENT-FAILURE'
             TO ALTERNATIVE-FRAME
       END-IF.

       IF VALUE-IS-PERCENT
           PERFORM SHOW-ABSOLUTE-NUMBER
       END-IF.

       IF DECISION-CHANGES
          AFTER-ONLY-WORDING-CHANGES
           PERFORM REVIEW-BIAS
       END-IF.

Comentário:

* SAME DATA.
* DIFFERENT STORY.

Outro:

* ALWAYS CHECK THE DENOMINATOR.

Outro:

* GREEN IS A COLOR.
* NOT A ROOT CAUSE.

E naturalmente:

* BAD WOLF HAD A 90% SURVIVAL RATE.
* THE OTHER 10% WERE LESS ENTHUSIASTIC.

Nosso programador fecha o membro.

Pouco depois recebe um slide:

“99,8% dos processos concluídos com sucesso.”

Ele pergunta:

— Quantos processos?

— Dois milhões.

Calcula.

— Então quatro mil falharam.

Silêncio.

— Quatro mil?

— Sim.

— Parece muito pior assim.

Ele sorri.

— Os dados são os mesmos.

Pausa.

— Agora precisamos decidir qual representação responde melhor à pergunta que estamos fazendo.

Em algum lugar:

VWORP.

VWORP.

VWORP.

A TARDIS desaparece.

No quadro da War Room fica uma frase:

A realidade não muda quando mudamos as palavras. A decisão humana, infelizmente, pode mudar — e é por isso que bons engenheiros aprendem a olhar além da moldura.

☕🌀

Next stop: Recency Bias — quando aquilo que aconteceu ontem começa a pesar tanto que dez anos de histórico quase desaparecem da decisão de hoje.

quinta-feira, 12 de janeiro de 2012

IBM System/360: Licença para Compatibilidade : Quando um Programador COBOL Descobre que o Verdadeiro Agente Secreto da Computação Não Era James Bond...

 

Bellacosa Mainframe e o legado do ibm system 360

☕ Um Café no Bellacosa Mainframe

IBM System/360: Licença para Compatibilidade

Quando um Programador COBOL Descobre que o Verdadeiro Agente Secreto da Computação Não Era James Bond... Era um Computador Lançado em 1964

"Meu nome é System. IBM System/360."


Missão Recebida

Londres.

Quartel-General do MI6.

Ano de 1964.

James Bond entra na sala de reuniões imaginando que enfrentará mais um vilão tentando dominar o mundo.

"M" coloca sobre a mesa uma pasta marcada como:

TOP SECRET – PROJECT 360

Bond pergunta:

— Quem é o inimigo?

M responde calmamente:

— Desta vez não existe inimigo, 007...

Existe uma invenção.

Uma máquina tão revolucionária que mudará para sempre a maneira como o planeta trabalha, faz ciência, movimenta dinheiro, envia foguetes ao espaço e processa bilhões de transações diariamente.

Seu codinome...

IBM System/360.

Bond sorri.

— Parece apenas um computador.

Q interrompe.

— Não, 007...

É muito mais perigoso que isso.


Introdução

Todo programador COBOL aprende cedo algumas palavras mágicas.

MOVE.

READ.

WRITE.

PERFORM.

OPEN.

CLOSE.

Mas poucos sabem que essas palavras só continuam existindo, praticamente inalteradas há mais de sessenta anos, porque um grupo de engenheiros da IBM tomou uma das decisões mais ousadas da história da tecnologia.

A maioria acredita que a computação moderna nasceu com:

  • Windows

  • Linux

  • Internet

  • Google

  • AWS

  • Smartphones

Na realidade...

Todos esses são apenas capítulos posteriores de uma história iniciada oficialmente em 7 de abril de 1964.

Naquele dia nasceu o IBM System/360.

E como em todo bom filme de James Bond, o verdadeiro plano do vilão não aparece nos primeiros minutos.

Da mesma forma, o verdadeiro legado do System/360 demoraria décadas para ser compreendido.


A Operação Antes de 1964

Imagine o cenário.

Você trabalha em um banco.

Sua empresa compra um computador.

Tudo funciona perfeitamente.

Cinco anos depois chega um equipamento mais moderno.

Excelente notícia?

Nem tanto.

Naquela época significava praticamente começar do zero.

Os programas precisavam ser reescritos.

Os operadores reaprendiam comandos.

Os compiladores mudavam.

Os sistemas operacionais desapareciam.

Era como trocar um Aston Martin por um submarino e descobrir que nenhuma peça servia.

Cada computador era um universo isolado.

Cada fabricante criava suas próprias regras.

Era um verdadeiro caos tecnológico.


O Plano do Vilão

Todo filme de James Bond possui um plano secreto.

Na computação dos anos 60, o "vilão" era justamente a incompatibilidade.

Ela consumia dinheiro.

Tempo.

Equipes inteiras.

Imagine construir um prédio inteiro.

Depois demolir tudo apenas porque o elevador mudou de fabricante.

Era exatamente isso que acontecia com os computadores.


Entra em Cena o Agente 360

A IBM aparece discretamente.

Sem explosões.

Sem lasers orbitais.

Sem carros invisíveis.

Mas com uma ideia muito mais poderosa.

Compatibilidade.

Pela primeira vez na história, uma família inteira de computadores compartilhava a mesma arquitetura.

O software deixava de pertencer ao hardware.

Parece simples.

Na época foi revolucionário.


O Nome 360 Não Foi Escolhido por Acaso

Muitos imaginam que seja apenas um número.

Na verdade representa um círculo completo.

360 graus.

A mensagem era clara.

Este computador serviria para:

  • ciência

  • engenharia

  • universidades

  • bancos

  • seguros

  • governo

  • indústria

  • defesa

  • comércio

Era uma máquina para tudo.

Até hoje essa filosofia permanece viva.


O Primeiro Gadget de Q

Nos filmes de Bond sempre existe um equipamento aparentemente comum.

Depois descobrimos que ele faz algo extraordinário.

O System/360 era exatamente isso.

Por fora:

Um computador.

Por dentro:

Uma plataforma completa.


O Manual Secreto

Uma das maiores armas do System/360 não era seu hardware.

Era sua documentação.

Hoje isso parece banal.

Na época era quase inacreditável.

A IBM documentou cuidadosamente:

  • arquitetura

  • registradores

  • instruções

  • formatos de dados

  • entrada e saída

  • interrupções

  • convenções

Isso permitiu que outras empresas desenvolvessem:

  • compiladores

  • linguagens

  • sistemas operacionais

  • ferramentas

  • utilitários

Nascia um ecossistema.


O Primeiro Easter Egg

Existe uma curiosidade fantástica.

O projeto custou aproximadamente US$ 5 bilhões na época.

Corrigindo pela inflação atual...

Estamos falando de dezenas de bilhões de dólares.

Foi um dos maiores investimentos industriais do século XX.

A IBM literalmente apostou sua sobrevivência.

Se desse errado...

Talvez hoje nem existisse IBM.

Nem COBOL.

Nem IBM Z.

Nem boa parte da indústria corporativa.


O Grande Segredo: ISA

Todo computador possui uma identidade.

Ela recebe o nome de:

Instruction Set Architecture.

Ou simplesmente ISA.

Imagine um idioma.

O processador entende palavras como:

ADD

SUB

LOAD

STORE

COMPARE

BRANCH

O System/360 definiu esse idioma.

E fez uma promessa praticamente impossível.

"Mesmo que construamos computadores muito mais rápidos no futuro...

Eles continuarão entendendo esta mesma linguagem."

Sessenta anos depois...

Ainda cumprem essa promessa.


Licença para Escalar

Antes do System/360, crescer significava recomeçar.

Depois dele...

Bastava trocar de modelo.

Imagine começar com um computador pequeno.

Sua empresa cresce.

Você compra outro maior.

Os programas continuam funcionando.

Hoje chamamos isso de:

Escalabilidade.

Na época...

Era magia.


Missão Decimal

Aqui está uma das maiores genialidades da arquitetura.

Ela atendia simultaneamente dois mundos.

O Mundo Científico

Precisava calcular:

  • órbitas

  • foguetes

  • satélites

  • engenharia

  • física nuclear

Utilizava ponto flutuante.


O Mundo Financeiro

Precisava calcular:

  • juros

  • salários

  • impostos

  • seguros

  • aplicações

Utilizava aritmética decimal.

Isso evitava erros de arredondamento.

Por isso bancos continuam utilizando Packed Decimal até hoje.


Dica Bellacosa nº 1

Todo iniciante em COBOL deveria estudar:

  • DISPLAY

  • COMP

  • COMP-3

Antes mesmo de aprender CICS.

Antes mesmo de aprender Db2.

Entender representação de dados explica metade dos "mistérios" da linguagem.


O Verdadeiro Aston Martin

James Bond possuía um Aston Martin cheio de equipamentos.

O System/360 também.

Só que seus gadgets eram invisíveis.

Entre eles:

✔ canais de entrada e saída

✔ arquitetura modular

✔ compatibilidade

✔ interrupções

✔ múltiplos dispositivos

✔ independência entre CPU e periféricos

Era tecnologia extremamente avançada para 1964.


Os Agentes Secretos Chamados Canais

Um dos componentes mais brilhantes eram os Channel Processors.

Enquanto a CPU trabalhava...

Os canais conversavam com:

  • discos

  • fitas

  • impressoras

  • leitores de cartão

Sozinhos.

Hoje chamaríamos isso de:

Processamento paralelo.

DMA.

Offloading.

Hardware Acceleration.

Em 1964.


Curiosidade de Espião

Muitos engenheiros modernos acreditam que aceleração de hardware nasceu recentemente.

Na realidade...

Os canais do System/360 já faziam isso há mais de meio século.


O Cofre Suíço da Compatibilidade

Imagine guardar dinheiro em um banco.

Sessenta anos depois...

Ele continua aceitando exatamente a mesma chave.

Parece impossível.

Mas isso acontece diariamente.

Programas COBOL escritos nos anos 70 ainda executam em IBM Z modernos.

Alguns sofreram manutenção.

Outros permanecem incrivelmente próximos da versão original.

Pouquíssimas plataformas oferecem essa continuidade.


Dica Bellacosa nº 2

Nunca pense:

"COBOL é antigo."

Pense:

"COBOL possui estabilidade arquitetural."

São conceitos completamente diferentes.


A Organização SPECTRE

Nos filmes de Bond existe a SPECTRE.

Na informática havia outra ameaça.

A fragmentação.

Cada fabricante queria criar seu próprio universo.

IBM fez exatamente o contrário.

Criou uma arquitetura comum.

Isso permitiu o nascimento de um mercado inteiro.


O Nascimento dos Parceiros

Sem uma arquitetura estável dificilmente existiriam:

  • softwares comerciais

  • bancos de dados

  • ERPs

  • compiladores independentes

  • ferramentas CASE

  • produtos de terceiros

Foi o início do conceito moderno de ecossistema.


Easter Egg nº 2

O autor do texto original comenta que levou vinte e nove anos para compreender a importância do System/360 em sua própria vida.

Isso acontece com quase todo profissional de TI.

Quando começamos a estudar COBOL, JCL ou CICS, enxergamos apenas ferramentas.

Décadas depois percebemos que estamos trabalhando dentro de uma filosofia criada muito antes de nascermos.


Da Plataforma ao Universo

O System/360 não criou apenas computadores.

Criou um conceito.

Plataforma.

Hoje usamos essa palavra o tempo todo.

Windows é plataforma.

Linux é plataforma.

Android é plataforma.

AWS é plataforma.

IBM Z é plataforma.

Tudo isso possui raízes na arquitetura concebida em 1964.


CSI Bellacosa — Investigando as Pistas

Vamos analisar algumas tecnologias atuais.

Cloud

Escalar sem reescrever.

Origem?

System/360.


x86

Compatibilidade entre gerações.

Origem conceitual?

System/360.


Linux

Arquitetura estável.

Mesmo software durante décadas.

Influência?

System/360.


Containers

Separação entre aplicação e infraestrutura.

Ideia amadurecida posteriormente graças à evolução da virtualização dos mainframes.


Kubernetes

Mover aplicações sem alterar código.

Filosofia semelhante.


AWS EC2

Trocar hardware sem afetar aplicações.

Mesmo conceito.


Azure

Escalabilidade transparente.

Mesmo princípio.


IBM Cloud

Continuação natural dessa evolução.


Dica Bellacosa nº 3

Sempre que surgir uma tecnologia nova pergunte:

"Qual problema ela resolveu?"

Depois pergunte novamente:

"Será que o Mainframe já resolvia isso de outra forma?"

Você ficará surpreso.


O Próximo Filme

Todo filme de James Bond termina deixando um gancho.

O texto original faz exatamente isso.

O autor anuncia o próximo capítulo.

O protagonista deixa de investigar compatibilidade.

Agora investigará outra invenção.

Virtualização.

O famoso conceito:

"Um computador dentro de outro computador."

Sem ele provavelmente nunca existiriam:

  • VMware

  • Hyper-V

  • Docker (indiretamente)

  • Kubernetes (indiretamente)

  • AWS

  • Azure

  • Google Cloud

Tudo começa com outra revolução silenciosa.

O IBM System/370.


Curiosidades que Pouca Gente Conhece

🍸 Curiosidade 1 — O brinde que mudou o mundo

Enquanto muitos celebravam o lançamento de um novo computador em abril de 1964, poucos perceberam que estavam testemunhando o nascimento da arquitetura que sustentaria bancos, bolsas de valores, companhias aéreas e governos por décadas.

🕵️ Curiosidade 2 — A aposta mais cara da IBM

O desenvolvimento do System/360 envolveu milhares de engenheiros, diversas fábricas e uma reorganização completa da empresa. Foi uma decisão empresarial comparável a colocar todas as fichas em uma única missão.

💾 Curiosidade 3 — Compatibilidade como patrimônio

Empresas que investiram em software para System/360 puderam evoluir para System/370, S/390 e IBM Z preservando boa parte do conhecimento e dos investimentos realizados.

🎯 Curiosidade 4 — O COBOL encontrou seu lar

Embora o COBOL tenha sido criado antes do System/360, foi nessa plataforma que a linguagem encontrou o ambiente ideal para crescer e se tornar sinônimo de processamento corporativo.


Missão Cumprida

No universo de James Bond, o herói salva o mundo impedindo uma explosão nuclear, derrotando uma organização criminosa ou desativando um satélite orbital.

Na história da computação, o herói foi muito mais silencioso.

Não usava smoking.

Não dirigia um Aston Martin.

Não carregava uma Walther PPK.

Seu nome era IBM System/360.

Sua missão não era destruir vilões.

Era eliminar a maior ameaça da informática dos anos 1960: a incompatibilidade.

Ao introduzir uma arquitetura comum, um conjunto de instruções estável, proteção ao investimento, escalabilidade e a separação entre hardware e software, ele estabeleceu os alicerces da computação empresarial moderna. O que hoje parece natural — trocar servidores, atualizar sistemas, ampliar capacidade sem reescrever aplicações — começou com essa filosofia lançada em 7 de abril de 1964.

Para o programador COBOL iniciante, compreender o System/360 é como James Bond descobrir, no fim da missão, quem era o verdadeiro mentor por trás de todos os acontecimentos. De repente, tudo faz sentido: o COBOL, o z/OS, o JCL, o CICS, o Db2, o IBM Z e até conceitos modernos como virtualização, computação em nuvem e arquiteturas compatíveis deixam de ser peças isoladas e passam a formar uma única narrativa.

E existe um último easter egg digno de um filme de espionagem: talvez o maior segredo do System/360 nunca tenha sido sua velocidade, sua memória ou seu hardware.

Seu verdadeiro "dispositivo secreto" foi uma ideia.

A ideia de que o software deveria sobreviver ao hardware.

Sessenta anos depois, essa missão continua ativa.

E, como toda boa operação do MI6, ela permanece funcionando silenciosamente nos bastidores, protegendo bilhões de transações todos os dias.

Missão cumprida, Agente COBOL. A próxima pasta confidencial já está sobre a mesa: IBM System/370 — o computador que aprendeu a ser muitos computadores ao mesmo tempo.

quarta-feira, 11 de janeiro de 2012

☕💣🍉 O DIA EM QUE O MAINFRAME TENTOU APAGAR UMA MELANCIA: A HISTÓRIA SECRETA DO SUIKAWARI, O “DELETE DATASET” MAIS DIVERTIDO DO VERÃO JAPONÊS

 

Bellacosa Mainframe divertidos dias de verao suikawari

☕💣🍉 O DIA EM QUE O MAINFRAME TENTOU APAGAR UMA MELANCIA: A HISTÓRIA SECRETA DO SUIKAWARI, O “DELETE DATASET” MAIS DIVERTIDO DO VERÃO JAPONÊS

Se você assiste animes há algum tempo, certamente já viu aquela cena clássica: uma praia ensolarada, amigos reunidos, alguém vendado segurando um bastão e uma pobre melancia aguardando seu destino inevitável.

Então alguém grita:

— MAIS PARA A ESQUERDA!

Outro responde:

— NÃO! PARA A DIREITA!

E o resultado normalmente é um golpe certeiro na areia, numa barraca ou, em casos mais extremos, em algum amigo distraído.

Bem-vindo ao mundo do Suikawari (スイカ割り), uma das tradições mais curiosas, divertidas e simbólicas do verão japonês.

Mas de onde surgiu essa brincadeira? Por que ela aparece em tantos animes? E será que existe alguma história escondida por trás da melancia mais famosa da cultura pop japonesa?

Pegue seu café, coloque sua pulseira de operador e venha comigo.


O que significa Suikawari?

A palavra é simples:

  • Suika (スイカ) = melancia

  • Wari (割り) = quebrar, dividir, partir

Literalmente:

"Quebrar a melancia."

Os japoneses têm um talento especial para dar nomes extremamente objetivos às suas tradições.

Imagine se o JCL fosse criado por eles:

//DELETEJOB EXEC PGM=DELETEFILE

Sem mistério.

Sem marketing.

Sem buzzword.

Apenas a verdade.


A origem do Suikawari

Curiosamente, ninguém sabe exatamente quando o Suikawari surgiu.

Os historiadores acreditam que a prática ganhou força durante o crescimento do turismo de praia no Japão entre as décadas de 1950 e 1960.

Após a Segunda Guerra Mundial, o país passou por um enorme desenvolvimento econômico.

Mais pessoas começaram a viajar para praias durante as férias escolares.

Era necessário criar atividades simples, divertidas e acessíveis.

Então alguém provavelmente pensou:

— E se vendássemos uma pessoa e mandássemos ela acertar uma melancia com um pedaço de madeira?

E, de alguma forma, isso funcionou.

Décadas depois, continua funcionando.


O regulamento que quase ninguém conhece

Sim.

Existe um regulamento oficial.

O Japão levou a brincadeira tão a sério que criou regras formais para competições.

Entre elas:

  • A melancia deve estar posicionada em uma área específica.

  • O participante deve estar vendado.

  • Há limite de tempo.

  • Os espectadores podem orientar verbalmente.

  • O vencedor é quem consegue atingir o alvo corretamente.

Em outras palavras:

É quase um sistema de navegação assistida por voz.

Uma espécie de GPS humano.

Com uma taxa de erro absurdamente maior.


A grande ironia da brincadeira

O objetivo é quebrar uma melancia.

Mas a parte divertida nunca foi a melancia.

É o caos.

O verdadeiro entretenimento é observar alguém completamente perdido tentando interpretar instruções contraditórias.

É praticamente uma reunião de crise de TI.

Equipe A: Vai para a esquerda!
Equipe B: Não! Direita!
Equipe C: Volta!
Equipe D: Para!
Operador: Mas qual é o comando correto?

Resultado:

Abend emocional para todos os envolvidos.


Por que aparece tanto nos animes?

Porque o Suikawari se tornou um símbolo cultural do verão japonês.

Assim como:

  • Fogos de artifício

  • Yukatas

  • Festival Matsuri

  • Praia

  • Cigarras cantando

  • Sorvete de gelo raspado

  • Romance de férias

Quando um diretor coloca uma cena de Suikawari no anime, ele está enviando uma mensagem subliminar:

"Aproveite este momento. O verão não dura para sempre."

Por isso muitas dessas cenas carregam uma sensação de nostalgia.


A fofoca que ninguém comenta

Muitos romances de anime começam durante um Suikawari.

Coincidência?

Claro que não.

A fórmula é clássica:

  1. Heroína vendada.

  2. Protagonista ajudando.

  3. Aproximação física.

  4. Momento constrangedor.

  5. Silêncio.

  6. Desenvolvimento romântico.

O Suikawari é praticamente o Tinder do verão japonês.

Com menos algoritmos.

E mais melancias.


O easter egg escondido em centenas de animes

Existe um padrão curioso.

Em muitos animes, o personagem que consegue acertar a melancia logo na primeira tentativa costuma ser:

  • O protagonista.

  • O personagem mais disciplinado.

  • Ou alguém com habilidades especiais.

Já aquele que erra completamente geralmente é:

  • O personagem cômico.

  • O distraído.

  • O azarado oficial da turma.

É uma forma silenciosa de o diretor mostrar a personalidade dos personagens sem precisar explicar nada.


A teoria do "mainframe da vida"

Agora vamos imaginar o Suikawari como um ambiente z/OS.

A melancia é o dataset.

A venda é a falta de documentação.

Os amigos são a equipe de suporte.

O bastão é o utilitário.

E o operador está tentando executar a tarefa.

Algo como:

DELETE DATASET CLIENTE.PRODUCAO

Sem saber exatamente onde está o dataset.

A equipe começa a orientar.

Mais para a esquerda!
Mais para a direita!
Volta um pouco!
Agora!

O operador executa.

Silêncio.

Então surge a mensagem:

IDC3009I DATA SET DELETED

Sucesso.

A melancia foi embora.


Curiosidades que poucos fãs conhecem

A melancia é considerada uma fruta premium no Japão

Enquanto no Brasil a melancia é relativamente barata, no Japão frutas podem ser extremamente caras.

Dependendo da região, uma única melancia pode custar dezenas de dólares.

Por isso muitos japoneses utilizam melancias menores para a brincadeira.


Existem melancias quadradas

Sim.

Elas existem.

São cultivadas dentro de caixas transparentes para crescerem em formato cúbico.

Originalmente foram criadas para facilitar armazenamento.

Hoje são mais utilizadas como itens decorativos.

E custam valores absurdos.


Nem sempre usam bastões

Dependendo da região:

  • Bastões de bambu

  • Bastões de madeira

  • Réplicas esportivas

podem ser utilizados.

A regra principal continua sendo a mesma:

A melancia precisa perder essa batalha.


Os Suikawaris mais famosos dos animes

Diversas obras utilizaram a tradição:

  • Clannad

  • Air

  • Kanon

  • Non Non Biyori

  • Ano Hana

  • Haruhi Suzumiya

  • Nagi no Asukara

  • Bunny Girl Senpai

  • Summer Time Rendering

  • Barakamon

Sempre que aparece uma melancia na praia, veteranos dos animes já sabem o que está prestes a acontecer.

É quase um evento programado.


O significado oculto da melancia

Embora seja apenas uma brincadeira, muitos estudiosos da cultura japonesa observam algo interessante.

A melancia representa um momento temporário.

O verão acaba.

As férias terminam.

Os amigos seguem caminhos diferentes.

A fruta será consumida.

O dia chegará ao fim.

Tudo é passageiro.

Talvez seja por isso que tantas cenas de Suikawari carregam um sentimento melancólico escondido atrás das risadas.

É uma celebração do presente.

Uma lembrança de que certos momentos só existem uma vez.


Conclusão: o job mais divertido do verão

O Suikawari parece uma brincadeira simples.

E realmente é.

Mas ele acabou se transformando em um dos maiores símbolos da juventude japonesa.

Durante décadas, atravessou gerações, praias, festivais, mangás e animes.

E toda vez que vemos alguém vendado tentando acertar uma melancia, estamos assistindo a algo muito maior do que uma simples competição.

Estamos vendo amizade.

Memórias.

Verão.

Nostalgia.

E, claro, uma demonstração prática de que seguir instruções de várias pessoas ao mesmo tempo quase nunca termina bem.

Porque, no final das contas, a vida inteira talvez seja um enorme Suikawari.

Todos nós estamos vendados.

Tentando encontrar o alvo.

Esperando não acertar a pessoa errada.

E torcendo para que o próximo comando não provoque um ABEND.

☕💣🍉

terça-feira, 10 de janeiro de 2012

🔥 JCL – Job Control Language: o cérebro silencioso do mainframe em um mundo distribuído

Bellacosa Mainframe apresenta Job Control Language JCL

 


🔥 JCL – Job Control Language: o cérebro silencioso do mainframe em um mundo distribuído



☕ Midnight Lunch no CPD (ou: quando o job ainda manda)

Era hora do midnight lunch. Café requentado, luz fria do CPD, impressora 3211 cuspindo papel contínuo.
O sysprog passa e solta a frase clássica:

“Não é o programa… é o JCL.”

Silêncio respeitoso.
Porque todo mainframer sabe: quem controla o JCL controla o sistema.

Este artigo é sobre JCL (Job Control Language), mas com um tempero moderno:
👉 como o JCL se encaixa — e ainda ensina — no mundo das aplicações distribuídas.


🧠 O que é JCL (para quem já viveu isso, mas nunca parou pra filosofar)

JCL não é linguagem de programação.
JCL é linguagem de orquestração.

Antes de:

  • YAML

  • Pipelines CI/CD

  • Kubernetes

  • Airflow

  • Jenkins

…já existia:

//JOBNAME JOB ... //STEP01 EXEC ... //DD1 DD ...

📌 JCL diz ao sistema:

  • O que rodar

  • Em que ordem

  • Com quais recursos

  • Com quais dados

  • Com quais limites

  • E como reagir a falhas

Ou seja: governança operacional pura.


🕰️ Um pouco de história (porque mainframer não vive sem contexto)

  • Anos 60–70: JCL nasce para controlar jobs batch

  • Anos 80: amadurece com JES2/JES3

  • Anos 90: integra-se com CICS, DB2, MQ

  • Anos 2000+: passa a conviver com Unix, web, cloud

  • Hoje: continua firme, enquanto muita stack moderna muda a cada 6 meses

💡 Curiosidade Bellacosa:
Muita ferramenta “moderna” só redescobriu conceitos que o JCL já fazia bem desde o século passado.


🌐 Aplicações distribuídas explicadas para mainframers

Vamos traduzir para o dialeto JCL.

Uma aplicação distribuída é como um job com vários steps rodando fora do z/OS, em máquinas diferentes, falando por mensagens.

Analogia direta

Mundo DistribuídoMundo JCL
MicroserviceSTEP bem definido
Pipeline CI/CDJob com múltiplos EXEC
SchedulerJES
Retry automáticoRESTART
TimeoutTIME
LogsSYSPRINT / SMF
OrquestraçãoJOB statement

👉 JCL foi um “orquestrador” décadas antes da palavra existir.


🧩 O JOB statement: o “manifest.yaml” do mainframe

No mundo moderno, você descreve tudo em um manifesto.

No mainframe, isso sempre existiu:

//MEUJOB JOB 'BELLACOSA', /* CLASS=A, MSGCLASS=X, TIME=0, REGION=0M, PRTY=15 */

Aqui você define:

  • Prioridade

  • Tempo de CPU

  • Memória

  • Classe de execução

  • Comportamento operacional

💡 Easter Egg:
TIME=0 é o “unlimited resources” do mundo mainframe — usado com responsabilidade, claro 😈


⚙️ Steps, COND e a arte de não rodar o que não precisa

Aplicações distribuídas vivem de fluxos condicionais.
No JCL, isso já existia com classe:

COND=(4,LT)

Tradução:

“Se algo deu muito certo, nem roda isso aqui.”

😂

Brincadeiras à parte:

  • COND evita processamento desnecessário

  • Reduz custo

  • Aumenta previsibilidade

👉 Conceito idêntico a short-circuiting em pipelines modernos.


🔄 START, RESTART e resiliência real

No mundo cloud:

  • “Reprocessa o pipeline”

  • “Rerun from failed stage”

No mainframe, desde sempre:

  • START=STEPX

  • RESTART=STEPX

Isso não é detalhe técnico.
Isso é engenharia de confiabilidade.

💡 Curiosidade:
Muitos sistemas distribuídos ainda sofrem para fazer restart idempotente.
No batch mainframe… isso é requisito básico desde o projeto.


📊 Observabilidade: SMF é o avô do tracing distribuído

Hoje falam em:

  • Logs

  • Metrics

  • Traces

No mainframe:

  • SMF

  • RMF

  • JES logs

  • SYSOUT

📌 O conceito é o mesmo:

“Se eu não consigo medir, eu não consigo operar.”

A diferença?
O mainframe sempre tratou isso como obrigação, não como opcional.


🪜 Passo a passo mental para o mainframer entrar no mundo distribuído

  1. Pense em jobs como pipelines

  2. Pense em steps como microserviços

  3. Pense em JES como scheduler

  4. Pense em SMF como observabilidade

  5. Pense em RESTART como resiliência

  6. Confie: você já sabe mais do que imagina


📚 Guia de estudo recomendado (com cérebro mainframe)

🔹 Conceitos para estudar:

  • APIs REST

  • Message Queues

  • Event-driven architecture

🔹 Faça paralelos:

  • MQ ↔ Kafka

  • JCL ↔ YAML

  • JES ↔ Orquestrador

  • CICS ↔ API Gateway

🔹 Exercício clássico:

“Se isso fosse um job batch, onde ele falharia?”


🏁 Conclusão – El Jefe fecha a conta

O mundo mudou.
As palavras mudaram.
As ferramentas mudaram.

Mas os princípios

  • Orquestração

  • Controle

  • Governança

  • Resiliência

  • Observabilidade

👉 o JCL já fazia tudo isso.

Por isso, quando alguém diz:

“Mainframe é legado”

O mainframer responde, calmamente, entre um café e outro:

“Legado é aquilo que ainda funciona.”

🔥☕

segunda-feira, 9 de janeiro de 2012

🔥 Conhecimento básico sobre aplicações distribuídas – um guia para mainframers que sobreviveram ao monólito



 🔥 Conhecimento básico sobre aplicações distribuídas – um guia para mainframers que sobreviveram ao monólito




1️⃣ Introdução: quando o monólito saiu da jaula

Mainframer raiz conhece bem o monólito confiável: CICS firme, DB2 consistente, batch noturno pontual como relógio suíço. Durante décadas, aplicação distribuída era vista como “coisa de Unix instável” ou “modinha client-server”.

Mas o mundo girou. A web cresceu, o mobile explodiu, a nuvem virou padrão e, de repente, o monólito começou a ser fatiado em serviços. Nasciam as aplicações distribuídas — e com elas, novos problemas… e velhos conceitos que o mainframe já conhecia muito bem.

💡 Easter egg: se você já lidou com VTAM, MQSeries e sysplex, você já entendeu aplicações distribuídas… só não sabia o nome moderno disso.



2️⃣ O que são aplicações distribuídas (sem buzzword)

Uma aplicação distribuída é aquela em que:

  • O processamento ocorre em vários nós

  • Cada parte da aplicação pode rodar em máquinas, containers ou regiões diferentes

  • A comunicação acontece por rede, não por memória compartilhada

Exemplos modernos:

  • Microservices em Kubernetes

  • APIs REST + filas (Kafka, MQ, RabbitMQ)

  • Frontend web → backend → banco → cache → serviços externos

No fundo, é o velho conceito de desacoplamento, agora amplificado.


3️⃣ Paralelos diretos com o mundo mainframe 🧠

Mundo MainframeMundo Distribuído
CICS TransactionMicroservice
MQSeriesEvent Streaming
SysplexCluster
SMF / RMFTelemetria / Observabilidade
AbendException distribuída
Batch encadeadoPipelines assíncronos

👉 Conclusão Bellacosa: mainframers não estão atrasados — estão adiantados há 30 anos.


4️⃣ Principais desafios (spoiler: não são novos)

🔹 Latência

No mainframe, o gargalo era I/O.
No distribuído, é rede + serialização + hops excessivos.

🔹 Falhas parciais

No mundo distribuído:

“Se algo pode falhar, vai falhar, mas só um pedaço.”

Isso lembra:

  • Regiões CICS indisponíveis

  • LPAR isolada

  • Subsystem down às 03:12 😈

🔹 Consistência

Aqui entra o famoso CAP Theorem — mas mainframer chama isso de:

“Escolher entre disponibilidade e integridade quando o caldo entorna.”


5️⃣ Conceitos essenciais que todo mainframer deve dominar

✔️ Comunicação síncrona vs assíncrona

  • Síncrona: REST, RPC (espera resposta)

  • Assíncrona: filas, eventos, fire-and-forget
    👉 MQ old school total.

✔️ Escalabilidade horizontal

  • Escalar mais instâncias, não máquinas maiores
    (trauma de quem pedia upgrade de MIPS aprovado em comitê 😅)

✔️ Observabilidade

  • Logs

  • Métricas

  • Traces distribuídos

📌 Curiosidade: SMF foi o avô do tracing moderno.


6️⃣ Passo a passo mental para entender qualquer sistema distribuído

1️⃣ Identifique quais serviços existem
2️⃣ Veja como eles se comunicam
3️⃣ Descubra onde estão os pontos de falha
4️⃣ Analise latência e dependências
5️⃣ Verifique quem é o dono do dado
6️⃣ Observe como o sistema se comporta quando algo cai

🧨 Dica Bellacosa: desligue mentalmente um serviço e pergunte
“O que quebra primeiro?”


7️⃣ Guia de estudo para mainframers curiosos 📚

Conceitos

  • Microservices vs Monólito

  • Event-driven architecture

  • Observabilidade

  • Resiliência e retries

Ferramentas modernas (com alma antiga)

  • Instana / Dynatrace → RMF da nuvem

  • Prometheus → SMF open source

  • Kafka → MQSeries com esteroides

  • Kubernetes → Sysplex com YAML


8️⃣ Aplicações práticas no dia a dia

  • Integrar mainframe com APIs modernas

  • Expor transações CICS como serviços

  • Monitorar ambientes híbridos

  • Diagnosticar falhas ponta a ponta

  • Atuar como tradutor cultural entre legado e cloud

🎯 Mainframer que entende distribuído vira peça-chave.


9️⃣ Comentário final (meia-noite, café frio ☕)

Aplicações distribuídas não são o fim do mainframe.
São apenas o mesmo problema antigo, rodando em mais lugares, com nomes novos e menos disciplina.

Quem sobreviveu a:

  • Batch quebrado em fechamento

  • Deadlock às 02h

  • Região CICS instável em dia útil

…tem todas as credenciais para dominar o mundo distribuído.

🖤 El Jefe Midnight Lunch aprova:
legado não é atraso — é memória de guerra.

domingo, 8 de janeiro de 2012

🖥️🧙‍♂️ Comandos de gerenciamento do IBM CICS

 



🖥️🧙‍♂️ Comandos de gerenciamento do IBM CICS

Bellacosa Mainframe Style — Guia definitivo para Padawan CICS

Os comandos de gerenciamento do IBM CICS são o coração operacional do ambiente transacional em mainframe. Diferentemente dos comandos EXEC CICS, usados dentro de programas COBOL, PL/I ou assembler, os comandos de gerenciamento são transações interativas, executadas diretamente no terminal 3270, com foco em administração, diagnóstico e controle em tempo real do sistema.

Esses comandos surgiram para dar autonomia ao operador e ao analista, permitindo gerenciar recursos sem reiniciar o CICS ou recorrer a JCL. O principal deles é o CEMT (CICS Execute Master Terminal), usado para consultar e alterar o estado de tarefas, programas, arquivos, transações e conexões. Já o CEDA (CICS Execute Definition) permite definir e instalar recursos no CSD (CICS System Definition), funcionando como um catálogo central de configurações. O CECI é voltado a testes, permitindo executar comandos EXEC CICS de forma interativa, enquanto o CEDF atua como ferramenta básica de depuração, interceptando chamadas EXEC CICS durante a execução de programas.

Outros comandos importantes incluem o CESN (login e segurança), CEOT (reset de sessão), CEBR (navegação em arquivos VSAM) e CEVT (controle de eventos temporizados). Em conjunto, esses comandos transformam o CICS em um ambiente altamente controlável, onde estabilidade, disciplina e observabilidade são valores centrais — características que explicam sua longevidade em sistemas críticos até hoje.


Antes de existir DevOps, Kubernetes ou observabilidade, o CICS já tinha seu próprio painel de controle Jedi:
as transações de gerenciamento, executadas direto no terminal 3270.

Elas não são EXEC CICS, são comandos operacionais — a diferença entre programar e governar o império.


🧠 O que são comandos de gerenciamento do CICS?

São transações especiais, quase sempre iniciadas com CE ou CM, usadas para:

  • administrar recursos

  • diagnosticar problemas

  • testar comandos

  • depurar programas

  • controlar o runtime

📌 Insight Bellacosa:

EXEC CICS é para o código.
CEMT é para quem manda.


Comando CEMT


🔹 1️⃣ CEMT — CICS Execute Master Terminal

O CEMT (CICS Execute Master Terminal) é o principal comando de gerenciamento do IBM CICS, usado para monitorar e controlar recursos em tempo real a partir do terminal 3270. Com ele, o operador ou analista pode consultar (INQUIRE) e alterar (SET) o estado de tarefas, programas, arquivos, transações, terminais e conexões, sem reiniciar o sistema. Criado para dar autonomia operacional, o CEMT permite ações críticas como NEWCOPY de programas, cancelamento de tasks presas e verificação de uso de recursos. É uma ferramenta poderosa, rápida e perigosa: um comando mal aplicado pode impactar produção instantaneamente. Dominar o CEMT é passo essencial para qualquer profissional CICS.

📟 O console supremo

📜 História

Criado para substituir comandos internos e dar controle online do CICS.

🔧 Para que serve

  • Ver e alterar status de:

    • Tasks

    • Programs

    • Files

    • Transactions

    • Terminals

    • Connections

🧪 Exemplo (Padawan)

CEMT I TASK
CEMT I PROG(DMCPGM01)
CEMT SET PROG(DMCPGM01) NEWCOPY

💡 Dicas

  • I = INQUIRE

  • SET muda o estado em produção 😈

🥚 Easter egg:
CEMT I TASK já derrubou mais produção que bug em COBOL mal testado.


Comando CEDA


🔹 2️⃣ CEDA — CICS Execute Definition

O CEDA (CICS Execute Definition) é o comando de gerenciamento do CICS responsável por definir e administrar recursos no CSD (CICS System Definition). Por meio dele, o analista cria, altera, remove e instala definições como PROGRAM, TRANSACTION, FILE, MAPSET e DB2ENTRY, sem necessidade de JCL. O CEDA separa conceito de execução: definir não é instalar, sendo necessário o comando INSTALL para ativar o recurso no ambiente. Criado para dar flexibilidade e padronização ao CICS, o CEDA é essencial para mudanças controladas. Seu uso correto garante consistência, rastreabilidade e estabilidade em ambientes transacionais críticos.

📚 O catálogo de schemas do CICS

📜 História

Criado para definir recursos sem JCL.

🔧 Para que serve

  • Definir recursos no CSD:

    • PROGRAM

    • TRANSACTION

    • FILE

    • MAPSET

    • DB2ENTRY

🧪 Exemplo

CEDA DEF PROGRAM(DMCPGM01)
CEDA INS TRAN(DMC1)
CEDA INSTALL

💡 Dicas

  • Definir ≠ Instalar

  • Só vira realidade após INSTALL

🥚 Easter egg:
Já existia Infrastructure as Data antes do YAML virar moda.



Comando CECI

🔹 3️⃣ CECI — CICS Execute Command Interpreter

O CECI (CICS Execute Command Interpreter) é o comando de gerenciamento do CICS usado para testar comandos EXEC CICS de forma interativa, sem escrever ou compilar programas. Ele permite simular operações como READ, WRITE, LINK, SEND e RECEIVE, facilitando aprendizado, validação e diagnóstico rápido de problemas. Criado como laboratório do CICS, o CECI é muito utilizado por iniciantes e analistas experientes para entender o comportamento dos recursos em tempo real. Apesar de ser uma ferramenta didática, o CECI pode alterar dados reais, exigindo cuidado em ambientes produtivos. É um recurso valioso para estudo e testes controlados.

🧪 Laboratório nuclear

📜 História

Criado para testar EXEC CICS sem escrever programa.

🔧 Para que serve

  • Simular comandos EXEC CICS

  • Testar arquivos, filas, links

🧪 Exemplo

EXEC CICS READ FILE(ARQCLI)

💡 Dicas

  • Ideal para aprender CICS

  • Pode alterar dados reais ⚠️

🥚 Easter egg:
CECI é o Postman do CICS — só que mais perigoso.


Comando CEDF

🔹 4️⃣ CEDF — CICS Execution Diagnostic Facility

O CEDF (CICS Execution Diagnostic Facility) é o comando de gerenciamento do CICS utilizado para depuração básica de programas em tempo de execução. Ao ser ativado, ele intercepta cada comando EXEC CICS, permitindo ao analista acompanhar passo a passo a execução da task, visualizar parâmetros e identificar erros lógicos. Criado antes das ferramentas modernas de debug, o CEDF foi por muito tempo o principal recurso de diagnóstico no CICS. Seu uso deve ser restrito a ambientes controlados, pois pode impactar desempenho e travar sessões se esquecido ativo. Ainda hoje, é valioso para aprendizado e análise detalhada.

🐞 O debugger raiz

📜 História

Antes de Xpediter, Debug Tool… só existia o CEDF.

🔧 Para que serve

  • Debug passo a passo

  • Interceptar EXEC CICS

🧪 Exemplo

CEDF ON

💡 Dicas

  • Use só em ambiente controlado

  • Pode afetar performance

🥚 Easter egg:
Todo mainframer já travou uma task esquecendo o CEDF ON.


Comando CESN


🔹 5️⃣ CESN — CICS Sign-On

O CESN (CICS Execute Sign-On) é o comando de gerenciamento do CICS responsável pelo processo de autenticação do usuário no ambiente transacional. Ele permite que o operador ou analista se identifique no CICS, integrando-se aos sistemas de segurança como RACF, ACF2 ou Top Secret. O CESN associa o usuário ao terminal, definindo permissões e controles de acesso às transações e recursos. Criado para garantir rastreabilidade e segurança, é o primeiro comando executado em muitos ambientes. Sem um sign-on válido, o usuário permanece com acesso restrito, impossibilitado de operar ou administrar o sistema.

🔐 Porta de entrada

📜 História

Integração direta com RACF/ACF2/TopSecret.

🔧 Para que serve

  • Login no CICS

🧪 Exemplo

CESN

💡 Dicas

  • Usuário ≠ terminal

  • Segurança manda

🥚 Easter egg:
Sem CESN, você é só mais um terminal mudo.


Comando CEOT


🔹 6️⃣ CEOT — CICS End Of Task

O CEOT (CICS End Of Task) é o comando de gerenciamento do CICS utilizado para encerrar e limpar o estado de uma sessão no terminal 3270. Ele finaliza a task corrente, libera recursos associados e redefine o terminal para um estado inicial seguro. O CEOT é muito usado quando uma transação fica presa, apresenta comportamento inesperado ou após testes e depuração. Criado como mecanismo simples de recuperação, funciona como um “reset” controlado do terminal, sem afetar outras tasks do sistema. É uma ferramenta básica, porém essencial, para manter estabilidade e disciplina operacional no ambiente CICS.

🧹 Limpeza de sessão

📜 História

Criado para encerrar tasks zumbis.

🔧 Para que serve

  • Resetar estado do terminal

  • Encerrar tarefas presas

🧪 Exemplo

CEOT

🥚 Easter egg:
O “Ctrl+Alt+Del” do CICS.


Comando CEST


🔹 7️⃣ CEST — CICS Start

O CEST (CICS Execute Start) é um comando de gerenciamento menos conhecido do CICS, utilizado para iniciar tarefas ou transações de forma controlada, principalmente em cenários de teste e diagnóstico. Ele permite disparar uma execução sem depender do fluxo normal de entrada do usuário, ajudando analistas a validar comportamentos específicos do sistema. Historicamente, o CEST surgiu como apoio a ambientes de desenvolvimento e verificação operacional, não sendo amplamente usado em produção moderna. Embora simples, seu uso exige cautela, pois iniciar tasks manualmente pode consumir recursos ou gerar efeitos colaterais inesperados. É um recurso auxiliar, mas útil para estudos e testes dirigidos.

🚀 Bootstrap manual

🔧 Para que serve

  • Iniciar transações manualmente

  • Testes controlados

🥚 Pouco usado, mas histórico.


Comando CEBR

🔹 8️⃣ CEBR — CICS Browse

O CEBR (CICS Execute Browse) é o comando de gerenciamento do CICS utilizado para consultar e navegar interativamente por arquivos VSAM diretamente no terminal 3270. Ele permite localizar registros por chave, avançar ou retroceder sequencialmente e visualizar o conteúdo dos dados, sendo muito útil para análise e diagnóstico. O CEBR é amplamente usado em ambientes de desenvolvimento e suporte para verificar dados sem escrever programas. Apesar de ser uma ferramenta de leitura, seu uso requer cuidado com permissões e contexto do arquivo. É um recurso clássico do CICS, simples, eficiente e valioso para entendimento dos dados em tempo real.

📂 Explorador de arquivos

🔧 Para que serve

  • Browse online de VSAM

  • Debug de dados

🥚 Easter egg:
O File Explorer mais antigo ainda em produção.


Comando CEVT


🔹 9️⃣ CEVT — Event Control

O CEVT (CICS Event Control) é um comando de gerenciamento do CICS usado para controlar e testar eventos temporizados dentro do ambiente transacional. Ele permite simular condições baseadas em tempo, como atrasos, timeouts e disparo de eventos, auxiliando no diagnóstico de comportamentos assíncronos. Historicamente, o CEVT foi criado para apoiar testes de aplicações que dependem de temporização e controle interno do CICS. Embora pouco utilizado em ambientes modernos, permanece disponível para cenários específicos de estudo e validação. Seu uso exige cautela, pois eventos mal configurados podem afetar o fluxo normal das tarefas e a previsibilidade do sistema.

⏱️ Timer interno

🔧 Para que serve

  • Testar eventos temporizados

Pouco usado hoje, mas ainda vivo.


CICS Command Line Functions

🧠 Resumo Bellacosa Mainframe

ComandoFunção
CEMTGoverno
CEDADefinição
CECITeste
CEDFDebug
CESNSegurança
CEOTReset
CEBRDados
CESTStart
CEVTEventos

🧙‍♂️ Conselho final ao Padawan

Aprender CICS não começa em COBOL.
Começa em CEMT.

🖥️ MAINFRAME MODE ON:
Quem domina os comandos de gerenciamento não pede acesso — controla o ambiente.

Para saber mais sobre CICS

https://eljefemidnightlunch.blogspot.com/2012/10/cics-command-level-para-padawans.html



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