Bellacosa Mainframe apresenta IBM Mainframe REXX

REXX no z/OS: Guia Completo com História, Dicas e Curiosidades

---

1. Introdução ao REXX

REXX, sigla para REstructured eXtended eXecutor, é uma linguagem de programação de alto nível criada por Mike Cowlishaw, da IBM, na década de 1980.
Diferente de linguagens tradicionais como C, COBOL e PL/I, REXX é interpretada, de fácil leitura e sem tipagem explícita. Todos os dados são tratados como strings, e o sistema decide quando fazer conversão para números.

💡 Curiosidade: Apesar de muitos acharem que o nome veio do cachorro de Cowlishaw, isso é um mito urbano do Mainframe.

REXX se espalhou por todos os principais ambientes IBM: z/OS, z/VM, z/VSE, IBM i, AIX, e até ferramentas modernas IBM. Por isso, é considerada uma linguagem universal no ecossistema IBM.

---

2. Variáveis e Literais

• Variáveis não são case sensitive. Ou seja, var, VAR ou Var são a mesma variável.

• REXX não exige declaração de tipo e nem comprimento específico, embora existam limites definidos pelo sistema.

• Literals (strings constantes) podem ser colocadas entre aspas simples '...' ou duplas "...", sem diferença funcional.

💡 Dica: Sempre use aspas quando o conteúdo tiver espaços ou caracteres especiais.

---

3. Funções e Subrotinas

• Subrotinas (CALL) não precisam retornar valores. Elas executam ações e podem usar RETURN apenas para voltar ao ponto de chamada.

• Funções são chamadas para produzir valores, mas nem todas podem ser usadas como subrotinas.

• Ponto de atenção: Não confunda subrotinas com funções – tentar chamar algumas funções como CALL pode gerar erro.

---

4. Entrada de Dados

Existem três fontes principais:

1. Command Line / Argumentos:

   • Usados para passar parâmetros para o exec.

   • Sintaxe:

     PARSE ARG nome idade
     

   • Ex.: %‘meuexec’ JOAO 30

2. Stack (Data Stack):

   • Mecanismo central de entrada em REXX.

   • Comandos:

     PULL var      /* Lê do topo da stack */
     PARSE PULL a b c   /* Lê e divide em variáveis */
     

   • Pode receber dados de QUEUE, PUSH ou teclado (quando stack está vazia).

3. Keyboard (Interativo):

   • Se a stack estiver vazia, PULL lê do teclado no ambiente interativo (TSO/E).

💡 Dica: PARSE PULL é como um canivete suíço: lê e separa os dados ao mesmo tempo.
Exemplo avançado:

QUEUE "ABC-123-XYZ"
PARSE PULL a "-" b "-" c
SAY a b c
/* Resultado: ABC 123 XYZ */

---

5. Manipulação de Arquivos

• EXECIO funciona com:

  • Sequential datasets

  • PDS / PDSE members

• Não funciona diretamente com VSAM.

  • Para VSAM, use:

    • ISPF Data Set Services (ISRSUPC, ISRSDSN)

    • Chamada de utilitários MVS (ex.: IDCAMS)

💡 Exemplo simples de leitura de VSAM via ISPF:

ADDRESS ISPEXEC
"LIBDEF MYLIB DATASET ID('MY.VSAM.DATASET')"
"READ DSNAME(MY.VSAM.DATASET) OUTDATA(myArray)"

---

6. Comando LINEOUT()

• Escreve linha a linha, não permite random access.

• Sempre escreve na ordem sequencial do arquivo ou data set.

💡 Dica: Para manipular arquivos VSAM de forma controlada, combine ISPF services e arrays REXX.

---

7. Stack e PULL

• PULL remove registros do topo da stack.

• Alguns materiais citam acesso ao “fundo da stack”, mas na prática, o topo é a forma padrão de leitura.

• QUEUE e PUSH permitem inserir dados na stack de forma controlada.

---

8. Execução e Ambiente

• System REXX execs rodam em:

  • Console (z/OS)

  • Batch (JCL / MVS)

  • Programas via REXX Macro Interface

Não rodam diretamente em TSO/E como System exec.

• Host command environment depende do contexto:

  • TSO/E → ADDRESS TSO

  • Batch → ADDRESS MVS

  • ISPF → ADDRESS ISPEXEC

💡 Dica de ouro: Nunca presuma que TSO é o padrão universal. Cada address space tem seu ambiente próprio.

---

9. ISPF e Serviços REXX

• ISPF fornece serviços avançados (ISPEXEC) para criar:

  • Macros de edição

  • Manipulação de datasets

  • Painéis interativos

• ⚠️ ISPF é principalmente para online, não para batch (a menos que configurado explicitamente).

💡 Easter Egg: Você pode escrever comandos de edição personalizados diretamente em REXX, algo que programadores z/OS amam usar para automatizar tarefas repetitivas.

---

10. Indentação e Compilação

• REXX ignora indentação, tanto no interpretador quanto no compilador.

• Compilação é opcional – você pode rodar execs diretamente no interpretador.

---

11. Curiosidades e Fatos Divertidos

• Mike Cowlishaw nunca nomeou REXX após seu cachorro – é apenas uma lenda urbana.

• REXX é usado em automação de Mainframe desde os anos 80.

• É comum combinar REXX + ISPF + JCL + batch jobs para criar soluções totalmente automáticas em produção.

---

12. Resumo de Comandos Essenciais

Comando / Função	Uso
PARSE ARG	Ler argumentos passados na linha de comando
PULL / PARSE PULL	Ler registros da stack
QUEUE / PUSH	Inserir dados na stack
EXECIO	Ler/escrever sequential e PDS/PDSE
LINEOUT()	Escrever linhas sequenciais em arquivos
ISPEXEC services	Trabalhar com VSAM, painéis e macros ISPF
ADDRESS	Definir host command environment

---

13. Pontos de Atenção para Mainframe

• Nunca confunda funções com subrotinas.

• Stack é sequencial, não aleatória.

• EXECIO não acessa VSAM diretamente.

• ISPF serviços são para online, não para batch.

• Indentação é estética, não funcional.

• Variáveis não têm tipagem, mas cuidado com operações numéricas implícitas.

---

14. Exemplo Final Integrado

/* REXX Example: Stack + Parsing + File Write */
QUEUE "JOAO 30 SAO_PAULO"
PARSE PULL nome idade cidade
SAY "Nome:" nome ", Idade:" idade ", Cidade:" cidade

/* Write to a sequential file */
EXECIO 1 LINEOUT ("Nome:" nome) DATASET("USER.SEQ.DATA") STEM file. WAIT

Combina stack, PARSE PULL, e EXECIO.

---

Conclusão

REXX continua sendo uma ferramenta essencial para automação no Mainframe IBM.
Sua simplicidade, flexibilidade e integração com ISPF, TSO/E, batch e VSAM o tornam um verdadeiro canivete suíço para administradores e desenvolvedores Mainframe.

E lembre-se: não caia nos mitos – REXX não foi nomeado por um cachorro, mas por sua estrutura e poder de execução. 😉

 

Bellacosa Mainframe apresenta o panteão tupi-guarani para padawans

🜂 O Panteão Tupi-Guarani em Modo Produção

para mainframers, otakus e curiosos que sabem que todo sistema antigo ainda roda porque foi bem projetado

---

1. Introdução — quando os deuses ainda rodavam on-premise

Se você trabalha com mainframe, você já entendeu uma verdade incômoda do mundo moderno:
o que é antigo nem sempre é obsoleto — é apenas bem construído.

E se você gosta de anime, você também percebeu outra coisa: toda grande história nasce de um panteão, de entidades que regem leis invisíveis, forças naturais, ciclos e consequências. Nada acontece “porque sim”. Tudo responde a regras.

Agora segura essa ideia e pisa em solo brasileiro antes da chegada dos europeus.

Aqui, muito antes de servidores, nuvens e datacenters, os povos Tupi-Guarani já operavam um sistema completo de explicação do mundo — um panteão funcional, profundamente integrado à natureza, à ética e à sobrevivência coletiva.

Não era religião no sentido moderno.
Era arquitetura cósmica operacional.

---

2. O erro comum: chamar de “mitologia” como quem diminui

Quando falamos em “deuses gregos” ou “kami japoneses”, usamos respeito.
Quando falamos dos deuses indígenas, muita gente chama de “lendas”.

Erro grave de classificação.

O panteão Tupi-Guarani não era fantasia escapista. Era manual de operação da vida.

Cada divindade:

• explicava fenômenos naturais,

• regulava comportamento social,

• ensinava limites,

• reforçava ciclos,

• e mantinha o sistema estável.

Mainframer entende: isso não é superstição.
Isso é governança.

---

3. Nhanderu — o arquiteto do sistema 🌀

No topo da hierarquia não está um “deus bravo com raio”, mas Nhanderu (ou Nhanderu Tenondé).

Ele não é personagem ativo do dia a dia.
Ele é o arquiteto original.

Nhanderu:

• cria o mundo pela palavra,

• estabelece as leis,

• define os ciclos,

• e depois se afasta da operação direta.

Tradução técnica:
➡️ System Designer + Governance Model

Ele não interfere em cada evento. O sistema deve funcionar por si.

Anime parallel: aquele criador que estabelece o mundo e desaparece, deixando os espíritos e forças cuidarem do runtime.

---

4. Tupã — não é “o deus supremo” (e aqui está o easter egg) ⚡

Aqui entra um erro histórico clássico.

Muita gente aprende que Tupã é “o deus maior”.
Não exatamente.

Tupã é a manifestação do poder, especialmente:

• trovão,

• relâmpago,

• som,

• energia,

• sinal.

Ele é a voz audível da criação.

Para os Tupi-Guarani, Tupã não governa tudo — ele executa.

Mainframe translation:
➡️ Tupã é o subsystem de energia e comunicação, não o dono do sistema.

Easter egg histórico: missionários europeus reforçaram Tupã como “deus supremo” porque trovão lembra castigo divino cristão. Mas isso é fork mal documentado.

---

5. Jaci — a guardiã dos ciclos e do tempo 🌙

Jaci, a Lua, é uma das entidades mais importantes — e menos compreendidas.

Ela governa:

• o tempo noturno,

• a fertilidade,

• o crescimento,

• os sonhos,

• os ciclos femininos,

• o descanso.

Sem Jaci, o mundo entra em estado instável.

Ela não pune.
Ela regula.

No anime, Jaci seria aquela entidade silenciosa que nunca luta, mas sem a qual o mundo colapsa.

Mainframe analogy:
➡️ Scheduler + Clock do sistema

Se você ignora Jaci, você executa processo fora do horário — e paga o preço.

---

6. Guaraci — o Sol que não perdoa ☀️

Guaraci, o Sol, é força ativa, crescimento, esforço, clareza.

Ele:

• amadurece as plantas,

• fortalece o corpo,

• ilumina o caminho,

• cobra trabalho.

Mas atenção: Guaraci também castiga excessos.

Trabalhar demais sob o sol mata.
Ignorar o descanso quebra o corpo.

Tradução técnica:
➡️ CPU em full load sem controle térmico

Guaraci ensina algo que todo mainframer aprende cedo:
performance sem limite destrói hardware.

---

7. Anhangá — o erro de interpretação mais injusto 😈

Durante séculos, Anhangá foi tratado como “demônio”.

Isso é uma distorção brutal.

Anhangá é o espírito do erro, do engano, da ilusão.

Ele:

• confunde caçadores,

• protege animais,

• pune ganância,

• cria armadilhas mentais.

Ele não é mau.
Ele é teste de sanidade.

Anime analogy: aquele trickster que não mata, mas ensina da pior forma possível.

Mainframe view:
➡️ Fault Injection + Chaos Agent

Se você cai no Anhangá, o problema não é ele — é você.

---

8. Curupira — já falamos dele, mas ele merece status divino 🌿

Embora muitas vezes classificado como entidade menor, Curupira atua como daemon de proteção ambiental.

Ele:

• detecta exploração excessiva,

• confunde rastros,

• quebra a lógica do invasor.

Curupira não fala muito.
Ele age.

Anime parallel: guardião de dungeon que só ativa quando regras são quebradas.

---

9. Iara — controle de acesso emocional 🌊

Iara governa rios, lagos e o desejo humano.

Ela não mata todo mundo.
Ela seleciona.

Ela aparece para:

• os distraídos,

• os arrogantes,

• os que subestimam o ambiente.

Iara é engenharia social aquática.

No mundo anime, ela seria aquela entidade bela e fatal que testa maturidade emocional.

---

10. O panteão como sistema distribuído

Aqui está o ponto que o mainframer entende rápido:

O panteão Tupi-Guarani não é centralizado.

Não existe um único deus mandando em tudo.
Existem múltiplas entidades, cada uma responsável por uma camada.

• Criação → Nhanderu

• Energia → Tupã

• Tempo → Jaci

• Execução → Guaraci

• Erro → Anhangá

• Segurança → Curupira

• Interface emocional → Iara

Isso é arquitetura distribuída, não monolito.

---

11. Por que isso conversa tão bem com anime?

Porque o Japão fez exatamente isso com seus kami.

Espíritos:

• não são bons ou maus,

• respondem a regras,

• punem excessos,

• recompensam equilíbrio.

O Brasil tinha tudo isso — mas escolheu esquecer.

---

12. Curiosidades e easter eggs culturais 🥚

• Muitos nomes de cidades vêm dessas entidades.

• Expressões populares carregam ecos desses deuses.

• O medo da mata à noite não é irracional — é herança simbólica.

• A ideia de “pedir licença” à natureza vem diretamente do panteão.

---

13. Dicas para quem cria mundos, games ou histórias

Se você escreve, cria RPG ou ama worldbuilding:

• Use o panteão Tupi-Guarani como base, não caricatura.

• Pense nas entidades como funções, não personagens humanos.

• Dê consequência às ações.

• Evite maniqueísmo.

Isso gera mundos mais ricos do que copiar deuses gregos pela centésima vez.

---

14. Comentário final Bellacosa Mainframe ☕💾

Talvez o maior bug cultural brasileiro tenha sido desligar esse sistema achando que era coisa do passado.

O panteão Tupi-Guarani não é atraso.
É software maduro, testado por séculos, executado em ambiente hostil, com altíssima resiliência.

Enquanto o mundo corre atrás de mitologias importadas, a nossa dorme em cold storage — intacta, esperando restore.

E quem sabe, quando a gente aprender a ouvir de novo, descubra que esses deuses nunca foram embora.

Eles só ficaram em silêncio, observando se o operador atual merece acesso ao sistema.

🜂 JOB FINALIZADO — RC=0000

SMP/E: RECEIVE, APPLY e ACCEPT na vida real - Parte 4

 

Bellacosa Mainframe apresenta IBM SMP/E

📘 Série SMP/E para Iniciantes

Parte 4 – RECEIVE, APPLY e ACCEPT na vida real

“SMP/E não é teoria.
É JCL rodando às 3 da manhã… e tem que dar RC=0.”

---

🧠 O fluxo sagrado do SMP/E

No mundo real, todo SYSMOD passa obrigatoriamente por três fases:

RECEIVE  →  APPLY  →  ACCEPT

👉 Pular etapa não é atalho.
É atalho para incidente.

---

📥 RECEIVE — trazendo o SYSMOD para casa

O que o RECEIVE faz?

• Lê o PTF/APAR/FUNCTION

• Registra no CSI

• Torna o SYSMOD conhecido pelo SMP/E

📌 RECEIVE não muda o sistema.

---

Exemplo de JCL (simplificado)

SET BDY(GLOBAL).
RECEIVE SYSMODS.

👉 Fontes comuns:

• IBM Shopz

• FTP

• Portable datasets

---

Erros comuns no RECEIVE

• SYSMOD duplicado

• FMID inexistente

• CSI incorreto

💡 Dica Bellacosa:

“RECEIVE falhou? Nem pense em APPLY.”

---

🧪 APPLY — onde o risco começa

O que o APPLY faz?

• Copia módulos para TARGET libraries

• Atualiza o sistema executável

• Respeita VER, HOLD e ERROR

👉 Aqui o código passa a existir de verdade.

---

APPLY CHECK (obrigatório!)

SET BDY(TARGET).
APPLY CHECK.

Ele mostra:

• Conflitos

• Dependências

• HOLDs

• ERRORs

📌 Nunca pule o CHECK.

---

APPLY real

SET BDY(TARGET).
APPLY.

📌 Pode exigir:

• IPL

• Parada de subsistema

• Ação manual

---

Erros comuns no APPLY

• Ignorar ++HOLD

• APPLY direto em produção

• Não validar impacto

👉 Aqui nascem as histórias de guerra.

---

📦 ACCEPT — consolidando a verdade

O que o ACCEPT faz?

• Atualiza o DLIB

• Define o baseline oficial

• Prepara futuras manutenções

📌 ACCEPT não muda o sistema executável.

---

Exemplo de JCL

SET BDY(DLIB).
ACCEPT.

---

Erros comuns no ACCEPT

• ACCEPT sem teste

• ACCEPT em ambiente errado

• DLIB desatualizado

💡 Dica Bellacosa:

“ACCEPT é compromisso. Não faça de cabeça quente.”

---

🧩 Quem mexe em quê?

Comando	Afeta	Executável?
RECEIVE	CSI	❌
APPLY	TARGET	✅
ACCEPT	DLIB	❌

---

🔄 Rollback existe (mas dói)

RESTORE

• Reverte APPLY

• Não é trivial

• Depende do histórico

👉 Rollback não é Ctrl+Z.

---

🧠 Caso real (estilo Bellacosa)

Um PTF aplicado sem APPLY CHECK
ignorou um ++HOLD de IPL
Resultado: JES instável pós-manutenção

📌 Moral:

O SMP/E avisou. Alguém não leu.

---

🎓 Boas práticas de produção

• Sempre APPLY CHECK

• Leia HOLDS

• Separe ambientes

• Documente ACCEPTs

• Nunca automatize cegamente

---

🧠 Curiosidades Bellacosa

• RECEIVE é burocracia

• APPLY é tensão

• ACCEPT é responsabilidade

---

🧾 Comentário final – Parte 4

RECEIVE informa.
APPLY muda.
ACCEPT oficializa.

Quem entende isso domina o SMP/E.

---

📌 Próxima Parte da Série

👉 Parte 5 – Laboratório SMP/E: Workshop prático passo a passo

🧔‍♂️💈 Seus REORGs do Db2 estão criando barba?

 

Bellacosa Mainframe apresenta o reorg do db2 

🧔‍♂️💈 Seus REORGs do Db2 estão criando barba?

Ou: quando o REORG vira o primo cabeludo do ambiente z/OS

Se você trabalha com IBM Mainframe + Db2 z/OS há mais de cinco minutos, já sabe:
👉 REORG não é luxo, é higiene básica do banco.
O problema é como ele costuma ser tratado no mundo real.

Em ambientes médios e grandes, o cenário é quase sempre o mesmo:

• Centenas (às vezes milhares) de jobs de REORG

• Criados por times de aplicação diferentes

• Cada um com seu “jeitinho especial”

• Scripts frágeis

• Dependências implícitas

• CHECK DATA aqui, DISCARD ali

• E quando um passo falha… 🔥 incêndio operacional 🔥

É aí que surge a pergunta filosófica do DBA moderno:

“Será que meus REORGs estão criando barbas?”

Porque quando o REORG cresce sem controle, ele fica:

• desalinhado

• imprevisível

• difícil de reiniciar

• impossível de auditar

• e um pesadelo para compliance 😈

---

🧠 Um pouco de história (porque Bellacosa sempre conta)

Lá atrás, no “Velho Testamento do Db2”, REORG era quase um ritual sagrado:

• Janela batch gigante

• Tudo parado

• DBA com café forte

• E muito JCL artesanal

Com o tempo:

• Vieram REORG SHRLEVEL CHANGE

• Depois ONLINE

• Depois automação

• Depois… bagunça organizada (ou nem isso)

O problema não é o REORG.
O problema é a falta de controle centralizado sobre quando, como e por quê ele roda.

---

🎯 O ponto crítico: falta de controle central

Vamos ser honestos (fofoquinha de corredor):

• Times de aplicação sabem criar REORG

• Mas não querem (nem devem) cuidar de padrão corporativo

• DBA vira o “bombeiro de utilitário”

• Restart vira arqueologia

• Auditor pergunta:

  “Quem rodou esse REORG? Quando? Por quê? Com qual critério?”

• E o DBA responde:

  “Então… veja bem…” 😬

Script-driven process é frágil.
Um COND CODE mal interpretado e todo o castelo cai.

---

⚡ Power Up Your Db2 REORGs (sem quebrar nada)

É aqui que se separa as crianças dos adultos.

E já vou adiantar o diferencial que faz o DBA sorrir:

🧙‍♂️ Sem mudar JCL

Sim. Você leu certo.
Nada de refatorar centenas de jobs legados.

🧩 Sem impactar os fluxos de aplicação

Os times continuam criando seus REORGs como sempre.

🏛️ Separação clara de papéis

• Aplicação: o que precisa

• DBA: como, quando e sob quais regras

Esse detalhe é ouro em ambientes corporativos.

---

🧰 O que muda na prática?

O Mestre dos Magos do DB2 deve agir como um orquestrador invisível:

• Centraliza a execução

• Aplica padrões

• Controla paralelismo

• Registra tudo

• E mantém compliance feliz (raridade!)

Tudo isso transparente, sem “quebrar” o legado.

---

📚 O que você aprende (e ganha) com essa abordagem

🔍 Seleção inteligente de REORGs

Nada de “REORG por feeling”:

• Regras

• Thresholds

• Estatísticas reais

• Prioridades de negócio

📏 Ajuste automático de espaço

• Tablespace cresceu? Ajusta.

• Encolheu? Otimiza.
  Sem DBA das organizações Tabajara ficar refazendo cálculo no guardanapo.

🧭 Impacto em access path? Sim, senhor!

• Análise pós-REORG

• REBIND opcional e controlado

• Nada de surpresa em produção segunda-feira cedo ☕😱

⚙️ Paralelismo com limites

• Executa múltiplos objetos

• Respeitando cotas

• Sem matar o LPAR

• Sem “storm” de utilitários

📊 Relatórios e auditoria

• Quem rodou

• Quando

• Por quê

• Com quais critérios

Auditor pergunta → você mostra relatório → fim da conversa.

---

🥚 Easter Eggs para DBAs atentos

• REORG sem governança é dívida técnica disfarçada

• “Sempre rodamos assim” não é estratégia

• REORG automático não substitui DBA — ele liberta o DBA

• O maior inimigo da performance não é fragmentação… é improviso

---

🗣️ Comentário de bastidor (aquele sincero)

Se você:

• Vive apagando incêndio de REORG

• Já perdeu noite com restart quebrado

• Já ouviu “foi só um REORGzinho”

• Ou já explicou access path estranho depois de maintenance…

Então você não precisa rodar mais REORG.
Você precisa rodar REORG com controle.

---

🎓 Conclusão estilo Bellacosa

REORG não pode ser selvagem.
REORG precisa de coleira, guia e pedigree.

Automatizar sem padronizar é só acelerar o caos.
Centralizar sem mudar o legado é maturidade operacional.

Se seus REORGs estão “esta crescendo as barbas ”, talvez não seja hora de cortar…
👉 é hora de pentear com inteligência.

☕💙
Um café, um REORG bem governado e um DBA feliz.

 

Bellacosa Mainframe apresenta o Folclore brasileiro para padawans

🜂 Folclore Brasileiro em Modo Nativo

 para mainframers, otakus e curiosos que sabem que todo sistema tem alma

---

Introdução — quando o batch encontra o mito

Se você é mainframer, você entende uma coisa que muita gente não entende mais: sistemas antigos não são ultrapassados — são estáveis porque funcionam. Se você gosta de anime, você já percebeu outra coisa: toda boa história tem mitologia, regras internas, entidades, ciclos e consequências. Agora junta isso tudo e olha com atenção para o folclore brasileiro.

Spoiler: ele é um sistema distribuído milenar, documentado oralmente, resiliente, cheio de regras implícitas, processos em background, guardiões, exceções, erros fatais e lições que atravessam gerações.

O problema é que a gente cresceu achando que folclore era coisa de criança. Não é. Folclore é arquitetura cultural.

E hoje eu quero te mostrar isso em modo production ready.

---

1. Folclore não é lenda — é documentação viva

No mundo mainframe, documentação não nasce em PDF bonito. Ela nasce na prática, na falha, no incidente, no “não faz isso que dá problema”. O folclore funciona exatamente assim.

Antes de existir escrita formal, os povos originários do Brasil — Tupi, Guarani, Macro-Jê, Aruak e tantos outros — mantinham o conhecimento via transmissão oral, em ciclos repetidos, reforçados por histórias fortes, simbólicas e fáceis de lembrar.

Não é diferente de um JCL comentado passado de operador para operador.

“Não entra na mata sem pedir licença.”
“Não pesca mais do que precisa.”
“Não ri da noite.”

Isso não é superstição. Isso é controle de acesso ambiental.

---

2. Arquitetura do sistema: o mundo como ambiente de produção

No folclore brasileiro, o mundo não é um sandbox descartável. Ele é ambiente produtivo. E produção não perdoa.

A floresta, o rio, o céu, a noite e os animais não são cenários — são componentes do sistema.

• A floresta é o storage

• O rio é o data stream

• O vento é o scheduler

• O fogo é o commit irreversível

Se você faz algo fora das regras, não aparece um deus te punindo. O que acontece é pior: o sistema entra em estado inconsistente.

E aí surgem os processos de correção.

---

3. Curupira — o anti-debugger da mata 🌿

Vamos começar pelo mais famoso entre os mainframers do mato.

Curupira não é “monstrinho”. Ele é um mecanismo de proteção contra exploração predatória.

• Pés virados para trás?
  → Rastreamento confuso, logs invertidos.

• Aparece para quem caça por ganância?
  → Detecção baseada em comportamento, não identidade.

• Some quando respeitado?
  → Sistema entra em estado estável.

No mundo anime, o Curupira seria um guardião de dungeon que não ataca jogadores conscientes, só os que tentam farmar além do permitido.

Easter egg: pés invertidos são um truque narrativo genial. Quem tenta seguir o rastro se perde. É engenharia social aplicada à sobrevivência da floresta.

---

4. Boitatá — firewall de fogo 🔥

Boitatá é descrito como uma serpente de fogo, olhos brilhantes, presença silenciosa.

Tradução técnica:
➡️ Firewall ambiental contra destruição deliberada.

Ele aparece onde há:

• incêndio criminoso

• destruição gratuita

• invasão sem propósito

No anime, seria aquele espírito elemental que surge quando o equilíbrio é quebrado. Pense em Princess Mononoke. Isso é Boitatá rodando em background.

Curiosidade: o fogo do Boitatá não é caos — é limpeza corretiva. Ele protege, não consome.

---

5. Iara — engenharia social aquática 🌊

Ah, a Iara… mal interpretada por séculos.

Não é “sereia malvada”. É teste de atenção.

Ela aparece:

• para quem navega distraído

• para quem subestima o rio

• para quem confunde beleza com segurança

No mundo técnico: Iara é phishing emocional. Se você não entende o ambiente, cai.

Anime check: quantos personagens caem porque ignoram alertas óbvios? Iara é isso, só que com canto bonito e consequências fatais.

---

6. Saci — o hacker caótico 🌀

O Saci é o personagem mais subestimado do folclore.

Ele:

• altera pequenos detalhes

• esconde objetos

• muda resultados sem causar desastre total

• aparece rindo

Saci é chaos engineering.

Ele não destrói o sistema. Ele testa sua paciência, sua atenção e sua humildade.

Se você tenta capturá-lo à força, perde.
Se negocia, aprende.

Mainframer entende isso: nem todo erro é falha crítica. Alguns são teste de resiliência.

---

7. Noite, Lua e Sol — clock e scheduler 🌙☀️

No folclore indígena:

• Jaci (Lua) controla ciclos, fertilidade, descanso.

• Guaraci (Sol) regula crescimento, tempo, esforço.

Isso não é poesia. Isso é sincronização de processos.

Trabalhar contra o ciclo gera falha.
Descansar na hora errada gera erro.
Ignorar o tempo gera desgaste.

É o cron job mais antigo da humanidade.

---

8. Folclore x Anime — por que isso combina tanto?

Se você gosta de anime, já percebeu:

• Espíritos não são bons nem maus — são função.

• Poder tem custo.

• O mundo responde às ações.

• Exagero gera punição indireta.

Tudo isso já estava no folclore brasileiro.

O problema é que a gente cresceu olhando para fora e esquecendo o que estava rodando localmente.

Curiosidade amarga: o Brasil tem um folclore tão rico quanto o japonês, mas nunca fez world building consistente com ele. Falta coragem cultural.

---

9. Easter eggs culturais escondidos no dia a dia 🥚

Você já ouviu:

• “Não aponta pra lua.”

• “Respeita a mata.”

• “Não ri da noite.”

• “A noite escuta.”

Isso é folclore operacional, rodando sem manual.

São avisos comprimidos em frases simples, transmitidos sem precisar explicar o motivo técnico.

---

10. O que o folclore ensina para quem trabalha com tecnologia

Se você é mainframer, arquiteto, dev ou operador, o folclore brasileiro ensina coisas valiosas:

• Sistemas vivos exigem respeito.

• Nem tudo precisa ser explorado ao máximo.

• Equilíbrio é mais importante que performance.

• Nem todo erro é bug — às vezes é feedback.

• O ambiente responde ao abuso.

Isso é DevOps espiritual, muito antes do termo existir.

---

11. Por que resgatar o folclore agora?

Vivemos num mundo de:

• cloud sem dono

• consumo sem limite

• IA sem ética

• sistemas opacos

O folclore brasileiro lembra algo essencial:

Todo sistema tem consequências.

Não existe ação isolada.
Não existe impacto zero.
Não existe exploração infinita.

---

12. Comentário Bellacosa Mainframe ☕💾

Talvez o maior erro da nossa geração tenha sido achar que modernidade significa esquecer o passado.

O folclore brasileiro não é atraso.
Ele é base de dados histórica, validada por séculos de execução contínua.

Se o Japão transformou seus mitos em anime, games e filosofia pop, a gente também pode — sem copiar, sem diluir, sem pedir licença.

O Curupira não precisa de CGI.
O Saci não precisa virar piada.
O Boitatá não precisa ser esquecido.

Eles só precisam voltar a rodar em produção.

E quem sabe, assim como no mainframe, a gente aprenda que o sistema mais antigo ainda é o mais confiável.

🜂 FIM DO JOB — RC=0000

SMP/E: MCS na prática: ++VER, ++HOLD, ++ERROR sem medo - Parte 3

 

Bellacosa Mainframe apresenta IBM SMP/E

📘 Série SMP/E para Iniciantes

Parte 3 – MCS na prática: ++VER, ++HOLD, ++ERROR sem medo

“Quem domina MCS manda no SMP/E.
Quem ignora MCS vira refém do APPLY.”

---

🧠 Relembrando: o que são MCS?

MCS (Modification Control Statements) são as instruções formais que acompanham um SYSMOD.

Elas dizem ao SMP/E:

• O que é o SYSMOD

• Onde ele se aplica

• De que depende

• Quais são os riscos

• Quando parar e pedir atenção humana

📌 Regra de ouro:
Toda MCS começa com:

++

---

🧩 As três MCS que mais derrubam iniciantes

Nesta parte, vamos direto às três mais importantes do dia a dia:

• ++VER

• ++HOLD

• ++ERROR

---

🔎 ++VER — o filtro de compatibilidade

O que é?

O ++VER garante que o SYSMOD só seja aplicado na versão correta do produto.

👉 Tradução Bellacosa:

“Isso só entra se o ambiente for compatível.”

---

Exemplo:

++VER(Z038) FMID(HJES770).

Isso significa:

• z/OS versão Z038

• Produto JES2 (HJES770)

❌ Sem ++VER, o risco de aplicar PTF errado aumenta muito.

---

Dica Bellacosa

Se o ++VER não bate, o APPLY trava.
E isso é proteção, não problema.

---

🚨 ++HOLD — o aviso que você nunca deve ignorar

O que é?

O ++HOLD não é erro, é alerta.

Ele indica:

• Passos manuais necessários

• Impacto operacional

• Dependências externas

• Necessidade de IPL

---

Tipos comuns de HOLD

• SYSTEM → impacto no sistema

• ACTION → ação manual requerida

• ERROR → problema conhecido

• SECURITY → impacto de segurança

---

Exemplo:

++HOLD(SYSTEM) REASON(REQUIRES IPL).

📌 Tradução:

“Isso funciona, mas só depois de um IPL.”

---

Dica Bellacosa

HOLD não bloqueia, mas cobra atenção.
Ignorou, o sistema cobra depois.

---

🔥 ++ERROR — o alerta máximo

O que é?

O ++ERROR marca um PTF com defeito conhecido.

📌 Ele diz:

“Essa correção tem problema. Use por sua conta e risco.”

---

Exemplo:

++ERROR.

Isso indica:

• APAR ainda não resolvido

• Correção parcial

• Risco conhecido

---

Regra Bellacosa

Nunca aplique um ++ERROR sem ler a APAR.

Em ambientes críticos, muitas vezes:

• Aguarda-se o superseding PTF

• Ou aplica-se com mitigação

---

🧪 APPLY CHECK: seu melhor amigo

Antes de qualquer APPLY real:

APPLY CHECK

Ele mostra:

• Impacto do SYSMOD

• Dependências

• Conflitos

• HOLDs e ERRORs

💡 Dica Bellacosa:

“Quem usa APPLY CHECK dorme melhor.”

---

🧬 Relação entre ++VER, ++HOLD e ++ERROR

Statement	Bloqueia APPLY?	Função
++VER	Sim	Compatibilidade
++HOLD	Não	Alerta
++ERROR	Não	Erro conhecido

👉 SMP/E confia no sysprog, não no automático.

---

🧠 Curiosidades Bellacosa

• Um único ++HOLD ignorado já causou outages históricos

• ++ERROR existe para proteger a IBM e o cliente

• ++VER é o “cinto de segurança” do SMP/E

---

🧾 Comentário final – Parte 3

MCS não são opcionais.
São contratos técnicos.
E contrato mal lido dá problema.

---

📌 Próxima Parte da Série

👉 Parte 4 – RECEIVE, APPLY e ACCEPT na vida real

💾 Capítulo 3 — Boot inicial: o mundo além da escola

 

📚 SÉRIE “Sempre um Isekai”

Por Bellacosa Mainframe
(Memórias de um garoto que aprendeu a trocar de mundo sem sair da sala de aula)

💾 Capítulo 3 — Boot inicial: o mundo além da escola

O fim do colegial chegou rápido — como o ponto final de um livro que a gente queria que tivesse mais capítulos.
Mas o próximo volume já estava sendo escrito: o mundo do trabalho.

Com o diploma técnico em mãos e a curiosidade de quem sempre foi estrangeiro de si mesmo, entrei no universo do Processamento de Dados — ainda não se falava em “TI”.
Era um tempo em que o computador ocupava salas inteiras, e a palavra “mainframe” soava como magia industrial.
Aquele mundo lógico e silencioso me acolheu como nenhum outro.
Ali, finalmente, eu não era o aluno novo — eu era o programador que aprendia a dialogar com máquinas, e cada compile successful era uma nova forma de pertencer.

Percebi que, afinal, viver em trânsito não era desvantagem — era um sistema operacional de alma.
Ser o “novo” sempre me ensinou a observar, adaptar e reconstruir — exatamente o que um bom analista faz.
Minha vida inteira foi um boot contínuo: cada cidade, uma reinicialização; cada escola, uma nova rotina; cada linha de código, uma lembrança em hexadecimal.

Trabalhando como office-boy foi conquistando meu espaço, crescendo, fiz a faculdade, pós-graduação e mestrado, cresci academicamente, mas não abandonei os meus, protegi o quanto pode e ajudei a todos a trilharem o bom caminho. Não imagina que seria apenas o começo e que este isekai iria ainda mais longe, desta vez atravessando o oceano, mas isso já é outra história.

E talvez seja isso o que nos torna humanos no mundo das máquinas: a capacidade de recomeçar sem perder a memória.

---

☕ Epílogo — O Isekai Real

No fim das contas, percebo que nunca precisei ser transplantado para outro mundo.
Meu isekai sempre foi aqui mesmo — entre escolas, cidades e sistemas que me forjaram.
E, como todo bom personagem de jornada, aprendi que mudar é só outra forma de continuar.

---

Série “Sempre um Isekai”
Um relato sobre educação, adaptação e vocação — onde cada reboot é também um renascimento.
Assinado: Bellacosa Mainframe