☕ 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

domingo, 14 de fevereiro de 2010

Notícias Populares: Tarantino, COBOL e o Jornal que Espremia e Saía Sangue

 

Bellacosa Mainframe e o jornal noticias populares

☕ Um Café no Bellacosa Mainframe

Notícias Populares: Tarantino, COBOL e o Jornal que Espremia e Saía Sangue

🩸 Crime, sexo, Bebê-Diabo, ditadura, censura, bancas, manchetes impossíveis e a extraordinária história do jornal que transformou São Paulo num filme de Quentin Tarantino décadas antes de Tarantino filmar Pulp Fiction

Imagine, jovem padawan do COBOL, que você saiu do trabalho em 1987.

Não existe smartphone.

Não existe Google.

Não existe X.

Não existe Instagram.

Não existe portal de notícias.

Não existe WhatsApp.

E, evidentemente, ninguém recebeu ainda no grupo da família um vídeo de procedência duvidosa acompanhado da mensagem:

URGENTE!!! REPASSEM ANTES QUE APAGUEM!!!

Para descobrir o que aconteceu no mundo, você passa diante de uma banca de jornal.

E ali está o algoritmo de recomendação de 1987.

Só que feito de madeira, metal, barbante e pregadores.

Dezenas de jornais e revistas estão expostos. Alguns pendurados. Outros sobrepostos. As capas disputam fisicamente alguns centímetros do seu campo de visão.

Folha.

Estadão.

Jornal da Tarde.

Gazeta Esportiva.

Revistas.

Quadrinhos.

E então aparece uma coisa que parece ter sido diagramada por alguém que misturou jornalismo policial, filme B, programa de auditório, revista masculina, conversa de boteco e uma quantidade preocupante de café.

NOTÍCIAS POPULARES.

O NP.

Você não precisava comprar.

Bastava enxergar a manchete.

E a manchete praticamente agarrava você pelo colarinho.

O jornal circulou de 1963 a 2001 e ficou marcado justamente pela combinação de textos curtos, muitas fotografias e títulos de enorme impacto. Em sua fase clássica, crime, sexo, violência, escatologia, celebridades, futebol e acontecimentos sobrenaturais conviviam alegremente no mesmo produto editorial.

Se Quentin Tarantino tivesse nascido no Brás e trabalhado como repórter policial antes de dirigir cinema, talvez alguma coisa parecida tivesse acontecido.

Só faltava Samuel L. Jackson entrar na redação e perguntar:

E o fechamento, motherf...?


CAPÍTULO I — ERA UMA VEZ UMA INTERNET DE PAPEL

Para compreender o Notícias Populares é preciso cometer um erro muito comum em manutenção de legado:

não analisar o programa sem analisar o ambiente em que ele executava.

Um COBOL de 1973 parece estranho quando retirado de seu contexto.

O NP também.

O Brasil que viu o jornal nascer, em 15 de outubro de 1963, era muito diferente do Brasil digital.

A televisão estava crescendo.

O rádio tinha enorme importância.

O país atravessava urbanização acelerada.

Milhares de pessoas migravam para grandes centros industriais.

São Paulo crescia violentamente.

Havia trabalhadores com pouca escolarização formal e enormes desigualdades educacionais.

Aqui vale corrigir uma simplificação importante.

Não seria justo dizer simplesmente:

“O NP existia porque o povo brasileiro não sabia ler.”

Não.

O fenômeno é mais interessante.

Existiam índices elevados de analfabetismo e escolarização limitada, mas também existia uma enorme população leitora com diferentes graus de letramento, habituada a formas mais diretas e orais de comunicação.

O NP compreendeu isso extraordinariamente bem.

Ele reduziu a complexidade sintática.

Usou títulos enormes.

Preferiu frases curtas.

Explorou fotografias.

Empregou vocabulário cotidiano.

Transformou assuntos complexos em narrativas.

Em linguagem de sistemas:

INPUT:
acontecimento complexo

PROCESS:
simplificação
personificação
emoção
imagem
humor
sexo
violência
curiosidade

OUTPUT:
MANCHETE IMPOSSÍVEL DE IGNORAR

Isso também explica por que chamar seu público simplesmente de “ignorante” seria perder justamente a parte mais interessante da história.

O leitor do NP podia ter pouca educação formal e, ao mesmo tempo, possuir enorme conhecimento prático do trabalho, da cidade, do transporte, do sindicato, do futebol e da sobrevivência urbana.

O jornal aprendeu a falar a língua desse público.


CAPÍTULO II — O NASCIMENTO ÀS VÉSPERAS DO GOLPE

Aqui a história fica politicamente muito mais interessante.

O NP foi lançado em 1963 pelo empresário Herbert Levy, tendo Jean Mellé como figura fundamental de sua concepção e primeira direção editorial. A intenção original envolvia disputar o público popular da Última Hora, jornal associado a Samuel Wainer e ao campo político ligado ao trabalhismo. Fontes históricas descrevem o projeto inicial como uma tentativa de criar um jornal popular politicamente conservador.

E olhe a data:

1963.

Um ano antes do golpe militar de 1964.

O Brasil fervia.

João Goulart.

Reformas de Base.

Movimento sindical.

Guerra Fria.

Anticomunismo.

Conflitos empresariais.

Estados Unidos e União Soviética disputando influência mundial.

As Forças Armadas no centro da crise.

E havia a Última Hora falando diretamente com parcelas populares.

A ideia era disputar esse espaço.

Só que aconteceu uma coisa deliciosamente digna de sistema legado.

O requisito original perdeu importância.

O produto sobreviveu.

Depois do golpe de 1964, aquele propósito político inicial tornou-se menos necessário. Em 1965, o jornal passou para o controle do grupo que viria a constituir o Grupo Folha.

É o equivalente jornalístico de:

* ESTA ROTINA FOI CRIADA PARA UMA REGRA DE 1963.
* A REGRA NÃO EXISTE MAIS.
* A ROTINA CONTINUA SENDO EXECUTADA.

Todo COBOLzeiro imediatamente se sente em casa.


CAPÍTULO III — IMPRENSA AMARELA NÃO É LISTA TELEFÔNICA

Quando falamos em imprensa amarela, não estamos falando das antigas Páginas Amarelas do telefone.

Estamos falando de yellow journalism ou yellow press.

O conceito nasceu ligado à imprensa sensacionalista de grande circulação: manchetes enormes, acontecimentos dramáticos, crimes, escândalos, histórias humanas, sexo, curiosidades e exploração emocional.

No Brasil popularizou-se também a expressão:

imprensa marrom.

A tradição remonta à penny press e à yellow press do século XIX e reaparece em diferentes formatos no jornalismo popular brasileiro.

O NP levou a fórmula a um nível quase industrial.

Se fosse arquitetura de software:

NOTÍCIA
   |
   +--> medo
   |
   +--> sexo
   |
   +--> curiosidade
   |
   +--> indignação
   |
   +--> humor
   |
   +--> identificação popular
   |
   +--> MANCHETE

Era um engagement engine analógico.


CAPÍTULO IV — O ALGORITMO ERA A BANCA

Aqui está uma coisa que uma geração criada com celulares talvez tenha dificuldade de visualizar.

A banca de jornal era uma interface gráfica urbana.

E era maravilhosa.

Havia revistas penduradas.

Jornais dobrados.

Capas sobrepostas.

Publicações presas em varais e expositores.

Gente esperando ônibus.

Gente saindo do trabalho.

Gente parando alguns minutos.

Gente que não comprava absolutamente nada, mas lia todas as manchetes disponíveis.

Era o Google News da calçada.

O jornaleiro era o algoritmo.

— Chegou aquela revista?

— Chegou.

— Tem jornal do concurso?

— Ali.

— Saiu o resultado do jogo?

— Primeira página.

E havia um fenômeno importantíssimo:

uma única cópia tinha dezenas de leitores visuais.

Hoje contamos pageviews.

Na banca, ninguém sabia quantos olhos haviam processado uma capa.

O NP compreendeu perfeitamente essa economia da atenção.

Sua primeira página precisava funcionar a cinco metros de distância.

Isso significa:

tipografia enorme + fotografia + poucas palavras + emoção.

É praticamente a ciência moderna da thumbnail do YouTube aplicada em papel-jornal.


CAPÍTULO V — TARANTINO ENTRA NA REDAÇÃO

Agora imaginemos Quentin Tarantino analisando uma pilha de Notícias Populares.

Ele provavelmente reconheceria imediatamente vários elementos de sua própria gramática cinematográfica.

Violência exagerada.

Humor dentro da tragédia.

Personagens marginais.

Sexo.

Grotesco.

Cultura popular.

Diálogos aparentemente absurdos.

Criminalidade.

Situações inacreditáveis.

O extraordinário misturado ao cotidiano.

Uma pessoa pega o ônibus.

Outra mata o vizinho.

Outra encontra um lobisomem.

Uma celebridade desapareceu.

Alguém viu um disco voador.

Uma mulher está seminua na contracapa.

O Corinthians perdeu.

Tudo pertence ao mesmo universo narrativo.

É quase:

Pulp Journalism.


CAPÍTULO VI — AS MANCHETES

Algumas manchetes tornaram-se parte do folclore jornalístico brasileiro.

Uma das mais famosas foi:

“Nasceu o Diabo em São Paulo”

Apareceu em 1975 e iniciou a lendária saga do Bebê-Diabo. O sucesso foi tão grande que a história continuou durante várias edições, transformando uma narrativa inicialmente ligada ao nascimento de uma criança com deformidades em uma verdadeira novela sobrenatural.

Outra manchete documentada pela própria história do jornal:

“Violada em pleno auditório”

O contexto?

Sérgio Ricardo havia quebrado o violão durante o Festival de Música Popular Brasileira de 1967.

O “violado” era o violão.

A construção deliberadamente ambígua fazia o resto.

Também apareceu:

“Desapareceu Roberto Carlos”

O contato com o cantor não havia sido conseguido nos Estados Unidos, e a história ganhou dimensão espetacular.

Havia ainda lobisomens, discos voadores, crimes improváveis, histórias sexuais e personagens urbanos transformados em celebridades instantâneas. O acervo histórico preserva, por exemplo, uma primeira página de 1974 dedicada a um suposto lobisomem pernambucano.

O NP compreendia algo fundamental:

a manchete não precisava contar a história inteira.

Precisava obrigar você a executar:

READ NEXT RECORD

CAPÍTULO VII — O BEBÊ-DIABO ERA O CLICKBAIT ANTES DO CLICK

O Bebê-Diabo merece uma parada especial.

A capa anuncia:

NASCEU O DIABO EM SÃO PAULO.

Venda espetacular.

E alguém percebe:

— Meu Deus.

— O quê?

— Vendeu tudo.

— Então o Diabo volta amanhã.

E voltou.

A criatura passou a protagonizar novas histórias.

Aparecia aqui.

Desaparecia ali.

Assustava gente.

Era visto em telhados.

Pegava táxi.

A narrativa continuou por semanas. A história acabou reconhecida como uma construção ficcional da redação e tornou-se talvez o exemplo máximo da mistura de jornalismo, folclore urbano e entretenimento que caracterizou o NP.

Hoje chamaríamos isso de:

retenção de audiência.

Ou:

story arc.

Ou:

conteúdo serializado.

Em 1975:

vende jornal pra cacete.


CAPÍTULO VIII — CRIME: ESPREME QUE SAI SANGUE

A fama do NP também vinha de sua cobertura policial.

Assassinatos.

Acidentes.

Corpos.

Criminosos.

Vítimas.

Delegacias.

Tragédias.

A violência podia aparecer de maneira gráfica que dificilmente seria aceita por muitos veículos generalistas atuais.

Essa estética produziu a célebre descrição:

“espreme que sai sangue”.

Mas há uma contradição importante.

A cobertura policial também dava visibilidade a personagens que raramente apareciam nas páginas nobres da grande imprensa.

Operário.

Empregada doméstica.

Morador da periferia.

Desempregado.

Prostituta.

Motorista.

Pequeno comerciante.

Migrante.

Criminoso de bairro.

Vítima desconhecida.

Era frequentemente uma representação brutal e exploratória.

Mas era representação.

O sujeito que jamais apareceria na coluna social podia ocupar meia primeira página do NP.


CAPÍTULO IX — SEXO VENDE. E O NP SABIA.

E chegamos ao subsistema que provavelmente teria recebido:

PROGRAM-ID. SEX-SELLS.

O NP utilizou extensamente erotismo.

Mulheres seminuas.

Nudez.

Modelos.

Atrizes.

Histórias sexuais.

Duplo sentido.

Escândalos amorosos.

Personagens sexualizados.

Em determinadas fases, mulheres nuas ou seminuas na contracapa tornaram-se parte reconhecível da fórmula editorial. Décadas depois, reproduções históricas dessas capas chegaram a enfrentar moderação automática nas redes sociais justamente por conter nudez.

Isso também revela uma mudança cultural enorme.

Aquilo que podia ficar pendurado numa banca no meio da rua, visível a qualquer transeunte, posteriormente poderia ser removido de uma plataforma digital.

A censura mudou de arquitetura.

Antes:

ESTADO
   |
CENSOR
   |
JORNAL

Hoje pode existir:

PLATAFORMA
   |
POLÍTICA DE CONTEÚDO
   |
ALGORITMO
   |
POST

Mudamos o middleware.

A discussão permaneceu.


CAPÍTULO X — DITADURA, CENSURA E A GRANDE CONTRADIÇÃO

O NP atravessou praticamente todo o regime militar brasileiro de 1964 a 1985.

E isso torna sua história fascinante.

Durante a ditadura, a imprensa brasileira conviveu com censura, pressões políticas, autocensura e perseguição a jornalistas.

Mas jornais não foram afetados exatamente da mesma maneira.

E o NP possuía uma característica peculiar.

Grande parte de sua energia editorial estava direcionada para:

crime, sexo, celebridades, futebol, bizarrices e cotidiano.

Enquanto jornais políticos podiam travar batalhas sobre governo, economia e repressão, o NP podia colocar um lobisomem na capa.

Há aqui uma ironia quase tarantinesca:

em um país onde determinados assuntos políticos eram perigosos demais para imprimir, um Bebê-Diabo podia tornar-se protagonista nacional.

Isso não significa que o jornal estivesse fora do sistema político ou imune à censura.

Significa que seu modelo editorial ocupava um espaço diferente.


CAPÍTULO XI — MAS QUEM CENSURA O MAU GOSTO?

Depois aparece outra discussão.

Não censura política.

Censura moral.

Até onde um jornal pode mostrar um cadáver?

Até onde pode explorar sexualmente uma capa?

Até onde pode publicar nudez?

Até onde pode transformar sofrimento humano em entretenimento?

Em 1994, a própria Folha registrava que o NP havia vencido disputas judiciais contra tentativas de obrigá-lo a circular lacrado, enquanto enfrentava outras controvérsias judiciais relacionadas ao conteúdo publicado.

Essa discussão continua atualíssima.

Troque:

banca

por:

timeline

e o problema reaparece.

Quem decide?

O Estado?

A plataforma?

O editor?

O algoritmo?

O leitor?


CAPÍTULO XII — HUMOR: O COMPONENTE QUE MUITA GENTE ESQUECE

Quem reduz o NP apenas a sangue e mulheres nuas perde uma característica fundamental:

ele podia ser tremendamente engraçado.

Às vezes propositalmente.

Às vezes involuntariamente.

Às vezes não havia sequer como saber.

O título possuía ritmo de piada.

Preparação.

Suspense.

Punchline.

A realidade era convertida em espetáculo linguístico.

Era quase uma tradição de boteco aplicada ao jornalismo.

O leitor podia pensar simultaneamente:

— Isso é horrível.

— Isso é absurdo.

— Isso não pode ser verdade.

— HAHAHAHAHAHAHA.

— Quanto custa?

Essa combinação é profundamente tarantinesca.

Você ri de alguma coisa da qual talvez não devesse rir.


CAPÍTULO XIII — O JORNAL TAMBÉM ERA SERVIÇO

Mas existe outro NP escondido atrás do Bebê-Diabo.

O jornal do trabalhador.

Emprego.

Sindicato.

Transporte.

Problemas urbanos.

Futebol.

Serviços.

Histórias dos bairros.

Problemas que afetavam diretamente as classes populares.

Essa dimensão é importante porque impede uma caricatura fácil.

O NP não era simplesmente:

CRIME + PEITO + DEMÔNIO

Era uma mistura muito mais complicada de jornalismo popular, serviço, entretenimento, sensacionalismo e exploração comercial da curiosidade humana.

Essa ambiguidade explica parte de sua longevidade.


CAPÍTULO XIV — 113 MIL EXEMPLARES

O negócio funcionou.

E muito.

Em 1986, a circulação média chegou a aproximadamente 113 mil exemplares diários.

Depois caiu para 71 mil em 1988.

Uma reforma gráfica e editorial iniciada em 1990 recuperou público, levando novamente a circulação para cerca de 104 mil exemplares naquele ano.

Observe o detalhe.

Não estamos falando de impressão de página web.

Cada exemplar precisava:

ser impresso,

dobrado,

empacotado,

transportado,

distribuído,

entregue à banca

e finalmente comprado.

Era uma infraestrutura física monstruosa.


CAPÍTULO XV — AS BANCAS ERAM AS REDES SOCIAIS

Imagine uma manhã em São Paulo.

Ônibus chegando.

Gente atravessando rua.

Café.

Cigarro.

Buzina.

Jornaleiro abrindo pacotes.

Os jornais são colocados no varal.

Um sujeito para.

Outro olha por cima do ombro.

Outro comenta:

— Você viu isso?

Pronto.

Temos:

POST       = capa
FEED       = banca
LIKE       = comentário
SHARE      = contar para colega
TRENDING   = multidão olhando
ALGORITHM  = jornaleiro
CLICK      = comprar

E havia algo maravilhoso:

o lurker analógico.

O cidadão que lia todas as manchetes e jamais comprava jornal algum.

O terror do modelo de monetização desde 1972.


CAPÍTULO XVI — TARANTINO ENCONTRA O NP

Agora podemos voltar ao nosso diretor imaginário.

Tarantino provavelmente compreenderia o Notícias Populares porque ambos trabalham com uma pergunta semelhante:

Até onde podemos levar a cultura popular antes que ela se transforme em grotesco?

Em Tarantino, a violência pode ser horrível e engraçada.

No NP também.

O sexo pode ser desejo, exploração e piada.

No NP também.

O criminoso pode virar personagem.

No NP também.

O absurdo pode coexistir com acontecimentos reais.

No NP também.

E principalmente:

ninguém está tentando parecer elegante.

O produto assume sua vulgaridade.

Isso é fundamental.

O NP não queria parecer o New York Times.

Ele queria que você parasse diante da banca.


CAPÍTULO XVII — ENTÃO VEIO A TELEVISÃO E ROUBOU O CÓDIGO-FONTE

Nos anos 1990 apareceu um concorrente devastador.

A televisão percebeu:

— Espera aí.

Crime funciona.

Tragédia funciona.

Perseguição funciona.

Repórter gritando funciona.

Popular funciona.

Programas como Aqui Agora levaram parte dessa estética para a televisão.

Depois outros programas policiais continuaram explorando a fórmula.

O que antes precisava ser imaginado através de uma fotografia agora aparecia:

em movimento.

Com som.

Sirene.

Repórter.

Helicóptero.

Ao vivo.

O NP encontrou um problema clássico de TI:

sua interface foi copiada por uma plataforma tecnologicamente mais atraente.


CAPÍTULO XVIII — O FIM

Em 20 de janeiro de 2001, saiu a última edição.

A circulação havia despencado para cerca de 20 mil exemplares diários.

Para comparar:

1986:

113.000

2001:

20.000

O Grupo Folha decidiu concentrar seu jornalismo popular no Agora São Paulo, que naquele momento circulava aproximadamente 118 mil exemplares por dia. A direção afirmou que o modelo do NP havia se esgotado.

Também pesavam a dificuldade comercial, a resistência de anunciantes, mudanças no mercado e a concorrência de novas formas de jornalismo popular.

O processo vinha ocorrendo havia anos:

1994 — 99 mil.

1996 — 74 mil.

1998 — 48 mil.

2001 — 20 mil.

O batch estava morrendo lentamente.

Até alguém executar:

//NP      JOB
//STEP01  EXEC PGM=ENCERRA
//SYSOUT  DD SYSOUT=*
//

RC=0000

37 anos.

Fim.


CAPÍTULO XIX — OU TALVEZ NÃO

Porque aqui está o maior easter egg desta história.

O Notícias Populares morreu?

O jornal, sim.

A arquitetura?

HAHAHAHAHAHA.

Não.

Olhe sua timeline.

URGENTE!

CHOCANTE!

VOCÊ NÃO VAI ACREDITAR!

VEJA O QUE ACONTECEU!

IMAGENS FORTES!

POLÊMICA!

BOMBA!

ABSURDO!

Reconheceu?

O NP não desapareceu.

Ele foi portado para a Web.


CAPÍTULO XX — O NP ERA UM ALGORITMO HUMANO

A redação havia descoberto empiricamente coisas que hoje chamamos de:

  • engagement;

  • click-through rate;

  • emotional triggering;

  • visual hierarchy;

  • retention;

  • cliffhanger;

  • serialização;

  • curiosity gap;

  • personalização por público;

  • linguagem otimizada;

  • conteúdo viral.

Não havia machine learning.

Havia jornalista.

Não havia dashboard em tempo real.

Havia:

VENDEU?

Se a resposta fosse sim:

PERFORM FAZ-DE-NOVO
    UNTIL CIRCULACAO = ZERO
END-PERFORM.

O Bebê-Diabo foi praticamente um mecanismo de retenção serializado.


CAPÍTULO XXI — E O “POVO SEM LETRAMENTO”?

Voltamos ao ponto mais delicado.

É tentador olhar para aquelas capas hoje e concluir:

“Funcionavam porque o público era ignorante.”

Seria uma conclusão confortável.

E provavelmente errada.

Porque as mesmas técnicas funcionam hoje com:

executivos,

engenheiros,

médicos,

advogados,

professores,

programadores,

mestres,

doutores

e pessoas com três monitores exibindo dashboards.

O problema não é simplesmente alfabetização.

É psicologia humana.

Medo chama atenção.

Sexo chama atenção.

Perigo chama atenção.

Curiosidade chama atenção.

Violência chama atenção.

O extraordinário chama atenção.

Somos Homo sapiens antes de sermos usuários autenticados.

A diferença é que o NP precisava convencer um cidadão caminhando pela calçada.

Hoje o recomendador sabe exatamente qual Bebê-Diabo mostrar para cada pessoa.

E isso é muito mais poderoso.


CAPÍTULO XXII — O VERDADEIRO LEGADO

O Notícias Populares é uma cápsula cultural brasileira.

Nele encontramos simultaneamente:

ditadura,

urbanização,

migração,

violência,

desigualdade,

sexualidade,

machismo,

humor,

moralismo,

religiosidade,

superstição,

televisão,

futebol,

celebridades,

criminalidade,

publicidade,

censura,

liberdade de imprensa

e cultura popular.

Por isso suas capas parecem absurdas hoje.

Elas são snapshots de memória.

SYS1.BRASIL.HISTORIA.NP

Cada edição preserva não apenas aquilo que aconteceu.

Preserva aquilo que uma sociedade desejava ver.

E talvez isso seja ainda mais importante.


EPÍLOGO — PULP FICTION NA BANCA

Imagine a cena final.

São Paulo.

Final dos anos 1980.

Seis horas da manhã.

Ônibus passando.

Um bar abrindo.

Café sendo servido num copo americano.

A banca está cheia.

O jornaleiro prende jornais no varal.

Um trabalhador aproxima-se.

Olha uma capa.

Para.

Franze a testa.

Outro sujeito olha também.

Um terceiro aproxima-se.

Ninguém sabe ainda que existe uma coisa chamada Internet comercial.

Ninguém ouviu falar em SEO.

Não existe trending topic.

Não existe feed personalizado.

Não existe recomendador.

Não existe botão compartilhar.

Mas existe uma manchete enorme anunciando alguma combinação absolutamente improvável de:

crime + sexo + tragédia + celebridade + sobrenatural.

O primeiro homem comenta:

— Você viu essa porra?

O segundo responde:

— Vi.

O terceiro pergunta:

— O que aconteceu?

E a informação começa a circular.

Tarantino poderia congelar a imagem exatamente aí.

Entraria uma guitarra surf dos anos 1960.

A tela ficaria vermelha.

E surgiria:

NOTÍCIAS POPULARES

Nada mais que a verdade.

Corta.

Créditos.

Mas o COBOLzeiro permanece sentado diante do terminal.

Porque ele percebeu uma coisa inquietante.

O Notícias Populares foi encerrado em 2001.

O código-fonte comportamental que fazia o Notícias Populares funcionar continua executando.

A banca virou feed.

O varal virou timeline.

A manchete virou thumbnail.

O jornaleiro virou algoritmo.

O Bebê-Diabo virou conteúdo viral.

A disputa por centímetros de papel virou disputa por pixels.

E as centenas de pessoas que paravam diante das bancas para ler gratuitamente as manchetes viraram bilhões de dedos fazendo:

SCROLL
SCROLL
SCROLL
STOP

Talvez o maior legado do NP seja justamente esse.

Ele demonstrou, muito antes do Facebook, do YouTube, do TikTok e dos recomendadores modernos, que existe uma disputa feroz pelo recurso computacional mais caro do planeta:

a atenção humana.

E nisso, meu caro COBOLzeiro...

o velho Notícias Populares tinha um algoritmo absolutamente infernal.

sábado, 13 de fevereiro de 2010

Densetsu no Yuusha no Densetsu — Muito Além dos Heróis Lendários


Bellacosa Mainframe apresenta densetsu no yuusha no densetsu

☕ Um Café no Bellacosa Mainframe

Densetsu no Yuusha no Densetsu — Muito Além dos Heróis Lendários

O Que Todo Programador COBOL Padawan Precisa Saber Sobre Sistemas Complexos, Arquitetura, Segurança, Liderança e Como um Anime de Fantasia Explica Engenharia de Software

Quando pensamos em fantasia medieval japonesa, normalmente imaginamos espadas, magia e reis em guerra. Densetsu no Yuusha no Densetsu começa exatamente assim... e então surpreende.

Por trás da aventura existe uma narrativa sobre arquitetura de sistemas, manipulação política, segurança, preconceito, inteligência, governança e o peso do conhecimento.

Para quem trabalha com tecnologia, especialmente em ambientes corporativos complexos como IBM Z, a identificação é imediata.


Ficha Técnica

Título original

伝説の勇者の伝説

Romaji

Densetsu no Yūsha no Densetsu

Título internacional

The Legend of the Legendary Heroes

Autor

Takaya Kagami

Ilustrações (Light Novel)

Saori Toyota

Mangá

Hiroko Nagakura

Estúdio

ZEXCS

Direção

Itsurō Kawasaki

Música

Yoshihisa Hirano

Light Novel

2002

Anime

1º de julho de 2010

Exibição

Julho a dezembro de 2010

Episódios

24

Gênero

  • Fantasia

  • Aventura

  • Ação

  • Drama

  • Magia

  • Política

  • Mistério

  • Dark Fantasy

Classificação sugerida

16 anos.


Sinopse

Ryner Lute é um jovem aparentemente preguiçoso, dorminhoco e sem grandes ambições.

Na realidade, ele é um dos magos mais perigosos do continente.

Seus olhos possuem o lendário Alpha Stigma, um poder capaz de analisar e copiar praticamente qualquer magia.

O problema?

Quem possui esse dom costuma ser perseguido, temido ou executado.

Depois de sobreviver à guerra, Ryner recebe uma missão do recém-coroado rei Sion Astal:

viajar pelo mundo em busca das antigas relíquias dos Heróis Lendários.

O que parecia uma simples aventura transforma-se numa gigantesca conspiração envolvendo impérios, religiões, experimentos humanos e entidades ancestrais.


Resumo da História

A jornada de Ryner e Ferris Eris passa por diversos reinos, onde encontram relíquias antigas, enfrentam guerras, descobrem conspirações e revelam verdades que ameaçam toda a estrutura política do continente.

Enquanto isso, Sion tenta construir um reino justo, mas descobre que governar exige escolhas dolorosas.

A narrativa alterna entre batalhas, diplomacia e mistérios, mostrando que o maior inimigo nem sempre está no campo de batalha.


Personagens Principais

Ryner Lute

O protagonista.

Extremamente inteligente.

Sarcasmo constante.

Poder praticamente ilimitado.

Carrega traumas profundos e tenta esconder sua dor atrás da preguiça.

Sua jornada é descobrir se alguém como ele pode viver em paz.


Ferris Eris

Uma das melhores espadachins do continente.

Fria.

Elegante.

Sarcástica.

Sua relação com Ryner evolui de forma natural e cheia de momentos cômicos.

É a responsável por manter Ryner vivo — tanto fisicamente quanto emocionalmente.


Sion Astal

Talvez o personagem mais complexo da série.

Herói da guerra.

Idealista.

Rei de Roland.

Deseja eliminar injustiças, mas percebe que o poder cobra um preço alto.


Lucile Eris

Provavelmente um dos indivíduos mais perigosos do universo da obra.

Sua presença muda completamente o rumo da história.


Miran Froaude

General brilhante e estrategista.

Representa o lado militar da política.


O Que Há de Diferente?

A maioria dos animes de fantasia segue um padrão:

  • existe um herói;

  • existe um vilão;

  • ocorre uma guerra.

Aqui, nada é tão simples.

Cada reino possui seus próprios interesses.

Cada líder acredita estar fazendo o correto.

Não existe um "lado totalmente bom".

É uma fantasia política, quase uma mistura de:

  • Game of Thrones

  • Fullmetal Alchemist

  • Legend of the Galactic Heroes

  • Record of Lodoss War


As Aventuras

Durante a jornada encontramos:

  • antigas armas mágicas;

  • cidades destruídas;

  • experimentos proibidos;

  • guerras civis;

  • organizações secretas;

  • bibliotecas ancestrais;

  • lendas esquecidas;

  • monstros;

  • magias proibidas;

  • conflitos diplomáticos.

Cada arco amplia a compreensão do mundo e mostra que os verdadeiros perigos estão nas decisões humanas.


As Mensagens Ocultas

1. O conhecimento assusta

Ryner é perseguido porque sabe demais e possui um poder incomum.

Na TI, especialistas em sistemas críticos muitas vezes também são vistos com desconfiança ou dependência excessiva.


2. Poder sem controle é risco

O Alpha Stigma lembra uma tecnologia extremamente poderosa.

Sem governança, pode causar destruição.

É como uma IA avançada, um sistema privilegiado ou um ambiente de produção sem controles.


3. Nem toda documentação conta a verdade

Ao longo da série, diversas "verdades históricas" revelam-se incompletas ou manipuladas.

Quem trabalha com sistemas legados sabe que documentação antiga nem sempre reflete a realidade do código.


4. Arquitetura invisível

Por trás dos acontecimentos existe uma estrutura muito maior.

Da mesma forma, em um ambiente corporativo vemos apenas a aplicação; por trás dela há infraestrutura, middleware, banco de dados, filas, segurança e integrações.


5. Liderança exige sacrifícios

Sion descobre que liderar não é apenas ter boas intenções.

É tomar decisões difíceis, muitas vezes impopulares, pensando no longo prazo.


O Paralelo com o Mainframe

Imagine um banco.

Milhares de aplicações.

Décadas de evolução.

Centenas de integrações.

Documentação incompleta.

Equipes diferentes.

Mudanças constantes.

Esse universo se parece muito com o continente de Densetsu no Yuusha no Densetsu.

Ryner é como o analista sênior que entende a arquitetura inteira.

Ferris representa a execução precisa.

Sion simboliza a gestão.

As relíquias antigas lembram sistemas legados que ainda sustentam operações críticas.

E o Alpha Stigma pode ser comparado ao domínio profundo da tecnologia: poderoso, raro e capaz de resolver problemas complexos, mas exigindo responsabilidade.


Engenharia de Software Disfarçada

Ao observar a história sob a ótica da TI, percebemos temas como:

  • arquitetura corporativa;

  • segurança da informação;

  • gestão de conhecimento;

  • governança;

  • interoperabilidade entre "reinos" (sistemas);

  • legado tecnológico;

  • gestão de riscos;

  • liderança técnica;

  • evolução sem quebrar compatibilidade.


Impacto Cultural

Embora nunca tenha alcançado o sucesso comercial de Sword Art Online, Re:Zero ou Overlord, a obra conquistou uma base fiel de fãs graças ao seu universo rico, personagens moralmente complexos e mistura de fantasia com política. O anime também despertou interesse pelas light novels, que expandem significativamente a história além dos 24 episódios.

Entre os admiradores do gênero, é frequentemente citado como uma joia subestimada dos anos 2010, justamente por priorizar desenvolvimento de mundo e dilemas humanos em vez de apenas batalhas.


Vale a Pena?

Sem dúvida.

Quem procura apenas ação talvez estranhe o ritmo.

Mas quem aprecia:

  • construção de mundo;

  • estratégia;

  • política;

  • personagens complexos;

  • mistérios;

  • fantasia madura;

encontrará uma obra rica e recompensadora.


Café no Bellacosa ☕

Em ambientes Mainframe, aprendemos cedo que o sistema mais importante nem sempre é o mais visível. Há camadas ocultas de arquitetura, regras de negócio e décadas de conhecimento acumulado sustentando milhões de transações.

Densetsu no Yuusha no Densetsu transmite exatamente essa ideia. O verdadeiro poder não está apenas na magia de Ryner, mas em compreender as conexões invisíveis que unem todo o mundo ao seu redor.

Para um Programador COBOL Padawan, a grande lição é clara: dominar uma linguagem é importante, mas entender a arquitetura, a governança, a segurança e o contexto do negócio é o que transforma um desenvolvedor em um verdadeiro arquiteto de soluções. Afinal, sistemas críticos — e grandes histórias — nunca são tão simples quanto parecem à primeira vista.

sexta-feira, 12 de fevereiro de 2010

SMP/E – Tracking Element Levels

 

Bellacosa Mainframe apresenta SMP/E Tracking Element Levels

SMP/E for z/OS Workshop – Tracking Element Levels

FMID, RMID e UMID sem mistério – no melhor estilo Bellacosa Mainframe


🎯 Por que o SMP/E controla níveis de elementos?

No mundo z/OS, nada é instalado “por cima e pronto”. Cada módulo, macro ou arquivo precisa ter rastro, histórico e responsável.

É exatamente isso que o SMP/E faz ao controlar o nível de serviço dos elementos nos ambientes:

  • Target Libraries (TZONE) – o que está em execução

  • Distribution Libraries (DZONE) – o que é a referência oficial

E o controle acontece por meio de três identificadores clássicos:

FMID – RMID – UMID

Se você domina esses três, domina auditoria, RESTORE, APPLY e ACCEPT.


🧠 A base de tudo: SYSMOD-ID

Todos os identificadores usados pelo SMP/E são extraídos do:

++HEADER

Eles são conhecidos genericamente como SYSMOD-ID, mas cada um tem um papel específico quando associado a um elemento.


🧩 O cenário do workshop (exemplo realista)

Vamos acompanhar a vida real de um elemento chamado MOD1.

📦 Function SYSMOD: HGF1200

  • Introduz três elementos: MOD1, MOD2, MOD3

  • Esses elementos formam o load module LMOD1

📌 Funções normalmente:

  • não usam JCLIN inline

  • usam relative file, que é um unload de um PDS com JCLIN


🏗️ APPLY da função – nascimento do elemento

Quando a função HGF1200 é aplicada:

  • MOD1 passa a existir na Target Library

  • SMP/E grava no TZONE:

IdentificadorValor
FMIDHGF1200
RMIDHGF1200
UMID

📌 Interpretação Bellacosa

MOD1 está no nível funcional.

A função HGF1200 é a dona do código.

Quando FMID = RMID, estamos falando de base code


📦 ACCEPT da função – espelho na DLIB

Ao executar ACCEPT:

  • MOD1 é copiado para a Distribution Library

  • Os mesmos valores são registrados no DZONE

📌 O DZONE sempre representa:

“Como o produto deveria estar”


🩹 PTF UY00020 – primeira substituição

O PTF UY00020:

  • contém um replacement de MOD1

  • precisa identificar o dono funcional do elemento:

++VER FMID(HGF1200)

Como é o primeiro serviço sobre a base, não precisa de PRE.

🧾 Após APPLY do PTF UY00020 (TZONE)

IdentificadorValor
FMIDHGF1200
RMIDUY00020
UMID

📌 Regra de ouro:

Um elemento tem apenas um RMID.


🩹 PTF UY00040 – nova substituição

Agora entra o UY00040:

  • substitui MOD1 novamente

  • declara o UY00020 como pré-requisito

  • identifica o dono funcional: HGF1200

Após APPLY:

IdentificadorValor
FMIDHGF1200
RMIDUY00040
UMID

📌 MOD1 agora está em um nível superior de serviço.


🐞 APAR AY91862 – update, não replacement

O APAR normalmente:

  • não substitui o elemento inteiro

  • faz um update para corrigir erro

O packager deve informar:

  • FMID – quem é o dono

  • PRE – qual SYSMOD está sendo atualizado

Após APPLY:

IdentificadorValor
FMIDHGF1200
RMIDUY00040
UMIDAY91862

📌 Conceito-chave

UMID representa quem atualizou o elemento.


🧩 USERMOD ME00012 – customização local

Agora entra o famoso USERMOD:

  • altera MOD1 localmente

  • precisa identificar:

    • FMID (HGF1200)

    • RMID (UY00040)

    • todos os UMIDs existentes

Após APPLY:

IdentificadorValor
FMIDHGF1200
RMIDUY00040
UMIDAY91862, ME00012

📌 Elemento pode ter vários UMIDs, mas apenas um RMID.


🔍 O que o SMP/E realmente está rastreando?

Para cada elemento, o SMP/E sabe responder:

  • Quem introduziu? → FMID

  • Quem substituiu por último? → RMID

  • Quem atualizou? → UMID(s)

Isso vale tanto para:

  • TZONE (APPLY)

  • DZONE (ACCEPT)


🛡️ Visão de auditoria (dica de ouro)

Se você vê:

  • USERMOD em produção

  • sem ACCEPT

  • com múltiplos UMIDs

👉 alerta de risco operacional

O SMP/E está dizendo a verdade. Basta saber ler.


🧠  Conclusão Bellacosa Mainframe

FMID diz quem manda
RMID diz quem substituiu
UMID diz quem mexeu

SMP/E não perde nada.
Quem se perde é quem não entende o CSI.

No próximo passo, o caminho natural é:

➡️ Consolidated Software Inventory

Porque rastrear é bom.
Consolidar é profissional.


💾 Mainframe bom é mainframe auditável. 

quinta-feira, 11 de fevereiro de 2010

RACF: Mapeamento OPERCMD x SDSF (do Console à Tela Verde

 

Bellacosa Mainframe apresenta RACF 

🔐 RACF NA VEIA

Mapeamento OPERCMD x SDSF (do Console à Tela Verde

“Quem manda no console manda no sysplex…
mas quem controla o RACF manda até no operador.”
☕🖥️

No mundo z/OS, existem dois universos de comando:

  1. Console MVS real → controlado pela classe OPERCMDS

  2. Interface SDSF → controlada por um conjunto de classes RACF

Muita gente confunde, mistura e sofre.
Vamos separar isso como JES2 separa spool 😈


🧱 1️⃣ OPERCMDS – O PODER DO CONSOLE MVS

🎯 O que controla?

A classe OPERCMDS controla quem pode emitir comandos MVS e subsistemas:

  • No console físico

  • Via TSO CONSOLE

  • Via REXX ADDRESS CONSOLE

  • Via automação (SA, NetView, OPS/MVS)


📌 Exemplos clássicos de comandos protegidos

ComandoPerfil OPERCMDS
D A,LMVS.DISPLAY.ACTIVE
D U,ALLMVS.DISPLAY.UNITS
$DA (JES2)JES2.DISPLAY.ACTIVE
$P JOB123JES2.PURGE.JOB
VARY 1234,ONLINEMVS.VARY.DEVICE.ONLINE
SET SMF=xxMVS.SET.SMF

📌 Regra de ouro:
👉 Se é comando MVS/JES, o RACF olha primeiro para OPERCMDS.


🧠 Exemplo RACF raiz

RDEFINE OPERCMDS MVS.DISPLAY.** UACC(NONE) PERMIT MVS.DISPLAY.** CLASS(OPERCMDS) ID(OPERADOR) ACCESS(READ) SETROPTS CLASSACT(OPERCMDS) SETROPTS RACLIST(OPERCMDS) REFRESH

🖥️ 2️⃣ SDSF – O CONSOLE DE MENTIRINHA (MAS PERIGOSO)

“SDSF não é console…
mas faz estrago igual.”
😈

O SDSF é uma interface, e o RACF controla cada ação separadamente.


🧩 Classes RACF usadas pelo SDSF

ClasseFunção
SDSFAcesso geral ao SDSF
JESJOBSAções sobre jobs (cancel, purge, hold)
JESComandos JES
OPERCMDSSe o SDSF emitir comando real
WRITERWriters e saída
LOGSTRMLogs do sistema
FACILITYFunções especiais

📊 3️⃣ Tabela Mestre – OPERCMDS x SDSF

🧠 A tabela que salva operadores e professores

Ação no SDSFClasse RACFPerfil
Entrar no SDSFSDSFSDSF
Ver jobs (ST/DA)JESJOBSJOB.*
Cancelar jobJESJOBSJOB.CANCEL
Purge jobJESJOBSJOB.PURGE
Hold / ReleaseJESJOBSJOB.HOLD
Ver SYSLOGSDSFLOG
Comando JES $DAJESJES2.DISPLAY.ACTIVE
Comando MVS D A,LOPERCMDSMVS.DISPLAY.ACTIVE
Alterar prioridadeJESJOBSJOB.MODIFY

📌 Fofoquice real:
👉 Você pode ver tudo no SDSF e não conseguir executar nada, mesmo sendo “OPERADOR”.


⚔️ 4️⃣ Quando OPERCMDS e SDSF se cruzam

🎯 Exemplo clássico

Usuário no SDSF digita:

/D A,L

👉 O que acontece?

  1. SDSF aceita o comando

  2. RACF valida OPERCMDS

  3. Se não tiver perfil → RC=8, NOT AUTHORIZED

📌 Moral:
SDSF não ignora OPERCMDS, ele chama o RACF como qualquer console.


🔐 5️⃣ Ambiente RACF Restritivo (vida real)

✔️ Boas práticas Bellacosa Approved™

  • Nunca dar OPERCMDS MVS.** para usuário comum

  • ✔️ Preferir:

    • MVS.DISPLAY.*

    • JES2.DISPLAY.*

  • ✔️ Cancelamento via JESJOBS, não OPERCMDS

  • ✔️ Usar ROLES no SDSF

  • ✔️ Logar tudo (SMF 80, 83, 84)


🧪 6️⃣ Checklist rápido de segurança

✔ SDSF separado por perfil
✔ OPERCMDS mínimo necessário
✔ JESJOBS granular
✔ LOG e SYSLOG somente READ
✔ Nada de UACC(READ) em produção 😱
SETROPTS AUDIT OPERCMDS ativo


☕ Frase final do Bellacosa Mainframe

“No mainframe, comando não é poder…
autorização é.”

 

quarta-feira, 10 de fevereiro de 2010

🦋 Lei do Efeito Borboleta

Bellacosa Mainframe e o efeito borboleta



🦋 Lei do Efeito Borboleta

Ou: como um IF mal fechado pode mudar a vida inteira

Eu sempre digo: a vida roda em batch.
Você agenda um JOB achando que é simples… e lá na frente, três execuções depois, dá um ABEND existencial.

A Lei do Efeito Borboleta parte exatamente desse princípio:
👉 pequenas causas podem gerar consequências gigantescas.

O nome vem da famosa frase:

“O bater de asas de uma borboleta no Brasil pode provocar um tornado no Texas.”

Exagero poético? Talvez.
Mas quem já trabalhou com sistema complexo sabe: não é força, é encadeamento.


🌪️ Origem do Conceito (o nascimento do caos)

O conceito surgiu nos anos 1960 com o meteorologista Edward Lorenz, estudando modelos climáticos.

📌 Ele percebeu que:

  • alterar um número decimal quase invisível

  • mudava completamente a previsão do tempo

Na prática:

0.506127 ≠ 0.506

Na vida:

  • um “sim”

  • um atraso

  • uma conversa não tida

  • uma decisão tomada no cansaço

E o sistema inteiro muda.


🖥️ O Efeito Borboleta no Mainframe (a vida como JCL)

Quem é mainframeiro entende na hora:

  • Um SORT mal definido

  • Um campo com sinal errado

  • Um JOB fora de sequência

  • Um dataset sobrescrito sem backup

No começo: nada acontece.
Depois: tudo acontece ao mesmo tempo.

🦋 Pequeno erro →
🔥 Grande incêndio operacional


🧠 Como entender o Efeito Borboleta na prática

✔️ Sistemas complexos não são lineares
✔️ Nem tudo cresce proporcionalmente
✔️ Algumas coisas só fazem sentido depois

A vida:

  • não é CICS online

  • é batch noturno com dependência cruzada


🎎 No Japão (e nos animes)

O Japão ama esse conceito, mesmo sem chamar pelo nome.

📺 Exemplos clássicos:

  • Steins;Gate – mudar uma mensagem muda o mundo

  • Erased – pequenos atos alteram destinos

  • Your Name – encontros mínimos, impactos máximos

  • Tokyo Revengers – tentar consertar cria novos problemas

Easter egg cultural:
👉 o respeito extremo às pequenas ações
Cumprimentar, chegar no horário, silêncio, cuidado com detalhes.


🧩 Dicas Bellacosa para a vida

🦋 Nunca subestime pequenos atos

  • Uma palavra

  • Um gesto

  • Uma omissão

🦋 Cuide do input

  • Dados ruins geram saídas ruins

  • Pensamentos ruins viram hábitos

🦋 Nem todo efeito é imediato

  • Alguns JOBs rodam só no futuro


🤫 Fofoquices filosóficas

  • A maioria dos “acidentes” não são acidentes

  • A maioria das “coincidências” são encadeamentos

  • A maioria dos arrependimentos começa pequeno

E ninguém percebe…
até o tornado chegar.


🦋 Importância do Efeito Borboleta

Ele nos ensina:

  • humildade

  • responsabilidade

  • atenção aos detalhes

Porque no fim das contas…

Você nunca sabe qual pequena decisão
vai mudar tudo.

E como bom mainframeiro, eu aprendi cedo:

📌 O sistema nunca erra.
Ele apenas executa o que foi configurado.

E a vida?
Também.

🦋

terça-feira, 9 de fevereiro de 2010

🦇 Movimento Dark 1980 & Gótico 1990 — A Estrada Noturna da Tribo Invisível


 

🦇 Movimento Dark 1980 & Gótico 1990 — A Estrada Noturna da Tribo Invisível
Um artigo ao estilo Bellacosa Mainframe para o blog El Jefe Midnight




🌑 Introdução — Quando a noite era uma linguagem secreta

Antes dos algoritmos, antes da avalanche de notificações, existia um Brasil onde ser diferente exigia coragem — e ousadia. Os anos 1980 e 1990 foram décadas em que as subculturas não vinham por streaming: elas eram contrabandeadas por fitas cassete mal gravadas, revistas importadas escondidas entre LPs usados e conversas sussurradas nos corredores escuros das escolas.

É aqui que nasce o movimento Dark dos anos 80 e evolui para o Gótico dos anos 90: uma estrada noturna percorrida por almas inquietas, artistas à margem, e adolescentes que descobriam que o preto não era só uma cor — era um manifesto.




🦇 1. Os Anos 1980 — O Brasil cinza e o surgimento do Dark

O país recém saía da ditadura, o rock nacional florescia e o underground respirava mal, mas respirava. A estética Dark entrou como um vírus elegante:

  • Cabelo comprido, franjas caídas, roupas rasgadas, coturnos;

  • Letras introspectivas, soturnas, existenciais;

  • Música vinda principalmente da Europa:

    • Siouxsie and The Banshees,

    • The Cure,

    • Joy Division,

    • Bauhaus,

    • Sisters of Mercy.

Mas aqui o Dark ganhou sotaque BR:

  • Ira! — “Mudança de Comportamento”

  • Plebe Rude

  • Legião Urbana — “Sereníssima”, “Tempo Perdido”

  • Arte No Escuro

  • Zero – “Quimeras”

Os jovens não tinham internet — tinham o fanzine: xerox mal cortado, letras tortas, cola quente e vontade. Distribuía-se na rua Augusta, na Galeria do Rock, nos roqueiros do Largo do Arouche.




🦇 2. Ritual de Iniciação — Como alguém virava Dark em 1986

  1. Uma fita K7 gravada de uma fita gravada de outra fita gravada da Rádio 89.

  2. Cabelos ao vento, franjas cobrindo o olho esquerdo.

  3. Roupas pretas: se não tinha griffe, a mãe ou a avó costuravam — movimento maker antes do maker existir.

  4. Pôsters de filmes: “O Corvo”, “The Hunger”, “Nosferatu”.

  5. Caminhadas noturnas discutindo Nietzsche sem ter lido Nietzsche.

  6. A tribo: se encontrava sem combinar; a cidade conspirava.

Era um movimento emocional, quase ritualístico.




🌒 3. Anos 1990 — A mutação para o Gótico

Quando chegam os 90, o Dark amadurece. Larga parte do punk, assume uma estética mais teatral e abraça o misticismo. O termo “gótico” se consolida.

Os pilares do gótico 90

  • Maquiagem pesada.

  • Ternos e sobretudos longos (aquele que sua mãe costurou!).

  • Simbolismo: ankh, crucifixos, caveiras discretas.

  • Anéis vampíricos

  • A melancolia deixa de ser fraqueza: vira estilo de vida.

As bandas do altar gótico

  • The Cure (rainha-mãe do movimento inteiro).

  • Clan of Xymox.

  • London After Midnight.

  • The Mission.

  • Type O Negative (para os iniciantes em trevas do metal).

Aqui no Brasil a cena se fortalece:

  • Madame Satã (Bexiga) — templo máximo.

  • Espaço Retrô, Santa Cecília — clássico.

  • Fofinho Rock Club, Belém — garagem pura.

  • Aeroanta, Dama Xoc, Carbono 14.

Se você passasse pela Augusta num domingo cedo, veria vampiros desorientados indo embora enquanto as senhoras iam para a missa na igreja da Consolação. Um ecossistema perfeito.


🌘 4. Tribos Urbanas — A necessidade humana de pertencer

O Dark/Gótico não era só música. Era pertencimento.

Para muitos jovens — vindos da periferia, de famílias partidas, de escolas opressoras, de bairros onde pagode e samba eram regra — o preto era uma forma de existir no mundo.

Os encontros eram míticos:

  • Cemitérios (não para cultos, mas porque eram silenciosos e tinham clima).

  • Becos da Paulista.

  • Madrugadas eternas na Praça Roosevelt.

  • Conversas sobre a vida, o universo e o nada, enquanto um hot-dog da Augusta segurava a ressaca emocional.

  • Caminhadas sobre a madrugada nas assustadoras ruas do Centro Velho de São Paulo (Rua São Bento, Rua Direita, XV de Novembro e vale do Anhangabaú entre outras).

  • Zanzar sob a luz da Lua em noites de inverno paulistana.

  • Estações ferroviárias CBTU fechadas, aguardando a abertura e o primeiro trem.

Quem viveu sabe: era liberdade em sua forma mais artesanal.


🌑 5. A Estética Hacker — o paralelo com o Mainframe

Como Bellacosa Mainframe exige:

O movimento Dark/Gótico tem uma lógica parecida com o mundo mainframe:

  • Poucos entendem.

  • Muitos falam sem saber.

  • Há uma estética própria, fechada, ritualística.

  • Você precisa dos velhos mestres para ser iniciado.

  • Existe documentação, mas ela é esparsa, oral, perdida em zines e memórias.

  • Quem faz parte… reconhece o outro no escuro.

Dark/Gótico é, essencialmente, um RACF Group invisível: só entra quem conhece a senha emocional.


🌑 6. Curiosidades (Easter Eggs Noturnos)

  • O perfume favorito dos góticos paulistanos 90 era o Kaiak preto ou o Malbec — mesmo sabendo que a aura deveria ser de mofo poético.

  • A maioria dos góticos da época sabia dançar Wave com fluidez, mesmo nunca tendo tido aula.

  • O termo “vampirear” significava andar sem destino pela madrugada.

  • Boa parte da cena gótica paulista nasceu… nos corredores da Galeria do Rock.

  • O movimento era pequeno, mas altamente ramificado: cyber-gótico, vampírico, etéreo, pós-punk, industrial.


🌑 7. Conclusão — Ser Dark/Gótico não era moda. Era autobiografia.

O movimento Dark dos 80 e o Gótico dos 90 foram, para milhares de jovens, a escola onde se aprende a ser sensível, inquieto e diferente num mundo que queria todo mundo igual.

Era música, era estética…
Mas era, acima de tudo, um lugar emocional.

E quem viveu sabe:
A noite não era cenário.
Era lar.

E mesmo que hoje sejamos adultos caretas, programadores COBOL com backlogs intermináveis, analistas de sistemas soterrados em JCL…
Dentro de muitos de nós ainda há aquele adolescente andando de preto, ouvindo The Cure num walkman velho, filosofando bobagens às 2 da manhã sob um poste queimado da Vila Alpina.

E isso, meu caro,
é o tipo de coisa que mesmo o tempo não apaga.
🖤🌙


🌘 Para ir mais longe

O Movimento Dark, que ganhou força nos anos 1980 e se expandiu durante os anos 1990, foi muito mais do que um estilo musical. Ele representou uma forma de expressão artística e cultural voltada para temas como melancolia, introspecção, romantismo sombrio, existencialismo e crítica social. Suas raízes podem ser encontradas no pós-punk britânico do final dos anos 1970, especialmente em bandas como Bauhaus, Siouxsie and the Banshees, The Cure e Sisters of Mercy.

A estética gótica incorporou elementos da literatura de Edgar Allan Poe, Bram Stoker e Mary Shelley, além da arquitetura medieval, do simbolismo e do romantismo do século XIX. Roupas escuras, maquiagem marcante, cabelos elaborados e acessórios inspirados em épocas passadas tornaram-se símbolos da identidade do movimento.

Durante os anos 1990, a cultura gótica diversificou-se com a ascensão do darkwave, industrial, gothic metal e outras vertentes alternativas. O movimento também influenciou animes, mangás, cinema, videogames e diversas manifestações artísticas.

Mais do que uma celebração da tristeza, o universo dark sempre valorizou a individualidade, a criatividade e a reflexão sobre aspectos profundos da existência humana. Seu legado permanece vivo até hoje, influenciando moda, música, arte e cultura pop em todo o mundo.


segunda-feira, 8 de fevereiro de 2010

A Normalização do Desvio: Doctor Who, COBOL e o Dia em que o Errado Virou Procedimento

Bellacosa Mainframe e a normalizacao do desvio

☕ Um Café no Bellacosa Mainframe

A Normalização do Desvio: Doctor Who, COBOL e o Dia em que o Errado Virou Procedimento

Uma viagem pela TARDIS dos incidentes para descobrir por que “sempre fizemos assim” talvez seja uma das frases mais perigosas da informática

08:07.

Sala de operação.

Café razoavelmente quente.

Mainframe perfeitamente indiferente aos dramas humanos.

Um job termina:

JOB04217 ENDED - RC=0004

O programador COBOL recém-chegado olha para a tela.

Ele chama o analista veterano.

— Deu RC=04.

O veterano nem levanta os olhos.

— Normal.

O jovem observa novamente.

RC=0004

Ele hesita.

— Mas quatro não significa que aconteceu alguma coisa diferente?

O veterano bebe o café.

— Faz três anos que termina assim.

— E está correto?

— Nunca deu problema.

Nesse exato momento, em algum ponto aparentemente impossível entre Londres, Gallifrey e uma sala de máquinas IBM, começa aquele som.

VWORP.

VWORP.

VWORP.

Uma velha cabine policial azul materializa-se entre dois racks.

A porta abre.

O Doctor sai.

Olha para o monitor.

Olha para o veterano.

Olha novamente para:

RC=0004

E pergunta:

— Por que isso é normal?

O veterano responde:

— Porque acontece todos os dias.

O Doctor faz uma expressão preocupada.

— Ah.

Pausa.

— Isso não significa que seja normal.

Outra pausa.

— Significa apenas que vocês se acostumaram.

E assim começa nosso segundo passeio pela TARDIS dos incidentes.

Hoje conheceremos um dos fenômenos mais fascinantes — e perigosos — da engenharia de sistemas:


Normalization of Deviance

ou:

Normalização do Desvio.


🌀 Primeiro precisamos voltar no tempo

Nossa viagem anterior terminou no Swiss Cheese Model, de James Reason.

Aprendemos que sistemas complexos possuem várias camadas de defesa.

Cada camada possui fragilidades.

Os famosos buracos do queijo.

Um erro pode atravessar uma barreira e ser interrompido pela seguinte.

O desastre aparece quando vários buracos acabam alinhados.

Mas existe uma pergunta que ficou esperando dentro da TARDIS:

Como alguns desses buracos ficam tão grandes?

Ou ainda:

Como uma organização consegue conviver durante anos com uma situação claramente anormal sem perceber que existe perigo?

É aqui que encontramos a socióloga Diane Vaughan.

Vaughan estudou profundamente o processo decisório relacionado ao desastre do ônibus espacial Challenger e popularizou o conceito de normalization of deviance para explicar como desvios em relação aos padrões esperados podem, ao longo do tempo, tornar-se aceitos como normais dentro de uma organização. Materiais posteriores da própria NASA continuam usando explicitamente o conceito ao discutir Challenger, Columbia e outros eventos de segurança. (NTRS)

A ideia pode ser resumida assim:

Algo começa fora do padrão.

Nada ruim acontece.

Repetimos.

Nada ruim acontece novamente.

Repetimos outra vez.

Lentamente deixamos de enxergar aquilo como exceção.

Até que o desvio se transforma em normalidade.

E talvez a frase mais importante deste artigo seja:

Ausência de desastre não é evidência de segurança.


🧀 O queijo suíço começa a mudar de sabor

Voltemos ao nosso exemplo.

O padrão oficial diz:

RC=0000

Mas determinada rotina começou a terminar ocasionalmente com:

RC=0004

Na primeira vez alguém investigou.

Descobriu que existia um warning.

O processamento pareceu correto.

Nada foi perdido.

Então alguém decidiu:

— Podemos seguir.

Na semana seguinte:

RC=04 novamente.

A equipe verifica.

Tudo aparentemente correto.

Depois de um mês, ninguém verifica.

Depois de seis meses, o operador escreve no procedimento:

RC=04 pode ser ignorado.

Depois de dois anos, um programador pergunta:

— Por quê?

E ninguém mais sabe.

Essa é a parte fascinante.

A exceção adquiriu tradição.


👻 O fantasma do “nunca deu problema”

Existe uma expressão que aparece frequentemente em incidentes:

“Sempre fizemos assim.”

Sua prima:

“Nunca deu problema.”

E uma terceira:

“Isso acontece direto.”

As três deveriam causar aproximadamente a mesma reação que ouvir alguém dizer em Doctor Who:

“Não se preocupe. Essas estátuas nunca se mexem.”

Talvez seja uma boa hora para não piscar.


🚀 Challenger: quando resultados anteriores começam a ensinar a lição errada

O conceito de Diane Vaughan ficou fortemente associado à análise organizacional do desastre do Space Shuttle Challenger.

O Challenger foi destruído 73 segundos após o lançamento de 28 de janeiro de 1986, e os sete tripulantes morreram. A investigação e os estudos posteriores concentraram-se, entre outras questões, no comportamento dos O-rings dos Solid Rocket Boosters e no processo decisório que antecedeu o lançamento. (NTRS)

Mas o aspecto organizacional é particularmente interessante para nossa TARDIS.

Problemas e evidências envolvendo comportamento inadequado dos O-rings haviam aparecido anteriormente.

Os lançamentos anteriores, entretanto, não haviam terminado em catástrofe.

E aí ocorre algo profundamente humano.

Cada sucesso anterior começa a funcionar como argumento de segurança.

Observe a perversidade lógica:

Houve anomalia.
       ↓
Não ocorreu acidente.
       ↓
Logo, a anomalia aparentemente é tolerável.
       ↓
Repetimos.
       ↓
Outra anomalia.
       ↓
Novamente não ocorreu acidente.
       ↓
A confiança aumenta.

Parece lógico.

Mas existe um problema monumental.

Talvez você não esteja demonstrando que o sistema é seguro.

Talvez esteja apenas tendo sorte.

A própria NASA posteriormente passou a discutir explicitamente a normalização do desvio como uma lição de segurança associada a Challenger e Columbia. (NTRS)


🎲 Sorte não é controle operacional

Imagine um programa COBOL.

Existe um array:

01  WS-TABELA.
    05 WS-ITEM OCCURS 100 TIMES.

Alguém encontra um cenário onde um índice eventualmente chega a 101.

Por alguma razão, nada visível acontece.

Talvez aquela posição de memória não produza imediatamente um efeito perceptível.

Executa novamente.

Nada.

Mais uma vez.

Nada.

Alguém conclui:

“Pode deixar.”

Não.

O que aconteceu foi apenas:

“Ainda não observamos a consequência.”

Essas duas frases parecem semelhantes.

Não são.


🧠 O cérebro humano aprende com resultados

Nós somos excelentes máquinas de reconhecimento de padrões.

Isso nos salvou muitas vezes durante a evolução.

Se fazemos algo repetidamente e recebemos um resultado positivo, nosso cérebro aprende:

isso funciona.

No trabalho ocorre o mesmo.

Imagine:

procedimento oficial: 12 passos.

Operador percebe que pode pular os passos 4 e 7.

Executa.

Tudo funciona.

No dia seguinte repete.

Funciona.

Depois ensina para o colega:

— Esses dois você não precisa fazer.

Meses depois chega um novo funcionário.

Pergunta por que o procedimento possui doze passos se todo mundo realiza dez.

Resposta:

— O documento está velho.

Talvez esteja.

Ou talvez os passos quatro e sete existam porque alguém aprendeu uma lição extremamente cara em 1998.

Mas ninguém mais se lembra.


🏛️ A arqueologia dos procedimentos

Essa é uma dica valiosíssima para quem entra em ambientes legados.

Nunca presuma imediatamente que um procedimento estranho é inútil.

Pergunte:

por que isso existe?

Mainframes possuem décadas de história operacional.

Algumas rotinas aparentemente absurdas surgiram porque algum incidente igualmente absurdo aconteceu muito tempo atrás.

Talvez exista uma checagem aparentemente redundante porque um arquivo chegou vazio em 1994.

Talvez exista uma reconciliação porque um lote foi processado duas vezes em 2001.

Talvez alguém exija:

COUNT INPUT = COUNT OUTPUT + COUNT REJECT

porque certa madrugada milhões desapareceram em alguma etapa intermediária.

Procedimentos carregam fósseis de incidentes.

O problema aparece quando esquecemos a história.

Então começamos a retirar as proteções.


🦖 Easter Egg nº 1 — O procedimento jurássico

Todo ambiente mainframe possui pelo menos um procedimento cujo autor:

  1. aposentou-se;

  2. mudou de empresa;

  3. ninguém conhece;

  4. talvez seja hoje uma lenda;

  5. ou possivelmente todos os anteriores.

O documento chama-se algo como:

PROCEDIMENTO_BATCH_FINAL_REV17_2007.doc

Ninguém sabe por que o passo 13 existe.

Portanto alguém decide removê-lo.

Três semanas depois descobrimos.


🚨 Como nasce a Normalização do Desvio?

Ela raramente aparece em uma reunião onde alguém anuncia:

“A partir de hoje vamos trabalhar perigosamente.”

Seria conveniente.

Normalmente acontece gradualmente.

Primeiro surge uma pequena exceção.

Depois uma justificativa.

Depois repetição.

Depois tolerância.

Depois hábito.

Depois cultura.

Podemos representar assim:

PADRÃO
  ↓
PEQUENO DESVIO
  ↓
NADA ACONTECE
  ↓
REPETIÇÃO
  ↓
ACEITAÇÃO
  ↓
NOVO NORMAL
  ↓
DESVIO MAIOR
  ↓
NADA ACONTECE
  ↓
NOVA ACEITAÇÃO
  ↓
...
  ↓
INCIDENTE

Perceba um detalhe terrível.

A fronteira do aceitável se move.

Pouco a pouco.


🐸 A metáfora do sapo — com cuidado

Existe aquela famosa história do sapo colocado em água que esquenta lentamente e não percebe até ser tarde demais.

Como descrição literal do comportamento real de sapos, essa história é problemática.

Mas como metáfora organizacional é extraordinariamente útil.

As pessoas percebem facilmente uma mudança enorme.

Percebem muito menos uma mudança de 1% por semana.

Essa erosão progressiva da segurança também aparece em discussões de engenharia de segurança sob ideias relacionadas, como condições latentes e drift toward failure; um material da NASA sobre segurança organizacional coloca explicitamente esses conceitos próximos à normalização do desvio. (NTRS)


🖥️ Normalização do Desvio no Bellacosa Mainframe

Agora vamos aterrissar definitivamente no z/OS.

Imagine algumas frases.

“Esse dataset chega a 95%, mas nunca estourou.”

Desvio.

“Esse job demora três horas, mas sempre terminou antes da abertura.”

Desvio potencial.

“Temos que reiniciar a CICS toda quarta-feira.”

Hmm.

“Essa transação às vezes dá timeout; manda tentar de novo.”

Muito interessante.

“Quando ocorre esse ABEND, basta restartar.”

Doctor?

“Esse usuário tem SPECIAL porque facilita o suporte.”

DOCTOR?

“Essa senha é compartilhada pela equipe porque é operacional.”

DOCTOR!

O problema não é simplesmente cada situação isolada.

O problema é quando o excepcional ganha aparência de normalidade.


💾 Exemplo: o dataset de 95%

Segunda-feira:

82%.

Terça:

84%.

Semana seguinte:

87%.

Mês seguinte:

91%.

Alerta dispara.

Equipe limpa espaço.

Volta para 75%.

Meses depois:

93%.

Nada acontece.

Depois:

94%.

Nada.

95%.

Ainda funciona.

Então aparece uma nova crença:

“Até 95 está tranquilo.”

Observe.

O limite técnico pode não ter mudado.

Mas o limite psicológico mudou.

Depois chega 96%.

Funcionou.

Novo normal:

Depois 97.

Você percebe o padrão?

Estamos transformando sobrevivência passada em autorização futura.


⏱️ Exemplo: batch cada vez mais lento

Seu batch deveria terminar às 03:00.

Durante anos termina 02:15.

Um dia:

02:24.

Depois:

02:31.

02:38.

02:42.

02:50.

Ainda antes das 03:00.

Então ninguém se preocupa.

02:56.

02:58.

Continua “dentro da janela”.

Até que numa sexta-feira:

03:17.

E alguém pergunta:

— Como esse problema apareceu de repente?

Resposta:

não apareceu de repente.

Nós apenas demoramos para reconhecê-lo.


🔍 Aqui entram os Weak Signals

No episódio anterior falamos sobre sinais fracos.

Agora fica claro por que eles são tão importantes.

Normalização do desvio é frequentemente a arte organizacional de transformar sinais fracos em paisagem.

Um alerta aparece todo dia.

Inicialmente incomoda.

Depois você aprende a fechá-lo.

Depois configura filtro.

Depois ninguém vê.

Isso possui até um conceito associado:

alarm fatigue.

Quando tudo alerta, nada alerta.

Se um sistema produz 10.000 mensagens irrelevantes, a mensagem realmente importante precisa competir com 9.999 ruídos.


🚨 O pior alerta é aquele que todos conhecem

Imagine:

WARNING XYZ123

Operador novo:

— O que significa?

Veterano:

— Ignora.

— Por quê?

— Sempre aparece.

Essa conversa deveria imediatamente gerar uma pergunta:

Se é realmente irrelevante, por que ainda é um warning?

Existem duas possibilidades:

  1. o alerta deveria ser eliminado ou corrigido;

  2. o comportamento deveria ser investigado.

Deixar um warning permanente ensina pessoas a ignorarem warnings.

É treinamento comportamental involuntário.


🧀 Swiss Cheese + Normalization of Deviance

Agora podemos conectar nossos dois episódios.

No Swiss Cheese Model aprendemos que as barreiras possuem buracos.

A Normalização do Desvio mostra algo ainda mais assustador:

podemos aprender a conviver com os buracos.

Pior:

podemos ampliá-los.

Imagine:

FATIA 1 — PROCEDIMENTO

Desvio conhecido:
passo de validação ignorado.

Nada acontece.

Depois:

FATIA 2 — TESTE

Desvio conhecido:
cenário raro não testado.

Nada acontece.

Depois:

FATIA 3 — MONITORAMENTO

Desvio conhecido:
alerta ignorado.

Nada acontece.

Temos agora três buracos maiores.

O queijo suíço está ficando perigosamente transparente.


🛸 A TARDIS precisa viajar para antes do desastre

Em um post-mortem tradicional, talvez alguém pergunte:

“O que aconteceu às 14:32?”

Mas na normalização do desvio talvez precisemos perguntar:

“Quando esse comportamento começou?”

Pode ter sido:

três dias antes;

seis meses;

cinco anos.

Essa é outra razão pela qual incidentes são problemas temporais.

Precisamos estudar sua genealogia.


📝 Passo a passo — Como detectar Normalization of Deviance

Pegue papel, quadro, planilha, Confluence, SharePoint ou aquele bloco de notas que todo analista mainframe inexplicavelmente mantém ao lado do teclado.

Faça algumas perguntas.

Passo 1 — Liste os “sempre fazemos assim”

Converse com operadores e desenvolvedores.

Procure frases:

  • sempre fazemos;

  • pode ignorar;

  • nunca deu problema;

  • funciona desse jeito;

  • esse erro é normal;

  • precisa executar duas vezes;

  • de vez em quando trava;

  • é só reiniciar;

  • todo mundo usa esse usuário;

  • produção é diferente.

Cada uma merece investigação.

Não significa necessariamente que existe perigo.

Significa:

há algo interessante aqui.


🔍 Passo 2 — Compare prática e procedimento

Existe uma diferença entre:

work as imagined

e

work as done.

O primeiro é como imaginamos que o trabalho acontece.

O segundo é como ele realmente acontece.

Manual:

1. Gerar relatório.
2. Validar relatório.
3. Solicitar aprovação.
4. Executar processamento.

Realidade:

1. Gerar relatório.
2. Ninguém olha.
3. João manda OK no Teams.
4. Executar.

Temos um gap.

Investigue.


📈 Passo 3 — Procure tendências, não apenas limites

Não pergunte apenas:

“Passou do SLA?”

Pergunte:

“Está se aproximando progressivamente dele?”

Não pergunte apenas:

“Dataset encheu?”

Pergunte:

“Qual é a tendência de crescimento?”

Não pergunte:

“Houve ABEND?”

Pergunte:

“Warnings estão aumentando?”

Sistemas frequentemente contam sua doença antes de entrar em coma.

Precisamos escutar.


🧯 Passo 4 — Catalogue near misses

Lembra dos quase acidentes?

Eles são especialmente importantes aqui.

Imagine:

produção errada preparada.

Alguém percebe antes da execução.

Todo mundo comemora:

— Ainda bem.

Fecha chamado.

Fim.

Não.

Pergunte:

Por que quase executamos?

A NASA também usa casos de close call para discutir normalização do desvio. Em uma retrospectiva sobre a caminhada espacial EVA 23, a agência descreveu como uma falha de sensor passou a ser aceita como normal com base na experiência anterior, sem que sua causa fosse adequadamente questionada. (NASA)

Esse é um exemplo fantástico.

O sistema estava literalmente ensinando a equipe a aceitar um comportamento anormal.


🧠 Passo 5 — Pergunte o que mudou no significado de “normal”

Isso é poderoso.

Não pergunte apenas:

O sistema mudou?

Pergunte:

Nossa tolerância mudou?

Talvez um job sempre tivesse de terminar em 30 minutos.

Agora consideramos 50 aceitável.

Quando isso aconteceu?

Quem decidiu?

Foi formal?

Houve análise?

Ou aconteceu organicamente?


📏 Passo 6 — Defina guardrails

Um guardrail é uma proteção clara.

Por exemplo:

CPU > X        → investigar
Elapsed > Y    → investigar
Dataset > 85%  → agir
RC != 0        → justificar
Rejeição > Z%  → interromper

O importante é evitar limites negociáveis diariamente.

Caso contrário:

80 parece seguro.

82 também.

85 também.

90 também.

Até 99.


🛑 Passo 7 — Crie stop conditions

Profissionais precisam saber quando parar.

Em algumas culturas operacionais existe enorme pressão para:

continuar funcionando.

Mas maturidade também significa saber dizer:

“Não temos evidência suficiente para continuar com segurança.”

Isso vale para:

deploy;

migração;

batch;

IPL;

alteração de banco;

processamento financeiro;

mudança de infraestrutura.


🧹 Passo 8 — Mate warnings permanentes

Se existe alerta que pode ser ignorado diariamente, faça alguma coisa.

Corrija a causa.

Ajuste o alerta.

Mude severidade.

Documente formalmente.

Mas evite criar uma floresta de warnings inúteis.

Porque um dia, entre eles, chegará o warning importante.


🧪 Passo 9 — Revalide exceções

Toda exceção operacional deveria ter prazo.

Exemplo:

“Durante três semanas aceitaremos processamento de até 70 minutos.”

Excelente.

Depois de três semanas:

reavaliar.

Sem isso a exceção temporária possui uma habilidade corporativa impressionante:

tornar-se permanente.


📚 Passo 10 — Preserve memória organizacional

Documente:

  • por que o controle existe;

  • qual incidente o originou;

  • que risco ele reduz;

  • quem pode alterá-lo.

Imagine um comentário:

* NÃO REMOVER ESTA VALIDAÇÃO.
* INTRODUZIDA APÓS INCIDENTE INC-2008-1742.
* SEM ELA REGISTROS DUPLICADOS PODEM SER
* PROCESSADOS EM RESTART.

Isso vale ouro.

Muito melhor que:

* NAO MEXER.

Embora, admitamos, o segundo tenha certa elegância ameaçadora.


👾 Easter Egg nº 2 — “Não pisque”

No universo de Doctor Who, os Weeping Angels possuem uma regra extremamente simples:

Don't blink.

Na operação talvez devêssemos criar outra:

Don't normalize.

Encontrou algo estranho?

Observe.

Entenda.

Explique.

Corrija ou aceite conscientemente.

Mas nunca permita que se torne normal apenas porque você o viu muitas vezes.


⚠️ Normalização não significa incompetência

Essa é uma parte importantíssima.

Pessoas envolvidas nesse processo não precisam ser irresponsáveis.

Normalização do desvio pode acontecer justamente com profissionais experientes.

Eles conhecem o sistema.

Já viram aquilo várias vezes.

Criaram adaptações.

Obtiveram sucesso.

Então seu próprio conhecimento produz confiança.

Esse é o paradoxo.

Experiência pode aumentar segurança.

Mas experiência com desvios sobrevividos também pode produzir excesso de confiança.


🧭 “Funcionou ontem” não é prova matemática

Existe uma lógica silenciosa:

Funcionou 100 vezes.
Logo funcionará na 101ª.

Não necessariamente.

Talvez exista uma probabilidade pequena de falha.

Imagine 1%.

Você pode executar dezenas de vezes sem observar nada.

Isso não torna o risco zero.

Significa apenas que a amostra ainda não encontrou o problema.

Em sistemas críticos, precisamos evitar confundir:

histórico de sucesso

com

demonstração de segurança.


💥 Quando a sorte cobra juros

Pense numa equipe que realiza deploy manualmente.

Existe um passo perigoso.

Durante cinco anos ninguém erra.

A organização conclui:

O processo é seguro.

Talvez não seja.

Talvez você tenha uma equipe extraordinariamente cuidadosa compensando um processo ruim.

Então chega:

turnover;

pressão;

madrugada;

incidente paralelo;

pessoa nova;

cansaço.

Os buracos alinham.

A organização pergunta:

— Por que fulano errou?

Resposta mais interessante:

Por que nossa segurança dependia de ninguém jamais errar?


⚖️ Just Culture entra novamente na TARDIS

Precisamos criar ambiente onde alguém consiga dizer:

“Isso aqui está errado.”

Sem ouvir:

“Sempre funcionou.”

Profissionais novos possuem uma vantagem curiosa.

Eles ainda enxergam estranheza.

Depois de anos, nossos olhos se acostumam.

Por isso uma pergunta aparentemente ingênua pode ser extremamente valiosa:

“Por que fazemos isso?”

Nunca ridicularize essa pergunta.

Talvez o iniciante esteja vendo um buraco que todos os veteranos aprenderam a ignorar.


☕ Conselho Bellacosa para quem começa em COBOL

Se entrar num ambiente e alguém disser:

“Esse erro é normal.”

Não responda imediatamente:

“Está errado!”

Você ainda não possui contexto.

Pergunte humildemente:

“Você pode me explicar por que ele ocorre e por que sabemos que é seguro?”

Essa pergunta é extraordinária.

Pode haver uma explicação perfeitamente legítima.

Ótimo.

Você aprendeu.

Mas talvez a resposta seja:

“Não sei. Sempre foi assim.”

Nesse momento:

anote.

Talvez você tenha encontrado nossa próxima investigação.


🔬 Métricas que ajudam

Algumas tendências merecem acompanhamento:

tempo médio de batch;

CPU;

I/O;

paging;

volume processado;

crescimento de datasets;

frequência de restart;

ABENDs;

warnings;

timeouts;

filas;

reprocessamentos;

erros funcionais;

chamados repetidos;

intervenções manuais.

E existe uma métrica especialmente interessante:

quantas vezes alguém precisa “dar um jeitinho” para o sistema continuar funcionando?

Não costuma existir no dashboard.

Talvez devesse.


👨‍🚒 Heroísmo operacional pode esconder fragilidade

Existe aquele profissional lendário.

Quando tudo quebra:

liga para Carlos.

Carlos executa três comandos misteriosos.

Sistema volta.

Todos aplaudem.

Excelente Carlos.

Mas temos um problema.

Se isso acontece constantemente, Carlos pode estar funcionando como mecanismo compensatório de uma arquitetura frágil.

Organizações frequentemente confundem heroísmo com resiliência.

Resiliência é:

o sistema consegue lidar com problemas.

Heroísmo é:

precisamos encontrar Carlos às 03:17.

São coisas diferentes.


🌀 Doctor Who e o perigo da rotina

Talvez essa seja nossa melhor conexão com Doctor Who.

O Doctor chega em um lugar onde moradores dizem:

— Sempre fazemos esse ritual.

— Por quê?

— Porque sempre fizemos.

— E aquela porta?

— Nunca abrimos.

— Por quê?

— Porque disseram que não devemos.

Naturalmente atrás da porta existe algum alienígena ancestral capaz de destruir metade da galáxia.

Em organizações, nossos monstros são menos cinematográficos.

São:

scripts antigos;

autorizações excessivas;

warnings ignorados;

planilhas manuais;

restarts rotineiros;

acessos compartilhados;

validações puladas;

backups nunca restaurados;

procedimentos desatualizados.

Mas o mecanismo psicológico é surpreendentemente parecido.


🔄 A Regeneração

Nossa série não existe para admirar acidentes.

Existe para aprender.

Então qual seria a regeneração depois de detectar normalização do desvio?

Primeiro:

tornar o desvio novamente visível.

Depois:

entender sua origem.

Medir o risco.

Decidir conscientemente:

corrigir;

mitigar;

monitorar;

ou formalmente aceitar.

O fundamental é substituir:

“sempre fizemos assim”

por:

“sabemos por que fazemos assim.”

Essa diferença representa maturidade operacional.


📓 Diário do Doctor

Guarde estas ideias.

Normalização do desvio ocorre quando uma prática fora do padrão passa gradualmente a ser aceita porque consequências negativas não apareceram imediatamente.

Sucesso passado não comprova segurança futura.

Near misses são dados, não apenas golpes de sorte.

Warnings repetidos precisam ser entendidos, não domesticados.

A tolerância organizacional pode mudar lentamente sem decisão formal.

Procedimentos podem carregar memória de acidentes antigos.

Iniciantes enxergam coisas que veteranos deixaram de notar.

“Nunca deu problema” descreve o passado. Não garante absolutamente nada sobre amanhã.

E sobretudo:

O desvio mais perigoso pode ser justamente aquele que deixou de parecer desvio.


🕰️ 17:43 — sexta-feira

Voltamos à nossa sala de operação.

O programador iniciante continua olhando para:

JOB04217 ENDED - RC=0004

O veterano termina o café.

O Doctor aproxima-se.

— Há quanto tempo isso acontece?

— Uns três anos.

— Alguém investigou?

— No começo.

— E descobriram a causa?

Silêncio.

— Não lembro.

O Doctor sorri.

Não é um sorriso tranquilizador.

— Excelente.

— Excelente?

— Sim.

Ele abre a porta da TARDIS.

— Encontramos nosso monstro.

O programador aponta para a tela.

— O RC=04?

— Não.

O Doctor entra.

— O fato de vocês terem parado de perguntar por quê.

A porta fecha.

VWORP.

VWORP.

VWORP.

A cabine desaparece.

O jovem olha novamente para o console.

Pensa durante alguns segundos.

Abre o histórico.

Pesquisa:

JOB04217

Três anos.

Centenas de RC=04.

Mas encontra algo interessante.

No começo acontecia uma vez por mês.

Depois semanalmente.

Depois diariamente.

Mais interessante ainda:

o elapsed time também estava aumentando.

Pouco.

Lentamente.

Quase imperceptivelmente.

Ele pega o telefone.

— Temos uma coisa estranha aqui.

Do outro lado alguém pergunta:

— Está dando erro?

Ele olha para:

RC=0004

Sorri.

— Ainda não.

E talvez essa seja justamente a melhor hora para investigar.

Porque incidentes possuem uma propriedade desagradável:

antes de acontecerem, parecem apenas possibilidades.

Depois que acontecem, todos dizem que eram óbvios.

Nossa missão nessa série será encontrá-los enquanto ainda estão no primeiro grupo.

☕🌀


🥚 Easter Egg final

Em algum lugar do código do JOB04217 existe um comentário que ninguém havia notado:

      * BAD WOLF

Ninguém sabe quem escreveu.

O ChangeMan indica que a linha existe desde 2005.

Melhor deixarmos para outra viagem.

Next stop: Hindsight Bias — o estranho fenômeno pelo qual todo incidente se torna absolutamente óbvio cinco minutos depois de acontecer.


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