 |
| Bellacosa Mainframe o perigo da tecnologia sem objetivo |
☕ Um Café no Bellacosa Mainframe
🧠 DEEP THOUGHT E A DUNGEON DO 42 — QUANDO O COBOL DESCOBRIU QUE A RESPOSTA CORRETA NÃO SERVE PARA NADA SE NINGUÉM SOUBER A PERGUNTA
Tecnologia, COBOL, sistemas de informação, semiótica, automação, sistemas sociotécnicos, modernização, IA, agentes, conhecimento, responsabilidade — e o dia em que um programador COBOL descobriu que até o maior computador do Universo pode entregar uma resposta inútil quando ninguém sabe exatamente qual problema queria resolver.
🎬 PRÓLOGO — A RESPOSTA É 42
Imagine que você acabou de entrar em uma grande empresa como programador COBOL.
Primeiro emprego.
Primeiro crachá.
Primeiro acesso ao TSO.
Primeiro READY.
Primeira vez olhando para uma tela ISPF e pensando:
— Meu Deus... onde fui me meter?
Você recebe sua primeira missão.
Um programa COBOL antigo está apresentando comportamento estranho.
O líder técnico explica:
— Precisamos modernizar isso.
Você pergunta:
— Qual é o problema?
Silêncio.
Alguém responde:
— É COBOL.
Você insiste:
— Sim. Mas qual é o problema?
Novo silêncio.
Então começam as respostas:
— É antigo.
— Precisamos ir para cloud.
— Precisamos colocar APIs.
— Precisamos usar inteligência artificial.
— Precisamos de microsserviços.
— Precisamos de Kubernetes.
— Precisamos modernizar.
Você olha novamente para o programa.
Ele executa diariamente.
Processa milhões de registros.
O tempo de processamento está dentro da janela batch.
Não existem incidentes graves associados a ele.
O custo é conhecido.
A operação conhece o sistema.
E aparentemente ninguém consegue explicar exatamente qual problema está sendo resolvido pela modernização.
Nesse momento, uma voz grave ecoa pela sala:
42.
Todos olham assustados.
É Deep Thought.
O lendário computador de O Guia do Mochileiro das Galáxias acaba de entrar na War Room.
E ele tem uma péssima notícia:
vocês estão procurando respostas antes de descobrir a pergunta.
Pegue o café.
Abra o ISPF.
Hoje nossa dungeon não começa com COBOL.
Começa com algo muito mais perigoso:
uma solução procurando um problema.
🧙 CAPÍTULO 1 — A CHANTAGEM TECNOLÓGICA
Existe uma crença recorrente na indústria de tecnologia:
tecnologia nova é necessariamente melhor.
O mecanismo funciona mais ou menos assim:
Tecnologia nova
↓
Marketing
↓
Promessa de produtividade
↓
Medo de ficar para trás
↓
Compra
↓
Implantação
↓
Problemas inesperados
↓
Nova tecnologia prometendo resolver os problemas
↓
REPEAT
Esse medo ganhou até uma expressão moderna:
FOMO — Fear Of Missing Out.
O medo de ficar de fora.
A empresa olha para a concorrência usando inteligência artificial e pergunta:
— Por que ainda não temos IA?
Poucos perguntam:
— Qual problema nosso exige IA?
Essa diferença parece pequena.
Não é.
É a diferença entre engenharia e fetichismo tecnológico.
Podemos chamar esse fenômeno de chantagem tecnológica:
“Se você não comprar nossa nova tecnologia, sua empresa ficará ultrapassada.”
Ontem eram PCs.
Depois cliente-servidor.
Depois downsizing.
Depois Internet.
Depois SOA.
Depois cloud.
Depois containers.
Depois blockchain.
Depois inteligência artificial generativa.
Agora:
Agentic AI.
Não significa que essas tecnologias sejam ruins.
Pelo contrário.
Muitas transformaram profundamente a computação.
O problema começa quando a tecnologia deixa de ser meio e passa a ser objetivo.
⚔️ CAPÍTULO 2 — A SOLUÇÃO QUE SAIU PROCURANDO UM PROBLEMA
Imagine uma empresa que compra uma poderosa plataforma de inteligência artificial.
Contrato assinado.
Licenças compradas.
Consultoria contratada.
Infraestrutura instalada.
Então alguém pergunta:
— O que vamos fazer com isso?
Perceba a inversão.
O caminho saudável seria:
PROBLEMA
↓
ANÁLISE
↓
REQUISITOS
↓
ALTERNATIVAS
↓
TECNOLOGIA
↓
IMPLEMENTAÇÃO
↓
MEDIÇÃO
Mas o caminho frequentemente encontrado é:
TECNOLOGIA
↓
COMPRA
↓
PROJETO
↓
PROCURA POR CASO DE USO
Quando ouvimos:
“Agora precisamos encontrar casos de uso para justificar a plataforma.”
Deep Thought provavelmente responderia:
Porque começamos pela resposta.
Ainda não sabemos a pergunta.
🧠 CAPÍTULO 3 — DEEP THOUGHT E O MAIOR PROBLEMA DE REQUISITOS DO UNIVERSO
Em O Guia do Mochileiro das Galáxias, uma civilização constrói um computador gigantesco chamado Deep Thought.
Sua missão é encontrar a resposta para:
a Vida, o Universo e Tudo Mais.
Depois de um período absurdamente longo de processamento, Deep Thought finalmente anuncia a resposta:
42.
Problema resolvido?
Não.
Ninguém sabe exatamente qual era a pergunta.
Essa é uma das melhores metáforas acidentais sobre engenharia de requisitos.
Um computador pode executar perfeitamente:
INPUT
↓
ALGORITHM
↓
OUTPUT
Mas existe uma pergunta anterior:
O que estamos tentando descobrir?
E outra posterior:
O que significa o resultado?
Sem essas duas coisas, podemos possuir processamento perfeito e ainda assim produzir algo inútil.
🖥️ CAPÍTULO 4 — COMPUTADORES NÃO RESOLVEM PROBLEMAS
Calma.
Eles obviamente resolvem determinados problemas computacionais.
Mas existe uma distinção importante.
Computadores executam representações formalizadas de problemas.
Antes de chegar ao COBOL, alguma coisa precisa acontecer.
Imagine um banco.
A organização estabelece:
determinadas contas devem ser bloqueadas quando determinadas condições forem satisfeitas.
Depois isso vira regra de negócio.
Depois especificação.
Finalmente podemos ter:
IF SALDO-CLIENTE < ZERO
MOVE 'B' TO STATUS-CONTA
END-IF.
Para a CPU isso é maravilhoso.
Temos uma condição.
Temos dados.
Temos uma ação.
Mas Deep Thought pergunta:
— Por que saldo negativo significa bloqueio?
Boa pergunta.
Talvez existam:
Portanto, antes daquele pequeno IF, existiu um mundo inteiro.
REALIDADE
↓
POLÍTICA
↓
REGRA DE NEGÓCIO
↓
ESPECIFICAÇÃO
↓
ALGORITMO
↓
COBOL
O programador normalmente encontra apenas o último andar dessa pirâmide.
🏺 CAPÍTULO 5 — O PROGRAMA COBOL É UM FÓSSIL ORGANIZACIONAL
Agora você encontra:
IF WS-TYPE = '7'
AND WS-CODE NOT = '91'
AND WS-FLAG = 'Y'
PERFORM 8300-PROCESSAR
END-IF.
Sua primeira reação pode ser:
— Que porcaria é essa?
Cuidado.
Talvez você esteja diante de um fóssil.
WS-TYPE = '7' pode ter surgido em 1989.
WS-CODE NOT = '91' pode ter aparecido depois de uma fraude em 1997.
WS-FLAG = 'Y' pode representar uma exigência regulatória de 2008.
E o PERFORM pode ter sido alterado depois de uma fusão empresarial em 2014.
Você não está simplesmente lendo código.
Está praticando:
arqueologia organizacional.
Um sistema legado pode ser uma espécie de memória institucional executável.
Isso explica por que reescrever sistemas antigos é muito mais difícil do que traduzir linguagens.
🏰 CAPÍTULO 6 — SISTEMAS DE INFORMAÇÃO NÃO SÃO APENAS COMPUTADORES
Um erro comum de iniciantes é pensar:
Sistema de Informação
=
Hardware + Software + Banco de Dados
Na realidade temos algo muito maior:
PESSOAS
│
│
PROCESSOS ── INFORMAÇÃO ── TECNOLOGIA
│
│
REGRAS
│
│
CULTURA
Existe ainda:
poder;
autoridade;
confiança;
experiência;
legislação;
comunicação;
exceções;
conhecimento tácito.
Isso é chamado de visão sociotécnica.
O computador é apenas uma parte do sistema.
📜 CAPÍTULO 7 — EXISTE UM SISTEMA QUE NÃO ESTÁ NO COMPUTADOR
Imagine um processo de crédito.
O manual diz:
Pedido
↓
Análise
↓
Score
↓
Aprovação
Esse é o sistema formal.
Mas na prática acontece:
Pedido
↓
Analista
↓
Consulta sistema
↓
Liga para gerente
↓
"Conheço esse cliente."
↓
Consulta documento antigo
↓
Conversa com supervisor
↓
Exceção
↓
Aprovação
Isso também é um sistema de informação.
Só que parte dele é informal.
O perigo aparece quando alguém automatiza somente:
Pedido → Score → Aprovação
e acredita ter automatizado todo o processo.
Não automatizou.
Automatizou apenas a parte que conseguiu formalizar.
🔒 CAPÍTULO 8 — “O SISTEMA NÃO DEIXA”
Quem nunca ouviu:
“Não posso fazer. O sistema não deixa.”
Essa frase merece atenção.
O computador não acordou naquela manhã e decidiu impedir alguma coisa.
Alguém:
definiu uma política;
transformou-a em regra;
especificou uma condição;
programou;
testou;
colocou em produção.
Portanto:
"O SISTEMA NÃO DEIXA"
normalmente significa:
"UMA DECISÃO HUMANA FOI
FORMALIZADA EM SOFTWARE"
Mas existe um efeito psicológico interessante.
Depois que a regra entra no computador, ganha aparência de autoridade.
— Por que meu pedido foi recusado?
— O sistema recusou.
Como se o computador fosse uma entidade independente.
📡 CAPÍTULO 9 — DADO NÃO É INFORMAÇÃO
Considere:
327
O que significa?
Nada.
Agora:
327 ms
Melhor.
Depois:
CICS RESPONSE TIME = 327 ms
Agora temos informação contextualizada.
Mas ainda falta alguma coisa.
Imagine que historicamente aquela transação responde entre 80 e 150 ms.
Agora:
BASELINE = 120 ms
ATUAL = 327 ms
Um especialista interpreta:
Existe degradação.
Investigando, encontra:
Db2 LOCK CONTENTION
↓
WAIT
↓
CICS RESPONSE TIME
↓
327 ms
Veja a transformação:
327
↓
DADO
327 ms
↓
CONTEXTO
CICS = 327 ms
↓
INFORMAÇÃO
327 > BASELINE
↓
INTERPRETAÇÃO
Db2 contention
↓
CONHECIMENTO
Investigar locking
↓
AÇÃO
Esse caminho é fundamental para entender sistemas de informação.
🔤 CAPÍTULO 10 — SEMIÓTICA ENTRA NA SALA DO CPD
Semiótica estuda sinais e significados.
Isso parece filosofia distante de COBOL.
Não é.
Considere:
RC=12
Para o computador são bits.
Para JES pode representar um retorno.
Para o operador:
— O job falhou.
Para o programador:
— Preciso verificar a step.
Para o negócio:
— O processamento não terminou.
Para o cliente:
— Meu pagamento não apareceu.
O mesmo sinal produziu significados diferentes.
Podemos simplificar:
SINAL
+
CONTEXTO
+
INTÉRPRETE
=
SIGNIFICADO
O computador manipula sinais.
O significado surge da interpretação.
🤖 CAPÍTULO 11 — ENTÃO CHEGOU A INTELIGÊNCIA ARTIFICIAL
Agora a discussão fica extraordinariamente moderna.
Um LLM recebe tokens.
Processa tokens.
Produz tokens.
Nós olhamos para a saída e dizemos:
“A IA respondeu.”
Mas existe diferença entre:
TEXTO PLAUSÍVEL
e:
INFORMAÇÃO VERDADEIRA
E existe outra diferença entre:
INFORMAÇÃO
e:
DECISÃO SEGURA
Por isso surgiram discussões sobre:
hallucination;
grounding;
RAG;
provenance;
explainability;
human-in-the-loop;
governança;
validação.
O problema filosófico de Deep Thought voltou usando GPU.
⚠️ CAPÍTULO 12 — AUTOMATION BIAS
Imagine uma tela:
FRAUD RISK: 93.17%
Aquilo parece preciso.
93,17%.
Duas casas decimais!
Só que um bom engenheiro pergunta:
O que significa 93,17%?
Qual população foi utilizada?
Qual é o falso positivo?
O modelo está calibrado?
Houve drift?
Quais dados estão faltando?
Quem decidiu o threshold?
Existe direito de revisão?
Existe um fenômeno chamado automation bias: nossa tendência de atribuir confiança excessiva a resultados produzidos por sistemas automatizados.
Quanto mais bonita a interface, maior pode ser a tentação.
🪞 CAPÍTULO 13 — O BANCO DE DADOS NÃO CONTÉM O CLIENTE
Imagine uma tabela:
CUSTOMER
ID
NAME
ADDRESS
BALANCE
RISK_SCORE
STATUS
Existe uma pessoa dentro do Db2?
Não.
Existe uma representação computacional dela.
A pessoa real possui história, intenções, relações, circunstâncias e contexto.
O banco contém apenas atributos considerados relevantes para determinada finalidade.
Isso significa:
o modelo não é a realidade.
Todo sistema informatizado reduz alguma coisa.
REALIDADE
████████████████████████████
MODELO
██████████████████
REGRA
██████████
SOFTWARE
██████
DADOS
████
Cada camada perde contexto.
☁️ CAPÍTULO 14 — MODERNIZAR NÃO É TROCAR COBOL POR JAVA
Aqui encontramos uma das maiores armadilhas da modernização.
A empresa possui:
PROCESSO DE 1987
↓
COBOL
Decide modernizar:
COBOL
↓
JAVA
↓
MICROSERVICES
↓
CONTAINER
↓
KUBERNETES
Fantástico.
Agora temos:
um processo de 1987 executando lindamente dentro de containers.
Modernização tecnológica não garante modernização organizacional.
Antes de reescrever o programa, deveríamos perguntar:
— Essa regra ainda é necessária?
— Esse processo ainda faz sentido?
— Essa informação ainda precisa ser coletada?
— Essa aprovação ainda controla algum risco?
— Essa exceção ainda existe?
Às vezes a melhor linha de código modernizada é aquela que descobrimos que pode ser eliminada.
🦖 CAPÍTULO 15 — LEGACY NÃO SIGNIFICA INÚTIL
Tecnologia antiga possui algo que tecnologia nova ainda não conseguiu comprar:
história operacional.
COBOL, CICS, Db2 e z/OS possuem décadas de:
documentação;
correções;
conhecimento;
práticas operacionais;
troubleshooting;
compatibilidade;
experiência.
Tecnologia nova oferece possibilidades fantásticas.
Mas também pode trazer:
Portanto:
NOVO ≠ MELHOR
e:
VELHO ≠ RUIM
A pergunta correta é:
ADEQUADO?
Deep Thought aprova.
💰 CAPÍTULO 16 — O LOCK-IN MAIS PERIGOSO NÃO É TECNOLÓGICO
Todo mundo conhece vendor lock-in.
Mas existe outro:
conceptual lock-in.
Quando compramos determinada tecnologia, começamos a enxergar todos os problemas através dela.
Quem vende blockchain encontra blockchain em tudo.
Quem vende RPA encontra processos para robotizar.
Quem vende cloud encontra workloads para migrar.
Quem vende GenAI encontra copilots.
Quem vende Agentic AI encontra agentes.
É a velha história:
Quando sua única ferramenta é um martelo, muitos problemas começam misteriosamente a parecer pregos.
A ferramenta passou a definir o problema.
Esse é o momento de chamar Deep Thought.
🚨 CAPÍTULO 17 — DEBUGGING DA ORGANIZAÇÃO
Imagine:
CLIENTES RECEBERAM COBRANÇA DUPLICADA.
O programador procura o programa.
Isso é necessário.
Mas uma verdadeira investigação pergunta:
Por que duplicação era possível?
Por que não havia idempotência?
Por que reconciliação não detectou?
Por que monitoramento não alertou?
Por que reprocessamento foi autorizado?
Por que o operador acreditou que era seguro?
A documentação explicava isso?
Quem conhecia a exceção?
Qual decisão organizacional criou essa condição?
Você deixou de simplesmente depurar COBOL.
Agora está:
debugando a organização.
Essa é uma habilidade extraordinária para quem trabalha com sistemas críticos.
🧭 CAPÍTULO 18 — PASSO A PASSO ANTES DE AUTOMATIZAR
Antes de escolher tecnologia, faça este exercício.
PASSO 1 — Defina o problema
Não escreva:
“Precisamos de IA.”
Escreva:
“Recebemos 30 mil solicitações mensais e 40% são classificadas manualmente.”
Agora temos problema.
PASSO 2 — Descubra quem participa
Liste:
usuário
operador
cliente
gestor
auditoria
segurança
compliance
sistemas
PASSO 3 — Mapeie o processo real
Não apenas o manual.
Observe o que as pessoas realmente fazem.
PASSO 4 — Procure exceções
Pergunte:
“Quando vocês não seguem esse procedimento?”
Essa pergunta vale ouro.
PASSO 5 — Descubra conhecimento tácito
Pergunte ao operador experiente:
“Como você sabe que alguma coisa está errada?”
A resposta pode revelar conhecimento inexistente na documentação.
PASSO 6 — Defina o que pode ser formalizado
Nem todo julgamento humano precisa virar IF.
PASSO 7 — Defina risco
O que acontece quando a automação erra?
PASSO 8 — Escolha tecnologia
Só agora.
COBOL?
Java?
Python?
RPA?
IA?
Nada?
Sim.
“Nada” também é uma alternativa arquitetural válida.
🤖 CAPÍTULO 19 — AGENTES DE IA TORNAM TUDO MAIS SÉRIO
Antigamente:
HUMANO
↓
SISTEMA
↓
RESULTADO
↓
HUMANO
O humano interpretava antes de agir.
Com agentes podemos construir:
HUMANO
↓
AGENTE
↓
LLM
↓
API
↓
SISTEMA
↓
DECISÃO
↓
OUTRA API
↓
AÇÃO
Agora a pergunta muda.
Não basta perguntar:
“A resposta está correta?”
Precisamos perguntar:
“O sistema possui autoridade para agir?”
Isso introduz:
identidade;
autorização;
segregação de funções;
auditoria;
rollback;
limites;
aprovação;
rastreabilidade;
responsabilidade.
Para quem conhece RACF, pense assim:
Não basta o agente saber como executar uma operação.
Precisamos definir quem ele representa, qual recurso pode acessar e com qual autoridade.
IA também precisa de RACF emocional.
Easter egg encontrado. ☕
👑 CAPÍTULO 20 — RESPONSABILIDADE É O CAMPO QUE NÃO CABE NO COPYBOOK
Imagine:
DADO
↓
ALGORITMO
↓
RESULTADO
↓
INTERPRETAÇÃO
↓
DECISÃO
↓
AÇÃO
↓
CONSEQUÊNCIA
Existe mais uma etapa:
RESPONSABILIDADE
Quem responde?
O programador?
O usuário?
O fornecedor?
O gestor?
Quem aprovou?
Quem definiu a regra?
Quem forneceu os dados?
Quem autorizou a automação?
Sistemas críticos não podem terminar em:
MOVE '42' TO WS-RESPOSTA.
Precisamos saber por que 42 existe e o que alguém pretende fazer com ele.
🧪 CAPÍTULO 21 — O TESTE DE DEEP THOUGHT
Na próxima reunião em que alguém anunciar:
“Precisamos colocar IA nisso!”
não comece discutindo modelo.
Pergunte:
Qual problema estamos tentando resolver?
Depois:
Como sabemos que esse problema existe?
Depois:
Como medimos seu tamanho?
Depois:
Quem é afetado?
Depois:
Como resolvemos atualmente?
Depois:
Quais exceções existem?
Depois:
Que conhecimento não está documentado?
Depois:
Qual erro é aceitável?
Depois:
Quem interpreta a saída?
Depois:
Quem responde se estiver errada?
E finalmente faça a pergunta assassina:
O que acontece se não comprarmos tecnologia nenhuma?
Às vezes a resposta será:
Nada.
Parabéns.
Você talvez tenha acabado de economizar alguns milhões.
🎁 CURIOSIDADE — A TECNOLOGIA MAIS NOVA PODE SER A MAIS ARRISCADA
Existe uma expressão interessante:
bleeding edge.
Podemos imaginar:
BLEEDING EDGE
↓
LEADING EDGE
↓
MATURE
↓
LEGACY
↓
OBSOLETE
Observe uma coisa importante:
legacy e obsolete não são sinônimos.
Um sistema pode ser legado e continuar:
suportado;
confiável;
economicamente adequado;
seguro;
crítico.
Da mesma maneira, uma tecnologia novíssima pode ser completamente inadequada ao problema.
Idade é apenas uma variável.
🥚 EASTER EGG — JOB DEEPTHOT
Nos confins da spool existe um job misterioso:
//DEEPTHOT JOB (42),'UNIVERSE'
//STEP01 EXEC PGM=QUESTION
//SYSOUT DD SYSOUT=*
//SYSIN DD *
LIFE
UNIVERSE
EVERYTHING
/*
Depois de milhões de anos de CPU:
IEF142I DEEPTHOT STEP01 - STEP WAS EXECUTED
ANSWER = 42
MAXCC = 0000
O job terminou perfeitamente.
MAXCC=0000.
Nenhum ABEND.
Nenhum dump.
Nenhum erro.
E mesmo assim...
ninguém sabe o que fazer com o resultado.
Esse talvez seja o exemplo perfeito de que:
EXECUÇÃO CORRETA
≠
PROBLEMA CORRETAMENTE RESOLVIDO
☕ EPÍLOGO — O PROGRAMADOR COBOL QUE APRENDEU A PERGUNTAR
Nosso jovem programador volta para a War Room.
Alguém pergunta:
— Então vamos migrar o programa?
Ele responde:
— Talvez.
— Java?
— Talvez.
— Cloud?
— Talvez.
— IA?
— Talvez.
O gerente começa a perder a paciência.
— Então qual é a sua recomendação?
O programador olha novamente para o programa COBOL de 35 anos.
Depois pergunta:
Qual problema estamos tentando resolver?
Silêncio.
Deep Thought sorri em algum lugar do Universo.
Porque naquele instante o iniciante deixou de ser simplesmente alguém que escreve COBOL.
Começou a pensar como engenheiro.
Tecnologia não existe isoladamente.
Computadores fazem parte de sistemas sociais.
Dados precisam de contexto.
Sinais precisam de interpretação.
Regras carregam decisões humanas.
Código carrega história.
Automação carrega responsabilidade.
IA não elimina esses problemas.
Amplifica-os.
E modernização não significa trocar uma linguagem velha por uma linguagem nova.
Significa compreender suficientemente bem o sistema para decidir conscientemente o que deve permanecer, o que deve mudar, o que deve ser automatizado e o que nunca deveria ter existido.
Talvez essa seja uma das maiores lições para qualquer programador COBOL entrando no mundo dos sistemas corporativos:
Não se apaixone primeiro pela resposta. Apaixone-se pelo problema.
Porque hardware muda.
Linguagens mudam.
Arquiteturas mudam.
Mainframes evoluem.
Cloud evolui.
IA evolui.
Os vendedores continuarão chegando com respostas extraordinárias.
Mas alguém ainda precisará fazer aquela pergunta incômoda na reunião:
“Qual era mesmo o problema?”
E quando ninguém souber responder...
há sempre uma resposta tecnicamente disponível.
IDENTIFICATION DIVISION.
PROGRAM-ID. DEEP-THOUGHT.
PROCEDURE DIVISION.
MOVE 42 TO WS-ANSWER
DISPLAY
'THE ANSWER TO LIFE,'
' THE UNIVERSE AND EVERYTHING: '
WS-ANSWER
STOP RUN.
MAXCC=0000.
Resposta encontrada.
Projeto entregue.
Produção estável.
Só faltou um pequeno requisito:
descobrir a pergunta.
☕💻
EASTER EGG FINAL: se este artigo fosse um job de produção, eu verificaria o spool às 03:17. Deep Thought provavelmente estaria esperando por lá, tentando descobrir por que alguém abriu um incidente para corrigir um 42 que estava funcionando exatamente como especificado.
Máxima Bellacosa
O job pode terminar com MAXCC=0000, entregar 42 e ainda assim o projeto inteiro estar errado — porque ninguém perguntou se aquela era a pergunta que precisava ser respondida.
