Bellacosa Mainframe em uma tarde de churrasco

🥩 Churrasco: Mapa Completo dos Cortes

Brasil 🇧🇷 x Argentina 🇦🇷 x Japão 🇯🇵

(ou: como o mesmo boi vira três filosofias de vida)

Se tem uma coisa que mainframer entende, é isso:
👉 o mesmo hardware pode ser usado de formas totalmente diferentes, dependendo do sistema operacional.

Com carne bovina é igual.

O boi é o mesmo.
O corte muda.
A cultura manda.

E o resultado… muda tudo.

---

🐂 O BOI É UM SÓ. O MODELO É QUE MUDA.

Tecnicamente:

• Os músculos são os mesmos

• A anatomia não muda de país para país

Mas cada cultura:

• Enxerga o boi de um jeito

• Corta de forma diferente

• Valoriza partes diferentes

• Cria nomes próprios (às vezes confusos)

👉 É como COBOL, PL/I e Java acessando o mesmo banco.

---

churrasco de picanha

🇧🇷 BRASIL – O MODELO “CHURRASCO ROOT”

O Brasil historicamente:

• Simplificou os cortes

• Pensou em grelha grande

• Fogo alto

• Peças inteiras

Cortes clássicos brasileiros

Brasil	Onde fica	Observação
Picanha	Tampa da alcatra	Ícone nacional
Contra-filé	Lombo	Muitas vezes sem subdivisão
Alcatra	Traseiro	Corte “coringa”
Maminha	Ponta da alcatra	Macia e suculenta
Fraldinha	Diafragma	Sabor intenso
Costela	Costelas	Tempo + paciência

📌 Easter egg brasileiro
Durante décadas, o Brasil:

“rodou em produção” sem separar ancho, chorizo e ribeye.
Tudo era contra-filé e pronto.

---

Churrasco de ancho

🇦🇷 ARGENTINA – O MODELO “PRECISÃO & TRADIÇÃO”

A Argentina olha para o boi como um engenheiro.

Aqui:

• Cada músculo tem nome

• Cada corte tem função

• Menos tempero

• Mais respeito à carne

Cortes argentinos famosos

Argentina	Equivalente Brasil
Bife Ancho	Contra-filé (parte dianteira)
Bife de Chorizo	Contra-filé (parte traseira)
Vacío	Fraldinha
Asado	Costela
Entraña	Diafragma

📌 Ancho argentino
É praticamente o ribeye:

• Muito marmorizado

• Extremamente suculento

• Rei das parrillas

👉 Se fosse TI: hardware premium sem overclock.

---

churrasco de sirioin de wagyu

🇯🇵 JAPÃO – O MODELO “QUALIDADE EXTREMA”

O Japão não discute “qual corte é melhor”.
Ele pergunta:

“Qual a qualidade absoluta desse corte?”

Aqui entra o Wagyu.

⚠️ Atenção:

Wagyu NÃO é corte.
É o tipo de boi.

Cortes japoneses comuns em anime e yakiniku

Japão	Equivalente
Karubi (カルビ)	Costela / short rib
Riburo-su (リブロース)	Ribeye
Sirloin (サーロイン)	Contra-filé
Momo (もも)	Coxão
Gyūtan (牛タン)	Língua

📌 Karubi domina os animes:

• Cortado fino

• Muito marmorizado

• Grelha rápida

• Cena de amizade garantida

---

🌏 MAPA RESUMO – O MESMO CORTE, TRÊS NOMES

Região do boi	Brasil	Argentina	Japão
Lombo	Contra-filé	Ancho / Chorizo	Sirloin
Costela alta	Costela	Asado	Karubi
Diafragma	Fraldinha	Vacío	—
Traseiro	Alcatra	Cuadril	Momo
Língua	—	—	Gyūtan

---

🥚 Easter Eggs Carnívoros

🥚 A picanha:

• Não é tão valorizada fora do Brasil

• Virou símbolo nacional mais por cultura do que por técnica

🥚 No Japão:

• Marmorização é pontuada (A3, A4, A5)

• Gordura ≠ defeito

• Gordura = arte

🥚 Na Argentina:

• Sal grosso e fogo

• Nada de exagero

• Carne fala sozinha

---

☕ Tradução para Mainframers

• Brasil = sistema robusto, simples, parrudo

• Argentina = arquitetura refinada, bem segmentada

• Japão = altíssima performance, custo alto, precisão absoluta

Nenhum está errado.
Cada um resolve um problema diferente.

---

🧠 Comentário Bellacosa Mainframe

Entender cortes é como entender sistemas:

• Não existe “o melhor”

• Existe o mais adequado

• Para o contexto

• Para o momento

• Para a carga

E no fim…
O boi agradece quando é bem tratado
E o operador também.

---

JOB FINALIZADO
RC=0
SYSOUT: “Fome aumentou consideravelmente.” 🥩🔥

 

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