Bellacosa Mainframe explorando address spaces & tasks

☕ O Segredo Mais Importante do z/OS Que Quase Ninguém Explica: Address Spaces & Tasks (O “Multiverso” do Mainframe)

🧙‍♂️ Padawan, aproxime-se.
Se você entender profundamente Address Spaces e Tasks, você atravessa a porta de entrada do mundo Sysprog. Sem isso, z/OS parece magia. Com isso, vira engenharia.

Pegue seu café. Vamos abrir o capô do mainframe. ☕

---

🌌 Capítulo 1 — O z/OS Não Executa Programas. Executa Universos.

Em um PC comum você pensa:

“Vou rodar um programa.”

No z/OS, o raciocínio é outro:

⭐ “Vou criar um ambiente isolado onde programas poderão existir.”

Esse ambiente é o:

🏢 Address Space

Ele contém:

• Memória virtual privada
• Identidade de segurança
• Recursos
• Estruturas de controle
• Tasks (unidades de execução)
• Programas rodando

👉 Tudo roda dentro de um address space.

Exceto funções internas do kernel — e isso é assunto para um Jedi Master.

---

🔎 Como ver o “multiverso” ao vivo

Abra o SDSF:

SDSF → DA

Cada linha é um universo independente:

• MASTER
• JES2
• TCPIP
• IBMUSER
• CICS
• Jobs batch
• Processos UNIX

Um sistema real pode ter centenas.

🥚 Easter Egg #1:
O MASTER é sempre ASID 1.
Se ele cair… você tem problemas maiores do que um dump.

---

🔒 Capítulo 2 — O Isolamento Que Salvou o Mainframe

Cada address space tem memória privada.

Um programa em A NÃO pode acessar a memória de B.

Isso evita:

• Corrupção entre aplicações
• Vazamento de dados
• Quedas sistêmicas
• Caos total

🧠 Mas há um truque genial…

Cada espaço acha que possui toda a memória.

Sim. Toda.

---

🧭 Virtual Memory — A Ilusão Controlada

Dois programas podem usar o mesmo endereço:

x'2795'

E acessar memórias físicas diferentes.

Isso ocorre graças à:

⭐ DAT — Dynamic Address Translation

Virtual → Page Tables → Real Memory

👉 Daí o nome Address Space.

Cada universo tem seus próprios endereços.

---

🤝 Compartilhamento? Só com permissão

Quando necessário:

• Common Storage (CSA/ECSA)
• Cross-memory services
• Program Call
• Serviços autorizados

Exemplo clássico:

CICS falando com DB2.

---

🧵 Capítulo 3 — Dentro do Universo: Tasks

Um address space sozinho não executa nada.

Quem executa são:

🧵 Tasks (TCBs ou SRBs)

⭐ Task = menor unidade despachável

O dispatcher agenda tasks nos CPUs.

---

⚡ Paralelismo real

Se houver 10 CPUs → até 10 tasks executando simultaneamente.

Mas…

🥚 Easter Egg #2:
A maioria das tasks está esperando algo — não executando.

Porque sistemas corporativos são I/O-bound.

---

⏳ Estados típicos

🟢 Running

No CPU agora

🟡 Ready

Quer CPU, mas aguarda

🔴 Waiting

Esperando evento:

• I/O
• Lock
• Resposta externa
• Timer
• Memória

---

📦 Uma task pode executar vários programas

Mas:

❗ Apenas um por vez

Exemplo COBOL clássico:

MAIN
  CALL VALIDATE
  CALL CALCULATE
  CALL UPDATE
  CALL PRINT
STOP RUN

Tudo na mesma task.

---

⚙️ Quer paralelismo? Crie novas tasks.

ATTACH → nova TCB

Exemplo batch paralelo:

Task A → Arquivo1
Task B → Arquivo2
Task C → Arquivo3

---

🐧 Padawans vindos do UNIX

Boa analogia:

z/OS	UNIX
Address Space	Process
Task (TCB)	Thread

E sim:

⭐ Cada thread USS é uma task.

---

👑 Capítulo 4 — A Task Raiz: RCT

Quando um address space nasce:

1. Cria-se a Region Control Task (RCT)
2. Outras tasks são iniciadas
3. Programas executam nelas

Hierarquia:

Address Space
   └── RCT
         ├── Task A
         └── Task B

🥚 Easter Egg #3:
Se a RCT terminar… o address space inteiro termina.

Sem órfãos. Sem bagunça.

---

⚡ Capítulo 5 — O Primo Ninja: SRB

Existem dois tipos de tasks:

🧵 TCB — normal

Aplicações, batch, TSO, etc.

⚡ SRB — especial

Serviços do sistema.

Diferenças fundamentais:

TCB	SRB
Pode esperar	Geralmente não
Longo prazo	Curto
Local	Pode ser cross-memory
Aplicações	Sistema

SRBs são criados via:

SCHEDULE

Não automaticamente.

---

🧠 Capítulo 6 — Memória Compartilhada entre Tasks

Dentro do mesmo address space:

👉 Tasks compartilham memória.

Isso permite cooperação rápida.

Mas também risco.

Programas autorizados podem proteger áreas — aplicações comuns raramente fazem isso.

---

🏛️ Capítulo 7 — Como Address Spaces Nascem

Criados quando surge um workload independente:

• IPL do sistema
• START de serviço
• Logon TSO
• Job batch selecionado pelo JES
• Processo UNIX iniciado

❌ NÃO quando:

• Um programa começa
• Um comando TSO é digitado
• Uma subrotina é chamada

🥚 Easter Egg #4:
Criar address space é caro. z/OS evita fazer isso sem necessidade.

---

🧾 Capítulo 8 — ASCB, ASID e Jobname

Cada address space é registrado por um:

⭐ ASCB — Address Space Control Block

Contém:

• ASID (ID interno)
• Jobname (nome visível)
• Ponteiros para TCBs
• Estado
• Dados de gerenciamento

Operador vê:

👉 JOBNAME

Sistema usa:

👉 ASID

---

👨‍💼 Capítulo 9 — Administração na Vida Real

Operadores controlam address spaces, não tasks.

Comandos típicos:

S TCPIP
P CICS
C JOB123
F JES2,QUIESCE

Tasks só entram em cena quando algo dá errado.

---

💥 Capítulo 10 — Por Que Isso Faz o Mainframe Ser o Mainframe

Essa arquitetura permite:

✔ Escalabilidade massiva
✔ Isolamento forte
✔ Alta disponibilidade
✔ Throughput absurdo
✔ Recuperação controlada
✔ Multi-tenant seguro

---

🏆 O Insight Jedi

🏢 Address Space = Ambiente

🧵 Task = Execução

💻 Program = Código executado

Ou, no idioma Bellacosa:

“O z/OS não roda programas.
Ele mantém universos onde programas vivem.”

---

☕ Missão do Padawan

Se você entendeu este artigo, já ultrapassou 80% dos iniciantes em mainframe.

O próximo passo é dominar:

• Dispatching e WLM
• Storage Manager
• JES internals
• Subsystems architecture
• Dump analysis

---

💬 Último conselho

🧙‍♂️ “Quem entende Address Spaces e Tasks não apenas usa o z/OS… começa a pensar como ele.”

 

 

Bellacosa Mainframe explica os 31 bits de endereçamento de memoria no IBM MVS

🔥 “31 Bits?! O Bug que Virou Arquitetura: o Segredo Oculto do MVS que Quase Quebrou o Mainframe (e Salvou Tudo)”

Se você chegou até aqui, jovem padawan do aço e silício… prepare-se: essa não é só uma história técnica — é um daqueles momentos em que uma limitação virou genialidade.

Hoje você vai entender por que o MVS roda em 31 bits, mesmo em um mundo que já flertava com 32 bits — e como isso se conecta diretamente com compatibilidade, performance e… um bit que virou lenda. 🧠⚡

---

🧠 O Contexto: Quando 32 bits Ainda Era Ficção Científica Prática

Voltamos para os anos 70/80, época do OS/360 e da evolução para o MVS.

Naquele tempo:

• 24 bits era o padrão (endereçamento até 16 MB 😱)
• A IBM precisava evoluir
• Mas não podia quebrar NADA do que já existia

💡 Tradução Bellacosa:

“Evoluir sem quebrar legado — o esporte olímpico do mainframe.”

---

⚙️ A Chegada dos 32 bits… com um Plot Twist

Quando a IBM decidiu expandir para 32 bits, veio o dilema:

👉 Como crescer sem destruir milhares de aplicações escritas para 24 bits?

A solução foi engenhosa e ousada:

➡️ Usar apenas 31 bits para endereço
➡️ E reservar 1 bit para controle

---

💥 O Bit 0: O Verdadeiro Protagonista

Aqui entra o easter egg mais clássico do mundo mainframe:

O bit mais significativo (bit 0) foi separado para indicar o modo de endereçamento.

📌 Resultado:

Bit 0	Significado
0	Endereço válido (modo 31 bits)
1	Controle especial (ex: retorno de subrotina)

💡 Isso permitia:

• Misturar código 24 bits com 31 bits
• Manter compatibilidade TOTAL
• Evitar crashes catastróficos

---

🧬 O Nascimento do “Modo 31”

O MVS passou a operar em algo híbrido:

• 24-bit mode (legado)
• 31-bit mode (expansão)

E isso foi formalizado em arquiteturas como:

👉 System/370-XA

---

🎮 Exemplo Prático (Estilo Raiz)

Imagine um programa chamando uma subrotina:

BALR  R14,R15

O endereço de retorno fica no registrador com o bit 0 ligado (1).

🔍 Isso significa:

“Ei! Isso não é um endereço comum — é um ponteiro de controle!”

🔥 Resultado:

• O sistema sabe diferenciar código de controle
• Evita confusão com endereços reais
• Permite transições seguras entre modos

---

🧪 Analogias para Padawans

Pense assim:

O MVS usa 31 bits como endereço e guarda o último bit como se fosse um "selo VIP" no ingresso 🎟️

• Sem selo → endereço normal
• Com selo → instrução especial

---

🧠 Por que isso foi GENIAL?

Porque resolveu 3 problemas gigantes de uma vez:

1. 🛡️ Compatibilidade absoluta

Programas antigos continuaram funcionando.

2. 🚀 Expansão de memória

Sai de 16 MB → até 2 GB

3. 🧩 Controle inteligente

O sistema ganhou uma forma de distinguir contextos sem custo extra

---

🐣 Easter Egg que poucos contam

Muitos bugs clássicos em assembler vinham de:

👉 esquecer de limpar o bit 0

Resultado?

💥 Endereço inválido
💥 S0C4 (proteção)
💥 Caos existencial do operador

---

⚡ Comentário Bellacosa Mainframe

Se você acha isso gambiarra…

💬 “No mundo distribuído, isso seria um workaround.
No mainframe… virou ARQUITETURA OFICIAL.”

E mais:

👉 Essa decisão influenciou diretamente o caminho até o 64 bits no z/Architecture

---

🚀 Moral da História

O MVS não é 31 bits por limitação.

Ele é 31 bits por estratégia, elegância e sobrevivência.

Às vezes, a melhor inovação não é avançar tudo…
é avançar sem quebrar nada.

---

🔥 TL;DR para o Padawan Apressado

• MVS usou 31 bits para endereço
• 1 bit virou controle (bit 0)
• Garantiu compatibilidade com 24 bits
• Evitou reescrever o mundo inteiro
• Criou um dos hacks mais elegantes da história da computação 

 

Bellacosa Mainframe explica o endereçamento de memoria no IBM Mainframe 24 31 e 64 bits

📊 “Da Era dos 16MB ao Infinito: A Linha do Tempo que Explica 24 → 31 → 64 bits no Mainframe”

Prepare-se, padawan… agora você vai enxergar a evolução do mainframe como um verdadeiro mapa de poder computacional — cada salto não foi só técnico… foi uma jogada estratégica digna de xadrez. ♟️

---

🟢 1. Era 24 bits — O Mundo Cabia em 16MB

🔹 Contexto

• Arquitetura do OS/360
• Endereçamento: 24 bits
• Limite: 16 MB

🧠 O que isso significava?

• Tudo precisava caber em um espaço minúsculo
• Programas eram ultra otimizados
• Overlays eram comuns (carregar partes do programa sob demanda)

💬 Bellacosa insight:

“Aqui nasceu o DNA da eficiência — cada byte valia ouro.”

---

🟡 2. Era 31 bits — O Hack Mais Elegante da História

🔹 Contexto

• Evolução para o MVS
• Introdução da System/370-XA

⚙️ O que mudou?

• Endereçamento: 31 bits (não 32!)
• Limite: 2 GB
• 1 bit reservado (bit 0) para controle

🔥 O pulo do gato:

• Compatibilidade TOTAL com 24 bits
• Mistura de modos (24 + 31)
• Controle inteligente via bit mais significativo

🧪 Conceito-chave:

O endereço não é só endereço — ele carrega “intenção”

💬 Bellacosa insight:

“Enquanto o mundo queria mais bits… o mainframe queria mais inteligência.”

---

🔵 3. Era 64 bits — O Universo Expandido

🔹 Contexto

• Arquitetura moderna: z/Architecture
• Sistemas como z/OS

🚀 O que mudou?

• Endereçamento: 64 bits
• Limite teórico: exabytes
• Espaço virtual gigantesco

🧠 Novos conceitos:

• Above the bar / below the bar
• Memory objects
• Large memory exploitation

💬 Bellacosa insight:

“Agora não é mais sobre caber… é sobre escalar sem limites.”

---

📊 Timeline Simplificada (Estilo Raiz)

1970s  ───────────────► 24 bits (16 MB)
          OS/360

1980s  ───────────────► 31 bits (2 GB)
          MVS / System/370-XA
          (bit 0 reservado 👀)

2000+  ───────────────► 64 bits (exabytes)
          z/Architecture / z/OS

---

🧬 Conexão Evolutiva (O Segredo por Trás)

Era	Problema	Solução	Filosofia
24 bits	Memória limitada	Otimização extrema	“Faça caber”
31 bits	Crescer sem quebrar	Bit de controle	“Evolua com legado”
64 bits	Escalabilidade	Espaço massivo	“Expanda sem limites”

---

🐣 Easter Egg de Mestre

Mesmo no mundo 64 bits…

👉 O conceito de “compatibilidade com legado” continua vivo
👉 E o espírito do bit 0 ainda ecoa nas decisões de design

💥 Ou seja:

O passado do mainframe nunca foi descartado — ele foi incorporado

---

⚡ Fechamento Estilo Bellacosa

Se você entendeu essa timeline, você desbloqueou algo raro:

🧠 Você não vê mais bits… você vê decisões arquiteturais

Porque no mainframe:

Cada bit tem história
Cada limitação vira estratégia
E cada evolução respeita o passado

 

 

Bellacosa Mainframe apresenta a biblioteca matematica do Python

🔥 NumPy: O “PACKED DECIMAL” do Python que Vai Explodir sua Cabeça COBOL

Se você veio do mundo COBOL, onde cada byte importa, cada campo tem propósito e cada processamento precisa ser eficiente… então prepare-se: você está prestes a conhecer o coração matemático do Python — a biblioteca NumPy.

E sim… ela é MUITO mais próxima do seu mundo do que você imagina.

---

☕ O choque de realidade: Python puro vs processamento “mainframe-like”

No COBOL, você já sabe:

• COMPUTE é rápido
• PERFORM VARYING é controlado
• Estruturas são previsíveis

Agora veja isso no Python “cru”:

lista = [1, 2, 3, 4]
resultado = [x * 2 for x in lista]

Funciona… mas não é exatamente eficiente nível mainframe, certo?

Agora entra o NumPy:

import numpy as np

array = np.array([1, 2, 3, 4])
resultado = array * 2

💥 BOOM.

Você acabou de fazer processamento vetorial, algo muito mais próximo de um:

“loop implícito otimizado em assembler por baixo dos panos”

Sim… isso cheira a z/Architecture.

---

🧠 Origem: quando cientistas reinventaram o “processamento batch”

O NumPy nasceu oficialmente em 2006, mas sua raiz vem de duas bibliotecas:

• Numeric
• Numarray

Ambas criadas para resolver um problema clássico:

“Python era bom… mas lento para matemática pesada”

A fusão virou NumPy — e trouxe um conceito poderoso:

👉 Arrays homogêneos de alta performance

Se você pensa em:

• tabelas VSAM
• buffers de memória
• áreas de trabalho

Você já entendeu metade do NumPy.

---

⚙️ O conceito que muda tudo: ndarray

O coração do NumPy é o ndarray (N-dimensional array).

Pense nisso como:

COBOL	NumPy
OCCURS	array
PIC 9(5)V99	dtype=float64
Tabela indexada	ndarray
Área contígua memória	buffer otimizado

Exemplo:

import numpy as np

dados = np.array([10, 20, 30])
print(dados * 2)

Saída:

[20 40 60]

Sem loop explícito. Sem PERFORM.

👉 Isso é chamado de vectorization.

---

🚀 Performance: aqui mora o espírito do mainframe

NumPy é rápido porque:

• Escrito em C (baixo nível)
• Usa operações vetorizadas
• Evita overhead de loops Python

📌 Tradução para o mundo COBOL:

“Você está rodando um SORT interno com exit em assembler… sem escrever assembler.”

---

🔍 Curiosidades que todo coboleiro vai amar

🧩 1. NumPy evita loops como você evita GO TO

Loops em Python são lentos.

NumPy resolve isso com operações vetoriais:

a = np.array([1,2,3])
b = np.array([4,5,6])

print(a + b)

Resultado:

[5 7 9]

👉 Isso é equivalente a um loop automático altamente otimizado.

---

🧠 2. Broadcasting: o PERFORM invisível

a = np.array([1,2,3])
print(a + 10)

Resultado:

[11 12 13]

Sem loop. Sem stress.

👉 O NumPy “espalha” o valor automaticamente.

---

🏎️ 3. Memória contígua = performance absurda

Diferente de listas Python, NumPy usa:

• memória contínua
• tipos fixos

👉 Isso lembra:

• buffers de I/O
• áreas de WORKING-STORAGE bem definidas

---

🧪 Exemplos práticos (modo COBOL mindset ON)

📊 Soma de um dataset

COBOL:

PERFORM VARYING I FROM 1 BY 1 UNTIL I > 100
   ADD VALOR(I) TO TOTAL
END-PERFORM

NumPy:

np.sum(array)

💥 1 linha. Otimizado. Vetorizado.

---

📈 Média (sem reinventar roda)

np.mean(array)

👉 Nada de controle manual. Nada de variáveis acumuladoras.

---

🔄 Transformação em massa

array * 1.15

👉 Isso é literalmente um:

“REDEFINES aplicado em lote com COMPUTE automático”

---

🧠 Easter Eggs e detalhes escondidos

🥚 1. O tipo float64 é padrão

👉 Isso significa precisão alta — quase como trabalhar com campos bem definidos no COBOL financeiro.

---

🥚 2. Você pode acessar o “layout de memória”

array.strides

👉 Sim… você pode ver como os dados estão distribuídos na memória.

Isso é nível:

“debug de storage layout no mainframe”

---

🥚 3. NumPy conversa com C diretamente

👉 Isso permite integrar com código de baixo nível.

Ou seja:

Python vira quase um “COBOL com superpoderes científicos”

---

⚔️ NumPy vs Python puro (visão mainframe)

Aspecto	Python puro	NumPy
Performance	Baixa	Altíssima
Tipagem	Dinâmica	Estática (dtype)
Memória	Fragmentada	Contígua
Loop	Manual	Vetorizado
Estilo	Script	Científico / batch-like

---

🌍 Onde isso entra na sua evolução?

Se você domina COBOL, NumPy é uma ponte natural para:

• 📊 Data Science
• 🤖 Machine Learning
• 📈 Analytics de alto volume
• 🧮 Simulações financeiras

E mais importante:

👉 Você não começa do zero
👉 Você reaproveita seu mindset de performance

---

🎯 Conclusão: o despertar do coboleiro moderno

NumPy não é só uma biblioteca.

É uma mudança de paradigma.

É quando você percebe que:

“O Python pode ser tão performático quanto um batch bem escrito — se você usar as ferramentas certas.”

E aqui vai a provocação final:

🔥 Se COBOL é o rei do processamento estruturado…
🔥 NumPy é o motor matemático que pode levar você além do mainframe.

 

Bellacosa Mainframe e o mundo secreto do Storage Mainframe cartridges e o cofre na montanha de ferro

🔥💀 DO CARTÃO PERFURADO AO COFRE NA MONTANHA

“Como seus dados COBOL sobreviveram a guerras, ransomware… e ao tempo”

---

🧨 Introdução (sem mimimi)

Se você escreve COBOL hoje…
existe uma chance enorme de que o dado que você manipula:

• já esteve em um cartão perfurado
• passou por uma fita magnética
• e talvez hoje esteja guardado em um cofre subterrâneo

Sim… isso não é romantização.
Isso é a linha evolutiva real do mainframe.

E no meio dessa história… existe um nome quase lendário:

👉 Iron Mountain

---

🧱 Capítulo 1 — Cartão perfurado: o “INSERT INTO” de 1930

Antes de existir dataset…
antes de existir VSAM…

👉 Existia isso:

• Cartões físicos
• 80 colunas
• Cada furo = dado

---

💀 Tradução Bellacosa:

“Seu SELECT era um buraco no papel”

---

🧠 Curiosidades

• Um programa COBOL inteiro = caixa de cartões
• Derrubar a pilha = ABEND físico real
• Ordenação = literalmente reorganizar papel

---

⚠️ Problema

• Lento
• Frágil
• Não escalável

---

👉 Aí veio a revolução…

---

📼 Capítulo 2 — Tape: o primeiro “Big Data” do mundo

👉 A fita trouxe:

• 📦 Volume massivo
• 🔄 Processamento sequencial
• ⚡ Muito mais velocidade que cartão

---

💀 Tradução:

“Sai o papel… entra o fluxo contínuo”

---

🧠 Como isso impactou o COBOL?

👉 Nasce o modelo que você usa até hoje:

• Arquivo sequencial
• Batch
• Processamento em massa

---

💡 Insight poderoso

👉 Seu COBOL batch moderno…

💀 ainda pensa como fita

---

📦 Capítulo 3 — Cartridge: o “pendrive” do mainframe

• Fita aberta → cartridge fechado
• Mais proteção
• Mais densidade
• Automação

---

📊 Exemplo real

• LTO-9 → 18 TB (nativo)
• Compressão → até 45 TB

---

💀 Tradução:

“Uma fita hoje guarda mais que um datacenter antigo inteiro”

---

🏔️ Capítulo 4 — Iron Mountain: o cofre dos dados do mundo

👉 Agora entra o nível lendário…

A Iron Mountain:

• Guarda dados em minas subterrâneas
• Protegidas contra:
  • fogo
  • guerra
  • desastre
• Usada por:
  • bancos
  • governos
  • Fortune 500

---

💀 Tradução Bellacosa:

“Se tudo der errado… seus dados estão dentro de uma montanha”

---

🚚 Como funciona

1. Backup em fita
2. Fita retirada da library
3. Transporte seguro
4. Armazenamento em cofre

---

🔐 Segurança real

👉 Isso cria o famoso:

AIR GAP físico

---

🧠 Capítulo 5 — Por que fita ainda manda?

---

⚔️ Disk vs Tape (sem romantismo)

Critério	Disk	Tape
Velocidade	⚡	🐢
Custo	💸	💰
Durabilidade	❌	✅
Segurança	⚠️	🔐

---

💀 Verdade dura:

“Disco é rápido… fita é eterna”

---

🧨 Capítulo 6 — Ransomware não perdoa (mas fita sim)

👉 Se o backup estiver online:

💀 Ele será criptografado junto

---

👉 Se estiver em fita offline:

✔️ Intocado
✔️ Recuperável
✔️ Seguro

---

🧠 Capítulo 7 — O que o dev COBOL precisa entender

---

💡 Você NÃO está só escrevendo código

Você está:

• Alimentando sistemas de retenção
• Gerando dados regulatórios
• Criando histórico corporativo

---

🎯 Dicas práticas

👉 Quando pensar em arquivos:

• Sequencial → fita-friendly
• Batch → tape-driven
• Grande volume → tape inevitável

---

👉 Quando pensar em backup:

• Disk → rápido
• Tape → seguro

---

👉 Quando pensar em DR:

💀 “Se não tem fita… não tem garantia”

---

🧨 Curiosidades que ninguém te conta

• CERN usa tape para centenas de PB
• Cloud providers usam tape no backend
• LTO roadmap chega a 576 TB por fita (futuro)

---

💀 Conclusão — A verdade que poucos entendem

👉 O mundo mudou
👉 A tecnologia evoluiu

Mas…

---

💀 A fita nunca morreu

---

Ela só:

• Ficou mais densa
• Mais segura
• Mais invisível

---

🎯 Frase final estilo Bellacosa

“Seu COBOL pode rodar no Z17…
mas a memória da empresa ainda descansa em fita — guardada dentro de uma montanha.”