Bellacosa Mainframe apresenta JCL Job Control Language

☕🔥 JCL & Produção Batch Mainframe — a engenharia silenciosa que move bilhões 

Se você já otimizou STEP para caber na janela, já analisou RC 0004 com cara de 0012, já salvou processamento crítico com um COND= bem colocado, então este texto não é introdutório.
É JCL raiz, técnico, com cheiro de CPD, café requentado e responsabilidade financeira.

---

🕰️ Origem & História — por que o JCL ainda governa o mundo

O JCL (Job Control Language) nasce junto com o conceito de processamento em lote nos grandes centros de dados, quando:

• Processar tudo “online” era inviável

• O custo de CPU precisava ser controlado

• O erro precisava ser detectável, tratável e auditável

Enquanto linguagens vêm e vão, o JCL ficou porque:

• É determinístico

• É declarativo

• É governável

• É auditável

☕ Verdade histórica:

Toda fintech moderna ainda depende de batch — só não admite.

---

🏦 Por que bancos, telecom e gigantes globais usam Mainframe

Empresas que processam milhões de transações críticas exigem:

• Alta disponibilidade (24x7)

• Integridade absoluta

• Escalabilidade previsível

• Segurança nativa

• Throughput sob pico

A Plataforma IBM Mainframe entrega:

• Sysplex

• Parallel Sysplex

• z/OS

• DB2, CICS, MQ

• RACF, SMF, RMF

🔥 El Jefe truth:

Cloud escala. Mainframe sustenta.

---

🧠 JCL não é script — é contrato operacional

JCL define:

• O que roda

• Quando roda

• Com quais recursos

• Com quais dados

• O que acontece se falhar

Ele não executa lógica de negócio.
Ele orquestra o sistema operacional.

📌 Exemplo clássico:

//STEP01 EXEC PGM=PROG01,COND=(4,LT)
//DD01  DD DSN=BASE.DADOS.ENTRADA,DISP=SHR

☕ Comentário ácido:

JCL errado não falha — impacta.

---

⚙️ Funcionamento do Processamento Batch

Fluxo real:

1. Job submetido

2. JES valida sintaxe

3. Initiator seleciona

4. Recursos alocados

5. Programas executam

6. RC avaliados

7. Próximo STEP decide

8. Output gerado

9. SLA confirmado ou perdido

🔥 Veterano sabe:

O problema raramente está no STEP que abendou.

---

🧩 Ecossistema Operacional — as ferramentas de poder

🧑‍💻 TSO — o shell do z/OS

• Execução direta

• Diagnóstico rápido

• REXX, CLIST, comandos

☕ Curiosidade:

Quem domina TSO resolve problema sem ticket.

---

🗂️ ISPF/PDF — produtividade industrial

• Editor poderoso

• Gestão de datasets

• Browse inteligente

• Macros

🔥 Easter egg:

PF7 e PF8 são memória muscular.

---

📊 SDSF — o raio-X da produção

• Jobs

• STCs

• Spool

• Syslog

• Comandos

📌 Uso clássico:

SDSF DA / ST / H

☕ Verdade dura:

SDSF é onde a verdade aparece.

---

🧪 JCL na prática — decisões de veterano

COND vs IF/THEN/ELSE

• COND = simples e perigoso

• IF/THEN = legível e controlável

🔥 Regra de produção:

COND errado roda STEP que não deveria.

---

Alocação de Recursos

• DISP

• SPACE

• UNIT

• VOL

☕ Fofoquice técnica:

DISP=SHR mal usado já derrubou banco.

---

Tratamento de Erros

• RC esperado ≠ sucesso

• RC aceitável ≠ erro

• Abend ≠ falha total

📌 Exemplo:

// IF (STEP01.RC <= 4) THEN

---

🛠️ Utilitários do Sistema — os bastidores

• IEBGENER

• IDCAMS

• SORT / ICETOOL

• IEBCOPY

• DFSORT

🔥 Veterano:

Quem domina utilitário domina batch.

---

🧠 Lógica Estruturada aplicada ao Batch

Mesmo sem “programar”:

• Sequência

• Decisão

• Repetição (simulada)

• Modularização por STEP

☕ Comentário ácido:

JCL ruim é código espaguete sem goto.

---

🧨 Atividades Operacionais & de Análise

Produção batch exige:

• Leitura de mensagens

• Análise de dumps

• Correlação entre jobs

• Impacto em cadeia

• Comunicação com negócio

🔥 Verdade cruel:

Produção não tem replay.

---

🥚 Easter Eggs & Curiosidades do Batch

• Todo ambiente tem um job “imortal”

• Sempre existe um dataset “temporário” de 10 anos

• O maior medo é:

  “Rodou fora da janela…”

• RC 0000 nem sempre é vitória

---

☕🔥 Conclusão — Manifesto El Jefe Batch

JCL não é:

• Legado morto

• Linguagem simples

• Detalhe operacional

JCL é:

• Coluna vertebral do processamento corporativo

• Contrato de execução

• Instrumento de controle de risco

☕🔥 Quem domina JCL,
não escreve jobs —
governa o processamento de dados.

Se quiser, posso:

• Criar labs de produção real

• Montar checklist de análise de jobs

• Criar guia JCL para veteranos

• Produzir versão acadêmica ou institucional

• Montar trilha Batch + JCL + SDSF + RACF

É só chamar.

 

Bellacosa Mainframe e a lei da responsabilidade

☕ Lei da Responsabilidade

ou: quem deu o SUBMIT é dono do JOB

Vou falar em primeira pessoa, porque essa lei eu não aprendi em livro — eu aprendi na marra, entre JCL mal formatado, JOB em ABEND e decisões da vida que também não tinham //SYSOUT=* pra revisar depois.

---

📜 Origem – de onde vem essa lei?

A Lei da Responsabilidade nasce da mesma matriz que:

• o estoicismo (assuma o que depende de você),

• a ética clássica,

• e o famoso “cada ação gera consequência”.

No Japão, ela conversa muito bem com conceitos como giri (dever moral), sekinin (責任 – responsabilidade) e até com o mottainai: não desperdiçar oportunidades nem ações.

No mainframe?
Ela está implícita desde o primeiro dia:

“Quem submeteu o JOB é responsável pelo resultado.”

Simples. Brutal. Justo.

---

🧠 O que essa lei significa?

Significa entender que:

• escolhas têm efeitos,

• omissões também são escolhas,

• e não existe rollback da vida.

Na TI e na vida:

• Se deu certo → mérito.

• Se deu errado → aprendizado (ou ABEND).

Culpar:

• o sistema,

• o colega,

• o tempo,

• o governo,

• Mercúrio retrógrado,

é só uma forma elegante de rodar em WAIT indefinido.

---

🖥️ Tradução Bellacosa Mainframe

• Você escreveu o JCL → você testa.

• Você abriu a regra no RACF → você responde.

• Você fez o DEPLOY sexta à noite → você não some.

Na vida:

• Escolheu o caminho → sustente.

• Falou → arque.

• Prometeu → cumpra.

Responsabilidade é ownership, não culpa.

---

🛠️ Como praticar no dia a dia

• Pare de terceirizar decisões.

• Pare de dizer “não tive escolha”.

• Tenha coragem de dizer: “fui eu”.

Dica prática:

Antes de qualquer decisão, pergunte:
“Eu topo lidar com a consequência disso?”

Se a resposta for não, não submeta o JOB.

---

🥚 Easter eggs & curiosidades

• Em japonês corporativo, assumir erro rápido aumenta confiança, não diminui.

• Em times maduros, quem assume falhas vira referência.

• No mainframe, os melhores profissionais são os que dizem:
  “deixa comigo” — e ficam até resolver.

---

☕ Fofoquices do El Jefe

Já vi muito “senior” desaparecer quando o batch estourou.
E já vi muito “junior” crescer porque ficou até o último IEC999I virar sucesso.

Responsabilidade constrói reputação silenciosamente.

---

🧭 Como entender de verdade

Não confunda responsabilidade com peso.
Ela é liberdade com consciência.

Quando você assume:

• ganha autonomia,

• ganha respeito,

• ganha paz.

---

🌏 Importância para a vida (e para o Japão)

No Japão, responsabilidade mantém:

• confiança social,

• eficiência coletiva,

• harmonia (wa).

Na vida:

• ela te tira do modo vítima,

• te coloca no modo autor da própria história.

---

🧠 Conclusão Bellacosa

A Lei da Responsabilidade é simples:

Você é o operador do seu próprio sistema.
Se der ABEND, analisa, corrige e segue.

Sem drama.
Sem desculpa.
Sem RESET.

☕
E agora me diga…
você anda assumindo seus JOBs ou só reclamando do spool?

Uma tarde passeando por Leiria

Estamos passeando por um parque delicioso, aproveitando as margens deste ribeirão cheio de patinhos, como bom maníaco por fotos. Nao podia deixar de capturar este pequeno momento.

Esta cidade tem muitos encantos a serem descobertos, possui um  castelo, uma antiga fabrica de papel (parece que foi a primeira de Portugal), um parque com aviao militar, roda d'agua e o patinhos. Muitos patinhos nadando tranquilamente pela ribeira.

SMP/E for z/OS Workshop: Restore

Bellacosa Mainframe apresenta SMP/E Restore

SMP/E for z/OS Workshop

RESTORE: quando o Apply deu ruim e você precisa voltar no tempo (sem desligar a produção)

Se APPLY é instalar e ACCEPT é oficializar, RESTORE é o botão de “desfaz” do SMP/E.
Mas não se engane: RESTORE não é CTRL+Z. Ele exige entendimento profundo de dependências, níveis de serviço e do que está no target versus no distribution.

Vamos destrinchar isso no melhor estilo Bellacosa Mainframe: sem romantismo, com realidade de produção.

---

O que é o comando RESTORE no SMP/E?

O RESTORE permite remover um ou mais SYSMODs aplicados no target, reinstalando o nível existente nos DLIBs (distribution libraries) de volta para as target libraries.

📌 Ponto-chave

RESTORE só funciona para SYSMODs que foram APPLIED e ainda NÃO ACCEPTED.

Na prática:

• Algo foi aplicado

• Quebrou, gerou erro, impacto funcional ou regressão

• Você precisa voltar o código para o último nível aceito

RESTORE entra em ação.

---

Onde o RESTORE atua?

RESTORE é sempre direcionado a um Target Zone:

SET BDY(TZONE)

Esse target zone:

• Identifica as target libraries

• Mapeia qual distribution zone (DZONE) contém o backup válido

• Será atualizado com os metadados corretos após o restore

📦 O SMP/E não inventa código
Ele reinstala exatamente o que está nos DLIBs.

---

O que o RESTORE realmente faz?

Durante o processamento, o SMP/E:

✔ Substitui os elementos do target pelos elementos do DLIB
✔ Reexecuta link-edit se necessário
✔ Copia FMID, RMID e UMID do DZONE para o TZONE
✔ Atualiza o CSI
✔ Remove registros do SYSMOD restaurado (dependendo das opções)

Ou seja:

O target volta a refletir o último nível oficialmente aceito.

---

RESTORE vs APPLY – parecem iguais, mas não são

APPLY	RESTORE
Usa SMPPTS	Usa DLIBs
Entrada: Global Zone + SMPPTS	Entrada: DZONE + DLIBs
Instala novo código	Reinstala código anterior
Avança nível	Retrocede nível

👉 Ambos atualizam Target Libraries e Target Zone, mas com propósitos opostos.

---

Inline JCLIN e SMPCDS: o detalhe que derruba gente experiente

Se o SYSMOD a ser restaurado possui inline JCLIN, o SMP/E precisa do SMPCDS.

Por quê?

Porque o SMPCDS contém:

• Backup da estrutura do TZONE

• Informações necessárias para restaurar corretamente macros, source e datasets

Sem isso, o RESTORE pode:

• Falhar

• Ou deixar o ambiente inconsistente

---

O comando RESTORE na prática

Exemplo básico:

RESTORE 
  SELECT(UP00003)

Operandos importantes

🔹 SELECT (obrigatório)

Define quais SYSMODs você quer remover.

---

🔹 GROUP (a parte traiçoeira)

No RESTORE, o GROUP funciona ao contrário do APPLY.

• APPLY: GROUP busca pré-requisitos ausentes

• RESTORE: GROUP busca SYSMODs que DEPENDEM do selecionado

👉 Se um SYSMOD depende do que você quer remover, ele também precisa ser restaurado.

---

🔹 CHECK (sempre use!)

RESTORE CHECK SELECT(UP00003)

CHECK:

• Não altera nada

• Analisa dependências

• Mostra mensagens do tipo GIM35922I

📌 Dica Bellacosa:

Raramente o primeiro RESTORE CHECK resolve tudo.
Rode, leia os relatórios, ajuste o SELECT, rode de novo.

---

Exemplo clássico de dependências (vida real)

Temos 7 PTFs aplicados:

UP00001
 └─ UP00002
     ├─ UP00003
     │   ├─ UP00005
     │   └─ UP00007
     └─ UP00004
         └─ UP00006

Somente UP00001 foi ACCEPTED.

🎯 Objetivo: restaurar UP00003

Pergunta clássica de prova e produção:

Posso restaurar só o UP00003?

❌ Não.

Você também precisa restaurar:

• UP00005

• UP00007

Porque dependem diretamente dele.

---

Onde descobrir isso sem chutar?

1️⃣ Mensagens SMP/E (ex: GIM35922I)
2️⃣ SYSMOD Status Report
3️⃣ CAUSER SYSMOD SUMMARY REPORT ← o mais importante

Esse relatório explica:

• Por que o RESTORE falhou

• Quais SYSMODs estão bloqueando

• O que falta no SELECT

---

O que o SMP/E remove após um RESTORE bem-sucedido?

Se NOREJECT = OFF:

• Remove entrada do SYSMOD no Global Zone

• Remove MCS do SMPPTS

• Remove SMPTLIBs (se existirem)

⚠️ HOLD DATA NÃO É REMOVIDA

Se NOREJECT = ON:

• Remove apenas APPID do Target Zone

---

RESTORE não é simples (e nunca foi)

RESTORE pode se tornar complexo quando:

• Muitos PTFs aplicados

• DLIB muito atrás do Target

• Cadeias longas de dependência

👉 É comum rodar:

RESTORE CHECK
RESTORE CHECK
RESTORE CHECK

Até fechar todo o quebra-cabeça.

---

Conclusão Bellacosa Mainframe

RESTORE é:

• Uma ferramenta poderosa

• Um salva-produção

• Um teste de maturidade do system programmer

Quem domina RESTORE:
✔ Entende dependências
✔ Entende níveis de serviço
✔ Não entra em pânico quando APPLY quebra

APPLY instala. ACCEPT oficializa. RESTORE ensina humildade.

No próximo módulo, o foco sai do SMP/E operacional e entra no product build — onde o código nasce antes de virar SYSMOD.

🔥 PERFORM no COBOL: você manda ou ele manda em você?

 

Bellacosa Mainframe apresenta o comando Perform em COBOL

🔥 PERFORM no COBOL: você manda ou ele manda em você?

(Um café no Bellacosa Mainframe, para padawans e cavaleiros Jedi do z/OS)

Você já deu o spoiler certo: PERFORM é o maestro do COBOL.
Quem domina PERFORM escreve código legível, previsível, auditável e aceito em produção.
Quem não domina… acaba criando um GO TO disfarçado com terno e gravata 😅

Vamos organizar, aprofundar e elevar o nível do que você trouxe — com exemplos reais, pegadinhas, DB2, CICS e dicas de campo.

---

COBOL e o Perform

🧠 Origem e filosofia do PERFORM

Nos anos 70, COBOL sofreu com o “spaghetti code” (muito GO TO).
O PERFORM surgiu como a resposta estruturada, permitindo:

• Modularidade

• Fluxo previsível

• Testabilidade

• Facilidade de manutenção (sim, o auditor agradece)

👉 Regra de ouro mainframe:

“Se dá pra fazer com PERFORM, NÃO use GO TO.”

---

Comando Perform e suas variações em COBOL

1️⃣ PERFORM Simples — chamada limpa e direta

📌 O que faz

Executa um parágrafo uma única vez.

PERFORM 0100-CALCULA-IMPOSTO

🧪 Exemplo real

0100-CALCULA-IMPOSTO.
    COMPUTE WS-IMPOSTO = WS-VALOR * 0.15.
0100-EXIT.
    EXIT.

💡 Dica Bellacosa

• Sempre crie o -EXIT

• Facilita debug, tracing e manutenção futura

---

2️⃣ PERFORM VARYING — o FOR do COBOL

📌 O que faz

Loop com contador explícito.

PERFORM VARYING WS-CONT FROM 1 BY 1
 UNTIL WS-CONT > 10
    PERFORM 0300-PROCESSA-REGISTRO
END-PERFORM

🧪 Exemplo com tabela interna

PERFORM VARYING IDX FROM 1 BY 1
 UNTIL IDX > WS-QTDE
    MOVE WS-TABELA(IDX) TO WS-REG
    PERFORM 0400-VALIDA-DADO
END-PERFORM

⚠️ Pegadinha clássica

❌ Alterar WS-CONT dentro do parágrafo executado
✔️ Deixe o controle só no PERFORM

---

3️⃣ PERFORM UNTIL — o rei da leitura de arquivos

📌 O que faz

Repete até a condição ser verdadeira
(atenção: condição é avaliada antes)

PERFORM UNTIL WS-FIM = 'SIM'
    READ ARQ-ENTRADA
        AT END MOVE 'SIM' TO WS-FIM
        NOT AT END
            PERFORM 0500-PROCESSA-REG
    END-READ
END-PERFORM

🧠 Padrão mainframe clássico

• Batch

• VSAM

• Sequential files

• DB2 cursors (já já)

---

4️⃣ PERFORM TIMES — simples, direto e elegante

📌 O que faz

Executa um bloco N vezes, sem contador explícito.

PERFORM 12 TIMES
    ADD 1 TO WS-TOTAL
END-PERFORM

📌 Quando usar

• Simulações

• Inicializações

• Processos fixos

❌ Quando NÃO usar

• Quando você precisa do índice (use VARYING)

---

5️⃣ PERFORM THRU — tradição mainframe raiz 🧓💾

📌 O que faz

Executa uma sequência contínua de parágrafos

PERFORM 1000-INICIALIZA
   THRU 1099-INICIALIZA-EXIT

🧪 Estrutura clássica

1000-INICIALIZA.
    OPEN INPUT ARQ-ENTRADA
    PERFORM 1100-CARREGA-PARAMETROS.

1099-INICIALIZA-EXIT.
    EXIT.

⚠️ Regra sagrada

Nunca coloque código fora da sequência THRU

Senão…
🔥 comportamento imprevisível
🔥 bugs fantasma
🔥 chamado em produção às 3h da manhã

---

🟦 PERFORM + DB2 (exemplo real)

Cursor com PERFORM UNTIL

PERFORM UNTIL SQLCODE NOT = 0
    EXEC SQL
        FETCH C1 INTO :WS-COL1, :WS-COL2
    END-EXEC

    IF SQLCODE = 0
        PERFORM 2000-PROCESSA-LINHA
    END-IF
END-PERFORM

👉 Padrão de ouro DB2 COBOL

---

🟩 PERFORM + CICS

PERFORM 3000-VALIDA-MAP
PERFORM 3100-PROCESSA-NEGOCIO
PERFORM 3200-ENVIA-RESPOSTA

✔ Modular
✔ Legível
✔ Fácil de testar

---

🧨 Erros comuns em produção

Erro	Impacto
PERFORM THRU mal delimitado	Execução inesperada
Alterar contador no parágrafo	Loop infinito
Falta de EXIT	Debug caótico
GO TO misturado com PERFORM	Código ilegível

---

🧙 Curiosidades & Easter Eggs

🥚 Em COBOL antigo, PERFORM THRU era o padrão absoluto
🥚 Auditores AMAM código com PERFORM bem estruturado
🥚 Muitos shops ainda proíbem GO TO por norma interna
🥚 PERFORM é um dos motivos do COBOL sobreviver tão bem até hoje

---

🎓 Regra final para padawans

Se você entende PERFORM, você entende o fluxo do COBOL.
Se entende o fluxo, domina Batch, DB2 e CICS.

 

Bellacosa Mainframe e a lei sincronicidade

☕ Lei da Sincronicidade (Carl Jung)

Ou: quando o universo dá SUBMIT no JCL sem te avisar

Vou falar em primeira pessoa, como bom mainframeiro raiz que já viu coisa demais acontecer “por acaso” para ainda chamar tudo de coincidência.

---

📜 Origem – Quem foi o operador dessa ideia?

Carl Gustav Jung, psiquiatra suíço, parceiro intelectual (e depois desafeto) de Freud, criou o termo Sincronicidade para explicar algo simples e profundo:

Eventos que não têm relação de causa e efeito,
mas possuem significado para quem vivencia.

Não é misticismo barato. Jung era sistemático. Ele só percebeu que a psique humana e o mundo externo às vezes parecem rodar no mesmo clock.

---

🧠 Conceito em modo Mainframe

Pense assim:

• Não houve CALL

• Não houve PERFORM

• Não houve TRIGGER

Mas dois eventos acontecem juntos e fazem todo o sentido naquele contexto.

👉 Isso não é bug.
👉 É evento correlacionado por significado, não por lógica.

---

☕ Histórias (quem nunca?)

Eu já vivi várias:

• Pensar numa pessoa e ela aparecer

• Procurar uma resposta e tropeçar num livro, num artigo, numa conversa

• Estar travado num problema técnico e a solução surgir fora do terminal

No mundo IBM Z:

você sai pra tomar café… e o problema se resolve na sua cabeça.

Clássico.

---

🧩 Easter Eggs culturais

• Jung discutiu sincronicidade com Wolfgang Pauli, físico quântico

• Matrix usa isso o tempo todo (o déjà-vu do gato 🐈)

• Evangelion e Steins;Gate vivem disso

• No Japão, a ideia dialoga com:

  • En (縁) – laços invisíveis

  • Ma (間) – o espaço entre eventos

  • Ki (気) – fluxo

---

🗣️ Fofoquices filosóficas

Sincronicidade:

• Não responde quando você exige

• Não aparece para quem tenta controlar tudo

• Surge quando você para de forçar

É quase um RACF do universo:

acesso concedido só quando você está no grupo certo 😄

---

🛠️ Prática – dá pra “ativar”?

Não dá pra forçar.
Mas dá pra perceber:

• Observe padrões

• Escute mais

• Desligue o excesso de ruído

• Anote coincidências estranhas

Quanto mais atento, mais frequentes elas parecem.

---

🧘 Como entender sem pirar

Importante:

• Sincronicidade não substitui lógica

• Não invalida ciência

• Não explica tudo

Ela complementa.

Nem tudo no mundo roda em batch previsível.

---

🌏 Significado e importância

Ela nos lembra que:

• Nem tudo é controle

• Nem tudo é causa e efeito

• Sentido também é uma forma de ordem

Na vida, no trabalho, na criação:
quando as coisas começam a encaixar sem esforço excessivo, talvez seja hora de parar de lutar contra o fluxo.

---

☕ Conclusão Bellacosa

Sincronicidade é aquele momento em que você pensa:

“Isso foi coincidência demais…”

E sorri, porque sabe:
o sistema da vida rodou certo sem precisar de restart.

Às vezes, o universo não fala.
Ele alinha.

 

🥤 A Origem da Tubaína — O “Refrigerante do Povo” que Virou Ícone Nacional

Se existe um refrigerante que pode ser chamado de “SPOOL da infância brasileira”, esse refrigerante é a Tubaína. Ela não é apenas uma bebida: é um dataset cultural distribuído em milhares de versões, cada uma com seu label caseiro, sua micro-história e seus segredos de sabor guardados como PDS protegido no RACF.

Mas afinal… de onde veio essa lenda?

---

🌱 A Origem – Muito Antes da Fanta e da Coca Pensarem em Chegar Aqui

A Tubaína surgiu no interior do estado de São Paulo, entre o fim dos anos 1930 e início dos anos 1940. Não existe um único inventor, nem uma fábrica original certificada como “a primeira”.
E é justamente isso que faz parte do charme.

Tubaína nasceu como:

• bebida artesanal,

• produzida em pequenas fábricas e engarrafadoras familiares,

• que usavam xaropes de frutas, açúcar e gás carbônico para criar um refrigerante barato e acessível.

O nome “Tubaína” teria duas origens possíveis:

🅰️ Versão 1 — Do Tupi “tubaina” = bebida fermentada / bebida de raiz

Registros linguísticos apontam que “tubaina” aparece como variação de palavras indígenas relacionadas a bebida local ou fruta macerada.

🅱️ Versão 2 — Marca que virou nome genérico

Outra versão, muito forte entre historiadores de indústria, diz que Tubaína era originalmente o nome de um xarope-base distribuído para fábricas pequenas, que passaram a engarrafar refrigerantes com essa marca — e com o tempo, “virou sinônimo de qualquer refrigerante barato do interior”.
Um clássico caso Aspirina / Gilete / Maizena / Xerox.

---

🏭 As Primeiras Fábricas – O Brasil Raiz Engarrafado

Entre as primeiras e mais conhecidas estão:

• Tubaína Zarco – Piracicaba/SP

• Tubaína Bacharel – São João da Boa Vista/SP

• Turbaína Ferraspari – Jundiai/SP

• Tubaína Joaninha – Taubaté/SP

• Tubaína Arco Íris – Mococa/SP

• Tubaína Vivi – diversas cidades do interior

• Sanbra/J. Macedo, que vendia xaropes Tubaína para engarrafadores

Essas pequenas fábricas se espalharam como jobs submitting in batch, cada uma com sua receita própria — mais doce, mais artificial, mais frutada ou mais “doce de bar”.

---

🎨 O Sabor – Uma Mistura Única (E Bagunçada) de Identidade Brasileira

O sabor da Tubaína era, e é, uma alquimia:

• ramalhete de frutas artificiais,

• base de guaraná ou tutti-frutti,

• açúcar para adoçar a vida,

• e cor âmbar ou avermelhada, levemente translúcida.

Era um sabor que gritava: “sou simples, sou barata, sou boa!”

Em muitos lugares, Tubaína era bebida em garrafa de 600 ml, com tampa de metal que você abria na quina da mesa, e com aquele som clássico que parecia um IEFC001I anunciando início do serviço.

---

🧃 Por que a Tubaína virou febre?

Simples:

• Era barata (metade do preço dos grandes refrigerantes).

• Era local (tradição regional fortíssima).

• Era familiar (produzida por fábricas do bairro).

• Era democrática (vendida no bar, no campinho, no mercadinho).

• Era saborosa de um jeito despretensioso.

E claro:
Toda cidade tinha “a melhor Tubaína do mundo”.
Cada uma com seu fã-clube.

---

🥚 Easter-Egg — Tubaína era a bebida “clandestina” dos anos 60/70

Acredite:
Algumas versões de Tubaína tinham teor alcoólico leve, por causa da fermentação natural dos xaropes artesanais.

Era tão discreto que ninguém falava disso… mas todo mundo sabia.
Tipo um dataset uncataloged que só o operador raiz conhecia.

---

📜 A Situação Atual – A Sobrevivente do Brasil Raiz

Hoje, a Tubaína:

• segue viva em centenas de microfábricas pelo Brasil,

• tem festivais próprios (como o Tubaína Fest, em São Paulo),

• virou produto gourmet em algumas versões,

• e ganhou um renascimento nostálgico nas redes sociais.

Marcas atuais de destaque:

• Tubaína São João

• Dore

• Frevo

• Itubaína Retrô (da Schin) – a versão industrial mais famosa

• Tubaína Xereta

---

🔍 Curiosidades — Pacote Bellacosa

• 🔸 “Tubaína” é praticamente um open-source beverage — cada região fez sua fork.

• 🔸 Garrafas retornáveis de Tubaína foram ícones dos anos 50 a 90.

• 🔸 Em muitos lugares, “Tubaína” virou sinônimo de qualquer refri de garrafa marrom, mesmo que o rótulo dissesse outro nome.

• 🔸 Tubaína é considerada por alguns historiadores como o primeiro refrigerante realmente popular do Brasil, antes da Coca dominar tudo.

• 🔸 Existe um museu informal da Tubaína, com rótulos de mais de 700 marcas coletadas pelo interior paulista.

---

🥤✨ Conclusão – Tubaína: A Bebida Mais Brasileira Que Já Houve

Tubaína é memória líquida.
É o refrigerante da infância, do boteco, do campinho, da padaria com balcão de mármore, do mercadinho com cheiro de madeira e sabão em pedra.

Ela não veio de corporações gigantes.
Ela nasceu como obra de milhares de pequenos criadores, todos querendo fazer uma bebida gostosa, barata e acessível — um verdadeiro cluster de boa vontade e criatividade.

A origem exata pode ser múltipla.
Mas a essência é uma só:

Tubaína é o sabor do Brasil raiz.