Bellacosa Mainframe apresenta Auditoria no IBM SMP/E

📋 Checklist de Auditoria SMP/E

O que o auditor pergunta (e o que você precisa provar)

“Auditor não quer opinião.
Quer evidência.”

---

🧠 Objetivo do checklist

Garantir que:

• O z/OS está íntegro

• A manutenção é controlada

• As mudanças são rastreáveis

• O ambiente é auditável

👉 SMP/E é prova técnica, não discurso.

---

🔐 1. Controle de Acesso (RACF / ACF2 / TSS)

✔ CSI protegido (UACC=NONE)
✔ ALTER restrito a sysprogs autorizados
✔ READ para auditoria
✔ Logging ativo
✔ Revisão periódica de acessos

📌 Evidência:

• LISTDSD

• Relatórios RACF

• Perfis ativos

---

📦 2. Proteção das bibliotecas SMP/E

✔ TARGET libraries protegidas
✔ DLIB libraries protegidas
✔ SMPTLIB, SMPMTS, SMPPTS controlados
✔ Separação TEST / PROD

📌 Evidência:

• RACF profiles

• Dataset attributes

---

🔁 3. Processo RECEIVE / APPLY / ACCEPT

✔ RECEIVE documentado
✔ APPLY CHECK executado
✔ APPLY validado em teste
✔ ACCEPT autorizado formalmente

📌 Evidência:

• Outputs SMP/E

• JCL versionado

• Change records

---

🚨 4. Gestão de ++HOLD e ++ERROR

✔ HOLDS analisados
✔ Decisão documentada
✔ ERROR tratados com cautela
✔ Mitigações registradas

📌 Evidência:

• PTF cover letters

• APARs

• Decisões de risco

---

🧩 5. Gestão de USERMOD

✔ USERMOD documentado
✔ Justificativa formal
✔ Controle de APPLY/ACCEPT
✔ Revisão periódica

📌 Evidência:

• SYSMOD history

• Documentação técnica

---

🧪 6. APPLY CHECK (obrigatório)

✔ APPLY CHECK sempre executado
✔ Resultados arquivados
✔ Conflitos analisados

📌 Evidência:

• Output APPLY CHECK

• Aprovação formal

---

🧱 7. Controle de DLIB (baseline)

✔ DLIB atualizado
✔ ACCEPT consciente
✔ Baseline consistente
✔ DLIB protegido

📌 Evidência:

• CSI

• Relatórios SMP/E

---

🔄 8. Capacidade de RESTORE

✔ Processo definido
✔ Histórico preservado
✔ Testes de rollback
✔ Documentação clara

📌 Evidência:

• JCL RESTORE

• Registros históricos

---

🧠 9. Atualização e Segurança

✔ PTFs de segurança aplicados
✔ CVEs avaliados
✔ Backlog controlado
✔ Plano de atualização

📌 Evidência:

• Relatórios IBM

• Histórico SMP/E

---

🧾 10. Evidências e documentação

✔ Outputs armazenados
✔ Logs disponíveis
✔ Histórico preservado
✔ Responsáveis identificados

📌 Evidência:

• CSI

• JCL

• Relatórios

---

🚨 Red flags para auditor

❌ ALTER irrestrito
❌ ACCEPT sem teste
❌ USERMOD esquecido
❌ CSI sem proteção
❌ Falta de APPLY CHECK

👉 Tudo isso gera não conformidade.

---

🧠 Curiosidades Bellacosa

• Auditor confia mais no CSI do que em planilha

• SMP/E é trilha de auditoria nativa

• Segurança começa no controle de mudança

---

🧾 Comentário final – Checklist SMP/E

Quem tem SMP/E bem cuidado
não teme auditoria.

📋 Checklist de Auditoria SMP/E, no estilo Bellacosa Mainframe, pensado para auditoria interna, externa, SOX, PCI, ISO, ou simplesmente para dormir tranquilo. 

📋💾🛡️

☕ Um Café no Bellacosa Mainframe — z/OS 1.11: o sistema operacional que trouxe o mainframe para a era da automação e integração inteligente

☕ Um Café no Bellacosa Mainframe — z/OS 1.11: o sistema operacional que trouxe o mainframe para a era da automação e integração inteligente

---

🕰️ Ano de lançamento

O IBM z/OS 1.11 foi lançado em setembro de 2009, acompanhando o System z10 e já projetado para explorar os novos recursos do futuro zEnterprise z196.
Essa versão marcou o início de uma nova filosofia da IBM: transformar o mainframe em uma plataforma de nuvem corporativa, com automação, padronização e serviços integrados.

Se o z/OS 1.9 foi o cérebro que aprendeu a se ajustar, o 1.11 foi o que começou a conversar com o mundo — do batch ao web service, do COBOL ao Java.

---

⚙️ Introdução técnica

O z/OS 1.11 foi uma das versões mais importantes na linha evolutiva do sistema operacional da IBM.
Seu foco foi automação, integração e modernização de workloads, incluindo:

• Melhorias em Parallel Sysplex, WLM e Sysplex Distributor;

• Suporte estendido para Java 6 e J2EE workloads;

• Inovação com o z/OS Management Facility (z/OSMF) — a primeira interface web administrativa nativa;

• Preparação do sistema para ambientes de nuvem privada com gerenciamento centralizado.

Foi o primeiro passo concreto rumo ao conceito de z/OS como um serviço, uma base sólida para DevOps e administração simplificada.

---

🧠 Avanços na memória e arquitetura

O z/OS 1.11 consolidou o uso inteligente da memória com diversas melhorias:

• Suporte ampliado ao 64-bit Real Memory (memória física acima de 2 TB nos novos mainframes);

• Introdução de Large Memory Workload Management, otimizando o balanceamento entre LPARs e processadores zIIP/zAAP;

• Novo modelo de páginas grandes (1MB e 2GB) — reduzindo TLB misses e melhorando performance para Java, DB2 e IMS;

• HiperDispatch aprimorado, permitindo que o sistema entenda afinidade entre processadores e cache L3 — essencial no z10.

Esses avanços permitiram que o z/OS 1.11 alcançasse níveis inéditos de throughput e paralelismo, mantendo latência mínima mesmo sob carga mista (CICS, batch e WebSphere simultaneamente).

---

🧩 Aplicativos internos e softwares embarcados

O ecossistema do z/OS 1.11 foi um verdadeiro salto de modernização.
Alguns destaques:

• z/OS Management Facility (z/OSMF):
  Primeira interface web oficial para administração do sistema, com painéis para automação, diagnóstico, configuração e gerenciamento de políticas WLM.
  Simplificou tarefas antes realizadas apenas via TSO/ISPF.

• RACF (Security Server):
  Suporte a Kerberos, LDAPv3 aprimorado, autenticação forte e integração com certificados X.509 e tokens digitais.
  Introduziu segurança contextual (baseada em aplicação e identidade).

• DFSMS:
  Recursos de automated data tiering e policy management que ajustam classes de armazenamento automaticamente conforme o uso.
  O sistema agora entende se um dataset é “quente” (muito acessado) ou “frio”.

• JES2/JES3:
  Novas funções de checkpoint automático, otimização de spool e integração direta com WLM.
  Suporte a batch pipes aprimorado — essencial em grandes ambientes financeiros.

• RMF (Resource Measurement Facility):
  Painéis gráficos via z/OSMF e suporte a monitoramento em tempo real.
  Agora o RMF conversa com o WLM, ajudando a ajustar prioridades de forma preditiva.

• UNIX System Services (USS):
  Suporte a NFSv4, POSIX Threads 2008, 64-bit shared libraries e novas APIs para Java e CICS TS 4.1.
  O USS finalmente se torna um “Unix de verdade” dentro do z/OS.

---

🔬 Instruções de máquina e PR/SM

Com o System z10, o z/OS 1.11 pôde explorar um conjunto poderoso de novas instruções:

• Decimal Floating Point (DFP) — um divisor de águas para cargas financeiras e científicas, agora executadas nativamente em hardware.

• Improved Branch Prediction e Pipeline Control, otimizando ciclos por instrução.

• Criptografia CPACF v3 com suporte a SHA-2 e AES-256 de alta velocidade.

• Hardware-based time synchronization (STCKE) — precisão de microssegundos entre LPARs.

No firmware, o PR/SM ganhou refinamentos que transformaram a administração:

• Dynamic Logical Processor Management, permitindo ligar/desligar CPUs sem IPL;

• Group Capacity Capping Inteligente, ajustando limites conforme a carga;

• HiperDispatch Awareness — o PR/SM entende quais threads se beneficiam de caches próximos, reduzindo cross-LPAR latency.

Essas mudanças deram ao z/OS 1.11 o status de sistema operacional consciente de hardware, capaz de usar cada ciclo de CPU de forma estratégica.

---

🧮 Créditos de CPU e virtualização

O z/OS 1.11 trouxe um dos avanços mais finos em gerenciamento de CPU:

• O WLM (Workload Manager) foi redesenhado para funcionar com HiperDispatch e PR/SM inteligente.

• Créditos de CPU dinâmicos agora são realocados em tempo real com base em service classes e goals.

• Integração mais profunda com zAAPs e zIIPs, permitindo que workloads Java e DB2 usem processadores especializados sem penalizar o uso geral.

• Introdução do Soft Capping Dinâmico 2.0 — controle fino de MIPS por LPAR com base em carga real, não apenas limite estático.

Esse conjunto de recursos transformou o z/OS 1.11 em um ambiente de computação previsível, otimizado e autocorretivo.

---

🧭 Curiosidades e bastidores

• O projeto interno da IBM foi apelidado de “Aurora”, simbolizando o nascer de uma nova era de gerenciamento visual e automação.

• O z/OS 1.11 foi o primeiro sistema operacional IBM com interface web embarcada (z/OSMF) — um marco histórico.

• Também foi a primeira versão compatível nativamente com Java 6, o que revolucionou o uso do WebSphere Application Server no mainframe.

• O RMF começou a gerar dados exportáveis via XML e HTTP, prenúncio da integração com ferramentas de monitoramento modernas.

---

☕ Dica Bellacosa Mainframe

Quer ver o z/OS conversar com o operador?
O z/OSMF é o ponto de virada. Se você nunca testou, vale rodar em um zPDT ou zD&T.
Além disso, o z/OS 1.11 é excelente para quem quer entender a transição do mainframe clássico (verde e 3270) para o mundo Web, API e automação.

---

📜 Resumo técnico rápido

Item	Descrição
Versão	z/OS 1.11
Ano de lançamento	2009
Hardware principal	IBM System z10 / início do z196
Arquitetura	z/Architecture (64-bit total)
PR/SM	Dynamic LPAR, HiperDispatch, Soft Capping 2.0
Instruções novas	Decimal Floating Point, SHA-2, AES-256
WLM	HiperDispatch-aware, credit realocation em tempo real
Segurança	RACF com Kerberos e autenticação forte
Rede	NFSv4, IPv6, IPsec e QoS avançado
Curiosidade	Primeira versão com z/OSMF (interface web nativa)

---

💬 “O z/OS 1.11 não apenas gerenciava o mainframe — ele aprendeu a mostrá-lo ao mundo.”

🌍 Tricksters do Mundo

Bellacosa Mainframe revisa e encontra os Tricksters 

🌍 Tricksters do Mundo

Explicados para Mainframers (com logs, falhas e bypass autorizados pelo caos)

Se o mundo fosse um mainframe cósmico, os tricksters seriam aqueles programas que:

• Não seguem o fluxo esperado

• Exploram regras mal definidas

• Nunca causam ABEND técnico, só ABEND moral

• E sempre deixam o operador confuso olhando o SYSOUT

Eles não são heróis clássicos.
Não são vilões tradicionais.
São testes de stress ambulantes do sistema social, divino e humano.

---

🧠 O que é um Trickster? (definição estilo manual IBM)

Trickster é um arquétipo universal que aparece em praticamente todas as culturas humanas.

Características comuns:

• Inteligência acima da média

• Moral flexível (ISO = UR total)

• Uso de ironia, mentira e ambiguidade

• Capacidade de virar o jogo sem força

• Exposição das falhas do sistema

📌 Em linguagem mainframe:

Tricksters existem para provar que a regra estava errada, não o código.

---

⚙️ Trickster ≠ Hacker (mas quase)

Comparação rápida:

Hacker	Trickster
Explora falha técnica	Explora falha humana
Precisa de acesso	Precisa de arrogância alheia
Pode ser barrado	Sempre passa
Age oculto	Age à vista de todos

O trickster não invade.
Ele recebe permissão sem que o sistema perceba.

---

🌎 Tricksters pelo mundo (versão “data center global”)

🇧🇷 Pedro Malazarte – Brasil

Função: Auditor informal da desigualdade
Falha explorada: Ganância, ignorância, abuso de poder

Pedro segue ordens literalmente.
Resultado:

• Quem mandou se arrepende

• Ele sobrevive

• O sistema continua errado

➡️ Literal execution bug.

---

🇯🇵 Kitsune – Japão

Raposas mágicas que:

• Mudam de forma

• Enganam humanos

• Testam caráter

No Japão, o trickster é:

• Elegante

• Espiritual

• Ambíguo

Kitsune pune:

• Arrogância

• Falta de respeito

• Desejo excessivo

➡️ Security test espiritual.

---

🇳🇴 Loki – Mitologia Nórdica

O mais mainframe de todos.

Loki:

• Ajuda os deuses

• Quebra tudo

• Conserta depois

• Ou piora

Ele é:

• O desenvolvedor brilhante sem documentação

• O cara que resolve hoje e explode amanhã

➡️ Change sem CAB approval.

---

🇩🇪 Till Eulenspiegel – Alemanha

Especialista em:

• Interpretar ordens literalmente

• Humilhar autoridades com lógica pura

Exemplo clássico:

“Ensine as pessoas a ver.”

Ele pinta óculos nos muros.

➡️ Manual mal escrito, execução perfeita.

---

🇳🇬 Anansi – África Ocidental

Aranha-trickster.

Anansi:

• Usa histórias como arma

• Ensina lições morais

• Vence deuses maiores

É o DBA da narrativa:

• Controla quem sabe o quê

• Quando sabe

• E como usa

➡️ Gestão de conhecimento como poder.

---

🇨🇳 Sun Wukong – China (Rei Macaco)

Sim, o avô espiritual de Goku.

Sun Wukong:

• Engana o Céu

• Enfrenta burocracia divina

• Ri das regras cósmicas

Ele literalmente:

• Se recusa a aceitar hierarquia

• Burla imortalidade

• Sobrevive a punições absurdas

➡️ Usuário root no universo.

---

🇺🇸 Coyote – Povos indígenas norte-americanos

Coyote:

• Cria o mundo… errando

• Ensina falhando

• Aprende quebrando

Ele não é sábio.
Ele vira sábio depois do erro.

➡️ Ambiente de testes permanente.

---

🎌 Tricksters e Anime: não é coincidência

Todo fã de anime já conhece tricksters, mesmo sem chamar assim:

• Goku (início) → Sun Wukong

• Luffy → Trickster caótico

• Hisoka → Trickster sombrio

• Gojo → Quebra regras conscientemente

Anime ama tricksters porque:

• Eles desafiam hierarquia

• Crescem fora do sistema

• Revelam hipocrisia

➡️ Shōnen inteiro é um grande test case contra autoridade absoluta.

---

🧩 Easter eggs culturais

🥚 Tricksters quase sempre:

• Fingem ser burros

• Caem em armadilhas que eles mesmos criam

• Morrem… e voltam

• Nunca aprendem totalmente

🥚 Eles não querem destruir o sistema
👉 Querem mostrar que ele não funciona como promete

---

🧠 O Trickster no ambiente corporativo (cuidado!)

Existe o trickster moderno:

• O cara que responde e-mail literalmente

• O analista que segue processo ruim até quebrar

• O dev que pergunta “é isso mesmo?”

⚠️ Atenção:
Nem todo ambiente aceita tricksters.
Alguns preferem sistemas injustos funcionando do que sistemas questionados.

---

💬 Comentário Bellacosa Mainframe

Mainframers entendem tricksters porque vivem em ambientes onde:

• Regras antigas ainda mandam

• Documentação nem sempre reflete a realidade

• Quem entende o sistema sobrevive melhor que quem manda

O trickster é o COBOL humano:

• Velho

• Subestimado

• Mas essencial

---

🏁 Encerramento – JOB STATUS

Tricksters existem porque:

• Sistemas são feitos por humanos

• Humanos erram

• E alguém precisa provar isso sem derrubar tudo

Eles são:

• O riso no meio da opressão

• A inteligência do fraco

• O teste de integridade cultural

JOB FINALIZADO
RC=0
SYSOUT: “Sistema exposto, mas ainda rodando.”

📉 Por que o MS Project caiu em desuso nas equipes modernas?

Bellacosa Mainframe apresenta o fim do Ms Project

Ao estilo Bellacosa Mainframe — direto, pragmático e sem romantizar ferramenta legada:

---

📉 Por que o MS Project caiu em desuso nas equipes modernas?

O MS Project nasceu em um mundo onde planejar era mais importante do que aprender.
Projetos eram previsíveis, lineares e comandados por um Project Manager centralizador.
Esse mundo acabou.

Hoje, projetos mudam toda semana.
E o MS Project não lida bem com mudança constante.

---

⚙️ O que mudou no jogo

1️⃣ Do Plano Fixo para o Fluxo Contínuo

• MS Project → cronograma fechado, dependências rígidas

• Mundo atual → backlog vivo, prioridades dinâmicas

Atualizar um Gantt a cada mudança:

• consome tempo

• não gera valor

• cria falsa sensação de controle

---

2️⃣ Do Comando e Controle para Times Autônomos

• MS Project pressupõe:

  • um dono do plano

  • tarefas atribuídas de cima para baixo

• Agile / DevOps exigem:

  • auto-organização

  • visibilidade compartilhada

  • decisão no nível do time

O MS Project não conversa com times auto-geridos.

---

3️⃣ Planejamento por Datas vs Planejamento por Valor

• MS Project pergunta: “quando termina?”

• Agile pergunta: “qual valor entregamos agora?”

Hoje, valor entregue > cronograma perfeito.

---

🔁 Quem ocupou o lugar do MS Project?

O MS Project não teve um substituto direto.
Ele foi desmontado em partes.

🔹 Planejamento e Backlog

• Jira

• Azure DevOps

• Rally

👉 substituíram o planejamento detalhado por backlog priorizado

---

🔹 Fluxo de Trabalho

• Kanban Boards

• Trello

• Jira Boards

👉 substituíram o Gantt por fluxo visual em tempo real

---

🔹 Roadmap e Visão

• Product Roadmap

• Product Vision

• OKRs

👉 substituíram o cronograma mestre por direção estratégica flexível

---

🔹 Execução e Métricas

• Velocity

• Lead Time

• Cycle Time

• Burnup / Burndown

👉 substituíram o % completo do MS Project, que nunca refletiu a realidade

---

🧠 O verdadeiro motivo do desuso

O MS Project não é ruim.
Ele só resolve um problema que quase não existe mais.

Projetos previsíveis, estáveis, com escopo fechado.

Hoje temos:

• produto em evolução

• requisitos emergentes

• integração contínua

• entrega contínua

MS Project não acompanha ritmo de pipeline.

---

🧾 Onde o MS Project ainda sobrevive

Ele não morreu.
Virou ferramenta de exceção:

• Engenharia pesada

• Construção civil

• Infraestrutura tradicional

• Projetos regulatórios com escopo fechado

👉 Onde mudança é inimiga, não aliada.

---

🔚 Conclusão Bellacosa

MS Project planeja projetos.
Agile gerencia incerteza.

Quando a incerteza virou regra,
o MS Project virou peça de museu corporativo.

Bellacosa Mainframe apresenta o primeiro controle de versão IEBUPDATE

---

🍔💾 Before Git Was Cool

O primeiro controle de versão no mainframe (e por que você já usou sem saber)

Midnight Lunch Edition – para ler entre um batch e outro

Hoje todo mundo fala de Git como se controle de versão tivesse surgido junto com startup, hoodie e café cold brew.
Mas quem viveu (ou herdou) ambiente mainframe sabe: o problema é antigo — e a solução também.

Antes de existir “version control”, já existia controle de mudanças.
E spoiler: o mainframe resolveu isso décadas antes do Git.

---

🏛️ Quando “controle de versão” ainda não tinha nome

Nos anos 60, a pergunta já era a mesma que ecoa hoje nos times DevOps:

• Quem mexeu nesse source?

• Qual versão está em produção?

• Por que ontem funcionava e hoje abenda?

A diferença é que:

• Não existia terminal bonito

• Não existia branch

• Não existia merge

• Existia batch, cartão perfurado e PDS

---

🥇 O verdadeiro pioneiro: IEBUPDTE

📅 Ano de lançamento: 1964
🏭 Fabricante: IBM
🖥️ Ambiente: OS/360

O IEBUPDTE não era vendido como “controle de versão”, mas na prática ele fazia exatamente isso:

👉 Controle estruturado de alterações em código-fonte

---

🧠 O que o IEBUPDTE fazia (na raça)

• Aplicava deltas (ADD / DEL / CHANGE)

• Atualizava membros em PDS

• Permitida reconstrução de versões

• Mantinha histórico dentro do próprio source

• Funcionava 100% batch-first

Exemplo clássico:

./ ADD NAME=PROG1
000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. PROG1.
./ ENDUP

Ou removendo código:

./ DEL 000300-000500

📌 Diff e patch antes do diff existir.

---

✅ O que ele fazia bem

✔️ Controle linha a linha
✔️ Reprodutibilidade
✔️ Integração total com o SO
✔️ Auditoria via JCL
✔️ Simplicidade brutal

❌ O que ele não fazia

✖️ Branch
✖️ Merge
✖️ Concorrência elegante
✖️ UX amigável
✖️ Marketing 😅

---

🟠 O primeiro “controle de versão moderno”: SCCS

📅 1972
🏭 Bell Labs (AT&T)

O SCCS (Source Code Control System) não nasceu no mainframe, mas trouxe os conceitos que moldaram tudo depois:

• Check-in / check-out

• Histórico separado do código

• Identificação automática de versão

• Deltas reversíveis

@(#)program.c 1.3

Se você usa Git hoje, agradeça silenciosamente ao SCCS.

---

⚔️ Outros nomes da época (não proprietários)

🟤 CMS UPDATE (VM/CMS)

Um IEBUPDTE interativo.
Simples, direto e extremamente eficiente em ambientes VM.

🟣 RCS (1982)

Evolução do SCCS, mais simples, mais elegante — ainda sem branches decentes.

---

🚫 E os famosos “controladores de biblioteca”

(menção honrosa, sem aprofundar)

• PANVALET

• LIBRARIAN

Eles dominaram o mercado, mas não inventaram o conceito.
Só empacotaram, venderam e deram manual grosso.

---

🥚 Easter Eggs de CPD

🥚 Easter Egg #1
IEBUPDTE é mais parecido com git apply do que com git commit.

🥚 Easter Egg #2
Comentário no COBOL tipo:

* ALTERADO POR CARLOS EM 12/08/1989

➡️ Isso é controle de versão manual.
Herança direta da era pré-ferramenta.

🥚 Easter Egg #3
Controle de versão nasceu batch-first.
CI/CD moderno só está reaprendendo isso.

🥚 Easter Egg #4
Se o histórico está no source, é porque um dia não existia repositório.

---

🧓 Filosofia Bellacosa Mainframe

“O Git não inventou controle de versão.
Ele só colocou uma interface moderna numa ideia que o mainframe já resolvia quando computador ocupava uma sala inteira.”

---

📌 Resumo para guardar no bolso

Ferramenta	Ano	Tipo	Origem
IEBUPDTE	1964	Controle de mudanças	IBM
CMS UPDATE	~1969	Controle de mudanças	IBM
SCCS	1972	Version control formal	Bell Labs
RCS	1982	Version control	Unix

---

🍔 Midnight Lunch Final Thought

Enquanto o mundo discute GitOps, trunk-based e feature flags, o mainframe segue ali, quieto, lembrando:

“Nada disso é novo. Só mudou o hype.”

---

 

Bellacosa Mainframe apresenta Murasaki Shikibu a primeira romancista da historia

📜 Murasaki Shikibu – a mulher que escreveu o primeiro “sistema operacional” da literatura

Antes de existir romance, antes de existir “novel”, antes de existir protagonista com crise existencial…
existiu Murasaki Shikibu.

E não, ela não escreveu qualquer coisa.
Ela escreveu Genji Monogatari (源氏物語) — O Conto de Genji — considerado por muitos historiadores o primeiro romance psicológico da história da humanidade.

Sim.
Enquanto a Europa ainda estava preocupada em não pegar peste, o Japão já estava rodando literatura nível enterprise.

---

Murasaki Shikibu

👘 Quem foi Murasaki Shikibu?

Murasaki Shikibu viveu por volta do ano 978 até cerca de 1014, durante o Período Heian, uma era marcada por refinamento estético, intrigas de corte e poesia como moeda social.

Ela era:

• Dama da corte imperial

• Intelectual autodidata

• Leitora de clássicos chineses (algo raríssimo para mulheres da época)

• Observadora silenciosa da elite japonesa

Curiosidade importante:
“Murasaki Shikibu” não é o nome real dela.

👉 “Murasaki” vem de uma personagem do próprio Genji
👉 “Shikibu” refere-se ao cargo do pai no Ministério dos Ritos

Ou seja:

Ela virou user ID histórico baseado na própria obra.

---

📚 O trabalho: Genji Monogatari

O Conto de Genji não é um livro curto.
São 54 capítulos, centenas de personagens, décadas de eventos e uma profundidade emocional absurda.

O protagonista:

• Hikaru Genji, o “Príncipe Brilhante”

• Belo, educado, poderoso… e profundamente humano

O diferencial?

• Não é uma história de herói

• É uma história de emoções, arrependimentos, impermanência

Nada de final feliz padrão.
Aqui tem debug emocional.

---

🧠 Por que isso foi revolucionário?

Antes de Murasaki:

• Histórias épicas

• Mitológicas

• Religiosas

Depois de Murasaki:

• Pessoas complexas

• Amor não correspondido

• Ciúmes

• Solidão

• Passagem do tempo

Ela escreveu sobre:

• Mulheres esquecidas

• Amores silenciosos

• Relações que não escalam

• A dor de envelhecer

É quase um log de produção da alma humana.

---

🏯 Contexto histórico: a corte Heian

A corte japonesa era:

• Extremamente hierárquica

• Obcecada por aparência

• Governada por etiqueta, poesia e fofoca

Sim, fofoca.

Cartas eram escritas em forma de poema.
Uma escolha errada de palavra podia:

• arruinar reputações

• encerrar relacionamentos

• causar exílio social

Murasaki observava tudo isso em silêncio, como um sysprog cultural, registrando comportamentos.

---

👀 Fofocas & bastidores

📌 Dizem que Murasaki era:

• Reservada

• Crítica

• Pouco impressionada com a corte

Ela escreveu em seu diário críticas diretas a colegas, chamando algumas de:

“superficiais e barulhentas”

Sim, ela era low profile, mas afiada.

📌 Há indícios de que:

• Parte do Genji seja autobiográfica

• Alguns personagens sejam sátiras disfarçadas da corte

Shadow IT literário.

---

🥚 Easter eggs culturais

• O Genji Monogatari influenciou:

  • Mangás

  • Animes

  • Dramas históricos (taiga dramas)

  • Estética do shōjo moderno

• O conceito japonês de mono no aware (a beleza da impermanência)
  👉 foi cristalizado ali

• Muitos clichês de anime:

  • Amores silenciosos

  • Personagens melancólicos

  • Relações que não se resolvem
    têm DNA Genji

---

🧬 Legado

Murasaki Shikibu deixou:

• O primeiro romance psicológico

• Uma nova forma de narrar o humano

• A base emocional da literatura japonesa

Ela provou que:

Observar é tão poderoso quanto agir.

E que:

Histórias mudam o mundo sem fazer barulho.

---

⚙️ Tradução para o mundo mainframe

Murasaki Shikibu era:

• Uma analista funcional da alma

• Uma arquiteta de sistemas emocionais

• Uma escritora que entendia estado, contexto e transição

Seu texto:

• Não força eventos

• Não acelera resoluções

• Respeita o tempo

Como um sistema legado bem projetado, que envelhece com dignidade.

---

☕ Comentário final estilo El Jefe Midnight Lunch

Num mundo que grita, Murasaki escreveu em sussurros.
Num ambiente competitivo, ela observou.
Num sistema rígido, ela criou algo eterno.

Mais de mil anos depois, ainda estamos lendo, adaptando e sentindo.

Isso não é moda.
Isso é arquitetura cultural.

 

Bellacosa Mainframe apresenta IBM SMP/E

🧩 SMP/E + RACF na prática

Onde manutenção encontra segurança (e o auditor sorri)

“Não adianta proteger usuário se qualquer um pode mudar o sistema.”

---

🧠 Por que SMP/E precisa de RACF?

SMP/E controla o código do z/OS.
RACF controla quem pode tocar nesse código.

👉 Separados, são fortes.
👉 Juntos, são governança.

---

🔐 O que exatamente deve ser protegido?

🎯 Alvos críticos

• CSI (Consolidated Software Inventory)

• SMP/E libraries

• Datasets TARGET e DLIB

• JCL de manutenção

• Procedimentos de APPLY/ACCEPT

📌 Quem altera isso altera o sistema inteiro.

---

🧩 Princípio da menor permissão

Não existe:

“Acesso total para facilitar.”

Existe:

• Acesso mínimo

• Temporário

• Auditável

---

🧾 Protegendo o CSI

Recomendação clássica

• DATASET profile no RACF

• UACC=NONE

• ALTER só para sysprog autorizado

• READ para auditoria

📌 CSI é prova histórica.

---

🛡️ Protegendo bibliotecas SMP/E

• SMPTLIB

• SMPMTS

• SMPPTS

• SMPSCDS

👉 Controle separado de produção e teste.

💡 Dica Bellacosa:

“Quem pode escrever no SMPMTS pode quebrar o sistema.”

---

👥 Segregação de funções (SOX friendly)

Função	Permissão
Sysprog	APPLY
Change Mgmt	Aprovar
Auditor	READ
Operação	Executar JCL controlado

📌 Uma pessoa não deve fazer tudo.

---

🔎 Auditoria e rastreabilidade

Auditor pergunta:

• Quem aplicou?

• Quando?

• O quê?

• Por quê?

👉 SMP/E responde
👉 RACF confirma

---

🧪 APPLY CHECK como controle

• APPLY CHECK obrigatório

• Output guardado

• Assinatura de mudança

💡 Dica Bellacosa:

“APPLY CHECK é evidência de controle.”

---

🚨 Cenário de risco real

Sysprog com ALTER irrestrito
USERMOD sem controle
ACCEPT em produção
Auditor encontra

📌 Resultado:

• Não conformidade

• Risco operacional

• Stress garantido

---

🛠️ Boas práticas recomendadas

✔ Perfis RACF específicos
✔ Logging ativo
✔ Revisão periódica
✔ Separação TEST/PROD
✔ Documentação SMP/E

---

🧠 Curiosidades Bellacosa

• Auditor confia mais no CSI do que em planilha

• RACF mal configurado invalida SMP/E

• Segurança começa no dataset

---

🧾 Comentário final – SMP/E + RACF

RACF protege acesso.
SMP/E protege integridade.
Juntos, protegem o negócio.

🧩🛡️💾🔥