Bellacosa Mainframe apresenta o famoso gato da sorte maneki neko

Perfeito. Vamos de Maneki-neko no modo Bellacosa Mainframe 🐱⚙️
Origem, história, fofoca, easter egg, curiosidade inútil-útil e aquele paralelo inevitável com sistemas que não podem cair.

---

🐱 Maneki-neko – o gato que dá IPL na sorte

Se você já entrou num restaurante japonês, numa lojinha de bairro ou até num boteco “meio oriental”, provavelmente viu ele lá:
um gato sentado, uma patinha levantada, olhando para o nada… mas trabalhando pesado.

O Maneki-neko (招き猫) não está acenando.
Ele está chamando.

E isso muda tudo.

---

Maneki neko

📜 Origem: logs antigos do Japão feudal

O termo Maneki-neko vem de:

• maneku (招く) → convidar, chamar

• neko (猫) → gato

Ou seja:

“o gato que chama”

As origens mais aceitas ficam entre os séculos XVII e XVIII, no Período Edo, quando o Japão começa a urbanizar, surgem comércios, rotas internas e… concorrência.

Existem três lendas principais, como qualquer sistema legado respeitável.

---

🏯 Lenda do Templo Gotoku-ji (a mais famosa)

Um senhor feudal passava por um templo pobre durante uma tempestade.
Viu um gato levantando a pata, como se chamasse.

Curioso, se aproximou.
No instante seguinte, um raio caiu exatamente onde ele estava antes.

Resultado:

• Sobreviveu

• Financiou o templo

• O gato virou símbolo de proteção + prosperidade

Failover espiritual bem-sucedido.

---

🏮 Lenda da velha comerciante pobre

Uma senhora, sem dinheiro, sonha com um gato dizendo:

“Faça estátuas de mim e você nunca passará fome.”

Ela obedece.
As pessoas começam a comprar.
O dinheiro volta.

Primeiro caso documentado de monetização de mascote.

---

🧧 Lenda da gueixa e o gato enforcado (a versão dark)

Um gato puxa o quimono da gueixa repetidamente.
Assustado, um cliente decapita o gato.

A cabeça voa, mata uma cobra venenosa que estava prestes a atacar a gueixa.

Culpa, remorso, estátuas do gato…

Backup tardio, mas com aprendizado.

---

🐾 A pata levantada NÃO é aleatória

Aqui entra a parte que pouca gente sabe:

• 🐱 Pata esquerda levantada
  → chama clientes, pessoas, movimento
  → comum em lojas e restaurantes

• 🐱 Pata direita levantada
  → chama dinheiro, prosperidade
  → comum em empresas, caixas, escritórios

• 🐱 Duas patas levantadas
  → proteção total
  → também conhecido como “overkill visual”

Duas patas = firewall + IDS + backup offsite.

---

🎨 Cores e seus significados

Nada no Maneki-neko é decorativo. Tudo é configuração.

• 🤍 Branco → pureza, novos começos (default)

• 🖤 Preto → proteção contra azar

• ❤️ Vermelho → saúde

• 💛 Dourado → dinheiro (o mais vendido)

• 💚 Verde → estudos, crescimento

• 💗 Rosa → amor (versão moderna)

---

🧧 A moeda oval (koban)

Muitos Maneki-nekos seguram uma moeda com inscrição:

千万両 (sen man ryō)

Tradução livre:

“10 milhões de ryō”
(uma fortuna absurda na época)

É o equivalente espiritual a:

MAX-AMOUNT=YES

---

🥚 Easter eggs culturais

• O gesto japonês de “chamar alguém” é com a palma para baixo, não para cima
  → o gato NÃO está dando tchau

• No anime Natsume Yuujinchou, Doraemon, Pokémon, Bleach e até Hello Kitty, referências ao Maneki-neko aparecem o tempo todo

• O bairro de Gotoku-ji, em Tóquio, tem milhares de estátuas acumuladas
  → um spool espiritual de agradecimento

---

🧠 Tradução para o mundo mainframe

O Maneki-neko representa:

• Alta disponibilidade

• Chamada constante de recursos

• Proteção contra eventos inesperados

• Resiliência silenciosa

Ele não faz barulho.
Não promete milagres.
Só fica lá, funcionando.

Como um CICS estável numa sexta-feira à noite.

---

☕ Comentário final estilo El Jefe

Talvez o Maneki-neko não traga dinheiro sozinho.
Mas ele lembra algo fundamental:

Sorte também é disciplina, atenção e constância.

O gato não corre atrás da prosperidade.
Ele senta, observa…
e chama.

Como todo bom sistema que dura décadas.

---

🐾⚙️

 

Bellacosa Mainframe apresenta um review smp/e 

🧠 SMP/E for z/OS – Uma Revisão

Revisão definitiva (com cheiro de fita, CSI alinhado e café frio ☕)

Se você acha que SMP/E é complicado, relaxa: ele só é honesto.
Honesto no sentido de que reflete exatamente a complexidade do z/OS — sem abstrações mágicas, sem “next, next, finish”.

SMP/E não é só uma ferramenta.
É memória histórica, controle cirúrgico e disciplina operacional.

Vamos revisar The Network do SMP/E for z/OS Workshop no melhor estilo Bellacosa Mainframe: com contexto, visão sistêmica e alguns easter eggs que só quem já brigou com um CSI entende 😉

---

🏛️ Antes do SMP/E: quando tudo era fita, suor e coragem

Nos anos 70, o mundo era simples — e perigoso.

• O sistema vinha em DLIB tapes

• O SYSGEN tinha Stage 1 e Stage 2

• O programador montava tudo na unha

• E manutenção?
  👉 Manual. Muito manual.

Resultado?

• Instabilidade

• Erros humanos

• Sistemas que “funcionavam… até não funcionarem”

💾 Easter egg #1:

Quem nunca teve medo de rodar um IEP_COPY no volume errado… não viveu essa época.

---

🧬 A chegada do SMP (e depois SMP/E)

Nos anos 80, a IBM fez algo revolucionário:
automatizou o que não podia mais depender da memória humana.

Nascia o SMP, que depois evoluiu para SMP/E (System Modification Program / Extended).

Agora o sistema tinha:

• Global Zone → cérebro

• Target Zone → sistema em execução

• Distribution Zone (DLIB) → fonte da verdade

Tudo documentado.
Tudo rastreável.
Tudo auditável.

---

🧠 O conceito-chave: CSI (Consolidated Software Inventory)

O CSI é o coração do SMP/E.

Ele responde perguntas críticas como:

• O que está instalado?

• Onde está?

• Como foi construído?

• Quem depende de quem?

Zonas:

• Global Zone
  Índice mestre + opções de controle

• Target Zone
  Reflete o que está rodando

• Distribution Zone
  Reflete o que foi entregue

📌 Regra de ouro:

SMP/E não adivinha. Ele só faz exatamente o que o CSI diz.

---

📦 Tudo em SMP/E é SYSMOD

Não existe exceção.
Se entrou no SMP/E, virou SYSMOD.

Tipos clássicos:

• FUNCTION → produto novo

• PTF → serviço preventivo

• APAR → correção corretiva

• USERMOD → customização local (o famoso “aqui a gente fez diferente”)

Todos eles têm:

• MCS (++ statements) → inteligência

• Modification Text → o código

💾 Easter egg #2:

Viu ++HOLD? Pare. Respire. Leia o PSP antes de qualquer APPLY.

---

🔁 O fluxo eterno do SMP/E

O ciclo que nunca muda:

1. RECEIVE

   • Entra no SMPPTS

   • Atualiza Global Zone

   • Nada muda no sistema ainda

2. APPLY

   • Atualiza Target Libraries

   • Sistema pode ser testado

   • Ainda reversível

3. RESTORE

   • Volta ao último nível aceito

   • Usa DLIB como fonte

   • Seu botão de “desfazer”

4. ACCEPT

   • Atualiza DLIB

   • Ponto sem volta

   • Agora é história oficial

💣 Easter egg #3:

ACCEPT em produção sem teste é um pedido formal de incidente grave.

---

🌐 The Network: quando o SMP/E ganhou internet

Chegamos ao ponto alto do módulo: entrega eletrônica.

Com Shopz / JustShopz, tudo mudou:

• Menos fita

• Mais automação

• Menos transporte físico

• Mais rastreabilidade

Opções modernas:

• ServerPac → replace completo

• CBPDO → produto ou serviço incremental

• Internet Delivery

  • RECEIVE FROMNETWORK

  • RECEIVE FROMNTS

  • RECEIVE ORDER

📦 Tudo chegando direto no HFS/zFS, validado por hash, protegido por certificado X.509.

🔐 Easter egg #4:

Se o RACDCERT não reconhece seu certificado, o SMP/E também não vai.

---

🧾 Shopz, pedidos e abas que importam

Depois de submeter o pedido:

• Ele aparece como Open

• Depois Submitted ou Order Center

• E você acompanha em:
  👉 In Progress

Quando muda para Download…
🎉 chegou a hora.

📬 E-mail da IBM
🔗 Link direto
⏳ 14 dias de validade

---

🧠 SMP/E moderno não é só manutenção

Hoje o SMP/E também:

• Ordena PTF automaticamente

• Agenda serviço

• Controla origem dos fixes (SourceID)

• Centraliza histórico

Tudo isso com:

• RECEIVE ORDER

• ORDER Management (Option 7)

• Java ou ICSF

• FTPS + Hash SHA-1

---

🧪 Planejamento: onde bons sysprogs se diferenciam

Antes de qualquer INSTALL:

• Clone do sistema

• Program Directory

• PSP Buckets

• Espaço em Target, DLIB e SMP/E datasets

• IVP depois

• Testes reais

• Migração controlada

🧠 Easter egg final:

O melhor sysprog não é o que instala rápido.
É o que dorme tranquilo depois do IPL.

---

🏁 Conclusão

SMP/E não é moda.
Não é hype.
Não é simples.

Ele é engenharia de software em estado puro, aplicada a um dos ambientes mais críticos do planeta.

E se você chegou até aqui entendendo tudo isso…
👉 Parabéns: você fala fluentemente Mainframe.

 

Bellacosa Mainframe apresenta o REXX

☕🔥 REXX Hardcore no z/OS — automação, controle e poder operacional  

Se você já salvou produção com um exec improvisado, já rasgou SDSF via ADDRESS, ou já ouviu

“isso dá pra automatizar em REXX, né?”
então puxa a cadeira.
Aqui é REXX técnico, sem verniz didático e com cheiro de madrugada.

---

🕰️ Histórico & Origem — por que o REXX virou arma de produção

O REXX (Restructured Extended Executor) nasce na IBM nos anos 80 com uma missão clara:

• Substituir JCL “verboso”

• Padronizar scripts

• Criar uma linguagem legível, extensível e integrada ao sistema

Ele não foi feito para ser “bonito”.
Foi feito para controlar ambiente.

☕ Verdade histórica:

REXX não é linguagem de apoio — é linguagem de governo operacional.

---

🧠 Conceito de Ambiente de Processamento

REXX não executa no vácuo.
Ele sempre roda dentro de um ambiente:

• TSO/E

• Batch

• SDSF

• ISPF

• CICS (indiretamente)

• Programas externos

Cada ambiente define:

• Comandos válidos

• RC interpretado

• Recursos disponíveis

• Permissões RACF

🔥 Easter egg:
O mesmo EXEC pode funcionar em TSO e falhar em Batch sem mudar uma linha.

---

🧩 Fundamentos da Linguagem — simples na superfície, profunda no núcleo

Sintaxe & Elementos

• Tipagem dinâmica

• Strings como cidadão de primeira classe

• Sem declaração obrigatória

• Case-insensitive (armadilha clássica)

📌 Exemplo:

parse upper arg parm1 parm2
if parm1 = '' then exit 8

☕ Comentário ácido:
REXX perdoa erro demais — e isso cobra seu preço em produção.

---

🏗️ Estrutura de um Programa REXX

Todo EXEC sério tem:

1. Identificação

2. Validação de ambiente

3. Tratamento de RC

4. Controle de erro

5. Cleanup

📌 Exemplo base:

/* REXX */
signal on error
signal on failure
signal on syntax

address tso
"ALLOC FI(IN) DA('DATASET') SHR"
...
exit 0

🔥 Veterano sabe:
EXEC sem SIGNAL ON é convite ao caos.

---

🧮 Estrutura de Dados — tabelas na memória

REXX não tem array clássico.
Tem stem variables.

tab.1 = 'A'
tab.2 = 'B'
tab.0 = 2

☕ Curiosidade:
Stem mal controlado vira memory leak conceitual.

---

📂 Acesso a Arquivos & Geração de Relatórios

• ALLOC / FREE

• EXECIO DISKR / DISKW

• Geração de relatórios spoolados

• Integração com SORT

📌 Exemplo:

"EXECIO * DISKR IN (STEM L.)"
do i=1 to L.0
  say L.i
end

🔥 Easter egg:
EXECIO ignora erro… até você checar o RC.

---

🔃 Classificação & Manipulação de Dados

• SORT via IDCAMS

• SORT via ICETOOL

• Manipulação em memória (lento)

• Pipeline híbrido REXX + SORT

☕ Regra de produção:

Se precisa ordenar muito, não é REXX — é SORT.

---

🗂️ Acesso a Diretório de PDS

REXX + ISPF services:

• LMDINIT

• LMMLIST

• LMCLOSE

📌 Exemplo:

address ispexec
"LMINIT DATAID(DID) DATASET('MY.PDS')"
"LMMLIST DATAID(DID) OPTION(LIST)"

🔥 Veterano:
ISPF services dão poder… e risco.

---

🧑‍💻 Interatividade com Usuário (TSO)

• Pseudo-conversational

• Command-level

• SAY / PULL

• Mensagens controladas

☕ Fofoquice:
Interface feia, mas resolve crise em minutos.

---

🧪 Modos de Execução REXX

🟢 REXX Linha de Comando (Online)

• Interativo

• Debug rápido

• Dependente de perfil

🟡 REXX Batch Script (Interpretado)

• Executa via IKJEFT01

• Dependente de ambiente

• Mais flexível

🔴 REXX Batch Compilado

• Performance superior

• RC previsível

• Menos tolerante a erro

• Exige processo de build

🔥 Script vs Compilado:

Interpretado é agilidade.
Compilado é confiabilidade.

---

🔐 REXX + RACF

REXX não ignora segurança:

• Herda permissões do usuário

• Pode consultar via RACROUTE (indireto)

• Controla acesso via classes

☕ Verdade dura:
EXEC com SPECIAL é bomba com pavio curto.

---

🗄️ REXX + DB2

• DSNREXX

• SQL dinâmico

• RC + SQLCODE + SQLSTATE

• Automação de consultas e relatórios

📌 Exemplo:

ADDRESS DSNREXX
"EXECSQL SELECT COUNT(*) INTO :CNT FROM SYSIBM.SYSTABLES"

🔥 Easter egg:
SQLCODE ignorado vira incidente invisível.

---

🔀 ADDRESS — o coração da integração

ADDRESS muda o destino dos comandos:

• TSO

• ISPEXEC

• SDSF

• CONSOLE

• DSNREXX

☕🔥 Regra sagrada:

Quem domina ADDRESS domina o sistema.

---

🔢 Return Code (RC) — o idioma da produção

• RC ≠ erro sempre

• RC precisa ser interpretado

• Padronização é vital

if rc > 4 then exit rc

🔥 Veterano:
RC não tratado é mentira operacional.

---

📘 Programa do Curso — visão hardcore

Estrutura Geral / Labs

• Ambiente restritivo

• Casos reais

• Incidentes simulados

Instruções REXX

• IF, DO, SELECT

• SIGNAL, EXIT

• PARSE

Funções Internas / Sub-rotinas

• Modularização

• Reuso

• Controle de escopo

Comandos REXX

• SAY, PULL, TRACE

• QUEUE / PULL

• EXECIO

Funções TSO / CONSOLE

• WTO

• MODIFY

• DUMP

• SDSF

INTERPRET (🔥 perigoso)

• Execução dinâmica

• Flexibilidade extrema

• Risco máximo

☕ Comentário ácido:

INTERPRET é poder absoluto — use sóbrio.

---

🥚 Easter Eggs & Fofoquices REXX

• Todo ambiente tem um EXEC “salvador”

• Sempre existe um REXX sem comentários rodando há anos

• O melhor REXX é o que não precisa ser explicado

• Debug começa com TRACE ?R

---

☕🔥 Conclusão — Manifesto El Jefe REXX

REXX não é:

• Script simples

• Linguagem de iniciante

• Alternativa ao COBOL

REXX é:

• Cola do z/OS

• Automação estratégica

• Ferramenta de sobrevivência em produção

☕🔥 Quem domina REXX,
não programa apenas —
orquestra o mainframe.