☕ 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, 7 de outubro de 2012

Zero-Risk Bias: Doctor Who, COBOL e o Dia em que Eliminamos um Risco de 1% — e Ignoramos Outro de 40%

 

Bellacosa Mainframe e o  zero-risk bias

☕ Um Café no Bellacosa Mainframe

Zero-Risk Bias: Doctor Who, COBOL e o Dia em que Eliminamos um Risco de 1% — e Ignoramos Outro de 40%

Uma viagem pela TARDIS dos incidentes para entender por que “risco zero” é psicologicamente irresistível — mesmo quando perseguir o zero pode custar caro, atrasar decisões e piorar o risco total do sistema

09:08.

Segunda-feira.

Sala de risco.

Café quente.

Na tela:

RISCO A
---------
Probabilidade: 1%
Impacto: baixo
Mitigação possível:
1% → 0%

Custo:
R$ 800.000

Ao lado:

RISCO B
---------
Probabilidade: 40%
Impacto: alto
Mitigação possível:
40% → 15%

Custo:
R$ 800.000

O gerente olha.

— Vamos eliminar o risco A.

Nosso jovem programador COBOL franze a testa.

— Por quê?

— Porque conseguimos zerar.

— E o risco B?

— Continuaria existindo.

— Mas cairia de 40% para 15%.

— Sim.

— Isso parece uma redução muito maior.

— Mas ainda sobraria 15%.

Nosso jovem olha novamente.

A:
1% → 0%

B:
40% → 15%

Ele começa a fazer contas.

O primeiro elimina:

1 ponto percentual.

O segundo elimina:

25 pontos.

Mesmo custo.

Ele pergunta:

— Então estamos escolhendo evitar 1 caso em 100 em vez de reduzir 25 casos em 100?

O gerente responde:

— Estamos eliminando completamente um risco.

Pausa.

— Zero.

Ah.

A palavra.

ZERO.

Ela possui um poder psicológico impressionante.

Zero erro.

Zero incidente.

Zero vazamento.

Zero falha.

Zero risco.

VWORP.

VWORP.

VWORP.

A TARDIS materializa-se atrás do projetor.

A porta abre.

O Doctor sai.

Olha para os dois números.

— Qual opção evita mais problemas?

— B.

— Qual escolheram?

— A.

— Por quê?

O gerente responde:

— Porque elimina um risco completamente.

O Doctor sorri.

— Ah.

— O quê?

— Humanos gostam de transformar zero em uma propriedade mágica.

Pausa.

— Matemática normalmente não é tão sentimental.

Bem-vindo ao:



Zero-Risk Bias

Ou:

Viés do Risco Zero

A tendência de preferir eliminar completamente um risco pequeno, reduzindo-o a zero, em vez de escolher uma alternativa que produza uma redução maior no risco total, mas deixe algum risco residual.

Em linguagem Bellacosa:

“Se uma opção chega a zero, nosso cérebro pode gostar tanto dela que esquece de perguntar quanto risco total realmente eliminamos.”


🧠 O fascínio do zero

Por que zero parece tão especial?

Porque zero é:

final.

Limpo.

Sem ambiguidade.

Sem risco residual.

Sem “talvez”.

1% → 0%

é psicologicamente satisfatório.

Já:

40% → 15%

deixa uma sobra.

E nosso cérebro olha para:

15%

e pensa:

“Ainda existe risco.”

Correto.

Mas esquece:

reduzimos 25 pontos percentuais.


☕ Bellacosa Mainframe: o alerta impossível

Imagine:

alerta falso acontece:

1 vez por mês.

Equipe decide:

“Queremos zero falso positivo.”

Então ajusta thresholds agressivamente.

Resultado:

falsos positivos:

zero.

Excelente.

Mas agora alguns incidentes reais deixam de gerar alerta.

O risco eliminado:

incômodo.

O risco aumentado:

falha não detectada.

Zero pode ter sido obtido...

deslocando risco para outro lugar.


🧠 Zero em uma métrica pode piorar o sistema inteiro

Essa é uma das grandes lições.

Você pode obter:

FALSE POSITIVES = 0

mas talvez:

FALSE NEGATIVES ↑

Ou:

CHANGE FAILURES = 0

porque:

DEPLOYMENTS = 0

Parabéns.

Eliminamos falha de mudança...

eliminando mudança.

Produção ficou perfeitamente segura.

Até envelhecer.


👻 Easter Egg nº 1 — Daleks e zero risco

Dalek:

— ZERO RISK OF HUMAN REBELLION.

Doctor:

— Como?

Dalek:

— ELIMINATE ALL HUMANS.

Doctor:

— Tecnicamente eficaz.

Pausa.

— Talvez um pouco agressivo na otimização.

Toda solução de risco possui:

efeitos colaterais.


🧠 Zero-Risk Bias e Need for Control

O capítulo anterior encaixa perfeitamente.

Need for Control diz:

“Quero reduzir incerteza.”

Zero-Risk Bias oferece a solução psicologicamente perfeita:

“Zere.”

Agora organizações começam:

adicionar controles;

bloquear mudanças;

proibir ações;

buscar zero incidente.

Mas:

zero em um tipo de risco não significa risco total mínimo.


☕ Zero change risk

Uma empresa pode decidir:

“Não vamos mudar nada antes do fechamento.”

Talvez razoável.

Agora expande:

“Melhor não mudar quase nada nunca.”

Mudanças caem.

Risco de deployment:

baixo.

Technical debt:

sobe.

Security exposure:

sobe.

Obsolescência:

sobe.

Zero local.

Risco global maior.


🧠 Local Risk Optimization

Essa expressão é importante.

Você otimiza:

um risco específico.

Ignora:

sistema inteiro.

Exemplo:

OBJETIVO:
ZERO INCIDENTE DE DEPLOY

Solução:

não deployar.

Mas talvez negócio precise:

patch;

correção;

capacidade.

Risco migra.


🧠 Zero-Risk Bias + Status Quo Bias

Mudar:

risco visível.

Não mudar:

parece risco zero no momento.

Status Quo Bias diz:

continue.

Zero-Risk Bias diz:

assim eliminamos risco de mudança.

Mas o status quo possui:

risco próprio.


☕ O mainframe parado no tempo

“Não altere porque funciona.”

Cinco anos.

Patch não aplicado.

Skills caem.

Dependências envelhecem.

Agora o sistema que “não mudava” ficou:

mais arriscado.

A ausência de mudança nunca foi zero risco.


🧠 Omission Bias

Não agir parece menos causador.

Zero-Risk Bias pode reforçar:

“Se não tocarmos, não causamos incidente.”

Mas talvez não agir permita:

outro incidente.


🧠 Loss Aversion

Zero perda parece especialmente atraente.

Mesmo se outra opção oferece ganho esperado muito maior.

Perder absolutamente nada:

psicologicamente poderoso.

Loss Aversion + Zero-Risk Bias formam uma dupla conservadora fortíssima.


🧠 Framing Effect

Compare:

Frame A

“Esta solução elimina 100% deste risco.”

Frame B

“Esta solução reduz apenas 1 ponto percentual do risco total.”

Mesma intervenção.

Impacto emocional completamente diferente.

Framing pode explorar Zero-Risk Bias.


☕ Vendor slide

ELIMINATES 100% OF RISK X!

Ótimo marketing.

Pergunta Bellacosa:

“Quanto X representa do risco total?”

Talvez:

0,2%.

A frase continua verdadeira.

Mas relevância muda.


🎯 Pergunta Bellacosa nº 1

Quando alguém disser:

“Isso elimina totalmente o risco.”

Pergunte:

“Quanto esse risco representa do problema total?”

Excelente.


🧠 Absolute Risk Reduction

Essa ideia ajuda muito.

Imagine:

Risco A:

2% → 0%.

Redução absoluta:

2 pontos.

Risco B:

50% → 20%.

Redução absoluta:

30 pontos.

Se mesmo custo:

B geralmente merece forte atenção.

Zero não deveria esconder magnitude.


☕ Relative versus absolute

Fornecedor:

“Redução de 100%!”

Era:

0,1% → 0%.

Sim.

100% daquele risco.

Mas:

0,1 ponto percentual total.

Sempre pergunte:

“100% de quanto?”


🧠 Base Rate Neglect

Outro velho amigo.

Se evento é extremamente raro:

zerá-lo pode produzir benefício mínimo.

Enquanto risco comum permanece.

Zero-Risk Bias pode fazer taxa-base desaparecer.


🔐 Segurança: vulnerabilidade rara

Security encontra:

vulnerabilidade extremamente difícil de explorar.

Probabilidade baixa.

Patch custa:

muito.

Outro problema:

MFA ausente em milhares de contas.

Mesmo orçamento.

Qual priorizar?

Resposta:

depende de impacto e contexto.

Mas Zero-Risk Bias pode preferir:

“eliminar completamente CVE X”

porque fica bonito no relatório.

Enquanto risco amplo permanece.


🧠 Compliance influencia muito

Auditoria encontra:

um controle com status:

NON-COMPLIANT

Organização quer:

zero findings.

Então gasta recursos enormes para remover finding pequeno.

Enquanto riscos reais não auditados continuam.

Isso é:

audit optimization versus risk optimization.


☕ Zero finding

Audit dashboard:

0 OPEN FINDINGS

Linda tela.

Mas segurança não vive apenas no dashboard do auditor.


🧠 Zero-Risk Bias + Illusion of Control

Se zeramos uma categoria:

sentimos:

“Controlamos.”

Mas riscos complexos raramente desaparecem.

Eles:

mudam;

migram;

combinam.

A sensação de zero reforça Illusion of Control.


🧀 Swiss Cheese Model novamente

Eliminar um buraco de uma fatia:

ótimo.

Mas se outras quatro fatias possuem buracos enormes:

risco sistêmico continua.

Zero em um controle não é:

zero acidente.


🧠 Control Coverage

Exemplo:

MFA elimina grande parte do risco de senha roubada.

Excelente.

Mas não elimina:

session hijack;

insider;

malware;

application vulnerabilities.

Não diga:

“Account takeover risk = 0.”

Diga:

“Este failure mode foi fortemente reduzido.”

Linguagem mais madura.


☕ “Zero trust” também não significa zero risco

Só para evitar trocadilho perigoso.

Zero Trust é um modelo arquitetural específico.

Não promessa metafísica de risco zero.


🧠 Planning Fallacy e zero buffers

Outro curioso.

Gestor quer:

zero atraso.

Então plano não admite:

slack.

Tudo exatamente encaixado.

Uma dependência atrasa.

Sistema inteiro cai.

Buscar zero “tempo ocioso” pode eliminar:

margem.

Agora fragilidade aumenta.


🧠 Efficiency vs Resilience

Zero ociosidade.

Parece ótimo.

Mas capacidade livre pode ser:

reserva de resiliência.

CPU 100% ocupada sempre:

eficiente?

Talvez.

Quando pico chega:

sem margem.


☕ O sistema perfeito a 100%

CPU:

100%.

Storage:

100%.

Equipe:

100%.

Nenhuma folga.

Parabéns.

Construímos uma máquina muito eficiente para quebrar no próximo desvio.


🌀 Drift Into Failure

Pressão por eliminar desperdício:

reduz margem.

Cada pequena redução parece racional.

Até:

sistema sem buffer.

Zero-Risk Bias pode perseguir:

zero idle;

zero extra capacity;

zero redundancy.

Paradoxalmente:

aumenta risco de falha.


🧠 Redundancy looks inefficient

Duas máquinas para trabalho de uma.

“Desperdício.”

Até uma falhar.

Redundância é custo comprado para reduzir impacto.

Se perseguimos zero “recurso ocioso”:

matamos resiliência.


☕ Backup parece inútil todos os dias

Até o dia em que vira o sistema mais importante da empresa.


🧠 Zero defects

Em manufatura e qualidade, “zero defects” pode ser uma aspiração útil.

Mas como meta operacional rígida pode gerar:

underreporting;

medo;

ocultação.

Se qualquer erro é inaceitável:

pessoas podem deixar de reportar.

Agora dashboard:

zero defeitos.

Realidade:

defeitos invisíveis.


🧠 Goodhart's Law retorna

Meta:

zero incidentes.

Equipe aprende:

reclassificar incidentes.

Agora:

KPI perfeito.

Sistema igual.

Métrica virou objetivo.


☕ SEV-1 virou “degradação operacional”

Zero SEV-1.

Marketing interno excelente.

Clientes talvez discordem.


🧠 Zero-Risk Bias + Self-Serving Bias

Sucesso:

“Eliminamos o risco.”

Depois falha de outro tipo:

“Evento imprevisível.”

Self-Serving protege narrativa.


🧠 Narrative Bias

Uma história simples:

“Tínhamos problema X, eliminamos X, agora estamos seguros.”

Bonita.

Sistemas complexos:

menos cooperativos.

Talvez problema verdadeiro fosse:

conjunto de riscos.


🎯 Pergunta Bellacosa nº 2

“Qual risco aumentamos para conseguir zerar este?”

Uma das melhores perguntas do capítulo.


🧠 Risk Transfer

Às vezes não reduzimos risco.

Transferimos.

Exemplo:

security bloqueia tudo.

Security risk ↓.

Business interruption risk ↑.

Ou:

mais manual approval.

Unauthorized change risk ↓.

Delay risk ↑.

Faça mapa.


☕ Risco não desapareceu

Mudou de departamento.

Clássico corporativo.


🧠 Risk Portfolio

Pense como portfólio.

Temos:

security;

availability;

integrity;

cost;

delivery;

compliance.

O objetivo não é:

zerar um.

É:

otimizar risco total dentro de apetite aceitável.


🧠 Risk Appetite

Uma organização madura admite:

alguns riscos residuais.

Isso pode soar assustador.

Mas é realidade.

Zero risco possui:

custo infinito

ou:

atividade zero.


☕ A única aplicação com zero bug garantido

A que nunca foi escrita.

Talvez.

Mesmo assim requisito pode estar errado.


🧠 Residual Risk

Depois dos controles:

sobra risco.

Precisamos:

aceitar;

transferir;

mitigar;

evitar.

Mas conscientemente.

A palavra “residual” é uma vacina contra fantasia de zero.


🧠 Risk Matrix

Exemplo:

RISK A
P=1
I=1
SCORE=1

RISK B
P=4
I=5
SCORE=20

Se orçamento igual:

zerar A talvez seja emocionalmente atraente.

Mas B domina exposição.


☕ Pareto do risco

Talvez:

20% dos riscos

respondam por:

80% da exposição.

Zero-Risk Bias pode gastar recursos nos riscos pequenos que são fáceis de zerar.

Porque:

resultado fica visível.


🧠 Easy-to-Zero Trap

Esse é um fenômeno prático interessante.

Risco pequeno:

fácil de eliminar.

Risco grande:

difícil de reduzir.

Gestão prefere:

o fácil.

Dashboard ganha:

check verde.

Mas exposição quase não muda.


☕ Green-box optimization

Precisávamos reduzir risco.

Reduzimos:

número de quadrados vermelhos.

Não necessariamente:

risco.

Framing Effect em forma de dashboard.


🔐 Patch management

CVE pequena:

patch simples.

CVE crítica:

aplicação antiga difícil.

Equipe fecha:

20 pequenas.

Dashboard:

20 riscos eliminados.

Crítica permanece.

Count-based metrics podem incentivar Zero-Risk Bias.


🧠 Count ≠ Exposure

20 vulnerabilidades baixas

não necessariamente > 1 crítica.

Precisamos weighted risk.


📊 Weighted Risk Reduction

Em vez de medir:

RISKS CLOSED: 20

meça:

EXPOSURE REDUCED: X%

Muito melhor.


🧠 Zero-Risk Bias em incident response

Alguém propõe:

“Bloqueie completamente tráfego externo.”

Isso talvez zere ataque daquele vetor.

Mas:

serviço cai para todos.

Segurança conseguiu zero risco de entrada...

porque ninguém entra.

Às vezes correto em emergência.

Mas trade-off precisa ser explícito.


☕ Segurança máxima:

desligar computador.

Disponibilidade:

0%.

Sempre existe troca.


🧠 Fail Closed vs Fail Open

Security prefere muitas vezes:

fail closed.

Availability pode preferir:

fail open.

Nenhuma opção é zero risco.

Cada uma escolhe:

qual risco priorizar.

Engenharia é trade-off.


🧠 Zero-Risk Bias odeia trade-offs

Porque trade-off diz:

“Algo continuará imperfeito.”

O cérebro prefere:

uma dimensão perfeita.

Mesmo se o resto piorar.


👻 Easter Egg nº 2 — Cybermen perfeitos

Cyberman:

— ELIMINAMOS TODA EMOÇÃO.

Doctor:

— Por quê?

— EMOTION CAUSES PAIN.

— E também alegria.

Silêncio.

Eliminar completamente um problema pode eliminar:

coisas úteis junto.

Zero pode ser caro.


🧠 Zero false positives

Fraud system.

Meta:

zero falso positivo.

Então threshold relaxa.

Clientes legítimos nunca bloqueados.

Mas fraude passa.

Ou:

zero fraude.

Threshold agressivo.

Clientes legítimos bloqueados.

Impossível otimizar uma métrica sem trade-off.


🧠 Precision vs Recall

Excelente exemplo de ML.

Quer:

recall 100%.

Talvez aumente falso positivo.

Quer:

precision 100%.

Talvez perca casos reais.

Zero-Risk Bias pode perseguir extremo sem considerar custo.


🤖 IA

“Queremos zero hallucination.”

Objetivo desejável.

Mas dependendo da aplicação:

talvez sistema passe a responder:

“Não sei.”

para quase tudo.

Hallucinations ↓.

Utility ↓.

Precisamos:

calibração;

grounding;

abstention.

Não apenas zero num KPI isolado.


☕ IA absolutamente segura que não responde nada

Impressionante safety score.

Usuário um pouco decepcionado.


🧠 Automation Bias + zero error promises

Fornecedor diz:

“100% accurate.”

Desconfie.

Sistemas reais quase sempre possuem:

condições;

escopo;

dataset.

Zero é ótimo marketing.

Engenharia precisa perguntar:

denominador.


🎯 Pergunta Bellacosa nº 3

“Zero em qual população, período e condição?”

Muito importante.


🧠 Sample Size

Teste:

zero falhas em 10 casos.

Isso não prova:

zero risco.

Talvez apenas não vimos.

Survivorship Bias + small sample.


☕ Rodou três vezes

“100% confiável.”

Não.

“3/3 até agora.”

Outra linguagem.


🧠 Confidence Intervals

Mesmo sem matemática pesada:

zero eventos observados não significa probabilidade zero.

Se um evento é raro:

talvez amostra pequena não detecte.


🧠 Black Swan misuse

Risco raro não é zero.

Mas também não devemos gastar tudo tentando eliminar qualquer evento concebível.

Precisamos:

probabilidade × impacto × custo de controle.


☕ Existe risco de meteorito no data center

Provavelmente.

Orçamento para isso?

Depende.

Talvez antes arrumemos backup.


🧠 Risk Prioritization

Uma abordagem simples:

EXPOSURE ≈ PROBABILITY × IMPACT

Não perfeita.

Mas ajuda.

Depois considere:

velocity;

detectability;

irreversibility.

Muito melhor que:

“Consigo zerar este.”


🧠 Risk Reduction per Dollar

Outro conceito útil:

quanto risco reduzimos por real investido?

Exemplo:

A:

R$800k → redução 1 ponto.

B:

R$800k → redução 25 pontos.

B parece muito mais eficiente.


☕ ROIR

Return on Risk Reduction.

Não precisa virar sigla oficial.

Mas gosto.


🧠 Expected Loss

Simplificando:

EXPECTED LOSS =
PROBABILITY × IMPACT

Se risco:

1% × R$10k

versus:

40% × R$10M,

a diferença é brutal.

Zero-Risk Bias pode ignorar.


🧠 Tail Risk caution

Claro:

probabilidade baixa + impacto catastrófico

pode merecer controle forte.

Não use apenas probabilidade.

Exemplo:

perda de vida;

falência;

integridade.

Zero-Risk Bias não significa:

“ignore riscos raros.”

Significa:

não valorize o número zero independentemente da exposição total.


☕ Risco nuclear não vira irrelevante porque é raro

Contexto importa.


🧠 Irreversibility

Um risco de 0,1% com consequência irreversível enorme pode merecer quase zero tolerance.

Então precisamos:

impacto.

Not just probability.


🧠 Risk Tolerance

Algumas categorias podem ter:

tolerância zero.

Exemplo:

violação intencional de determinado controle.

Mas isso é:

decisão normativa.

Não viés.

Zero-Risk Bias aparece quando o “zero” é escolhido emocionalmente sem análise comparativa.


☕ Zero tolerance não é automaticamente Zero-Risk Bias

Boa distinção.

Política pode escolher:

zero tolerance

por razões legais, éticas ou de segurança.

O viés é:

sobre preferência desproporcional pelo zero.


🧠 Need for Control + Zero-Risk Bias em governança

Depois de incidente:

“Isso nunca mais pode acontecer.”

Compreensível.

Mas:

literalmente nunca?

Talvez custe:

infinito.

Melhor:

“Como reduzimos probabilidade e impacto a um nível aceitável?”

Menos dramático.

Muito mais engenheiro.


🧠 “Never Again” problem

Incidentes graves geram:

regras específicas para impedir repetição exata.

Excelente.

Mas próximo incidente pode ser diferente.

Recency Bias + Zero-Risk Bias:

preparamos sistema perfeitamente contra último caso.


☕ Fighting the last war

Agora com meta:

zero repetição.

Mas risco novo aparece.


🧠 Control Portfolio novamente

Em vez de:

“zero incidente X”,

pergunte:

“qual conjunto de controles reduz mais exposição total?”

Swiss Cheese.


🧠 Defense in Depth

Não zera uma camada.

Distribui defesa.

Talvez cada controle tenha falha residual.

Juntos:

risco muito menor.

Zero-Risk Bias pode preferir gastar tudo tornando uma camada perfeita.

Isso é ruim.


☕ Melhor cinco barreiras boas que uma barreira “perfeita” e quatro ausentes

Quase o Swiss Cheese escrevendo orçamento.


🧠 Zero-Risk Bias em staffing

Gestor quer:

zero erro júnior.

Solução:

júnior não toca produção.

Agora nunca aprende.

Bus factor aumenta.

Future staffing risk ↑.

Risco presente ↓.

Risco futuro ↑.


🧠 Training Environment

Melhor:

sandbox;

pairing;

review;

progressive access.

Aceite pequenos riscos controlados para reduzir risco maior futuro.


☕ Aprendizado também precisa de error budget

Bonita ideia.


🧠 Zero mistakes culture

Se ninguém pode errar:

ninguém experimenta.

Innovation ↓.

Reporting ↓.

Psychological safety ↓.

O objetivo deve ser:

erros detectáveis;

reversíveis;

com blast radius limitado.


🧠 Blameless culture

Não busca:

zero erro humano.

Busca:

sistemas tolerantes a erro.

Porque zero erro humano é fantasia.


☕ Poka-Yoke

Torne alguns erros impossíveis.

Excelente.

Mas não tente eliminar:

todo possível erro cognitivo.

Projete para:

tolerância.


🧠 Zero-Risk Bias + Dunning-Kruger

Pessoa conhece pouco risco total.

Enxerga um risco simples.

Consegue zerar.

Fica confiante.

Mas desconhece:

efeitos colaterais.

Mais um motivo para review multidisciplinar.


👥 Cross-functional risk review

Security vê:

security.

Ops vê:

availability.

Business vê:

revenue.

Juntos:

trade-offs ficam visíveis.

Sem isso:

cada silo tenta zerar seu risco.

Sistema inteiro sofre.


☕ Cada departamento quer zero no próprio dashboard

Mas o cliente usa o sistema inteiro.

Perfeito.


🧠 Silo Optimization

Security:

zero abertura.

Ops:

zero downtime.

Finance:

zero custo extra.

Dev:

zero atraso.

Impossível simultaneamente.

Governança precisa decidir trade-offs.


🎯 Pergunta Bellacosa nº 4

“Estamos minimizando risco global ou apenas limpando o dashboard da nossa equipe?”

Essa é excelente.


🧠 Zero-Risk Bias e change freezes

Freeze total:

risco de mudança ↓.

Mas:

security fixes atrasam.

Capacity fixes atrasam.

Defects permanecem.

Freeze pode ser correto em períodos críticos.

Mas precisa:

escopo;

duração;

exceção.

Não absoluto permanente.


☕ Congelar é uma ferramenta

Não uma religião.


🧠 Temporary zero-risk control

Às vezes buscamos zero temporariamente.

Exemplo:

durante incidente:

bloquear feature.

Isso pode ser ótimo.

Porque prioridade é:

containment.

A diferença:

tempo limitado.

Depois:

reavaliar.


🧠 Time Horizon

Trade-off depende de tempo.

Zero risk hoje

pode criar:

risco amanhã.

Present Bias entra.


🧠 Present Bias + Zero-Risk Bias

Evitar risco agora parece ótimo.

Custo futuro:

menos visível.

Exemplo:

não patchar hoje para zero deployment risk.

Security risk cresce.

Clássico.


☕ “Não toque antes do fechamento”

Ok.

Depois do fechamento?

Se vira:

“não toque nunca”,

temos problema.


🧠 Risk Debt

Podemos pensar em:

dívida de risco.

Ao evitar mudança arriscada agora:

acumulamos risco futuro.

Technical debt é exemplo.


🧠 Risk Budget

Organização pode pensar:

quanto risco aceitamos em:

mudança;

security;

availability.

Distribua.

Não tente zero universal.


📊 Error Budgets novamente

SRE traz excelente filosofia.

Não buscamos:

100% disponibilidade infinita

a qualquer custo.

Porque:

custo explode;

inovação para.

Definimos SLO.

Error budget.

Isso é praticamente:

antídoto institucional ao Zero-Risk Bias.


☕ 100% uptime é muito caro

E às vezes impossível.

99.99 pode ser perfeito para o negócio.

Contexto.


🧠 Availability Mathematics

Cada nove adicional custa.

Arquitetura.

Redundância.

Complexidade.

Pergunta:

cliente precisa?

Se não:

zero downtime pode ser investimento irracional.


🧠 Complexity Risk

Mais redundância pode introduzir:

complexidade.

Failover bugs.

Operational overhead.

Tentamos reduzir availability risk.

Podemos aumentar complexity risk.

Trade-off.


☕ HA mal testada é duas vezes mais coisa para quebrar

Às vezes.


🧠 Zero-Risk Bias + Control Complexity

Tenta eliminar cada failure mode.

Adiciona:

mais componentes.

Cada componente traz:

novos failure modes.

Ironia sistêmica.


🌀 Complexity spiral

RISK
↓
CONTROL
↓
COMPLEXITY
↓
NEW RISKS
↓
MORE CONTROLS

Need for Control manda lembranças.


🧠 Minimal sufficient control

Uma boa meta:

controle suficiente para reduzir risco a nível aceitável.

Não:

controle máximo.


☕ Suficientemente seguro

Pode soar menos heroico.

É engenharia.


🧠 Zero-Risk Bias em testes

Queremos:

100% code coverage.

Talvez.

Mas 100% coverage não significa:

100% qualidade.

Você pode gastar enorme esforço cobrindo linhas triviais...

e deixar cenários críticos mal testados.


💻 COBOL exemplo

Programa:

1.000 linhas.

Coverage:

100%.

Mas ninguém testou:

restart após commit parcial.

Métrica perfeita.

Risco crítico aberto.


🧠 Metric fixation

Zero-Risk Bias pode combinar com métricas binárias:

pass/fail.

covered/not covered.

compliant/non-compliant.

Reality:

gradações.


☕ Green != Safe

Já apareceu antes.

Continua verdadeiro.


🧠 Zero vulnerability count

Security report:

zero vulns críticas.

Ótimo.

Mas:

configuração?

IAM?

secrets?

insider?

Risco não cabe numa coluna.


🧠 Risk Taxonomy

Use categorias.

Não permita uma métrica dominar.


🧠 Portfolio Heatmap

Exemplo:

SECURITY     HIGH
AVAILABILITY MEDIUM
INTEGRITY    HIGH
DELIVERY     LOW
COMPLIANCE   LOW

Agora decisão considera conjunto.


🎯 Pergunta Bellacosa nº 5

“Se gastarmos todo o orçamento para zerar este risco, qual risco importante ficará sem tratamento?”

Poderosa.


🧪 Como combater Zero-Risk Bias

Passo 1 — Liste todos os riscos relevantes

Não apenas o mais visível.


Passo 2 — Quantifique exposição

Probabilidade.

Impacto.


Passo 3 — Compare redução absoluta

Antes → depois.


Passo 4 — Considere custo

Dinheiro.

Tempo.

Complexidade.


Passo 5 — Procure risk transfer

O que aumenta?


Passo 6 — Considere risco residual

Não esconda.


Passo 7 — Priorize exposição total

Não quantidade de zeros.


Passo 8 — Use time horizon

Hoje e futuro.


Passo 9 — Defina risk appetite

O que é aceitável?


Passo 10 — Reavalie após mudança

O portfólio melhorou?


📋 Checklist anti-Zero-Risk Bias

[ ] Estamos atraídos pela palavra “zero”?

[ ] Quanto esse risco representa do total?

[ ] Qual é a redução absoluta?

[ ] Outra opção reduz mais exposição?

[ ] Quanto custa chegar a zero?

[ ] Qual risco aumenta como efeito colateral?

[ ] Estamos transferindo risco para outro time?

[ ] O residual é realmente inaceitável?

[ ] Existe requisito legal ou ético de tolerância zero?

[ ] Estamos otimizando uma métrica isolada?

[ ] O dashboard verde representa risco real menor?

[ ] O zero foi obtido reduzindo atividade?

[ ] O controle adiciona complexidade?

[ ] Qual é o custo de oportunidade?

[ ] Qual risco importante ficará sem orçamento?

🧠 Pareto primeiro, zero depois

Antes de eliminar riscos pequenos:

ataque os grandes.

Pareto.

Talvez reduzir os top 3 riscos em 50% produza muito mais valor que zerar 20 riscos minúsculos.


☕ O dashboard fica menos bonito

Mas produção mais segura.

Escolha difícil.


🧠 Risk Reduction Curve

Frequentemente primeiros investimentos reduzem muito risco.

Últimos pontos até zero custam enorme.

RISK
100 ┐
    │\
    │ \
    │  \
    │   \____
    │        \____ 0
    └──────────── COST

Chegar de:

100 → 20

pode ser barato.

20 → 0

caríssimo.

Pergunta:

vale?

Depende.


🧠 Diminishing Returns

Mais controle.

Menos ganho marginal.

Zero-Risk Bias ignora diminishing returns porque:

zero possui valor emocional extra.


☕ O último 1% pode custar mais que os primeiros 99%

Clássico.


🧠 ALARP

Em gestão de risco existe ideia de reduzir riscos a níveis tão baixos quanto razoavelmente praticável em determinados contextos.

Sem entrar em regulação específica, o espírito é útil:

reduzir muito, mas considerando proporcionalidade.

Nem sempre zero.


🧠 Reasonably Practicable

Essa expressão obriga equilíbrio:

benefício;

custo;

viabilidade.

Engenharia real.


☕ “Porque zero é melhor” não é análise de risco

É preferência.


🧠 Zero-Risk Bias em DR

Queremos:

zero data loss.

RPO = 0.

Excelente.

Mas custa:

replicação síncrona;

latência;

complexidade.

O negócio realmente precisa?

Para pagamentos:

talvez.

Para analytics:

talvez não.

Mesma meta para tudo:

irracional.


💾 RPO/RTO risk-based

Tier 1:

RPO ~ 0.

Tier 3:

RPO 24h.

Isso é maturidade.

Não tratar todo workload como missão lunar.


☕ Nem todo arquivo precisa sobreviver ao apocalipse em tempo real

Alguns podem esperar o restore.


🧠 Data Integrity exceptions

Mas em contabilidade financeira:

alguns riscos podem ser intoleráveis.

Ótimo.

A resposta não é:

“zero sempre ruim.”

É:

zero precisa ser justificado pela criticidade, não desejado automaticamente.


🧠 Asymmetric Loss

Se um evento raro pode:

matar pessoas;

quebrar banco;

violar lei,

seu impacto domina.

Zero ou quase zero pode fazer sentido.

Não simplifique.


🧠 Bias != wrong decision

Importantíssimo para toda a série.

Uma decisão que zera risco pode ser correta.

Zero-Risk Bias é:

o mecanismo psicológico que pode nos fazer preferi-la pelas razões erradas.

Sempre separe:

resultado

de:

processo decisório.

Outcome Bias já ensinou.


☕ Pode chegar na decisão certa por raciocínio ruim

E na errada por raciocínio razoável.

Analise processo.


🧠 Decision Table

OPTION A
Risk reduction: 1
Cost: 10
Residual: 0

OPTION B
Risk reduction: 25
Cost: 10
Residual: 15

Agora escolha conscientemente.

Talvez A tenha requisito regulatório.

Se não:

B parece mais forte.


🧠 Multi-Criteria Decision

Inclua:

probability;

impact;

cost;

reversibility;

compliance;

reputation.

Não apenas:

zero.


🧠 Zero-Risk Bias e executive reporting

Executivos gostam:

“100% compliant.”

“Zero incidents.”

“Zero critical vulnerabilities.”

São números fáceis.

Mas podem incentivar manipulação.

Melhor:

exposição;

trend;

residual risk.


☕ “Zero” cabe melhor no slide

“Risco residual ajustado caiu 43%” é menos sexy.

Mas talvez mais verdadeiro.


🧠 Leading indicators

Zero incidentes neste mês.

Ótimo.

Mas:

near misses ↑.

Capacity margin ↓.

Manual interventions ↑.

Zero lagging indicator pode esconder tendência.

Drift Into Failure.


🧠 Near Misses matter

Se apenas contamos incidentes:

zero.

Mas dez near misses:

risco alto.

A sorte ainda está trabalhando.


☕ Zero acidentes não significa zero perigo

Talvez só zero materialização.


🧠 Insurance analogy

Você não tenta eliminar:

todo risco de incêndio.

Reduz:

probabilidade;

impacto.

Transfere parte:

seguro.

Isso mostra:

risk management ≠ risk annihilation.


🧠 Diversification

Em finanças:

não zera cada risco.

Distribui.

Mais uma metáfora útil.


☕ Mainframe risk portfolio

Backup.

DR.

Security.

Capacity.

Change.

Skills.

Não precisa zero em tudo.

Precisa equilíbrio.


🧠 Skills risk

Você poderia buscar:

zero risco de erro de júnior

não deixando júnior tocar.

Mas daqui a 5 anos:

zero sênior novo.

Skills risk enorme.

A solução:

mentoria.

Gradual responsibility.

Guardrails.


🧠 Open Mainframe logic

Conhecimento precisa circular.

Aceite pequenos riscos controlados para reduzir risco sistêmico de conhecimento concentrado.


🎯 Pergunta Bellacosa nº 6

“Estamos comprando zero risco hoje ao custo de criar um risco maior amanhã?”

Essa merece destaque.


🧠 Security patch example

Não aplicar patch:

zero deployment risk hoje.

Exploit risk futuro ↑.

Aplicar:

algum deployment risk.

Security risk ↓.

Trade-off.

Zero-Risk Bias pode travar.


🧠 Canary as compromise

Deploy em:

5%.

Agora não precisamos escolher:

zero mudança

ou:

100% mudança.

Reduzimos blast radius.

Excelente antídoto.


☕ Entre zero e tudo existe engenharia

Talvez a frase do capítulo.


🧠 Feature flags

Mesmo raciocínio.

Gradual exposure.

Test.

Measure.

Não busque binário.


🧠 Progressive Delivery

Contrapõe mentalidade:

all-or-nothing.

Zero-Risk Bias gosta de binário.

Engenharia moderna gosta de:

gradiente.


IF humano demais

IF RISK = ZERO
   ACCEPT
ELSE
   REJECT
END-IF

Pouco sofisticado.

Talvez:

EVALUATE TRUE
  WHEN RISK <= ACCEPTABLE
     CONTINUE
  WHEN RISK > ACCEPTABLE
     MITIGATE
END-EVALUATE

Melhor.


🧠 COBOL tem EVALUATE

Talvez psicologia de risco também precise.


🧠 Decision thresholds

Defina:

risk tolerance.

Acima:

mitigue.

Abaixo:

aceite.

Isso impede zero virar default.


🧠 Error Budget e Zero-Risk Bias

Volta porque é excelente.

Error budget literalmente diz:

algum erro é aceitável dentro de limites.

Isso pode parecer heresia para cultura “zero falhas”.

Mas permite:

inovação;

mudança;

aprendizado.


☕ Zero error budget também significa zero coragem

Talvez exagero.

Mas boa provocação.


🧠 Psychological Safety

Se meta é:

zero erro,

pessoas escondem.

Se meta é:

erro detectado cedo e tratado,

pessoas reportam.

Zero-Risk Bias também pode prejudicar cultura.


🧠 Fundamental Attribution Error

Meta zero.

Erro acontece.

Como zero era “obrigatório”:

alguém precisa ser culpado.

Agora erro sistêmico vira falha pessoal.

Outro capítulo conectado.


🧠 Self-Serving Bias

Gestão define zero impossível.

Equipe falha.

Gestão:

“Execução.”

Confortável.


☕ Zero impossível é uma meta ótima para culpar alguém

Porque sempre haverá falha.


🧠 Realistic SLOs

Uma boa meta:

desafiadora;

mensurável;

alinhada ao negócio.

Não moral.


🧠 Risk Communication

Explique:

“Não conseguimos eliminar completamente, mas reduzimos exposição em 70%.”

Isso é sucesso.

Cultura precisa aprender a celebrar:

redução.

Não apenas:

zero.


☕ “Ainda existe 5%.”

Sim.

Antes eram 40%.

Excelente trabalho.

Não deixe o zero roubar isso.


🧠 Risk Burn-down

Mostre:

40 → 30 → 20 → 10 → 5

Isso cria percepção de progresso sem exigir zero imediato.


🧠 Residual Risk Ownership

Quem aceita os 5%?

Business owner.

Risk owner.

Não esconda.

Aceitação consciente.


🧠 Governance madura

Risco residual documentado:

RESIDUAL RISK:
5%

OWNER:
Service Owner

RATIONALE:
Further reduction disproportionate to cost

Isso é controle adulto.


☕ “Aceitar risco” não significa “ignorar risco”

Outro ponto crucial.

É decisão consciente.


🧠 Zero-Risk Bias e incident prevention

Depois de incidente raro:

gestão:

“Nunca mais.”

Cria controle enorme.

Talvez reduza aquele cenário de:

0,5% → 0%.

Mas impede patch rápido e aumenta outro risco.

Faça análise de impacto do controle.


🧠 Post-Incident Control Review

Pergunte:

  • qual risco reduz?

  • quanto?

  • que risco cria?

  • custo?

  • duração?

Isso evita reação emocional.


🎯 Pergunta Bellacosa nº 7

“Estamos reduzindo risco ou apenas garantindo que este incidente específico nunca se repita exatamente igual?”

Excelente conexão com Recency Bias.


🧠 Generalize failure class

Não apenas:

“nunca mais aquele comando.”

Mas:

“como evitar qualquer comando destrutivo sem validação?”

Classe maior.

Melhor retorno.


🧠 Zero Specific Risk vs Broad Reduction

Zerar caso específico.

Ou:

reduzir vários casos.

Quase sempre compare.


📋 Bellacosa Risk Decision Card

RISK:
_________________

CURRENT EXPOSURE:
_________________

OPTION A:
Residual:
Cost:
New risks:

OPTION B:
Residual:
Cost:
New risks:

TOTAL RISK REDUCTION:
_________________

Simples.

Útil.


🧠 Stop chasing zeros blindly

Não significa:

aceite qualquer coisa.

Significa:

pergunte:

“Qual uso do próximo real, da próxima hora e da próxima barreira reduz mais risco importante?”

Essa é a pergunta econômica.


🧬 Regeneração organizacional

Uma organização madura contra Zero-Risk Bias aprende a:

medir exposição total;

comparar redução absoluta;

considerar impacto;

analisar custo;

mapear risk transfer;

aceitar residual risk;

usar SLOs e error budgets;

segmentar workloads por criticidade;

evitar métricas binárias como única verdade;

e revisar controles pelo efeito global.

Principalmente:

ela aprende a dizer:

“Zero é excelente quando é necessário e proporcional. Fora disso, zero é apenas um número — e às vezes um número caríssimo.”


📓 Diário do Doctor

Se guardar algumas ideias desta viagem, guarde estas:

Zero-Risk Bias é a tendência de preferir eliminar completamente um risco menor em vez de reduzir muito mais um risco maior.

Zero possui valor psicológico especial, mas não necessariamente valor econômico proporcional.

Compare redução absoluta, não apenas percentual relativo.

Pergunte “100% de quanto?”.

Um risco pode ser zerado transferindo risco para outra categoria.

Need for Control e Loss Aversion tornam o zero especialmente sedutor.

Status Quo Bias pode tratar não mudar como risco zero, mesmo quando a inação acumula risco.

Métricas de zero podem incentivar Goodhart e ocultação.

Error budgets e SLOs são formas maduras de aceitar risco residual conscientemente.

Riscos raros e catastróficos ainda podem justificar controles extremos; Zero-Risk Bias não significa ignorar tail risk.

Governança deve otimizar exposição total, não quantidade de quadrados verdes.

E principalmente:

A meta de gestão de risco não é colecionar zeros. É usar recursos limitados para impedir o maior dano provável e construir resiliência para aquilo que continuará inevitavelmente acima de zero.


🕰️ De volta à sala das 09:08

Risco A:

1% → 0%

Risco B:

40% → 15%

Mesmo custo.

O gerente diz:

— Ainda gosto do zero.

Nosso jovem sorri.

— Eu também.

— Então?

— Mas gosto mais de evitar 25 problemas do que um.

O Doctor aponta:

— Excelente frase.

A equipe decide tratar B.

Depois encontra controle barato adicional para A.

Risco final:

A:
1% → 0.4%

B:
40% → 15%

Não zeraram tudo.

Mas reduziram risco total brutalmente.

O dashboard continua com números diferentes de zero.

Produção continua muito mais segura.


🔧 Um mês depois

Outro debate.

Security:

— Queremos zero vulnerabilidades abertas de baixa severidade.

Operations:

— Isso exigiria janela de manutenção em 300 servidores.

Nosso jovem pergunta:

— E vulnerabilidades críticas?

— Temos seis.

— Então por que começamos pelas pequenas?

— Porque conseguimos zerar a fila.

Silêncio.

A TARDIS provavelmente materializaria nesse instante.

Em vez disso, alguém abre Pareto.

Prioridade muda.

Críticas primeiro.

Dashboard não fica imediatamente perfeito.

Risco cai muito mais.


🥚 Easter Egg final

Na manhã seguinte aparece:

BELLACOSA.BIAS(ZERO-RISK)

Dentro:

       IF RISK-AFTER = ZERO
           PERFORM CHECK-TOTAL-RISK
       END-IF.

       IF OPTION-A-REDUCES = 1
          AND OPTION-B-REDUCES = 25
           PERFORM ASK-WHY-WE-LIKE-ZERO
       END-IF.

       IF CONTROL-REMOVES-ONE-RISK
           PERFORM CHECK-NEW-RISKS
       END-IF.

Comentário:

* ZERO IS A NUMBER.
* NOT A MAGIC SPELL.

Outro:

* 100 PERCENT
* OF A TINY RISK
* CAN STILL BE TINY.

Mais um:

* REDUCE EXPOSURE.
* NOT JUST RED BOXES.

Outro:

* RESIDUAL RISK
* IS NOT FAILURE.

E naturalmente:

* DALEKS PREFER ZERO HUMANS.
* THIS IS NOT A BALANCED
* RISK STRATEGY.

Nosso jovem fecha o membro.

Pouco depois alguém diz:

— Esta solução não elimina o risco totalmente.

Ele pergunta:

— Quanto elimina?

— Cerca de 80%.

— E a alternativa?

— 100%.

— Custo?

— Dez vezes maior.

— Impacto do risco residual?

— Pequeno.

Ele pensa.

Antigamente talvez tivesse dito:

“Então vamos no zero.”

Agora pergunta:

— O que fazemos com os outros nove décimos do orçamento?

Silêncio.

A pergunta muda a sala.

Porque risco não vive sozinho.

Orçamento também não.

VWORP.

VWORP.

VWORP.

A TARDIS desaparece.

No quadro da War Room fica uma última frase:

Zero pode ser a escolha certa. Mas quando o zero se torna mais importante que a redução real de dano, deixamos de fazer gestão de risco e começamos a fazer coleção de números confortáveis.

☕🌀

Next stop: Risk Compensation / Peltzman Effect — quando uma nova proteção nos faz sentir tão seguros que começamos a assumir mais risco, devolvendo parte do benefício que o controle deveria ter criado.

📘 CICS Command Level para padawans

 

Aprenda CICS com Bellacosa Mainframe

📘 CICS Command Level para padawans

Walkthrough estilo Bellacosa Mainframe

CICS e suas interligações


O IBM CICS (Customer Information Control System) é, em termos honestos de CPD, o coração online do mainframe. Se o batch é o pulmão que trabalha à noite, o CICS é o sistema nervoso que reage em milissegundos enquanto o banco, a seguradora ou o governo estão abertos.

Tecnicamente, CICS é um gerenciador de transações que roda sobre o z/OS e controla milhares (às vezes milhões) de requisições simultâneas vindas de terminais 3270, aplicações web, APIs, filas e sistemas distribuídos. Cada requisição vira uma TASK, criada, suspensa, retomada e finalizada pelo CICS com uma eficiência quase antipática. Nada de criar processo novo, nada de desperdício: tudo reaproveitado, tudo controlado.

No mundo real, CICS é quem garante que duas pessoas não atualizem o mesmo saldo ao mesmo tempo, que uma queda de energia não corrompa dados e que o sistema continue respirando mesmo sob carga absurda. Ele faz isso com controle de concorrência, integridade transacional (UOW), recuperação automática e isolamento de falhas.

No estilo Bellacosa: CICS não é framework, não é servidorzinho e não é opcional. É um ecossistema maduro, conservador e extremamente confiável. Se ainda está rodando 40 anos depois, não é nostalgia — é engenharia bem-feita.



🔹 MÓDULO I – Conceitos Básicos

IBM CICS

Vamos ao CICS em funcionamento, versão Bellacosa Mainframe – sem romantizar, mas com respeito.

Tudo começa quando o usuário digita uma transação (ex: ABCD) no terminal 3270 ou quando um sistema chama o CICS via API. Nesse momento, o CICS não executa um programa — ele cria uma TASK. Essa TASK é uma entidade leve, controlada, numerada e com prazo de vida curto. Nada de processo pesado, nada de desperdício.

A TASK entra no dispatcher do CICS, que decide quando ela pode rodar. Se precisar de I/O (VSAM, DB2, fila, terminal), a TASK é suspensa educadamente e outra entra no lugar. Multitarefa cooperativa raiz, funcionando há décadas.

Quando o programa COBOL é chamado, ele roda em modo quasi-reentrant, usando áreas compartilhadas e dados isolados por WORKING-STORAGE ou COMMAREA. Cada comando EXEC CICS passa pelo Command Level Interface, que valida, executa e devolve RESP codes. Se algo der errado, o CICS sabe exatamente onde, quando e por quê.

Se houver atualização, o CICS controla a Unit of Work. Se a TASK termina bem, ele faz commit. Se cair, ele desfaz tudo como se nada tivesse acontecido.

No fim, o CICS devolve a resposta ao usuário, mata a TASK sem cerimônia e segue em frente. Rápido, previsível e implacavelmente confiável.

📌 O que é

Introduz o CICS (Customer Information Control System) como gerenciador transacional online, explicando o conceito de TASK, transação, domains, memória e execução concorrente.

🧠 Resumo rápido

CICS não é programa, é um sistema operacionalzinho dentro do z/OS para aplicações online. Ele cria, controla, pausa, retoma e mata tarefas sem dó.

🧪 Exemplo

Uma transação ABCD digitada no terminal cria uma TASK, que executa um programa COBOL, acessa VSAM e responde em milissegundos.

⚠️ Dica Bellacosa

Se você não entende TASK ≠ JOB, você vai sofrer no CICS.

🥚 Easter Egg

QR (Quasi-Reentrant) não é moda antiga — é o motivo pelo qual mil usuários podem usar o mesmo programa sem corrupção de dados.

🤫 Fofoquice

Todo iniciante acha que cada usuário tem “seu programa na memória”. Não tem. É tudo compartilhado. O CICS é mão de vaca por design.


🔹 MÓDULO II – Básico de Programação CICS

CICS COBOL Estrutura basica de um programa

No modo programação em COBOL, o CICS muda completamente a forma de pensar do programador — e é aí que muita gente tropeça. Em CICS, você não escreve um programa que roda do início ao fim; você escreve respostas a eventos controladas pelo gerenciador transacional.

O programa COBOL é carregado uma vez na memória e compartilhado por centenas ou milhares de usuários. Por isso ele precisa ser quasi-reentrant: nada de variáveis globais inocentes, nada de estado permanente sem controle. Cada execução acontece dentro de uma TASK, criada pelo CICS quando uma transação é disparada ou um programa é chamado via LINK, XCTL ou START.

Toda interação com o mundo externo é feita por comandos EXEC CICS. Não existe READ direto, não existe WRITE direto, não existe DISPLAY. Tudo passa pela API do CICS: READ FILE, SEND MAP, RECEIVE MAP, WRITEQ, LINK. Cada comando retorna códigos RESP e RESP2, e ignorar isso é pedir ABEND.

O fluxo é quase sempre pseudo-conversacional: o programa recebe dados, processa, grava se necessário, envia a tela e termina. No próximo ENTER, o CICS cria outra TASK e chama o programa de novo, passando o estado mínimo via COMMAREA ou Channel/Container.

No estilo Bellacosa: programar CICS em COBOL é aceitar que o controle não é seu. E justamente por isso funciona.

📌 O que é

Ensina como escrever programas CICS em COBOL, comandos EXEC CICS, EIB, SEND/RECEIVE, pseudo-conversação e NEWCOPY.

🧠 Resumo rápido

Programar CICS é pensar em eventos, não em fluxo contínuo. Cada ENTER é um novo começo.

🧪 Exemplo

EXEC CICS SEND MAP('TELA01') MAPSET('MAP01') END-EXEC

⚠️ Dica Bellacosa

Se você usar STOP RUN em CICS, o sistema vai te julgar silenciosamente.

🥚 Easter Egg

O EIB é o “log secreto” da task. Tudo o que deu errado (ou certo) está lá.

🤫 Fofoquice

Conversacional “raiz” funciona… até o dia que 300 usuários derrubam a região.


🔹 MÓDULO III – BMS (Basic Mapping Support)

Tela BMS CICS processo de compilação

Quando falamos de CICS + BMS + terminal 3270, estamos falando da engenharia raiz da interface homem-máquina no mainframe, sem JavaScript, sem frescura e com latência ridiculamente baixa.

A BMS (Basic Mapping Support) é a camada que define a tela 3270. Ela não desenha pixels; ela define campos: posição, tamanho, proteção, intensidade, cor, se aceita teclado ou não. Tudo isso vira um mapa físico que o terminal entende e um mapa lógico que o programa COBOL usa. É separação de responsabilidades antes de isso virar moda.

No funcionamento real, o programa CICS envia a tela usando EXEC CICS SEND MAP. O CICS converte o mapa BMS em um buffer 3270 e manda para o terminal. O usuário digita, pressiona ENTER, e o terminal não executa nada — ele apenas devolve o buffer de campos alterados. Simples e eficiente.

Quando o programa faz EXEC CICS RECEIVE MAP, o CICS interpreta o buffer recebido, preenche as áreas correspondentes no copybook do mapa e informa qual tecla foi pressionada via DFHAID. Nenhum campo inválido passa despercebido se você souber testar o byte de atributo.

No estilo Bellacosa: BMS não é feio, é honesto. Ele entrega exatamente o que promete: controle total, previsibilidade absoluta e zero surpresas em produção.

📌 O que é

BMS define telas 3270: layout, campos, atributos, cores, proteção, cursor.

🧠 Resumo rápido

BMS é HTML dos anos 70, só que mais rápido e sem frescura.

🧪 Exemplo

Campo protegido + numérico:

DFHMDF POS=(5,10),LENGTH=10,ATTRB=(PROT,NUM)

⚠️ Dica Bellacosa

Tela feia é culpa do programador, não do CICS.

🥚 Easter Egg

O byte de atributo é onde mora a magia: cor, intensidade, proteção e cursor.

🤫 Fofoquice

Todo mundo copia DFHBMSCA sem saber metade do que ele tem.


🔹 MÓDULO IV – Ferramentas de Apoio

Comandos de linha CICS

No CICS em linha de comando, você abandona o conforto do código e entra no território onde o sistema se revela. Ferramentas como CEDF, CEDX, CECI, CEMT, CESN, CECS e CMAC não são opcionais — são o kit de sobrevivência de quem resolve problema de verdade.

O CEDF é o debugger raiz. Ele intercepta cada EXEC CICS, mostra argumentos, RESP codes, EIB, working-storage e permite alterar valores em tempo real. O CEDX é a versão estendida: mais detalhes, mais poder, mais chance de fazer besteira se não souber o que está fazendo. Debug sem recompilar, do jeito que só mainframe permite.

O CECI é o intérprete de comandos CICS. Serve para testar READ, WRITE, SEND MAP e tudo mais sem escrever uma linha de COBOL. Ideal para provar que o erro não é do arquivo, é do programa. Já o CECS valida sintaxe de comandos CICS — evita erro bobo que vira ABEND caro.

O CEMT é o painel de controle do CICS: status de tasks, arquivos, programas, filas, conexões. Quem domina CEMT entende a região. O CESN cuida de segurança: sign-on, sign-off e identidade do usuário. E o CMAC é a enciclopédia de abends e mensagens — onde você descobre que o erro já aconteceu antes, só não com você.

Estilo Bellacosa: essas transações não são ferramentas — são raio-X do sistema vivo.

📌 O que é

CEDF, CEDX, CECI, CECS e CMAC — o kit sobrevivência do programador CICS.

🧠 Resumo rápido

CEDF é o debugger raiz: feio, poderoso e perigoso.

🧪 Exemplo

Usar CECI para testar um READ VSAM sem escrever código.

⚠️ Dica Bellacosa

Nunca use CEDF em produção sem autorização. O sysprog sente.

🥚 Easter Egg

CEDF permite forçar ABEND. Sim, oficialmente.

🤫 Fofoquice

CEDF + 2 terminais é coisa de veterano que não confia em ninguém.


🔹 MÓDULO V – Acessando Arquivos

CICS acessando Dataset VSAM

Quando o CICS acessa um dataset VSAM, não existe improviso — existe controle fino, concorrência disciplinada e medo saudável de corromper dados. Diferente do batch, aqui tudo acontece online, em milissegundos, com dezenas ou milhares de usuários disputando o mesmo arquivo.

Antes de qualquer coisa, o VSAM é definido ao CICS como um recurso: nome lógico, tipo (KSDS, ESDS ou RRDS), modo de acesso e regras de compartilhamento. O programa COBOL nunca acessa o VSAM direto; ele pede educadamente via EXEC CICS READ, WRITE, REWRITE ou DELETE. Quem decide se pode ou não é o CICS.

No acesso direto, o programa fornece a chave (RIDFLD) e o CICS localiza o registro. Se for só leitura, tudo bem. Se for atualização, entra o jogo sério: lock de registro. O CICS garante que só uma TASK mexa naquele dado por vez. Se outra tentar, ela espera — ou recebe exceção.

No acesso sequencial (browse), o CICS cria um cursor lógico com STARTBR e entrega registro por registro via READNEXT. Tudo controlado, tudo rastreável. Se a TASK cair no meio, o CICS sabe exatamente onde estava.

Estilo Bellacosa: VSAM no CICS não é arquivo — é recurso crítico. Trate como tal, ou o sistema te cobra com juros.

📌 O que é

Leitura de arquivos VSAM (ESDS, KSDS, RRDS), acesso direto e sequencial.

🧠 Resumo rápido

CICS acessa VSAM sem JCL, sem batch, sem paciência.

🧪 Exemplo

EXEC CICS READ FILE('ARQ01') INTO(AREA) RIDFLD(CHAVE) END-EXEC

⚠️ Dica Bellacosa

READ sem RESP é convite para ABEND invisível.

🥚 Easter Egg

Browse (STARTBR/READNEXT) é cursor de banco de dados versão 1974.

🤫 Fofoquice

Problema de concorrência quase sempre é batch rodando fora do horário.


🔹 MÓDULO VI – Atualizando Arquivos


CICS CRUD em VSAM e unidades de trabalho

No CICS, falar de CRUD sem falar de UOW (Unit of Work) é conversa de quem nunca viu dado corrompido em produção. Aqui, criar, ler, atualizar e excluir registro não é só operação — é compromisso com integridade.

O READ é o ponto de entrada: você consulta um registro VSAM ou DB2 e decide o que fazer. Se for só leitura, o CICS observa. Mas no momento em que você faz um READ UPDATE, o jogo muda. O CICS trava o registro para aquela TASK. A partir daí, qualquer CREATE (WRITE), UPDATE (REWRITE) ou DELETE passa a fazer parte de uma UOW.

A UOW é o acordo sagrado: ou tudo acontece, ou nada acontece. Se o programa termina normalmente, o CICS faz o syncpoint (commit) e grava definitivamente as alterações. Se der erro, ABEND, timeout ou queda de sistema, o CICS entra em ação e desfaz tudo usando seus logs. O sistema volta ao estado consistente como se a TASK nunca tivesse existido.

Isso permite concorrência pesada sem caos. Cem usuários podem acessar o mesmo arquivo e, ainda assim, os dados permanecem corretos. Não é sorte — é arquitetura.

Estilo Bellacosa: CRUD em CICS não é sobre gravar dado, é sobre não estragar o que já existe. Quem ignora UOW aprende rápido… geralmente em produção.

📌 O que é

UPDATE, WRITE, DELETE, UOW, integridade e recuperação.

🧠 Resumo rápido

CICS leva consistência a sério. Se cair, ele volta atrás.

🧪 Exemplo

Atualizar registro com REWRITE após READ UPDATE.

⚠️ Dica Bellacosa

UPDATE sem UOW bem definido = auditor sorrindo.

🥚 Easter Egg

UNLOCK existe porque alguém esqueceu de liberar registro em 1989.

🤫 Fofoquice

Quem não entende syncpoint nunca dormiu após deploy.


🔹 MÓDULO VII – Sub-rotinas

CICS chamando subrotinas Xctl e link

No CICS, chamar subrotinas não é simples desvio de fluxo — é orquestração controlada de programas dentro de uma TASK. Aqui, cada chamada tem consequência arquitetural, e errar isso vira efeito dominó em produção.

O comando mais comum é o LINK. Ele chama outro programa, passa o controle, compartilha a mesma UOW e depois volta para o chamador. É a escolha certa quando você precisa reutilizar lógica e manter contexto. LINK é educado, previsível e fácil de auditar. Se o programa chamado falhar, a TASK inteira sente.

Já o XCTL é corte seco. Ele transfere o controle para outro programa e não volta. A partir daí, o chamador deixa de existir. Isso é útil para navegação de fluxo — mudar de tela, mudar de etapa — mas perigoso se usado sem critério. Muito sistema virou labirinto por abuso de XCTL.

O START cria uma nova TASK, independente, assíncrona. É processamento em paralelo versão mainframe: robusto, rastreável e com impacto real no sistema. Use com consciência.

A comunicação entre programas pode ser via COMMAREA (limitada, clássica) ou Channel/Container (moderna, flexível). Ambas exigem disciplina.

Estilo Bellacosa: em CICS, chamar programa é decisão de arquitetura, não linha de código.

📌 O que é

LINK, XCTL, START, LOAD, níveis lógicos e COMMAREA.

🧠 Resumo rápido

LINK volta, XCTL não. Parece simples, mas derruba sistemas.

🧪 Exemplo

EXEC CICS LINK PROGRAM('PGM02') COMMAREA(AREA) END-EXEC

⚠️ Dica Bellacosa

COMMAREA grande é gambiarra elegante.

🥚 Easter Egg

START cria task assíncrona — tipo thread, só que sério.

🤫 Fofoquice

Muita aplicação virou “espaguete” por abuso de XCTL.


🔹 MÓDULO VIII – Channel / Container

CICS e o uso de commarea e cotainers

No CICS, Channel e Container surgem como resposta adulta a um problema antigo: a COMMAREA era útil, mas pequena, rígida e fácil de virar gambiarra. Channel/Container é o CICS dizendo: “vamos fazer isso direito”.

Um Channel é um agrupador lógico. Pense nele como um envelope nomeado que viaja junto com a TASK. Dentro dele vivem os Containers, que são áreas de dados independentes, cada uma com nome, tipo e tamanho próprio. Não existe limite prático de 32K, não existe copybook único obrigatório, não existe empacotamento manual de estruturas. Cada container carrega exatamente o que precisa carregar.

Na prática, quando um programa chama outro via LINK ou XCTL, ele pode passar um Channel inteiro. O programa chamado acessa apenas os containers que lhe interessam. Isso reduz acoplamento, melhora legibilidade e facilita evolução do sistema sem quebrar o legado.

Os comandos são explícitos: PUT CONTAINER, GET CONTAINER, DELETE CONTAINER. Nada mágico, tudo rastreável. O CICS gerencia memória, ciclo de vida e limpeza automaticamente quando a TASK termina.

Estilo Bellacosa: Channel/Container não é moda — é higiene arquitetural. Quem insiste em COMMAREA gigante não está sendo “clássico”, está só adiando o próximo problema.

📌 O que é

Substituto moderno da COMMAREA.

🧠 Resumo rápido

Channel/Container é COMMAREA adulta, sem limite de 32K.

🧪 Exemplo

Passar múltiplas estruturas sem copybook único.

⚠️ Dica Bellacosa

Projeto novo? Use Channel/Container. Sempre.

 

CICS channel

🥚 Easter Egg

Você pode passar XML, JSON e estruturas complexas sem dor.


🔹 MÓDULO IX – Áreas Externas

CICS em areas externas getmain e freemain

No CICS, falar de áreas externas, GETMAIN e FREEMAIN é entrar no território onde o programador deixa de ser usuário da API e vira responsável direto pela memória. Aqui não tem coletor de lixo, não tem perdão automático.

Por padrão, programas CICS são quasi-reentrant e compartilham código. A WORKING-STORAGE existe, mas é controlada pelo CICS. Quando você precisa de memória dinâmica — tabelas em tempo de execução, buffers variáveis, listas crescentes — entra o GETMAIN. Ele pede ao CICS um bloco de memória, no tamanho exato, dentro da região apropriada (TASK ou SHARED). A memória vem zerada, identificável e sob controle do gerenciador.

O perigo começa quando o programador esquece que toda memória alocada precisa ser devolvida. É aí que entra o FREEMAIN. Ele libera explicitamente aquela área. Se você não chamar FREEMAIN, o CICS até limpa no fim da TASK, mas você cria pressão desnecessária na região, degrada performance e ganha fama silenciosa.

GETMAIN mal usado vira vazamento, corrupção e comportamento fantasma. GETMAIN bem usado resolve problemas reais com elegância.

Estilo Bellacosa: GETMAIN é poder, FREEMAIN é responsabilidade. Quem domina os dois escreve sistema robusto. Quem esquece um deles cria incidente que ninguém entende — até o sysprog olhar.

📌 O que é

GETMAIN, FREEMAIN, tabelas em memória, SET.

🧠 Resumo rápido

Memória dinâmica em CICS é poder — e perigo.

⚠️ Dica Bellacosa

Quem esquece FREEMAIN cria vazamento silencioso.


🔹 MÓDULO X – Filas TD e TS

CICS e dados armazenados em ts e td

No CICS, filas TD e TS existem para resolver dois problemas distintos que muita gente insiste em misturar. E quando mistura, dá dor de cabeça.

As filas TD (Transient Data) são feitas para mensagens sequenciais: logs, integração, auditoria, disparo de processos. Você escreve, alguém lê, acabou. Elas podem ser intrapartition (gerenciadas totalmente pelo CICS) ou extrapartition (apontando para datasets externos). TD é fluxo, é trilha, é “escreveu, seguiu em frente”. Não é banco de dados e não é memória temporária.

Já as filas TS (Temporary Storage) são armazenamento temporário com nome. Você grava um item, lê depois, atualiza, apaga quando quiser. TS é usada para guardar contexto entre pseudo-conversações, listas temporárias, dados intermediários. Pode ser em memória ou em dataset, dependendo da configuração. É flexível, mas exige disciplina.

A regra não escrita: TD não se lê para decidir lógica; TS não se usa como persistência definitiva. TD é linear, TS é aleatório. Cada uma tem custo, impacto e comportamento próprios.

Estilo Bellacosa: TD é correio, TS é gaveta. Quem usa correio como gaveta perde carta. Quem usa gaveta como arquivo perde o sistema.

📌 O que é

Queueing no CICS: TD (logs, integração) e TS (temporário).

🧠 Resumo rápido

TD é “mensagem”, TS é “memória com nome”.

⚠️ Dica Bellacosa

TS não é banco de dados. Nunca foi.


🔹 MÓDULO XI – Tratamento de Exceções

CICS trantando erros e exceções

No CICS, tratamento de erros e exceções não é detalhe — é parte da arquitetura. Aqui o sistema assume que algo vai dar errado e se prepara melhor do que muita aplicação moderna.

Toda chamada EXEC CICS retorna códigos RESP e RESP2. Ignorar isso é escolher viver no escuro. O RESP indica o tipo geral da condição; o RESP2 detalha o motivo real. Arquivo não encontrado, registro bloqueado, mapa inválido, segurança negada — tudo é sinalizado. Quem testa RESP controla o fluxo. Quem não testa, recebe ABEND surpresa.

Além disso, o CICS permite HANDLE CONDITION, que desvia automaticamente o fluxo quando uma exceção ocorre. É poderoso, mas exige disciplina. Existe também o NOHANDLE, para quando você quer assumir o risco conscientemente. Já o IGNORE CONDITION é a forma oficial de dizer: “sei que isso pode acontecer e não é erro”.

Para falhas graves, entra o HANDLE ABEND. Ele permite capturar o abend, registrar contexto, liberar recursos e até apresentar mensagem amigável ao usuário antes do fim da TASK. O CICS não deixa o sistema cair — ele isola o problema.

Estilo Bellacosa: erro em CICS não é acidente, é evento esperado. Trate, registre e siga em frente. Quem não faz isso vira estudo de caso no CMAC.

📌 O que é

RESP, RESP2, HANDLE CONDITION, HANDLE ABEND.

🧠 Resumo rápido

Erro não tratado em CICS vira ABEND educacional.

⚠️ Dica Bellacosa

RESP é obrigação moral.


🔹 MÓDULO XII – Programas Exemplo

Em breve disponibilizarei o link do repositorio do GITHUB.

📌 O que é

Integra tudo: tela, VSAM, navegação, exceções.

🧠 Resumo rápido

Aqui o aluno vira programador de verdade.


📚 GUIA DE ESTUDO (Bellacosa Approved)

Mapa do Tesouro CICS


🥇 Ordem ideal

  1. Conceitos + TASK

  2. EXEC CICS + EIB

  3. BMS

  4. VSAM READ/BROWSE

  5. UPDATE + UOW

  6. LINK/XCTL

  7. Channel/Container

  8. Exceções

🛠️ Treinar sempre

  • CECI antes de codar

  • CEDF em ambiente controlado

  • Ler CMAC após ABEND

🧠 Mentalidade

CICS não executa programas.
Ele orquestra eventos.


Trabalho em curso 

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