Translate

terça-feira, 5 de maio de 2009

🥩 Churrasco: Mapa Completo dos Cortes

 

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

BrasilOnde ficaObservação
PicanhaTampa da alcatraÍcone nacional
Contra-filéLomboMuitas vezes sem subdivisão
AlcatraTraseiroCorte “coringa”
MaminhaPonta da alcatraMacia e suculenta
FraldinhaDiafragmaSabor intenso
CostelaCostelasTempo + 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

ArgentinaEquivalente Brasil
Bife AnchoContra-filé (parte dianteira)
Bife de ChorizoContra-filé (parte traseira)
VacíoFraldinha
AsadoCostela
EntrañaDiafragma

📌 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ãoEquivalente
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 boiBrasilArgentinaJapão
LomboContra-filéAncho / ChorizoSirloin
Costela altaCostelaAsadoKarubi
DiafragmaFraldinhaVacío
TraseiroAlcatraCuadrilMomo
LínguaGyū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.” 🥩🔥

segunda-feira, 4 de maio de 2009

🦇 O QUE É O MOVIMENTO DARK/GÓTICO?

 

Bellacosa Mainframe relembra o movimento Dark Gotico

🦇 O QUE É O MOVIMENTO DARK/GÓTICO?

O movimento gótico (ou dark) é uma subcultura que mistura:

  • 🎵 Música (pós-punk, gothic rock, darkwave, industrial)
  • 🖤 Estética (preto, maquiagem dramática, visual vitoriano ou cyber)
  • 🧠 Filosofia (existencialismo, romantismo sombrio, crítica social)
  • 🎭 Arte (literatura, cinema, moda)

👉 Surgiu como uma evolução do punk — mais introspectiva, atmosférica e artística.


🌍 ORIGEM GLOBAL (RAIZ DO SISTEMA)

🇬🇧 Inglaterra – Final dos anos 70 / início dos 80

💾 Processo histórico (pipeline):

PUNK (1977) → PÓS-PUNK → GOTHIC ROCK

🔥 Bandas fundadoras:

  • Bauhaus → música “Bela Lugosi’s Dead” (marco zero)
  • Siouxsie and the Banshees
  • The Cure
  • Joy Division

💡 Insight Bellacosa:

O gótico é como um “fork do punk” — mesma base, mas com outro mindset e estética.


🇧🇷 CHEGADA NO BRASIL (IMPORT DO SISTEMA)

📀 Anos 80 – Entrada via pós-punk e underground

📍 Epicentro: São Paulo

  • Casas como o lendário Madame Satã
  • Mistura de punk, new wave, industrial e dark

💾 Fluxo brasileiro:

IMPORT (UK/Europa) → ADAPTAÇÃO → IDENTIDADE BRASILEIRA

🦇 BANDAS GÓTICAS BRASILEIRAS (STACK NACIONAL)

🔥 Clássicas / Raiz

  • Violeta de Outono
  • Arte no Escuro
  • Cabine C
  • Voluntários da Pátria

🧪 Industrial / Darkwave / Electro

  • Escarlatina Obsessiva
  • Hocico (não BR, mas MUITO influente aqui)

🌑 Cena mais recente / alternativa

  • Plastique Noir
  • Gangue Morcego

🌍 BANDAS INTERNACIONAIS IMPORTANTES

  • The Sisters of Mercy
  • Fields of the Nephilim
  • Clan of Xymox
  • Dead Can Dance

🧠 FILOSOFIA DO MOVIMENTO

👉 Diferente do que muita gente pensa:

❌ Não é sobre depressão
✔️ É sobre estética da melancolia, reflexão e arte

📚 Influências:

  • Edgar Allan Poe
  • H. P. Lovecraft
  • Dracula

💡 Insight Bellacosa:

O gótico é tipo um “dump analysis emocional” — explorar o lado oculto do sistema humano 😄


🕶️ ESTÉTICA E VISUAL (INTERFACE DO SISTEMA)

  • Preto dominante 🖤
  • Roupas vitorianas / couro / renda
  • Maquiagem forte (olhos escuros)
  • Referências vampirescas e românticas

🔥 CURIOSIDADES (EASTER EGGS)

🥚 Easter Egg #1 – Bela Lugosi

A música “Bela Lugosi’s Dead” homenageia o ator:

  • Bela Lugosi

👉 Ele interpretou Drácula e virou símbolo eterno do gótico.


🥚 Easter Egg #2 – Madame Satã

O nome do clube vem de:

  • Madame Satã

👉 Figura icônica da contracultura brasileira.


🥚 Easter Egg #3 – The Cure não queria ser gótico

  • Robert Smith já disse várias vezes que não curtia o rótulo “gótico”

👉 Mas o sistema já tinha classificado 😄 (tipo job em produção…)


🥚 Easter Egg #4 – Gótico ≠ Emo

  • Emo → emocional, hardcore melódico
  • Gótico → atmosférico, artístico, sombrio

⚙️ ARQUITETURA DO MOVIMENTO (MODELO MAINFRAME 😄)

INPUT: Punk + Arte + Literatura sombria
PROCESSAMENTO:
- Pós-punk
- Darkwave
- Industrial
OUTPUT:
- Música
- Moda
- Filosofia
- Comunidade underground

🧠 O QUE VOCÊ PRECISA SABER (RESUMO EXECUTIVO)

✔️ Surgiu no pós-punk inglês
✔️ Chegou ao Brasil nos anos 80 (SP como hub)
✔️ Mistura música + arte + filosofia
✔️ Tem cena brasileira forte (underground até hoje)
✔️ Não é só estética — é identidade cultural


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

 

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/EADDRESS TSO

    • BatchADDRESS MVS

    • ISPFADDRESS 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çãoUso
PARSE ARGLer argumentos passados na linha de comando
PULL / PARSE PULLLer registros da stack
QUEUE / PUSHInserir dados na stack
EXECIOLer/escrever sequential e PDS/PDSE
LINEOUT()Escrever linhas sequenciais em arquivos
ISPEXEC servicesTrabalhar com VSAM, painéis e macros ISPF
ADDRESSDefinir 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. 😉


domingo, 3 de maio de 2009

🜂 O Panteão Tupi-Guarani em Modo Produçã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

sábado, 2 de maio de 2009

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ê?

ComandoAfetaExecutável?
RECEIVECSI
APPLYTARGET
ACCEPTDLIB

🔄 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


sexta-feira, 10 de abril de 2009

🍱 Sa-Shi-Su-Se-So: o “JCL” do sabor japonês

 ☕️ Um Café no Bellacosa Mainframe – Especial Cozinha Japonesa

Bellacosa Mainframe apresenta o sa shi su se so o maior segredo da culinaria japonesa


🍱 Sa-Shi-Su-Se-So: o “JCL” do sabor japonês

Se você acha que culinária japonesa é só sushi, shoyu e wasabi… senta que lá vem história, causo, anime, origem e até analogia com mainframe — porque sim, dá pra explicar tempero com mentalidade de sysprog 😄

No Japão, existe um conceito quase sagrado na cozinha:
👉 さ・し・す・せ・そ (Sa-Shi-Su-Se-So)
Os cinco pilares do tempero tradicional japonês, na ordem correta de uso. Errou a ordem? Igual rodar JCL fora de sequência: até compila, mas o resultado vem estranho.


🧠 Origem: por que essa ordem existe?

Essa regra nasceu no Japão feudal, quando:

  • açúcar era artigo de luxo 💎

  • fermentação era ciência, não moda

  • o fogo era baixo, o tempo era longo

  • e o sabor vinha do equilíbrio, não do exagero

A ordem não é poética — é química e física:

  • alguns ingredientes penetram melhor antes,

  • outros evaporam,

  • outros amargam se entram cedo demais.


🧂 O breakdown técnico (estilo manual IBM)

🟡 Sa (砂糖 – Satō / Açúcar)

📌 Sempre primeiro

  • Açúcar endurece os ingredientes

  • Se entrar depois, não penetra

  • Função: arredondar sabores, não adoçar

💡 Dica Bellacosa:
Açúcar é como parâmetro de inicialização: se não definir no começo, depois não adianta ajustar.

🍜 Anime moment:
Em Shokugeki no Soma, o açúcar aparece como “arma secreta” em pratos salgados. Quem ignora… perde duelo.


🧂 Shi (塩 – Shio / Sal)

📌 Depois do açúcar

  • Sal puxa umidade

  • Realça o umami natural

  • Se entrar antes do açúcar, bloqueia absorção

🧠 Curiosidade:
No Japão antigo, sal era salário (sim, tipo salary mesmo). Errar sal era ofensa pessoal.


🍶 Su (酢 – Su / Vinagre)

📌 No meio, nunca no começo

  • Vinagre evapora rápido

  • Se cozinhar demais, vira agressivo

  • Dá acidez e “acorda” o prato

🍣 Causo clássico:
Arroz de sushi com vinagre fervido demais = desastre silencioso. Parece ok… até você provar.


🍶 Se (醤油 – Shōyu / Molho de soja)

📌 Quase no final

  • Já é salgado

  • Já é fermentado

  • Já é complexo

💡 Dica de veterano:
Shoyu cedo demais = prato escuro, amargo e pesado.
Shoyu no final = brilho, aroma e respeito.

🎌 Anime alert:
Em Midnight Diner, o shoyu é tratado como assinatura do cozinheiro — entra no final, quase como um “commit”.


🍶 So (味噌 – Miso)

📌 Sempre por último (ou fora do fogo)

  • Miso é vivo (fermentado)

  • Calor excessivo mata aroma

  • Função: profundidade e alma

🧘 Filosofia japonesa:
Miso não é tempero. É estado de espírito.

🍲 Quem viu Oshino Shinobu comendo sopa de missô em Monogatari sabe: aquilo é conforto em forma líquida.


🧩 Analogia Mainframe (porque sim 😎)

Sa-Shi-Su-Se-SoMainframe
AçúcarParâmetro inicial
SalControle de consistência
VinagreAjuste fino
ShoyuIntegração externa
MisoCultura legada (não mexe demais!)

Mexeu fora da ordem?
👉 S0C7 gastronômico.


⚠️ Erros comuns de iniciante (todo mundo já fez)

  • ❌ Shoyu no começo “pra pegar gosto”

  • ❌ Miso fervendo

  • ❌ Açúcar no final tentando salvar prato

  • ❌ Confundir shoyu com sal

  • ❌ Ignorar o tempo


🍥 Curiosidade bônus (Easter Egg 🍡)

O “Se” às vezes é explicado como せいゆ (seiyu) em livros antigos — um termo genérico para líquidos fermentados. A padronização moderna ficou com shoyu, mas a regra é mais velha que muita receita escrita.


☕ Conclusão – o sabor também tem arquitetura

A cozinha japonesa não é minimalista por acaso.
Ela é:

  • determinística

  • sequencial

  • respeita legado

  • otimiza recursos

  • prioriza equilíbrio

Exatamente como um bom ambiente mainframe.

Porque no fim…

cozinhar bem é saber quando NÃO mexer. ☕🍜