Gakuen Mokushiroku: Highschool of the Dead — Quando o Datacenter da Humanidade Entrou em ABEND e Apenas os Operadores Sobreviveram

 

Bellacosa Mainframe apresenta Highschool of the Dead

☕ Um Café no Bellacosa Mainframe

Gakuen Mokushiroku: Highschool of the Dead — Quando o Datacenter da Humanidade Entrou em ABEND e Apenas os Operadores Sobreviveram

"Todo sistema é considerado confiável... até o primeiro desastre real. Highschool of the Dead mostra exatamente o que acontece quando o planeta inteiro perde o operador."

---

Ficha Técnica

Título Original: 学園黙示録 HIGHSCHOOL OF THE DEAD (Gakuen Mokushiroku: Highschool of the Dead)

Título Internacional: Highschool of the Dead

Autor (Mangá):

• Daisuke Satō (roteiro)

• Shōji Satō (arte)

Estúdio: Madhouse

Diretor: Tetsurō Araki

Composição da Série: Yōsuke Kuroda

Design de Personagens: Masayoshi Tanaka

Música: Takafumi Wada

Mangá

• Publicado entre 2006 e 2013

• Revista Monthly Dragon Age

Anime

• Lançamento: 5 de julho de 2010

• Exibição: julho a setembro de 2010

OVA

• Drifters of the Dead (2011)

Quantidade de episódios

• 12 episódios

• 1 OVA

---

Classificação

• 🔞 17+ (em muitos países)

• Violência extrema

• Sangue

• Terror

• Nudez parcial

• Conteúdo sexual

• Linguagem adulta

Não é um anime indicado para crianças.

---

Gêneros

• Horror

• Zumbis

• Sobrevivência

• Ação

• Suspense

• Ecchi

• Drama

• Pós-apocalipse

---

Sinopse

Tudo começa em uma manhã aparentemente comum.

Enquanto os alunos seguem sua rotina escolar, uma estranha epidemia transforma pessoas em mortos-vivos extremamente agressivos.

Em questão de minutos, a escola inteira se torna um cenário de massacre.

Takashi Komuro consegue escapar junto de alguns colegas, iniciando uma longa jornada para encontrar familiares, abrigo e respostas.

Mas rapidamente descobrem uma verdade:

Os mortos não são necessariamente o maior perigo.

Quando a sociedade deixa de existir, o verdadeiro monstro passa a ser o próprio ser humano.

---

Resumo da História

O anime acompanha um pequeno grupo de estudantes tentando sobreviver ao colapso da civilização japonesa.

Eles atravessam:

• escolas

• bairros residenciais

• estradas

• delegacias

• mansões

• cidades completamente destruídas

Cada episódio representa um novo desafio.

Não existe governo.

Não existe polícia.

Não existe exército funcional.

Não existe internet.

Não existe logística.

Tudo aquilo que sustentava a sociedade desapareceu em poucas horas.

---

Os Personagens

Takashi Komuro

O protagonista.

Não é o mais forte.

Não é o mais inteligente.

Mas possui algo extremamente importante:

Capacidade de tomar decisões sob pressão.

No universo Bellacosa Mainframe, ele seria o Operador Master durante um desastre de produção.

---

Rei Miyamoto

Especialista em combate com lança.

Representa o lado emocional do grupo.

É também quem mantém parte da humanidade dos sobreviventes.

---

Saeko Busujima

Talvez uma das personagens femininas mais populares dos animes.

Excelente espadachim.

Calma.

Precisa.

Controlada.

Ela lembra um Sysprog experiente:

Não desperdiça movimentos.

Não desperdiça recursos.

---

Saya Takagi

A arquiteta.

O cérebro.

Enquanto todos pensam em sobreviver ao próximo minuto, Saya pensa nas próximas semanas.

Ela é praticamente uma Analista de Sistemas.

---

Kōta Hirano

Especialista em armas.

No início parece apenas um nerd.

Depois demonstra enorme capacidade técnica.

É o equivalente ao especialista de infraestrutura que conhece profundamente as ferramentas.

---

Shizuka Marikawa

A enfermeira.

Representa logística, primeiros socorros e transporte.

Sem ela o grupo dificilmente sobreviveria.

---

A Temática

À primeira vista parece apenas um anime de zumbis.

Na realidade fala sobre:

• colapso social

• ética

• medo

• liderança

• sobrevivência

• egoísmo

• confiança

• adaptação

O vírus é apenas o gatilho.

O verdadeiro tema é:

Como seres humanos reagem quando toda estrutura desaparece.

---

O que existe de diferente?

Muitos animes possuem zumbis.

Pouquíssimos possuem:

Ritmo extremamente acelerado

O desastre começa nos primeiros minutos.

Não existe preparação.

O espectador entra imediatamente no caos.

---

Personagens relativamente "normais"

Não existem poderes mágicos.

Não existem espadachins lendários.

São estudantes comuns.

Isso aumenta muito a sensação de realismo.

---

Ação cinematográfica

O diretor Tetsurō Araki mais tarde faria enorme sucesso em Attack on Titan.

Já era possível perceber seu estilo:

• câmeras rápidas

• enquadramentos dramáticos

• tensão constante

---

Violência gráfica

Em 2010 poucos animes apresentavam um nível tão alto de violência.

---

Ecchi exagerado

É o aspecto mais controverso da obra.

Em vários momentos o fan service interrompe completamente a tensão.

Para alguns isso faz parte da identidade da série.

Para outros prejudica o horror.

---

As Aventuras

Cada arco representa uma etapa da sobrevivência.

• escapar da escola

• encontrar abrigo

• procurar familiares

• buscar alimentos

• fugir de saqueadores

• enfrentar grupos armados

• lidar com governos inexistentes

Não existe "missão principal".

A missão é continuar vivo.

---

As Mensagens Ocultas

A civilização é extremamente frágil

Levamos décadas para construir uma sociedade.

Podemos perdê-la em poucos dias.

---

O conhecimento vale mais que força

Saya salva o grupo inúmeras vezes usando inteligência.

Não músculos.

---

Liderança não depende de cargo

Takashi nunca foi líder.

As circunstâncias o obrigam a assumir essa função.

---

Recursos são limitados

Comida.

Combustível.

Remédios.

Munição.

Tudo acaba.

A sobrevivência depende de planejamento.

---

O medo transforma pessoas

Durante o anime vemos cidadãos comuns se tornando criminosos.

O verdadeiro vírus talvez seja o desespero.

---

Bellacosa Mainframe

O Grande ABEND Mundial

Imagine que a humanidade inteira seja um gigantesco ambiente IBM Z.

De repente acontece um desastre.

• JES2 para de controlar filas.

• CICS perde conectividade.

• DB2 deixa de responder.

• MQ interrompe mensagens.

• O operador desaparece.

• O WLM deixa de distribuir carga.

O ambiente continua ligado.

Mas não existe mais coordenação.

É exatamente isso que acontece em Highschool of the Dead.

Os zumbis são processos que continuam executando.

Consomem CPU.

Consumem memória.

Propagam corrupção.

Mas perderam completamente sua lógica de negócio.

Enquanto isso, os sobreviventes tentam manter o "Sistema Operacional Sociedade" funcionando.

Takashi torna-se o Incident Manager.

Saya atua como arquiteta.

Saeko é a equipe de resposta imediata.

Kōta administra os recursos críticos.

Shizuka representa Disaster Recovery.

No fundo, o anime inteiro pode ser interpretado como um enorme exercício de:

• Business Continuity

• Disaster Recovery

• Gestão de Incidentes

• Gestão de Crises

• Resiliência Operacional

---

Impacto Cultural

Quando estreou em 2010, Highschool of the Dead tornou-se um enorme sucesso.

Foi um dos responsáveis por popularizar novamente o gênero zumbi nos animes.

Influenciou diversas obras posteriores.

Também consolidou a reputação do estúdio Madhouse em animações de ação extremamente fluidas.

Até hoje permanece como referência quando se fala em animes de sobrevivência.

---

Houve censura?

Sim.

Este é um dos animes mais censurados de sua época.

Dependendo da emissora e do país, cenas receberam:

• escurecimento da tela (black shading);

• feixes de luz (light beams) para ocultar nudez;

• neblina ou fumaça digital;

• cortes de enquadramento;

• redução de violência gráfica.

As versões em Blu-ray removeram grande parte dessas censuras, apresentando a obra em sua forma originalmente produzida.

Além disso, alguns países restringiram sua classificação indicativa devido ao conteúdo sexual e à violência intensa.

---

Por que nunca ganhou uma segunda temporada?

Essa é uma das maiores frustrações dos fãs.

O mangá sofreu longos hiatos por problemas de saúde do roteirista Daisuke Satō. Em 2017, o autor faleceu, deixando a história inacabada. Sem material suficiente e sem uma conclusão oficial, uma continuação do anime nunca foi produzida.

---

Vale a pena assistir?

Mesmo anos após seu lançamento, Gakuen Mokushiroku: Highschool of the Dead continua relevante por combinar ação frenética, horror, suspense e discussões sobre comportamento humano em situações extremas. Embora o fan service possa dividir opiniões, a qualidade da animação, a direção dinâmica e a construção da tensão fazem dele um clássico do gênero zumbi nos animes.

Veredicto Bellacosa Mainframe

Se The Walking Dead mostra como administrar uma comunidade após o colapso, Highschool of the Dead retrata o momento exato em que o ambiente entra em falha catastrófica.

Para um profissional de IBM Z, é como acompanhar um ABEND sistêmico onde não há IPL, backup imediato ou equipe de plantão. Cada decisão precisa ser tomada com os recursos disponíveis, priorizando continuidade de serviço, resiliência e cooperação.

No fim, a grande lição da obra é clara: a tecnologia pode manter sistemas funcionando, mas são as pessoas, sua capacidade de adaptação e liderança, que determinam se uma organização — ou uma civilização — sobreviverá ao desastre.

 

Bellacosa Mainframe explica o JSON

🔥☕ JSON: O “COBOL DOS DADOS MODERNOS”? — A Linguagem Invisível Que Dominou APIs, Nuvem e Até o Mainframe ☕🔥

“Enquanto muita gente ainda pensava em arquivos texto… o JSON já estava preparando o planeta para microserviços, APIs e integração global.”

---

🚀 Introdução — O Formato Que Conquistou o Mundo

Se existe algo que une JavaScript, Python, Java, Node.js, Kubernetes, APIs REST, Open Banking, cloud e até o z/OS… esse algo é o JSON.

Sim…

Aquele bloco aparentemente simples:

{
  "cliente": "BELLACOSA",
  "conta": 12345,
  "saldo": 9999.99
}

Hoje parece trivial.

Mas o impacto do JSON na computação foi monstruoso.

Ele virou:

• o idioma oficial das APIs,
• a “cola” da internet moderna,
• o padrão universal de troca de dados,
• e uma das maiores revoluções silenciosas da computação corporativa.

E o mais curioso?

O JSON nasceu de forma extremamente simples… quase como um “truque elegante” dentro do JavaScript.

---

🧠 Quem Criou o JSON?

O JSON foi criado por:

👨 Douglas Crockford

Programador, arquiteto de software e evangelista JavaScript.

---

📅 Data de Criação

O JSON começou a ganhar forma por volta de:

📌 2001

E foi oficialmente popularizado entre:

📌 2002–2005

---

🌍 O Problema Que o JSON Resolveu

Antes do JSON, integração era quase sempre baseada em:

• XML
• CSV
• Arquivos posicionais
• Protocolos binários
• EDI
• Mensagens proprietárias

O problema?

Tudo era:

• pesado,
• verboso,
• lento,
• difícil de ler,
• difícil de debugar.

Exemplo de XML:

<cliente>
   <nome>BELLACOSA</nome>
   <saldo>9999.99</saldo>
</cliente>

Agora compare com JSON:

{
   "nome": "BELLACOSA",
   "saldo": 9999.99
}

Menos ruído.
Mais legibilidade.
Mais velocidade.
Mais simplicidade.

E o mercado enlouqueceu.

---

⚡ O Grande Segredo do JSON

O JSON nasceu inspirado diretamente nos objetos JavaScript.

Na prática:

var cliente = {
   nome: "BELLACOSA",
   saldo: 9999.99
}

Douglas Crockford percebeu:

“E se isso virar um formato universal de troca de dados?”

E virou.

---

🔥 O JSON Explodiu Com as APIs REST

Quando APIs REST começaram a dominar o mercado…

o JSON virou praticamente obrigatório.

Porque:

• era leve,
• rápido,
• fácil de parsear,
• perfeito para internet,
• amigável para humanos.

Resultado?

O XML começou a perder espaço rapidamente.

---

☕ O Mainframe Não Ficou de Fora

Aqui começa a parte interessante para o mundo COBOL.

Muita gente achava:

“Mainframe nunca vai falar JSON.”

Erro histórico.

Hoje o z/OS conversa JSON o tempo inteiro:

• APIs REST
• z/OS Connect
• CICS Web Services
• MQ
• Kafka
• Open Banking
• Microsserviços
• Cloud híbrida

O JSON virou peça fundamental da modernização mainframe.

---

🧠 COBOL + JSON = O Casamento Corporativo Moderno

A IBM percebeu rapidamente:

Se o mainframe quisesse continuar reinando…
precisaria falar JSON nativamente.

E então vieram recursos modernos como:

📌 JSON PARSE

e

📌 JSON GENERATE

no Enterprise COBOL.

---

🚀 Exemplo COBOL Moderno Com JSON

Gerando JSON

IDENTIFICATION DIVISION.
PROGRAM-ID. GERJSON.

DATA DIVISION.

WORKING-STORAGE SECTION.

01 CLIENTE.
   05 NOME      PIC X(20) VALUE 'BELLACOSA'.
   05 SALDO     PIC 9(5)V99 VALUE 99999.99.

01 JSON-SAIDA  PIC X(200).

PROCEDURE DIVISION.

JSON GENERATE JSON-SAIDA
   FROM CLIENTE

DISPLAY JSON-SAIDA.

STOP RUN.

Saída:

{"NOME":"BELLACOSA","SALDO":99999.99}

---

🔥 Parsing JSON no COBOL

Recebendo API REST

JSON PARSE JSON-ENTRADA
   INTO CLIENTE

Isso foi revolucionário no z/OS.

Porque eliminou:

• parsers manuais,
• tratamentos absurdos,
• lógica artesanal,
• conversões complexas.

---

🧠 O Que Tornou o JSON Tão Poderoso?

📌 1. Legibilidade Humana

Até operador consegue entender.

---

📌 2. Estrutura Hierárquica

Permite:

• objetos,
• listas,
• arrays,
• árvores complexas.

---

📌 3. Independência de Linguagem

Funciona em:

• COBOL
• Java
• Python
• Go
• Node.js
• Rust
• RPG
• PL/I

---

📌 4. Perfeito Para APIs

JSON praticamente virou:

“o TCP/IP da integração moderna.”

---

⚠️ Desvantagens do JSON

Nem tudo são flores.

---

❌ 1. Sem Tipagem Forte

JSON puro não define:

• decimal fixo,
• packed decimal,
• COMP-3,
• datas reais.

Isso gera problemas em integrações financeiras.

---

❌ 2. Overhead de Texto

JSON é texto.

Protocolos binários podem ser mais rápidos.

---

❌ 3. Segurança

Parsing inseguro pode causar:

• injection,
• payload malicioso,
• consumo excessivo de memória.

---

❌ 4. Precisão Numérica

Problema clássico:

• valores financeiros,
• arredondamentos,
• IEEE floating point.

O mainframe sofre muito menos disso graças ao decimal packed.

---

🔥 Curiosidades Históricas

☕ JSON NÃO É Linguagem

Apesar do nome:

JavaScript Object Notation

JSON NÃO é uma linguagem de programação.

É apenas um formato de dados.

---

☕ O JSON Virou Padrão Oficial

RFC oficial:

📌 RFC 8259

---

☕ XML Dominava Absolutamente

Antes do JSON:

• SOAP,
• WSDL,
• XML Schema,
• namespaces,
• tags gigantescas.

Parecia um ritual mágico corporativo.

JSON chegou como uma motosserra.

---

💣 Easter Egg Histórico

Douglas Crockford chegou a remover referências perigosas do JavaScript porque:

📌 JSON podia executar código involuntariamente

No começo muita gente fazia:

eval(json)

Isso virou um pesadelo de segurança.

Daí nasceram parsers seguros.

---

🚀 JSON no Mundo Mainframe Moderno

Hoje o JSON está em todo lugar no z/OS:

Tecnologia	Uso
z/OS Connect	APIs REST
CICS	Web Services
IMS	Integração moderna
MQ	Mensageria
Kafka	Streaming
Db2 REST	APIs corporativas
Open Banking	Payloads financeiros
Cloud híbrida	Microsserviços

---

🔥 O JSON Mudou o Papel do Programador COBOL

Antigamente:

• COBOL manipulava arquivos,
• VSAM,
• copybooks,
• EBCDIC.

Hoje o COBOL moderno:

• consome APIs,
• gera REST,
• fala HTTP,
• troca JSON,
• integra cloud,
• conversa com Kubernetes.

O programador COBOL virou:

engenheiro de integração corporativa.

---

☕ Comparação Filosófica: JSON vs Copybook COBOL

Curiosamente…

JSON lembra MUITO a ideia dos copybooks.

Veja:

Copybook

01 CLIENTE.
   05 NOME PIC X(20).
   05 SALDO PIC 9(5)V99.

JSON

{
   "NOME": "BELLACOSA",
   "SALDO": 99999.99
}

Ambos descrevem estrutura de dados.

A diferença?

O JSON atravessa internet, nuvem e APIs.

---

🧠 O Verdadeiro Motivo do Sucesso do JSON

Não foi tecnologia.

Foi simplicidade.

O JSON venceu porque:

• humanos entendem,
• programadores gostam,
• APIs adoram,
• clouds dependem,
• empresas inteiras padronizaram nele.

---

💣 Conclusão — O JSON Virou a “Nova Linguagem Universal”

O JSON não matou o COBOL.

Na verdade…

Ele ajudou o COBOL a sobreviver à era cloud.

Hoje o mainframe continua relevante porque aprendeu:

• REST,
• APIs,
• microsserviços,
• containers,
• integração moderna,
• e principalmente…
• JSON.

E talvez essa seja a maior ironia da computação:

O formato que nasceu no JavaScript acabou ajudando o z/OS a continuar dominando o coração financeiro do planeta.

---

☕ Frase Final no Estilo Bellacosa Mainframe

“O COBOL continua processando bilhões… mas agora conversa com o mundo em JSON.” 🔥🚀

 

SMP/E for z/OS Workshop : LIST & REPORT Commands

 

Bellacosa Mainframe apresenta SMP/E List and Report Commands

SMP/E for z/OS Workshop

ACCEPT Processing – LIST & REPORT Commands

Quando olhar o CSI é tão importante quanto instalar o código

Instalar SYSMOD qualquer um instala.
Agora… saber exatamente o que está instalado, onde, por quê e com qual dependência
👉 isso separa operador de System Programmer.

É aqui que entram os comandos LIST e REPORT.

---

LIST Command

Abrindo o CSI como quem abre o capô do sistema

O comando LIST é o bisturi do SMP/E.
Ele não interpreta, não deduz, não opina.
Ele mostra os fatos gravados no CSI.

📌 O LIST pode extrair informações de:

• Global Zone

• Target Zone

• Distribution Zone

• SMPPTS

• SMPLOG

• SMPSCDS

💡 Easter egg #1

Se você confia mais na memória do que no LIST,
o CSI vai te humilhar em algum momento.

---

Boundary: o detalhe que separa sucesso de confusão

Antes de usar LIST, você define o boundary:

• Global Zone → acesso a SMPPTS

• Zona com DDDEF do SMPLOG

• Target Zone associada ao SMPSCDS

• Ou tudo de uma vez com:

ALLZONES

⚠️ ALLZONES lista tudo que existe, não tudo que você quer ver.

💡 Easter egg #2

ALLZONES às 3 da manhã
é como dar SELECT * em produção.

---

O que dá pra listar no Global Zone

Com LIST você pode ver:

• OPTIONS

• UTILITIES

• DDDEFs

• FMIDSETs

• ZONESETs

• SYSMOD entries

• MCS entries do SMPPTS

• HOLDDATA (++HOLD)

HOLDDATA com lupa

Você pode filtrar por:

• HOLDERROR

• HOLDSYSTEM

• HOLDUSER

E ainda combinar com SYSMOD específico.

📌 Se combinar filtros demais, o SMP/E só lista
entradas que satisfaçam todos.

---

Filtros avançados (onde mora o poder)

LIST aceita os mesmos refinamentos do APPLY/ACCEPT:

• SOURCEID

• EXSRCID

• FORFMID

• XZLMOD

• XZLMODP

• XREF

👉 Ideal para:

• Debug de dependência

• Auditoria

• Pós-migração

• Comparação entre ambientes

💡 Easter egg #3

SOURCEID bem usado
vale mais que planilha paralela.

---

LIST em Target e Distribution Zones

Além do básico, você pode listar:

• TARGETZONE definition

• DLIBZONE definition

• DDDEFs

• ELEMENT entries:

  • MOD

  • MAC

  • SRC

  • JAR

  • HFS

• LMOD entries

SYSMOD entries com status

Você pode filtrar por:

• ERROR

• SUP (superseded)

• NOSUP

• RESTORE

• NOAPPLY

• NOACCEPT

• BYPASS

• DELETE

📌 SUP e NOSUP são mutuamente exclusivos.

💡 Easter egg #4

SYSMOD em ERROR não é bug
é aviso ignorado.

---

LIST LOG e BACKUP

• LIST LOG → conteúdo do SMPLOG

  • Total ou por intervalo de data

• LIST BACKUP → conteúdo do SMPSCDS

  • Tudo ou por SYSMOD específico

👉 LIST é o comando ideal para auditoria forense do SMP/E.

---

LIST vs DIALOG QUERY

LIST = dados brutos
QUERY = visão amigável

Quando a coisa aperta…
LIST sempre vence.

---

REPORT Command

Quando você precisa que o SMP/E pense por você

Se o LIST mostra,
o REPORT analisa.

Ele cruza zonas, dependências, FMIDs, SOURCEIDs e HOLDs
e ainda gera comandos prontos.

📌 REPORT é o SMP/E dizendo:

“relaxa, eu faço a correlação.”

---

REPORT CROSSZONE

Dependência entre produtos e zonas

Usado para responder:

“Instalei isso aqui… quebrou quem?”

Requisitos:

• ZONESET obrigatório

• Pode limitar por:

  • FMID

  • ZONE

O relatório mostra:

• Dependências cruzadas

• SYSMODs faltantes

• Se já foram RECEIVED

• Quem causou a dependência

👉 E ainda gera comandos SMP/E no SMPPUNCH

NOPUNCH

se você não quiser os comandos.

💡 Easter egg #5

SMPPUNCH esquecido
vira APPLY acidental.

---

REPORT ERRSYSMODS

Quando o passado volta pra cobrar

Identifica SYSMODs que:

• Já foram instalados

• Mas agora estão em ERROR HOLD

Pode analisar:

• Global Zone

• Target Zone

• Distribution Zone

Filtros:

• Data inicial / final

• FMID

O relatório mostra:

• SYSMOD afetado

• Reason ID

• Quem resolve

• ++HOLD completo

💡 Easter egg #6

ERROR HOLD não some
só muda de lugar.

---

REPORT SOURCEID

Quem veio de onde?

Descobre:

• Quais SOURCEIDs existem

• Quais SYSMODs usam cada um

Com ou sem filtro por SYSMOD.

👉 Excelente para:

• FIXCAT

• Hardware novo

• Coexistência

• Migração de release

---

REPORT SYSMODS

Comparação entre zonas

Usado para:

• Validar ambientes

• Comparar releases

• Checar desvio de serviço

Parâmetros:

• INZONE

• COMPAREDTO

Resultado:

• O que existe em uma zona

• E não existe na outra

• Com comandos prontos para corrigir

💡 Easter egg #7

Ambiente “igual” sem REPORT
é fé, não evidência.

---

REPORT MISSINGFIX (FIXCAT)

Adeus PSP Bucket manual

Disponível a partir do SMP/E 3.6.

Identifica:

• APARs faltantes

• Por categoria FIXCAT

• Para hardware, software e coexistência

Mostra:

• FIXCAT

• APAR

• PTF corretivo

• Dependências

• Problemas de HOLD

📌 Dois blocos:
1️⃣ Missing fixes
2️⃣ Resolving SYSMODs em erro

💡 Easter egg #8

FIXCAT bem usado
economiza fim de semana inteiro.

---

Bellacosa Summary – em poucas linhas

LIST mostra o que existe
REPORT explica o impacto
SMPPUNCH sugere a correção
Você decide se confia

---

Checklist Bellacosa – LIST & REPORT

✔ LIST antes de APPLY
✔ REPORT antes de migrar
✔ FIXCAT sempre atualizado
✔ SOURCEID bem definido
✔ SMPPUNCH revisado
✔ LOG nunca ignorado

---

Conclusão

Quem domina LIST e REPORT:

• Não instala no escuro

• Não depende de planilha

• Não descobre erro em produção

• Não briga com auditor

💡 Easter egg final

O SMP/E sempre soube a verdade.
Você só precisava perguntar direito.

Bellacosa Mainframe Storage e DASD 3390

---

💽 Tracks, Cilindros e DASD no IBM Mainframe

Arquitetura, não nostalgia

“O mainframe não mede storage em tracks e cilindros porque é antigo.
Ele faz isso porque sabe exatamente o que está fazendo.”

---

1️⃣ A origem da filosofia: quando hardware importava (e ainda importa)

Desde os primórdios do IBM System/360 (1964), o mainframe foi projetado com um princípio inegociável:

👉 Controle total do I/O

Naquela época:

• Disco era caro

• CPU era valiosa

• I/O era o gargalo

💡 Conclusão da IBM:

“Se o gargalo é I/O, precisamos dominar o disco até o último detalhe físico.”

Assim nascem os conceitos de:

• Track

• Cilindro

• Bloco

• Extent

Nada disso é acaso. É engenharia.

---

2️⃣ O que é um TRACK (pista) – o átomo do DASD

📀 Track é:

• Uma circunferência física no platter do disco

• Unidade mínima de alocação real

• Otimizada para leitura e escrita sequencial

Características importantes:

• Contém um ou mais blocos

• O tamanho em bytes não é fixo

• Depende de:

  • Dataset (PS, PO, VSAM)

  • BLKSIZE

  • Tipo de acesso

📏 Referência clássica (3390):

• ≈ 56 KB por track (didático, não absoluto)

🧪 Easter egg técnico:

Mesmo quando você pede espaço em MB,
o DFSMS converte tudo para tracks internamente 😎

---

3️⃣ O que é um CILINDRO – o segredo da performance

🛢️ Cilindro =
Conjunto de tracks alinhados verticalmente em todos os pratos do disco.

Por que isso é genial?

• O braço do disco não precisa se mover

• Menos seek

• Mais throughput

• Menos latência

📌 Em mainframe:

Performance não é pico, é constância.

---

IBM HD 3390

4️⃣ Modelos clássicos de DASD IBM (história viva)

📦 IBM 2311 / 2314

• Anos 60 / 70

• Discos removíveis

• Origem dos conceitos de cilindro

📦 IBM 3330 – “Merlin”

• Gigante físico

• Primeiro “big storage”

📦 IBM 3380

• Alta densidade

• Base para sistemas bancários dos anos 80

📦 IBM 3390 (o eterno)

• Padrão até hoje (logicamente)

• Modelos:

  • 3390-3 (~2,8 GB)

  • 3390-9 (~8,4 GB)

• Referência de cálculo de tracks/cilindros

📦 DS8000 (atual)

• Storage virtualizado

• Cache massivo

• Flash

• Mas… emula 3390
  😏

O mainframe moderniza sem quebrar o passado.

---

5️⃣ Evolução: do ferro ao virtual (sem perder o controle)

Hoje:

• Não existe mais “disco girando” como antes

• Temos:

  • Cache

  • Flash

  • Virtualização

  • Striping interno

Mas o z/OS continua falando em:

• Track

• Cilindro

• Extent

💡 Por quê?

Porque:

• SMF mede I/O em tracks

• WLM calcula impacto por volume

• SMS aloca espaço físico previsível

• Batch depende disso

---

6️⃣ Alocação no dia a dia (JCL raiz)

Exemplo clássico:

//ARQ1 DD DSN=MEU.ARQUIVO,
//         DISP=(NEW,CATLG,DELETE),
//         SPACE=(CYL,(10,5),RLSE),
//         DCB=(RECFM=FB,LRECL=80,BLKSIZE=0)

📌 Tradução para o padawan:

• 10 cilindros primários

• 5 cilindros secundários

• Espaço real

• Custo previsível

• Impacto conhecido

---

7️⃣ Performance: onde o mainframe humilha

Linux / Unix:

• Você pede “10 GB”

• O filesystem decide tudo

• Fragmentação invisível

• Latência variável

Mainframe:

• Você define:

  • Onde

  • Quanto

  • Como cresce

• O sistema sabe:

  • Quantos seeks

  • Quantos tracks

  • Quanto I/O será gerado

📊 Resultado:

• SLA calculável

• Batch que termina no horário

• Sistema que envelhece bem

---

8️⃣ Uso prático: quem realmente se beneficia disso?

🏦 Bancos
✈️ Companhias aéreas
🏛️ Governos
💳 Clearing e pagamentos
📊 BI batch massivo

Onde:

• Erro não é opção

• Retry não existe

• Previsibilidade é rei

---

9️⃣ Curiosidades e Easter Eggs de mainframer

🧠 Você sabia?

• SPACE=(TRK,…) ainda é usado em sistemas críticos

• VSAM define espaço em CI/CA, mas mapeia para tracks

• SMF Type 42 mede EXCP por dataset

• EAV permite volumes gigantes, mas o cálculo continua físico

• O termo DASD é mais velho que “storage” 😄

---

🔚 Conclusão Bellacosa Mainframe ☕

Falar de tracks e cilindros não é nostalgia.
É respeito à física, engenharia de verdade e responsabilidade operacional.

“Mainframe não abstrai o problema.
Ele encara o problema de frente.”

E é por isso que, décadas depois,
ele ainda roda o mundo.

---

 

Bellacosa Mainframe apresenta o RACF 

☕🔥 RACF Hardcore — Segurança Mainframe sem verniz 

Se você já perdeu acesso ao próprio TSO, já bloqueou produção com um PERMIT mal dado, ou já ouviu

“foi só uma alteração de RACF…”
então este texto é para você.

Aqui não tem introdução infantil.
Aqui é RACF raiz, técnico, sistêmico e perigoso — do jeito que veterano respeita.

---

🕰️ História & Origem — por que o RACF nasceu paranoico

O RACF (Resource Access Control Facility) surge nos anos 70, quando a IBM percebeu que:

• Controle por good behavior não escala

• Segurança precisava ser centralizada

• Auditoria não podia ser opcional

RACF foi desenhado para:

• Negar por padrão

• Controlar quem, o quê, quando e como

• Integrar com o núcleo do z/OS

☕ Verdade inconveniente:

RACF não confia nem no SYSADM. E está certo.

---

🔐 Por onde começar com Segurança (visão de veterano)

Segurança não começa no comando. Começa no modelo mental.

Princípios reais:

• Least Privilege

• Segregation of Duties

• Accountability

• Auditabilidade

🔥 Easter egg:
Ambiente “funcionando” ≠ ambiente “seguro”.

---

🏗️ A Estrutura de Grupos — o esqueleto invisível

Grupos RACF não são “organizacionais”.
São domínios de autoridade.

• Grupos pais controlam filhos

• OWNER ≠ SUPGROUP

• Hierarquia mal desenhada vira bomba relógio

📌 Exemplo técnico:

ADDGROUP FINANCE SUPGROUP(SYS1) OWNER(SYS1)
ADDGROUP FINANCE.PAYROLL SUPGROUP(FINANCE)

☕ Comentário ácido:

Grupo mal definido é privilégio eterno.

---

⌨️ Os Comandos RACF — bisturis, não martelos

• ADDUSER / DELUSER

• ADDGROUP / DELGROUP

• CONNECT / REMOVE

• PERMIT

• ALTUSER / ALTGROUP

• SETROPTS

🔥 Regra de Produção:

Se você não sabe desfazer, não execute.

---

🗑️ Definindo & Excluindo Grupos RACF

Criar grupo é fácil.
Excluir é trauma.

Antes de um DELGROUP:

• Usuários conectados?

• Perfis com OWNER?

• DATASET PROFILE ownership?

• Surpresas em ACL herdada?

☕ Fofoquice técnica:
DELGROUP em produção é evento histórico.

---

👤 Definindo Usuários — mais que um ID

Um usuário RACF é:

• Identidade

• Responsabilidade

• Risco

Campos críticos:

• SPECIAL / OPERATIONS / AUDITOR

• PASSWORD interval

• REVOKE / RESUME

• OMVS / DFP / CICS

📌 Exemplo:

ADDUSER JOSE NAME('JOSE SILVA') DFLTGRP(FINANCE) PASSDATE(30)

🔥 Easter egg:
Usuário genérico é pecado capital.

---

🔗 Conectando Usuários a Grupos

CONNECT é onde a segurança realmente acontece.

• AUTHORITY (USE, READ, CONNECT, JOIN)

• GROUP-SPECIAL

• OWNER implícito

☕ Verdade nua:

CONNECT errado é privilégio que ninguém vê.

---

🗂️ Perfis de Conjunto de Dados (DATASET PROFILES)

O coração do RACF clássico.

• HLQ como fronteira de poder

• DISCRETIONARY ≠ MANDATORY

• UACC mal definido = vazamento

📌 Exemplo:

ADDSD 'FINANCE.PAYROLL.**' OWNER(FINANCE) UACC(NONE)
PERMIT 'FINANCE.PAYROLL.**' ID(PAYUSR) ACCESS(READ)

🔥 Curiosidade:
UACC(READ) já causou mais incidente que bug de COBOL.

---

🌐 Perfis Gerais de Recursos (CLASS Profiles)

Aqui o RACF vira onipresente:

• CICS

• IMS

• MQ

• SDSF

• OPERCMDS

• FACILITY

☕ El Jefe warning:

Quem ignora classe FACILITY não entende z/OS moderno.

---

🧨 Recursos Especiais do RACF

• SPECIAL

• OPERATIONS

• AUDITOR

• TRUSTED

• WARNING vs FAIL

🔥 Comentário venenoso:
SPECIAL demais é insegurança institucionalizada.

---

⚙️ O Comando SETROPTS — o painel nuclear

SETROPTS controla:

• Ativação de classes

• Auditoria

• Regras globais

• Password rules

📌 Exemplo:

SETROPTS CLASSACT(DATASET) RACLIST(DATASET) REFRESH

☕🔥 Regra sagrada:

SETROPTS sem planejamento vira outage invisível.

---

🔄 RACF Remote Sharing Facility (RRSF)

RACF em modo distribuído:

• Compartilhamento de identidades

• Replicação de perfis

• Confiança entre sistemas

🔥 Curiosidade:
RRSF mal configurado espalha erro em escala industrial.

---

🔗 RACF e Sysplex — segurança em cluster

No Sysplex:

• Database compartilhado

• Consistência obrigatória

• Propagação imediata

☕ Verdade dura:

No Sysplex, erro local vira problema global.

---

🧪 Programas Utilitários RACF

Ferramentas para quem não vive no ISPF:

• IRRDBU00

• IRRUT200

• IRRICE

• unloads para auditoria

• Análise offline

🔥 Easter egg veterano:
Auditor sério não confia só em LISTUSER.

---

🧠 Mentalidade de Segurança Mainframe (nível veterano)

✔️ Segurança é processo, não produto
✔️ Tudo que não está definido será explorado
✔️ RACF não protege sistema — protege negócio
✔️ Auditor não é inimigo
✔️ Log é prova histórica

---

🥚 Easter Eggs & Fofoquices RACF

• Todo ambiente tem um ID “histórico”

• Sempre existe um dataset que “ninguém sabe de quem é”

• Segurança forte incomoda — e é esse o objetivo

• Incidente sério sempre começa com:

  “Mas esse acesso sempre existiu…”

---

☕🔥 Conclusão — Manifesto El Jefe RACF

RACF não é:

• Cadastro

• Burocracia

• Entrave

RACF é:

• Arquitetura de confiança

• Controle de risco

• Linha final de defesa do z/OS

☕🔥 Se você domina RACF,
você não protege arquivos —
protege a empresa inteira.