☕ 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

quinta-feira, 17 de outubro de 2013

Goal Gradient Effect: Doctor Who, COBOL e o Dia em que Faltavam Apenas Três Por Cento para Fazermos uma Grande Besteira

 

Bellacosa Mainframe e o goal gradient effect

☕ Um Café no Bellacosa Mainframe

Goal Gradient Effect: Doctor Who, COBOL e o Dia em que Faltavam Apenas Três Por Cento para Fazermos uma Grande Besteira

Uma viagem pela TARDIS dos incidentes para entender por que quanto mais perto estamos de uma meta, maior tende a ser nossa motivação — e por que justamente a reta final pode concentrar pressa, fadiga, atalhos, vieses e alguns dos maiores riscos de um sistema crítico

Sexta-feira.

17:42.

Esse horário deveria existir no catálogo oficial de riscos operacionais.

Não porque alguma lei da física torne computadores particularmente instáveis às sextas-feiras.

Mas porque existe uma variável muito mais complicada ligada ao sistema:

seres humanos querendo ir embora.

Na War Room temos:

dois programadores;

um DBA;

um analista de produção;

um gerente;

um especialista em segurança;

quatro canecas;

uma garrafa térmica quase vazia;

e um dashboard gigantesco mostrando:

PROJETO MIGRAÇÃO PAYMENTS-X

███████████████████░

97% COMPLETE

Nosso jovem programador COBOL olha.

— Noventa e sete por cento.

O gerente sorri.

— Praticamente pronto.

O DBA olha para uma planilha.

— Falta validar o rollback da alteração de schema.

Silêncio.

O analista de produção acrescenta:

— E o restore completo ainda não foi testado.

O gerente olha novamente para:

97%

— Mas estamos praticamente prontos.

Nosso jovem pergunta:

— A reconciliação dos valores terminou?

— Temos amostragem.

— Completa?

— Não.

— E o teste de restart do batch?

— Fizemos um parcial.

— Então...

Ele aponta para o painel.

— De onde vieram os 97%?

O gerente responde:

— Noventa e sete tarefas de cem foram concluídas.

Nosso jovem começa a rir.

Não porque fosse engraçado.

Porque percebeu uma coisa extraordinária.

As três tarefas restantes eram:

98. VALIDAR RESTORE
99. VALIDAR ROLLBACK
100. VALIDAR RECONCILIAÇÃO

Ou seja:

haviam terminado 97 coisas.

E deixado para os últimos 3%:

as três coisas capazes de transformar uma implantação ruim numa madrugada histórica.

VWORP.

VWORP.

VWORP.

A TARDIS surge entre uma impressora e a máquina de café.

A porta abre.

O Doctor aparece.

Observa:

97%

Depois observa:

ROLLBACK ........ PENDING
RESTORE ......... PENDING
RECONCILIATION .. PENDING

Ele olha para a equipe.

— Imagino que estejam discutindo adiar o Go-Live.

Gerente:

— Na verdade estamos discutindo seguir.

— Por quê?

— Porque estamos em 97%.

O Doctor olha para nosso jovem COBOL.

— Isso é uma unidade de risco?

— Não.

— Unidade de prontidão?

— Também não.

— Unidade de integridade?

— Não.

O Doctor sorri.

— Então vocês estão prestes a tomar uma decisão técnica baseados em...

Pausa dramática.

— uma barra de progresso.

Bem-vindo ao:



Goal Gradient Effect

ou:

Efeito Gradiente de Meta.


🧠 O que é Goal Gradient Effect?

Em termos simples:

quanto mais próximos sentimos que estamos de alcançar uma meta, maior tende a ficar nossa motivação para completá-la.

Quando o objetivo está longe:

procrastinamos;

distribuímos esforço;

fazemos pausas;

mudamos de prioridade.

Quando a linha de chegada aparece:

aceleramos.

Isso pode ser excelente.

Também pode ser perigosíssimo.

Em linguagem Bellacosa:

quando a barra passa de 90%, nosso cérebro começa a executar um PERFORM UNTIL DONE que nem sempre consulta o manual operacional antes de continuar.


🐀 A história começa antes do COBOL

A ideia do Goal Gradient é antiga na psicologia comportamental.

Experimentos clássicos observaram que animais aumentavam o esforço conforme se aproximavam de uma recompensa.

Imagine um rato percorrendo um corredor em direção à comida.

No início:

ritmo normal.

Quanto mais próximo da recompensa:

mais rápido.

Nós somos ligeiramente mais sofisticados.

Temos:

PowerPoint;

Jira;

dashboards;

badges;

milhas aéreas;

certificados;

XP;

barra de progresso.

Mas nosso cérebro também gosta daquela sensação:

“Falta pouco.”


☕ O cartão do café explica muita coisa

Imagine:

COMPRE 10 CAFÉS
GANHE 1 GRÁTIS

Você tem:

1 carimbo.

Não existe urgência.

Agora você tem:

De repente o décimo café parece:

necessário.

Talvez você nem quisesse café naquele momento.

Mas:

falta apenas um.

Esse “apenas um” é poderoso.


🧠 Progress Bar

É por isso que:

███████████████████░ 95%

é psicologicamente diferente de:

████░░░░░░░░░░░░░░░░ 20%

Nos dois casos existe trabalho restante.

Mas a percepção muda.


☕ Você conhece isso

Download:

12%

Você vai fazer outra coisa.

Download:

98%

Você fica olhando.

Como se sua presença:

ajudasse os pacotes IP.

Não ajuda.

Mas estamos todos juntos nisso.


🧠 Endowed Progress Effect

Existe um fenômeno relacionado muito interessante:

Endowed Progress Effect.

Imagine dois cartões.

Primeiro:

8 CAFÉS

0 / 8

Segundo:

10 CAFÉS

2 / 10 JÁ CARIMBADOS

Nos dois casos faltam:

8 cafés.

Mas o segundo cria:

sensação de progresso prévio.

Você já começou.

Isso pode aumentar motivação.

Por isso programas de fidelidade, cursos e aplicativos frequentemente mostram:

progresso inicial.


☕ Em treinamento isso pode ser maravilhoso

Curso de COBOL:

[✔] Ambiente preparado
[✔] Primeiro programa
[ ] Variáveis
[ ] PERFORM
[ ] Arquivos
[ ] VSAM
[ ] Db2
[ ] CICS

Você já:

começou.

Agora existe:

movimento.


🧠 Goal Gradient não é inimigo

Esse ponto é fundamental.

O efeito pode ser:

fantástico para aprendizagem.

Em vez de:

APRENDER COBOL

uma missão equivalente a:

DERROTAR O IMPÉRIO GALÁCTICO,

quebre:

1. Estrutura do programa
2. PIC
3. MOVE
4. COMPUTE
5. IF
6. EVALUATE
7. PERFORM
8. Arquivos
9. VSAM
10. Db2

Agora existem:

linhas de chegada pequenas.

Cada conclusão:

gera sensação de avanço.


🧠 Microgoals

Metas pequenas podem reduzir:

procrastinação

e aumentar:

persistência.

Essa é a versão saudável do Goal Gradient.


👻 Easter Egg nº 1 — TARDIS 99%

Companion:

— Doctor! Terminei 99% do reparo da TARDIS!

— Excelente.

— Vamos viajar?

— O que falta?

— Os freios temporais.

Doctor:

— Então você terminou 99% do checklist e aproximadamente zero por cento da parte que eu gostaria de testar antes de atravessar o espaço-tempo.

Essa é uma lição extraordinariamente importante:

percentual de tarefas concluídas não significa percentual de risco eliminado.


🧠 O problema dos 99%

Imagine:

100 tarefas.

99 são:

relatórios;

labels;

documentação;

scripts;

configurações.

A centésima:

VALIDAR RECUPERAÇÃO DE DADOS

Dashboard:

99% COMPLETE

Risk dashboard:

talvez:

RECOVERY CONFIDENCE:
UNKNOWN

São coisas completamente diferentes.


☕ “Falta pouco” é uma descrição quantitativa

Não qualitativa.


🧠 Completion versus Readiness

Essa distinção deveria existir em praticamente todo projeto crítico.

Você pode ter:

DEVELOPMENT COMPLETE .... 100%

mas:

OPERATIONAL READINESS .... 65%

O código terminou.

O sistema:

não.


🧠 O velho “código pronto”

Programador:

— Código está pronto.

Gerente:

— Excelente! Produção amanhã.

Programador:

— Calma.

Teste?

Integração?

Performance?

Security?

Dados?

Rollback?

Documentação?

Runbook?

Monitoring?

Treinamento?


☕ “Código pronto”

é apenas uma versão tecnológica de:

“O avião está pronto. Só falta descobrir se voa.”


🧠 Os primeiros 90% e os outros 90%

Existe uma piada clássica em desenvolvimento:

Os primeiros 90% do projeto consomem 90% do tempo.
Os últimos 10% consomem os outros 90%.

Matematicamente:

absurdo.

Gerencialmente:

assustadoramente familiar.

Porque o final contém:

integração;

edge cases;

migrations;

bugs;

deploy;

rollback;

acceptance.


🧠 Planning Fallacy entra

Nós subestimamos:

o trabalho restante.

Então chegamos aos:

90%

achando:

“quase acabou”.

Mas talvez aquele 10% seja:

metade do esforço.


💻 COBOL matemático

Imagine:

90 tarefas:

1 hora cada.

10 tarefas:

20 horas cada.

Concluímos:

90 tarefas.

Dashboard:

90%

Horas totais:

90 + 200 = 290

Horas concluídas:

90

Trabalho realizado:

aproximadamente:

31%.

Parabéns.

Seu dashboard acabou de tomar um:

S0C7 conceitual.


🧠 Weighted progress

Poderíamos pesar:

tarefas.

Mas ainda existe problema:

peso também é:

estimativa.

Então:

melhore o indicador.

Mas nunca trate:

como verdade absoluta.


🧠 Goodhart’s Law entra na War Room

Objetivo:

entregar sistema funcional.

Métrica:

tarefas concluídas.

Quando:

tarefas concluídas

viram:

meta,

Goodhart aparece.

A equipe pode:

fechar tickets.

Quebrar trabalho.

Escolher tarefas fáceis.

O número melhora.


☕ Goal Gradient coloca turbo no Goodhart

Se estamos em:

95%,

há ainda mais motivação para:

fechar qualquer coisa que transforme:

95

em:


🧠 Campbell’s Law aparece com o bônus

Agora diga:

“O bônus depende de entregar sexta.”

Pronto.

Metric:

100%.

Money:

attached.

Reputation:

attached.

Executive expectation:

attached.

Aquela barra não é mais:

visualização.

Virou:

parte do sistema de incentivos.


🧠 Goal Gradient + Campbell

Quanto mais perto:

maior a motivação natural.

Quanto maior a consequência:

maior a pressão social.

Resultado:

a reta final fica psicologicamente carregada.


🧠 Goal Substitution

Começamos com:

entregar sistema seguro.

Depois:

completar projeto.

Depois:

atingir 100%.

Agora:

a barra substituiu o objetivo.

Goal Substitution.


☕ O velocímetro virou destino

Mais uma vez.


🧠 Ratchet Effect aparece segunda-feira

Equipe trabalha:

sexta;

sábado;

domingo.

Entrega.

Executivo diz:

— Excelente! Agora sabemos que vocês conseguem.

Próximo projeto:

prazo 20% menor.

Goal Gradient gerou:

heroic sprint.

Ratchet transforma:

heroic sprint

em:

capacidade normal.

Excelente receita para:

burnout.


🌀 O ciclo

META PRÓXIMA
    ↓
MOTIVAÇÃO ↑
    ↓
ESFORÇO HEROICO
    ↓
SUCESSO
    ↓
OUTCOME BIAS
    ↓
RATCHET
    ↓
NOVA META MAIS ALTA

E:

repeat.


🧠 Present Bias

Agora é sexta.

Queremos:

terminar agora.

Custos podem ir:

para segunda.

Então aparecem frases:

“Documentamos depois.”

“Refatoramos depois.”

“Corrigimos isso no hypercare.”

“Depois automatizamos.”

“Depois entendemos a causa.”


AFTER GO-LIVE

É um dataset particularmente perigoso.

Muitos registros entram.

Poucos saem.


🧠 Sunk Cost Fallacy

Projeto:

97%.

Gastamos:

18 meses.

Surge risco grave.

Argumento:

“Não podemos parar agora.”

Por quê?

Talvez exista:

boa justificativa econômica.

Mas talvez sejam:

18 meses já gastos.

Sunk Cost.

Goal Gradient acrescenta:

“E falta só 3%!”

Agora:

passado + proximidade

empurram:

continuidade.


🎯 O teste Bellacosa dos 20%

Quando alguém disser:

“Mas estamos quase acabando!”

pergunte:

“Se estivéssemos em 20%, tomaríamos exatamente essa mesma decisão com essa evidência?”

Se resposta:

não,

pare.

Talvez o progresso esteja:

participando indevidamente da decisão.


🧠 Action Bias na reta final

Um erro aparece.

Todo mundo quer:

fazer alguma coisa.

Porque relógio corre.

A meta está:

perto.

Action Bias:

restart.

Fix.

Patch.

Change.

Agora.

Talvez seja correto.

Mas:

investigue.


☕ O relógio do projeto não é root cause

Mesmo que grite muito.


🧠 Omission Bias

Também podemos acelerar:

não fazendo.

“Pula aquele teste.”

Não parece:

ação perigosa.

É:

omissão.

Mas:

não executar controle

é uma decisão.


🧠 Optimism Bias

Últimos 18 testes:

passaram.

Falta um.

“Vai passar.”

Talvez.

Mas:

não testamos para confirmar esperança.

Testamos justamente porque:

podemos estar errados.


🧠 Recency Bias

Os testes recentes foram:

bons.

Então o futuro parece:

bom.

Mas último teste pode ser:

diferente.


🧠 Confirmation Bias

Queremos lançar.

Então buscamos:

evidências de prontidão.

Os sinais negativos começam a virar:

“detalhes”.


☕ “Detalhe”

é uma palavra que cresce muito perto do deadline.


🧠 Framing Effect

Compare:

97% concluído

com:

rollback não validado

Mesmo projeto.

Emocionalmente:

histórias completamente diferentes.

O primeiro:

convida a continuar.

O segundo:

convida a pensar.


👻 Easter Egg nº 2 — Dalek PMO

Dalek Project Manager:

— PROJECT COMPLETION: 99%.

Doctor:

— O que falta?

— SECURITY VALIDATION.

— Importante?

— POTENTIAL PLANETARY DESTRUCTION.

— Então como vocês chegaram a 99%?

— 99 OF 100 TASKS COMPLETED.

Doctor:

— Vocês transformaram matemática administrativa em avaliação de risco.

Dalek:

— CORRECT.

Doctor:

— Isso não foi elogio.


🧠 Authority Gradient

Agora imagine:

CEO presente.

Diretor.

Gerente.

Todo mundo:

quer lançamento.

Júnior COBOL encontra:

uma inconsistência.

Ele diz?

Esse é outro problema.

Quanto mais perto:

maior pressão:

“Não seja você quem vai atrasar tudo.”


🧠 Psychological Safety

A equipe precisa acreditar:

qualquer pessoa pode:

parar.

Se risco legítimo.

Não importa:

cargo.

Não importa:

97%.


🎯 Pergunta Bellacosa

“Alguém aqui realmente pode dizer NO-GO?”

Não teoricamente.

Realmente.


🧠 Precommitment

Essa é uma defesa fantástica.

Defina antes:

NO-GO SE:

[ ] ROLLBACK NÃO VALIDADO
[ ] RESTORE NÃO TESTADO
[ ] RECONCILIAÇÃO FALHAR
[ ] SEV-1 ABERTO

Defina quando:

ninguém está:

cansado;

pressionado;

apaixonado pelos 97%.

Então:

sexta-feira,

não renegocie.


☕ O checklist protege você

da versão futura de você

que só quer ir para casa.


🧠 Stop the Line

Se condição crítica:

não passou,

status:

NO-GO

Mesmo:

99,9%.


🧠 Um 1% pode conter 100% do desastre

Essa é provavelmente a frase central do artigo.

O percentual mede:

quantidade.

Risco mede:

consequência × probabilidade.

Não são:

a mesma dimensão.


🧠 Segurança e o último quilômetro

Pense num voo.

São Paulo → Lisboa.

Aeronave percorreu:

99% da distância.

Piloto anuncia:

— Já completamos 99%. Vamos pular o checklist de pouso.

Você:

não ficaria particularmente feliz.

Por quê?

Porque:

os últimos minutos não são menos importantes porque o resto já aconteceu.

Na verdade:

pouso é:

fase crítica.


☕ O Go-Live é o pouso

Quanto mais perto:

mais disciplina.

Não:

menos.


🧠 A regra Bellacosa dos últimos 10%

Passou:

90%?

Menos euforia.

Mais:

evidência.

Passou:

95%?

Menos improviso.

Mais:

checklist.

Passou:

99%?

Não pergunte:

quanto falta?

Pergunte:

o que falta?

Essa pequena mudança:

vale ouro.


🧠 Hypercare muda a linha de chegada

Outro erro:

DONE = GO-LIVE

Talvez deveria ser:

DONE =
GO-LIVE
+
STABILITY
+
RECONCILIATION
+
HANDOVER
+
NO CRITICAL DEFECT

Agora:

Goal Gradient continua funcionando.

Mas em direção:

à meta certa.


☕ Esse é o truque

Não eliminar:

Goal Gradient.

Desenhar a linha de chegada corretamente.


🧠 Goal Architecture

Projetamos:

arquitetura de software.

Também deveríamos projetar:

arquitetura de metas.

Qual é:

objetivo real?

O que é:

milestone?

O que é:

proxy?

O que é:

Done?

Quais:

guardrails?


🧠 Exemplo ruim

Goal:

GO LIVE FRIDAY

Exemplo melhor:

SERVICE OPERATIONAL
WITH VALIDATED DATA
AND RECOVERABILITY

Sexta-feira:

é data.

Não:

outcome.


🧠 Goal Gradient no aprendizado COBOL

Agora vamos usar:

a favor.

Você é iniciante.

Não diga:

vou estudar COBOL.

Faça:

COBOL FILES

[✔] SELECT
[✔] FD
[✔] OPEN
[✔] READ
[ ] FILE STATUS
[ ] LAB

Agora:

4/6.

Seu cérebro:

quer os dois restantes.

Excelente.


🧠 Mas o LAB deve ficar no final

Porque o objetivo:

não é:

assistir aulas.

É:

fazer.


☕ O certificado diz:

“você terminou”.

O laboratório diz:

“você aprendeu alguma coisa”.

Diferente.


🧠 Goal Gradient + Campbell na educação

Empresa exige:

100% treinamento.

Pessoa está:

95%.

Deadline:

hoje.

Assiste:

restante em 2x.

Completion:

100%.

Skill:

?

Goal Gradient:

cumpriu.

Campbell:

pressionou.

Goal Substitution:

concluir virou aprender.

Goodhart:

score verde.

Belo crossover.


🧠 War Room: 95% recuperado

Outro cenário.

Incidente.

Sistema:

95% funcional.

Todos cansados.

Alguém diz:

“Podemos encerrar.”

Mas:

5% dos clientes continuam:

sem serviço.

Para eles:

availability:

0%.


☕ Média corporativa não consola o cliente quebrado

Isso vale lembrar.


🧠 Tail Neglect

A maioria:

voltou.

Agora long tail:

parece menor.

Mas pode conter:

clientes críticos.

Não encerre:

pela porcentagem.


🧠 Goal Gradient em RCA

Estamos quase fechando:

root cause.

Hipótese:

Db2.

Tudo encaixa.

Exceto:

uma mensagem MQ.

Alguém diz:

“Isso provavelmente não tem relação.”

Narrative Bias.

Confirmation Bias.

Goal Gradient.

Todos querem:

fechar RCA.

Mas o pequeno sinal pode:

ser justamente:

a causa real.


🎯 Pergunta Bellacosa

“Qual evidência relevante nossa explicação ainda não consegue explicar?”

Não feche:

porque a história ficou bonita.


☕ House MD aparece

Equipe:

— Todos os sintomas indicam lupus.

House:

— Exceto aquele.

Equipe:

— Talvez não importe.

House:

— Então é exatamente por ele que começaremos.

Em incidentes:

o log estranho

é:

o sintoma estranho.


🧠 Premature Closure

Diagnóstico plausível aparece.

Investigação:

para.

Goal Gradient pode:

aumentar atração pelo encerramento.

Ticket:

CLOSED.

RCA:

DONE.

Dopamina.


CLOSED não é sinônimo de:

CORRECT.


🧠 Goal Gradient em Agile

Sprint termina amanhã.

Temos:

9/10 STORIES

A última:

quase.

Tentação:

DONE.

Teste:

amanhã.

Documentation:

depois.

Agora:

velocity ficou linda.

Quality?

Depois.

Definition of Done protege.


🧠 Definition of Done

DONE =
CODED
AND
TESTED
AND
REVIEWED
AND
DEPLOYABLE

Sem:

90% Done.


☕ “Quase Done”

é:

IN PROGRESS.

Eu sei.

Dói.


🧠 WIP Limits

Kanban ajuda:

não manter:

dez itens a 90%.

Melhor:

nove concluídos,

um em progresso.

Goal Gradient então incentiva:

finish.

Isso é bom.


🧠 Deadline Gradient

Existe também:

o efeito do prazo.

Quanto mais perto:

mais urgência.

Goal Gradient e deadline frequentemente:

viajam juntos.

Resultado:

Student Syndrome.


☕ Prazo sexta

Trabalho começa:

quinta.

O scheduler humano possui:

algumas peculiaridades.


🧠 SLA

Ticket SLA:

4 horas.

Se prioridade só aumenta:

aos 3h50,

você criou:

cliff.

Equipe aprende:

trabalhar perto do breach.

Better:

escalation gradual.


☕ WLM para humanos

Talvez seja uma ideia.

Não espere:

SERVICE CLASS = PANIC.


🧠 Goal Gradient em vendas

Meta:

R$1 milhão.

Estamos:

R$930 mil.

Últimos dias:

desconto.

Negócios antecipados.

Venda futura:

puxada.

Meta:

100%.

Margem:

cai.

Janeiro:

vazio.

Goal Gradient + Present Bias.


🧠 IT equivalent

Fim de sprint.

Tickets:

puxados.

Technical debt:

empurrada.

Mesma dinâmica.


🧠 O projeto condenado em 95%

Outro ponto crítico.

Projeto:

95%.

Novo estudo mostra:

não há mais business case.

Falta:

R$10 milhões.

Benefício futuro:

R$2 milhões.

O racional:

parar.

Mas alguém diz:

“Depois de tudo isso?”

Sunk Cost.

Outro:

“Mas só faltam 5%!”

Goal Gradient.

Agora:

duas forças emocionais

contra:

matemática.


🎯 Pergunta Bellacosa

“Se começássemos hoje, pagaríamos o custo restante para obter apenas o benefício futuro restante?”

Se não:

talvez terminar seja erro.


🧠 Kill Criteria

Defina no começo:

STOP PROJECT IF:

BUSINESS CASE < X
COST TO COMPLETE > VALUE
TECHNICAL RISK > LIMIT
REGULATORY NEED DISAPPEARS

Assim:

o 95%

não ganha autoridade moral.


🧠 Goal Gradient pode ser herói

Agora equilíbrio.

Migração legada:

faltam três interfaces.

Ninguém quer:

mexer.

O sistema antigo continua:

vivo.

Mostre:

3
2
1
0

Goal Gradient:

aumenta motivação.

Excelente.


☕ Finalmente desligar o zumbi

é um uso perfeitamente digno.


🧠 Backlog enorme

2.000 itens:

desanimador.

Crie:

lote:

TOP 20 RISCOS

Resolva.

Progress:

visível.

Depois:

próximo.

Chunking + Goal Gradient.


🧠 Mas não escolha apenas os fáceis

Senão:

Easy Task Bias.

Goodhart.

Precisamos:

prioridade por:

valor/risco.


☕ Barra andando rápido

não significa:

problema sendo resolvido rápido.


🧠 Critical Path

Projeto:

90% tarefas done.

Critical path:

bloqueado.

Schedule:

atrasado.

Count:

irrelevante.

Acompanhe:

dependências críticas.


🎯 Pergunta Bellacosa

“Estamos reduzindo a incerteza real ou apenas fazendo checkboxes ficarem verdes?”

Essa pergunta serve:

para quase tudo.


🧠 Risk First

Faça cedo:

integrações difíceis;

data migrations;

performance tests;

unknowns.

Não deixe:

dragões

para:

97%.


☕ Mate o dragão

antes de distribuir os convites para a festa.


🧠 Goal Gradient e fadiga

Essa combinação merece atenção.

Meta aproxima.

Esforço:

sobe.

Fadiga:

sobe.

Capacidade cognitiva:

pode cair.

Então:

queremos agir mais exatamente quando nossa capacidade de decidir bem pode estar piorando.


🧠 War Room longa

02:37.

Alguém:

— Falta só um comando.

Talvez.

Mas quem está digitando:

está há 18 horas acordado.


ENTER

continua tendo o mesmo tamanho

mesmo quando o cérebro está cansado.

O impacto também.


🧠 Rotação

Em incidentes longos:

troque pessoas.

Fresh eyes.

Registre decisões.

O objetivo:

não é:

heroísmo.

É:

resolver.


🧠 Fresh Eyes Review

Antes do Go-Live:

chame alguém:

não emocionalmente envolvido.

Mostre:

remaining risks.

Não:

97%.

Pergunte:

go/no-go?


🎯 Blind Risk Review

Esse é um excelente truque:

não conte:

percentual.

Diga apenas:

rollback não testado; restore parcial; reconciliação incompleta.

Pergunte:

lançaria?

Agora compare resposta:

com aquela dada quando viram:

97%.

Se mudou:

hello Goal Gradient.


🧠 Pre-Mortem

Estamos em:

95%.

Em vez de:

“Como terminamos?”

pergunte:

“Imagine que segunda-feira virou desastre. O que provavelmente ignoramos hoje?”

Isso abre:

visão.


🧠 Devil’s Advocate

Dê a alguém:

função oficial:

argumentar NO-GO.

Assim:

discordar deixa de ser:

hostilidade.

Vira:

papel.


☕ O pessimista oficial

às vezes salva:

um fim de semana inteiro.


🧠 Goal Gradient e Groupthink

Todos:

animados.

Meta:

perto.

Ninguém quer:

estragar clima.

Groupthink.

Authority Gradient.

Goal Gradient.

Perfeito para:

esconder sinal fraco.


🎯 Pergunta Bellacosa

“Quem nesta sala está autorizado a ser inconveniente?”

Essa pessoa:

é controle de segurança.


🧠 Scope Creep final

Perto do Go-Live aparece:

— Já que estamos mexendo...

Não.

Freeze.

Última hora:

não é momento:

para feature.


☕ A feature “rapidinha”

das 17:30

tem tradição própria.


🧠 Goal Gradient e AI Agents

Agora entramos num ponto moderno.

Imagine agente:

objetivo:

100 tarefas.

Ele completou:

Reward:

alto em 100.

Pode intensificar:

ações.

Talvez:

criar subtasks simples.

Cobra Effect.

Talvez:

marcar tarefa como concluída cedo.

Goodhart.

Talvez:

assumir risco.

Moral Hazard.


🤖 Guardrails devem ser invariáveis

Nunca:

IF PROGRESS > 95
    REDUCE SAFETY
END-IF

Absurdo para código.

Surpreendentemente familiar:

para humanos.


🧠 Completion Reward

Agentes são particularmente sensíveis à:

função objetivo.

Se completion tem:

reward enorme,

precisamos verificar:

resultado real.


TASK STATUS = DONE

não significa:

universo concordou.


🧠 Goal Gradient e automação de incidentes

Auto-remediation:

95% serviço recuperado.

Último componente:

stateful.

Não force:

porque falta pouco.

Use:

risk policy.

Business priority.


🧠 WLM sabe disso

z/OS WLM não deveria pensar:

“Esse job já executou 98%, então agora tudo deve sair da frente.”

Ele considera:

service goals.

Importance.

Policy.

Humanos também precisam.


☕ Mainframe ensinando psicologia outra vez

Não é pouca coisa.


🧠 Goal Gradient e Error Budgets

Um exemplo interessante de efeito usado:

para cautela.

Error budget:

está perto de acabar.

Conforme limite aproxima:

equipe reduz:

changes arriscadas.

Aqui proximidade do objetivo/limite:

muda comportamento na direção:

segura.

Excelente.


🧠 O segredo está em definir a meta

Se meta:

“sexta-feira”,

corremos:

para sexta.

Se meta:

“30 dias estáveis”,

corremos:

para estabilidade.


🎯 Pergunta Bellacosa central

“Nossa linha de chegada está localizada no lugar certo?”

Porque comportamento:

irá gravitar em direção a ela.


🧠 Goal Gradient + Metric Fixation

Agora nosso capítulo anterior entra.

Se dashboard mostra:

97%,

Metric Fixation pode fazer:

organização acreditar que:

97%

é:

realidade objetiva.

Goal Gradient então:

acelera.

Combinação:

o número ganha autoridade e proximidade ganha urgência.


☕ Resultado:

barra de progresso vira:

Incident Commander.

Não deveria.


🧠 Metric Fixation antidote

Não mostre somente:

97%

Mostre:

DELIVERY ........ 97%
RECOVERY ........ 60%
DATA ............ 75%
OPS READINESS ... 68%
SECURITY ........ 92%

Agora:

menos sexy.

Mais útil.


🧠 Risk retired

Outra alternativa:

quanto risco eliminamos?

Não apenas:

tasks.


🧠 Goal Substitution antidote

Coloque objetivo em cima:

GOAL:
SAFE AND CORRECT PAYMENT PROCESSING

Depois:

metrics.

Não o contrário.


☕ Métrica abaixo.

Missão acima.

Literalmente.


🧠 A TARDIS cognitiva completa

Veja como os capítulos se conectam:

Goal Substitution: escolhemos proxy e esquecemos objetivo.

Metric Fixation: tratamos proxy como realidade.

Goodhart: o proxy vira meta e degrada.

Campbell: consequência social aumenta pressão.

Goal Gradient: proximidade da meta aumenta esforço.

Ratchet: sucesso vira nova meta mínima.

Cobra Effect: incentivo pode começar a produzir o próprio problema.

Sunk Cost: investimento passado dificulta parar.

Present Bias: custos futuros são empurrados para depois.

Action Bias: pressão manda agir.

Omission Bias: também podemos pular controles.

Optimism Bias: acreditamos que vai funcionar.

Authority Gradient: ninguém quer contrariar liderança.

Quando todos aparecem:

você não tem:

um simples projeto.

Você tem:

um crossover especial de duas horas da BBC chamado “The Go-Live of Doom”.


👻 Easter Egg nº 3 — Doctor pergunta ao dashboard

Doctor:

— Estamos prontos?

Dashboard:

— 99%.

Doctor:

— Não perguntei quanto terminamos.

— 99%.

— Perguntei se estamos prontos.

— 99%.

Doctor olha para Companion.

— Acho que o dashboard entrou em management.


🧠 Bellacosa Last Mile Review

Quando passar de:

90%,

rode:

WHAT REMAINS?

WHAT IS CRITICAL?

WHAT IS UNTESTED?

WHAT IS IRREVERSIBLE?

WHAT WOULD MAKE US STOP?

WHO CAN SAY NO?

WHAT HAPPENS AFTER GO-LIVE?

IS THIS SUSTAINABLE?

Muito mais poderoso:

que:

97%

🧪 Passo a passo para usar Goal Gradient corretamente

Passo 1 — Defina o outcome

Não:

“100% complete.”

Mas:

“serviço operando corretamente.”

Passo 2 — Quebre em milestones

Metas próximas:

motivam.

Passo 3 — Faça progresso visível

Use:

barra;

checklist;

countdown.

Passo 4 — Não trate tasks como pesos iguais

Criticality.

Risk.

Effort.

Passo 5 — Faça hard things cedo

Risk first.

Passo 6 — Defina No-Go antecipadamente

Antes:

da pressão.

Passo 7 — Preserve safety gates

Sem negociação:

por proximidade.

Passo 8 — Observe fadiga

Hero mode:

não é grátis.

Passo 9 — Use pre-mortem

Imagine:

falha.

Passo 10 — Mova Done para depois do Go-Live

Inclua:

stability.


📋 Checklist Bellacosa anti-Goal Gradient

[ ] Estamos perto da meta?

[ ] Isso mudou nossa tolerância a risco?

[ ] O que exatamente falta?

[ ] O que falta é crítico?

[ ] Estamos usando task count como readiness?

[ ] Se estivéssemos em 20%, decidiríamos igual?

[ ] Rollback está testado?

[ ] Restore está validado?

[ ] Reconciliação está completa?

[ ] Existe critério No-Go?

[ ] Alguém pode dizer não?

[ ] Estamos cansados?

[ ] Estamos em heroic mode?

[ ] Algum controle foi chamado de “detalhe”?

[ ] Go-Live foi confundido com Done?

🧠 O teste “quanto” versus “o quê”

Gerente:

— Falta quanto?

Resposta:

— 3%.

Pergunta ruim.

Melhor:

— Falta o quê?

Resposta:

— rollback, restore e reconciliation.

Agora temos:

informação.


☕ Nunca pergunte apenas:

quanto falta?

Pergunte:

o que existe dentro do que falta?

Essa talvez seja a melhor frase deste café.


🧠 Goal Gradient no desenvolvimento pessoal

Também use:

para estudar.

Se learning path tem:

40 módulos,

crie:

mini objetivos.

5 módulos.

Lab.

Review.

Outro bloco.

Assim:

Goal Gradient reaparece várias vezes.


🧠 Mas evite binge completion

Chegou:

95%.

Não corra pelo conteúdo:

para badge.

Use energia final:

para revisão.

Lab.

Teste.


☕ Faça a última etapa provar conhecimento

não apenas:

clicar em “concluir”.


🧠 Goal Gradient e certificação

Antes da prova:

course:

100%.

Isso não é:

readiness.

Faça:

mock exam.

Weakness analysis.

Lab.

Again:

Completion ≠ readiness.


🧠 A linha de chegada errada

Se sua meta:

“terminar curso”,

Goal Gradient ajuda terminar.

Se meta:

“ser capaz de resolver problema”,

precisa:

lab.

Defina certo.


🧠 Goal Gradient e projetos de migração

Mostrar:

40 sistemas
↓
12
↓
5
↓
2
↓
0

pode ser:

excelente.

Long tail:

ganha atenção.

Mas:

últimos sistemas tendem a ser:

os mais difíceis.

Por quê?

Os fáceis:

já foram.

Então:

remaining work não é amostra aleatória.


🎯 Pergunta Bellacosa

“Esses últimos itens sobraram por acaso ou justamente porque são os mais difíceis?”

Muito importante.


🧠 Selection Effect

Migração:

95% nodes done.

5% failed.

Não diga:

“95% funcionou, então force os outros.”

Os outros 5% foram:

selecionados por falhar.

Possuem:

características diferentes.


☕ O último servidor talvez não seja azarado

Talvez seja:

professor.


🧠 Goal Gradient em security remediation

100 vulnerabilities.

90 low.

10 critical.

90% closed.

Mas:

risk?

Talvez:

20% reduced.

Use:

risk-weighted progress.


🧠 Quantity versus consequence

Reaparece.


🧠 Goal Gradient e observabilidade

Se só existe:

progress score,

Metric Fixation.

Adicione:

remaining risk.

Unknowns.


UNKNOWN

é permitido.

Muito mais honesto que:

97.3%.


🧠 Goal Gradient e continuidade

Backup migration:

99%.

Remaining:

key encryption validation.

Não force.

Sometimes:

last task

contains:

entire control.


👻 Easter Egg nº 4 — COBOL

Nosso jovem encontra:

BELLACOSA.BIAS(GOAL-GRADIENT)

Código:

       IF PROJECT-PERCENT > 90
           PERFORM REVIEW-REMAINING-RISK
       END-IF.

       IF PROJECT-PERCENT > 95
          AND ROLLBACK-VALIDATED = 'N'
           MOVE 'NO-GO'
             TO RELEASE-STATUS
       END-IF.

       IF TEAM-SAYS 'FALTA-POUCO'
           PERFORM ASK-WHAT-REMAINS
       END-IF.

       IF REMAINING-ITEM = 'CRITICAL'
           MOVE ZERO
             TO IMPORTANCE-OF-PERCENT.

Comentário:

* 99% COMPLETE
* IS NOT
* 99% SAFE.

Outro:

* DO NOT ASK
* HOW LITTLE IS LEFT.
*
* ASK WHAT IS LEFT.

Outro:

* PROGRESS BAR
* HAS NO CHANGE AUTHORITY.

E naturalmente:

* TARDIS REPAIR: 99%
*
* REMAINING ITEM:
* BRAKES.
*
* STATUS:
* NO-GO.

🕰️ Voltamos para sexta-feira, 17:42

Dashboard:

97%

Gerente:

— Então vamos?

Nosso jovem olha:

ROLLBACK:
NOT VALIDATED

— Não.

— Mas estamos praticamente terminando.

— Estamos terminando tarefas.

— E qual é a diferença?

Ele aponta:

para o sistema.

— Quero saber se estamos terminando o projeto ou apenas terminando o checklist.

Silêncio.

Doctor sorri.


🔧 Go-Live adiado

Teste de rollback:

sábado de manhã.

Primeira tentativa:

falha.

Silêncio na sala.

Descobrem:

uma alteração de schema incompatível com:

rollback antigo.

Corrigem.

Testam novamente.

Passa.

Restore:

passa.

Reconciliation:

passa.

Agora:

DELIVERY ............ 100%
ROLLBACK ............ PASS
RESTORE ............. PASS
RECONCILIATION ...... PASS
OPS READINESS ....... PASS

Agora sim.

Go-Live.


☕ Segunda-feira

Nenhum incidente crítico.

Gerente encontra:

nosso jovem.

— Aqueles 3%...

— Sim.

— Eram pequenos no dashboard.

— Sim.

— Mas continham quase todo o risco restante.

— Exatamente.

Gerente toma café.

— Então devemos parar de usar porcentagem?

— Não.

— Então qual é a lição?

Nosso jovem sorri.

“Use porcentagem para saber quanto avançamos. Não para decidir sozinho se estamos seguros para continuar.”

Boa.


🧬 Regeneração organizacional

Uma organização madura entende que Goal Gradient é:

força psicológica.

Não:

defeito.

Ela usa:

milestones;

progress bars;

countdowns;

small wins.

Mas também:

protege:

quality;

safety;

rollback;

evidence;

recovery;

human judgment.

Ela sabe que a reta final:

aumenta motivação.

Por isso:

aumenta disciplina.

Principalmente:

ela não confunde:

“falta pouco”

com:

“o que falta importa pouco.”


📓 Diário do Doctor

Se guardar algumas coisas desta viagem:

Goal Gradient Effect descreve a tendência de aumentar motivação e esforço conforme percebemos maior proximidade de uma meta.

Ele pode ser usado positivamente em aprendizagem, migrações, backlog e projetos longos.

Progress bars funcionam porque tornam proximidade visível.

Endowed Progress mostra como progresso inicial percebido pode aumentar engajamento.

Percentual de tarefas concluídas não significa percentual de risco eliminado.

Completion e readiness são coisas diferentes.

Os últimos 5% podem conter justamente cutover, rollback, restore e reconciliation.

Goal Gradient combina perigosamente com Sunk Cost, Present Bias, Action Bias, Confirmation Bias e Authority Gradient.

Goodhart aparece quando completar a barra passa a importar mais que o outcome.

Campbell aumenta a pressão quando bônus e reputação estão ligados à conclusão.

Goal Substitution pode colocar a linha de chegada no lugar errado.

Metric Fixation pode transformar o percentual em uma falsa descrição completa da realidade.

Ratchet pode transformar o esforço heroico da reta final em nova capacidade esperada.

Defina No-Go antes de ficar emocionalmente perto demais da meta.

Pergunte “o que falta?”, não apenas “quanto falta?”.

E principalmente:

o fato de restar apenas 1% não significa que esse 1% seja pouco importante. Às vezes é justamente ali que alguém guardou o freio.


🥚 Easter Egg final

Antes de entrar na TARDIS, o Doctor deixa uma última mensagem no terminal:

IF PROJECT = 99-PERCENT-COMPLETE
   AND EVIDENCE = INCOMPLETE
      MOVE 'NOT-READY'
        TO STATUS
END-IF.

Nosso jovem pergunta:

— Doctor, uma organização realmente adiaria um projeto em 99% por causa de uma evidência crítica?

Ele olha para a TARDIS.

— Uma organização madura?

Pausa.

— Sim.

— E uma imatura?

Doctor abre a porta.

— Ela provavelmente terá uma ótima história para o postmortem.

VWORP.

VWORP.

VWORP.

A TARDIS desaparece.

Na War Room fica apenas:

97% pronto não é argumento técnico.

E abaixo:

“A linha de chegada pode nos fazer correr mais rápido. O trabalho da engenharia é garantir que não corramos mais rápido justamente na direção do precipício.”

☕🌀

Próxima parada: McNamara Fallacy — quando começamos medindo aquilo que é fácil, depois ignoramos aquilo que é difícil de medir e acabamos concluindo que tudo o que não cabe no dashboard simplesmente não existe.

segunda-feira, 14 de outubro de 2013

O BBS dos Yōkai — Parte II : Quando os fantasmas aprenderam TCP/IP: Kisaragi, Kunekune, Hachishakusama e as criaturas nascidas na Internet japonesa

 

Bellacosa Mainframe e o bbs dos yokai parte ii

☕ Um Café no Bellacosa Mainframe

O BBS dos Yōkai — Parte II

Quando os fantasmas aprenderam TCP/IP: Kisaragi, Kunekune, Hachishakusama e as criaturas nascidas na Internet japonesa

Dos fóruns anônimos ao Nico Nico Douga — uma expedição pelos lugares onde ficção, testemunho, meme e folclore digital deixaram de ter fronteiras claras

Por Vagner Bellacosa


Na primeira parte desta nossa escavação arqueológica encontramos algo perturbador.

O folclore não morreu quando chegaram os computadores.

Ele simplesmente ganhou modem.

A antiga sequência:

fogueira → história → viajante → aldeia → nova versão

transformou-se em:

BBS → fórum → repost → imageboard → blog → vídeo → anime → meme.

A humanidade continuou fazendo exatamente aquilo que sempre fez.

Contando histórias.

Modificando histórias.

Esquecendo quem inventou as histórias.

E jurando que aconteceram com o primo de alguém.

Mas deixamos algumas caixas fechadas no depósito do nosso museu arqueológico.

Está na hora de abri-las.

Pegue o café.

Ligue o terminal.

$HASP373 YOKAI2 STARTED

ARCHAEOLOGICAL LAYER: DEEP
ORIGINAL AUTHOR: UNKNOWN
NETWORK STATUS: CONNECTED

WARNING:
SOME ENTITIES MAY HAVE ESCAPED THE DATASET

Hoje vamos procurar justamente aquelas criaturas que talvez não existissem da mesma maneira sem a Internet.

Não são apenas yōkai antigos digitalizados.

São algo diferente.

São os yōkai da rede.


👻 1. O fantasma mudou de endereço

Durante séculos, fantasmas precisavam de lugares adequados.

Castelos.

Florestas.

Montanhas.

Casas abandonadas.

Cemitérios.

Estradas.

Poços.

Banheiros escolares.

Então apareceu a Internet.

E alguém percebeu que um fantasma também poderia morar em:

/thread/928374/

Essa mudança parece pequena.

Não é.

O ambiente onde uma história é contada modifica profundamente a própria história.

Imagine uma lenda tradicional.

Alguém diz:

“Há muitos anos, um viajante encontrou uma mulher naquela estrada.”

Automaticamente sabemos que estamos ouvindo uma história.

Agora imagine:

“Estou dentro de um trem e aconteceu uma coisa estranha.”

E abaixo aparece:

投稿日:2004/01/08

A pessoa aparentemente está online.

Agora.

Outros usuários respondem.

“Qual estação?”

“Olhe pela janela.”

“Ligue para alguém.”

“Você consegue ver o nome da estação?”

O fantasma ganhou tempo real.

Isso muda completamente o jogo.


🚉 2. Kisaragi Station — o yōkai que virou infraestrutura

Na Parte I visitamos rapidamente a famosa Kisaragi Station, ou Kisaragi Eki.

Agora precisamos voltar.

Porque Kisaragi representa uma mudança importante no folclore digital.

A história apareceu em 2004 no 2channel.

Uma usuária conhecida como Hasumi relata estar viajando de trem.

Há algo errado.

O trem deveria parar.

Não para.

O trajeto continua durante tempo demais.

Finalmente surge uma estação.

きさらぎ駅

Kisaragi Station.

O problema é simples.

A estação aparentemente não existe.

Aqui começa a genialidade.

Não apareceu um monstro.

Não apareceu uma mulher sem rosto.

Não apareceu um demônio.

A coisa sobrenatural é:

uma estação ferroviária.

Infraestrutura tornou-se entidade.

Isso é extraordinariamente moderno.

O terror não está numa floresta ancestral.

Está dentro do sistema ferroviário.

Você entrou no trem correto.

Na plataforma correta.

No horário correto.

E mesmo assim foi parar fora do mapa.

Para um programador mainframe, isso é particularmente aterrorizante.

O JOB executou normalmente.

COND CODE 0000.

Só que produziu o arquivo no universo errado.


🗺️ 3. O horror dos lugares impossíveis

Kisaragi toca num medo extremamente poderoso:

o lugar familiar que deixou de obedecer às regras.

Todo mundo que utiliza transporte público conhece determinadas expectativas.

Estações aparecem numa sequência.

Há horários.

Mapas.

Placas.

Linhas.

Rotas.

A infraestrutura promete previsibilidade.

Quando essa previsibilidade quebra, aparece algo profundamente desconfortável.

Imagine pegar o metrô em São Paulo.

Sé.

Liberdade.

São Joaquim.

Vergueiro.

Paraíso.

Então:

Estação Bellacosa.

Você olha o mapa.

Não existe.

As portas abrem.

A plataforma está vazia.

Seu celular continua funcionando.

Você escreve:

“Pessoal, alguém conhece a Estação Bellacosa?”

Um usuário responde:

“Não desça.”

Tarde demais.

As portas fecharam atrás de você.

Pronto.

O Brasil ganhou seu próprio Kisaragi.

😂


🌾 4. Kunekune — quando a baixa resolução fabrica um monstro

Agora viajamos para áreas rurais.

Ao longe existe alguma coisa branca.

Ela parece estar se movendo.

Talvez balançando.

Talvez contorcendo.

Você não consegue identificar.

Alguém olha melhor.

E alguma coisa acontece.

Bem-vindo ao Kunekune.

O nome está associado ao verbo japonês relacionado a contorcer-se ou serpentear.

As histórias normalmente descrevem uma figura branca distante, encontrada em campos ou áreas rurais, movendo-se de maneira impossível.

O detalhe importante:

não tente entender o que ela é.

Em várias versões, observar de longe é relativamente seguro.

Tentar compreender aquilo claramente pode levar à loucura.

Agora pense na beleza disso como criatura da era digital.

Kunekune é quase um artefato de compressão transformado em entidade sobrenatural.

Você vê alguma coisa.

Mas não há resolução suficiente.

O cérebro tenta completar.

Não consegue.

Você aumenta a imagem.

ZOOM 200%

Mais pixels.

ZOOM 400%

Agora parece pior.

ENHANCE

Meu amigo...

Hollywood mentiu para você.

Não existe botão mágico capaz de transformar quatro pixels numa placa de carro perfeitamente legível.

E talvez justamente por isso Kunekune funcione tão bem.

O terror está na impossibilidade de resolver a imagem.


🧠 5. O monstro que ataca pela compreensão

Existe algo filosoficamente delicioso no Kunekune.

Normalmente derrotamos monstros aprendendo sobre eles.

Descobrimos:

fraqueza;

origem;

nome;

padrão;

comportamento.

Conhecimento gera vantagem.

Kunekune inverte a regra.

Conhecimento é o ataque.

Quanto mais claramente você entende aquilo, maior o perigo.

Imagine isso como sistema de segurança:

ENTITY: KUNEKUNE

DISTANCE > 500m:
STATUS = SAFE

VISUAL RESOLUTION = LOW:
STATUS = SAFE

IDENTIFICATION ATTEMPT:
WARNING

SEMANTIC RESOLUTION > 80%:
CRITICAL

OBJECT FULLY UNDERSTOOD:
SYSTEM FAILURE

Lovecraft provavelmente aprovaria.

O programador COBOL, por outro lado, simplesmente colocaria:

IF KUNEKUNE = UNKNOWN
   CONTINUE
ELSE
   STOP RUN
END-IF.

Às vezes ignorar problema é estratégia de sobrevivência.

Não recomendaria em produção.

Mas contra entidades interdimensionais podemos abrir exceção.


📏 6. Hachishakusama — oito pés de problema

Agora encontramos outra criatura que se tornou extremamente conhecida dentro e fora do Japão:

Hachishakusama.

O nome significa aproximadamente:

“Senhora de oito shaku.”

Um shaku é uma antiga unidade japonesa próxima de 30 centímetros.

Oito shaku colocariam a entidade perto de 2,4 metros.

Portanto:

uma mulher absurdamente alta.

Mas altura não é a única característica memorável.

Ela também está associada a um som:

Po... po... po...

E aqui temos uma aula perfeita sobre criação de monstros.

Você não precisa fornecer vinte páginas de descrição.

Precisa de alguns elementos inesquecíveis.

Mulher.

Muito alta.

Roupa clara.

Chapéu.

Som estranho.

PO

PO

PO

Pronto.

Seu cérebro faz o resto.


🔊 7. O áudio como assinatura sobrenatural

Isso é importante.

Monstros eficientes possuem assinaturas.

Freddy Krueger tem elementos reconhecíveis.

Jason tem sua máscara.

Sadako tem o cabelo e a televisão.

Hachishakusama tem:

altura + aparência + som.

E o som é particularmente poderoso porque permite anunciar a criatura antes de mostrá-la.

Imagine uma adaptação audiovisual.

Silêncio.

Uma criança está sozinha.

Nada acontece.

Então, muito distante:

Po.

Ela para.

Silêncio.

Po.

Agora o espectador já sabe.

Não precisamos mostrar nada.

Esse mecanismo existe também no nosso folclore.

O som pode preceder a entidade.

Assobio.

Passos.

Corrente.

Choro.

Canto.

Berrante.

Lembra da nossa conversa?

Um universo brasileiro poderia ensinar ao espectador durante vários episódios que determinado som significa determinada coisa.

Depois basta tocá-lo.

O público completa o monstro sozinho.


🚽 8. Hanako-san encontra a Loira do Banheiro novamente

Não podemos atravessar a arqueologia japonesa sem voltar aos banheiros escolares.

Hanako-san é uma das mais conhecidas lendas escolares japonesas.

Dependendo da versão, existe determinado banheiro, determinado cubículo, determinado ritual.

E lá está Hanako.

A estrutura é irresistivelmente parecida com nossa experiência brasileira da Loira do Banheiro.

Novamente:

não precisamos concluir que uma deriva diretamente da outra.

Muito mais interessante é perguntar:

por que banheiros escolares produzem fantasmas tão facilmente?

Pense como criança.

Banheiro é um dos poucos lugares da escola onde você pode ficar isolado.

Existem portas.

Espelhos.

Cabines fechadas.

Ruídos.

Água.

Corredores vazios.

E, frequentemente, regras sociais sobre privacidade.

É praticamente um engine procedural de terror.

SCHOOL + CHILDREN + BATHROOM + MIRROR + DARKNESS
              ↓
      URBAN LEGEND GENERATOR

Se acrescentarmos:

“Minha prima viu.”

temos versão production-ready.


🚆 9. Densha Otoko — quando a Internet escreveu uma vida

Mas nem todo folclore da Internet japonesa envolve fantasmas.

Um dos casos culturalmente mais fascinantes é Densha Otoko — Train Man.

A história gira em torno de um homem associado à cultura otaku que teria ajudado uma mulher após um incidente num trem e depois recorrido a usuários de um fórum online para obter conselhos sobre como desenvolver o relacionamento.

A narrativa ganhou enorme popularidade.

Foi transformada em livro.

Mangá.

Filme.

Série de televisão.

E então aparece a pergunta arqueológica inevitável:

quanto da história realmente aconteceu?

Talvez tudo.

Talvez parte.

Talvez tenha sido dramatizada.

Talvez tenha sido construída.

Mas observe algo muito mais importante:

isso deixou de importar culturalmente.

Densha Otoko tornou-se história.

O fórum virou coro grego.

Milhares de desconhecidos participavam emocionalmente do desenvolvimento de uma relação.

Muito antes de influencers transmitirem suas vidas diariamente, comunidades online já estavam transformando acontecimentos pessoais em narrativa coletiva.


❤️ 10. O protagonista não estava sozinho

Densha Otoko também introduz uma dinâmica fascinante.

Nos romances tradicionais:

protagonista → problema → decisão.

Aqui:

protagonista → problema → fórum → 500 opiniões → decisão → volta ao fórum.

😂

Qualquer pessoa que já perguntou algo na Internet conhece o fenômeno.

“Ela respondeu isso. O que vocês acham?”

USER001:

“ELA GOSTA DE VOCÊ.”

USER002:

“CORRA.”

USER003:

“Pergunte diretamente.”

USER004:

“Minha ex fez exatamente isso.”

USER005:

“Compra um PC novo.”

Sempre existe esse sujeito.

O fórum torna-se personagem.

Isso antecipa algo profundamente contemporâneo:

a multidão digital participando da vida individual.


🖥️ 11. OS-tan — quando sistemas operacionais viraram garotas

Agora entramos numa região absolutamente maravilhosa da cultura otaku digital.

Imagine olhar para um sistema operacional e pensar:

“Isso seria uma garota.”

Bem-vindo ao universo das OS-tan.

Versões de sistemas operacionais passaram a ser antropomorfizadas como personagens, especialmente dentro da cultura de imageboards.

Características técnicas viravam características de personalidade.

Problemas de software viravam defeitos comportamentais.

Compatibilidade virava relacionamento.

Versões diferentes viravam irmãs.

Isso é antropomorfização aplicada à informática.

E, francamente, programadores fazem isso o tempo inteiro.

“O CICS está nervoso hoje.”

“O Db2 não gostou dessa query.”

“O RACF não deixou.”

“O JES comeu meu JOB.”

Estamos a uma saia escolar de distância de criar:

z/OS-tan.

😂


👩‍💻 12. Se o Bellacosa Mainframe tivesse uma OS-tan

Imagine.

z/OS-tan.

Uma senhora elegantíssima.

Não uma adolescente.

Ela está trabalhando há décadas.

Roupa impecável.

Nunca perde uma transação.

Carrega documentação de 12 mil páginas.

Quando alguém pergunta:

“Você ainda está funcionando?”

Ela responde:

“Meu filho, eu estava processando bilhões enquanto seu framework ainda era ideia.”

😂

Ao lado dela:

COBOL-tan.

Sessenta anos.

Aparenta trinta.

Todo mundo diz que vai morrer.

Ela ignora.

Continua processando folha de pagamento.

Isso mostra por que OS-tan é culturalmente interessante.

Não é apenas “anime girl”.

É uma maneira humana de transformar características abstratas de tecnologia em personagens compreensíveis.

Folclore tecnológico.


😶 13. Yukkuri — o meme que escapou do laboratório

Outro fenômeno peculiar é o universo Yukkuri.

Cabeças estilizadas derivadas de personagens associadas ao universo Touhou começaram a circular em comunidades japonesas.

A expressão:

ゆっくりしていってね!!!

algo como:

“Fique à vontade!” / “Vá com calma!”

tornou-se parte do meme.

Mas, como frequentemente acontece na Internet, o meme começou a sofrer mutações.

Imagens.

Vídeos.

Vozes sintetizadas.

Histórias.

Personagens.

Subculturas próprias.

E chega um momento em que alguém encontra uma imagem Yukkuri sem conhecer absolutamente nada sobre sua origem.

Para essa pessoa:

Yukkuri simplesmente existe.

Esse é o momento mágico em que o meme começa a se comportar como folclore.

A origem deixa de ser necessária para a sobrevivência.


🎥 14. Nico Nico Douga — comentários atravessando a tela

Então chegamos a outro monumento arqueológico:

Nico Nico Douga, hoje normalmente chamado NicoNico.

Uma característica histórica marcante da plataforma são os comentários aparecendo diretamente sobre o vídeo, atravessando a tela.

Isso cria uma experiência muito diferente de assistir sozinho.

Você está vendo o vídeo.

Mas também está vendo a reação acumulada de outras pessoas.

Em determinados momentos a tela pode praticamente desaparecer sob comentários.

É como assistir televisão dentro de um estádio.

O público virou parte da obra.

Piadas surgem.

Comentários repetem frases.

Determinados momentos ganham significados que o criador original jamais planejou.

Uma música pode tornar-se meme.

Uma cena obscura pode virar fenômeno.

Um erro pode tornar-se tradição.

A audiência passa a produzir uma segunda camada narrativa.


🧬 15. O meme já não pertence ao criador

Esse é talvez o ponto central da Parte II.

Na cultura digital, existe um momento em que o criador perde controle semântico sobre a criação.

Ele publica:

A.

A comunidade interpreta:

B.

Transforma em:

C.

Mistura com:

D.

Dez anos depois existe:

X.

E alguém pergunta ao autor:

“O que você acha de X?”

Ele responde:

“QUE DIABOS É ISSO?”

😂

Folclore sempre funcionou assim.

A Internet simplesmente tornou o processo visível e absurdamente rápido.


🕸️ 16. O ciclo completo

Agora conseguimos montar nosso pipeline arqueológico:

EXPERIÊNCIA HUMANA
        ↓
      RELATO
        ↓
       BBS
        ↓
      FÓRUM
        ↓
     IMAGEBOARD
        ↓
       MEME
        ↓
     FAN ART
        ↓
      VÍDEO
        ↓
   MANGÁ / ANIME
        ↓
   NOVA AUDIÊNCIA
        ↓
    NOVOS MEMES
        ↓
    NOVO FOLCLORE
        ↺

Não existe necessariamente começo ou fim.

Existe circulação.


🧪 17. O teste Bellacosa para detectar folclore digital

Quando encontrar algo estranho na Internet japonesa, faça cinco perguntas.

1. Quem criou?

Se ninguém sabe, +1 ponto.

2. Existem versões diferentes?

+1.

3. As pessoas discutem qual versão é verdadeira?

+1.

4. A história escapou da comunidade original?

+1.

5. Pessoas repetem sem conhecer a origem?

+1.

Resultado:

0-1  = MEME LOCAL
2-3  = MUTATION IN PROGRESS
4    = PROTO-FOLKLORE
5    = PARABÉNS, VOCÊ ENCONTROU UM YŌKAI DIGITAL

Não é classificação acadêmica.

É classificação Bellacosa.

Portanto possui certificação internacional da máquina de café.


🇧🇷 18. E onde entra o Brasil?

Agora retornamos à nossa Loira do Banheiro.

Ao canivete da roça.

À peixeira.

À trilha no mato.

Às velas.

Às latas.

Aos causos.

À reencarnação.

Às histórias que nossos avós juravam serem verdadeiras.

Temos exatamente os ingredientes necessários.

Talvez o Brasil não precise importar os monstros japoneses.

Precisamos aprender o mecanismo cultural que permitiu que eles continuassem sendo reinventados.

O Japão não preservou seus monstros congelando-os.

Continuou usando-os.

Mangá.

Anime.

Jogos.

Filmes.

Internet.

Mascotes.

Publicidade.

Memes.

O monstro antigo recebe roupa nova e continua andando.


🌳 19. Curupira 2.0 não precisa usar katana

Imagine uma história brasileira moderna.

Um grupo entra numa área remota.

GPS começa a apresentar coordenadas impossíveis.

Dois celulares mostram posições diferentes.

O mapa offline indica que estão caminhando em linha reta.

Mas retornam ao mesmo lugar.

Encontram pegadas.

Só que as pegadas parecem apontar na direção contrária à caminhada.

Nenhum personagem diz:

“ATENÇÃO ESPECTADOR ESTRANGEIRO: SEGUNDO O FOLCLORE BRASILEIRO...”

Não.

Deixe o japonês assistindo descobrir.

Deixe ele pesquisar:

“Brazil backwards feet forest creature.”

E então ele encontra:

Curupira.

Pronto.

Fizemos soft power.


🔥 20. O Boitatá não precisa de tutorial

Pantanal.

Noite.

Incêndio distante.

Uma linha luminosa começa a atravessar a vegetação.

O personagem local simplesmente diz:

“Apaga a lanterna.”

O estrangeiro não entende.

Outro personagem pergunta:

“Por quê?”

Resposta:

“Porque ele já viu a gente.”

Fim do episódio.

😂

No Reddit japonês:

“QUE PORRA É BOITATÁ?”

No dia seguinte:

500 mil pesquisas.

É assim que cultura viaja.


🕯️ 21. E talvez eu já tenha criado um yōkai

Voltemos à trilha.

Crianças.

Velas.

Latas.

Escuridão.

Pessoas assustadas.

Décadas depois, talvez alguém ainda conte:

“Naquela região apareciam umas luzes no mato.”

Talvez ninguém conte.

Provavelmente a história morreu.

Mas existe uma possibilidade minúscula e maravilhosa de que algum fragmento tenha sobrevivido.

Nesse caso, os criadores originais nem reconheceriam necessariamente a história atual.

Talvez agora exista uma mulher.

Talvez alguém tenha morrido.

Talvez as luzes sigam viajantes.

Talvez apareçam apenas em determinada noite.

O fork superou o original.

O repositório perdeu os autores.

Folklore v7.3 LTS.


🤖 22. E então chegou a inteligência artificial

Agora chegamos a 2026.

Algo novo entrou no pipeline.

Durante milênios tivemos:

humano → humano.

Depois:

humano → Internet → humano.

Agora:

humano → Internet → IA → humano.

E isso cria um problema arqueológico fascinante.

Uma IA encontra milhares de versões de determinada história.

Tenta responder:

“Qual é a origem?”

Mas talvez os próprios documentos disponíveis estejam repetindo uma informação incorreta.

Uma página copiou outra.

Outra copiou a primeira.

Cem páginas repetem.

Quantidade não transforma erro em verdade.

Temos uma nova obrigação:

preservar incerteza.

“Não sabemos.”

“Provavelmente.”

“O registro mais antigo localizado é...”

“Existem versões conflitantes.”

Essas frases são importantíssimas.

Caso contrário, a IA pode transformar folclore sobre a origem de uma lenda em origem oficial da lenda.


⚠️ 23. O monstro definitivo: a alucinação com referências

Imagine:

Uma pessoa inventa uma história em 1999.

Outra repete em 2002.

Um blog atribui erroneamente a história a 1987.

Dez blogs copiam.

Uma wiki copia.

Um vídeo cita a wiki.

Cem artigos citam o vídeo.

Uma IA lê tudo.

Perguntamos:

“Quando surgiu?”

Ela responde com absoluta confiança:

1987.

Parabéns.

Criamos algo muito mais perigoso que Hachishakusama:

O YŌKAI DA CITAÇÃO CIRCULAR.

Ele possui milhares de fontes.

Nenhuma delas sabe de onde veio a informação.

Todo pesquisador já encontrou algum parente dessa criatura.


🏺 24. O arqueólogo digital precisa aprender a dizer “não sei”

Talvez essa seja a principal lição desta expedição.

Arqueologia não significa encontrar respostas bonitas.

Às vezes significa encontrar:

um buraco.

Não sabemos quem publicou primeiro.

Não sabemos se aconteceu.

Não sabemos se determinada versão já circulava offline.

Não sabemos se o arquivo sobrevivente é o original.

E está tudo bem.

O desconhecido não diminui a história.

Às vezes é justamente aquilo que a torna fascinante.


🎁 Easter egg — O último login

Imagine 2076.

Um pesquisador encontra um arquivo de nossas conversas.

Ele lê:

“O BBS dos Yōkai.”

Continua.

Encontra Kisaragi.

Kunekune.

Hachishakusama.

Loira do Banheiro.

Peixeira.

Canivete.

COBOL.

IBM.

Café.

Velas numa trilha.

ChatGPT.

O pesquisador percebe que o arquivo termina abruptamente.

Mas existe uma última linha:

$HASP395 VAGNER ENDED

Ele sorri.

Fecha o arquivo.

Vai embora.

Naquela noite, recebe uma notificação.

Nova mensagem disponível.

Remetente:

VAGNER@BELLACOSA

Data:

09/08/2026

Mensagem:

“Esquecemos de falar de uma coisa...”

O pesquisador olha para o relógio.

03:17.

Seu terminal imprime sozinho:

$HASP373 YOKAI3 STARTED

Ele não sabe COBOL.

Não conhece JES2.

Não entende o significado.

Então faz aquilo que qualquer pesquisador de 2076 faria.

Pergunta à IA.

A IA demora alguns segundos.

E responde:

“Curioso. Esse JOB está executando há cinquenta anos.”

☕👻


☕ Conclusão — Os yōkai nunca foram os monstros

Talvez tenhamos começado esta série procurando criaturas.

Mas acabamos encontrando algo muito maior.

Nós mesmos.

O mecanismo que criou histórias ao redor de fogueiras continua funcionando dentro de servidores.

Mudamos a infraestrutura.

Não mudamos nossa necessidade de contar.

Queremos assustar.

Queremos rir.

Queremos pertencer.

Queremos explicar coisas estranhas.

Queremos transformar experiências em histórias.

Queremos repetir boas histórias.

E inevitavelmente as modificamos.

Por isso Kisaragi Station é importante.

Por isso Kunekune é interessante.

Por isso Hachishakusama atravessou idiomas.

Por isso Densha Otoko ultrapassou o fórum.

Por isso OS-tan transforma software em personagem.

Por isso Yukkuri continua sofrendo mutações.

Por isso Nico Nico conseguiu transformar comentários em parte da experiência audiovisual.

E por isso a Loira do Banheiro continua perfeitamente confortável do outro lado do planeta.

São manifestações diferentes da mesma máquina.

A máquina humana de fabricar significado.

Hoje ela está conectada à Internet.

Amanhã estará conectada a alguma coisa que ainda nem inventamos.

Mas tenho razoável certeza de uma coisa.

Alguém contará uma história.

Outra pessoa perguntará:

“Isso aconteceu mesmo?”

Uma terceira responderá:

“Meu primo conhece alguém que viu.”

E naquele instante...

o próximo yōkai terá acabado de nascer.


$HASP395 YOKAI2 ENDED - RC=0000

ARCHAEOLOGICAL STATUS: INCOMPLETE

UNIDENTIFIED ENTITIES REMAINING: MANY

NEXT DATASET: ???

☕👻💻

☕ Um Café no Bellacosa Mainframe

O BBS dos Yōkai — Guia da Expedição

Do fantasma contado ao redor da fogueira ao yōkai que vive no algoritmo: explore a série sobre arqueologia do folclore da Internet japonesa, BBS, 2channel, Futaba, lendas urbanas, creepypastas, cultura otaku, terror tecnológico e inteligência artificial.

O BBS dos Yōkai é uma série do Bellacosa Mainframe dedicada à arqueologia cultural da Internet japonesa.

A expedição acompanha a evolução das histórias desde os antigos fóruns e BBS japoneses até lendas como Kisaragi Station, Kunekune e Hachishakusama, chegando às creepypastas, vídeos amaldiçoados, jogos, algoritmos e inteligência artificial.

Escolha abaixo uma etapa da expedição. Os links são páginas independentes e podem ser abertas diretamente ou visualizadas no leitor incorporado.

TERMINAL DE LEITURA

Selecione uma etapa da expedição

Abrir em nova página ↗

Bellacosa Mainframe — Toda lenda começa como uma dúvida. Toda dúvida merece um café.

domingo, 6 de outubro de 2013

📊 Tabela de Erros Comuns no COBOL 5.x

 



📊 Tabela de Erros Comuns no COBOL 5.x

(Quando o compilador resolve dizer a verdade)

“COBOL 5 não quebrou seu programa.
Ele apenas revelou o que sempre esteve errado.”

— Bellacosa


🟥 ERROS DE DADOS (o choque de realidade)

Erro comumO que mudou no COBOL 5Sintoma típicoImpacto
MOVE inválido alfa → numéricoNUMCHECK rigorosoErro de compilação ou runtimeJob aborta cedo
Campo não inicializadoINITCHECK ativoWarning/erroResultado imprevisível exposto
Uso de lixo em COMPValidação agressivaFalha imediataS0C7 antecipado
PIC incompatívelValidação estritaCompile errorCódigo não sobe
Truncamento inesperadoTRUNC mais explícitoValor incorretoErro contábil

🥚 Easter-egg:

O erro “novo” já existia no COBOL 4 — só não gritava.


🟧 ERROS DE CONTROLE DE FLUXO

Erro comumCOBOL 5 faz diferenteSintomaConsequência
PERFORM THRU mal definidoAnálise de fluxoWarning severoLógica rejeitada
GO TO cruzando blocosRestrição maiorErro de compilaçãoCódigo não compila
IF/END-IF inconsistentesEstrutura rígidaCompile errorRefatoração obrigatória
EXIT mal posicionadoRegras mais clarasErro lógicoFluxo interrompido

Bellacosa note:

Se o COBOL 5 reclama, o código está errado — ponto.



🟨 ERROS DE STORAGE E MEMÓRIA

Erro comumCOBOL 5 expõeSintomaResultado
REDEFINES mal alinhadoSSRANGE ativoRuntime errorS0C4
OCCURS fora de limiteChecagem ativaAbort imediatoProteção de memória
DEPENDING ON inválidoValidação em runtimeAbendCorrupção evitada
Índice mal usadoTipagem rígidaCompile errorCorreção forçada

🥚 Easter-egg técnico:

SSRANGE não cria erro — ele evita desastre.


🟦 ERROS DE ARQUIVOS (mais disciplina)

Erro comumDiferença no COBOL 5SintomaImpacto
FILE STATUS ignoradoWarning severoJob rejeitadoErro detectado cedo
READ sem AT ENDAnálise estáticaCompile warningLoop evitado
WRITE sem validaçãoChecagem formalRuntime errorIntegridade garantida
OPEN fora de ordemValidação rígidaAbendErro explícito

🟪 ERROS DE PERFORMANCE (o paradoxo)

Erro comumPor que aparece no COBOL 5SintomaEfeito
Código “lento” após migraçãoOtimização diferenteCPU aumentaAjustar OPTIMIZE
Dependência de MOVENova análiseCódigo inchadoRefatoração
DISPLAY em loopRuntime modernoBatch mais lentoRemover debug
Falta de INLINECompilação conservadoraPerformance ruimAjustar opções

Bellacosa truth:

COBOL 5 é mais rápido — se o código merecer.


🟫 ERROS DE COMPILAÇÃO (novos padrões)

Erro comumCOBOL 5 exigeSintomaAção
Código legado ambíguoSintaxe claraCompile errorRefatorar
Ignorar warningsWarnings viram errosBuild falhaCorrigir
TRUNC inconsistentePadronizaçãoValor erradoRevisar
Dependência de defaultsDefaults mudaramResultado inesperadoDefinir parms

☠️ ABENDS mais associados ao COBOL 5

ABENDMotivo
S0C7Detectado mais cedo
S0C4Proteção de memória
U4038INITCHECK / NUMCHECK
U4087Violação de range
U4093Lógica inválida

🎓 Resumo para Padawans

✔ COBOL 5 não tolera código sujo
✔ Erros aparecem mais cedo
✔ Migração revela dívidas técnicas
✔ Mais seguro, mais rápido, mais previsível


🧠 Frase Final Bellacosa™

“COBOL 4 confiava no programador.
COBOL 5 confia nos dados.”

segunda-feira, 30 de setembro de 2013

💾 z/OS 2.1 — O salto técnico rumo à era híbrida do Mainframe ☁️⚙️

 





💾 z/OS 2.1 — O salto técnico rumo à era híbrida do Mainframe ☁️⚙️

Por Bellacosa Mainframe — onde bits, café e história se misturam ☕🖥️


Quando a IBM lançou o z/OS 2.1 em setembro de 2013, o mundo mainframe vivia uma encruzilhada: ou se isolava como um dinossauro tecnológico, ou se reinventava como o titã resiliente da nova era digital.
Adivinha qual caminho ele escolheu? 😎
Spoiler: o z/OS 2.1 é o marco da virada para a era híbrida e cognitiva do mainframe.

Vamos destrinchar o que mudou, as camadas técnicas e as curiosidades que tornam essa versão um divisor de águas.


🧬 1. Contexto histórico — o z/OS reencontra o futuro

O z/OS 2.1 nasceu junto com os mainframes IBM zEnterprise EC12 (zEC12), um monstro de 5.5 GHz, com 2 TB de memória, 120 processadores físicos e uma arquitetura pensada para virtualização de workloads e análise em tempo real.

O grande desafio da IBM era:

“Como preparar o z/OS para o futuro da integração, da nuvem e do mobile sem perder o legado que roda o planeta?”

Assim surge o z/OS 2.1, com foco em eficiência, elasticidade e conectividade.


🧠 2. Arquitetura e uso de memória — o cérebro expandido

O z/OS 2.1 trouxe uma reengenharia no gerenciamento de memória, aproveitando melhor a arquitetura z/Architecture e as inovações do PR/SM (Processor Resource/System Manager).

Principais avanços:

  • Suporte a 16 TB de memória virtual (um salto em relação ao 2.0).

  • Melhor uso da 64-bit addressing mode, reduzindo page faults e swaps.

  • Buffer Pools e dataspaces otimizados — ideal para DB2, IMS e CICS.

  • Cross Memory Services mais rápidos e isolados.

💡 Curiosidade Bellacosa: O kernel do z/OS 2.1 literalmente “aprende” a liberar memória mais rápido para workloads que mudam de prioridade — algo que hoje chamamos de “inteligência operacional”.


⚙️ 3. PR/SM, LPAR e créditos de CPU — o cérebro por trás da mágica

O firmware PR/SM (Processor Resource/System Manager) foi profundamente atualizado nesta geração para oferecer:

  • Dynamic CPU Weight Management: ajuste automático da prioridade das LPARs.

  • Intelligent Capping: limita o consumo sem matar o desempenho.

  • Soft Capping por Workload: controle fino para billing e otimização.

  • Suporte ao zAAP/zIIP integrados — sem necessidade de hardware dedicado.

🎩 Easter egg técnico: no z/OS 2.1, as LPARs começaram a “conversar” melhor via HiperSockets IPv6, abrindo caminho para a nuvem privada z/OS Connect.


💬 4. Aplicativos internos e softwares — a revolução silenciosa

O z/OS 2.1 veio com uma leva de atualizações internas e ferramentas novas:

🔹 CICS TS 5.1

Suporte a aplicações RESTful, JSON e web services nativos, antecipando o que hoje chamamos de API Economy.

🔹 DB2 11 for z/OS

Melhoria brutal no storage engine e otimização de index rebuild.
Menos CPU, mais throughput.

🔹 JES2 e JES3

Ambos ganharam compressão de spool, melhor suporte a Unicode e integração com RACF e SAF aprimorada.
O JES2, inclusive, ficou mais “verbozão” — logs mais inteligentes para devs e ops.

🔹 UNIX System Services (USS)

Expansão total: mais comandos POSIX, shell modernizado e integração com ferramentas open source (hello, Perl e Python!).

🔹 Communications Server

Nativo IPv6, com QoS aprimorado e integração direta com o z/OSMF.


🧩 5. z/OSMF e o renascimento do operador

O z/OS Management Facility (z/OSMF) virou protagonista.
Pela primeira vez, o operador do mainframe podia administrar o sistema via interface web, com dashboards, workflows e diagnósticos integrados.

Isso mudou tudo:

  • A operação ficou mais visual e menos criptográfica (adeus, painéis 3270 infinitos).

  • Surgiram scripts e automações REST, abrindo portas para DevOps no mainframe.

  • O z/OS começou a dialogar com o mundo Linux e Cloud.

💬 Bellacosa insight: o z/OSMF foi o primeiro passo real para o que hoje chamamos de “Mainframe as Code”.


🔍 6. Instruções de máquina e otimizações no zEC12

O z/OS 2.1 foi ajustado para o novo processador zEC12, que introduziu:

  • Instruções novas como Transactional Execution (TX) — acelera commits em DB2.

  • Crypto Express4S — hardware de criptografia de ponta.

  • Simultaneous Multithreading (SMT) — mais threads, menos gargalo.

  • HiperDispatch refinado — balanceia threads automaticamente.

Tudo isso sob o comando de um PR/SM mais “inteligente”, que distribuía créditos de CPU conforme prioridade, workload e até custo horário da LPAR (sim, billing inteligente já era realidade).


🕹️ 7. Curiosidades, fofoquices e bastidores

  • 🧙‍♂️ Dentro da IBM, o z/OS 2.1 era apelidado de “O Feiticeiro do Silício”, por causa da automação mágica dos workloads.

  • 🧩 O time que desenvolveu o z/OSMF tinha ex-devs do OS/2!

  • 💬 Foi a primeira versão oficialmente “Cloud Ready”, base dos projetos iniciais do z/OS Connect EE.

  • 🕵️‍♂️ Algumas funções experimentais do z/OS 2.1 só foram “oficializadas” no 2.2, como a integração com zAware e zCX.


🚀 8. Conclusão — o mainframe, renascido

O z/OS 2.1 é o elo entre o legado e o futuro.
Ele consolidou a base técnica que permitiria o z/OS rodar workloads modernos, APIs REST, automações web e integração em nuvem — tudo sem quebrar um único programa COBOL dos anos 70.
Esse é o verdadeiro superpoder do mainframe: evoluir sem perder o passado.


Bellacosa Mainframe
☕ Onde bits têm alma e memória tem história.
💬 Deixe nos comentários: você chegou a migrar para o z/OS 2.1? Qual foi o impacto no seu ambiente?

quarta-feira, 25 de setembro de 2013

☕🔥 ABEND S322 — O “EXECUTOR DO TEMPO” NO z/OS

 

Bellacosa Mainframe abend s322

☕🔥 ABEND S322 — O “EXECUTOR DO TEMPO” NO z/OS

Quando o Mainframe Diz:

“SEU JOB DEMOROU DEMAIS.”

Se existe um ABEND que transforma operador, sysprog e programador COBOL em investigadores desesperados…

é o lendário:

🚨 S322

E normalmente ele aparece assim:

IEF450I JOBNAME STEP01 - ABEND=S322

ou:

TIME EXCEEDED

ou ainda:

CPU TIME LIMIT EXCEEDED

E naquele instante…

o Junior Padawan entra em pânico:

“O mainframe travou?”
“Meu SORT entrou em loop?”
“O COBOL nunca terminou?”
“O JES2 ficou bravo?”
“A CPU derreteu?”

☕ Respira.

Porque o S322 é um dos ABENDs MAIS IMPORTANTES para entender:

performance

loops infinitos

consumo de CPU

batch tuning

TIME parameter

runaway jobs


🔥 O QUE É O S322?

O S322 é um:

🚨 TIME LIMIT EXCEEDED

Traduzindo:

O JOB ULTRAPASSOU O TEMPO DE CPU PERMITIDO.

Então o z/OS decidiu:

☠️ “VOU ENCERRAR ISSO AGORA.”


☕ A FILOSOFIA DO S322

No z/OS:

CPU É RECURSO SAGRADO.

Milhares de jobs compartilham:

  • processador

  • initiators

  • discos

  • spool

  • memória

Um job descontrolado pode:

  • atrasar produção

  • bloquear batch window

  • derrubar SLA

  • gerar caos operacional

Então o sistema impõe limites.


🔥 O GRANDE SEGREDO

S322 normalmente NÃO é bug de sintaxe.

É:

problema de lógica

loop infinito

SQL ruim

SORT monstruoso

leitura sem fim

runaway batch


☕ O MOMENTO EXATO DO S322

Fluxo:

JOB EXECUTA
 ↓
CPU TIME cresce
 ↓
Limite TIME atingido
 ↓
JES/zOS encerra job
 ↓
S322

🔥 O PARÂMETRO MAIS IMPORTANTE

TIME=

No JCL:

//JOBNAME JOB ... TIME=(1)

ou:

TIME=1440

☕ O QUE ISSO SIGNIFICA?


☕ TIME=(1)

Máximo:

1 minuto de CPU


☕ TIME=1440

Até:

24 horas


🔥 O ERRO CLÁSSICO DO PADAWAN

//STEP1 EXEC PGM=PROG1,TIME=(1)

Mas o job precisa:

5 minutos

Resultado:

💥 S322


☕ O MAIOR VILÃO DO S322

🚨 LOOP INFINITO

O rei absoluto dos ABENDs temporais.


🔥 EXEMPLO CLÁSSICO COBOL

PERFORM UNTIL WS-FIM = 'S'

   READ ARQUIVO

END-PERFORM

Mas:

WS-FIM nunca muda

Agora:

CPU sobe

job nunca termina

scheduler sofre

S322 aparece


☕ O LOOP FANTASMA

Mais perigoso:

PERFORM VARYING IDX FROM 1 BY 1
   UNTIL IDX > 100

Mas dentro:

MOVE 1 TO IDX

Agora:

loop eterno.


🔥 O S322 E O END-OF-FILE

Clássico absoluto.


☕ O ERRO

Junior esquece:

AT END

🔥 EXEMPLO

READ CLIENTE

sem:

AT END MOVE 'S' TO WS-FIM

Agora o READ nunca encerra corretamente.

Loop eterno.

Resultado:

☠️ S322


☕ O S322 E O SQL

Outro campeão.


🔥 CURSOR MALDITO

SELECT * FROM TABELA_GIGANTE

Sem índice.

Sem filtro.

Sem COMMIT.

Agora:

CPU explode.


☕ O SORT DA MORTE

//SYSIN DD *
  SORT FIELDS=COPY
/*

Mas dataset:

5 bilhões de registros

E disco ruim.

Resultado:

☠️ S322


🔥 O S322 E O “WAIT”

Outro cenário sombrio.

Job preso:

  • ENQ

  • recurso

  • fita

  • dataset lock

  • deadlock lógico

Tempo passa.

Resultado:

💥 S322


☕ O S322 NÃO É NECESSARIAMENTE CPU

Isso é importante.

Às vezes:

elapsed time

também pode causar término dependendo de políticas do sistema.


🔥 COMO INVESTIGAR O S322 PASSO A PASSO


✅ PASSO 1 — VERIFIQUE O JESMSGLG

Ali está a verdade.

Exemplo:

TIME EXCEEDED

✅ PASSO 2 — IDENTIFIQUE O STEP

STEP01

✅ PASSO 3 — VERIFIQUE CPU TIME

Mensagens:

CPU: 00:00:59

✅ PASSO 4 — PROCURE LOOPS

Pergunte:

  • EOF existe?

  • índice muda?

  • condição muda?

  • cursor fecha?

  • COMMIT existe?


✅ PASSO 5 — ANALISE O SYSOUT

Última mensagem repetitiva geralmente aponta o loop.


🔥 O SEGREDO DOS DISPLAYs

Veteranos usam:

DISPLAY IDX

para descobrir:

  • loop preso

  • contador travado

  • repetição infinita


☕ O DUMP DO S322

Curiosamente:

muitas vezes NÃO existe dump útil.

Porque o sistema apenas mata o job por timeout.


🔥 MAS ÀS VEZES EXISTE

Com opções especiais:

  • SYSUDUMP

  • CEEDUMP

  • SLIP

  • Abend-AID

Você pode capturar o estado.


☕ COMO O VETERANO INVESTIGA

Veterano pergunta imediatamente:

“O JOB ESTÁ PRESO OU APENAS LENTO?”

Isso muda tudo.


🔥 JOB LENTO

  • volume gigantesco

  • SQL ruim

  • SORT pesado

  • I/O excessivo


🔥 JOB PRESO

  • loop infinito

  • EOF errado

  • condição impossível

  • deadlock


☕ O S322 E O CICS

No CICS equivalente filosófico seria:

🚨 AICA

Ambos representam:

excesso de tempo.

Mas:


☕ S322

Batch.


☕ AICA

Online/CICS.


🔥 O S322 E O JES2

O JES monitora:

  • accounting

  • CPU

  • limites

  • classe de execução

Ele participa do encerramento.


☕ O SEGREDO DO TIME=NOLIMIT

Alguns ambientes permitem:

TIME=NOLIMIT

Veteranos tremem quando veem isso.

Porque runaway jobs podem:

destruir batch windows inteiras.


🔥 O S322 E O MAINFRAME ANTIGO

Nos anos 70/80:

CPU era MUITO cara.

Minutos desperdiçados tinham impacto financeiro enorme.

Então IBM criou mecanismos agressivos de timeout.


☕ CURIOSIDADE HISTÓRICA

Em ambientes antigos:

um loop infinito podia literalmente:

atrasar folha de pagamento inteira.


🔥 EASTER EGG MAINFRAME

Veteranos brincam:

“S322 significa:

Seu Job Não Quer Morrer.”


☕ O MAIOR ERRO DO PADAWAN

Resolver S322 aumentando:

TIME=1440

sem descobrir causa raiz.

Agora o job infinito só demora MAIS para morrer.


🔥 COMO EVITAR S322


✅ Sempre validar EOF


✅ Loops precisam mudar estado


✅ Revisar PERFORM UNTIL


✅ Revisar SQL


✅ Monitorar CPU


✅ Testar com massa pequena


✅ Usar contadores de proteção


☕ O “CONTADOR DE SANIDADE”

Veteranos adoram isso:

ADD 1 TO WS-COUNT

IF WS-COUNT > 999999
   DISPLAY 'LOOP SUSPEITO'
   STOP RUN
END-IF

🔥 O MAIOR ENSINAMENTO DO S322

Ele ensina algo profundo:

processamento sem controle destrói ambientes compartilhados.


☕ A VERDADE FINAL

O S0C7 pune dados inválidos.
O S0C4 pune memória inválida.
O S013 pune estrutura inválida.

Mas…

☕ O S322 PUNE PROGRAMAS QUE ESQUECERAM QUE O TEMPO DA CPU É SAGRADO NO z/OS.


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