☕ Um Café no Bellacosa Mainframe

MIPS, MSU e o Mistério da Conta que Cresce Mais Rápido que o Banco

Ou: como um programador COBOL iniciante descobre que um `PERFORM` inocente pode terminar numa reunião com o CFO

Se você está começando em COBOL, provavelmente alguém já lhe contou a versão resumida da história.

O mainframe é grande.

O mainframe é caro.

MIPS é alguma coisa relacionada a capacidade.

MSU é alguma coisa relacionada a cobrança.

E se você mexer num programa errado, algum senhor de barba grisalha aparecerá atrás de você com uma planilha impressa e uma expressão que significa:

— Filho… o que exatamente você colocou em produção ontem?

Essa versão não está completamente errada.

Mas está longe de contar a história inteira.

Porque existe um detalhe fascinante no universo IBM Z: uma linha de código pode ser tecnicamente correta, produzir exatamente o resultado esperado, passar nos testes, não gerar ABEND, não provocar S0C7, não derrubar CICS, não assustar RACF e ainda assim ser economicamente horrível.

E é aqui que nosso jovem gafanhoto COBOL entra no dojo.

Imagine o Sr. Miyagi diante de um terminal 3270.

Ele olha para você e diz:

— Bellacosa-san… programa bom não é programa que apenas funciona.

Você pergunta:

— Então o que é?

Ele aponta para o SMF.

— Programa bom trabalha certo, trabalha rápido e não põe fogo na fatura.

A aula começa.

🥋 1. Primeiro golpe: MIPS não é MSU

Antes de continuar, precisamos desmontar uma confusão muito comum.

MIPS e MSU aparecem frequentemente na mesma conversa, mas não são a mesma coisa.

MIPS significa, historicamente:

Millions of Instructions Per Second.

É uma forma tradicional de falar de capacidade computacional.

Só que em mainframe moderno isso precisa ser tratado com cuidado, porque uma “instrução” não é simplesmente uma moedinha universal que vale a mesma coisa em qualquer processador, geração ou workload.

Duas máquinas podem ter características diferentes.

Dois workloads podem exercitar partes diferentes do processador.

Uma aplicação matemática pesada se comporta de uma forma.

Um workload de transações CICS de outra.

Um batch COBOL gigante de outra.

Por isso, MIPS virou muito mais uma linguagem de capacidade e planejamento — e também, em muitos casos, uma unidade comercial usada por fornecedores de software — do que uma medida física absoluta.

MSU significa:

Million Service Units.

E aqui entramos diretamente no mundo de pricing e capacidade do software IBM Z.

A primeira regra do dojo é esta:

MIPS é normalmente uma conversa sobre capacidade. MSU pode ser uma conversa sobre capacidade, licenciamento e custo.

Mas cuidado.

Não saia por aí tentando converter:

1 MSU = 7,3 MIPS

como se estivesse convertendo quilômetros em milhas.

Não funciona assim.

Não existe uma conversão universal simples.

Se algum colega lhe entregar uma tabela mágica dizendo:

MSU × número secreto = MIPS

faça aquilo que todo programador COBOL experiente faz diante de uma planilha duvidosa:

olhe desconfiado.

Depois peça a fonte.

🧠 2. CPU também não é custo

Aqui vem a segunda rasteira.

O iniciante pensa:

“Se meu programa gastou 10% mais CPU, a empresa pagará 10% mais.”

Não necessariamente.

Você pode gastar mais CPU sem aumentar determinada parte do custo.

Pode gastar a mesma CPU e aumentar a conta.

Pode diminuir CPU e ter pouco impacto financeiro.

Pode simplesmente mudar o horário de execução e alterar completamente o efeito econômico.

Você acabou de conhecer uma das verdades mais importantes do mainframe:

Performance e custo são parentes, mas não são gêmeos.

Isso explica um fenômeno aparentemente absurdo.

Um banco pode crescer 8% em volume de negócio.

O consumo pode crescer 15%.

E a conta de software subir 30%.

O CFO olha para aquilo e pergunta:

— Quem roubou os outros 22%?

Nesse momento todos olham para o mainframe.

O mainframe olha para o teto.

O COBOL olha para o Db2.

O Db2 olha para o batch.

E o batch diz:

— Eu só estava seguindo o JCL.

⏰ 3. Conheça o monstro chamado R4HA

Agora o Sr. Miyagi pega quatro pedras e coloca sobre a mesa.

Cada pedra representa uma hora.

Ele diz:

— Quatro horas. Observe.

Em vários modelos tradicionais de subcapacity pricing existe um conceito muito importante:

Rolling Four-Hour Average, ou R4HA.

Em português informal:

média móvel de quatro horas.

A ideia é simples de entender.

Imagine o consumo:

08h — 70 MSU
09h — 80 MSU
10h — 85 MSU
11h — 90 MSU

Existe uma média para essa janela.

Depois:

09h — 80
10h — 85
11h — 90
12h — 95

Nova janela.

Depois:

10h — 85
11h — 90
12h — 95
13h — 110

E assim por diante.

A janela vai deslizando.

Daí o nome rolling.

Agora vem a parte importante.

Em determinados modelos tradicionais de cobrança, o pico relevante dessa média móvel pode influenciar a capacidade faturável.

E então acontece a tragédia clássica.

Durante o dia:

CICS            70
Db2             40
APIs            20
online geral    15

Tudo administrável.

Às 17h alguém dispara:

fechamento
relatório regulatório
batch contábil
extração de dados
reconciliação
backup lógico

Todos juntos.

Porque sempre foi assim.

Desde 1998.

Ninguém sabe exatamente por quê.

Mas existe um comentário no JCL:

//* NAO ALTERAR - PRODUCAO

E isso, no mainframe, às vezes tem o mesmo poder psicológico de uma placa escrita:

TUMBA DO FARAÓ — NÃO ABRIR.

O consumo dispara.

O banco não ficou três vezes maior.

O mundo não começou a fazer três vezes mais PIX.

Apenas vários workloads decidiram executar simultaneamente.

E aquela concentração pode produzir impacto econômico.

Esse é um dos motivos pelos quais scheduling pode ser tão importante quanto programação.

🎯 4. Primeira lição de ouro: deslocar não é otimizar

Imagine um batch que consome:

60 CPU seconds

Você executa às 17h.

Depois desloca para 02h.

Ele continua consumindo:

60 CPU seconds

Tecnicamente você não otimizou o código.

Não reduziu nenhuma instrução.

Não mexeu no COBOL.

Não mudou Db2.

Não alterou VSAM.

Mas pode ter melhorado a economia do ambiente dependendo do modelo de cobrança.

Isso é lindo porque destrói uma ideia muito comum:

otimização = mexer no programa.

Não.

Você pode otimizar:

código;
SQL;
scheduling;
arquitetura;
classificação de workload;
uso de processadores especializados;
política de capacidade;
configuração;
contrato.

Programador COBOL iniciante costuma enxergar apenas o programa.

Engenheiro mainframe experiente começa a enxergar o sistema inteiro.

Essa é a evolução.

🧾 5. Antes de mexer em qualquer coisa, descubra o contrato

Aqui está uma frase que deveria ser impressa em canecas:

Antes de otimizar o mainframe, descubra como o mainframe está sendo cobrado.

Porque não existe “a conta do mainframe”.

Existem várias contas.

Você pode ter:

hardware
software IBM
software ISV
storage
suporte
DR
licenças por capacidade
licenças por consumo
licenças por MIPS
modelos tradicionais
Tailored Fit Pricing
contratos especiais

E cada parte pode reagir de maneira diferente.

Imagine que você passe uma semana reduzindo um batch em 20%.

Excelente.

Mas descubra depois que aquele componente específico não altera o custo relevante do contrato atual.

Você melhorou performance.

Ótimo.

Só não economizou o que esperava.

Agora faça o contrário.

Você move um workload, altera uma janela de execução e reduz um pico economicamente relevante.

Nenhuma linha COBOL mudou.

E o financeiro percebe o efeito.

Bem-vindo ao mainframe.

🐍 6. O segundo monstro está dentro do seu COBOL

Agora finalmente chegamos à parte que interessa diretamente ao jovem programador.

Imagine este código:

PERFORM UNTIL WS-EOF = 'Y'
    READ ARQUIVO-CLIENTES
    ...
END-PERFORM.

Em 2001 o arquivo tinha:

500.000 registros

Em 2026:

40.000.000 registros

O código não piorou.

Ele é exatamente o mesmo.

Mas o mundo ao redor cresceu.

Isso ensina uma coisa importante:

Código velho pode ficar economicamente pior sem mudar uma única linha.

Não porque o código “apodrece”.

Porque os dados crescem.

Agora imagine coisa pior.

Dentro do loop existe outro acesso:

PERFORM PARA-CADA-CLIENTE
    PERFORM PROCURA-MOVIMENTO
END-PERFORM.

E PROCURA-MOVIMENTO faz uma busca ineficiente.

Talvez você tenha construído algo próximo de:

para cada cliente
    procurar em muitos registros

Com base pequena, aceitável.

Com base enorme, desastre.

Essa é a diferença entre:

funciona

escala.

Sr. Miyagi diria:

— Programa que vence teste com mil registros ainda não venceu produção com quarenta milhões.

🗄️ 7. Db2: onde uma linha aparentemente inocente pode virar um incêndio

Agora chegamos ao dojo subterrâneo.

SQL.

Um SQL pode continuar retornando exatamente os mesmos dados, mas consumir muito mais recursos.

Imagine:

SELECT NOME,
       SALDO
FROM CLIENTE
WHERE CPF = :WS-CPF

Ontem o Db2 usava um índice maravilhoso.

Hoje, por alguma mudança de estatística, cardinalidade, distribuição, acesso, manutenção ou desenho, o access path mudou.

Agora ele faz algo muito mais caro.

Uma consulta que custava pouco passa a custar cinco vezes mais CPU.

Uma execução?

Talvez ninguém perceba.

Agora multiplique por:

3.000.000 execuções por dia

A diferença aparece.

E muitas vezes ninguém associa a mudança imediatamente ao custo.

O programa entrou em produção em março.

A conta assustou em junho.

Finanças pergunta em agosto.

Desenvolvimento diz:

— Mas essa alteração foi meses atrás.

Exatamente.

O mainframe tem excelente memória.

Inclusive para as coisas que você gostaria que ele esquecesse.

📚 8. SMF: o livro-caixa secreto do reino

Se você é iniciante, guarde essa sigla:

SMF — System Management Facilities.

Não precisa decorar todos os record types agora.

Mas entenda o conceito.

O z/OS registra uma quantidade fantástica de informações sobre o que acontece no sistema.

Jobs.

Steps.

CPU.

I/O.

Workloads.

Subsistemas.

Consumo.

Horários.

Recursos.

Imagine o SMF como um gigantesco livro de bordo.

O CFO pergunta:

— Quem gastou?

Você não deveria responder:

— Produção.

Isso é o equivalente tecnológico de dizer:

— Foi alguém.

O objetivo é chegar perto disto:

LPAR PROD1
↓
service class X
↓
JOB ABC123
↓
STEP040
↓
programa COB987
↓
package Db2 XYZ
↓
SQL statement específico
↓
execuções aumentaram 300%

Agora temos investigação.

Não opinião.

O dashboard diz:

CPU aumentou.

O SMF ajuda a perguntar:

quem
quando
quanto
onde
por quê

Um mostra a fumaça.

O outro ajuda a encontrar o fósforo.

📈 9. RMF: enxergando a máquina respirando

Outro amigo importante:

RMF — Resource Measurement Facility.

Enquanto SMF oferece registros fundamentais para análise, RMF ajuda profundamente na observação e análise de recursos e performance do ambiente.

Pense assim:

SMF é o livro contábil.

RMF é o estetoscópio.

Você observa:

CPU
LPAR
workload
storage
I/O
delay
utilização

E começa a compreender se o sistema está saudável, pressionado, desequilibrado ou simplesmente executando o que deveria.

🧙 10. WLM: o mestre de cerimônias

Agora entra outro personagem:

WLM — Workload Manager.

O WLM é uma das ideias mais bonitas do z/OS.

Ele não pensa simplesmente:

“todo processo merece CPU igual.”

Ele trabalha com objetivos, importância e classes de serviço.

Porque no mundo real:

transação de cliente

não tem necessariamente a mesma prioridade que:

relatório interno

Um batch pode esperar.

Uma transação bancária olhando para um cliente na tela talvez não possa.

Então WLM ajuda o sistema a responder:

qual workload importa mais?
qual objetivo precisa ser atendido?
quem está atrasado?
como distribuir recursos?
existe pressão?
existem políticas de capacidade?

O iniciante vê CPU.

O WLM vê serviço.

Isso é uma mudança mental importantíssima.

🚀 11. zIIP: nem todo ciclo custa igual

Outro easter egg fundamental para quem está entrando no mundo IBM Z:

zIIP.

Certos tipos de trabalho podem ser elegíveis para execução em processadores especializados.

Isso muda completamente uma análise econômica.

Imagine:

Mês A
CP   = 70
zIIP = 40

Depois:

Mês B
CP   = 90
zIIP = 42

Você pergunta:

— Por que CP cresceu tanto?

Talvez o volume tenha mudado.

Talvez a arquitetura tenha mudado.

Talvez workload antes elegível esteja se comportando de outra maneira.

Talvez exista spillover.

Talvez haja configuração ou concorrência envolvida.

A pergunta correta deixa de ser:

“Quanto CPU usamos?”

e passa a ser:

“Onde o trabalho está sendo executado e qual é a implicação econômica disso?”

Isso é pensamento mainframe maduro.

📱 12. O aplicativo móvel que transformou uma transação em dez

Agora vem uma armadilha moderna.

O banco diz:

— Crescemos apenas 8% em clientes.

Então alguém conclui:

— CPU deveria crescer 8%.

Errado.

Imagine o aplicativo antigo.

Cliente abre o sistema.

Faz:

login
consulta saldo
logout

Três eventos relevantes.

Agora o aplicativo novo abre e dispara silenciosamente:

saldo
limite
PIX
cartões
investimentos
ofertas
notificações
score
extrato
financiamentos

O usuário fez uma ação.

O backend recebeu dez.

O negócio cresceu 8%.

A atividade computacional talvez tenha crescido 40%.

Isso é o que podemos chamar de:

amplificação digital.

A aplicação moderna fica mais bonita.

A UX fica mais rica.

O cliente vê tudo numa tela.

O mainframe recebe uma pequena chuva de APIs.

E depois alguém pergunta por que aumentou o consumo.

🧮 13. Pare de contar apenas transações

Outra lição.

Nem toda transação vale a mesma coisa.

Imagine:

consulta simples VSAM

PIX com antifraude, auditoria, MQ, Db2 e logging

Ambas podem aparecer em algum relatório como:

1 transação

Mas economicamente são bichos diferentes.

Por isso uma organização madura começa a medir:

CPU por 1.000 transações
CPU por PIX
CPU por consulta
CPU por cliente ativo
Db2 CPU por chamada
batch CPU por conta

Essa ideia é poderosa porque aproxima TI do negócio.

Agora o CFO consegue entender.

Em vez de:

— Gastamos 140 MSU.

Você diz:

— O custo computacional por mil transações caiu 6%.

Isso é música para finanças.

💰 14. Nasce o Mainframe Unit Economics

Aqui está uma forma muito boa de pensar.

Crie indicadores como:

CPU segundos / 1.000 transações
MSU / milhão de operações
custo / cliente ativo
custo / PIX
custo / conta processada

Agora compare ao longo do tempo:

          JAN   FEV   MAR   ABR

Volume    100   103   106   108
CPU       100   104   116   130
CPU/txn   100   101   109   120

Veja março.

Alguma coisa aconteceu.

Pergunta Mr. Miyagi:

— O que mudou entre fevereiro e março?

Essa pergunta talvez encontre:

novo release;
novo relatório;
access path Db2 ruim;
logging excessivo;
API nova;
antifraude;
rotina duplicada;
batch movido;
volume inesperado;
reprocessamento.

Agora você tem um método investigativo.

📉 15. Custo médio é bom. Custo marginal é melhor.

Existe uma pergunta ainda mais sofisticada:

Quanto custa processar o próximo crescimento do negócio?

Matematicamente:

Δ custo
───────
Δ volume

Imagine:

negócio +10%
consumo +10%

Normal.

Agora:

negócio +10%
consumo +25%

Alerta.

Por outro lado:

negócio +10%
consumo +4%

Talvez você esteja ganhando escala.

Isso é lindo porque destrói outro mito:

“Conta maior significa sistema pior.”

Não.

Você pode gastar mais dinheiro e ficar mais eficiente.

Exemplo:

transações +20%
custo +5%

A conta aumentou.

Mas o custo por transação caiu brutalmente.

O CFO precisa enxergar isso.

⚖️ 16. Nem todo consumo é desperdício

Essa talvez seja uma das lições mais importantes deste artigo.

Existem pelo menos três categorias de crescimento.

1. Consumo necessário

O negócio cresceu.

Mais clientes.

Mais transações.

Mais contas.

Mais pagamentos.

Naturalmente o mainframe trabalha mais.

2. Consumo deliberado

Você adicionou:

antifraude
criptografia
auditoria
compliance
observabilidade
novas funcionalidades

Tudo isso custa CPU.

Mas gera valor.

3. Consumo evitável

Aqui mora o desperdício:

loop desnecessário
SQL ruim
leitura redundante
job duplicado
reprocessamento
programa órfão
batch mal agendado
consulta desnecessária

A missão não é:

reduzir CPU a qualquer custo.

A missão é:

reduzir consumo que não produz valor.

Porque você também pode destruir performance tentando economizar demais.

O sistema economiza 3%.

O cliente passa a esperar.

O SLA vai embora.

Parabéns.

Você economizou CPU e perdeu negócio.

Mr. Miyagi bate com a régua no terminal.

— Não economizar assim.

🧟 17. O job zumbi

Todo ambiente antigo tem algum.

Ninguém sabe quem criou.

Ninguém sabe quem usa.

Executa todo domingo às 03h17.

Nome:

BCHX8712

Comentário:

//* PROCESSO ESPECIAL

Especial para quem?

Mistério.

Tentaram desligar uma vez em 2007.

Alguém telefonou reclamando.

Desde então ninguém mexe.

Esse é o famoso:

job zumbi.

Ambientes mainframe grandes acumulam processos por décadas.

Migrações.

Fusões.

Mudanças regulatórias.

Aplicações substituídas.

Relatórios que ninguém lê.

Interfaces abandonadas.

Por isso um dos melhores projetos de otimização pode não envolver performance.

Pode envolver coragem.

Pergunta:

Quem consome a saída deste job?

Se ninguém souber, não desligue no impulso.

Investigue.

Rastreie.

Valide dependências.

Teste.

Desative controladamente.

Mainframe não gosta de heroísmo sem evidência.

🔍 18. Passo a passo para o jovem programador

Se você está começando agora, siga esta sequência.

Passo 1 — descubra o que seu programa realmente faz

Não leia apenas COBOL.

Entenda:

entrada
processamento
arquivos
Db2
VSAM
MQ
CICS
chamadas externas
saída

Passo 2 — descubra o volume

Pergunte:

Quantas execuções?
Quantos registros?
Quantas transações?
Qual crescimento mensal?

Passo 3 — observe o custo por unidade

Não pense apenas:

programa gastou 200 CPU seconds

Pergunte:

200 CPU seconds para quantos registros?

Passo 4 — procure regressões

Compare versões.

Antes:

10 ms por transação

Depois:

18 ms

Alguma coisa mudou.

Passo 5 — veja SQL

Se usa Db2:

qual access path?
qual frequência?
quantas rows examinadas?
quantas retornadas?

Passo 6 — olhe scheduling

Seu job executa quando?

Ele compete com quem?

Existe motivo?

Passo 7 — pergunte sobre WLM

Qual service class?

Qual prioridade?

Qual objetivo?

Passo 8 — correlacione com negócio

Essa aplicação atende:

PIX?
cartões?
clientes?
folha?
fraude?

Passo 9 — documente

Porque seis meses depois alguém perguntará.

E talvez esse alguém seja você.

🕵️ 19. Um exemplo completo

O CFO diz:

— Conta de mainframe subiu 30%.

O time investiga.

Descobre:

crescimento normal do negócio      +8%
novo antifraude                    +5%
nova observabilidade               +3%
SQL regressivo                     +7%
batch concentrado em pico          +4%
processo duplicado                 +2%
outros                             +1%
                                  ----
                                   30%

Agora a conversa mudou.

Dos 30%:

16% = crescimento + capacidade nova
13% = problemas investigáveis/otimizáveis
1%  = ainda desconhecido

Isso é infinitamente melhor do que:

— Mainframe ficou caro.

Agora temos ações.

SQL regressivo?

Corrigir.

Batch?

Reagendar se fizer sentido no modelo econômico.

Processo duplicado?

Eliminar.

Antifraude?

Manter.

Porque aquilo protege o banco.

🧩 20. Easter egg para quem chegou até aqui

Existe uma velha tendência em computação de tentar transformar tudo numa métrica simples.

MIPS.

CPU.

TPS.

latência.

custo.

Mas sistemas complexos odeiam métricas isoladas.

É quase um princípio de Douglas Adams aplicado ao datacenter:

A resposta pode ser 42. O problema é descobrir qual era a pergunta.

Se alguém chegar na reunião dizendo:

— O sistema usa 12.000 MIPS.

A pergunta correta é:

— E daí?

12.000 MIPS pode ser excelente.

Pode ser horrível.

Pode ser barato.

Pode ser caro.

Pode estar processando milhões de transações com eficiência fantástica.

Ou pode estar queimando CPU lendo o mesmo arquivo quinze vezes.

A métrica sem contexto é apenas um número muito bem vestido.

🥋 21. A última lição do dojo

O jovem programador começa querendo aprender:

MOVE
PERFORM
IF
EVALUATE
READ
WRITE
CALL

Depois aprende:

JCL
VSAM
Db2
CICS

Depois entende:

SMF
RMF
WLM
R4HA
zIIP
pricing
capacity

E então acontece uma mudança interessante.

Ele deixa de pensar:

“Meu programa funciona?”

E começa a perguntar:

“Meu programa funciona bem dentro do sistema?”

Depois:

“Meu sistema usa recursos de maneira eficiente?”

E finalmente:

“O custo computacional produzido por esse workload faz sentido para o negócio?”

Nesse ponto você deixou de ser apenas programador COBOL.

Começou a pensar como engenheiro de plataforma.

☕ Epílogo — O CFO, o COBOL e a conta de luz

Voltemos à primeira cena.

Sala de reunião.

CFO na ponta da mesa.

Gráfico na tela.

Ele pergunta:

— Por que o custo do mainframe subiu 30% se o negócio cresceu 8%?

Silêncio.

Antigamente alguém responderia:

— Houve aumento de capacidade.

Hoje uma equipe madura deveria responder:

— Dos 30 pontos, oito correspondem ao crescimento do negócio. Cinco vieram do antifraude novo. Três da observabilidade. Sete são uma regressão Db2 já identificada. Quatro vieram de concentração de workloads numa janela economicamente desfavorável. Dois correspondem a processos redundantes em eliminação. Um ainda estamos investigando.

Agora o CFO entende.

E o mais importante:

confia.

Porque ninguém está defendendo mainframe com religião.

Está defendendo com dados.

Essa é talvez a grande diferença entre o velho discurso:

“Mainframe é caro, mas confiável.”

e o discurso moderno:

“Eu sei exatamente quanto custa, quem consome, por que consome e o que recebemos em troca.”

No fundo, MIPS e MSU não são apenas unidades técnicas.

São pistas.

SMF é a cena do crime.

RMF é o perito.

WLM organiza o trânsito.

Db2 às vezes é o suspeito.

O batch jura inocência.

O COBOL diz que só cumpriu ordens.

O CFO quer saber quem vai pagar.

E em algum canto escuro do datacenter existe um job de 1997 executando toda terça-feira às 02h13 porque alguém escreveu no JCL:

//* NAO REMOVER

Ninguém sabe quem.

Ninguém sabe por quê.

Mas ele continua lá.

Consumindo CPU.

Silenciosamente.

À espera de um jovem gafanhoto suficientemente curioso para perguntar:

— Mestre… isto ainda serve para alguma coisa?

E o Sr. Miyagi do mainframe sorri.

Porque finalmente você fez a pergunta certa.

https://eljefemidnightlunch.blogspot.com/2026/02/o-caso-dos-mips-que-cresceram-tres.html

https://eljefemidnightlunch.blogspot.com/2026/08/o-leilao-reverso-do-conhecimento-quando.html

https://eljefemidnightlunch.blogspot.com/2026/05/o-segredo-sujo-da-performance-no.html

https://eljefemidnightlunch.blogspot.com/2026/05/o-mainframe-nao-esta-lento-seu-sql-e.html

https://eljefemidnightlunch.blogspot.com/2026/03/bellacosa-mainframe-simulator-mainframe.html

Translate

sexta-feira, 6 de dezembro de 2024