☕ Um Café no Bellacosa Mainframe – Storage que não morre, só evolui

---

📼 IBM LTO-10 Ultrium: quando 40TB cabem em um cartucho (e o mainframe sorri)

Se você acha que fita magnética é coisa de museu, sente-se confortavelmente, pegue seu café ☕ e venha comigo. A IBM acaba de apresentar os novos cartuchos IBM LTO-10 Ultrium, modelos 564 e 664, trazendo 40TB por cartucho e reafirmando uma verdade inconveniente para o mundo cloud-only:

storage em fita nunca morreu — ele só ficou mais inteligente, mais denso e mais confiável.

---

🧠 Conceito técnico – o que é LTO Ultrium, afinal?

LTO (Linear Tape-Open) é um padrão aberto de armazenamento em fita, criado no fim dos anos 90 por IBM, HP e Seagate, com um objetivo claro:
👉 substituir soluções proprietárias caras por um padrão robusto, escalável e de longo prazo.

No mundo mainframe, LTO convive muito bem com:

• DFSMShsm

• TSM / Spectrum Protect

• z/OS, AIX, Linux on Z

• Ambientes híbridos (cloud + on-prem)

---

🚀 LTO-10 Ultrium – o salto técnico

A geração LTO-10 representa um avanço brutal em densidade e confiabilidade.

🔹 Destaques técnicos

• Capacidade nativa: 40TB por cartucho

• Compatibilidade: drives IBM LTO Ultrium 10

• Uso típico: backup, archive, cyber-vault, air-gap

• Performance: pensada para ambientes corporativos e mainframe-grade

💡 Lembre-se: fita não compete com SSD — ela resolve outro problema: retenção, custo por TB e proteção contra ransomware.

---

📦 Os novos modelos IBM

🟦 Model 564

• IBM LTO-10 Ultrium 40TB Data Cartridge

• Pacote com 20 cartuchos

• Com etiquetas

• Volume serial inicial definido

• Ideal para ambientes mainframe, bibliotecas automatizadas e controle rigoroso de mídia

🧠 Perfeito para quem ainda sabe o valor de um bom VOLSER bem planejado.

---

🟩 Model 664

• IBM LTO-10 Ultrium 40TB Data Cartridge

• Disponível em:

  • 20-pack

  • 5-pack

• Sem etiquetas

• Mais flexível para ambientes distribuídos ou etiquetagem customizada

---

🏛️ Um pouco de história – fita é raiz de mainframe

No mainframe, fita sempre foi:

• Backup confiável

• Arquivo regulatório

• Última linha de defesa

Dos rolo aberto aos 3480, 3490, 3590, até o LTO moderno, a fita evoluiu silenciosamente enquanto o resto do mundo brigava por IOPS.

🕰️ Curiosidade histórica:
o primeiro backup corporativo confiável do mundo foi feito em fita — e isso não mudou até hoje.

---

🛡️ Segurança & Ransomware – o retorno do “air-gap”

Aqui está o ponto onde LTO-10 brilha forte:

• Cartucho offline

• Imune a ataque remoto

• Ideal para cyber-vault

• Atende compliance pesado (banco, governo, saúde)

🔐 O ransomware odeia fita porque fita não responde a ping.

---

🧪 Exemplo prático (mundo real)

Imagine um ambiente z/OS com:

• 300TB de dados históricos

• Retenção de 7 anos

• Backup diário + full semanal

Com LTO-10 (40TB):

• Menos cartuchos

• Menos movimentação física

• Menor custo por TB

• Melhor controle operacional

📊 Resultado: menos stress, menos mídia, mais previsibilidade.

---

🧙 Easter eggs & fofoquices do datacenter

🥚 Easter egg #1:
Apesar do nome “open”, quem domina LTO em escala sempre foi a IBM (principalmente em ambientes mainframe).

🥚 Easter egg #2:
Enquanto o mundo fala em “green IT”, fita sempre foi o storage mais sustentável: baixo consumo, longa vida útil, zero energia quando parada.

🥚 Fofoquinha:
Muita empresa correu para cloud… e voltou para fita quando a fatura mensal começou a parecer um extrato do cartão black 😄

---

🗣️ Comentário Bellacosa Mainframe™

“Storage bom é aquele que você só lembra quando dá problema.
E fita… simplesmente não dá problema.”

O IBM LTO-10 Ultrium prova que mainframe não vive de nostalgia, vive de engenharia séria, previsibilidade e custo controlado.

---

🧩 Conclusão

Os novos cartuchos IBM LTO-10 modelos 564 e 664 não são apenas “mais capacidade”.
Eles são:

• Continuidade de uma história sólida

• Resposta moderna a ransomware

• Prova de que legacy ≠ obsoleto

☕ Se você cuida de dados críticos, compliance pesado ou simplesmente gosta de dormir tranquilo… fita ainda é sua melhor amiga.

---

 

Bellacosa Mainframe apresenta o tape libraries automatizado

☕ Um Café no Bellacosa Mainframe – Guia Prático de Fita no z/OS

---

📼 Guia prático de fita/cartridge no z/OS

(para quem já apanhou de VOLSER, SMS e HSM… ou vai apanhar)

Se tem uma coisa que todo mainframeiro aprende cedo ou tarde é que fita no z/OS não é só “backup”.
É política, automação, performance, custo, compliance… e um pouco de fé 😄

Vamos ao guia prático, direto ao ponto, no melhor estilo Bellacosa Mainframe.

---

1️⃣ Conceito básico – fita no z/OS não é só hardware

No z/OS, fita envolve três mundos trabalhando juntos:

• 🧠 Sistema Operacional (z/OS)

• 🧩 SMS (DFSMS)

• 🤖 Gerenciador de backup (DFSMShsm / Spectrum Protect)

📌 Regra de ouro:

Se a política estiver errada, não existe cartucho LTO-10 que salve.

---

2️⃣ Tipos de fita no z/OS

🔹 Fita real (tape físico)

• LTO, TS11xx, etc

• Biblioteca robótica

• Drive dedicado ou compartilhado

🔹 Fita virtual (VTS / VTL)

• Emula fita

• Backend em disco ou objeto

• Performance absurda, mas não é air-gap

🧠 Dica Bellacosa:

Ambiente grande sempre usa virtual + físico. Um sem o outro é pecado técnico.

---

3️⃣ Componentes principais (anota aí, padawan)

📦 Cartucho

• Ex: LTO-10 Ultrium 40TB

• Identificado por VOLSER

• Pode ser rotulado (SL) ou não rotulado (NL)

🏷️ Label

• SL (Standard Label) – o mais comum

• NL (No Label) – só para quem sabe muito bem o que está fazendo

🔢 VOLSER

• Nome do cartucho (6 caracteres)

• Ex: LTO001, BK2026

🥚 Easter egg:
VOLSER mal planejado vira caos operacional em 6 meses.

---

4️⃣ SMS e fita – onde tudo pode dar errado

🧩 Storage Class

Define:

• Se pode ir para fita

• Performance

• QoS

🗂️ Data Class

Define:

• LRECL, RECFM

• Se pode ser estendido

• Tipo de dataset

📜 Management Class (o coração da fita)

Define:

• Migração

• Backup

• Retenção

• Expiração

📌 Exemplo clássico

Primary Days Non-Usage: 5
Secondary Days Non-Usage: 30
Expire After Days: 365

☕ Tradução Bellacosa:

“Depois de 5 dias sem usar, manda pra fita.
Depois de 1 ano, pode morrer em paz.”

---

5️⃣ DFSMShsm – o dono da fita no z/OS

Se você usa z/OS, você usa HSM, mesmo que não saiba.

🛠️ O que ele faz

• Backup

• Migração

• Recall

• Expiração

• Controle de catálogo

🔑 Comandos essenciais

HSM LIST TAPE
HSM LIST BACKUP
HSM QUERY MIGRATION
HSM RELEASE

🥚 Easter egg:
Quando o recall demora, não xingue o HSM primeiro. Veja drive, robô e concorrência.

---

6️⃣ JCL básico gravando em fita

✍️ Exemplo simples

//STEP1   EXEC PGM=IEBGENER
//SYSUT1  DD  DSN=MEU.ARQUIVO.INPUT,DISP=SHR
//SYSUT2  DD  DSN=MEU.ARQUIVO.TAPE,
//            DISP=(NEW,KEEP),
//            UNIT=TAPE,
//            LABEL=(1,SL),
//            VOL=SER=LT0010
//SYSPRINT DD SYSOUT=*
//SYSIN    DD DUMMY

🧠 Dica:

Hoje quase ninguém codifica VOL=SER fixo.
Deixe o SMS escolher — ele sabe mais que você (e não esquece).

---

7️⃣ Bibliotecas robóticas – o “braço invisível”

No z/OS moderno:

• Robô monta

• Robô desmonta

• Operador só observa

⚠️ Erro comum de iniciante:
Pensar que fita é lenta.
👉 Lento é drive disputado.

---

8️⃣ Performance – sim, fita pode ser rápida

• Streaming contínuo = performance boa

• Muitos arquivos pequenos = sofrimento

🧠 Dica avançada:

Agrupe dados antes de gravar em fita.
Fita odeia stop/start.

---

9️⃣ Segurança e ransomware

Fita no z/OS é:

• Offline

• Isolada

• Confiável

🔐 Estratégia moderna:

• Backup diário em VTL

• Cópia semanal para fita física

• Cartucho fora do datacenter

☕ Isso se chama sobreviver a segunda-feira.

---

🔟 Erros clássicos (todos já cometemos)

❌ VOLSER sem padrão
❌ Retenção mal definida
❌ Fita virando “lixeira eterna”
❌ Esquecer limpeza de drive
❌ Achar que cloud substitui tudo

---

🗣️ Comentário final Bellacosa Mainframe™

“Quem domina fita, domina o tempo.
Porque dado velho também vale dinheiro.”

Fita no z/OS não é legado.
É engenharia, processo e maturidade operacional.

Road Map para Aprender Mainframe

O que um jovem padawan deve aprender para ser um especialista na Stack Mainframe. Um caminho com inúmeras possibilidades, requer esforço e dedicação, porém os frutos condizem ao esforço. Descubra o z/OS, codifique em COBOL, crie queries no SQL DB2 e vá além. #ibm #mainframe #cobol #cics #db2 #jcl #sdsf #qsam #vsam #query #sql #etl #jobs #procs #jes2 #lpar #sysplex

Conheça unidade de armazenamento CARTRIDGE Storage

A

storage mainframe cartridge e robot de leitura

FUJIFILM Corporation e a IBM anunciaram o desenvolvimento de um sistema de armazenamento em fita nativo de 50 TB, apresentando a maior capacidade nativa de cartucho de fita de dados do mundo.

 

IBM Tape Data Cartridge 700 GB

Conheça unidade de armazenamento CARTRIDGE Storage #MAINFRAME #IBM #STORAGE #cartridge

IBM Tape Data Cartridge 700 GB

 

🔥 IBM 3592 JF – O cartucho que carrega impérios de dados

---

🧠 Introdução – quando o dado dorme em fita, mas sonha em petabytes

Se você acha que fita magnética é coisa de museu, é porque nunca encarou um IBM 3592 JF rodando em um TS1140/TS1150 dentro de um data center que parece mais uma nave espacial do que uma sala fria.
O 3592 JF não é “backup”. Ele é arquivo corporativo, retenção legal, seguro contra ransomware e, em muitos bancos, a última linha de defesa da civilização digital.

Bem-vindo ao mundo onde dados não são deletados — são arquivados com honra.

---

📜 História – da fita de rolo ao JF

A linhagem do IBM 3592 nasce no início dos anos 2000 como sucessor espiritual das 3490/3480.
O sufixo JF marca uma geração madura, refinada, feita para:

• Ambientes z/OS heavy-duty

• Integração com DFSMS/HSM

• Coexistência com VTS, TS7700 e GDPS

📼 O JF é o tipo de mídia que sobrevive a mudanças de diretoria, ERPs, fusões e três modas de cloud.

---

🧱 Arquitetura do cartucho IBM 3592 JF

Características físicas e lógicas:

• 📏 Formato proprietário IBM (não confundir com LTO)

• 💾 Capacidade nativa: ~700 GB

• 🗜️ Capacidade com compressão: até ~2–3 TB (dependendo do workload)

• 🔐 Suporte a criptografia por hardware

• 🧬 Servo tracking de altíssima precisão

💡 Easter egg: a densidade da fita é tão alta que um cartucho mal acondicionado “grita” no log do drive antes mesmo de falhar.

---

🏗️ Onde ele vive no mundo real

Normalmente você encontra o 3592 JF em:

• 🗄️ IBM TS3500 / TS4500 Tape Library

• 🧠 TS7700 (Virtual Tape Server) como mídia física de backend

• 🧾 Ambientes regulados: bancos, seguradoras, governos

Ele conversa intimamente com:

• z/OS DFSMS

• HSM (Hierarchical Storage Manager)

• DFSMShsm Migration / Recall

---

🔄 Workflow clássico no mainframe

📌 Passo a passo “vida de fita”

1. Dataset criado (PS ou GDG)

2. Política de SMS decide: disk hoje, fita amanhã

3. HSM migra o dataset para fita

4. Catalog aponta para volume JF

5. Recall on-demand traz o dado de volta

6. Dataset volta ao disco como se nada tivesse acontecido

🧙‍♂️ Magia negra mainframe: a aplicação nunca sabe que o dado dormiu em fita.

---

📊 Logs, SMF e rastros

O 3592 JF deixa pegadas elegantes:

• SMF 14/15 – uso de fita

• SMF 42 – atividades de DFSMS

• SMF 94 – criptografia

• Logs do TS7700 (se virtualizado)

📎 Dica Bellacosa: fita não mente. Se algo sumiu, o SMF sabe onde foi parar.

---

🧩 Curiosidades que só quem viveu sabe

• ☕ Drives 3592 “acordam” antes do operador terminar o café

• 🔁 Uma fita JF pode sobreviver 30 anos se bem armazenada

• 🧯 Ransomware odeia fita — ela não monta sozinha

• 🎩 Cartucho com label mal escrito vira lenda urbana no CPD

---

🛠️ Dicas práticas de sobrevivência

✔️ Padronize nomenclatura de volumes
✔️ Nunca misture JF com JE/JB sem planejamento
✔️ Use criptografia nativa, não “caseira”
✔️ Monitore recalls excessivos (sinal de má política de HSM)
✔️ Tape não é lenta — lento é acesso mal desenhado

---

📚 Guia de estudo para mainframers

📖 Leia e domine:

• DFSMS Storage Administration

• DFSMShsm Implementation

• IBM TS11xx Drive Redbooks

• SMF 14/15 deep dive

🧠 Exercício clássico:

Simule migração, expiração, recall e auditoria de um dataset crítico sem que a aplicação perceba.

---

🧪 Aplicações reais do IBM 3592 JF

• 📜 Retenção legal (7–30 anos)

• 🏦 Histórico financeiro imutável

• 🧬 Dados médicos arquivados

• 🛰️ DR offline (air gap real)

• 📦 Data lake pré-cloud que ainda funciona

---

🧨 Comentário final – El Jefe Style

Enquanto o mundo discute se “cloud é o futuro”, o IBM 3592 JF continua fazendo o que sempre fez:
guardar o passado para proteger o futuro.

No mainframe, fita não é legado.
É estratégia.

🔥 Midnight Lunch aprovado. A fita gira, o dado dorme, o mainframer sorri.

 

Bellacosa Mainframe apresenta Suporte a Produção

☕🔥 Suporte à Produção Mainframe — engenharia operacional em estado bruto

Se você já deu CANCEL com o coração na mão, já leu dump em hexadecimal, já decorou mensagem $HASP melhor que CPF, então este texto não é para iniciantes.
Aqui falamos de Produção de verdade. Sem romantização. Sem power-point bonito.

---

🧠 Suporte à Produção Mainframe ≠ Operação

É engenharia operacional sob carga real.

Produção não é:

• Rodar job

• Reiniciar STC

• Abrir chamado

Produção é:

• Análise de impacto

• Decisão em ambiente crítico

• Entendimento sistêmico do z/OS

• Correlação entre eventos aparentemente desconexos

Produção é onde o design encontra a realidade — e geralmente perde.

---

🕰️ Raiz Histórica (para quem veio do MVS, não do YouTube)

O Suporte à Produção nasce quando:

• O batch deixou de ser “linear”

• O online passou a ser 24x7

• O negócio começou a depender de janela de processamento

• O erro deixou de ser aceitável

A evolução foi clara:

• Operador de console →

• Analista de Produção →

• Especialista em estabilidade operacional

Hoje, Produção é a última linha de defesa entre o z/OS e o prejuízo financeiro.

---

🎯 Objetivo Real do Suporte à Produção (versão sem marketing)

• Garantir throughput, não apenas execução

• Controlar contenção, não apenas erro

• Preservar integridade transacional

• Manter SLA, RTO e RPO

• Atuar antes do incidente virar crise

☕ Veterano sabe:

Produção não corrige código — corrige efeito colateral.

---

🧩 Arquitetura de Conhecimento (o que separa júnior de veterano)

🖥️ z/OS — domínio do núcleo

• JES2/JES3, initiators, classes, priorities

• Spool contention

• ENQ/DEQ, RESERVE, latch

• WTOR, automation hooks

• Dumps SVC vs SYSMDUMP

🔥 Apimentado:
Quem não entende JES não entende produção.

---

🧠 CICS — transação é sagrada

• Task Control

• Storage violation

• Transaction isolation

• Deadlock silencioso

• Dumps DSNAP / CEEDUMP

☕ El Jefe truth:

CICS não cai — ele sangra em silêncio.

---

📬 MQ — quando o assíncrono vira gargalo

• Depth x High/Low Threshold

• Channels retrying

• Poison message

• Commit vs rollback

• Impacto no batch e no online

🔥 Easter egg:
Fila cheia é sintoma, não causa.

---

🔌 Integration Bus (Broker)

• Flow degradation

• Message backlog

• XML/JSON parsing cost

• CPU vs I/O trade-off

• Propagação de erro invisível

☕ Fofoquice técnica:
Quando o Broker falha, todo mundo aponta para o mainframe.

---

🧪 REXX — automação tática

• Monitoramento ativo

• Ações condicionais

• Coleta de evidência

• Resposta automática a eventos

• Integração com SDSF, consoles e logs

🔥 Produção sem REXX é operação cega.

---

🗄️ DB2 Utilities — o campo minado

• REORG mal planejado

• RUNSTATS atrasado

• Lock escalation

• Deadlock intermitente

• Log pressure

☕ Frase clássica:

“Não mexe agora… deixa rodar.”

---

🌐 WebSphere / Acesso Remoto

• JVM pressure

• Thread starvation

• Timeout mascarado

• Latência invisível

• Cascata de falhas

🔥 Curiosidade:
O Web cai rápido. O mainframe aguenta a culpa.

---

🔍 Funcionamento Real em Produção (sem filtro)

1. Sintoma aparece longe da causa

2. Métrica parece normal

3. SLA corre

4. Dump gerado

5. Análise cruzada (JES + CICS + DB2 + MQ)

6. Decisão com risco calculado

7. Execução mínima, impacto máximo

8. Ambiente estabiliza

9. Post-mortem técnico

10. Documentação (que ninguém lê… até precisar)

---

🧠 Mentalidade do Veterano

✔️ Não confia em “achismo”
✔️ Não executa comando sem rollback mental
✔️ Pensa em efeito dominó
✔️ Prefere degradar a parar
✔️ Sabe quando não agir

☕🔥 Regra de ouro:

Em Produção, o comando mais perigoso é o que “sempre funcionou”.

---

🥚 Easter Eggs de Produção

• Todo ambiente tem um job que “ninguém encosta”

• Sempre existe um dataset com DISP=SHR que não deveria

• Todo incidente grave começa com:

  “Isso nunca aconteceu antes…”

• O melhor analista é o que não aparece no incidente report

---

🧨 Conclusão — El Jefe Midnight Lunch Manifesto

Suporte à Produção Mainframe é:

• Arquitetura viva

• Engenharia sob estresse

• Decisão sem margem de erro

• Responsabilidade sem aplauso

Não é glamour.
Não é palco.
É confiança operacional.

☕🔥 Se você já sobreviveu a uma madrugada de produção,
você sabe:

Produção não ensina — ela seleciona.

 

 

🔥 From Monitoring to Meaningful Engagement — IBM Storage Insights explicado para quem já confiou em RMF e I/O trace

Conhecimento básico sobre aplicações distribuídas para um público mainframer

---

☕ 00:47 — Antes de existir “Storage Insights”, já existia DD DISP=SHR

Todo mainframer raiz sabe:
armazenamento nunca foi só disco. Sempre foi:

• gargalo oculto

• causa raiz disfarçada

• vilão injustiçado

Em 2025, o que a IBM fez com o Storage Insights não foi criar algo novo — foi traduzir décadas de mentalidade mainframe para o mundo híbrido e distribuído.

---

🧬 Um pouco de história (ou: nada disso é realmente novo)

No z/OS, você sempre teve:

• RMF para performance

• SMF para evidência

• I/O trace para verdade inconveniente

• Capacity Planning como arte marcial

O que mudou em 2025 foi a embalagem e o alcance:

Storage Insights deixou de ser “monitor”
e virou plataforma de engajamento operacional.

📌 Comentário Bellacosa:
O distribuído está finalmente reaprendendo o que o mainframe nunca esqueceu.

---

🔍 O que realmente mudou (traduzido para mainframês)

🔹 De Monitoring → Actionable Intelligence

Antes (clássico):

• Alertas

• Dashboards

• “CPU alta”, “latência subiu”

Agora (2025):

• Tendência

• Previsão

• Recomendação contextual

🧠 Analogia direta:
RMF + histórico + operador experiente… automatizado.

---

🔹 De Operação Reativa → Engajamento Colaborativo

O Storage Insights virou:

• ponto de encontro

• linguagem comum

• ponte entre cliente, parceiro e IBM

📌 Tradução mainframe:
Como se o suporte já chegasse com o dump analisado.

😈 Easter egg:
No mainframe isso sempre se chamou “time que sabe o que está fazendo”.

---

🔹 De Visibilidade → Empoderamento

Não é mais “olhar gráfico”.
É:

• entender impacto

• simular decisão

• agir antes do incidente

🔥 Comentário ácido:
Dashboard bonito nunca salvou produção. Contexto sim.

---

📈 O quadro geral (ou: por que isso importa)

Em arquiteturas distribuídas:

• storage não é periférico

• storage define comportamento

O Storage Insights 2025 passa a ser:

• tecido de engajamento

• fonte de inteligência operacional

• base para automação real

📌 Bellacosa style:
Observabilidade sem ação é voyeurismo técnico.

---

🧠 Comparação honesta: Mainframe x Storage Insights

Conceito clássico	Storage Insights
RMF histórico	Trend analysis
SMF evidência	Telemetria contínua
Capacity planning	Predictive analytics
Operador experiente	AI recommendations
War room	Plataforma colaborativa

😈 Easter egg:
Chamaram de “AI”. Você chamava de “cara que conhece o sistema”.

---

🛠️ Passo a passo mental para o mainframer entender

1️⃣ Pare de pensar em “ferramenta”
2️⃣ Pense em governança operacional
3️⃣ Leia tendências, não alertas
4️⃣ Correlacione storage com aplicação
5️⃣ Use recomendação como hipótese, não dogma

🔥 Regra de ouro:
Quem decide continua sendo humano. A diferença é que agora ele decide melhor informado.

---

📚 Guia de estudo recomendado

Conceitos-chave

• Observabilidade

• Telemetria

• Capacity planning distribuído

• Hybrid cloud

• AIOps

Exercício Bellacosa

👉 Pegue um pico de latência
👉 Veja a tendência histórica
👉 Relacione com workload
👉 Compare com decisão reativa antiga

Resultado? Menos susto. Mais controle.

---

🎯 Aplicações reais no mundo corporativo

• Redução de incidentes

• Planejamento de crescimento

• Integração mainframe + cloud

• SRE corporativo

• Base para storage autônomo

---

🖤 Epílogo — 03:12 da manhã, tudo estável

O Storage Insights 2025 não é revolução.
É evolução com memória.

El Jefe Midnight Lunch conclui:
“O futuro do storage não é autônomo. É bem governado.”

 

 

CICS Storage Control

🧠 Storage Control no CICS

Onde o estado vive, onde ele morre e onde ele assombra produção

A imagem mostra:

Storage Control → Storage sources
• COMMAREA
• CWA (Common Work Area)
• TWA (Transaction Work Area)

Isso não é teoria.
Isso é onde bugs se escondem.

---

🧱 Storage Control – o papel do CICS

O Storage Control é o componente do CICS responsável por:

• Alocar memória

• Liberar memória

• Isolar memória entre tasks

• Proteger o CICS de você (sim, de você)

Tudo no CICS gira em torno de tasks concorrentes compartilhando CPU, mas não memória — salvo quando você pede explicitamente.

---

📦 COMMAREA

O clássico, o limitado, o abusado

O que é

Área de comunicação passada entre programas via:

• LINK

• XCTL

• RETURN TRANSID

Características

• 📏 Tamanho máximo: 32 KB

• 🔁 Passagem explícita

• ⏱️ Vida curta (dura o fluxo)

• 🔒 Isolada por task

Quando usar

• Dados pequenos

• Estruturas simples

• Fluxo linear clássico

Pecados capitais

• Usar COMMAREA como banco de dados

• Estourar tamanho

• Reusar layout errado (ASRA clássico)

💀 ABEND típico: ASRA / AEIP

---

CICS TWA

🧰 TWA – Transaction Work Area

Estado temporário da transação

O que é

Área de memória associada à transação, não ao programa.

Características

• Criada automaticamente pelo CICS

• Acessível por qualquer programa da transação

• Vive até o RETURN final

Quando usar

• Guardar estado entre múltiplos programas

• Fluxo pseudo-conversacional simples

Riscos

• Confundir TWA com COMMAREA

• Assumir que sobrevive entre transações (não sobrevive)

💡 Boa prática: TWA é “mochila da transação”, não cofre.

---

CICS CWA

🏛️ CWA – Common Work Area

O templo dos deuses (e dos pecados)

O que é

Área de memória global do CICS Region.

Características

• Compartilhada por todas as tasks

• Inicializada no startup

• Não é isolada

• Não é protegida

Quando usar (com muito cuidado)

• Tabelas de controle

• Flags globais

• Cache de leitura

Quando NÃO usar

• Dados de negócio

• Dados por usuário

• Qualquer coisa mutável sem controle

☠️ Risco real: corrupção de dados, race condition, caos silencioso.

CWA é poder absoluto — e poder absoluto gera incidentes absolutos.

---

🚀 CHANNEL & CONTAINER

O CICS moderno, civilizado e escalável

O que são

Substitutos modernos da COMMAREA.

• CHANNEL → agrupador lógico

• CONTAINER → estrutura de dados

Características

• 📏 Tamanho praticamente ilimitado

• 📦 Estruturas múltiplas

• 🔄 Tipagem flexível

• 🧼 Melhor manutenção

• 🔐 Mais seguro

Quando usar

• Aplicações modernas

• Integração

• Grandes volumes

• APIs CICS

Comparação rápida

Recurso	COMMAREA	CHANNEL/CONTAINER
Tamanho	32 KB	Muito maior
Estrutura	Única	Múltiplas
Manutenção	Difícil	Limpa
Futuro	Legado	Presente e futuro

---

🗺️ Como ler a imagem como um mainframer

A imagem não está falando só de memória.
Ela está dizendo:

“Escolha errado onde guardar estado
e você vai debugar às 3 da manhã.”

---

🧠 Regra Bellacosa de Ouro

• COMMAREA → conversa curta

• TWA → memória da transação

• CWA → último recurso

• CHANNEL/CONTAINER → escolha padrão moderna

---

☕ Comentário El Jefe Midnight Lunch

“CICS não quebra porque é antigo.
Ele quebra porque alguém tratou memória como variável global.”

🔥 Quem entende Storage Control, domina o CICS.

Bellacosa Mainframe apresenta Storage Management no IBM z/OS

---

🧱 IBM Mainframe Storage Management no z/OS

DFSMS, SMS x non-SMS, ISMF, ACS, DASD, TAPE, JCL, VSAM, PS e PO

O disco não é só espaço. É política, disciplina e sobrevivência.

---

☕ Introdução – Quando o disco manda mais que o código

Todo mainframe nasce vazio.
Nenhum COBOL roda, nenhum CICS responde, nenhum batch fecha balanço sem que alguém tenha decidido onde os dados vão morar.

E é aqui que muita gente erra:

“Ah, storage é só pedir espaço no JCL…”

❌ Errado.
No IBM Mainframe, storage é governança, automação, história, política corporativa e, muitas vezes, briga silenciosa entre times.

Este artigo é para você que:

• Já sofreu com SMS override

• Já ouviu “o ACS mandou”

• Já viu dataset ir parar num disco que você nem sabia que existia

• Ou ainda acha que VOL=SER ainda manda em tudo

Senta, pega o café, que a aula começa agora.

---

🏛️ Origem e História – Do ferro bruto ao cérebro automático

📼 Anos 60–70: tudo era manual

• Disco era caro

• Poucos volumes

• Programador escolhia tudo

• Erro humano era rotina

💣 Anos 80: o caos

• Explosão de dados

• Batch gigante

• Fragmentação absurda

• Discos cheios às 03:00 da manhã

🧠 Anos 90: nasce o DFSMS

A IBM percebeu:

“Não dá para deixar cada programador decidir disco.”

Surge o DFSMS (Data Facility Storage Management Subsystem).

Objetivo:

• Padronizar

• Automatizar

• Controlar

• Evitar desastre operacional

📌 DFSMS não é luxo. É resposta ao caos.

---

🧠 DFSMS – O cérebro do armazenamento no z/OS

DFSMS é:

• Parte nativa do z/OS

• Gerente de dados

• Juiz das decisões de disco

• Guarda-costas da infraestrutura

Ele cuida de:

• DASD

• TAPE

• Migração

• Backup

• Alocação

• Performance

• Disponibilidade

---

💽 DASD – O chão onde tudo pisa

DASD = Direct Access Storage Device

Tradução Bellacosa:

“É o HD do mainframe, só que sério.”

Tudo mora em DASD:

• z/OS

• SYS1

• Aplicações

• VSAM

• Logs

• Catálogos

📌 Volume = Disco = DASD

Exemplos reais:

PRD001
TSO123
CICS45

---

📼 TAPE – O ancião que ainda reina

Muita gente subestima, mas:

• Tape é barato

• Tape é denso

• Tape é confiável

• Tape é rei do backup

DFSMS controla:

• Migração HSM

• Recall automático

• Arquivamento

📌 Easter egg:
Muitos bancos ainda têm dados mais velhos que o programador, morando felizes em fita.

---

🧩 SMS x non-SMS – O conflito eterno

🔴 Non-SMS (old school)

Você manda:

• VOL=SER

• SPACE

• UNIT

Vantagem:

• Controle total

Desvantagem:

• Risco total

📌 Hoje: usado só em casos muito específicos.

---

🟢 SMS-Managed (mundo real)

O sistema manda.

Você pede:

• Nome do dataset

O SMS decide:

• Onde fica

• Quanto espaço

• Performance

• Migração

📌 Naming convention é lei.

---

🧬 ACS – O código que manda mais que o JCL

ACS Routine = cérebro do SMS

Ela decide:

• Data Class

• Storage Class

• Storage Group

Baseado em:

• Nome do dataset

• Usuário

• Programa

• Ambiente

Exemplo simplificado:

IF &DSN = 'PRD.*'
   SET &STORCLAS = 'HIGH'

💣 Easter egg cruel:

Você pode pedir CYL(1000).
O ACS pode te dar TRK(10).
E ainda sorrir.

---

🖥️ ISMF – Onde o poder mora

ISMF = Interactive Storage Management Facility

Ferramenta do:

• Storage admin

• Infra

• Arquitetura

Aqui você vê:

• Volumes

• Classes

• Storage Groups

• ACS

• Espaço real

📌 Programador geralmente não entra aqui.

---

🧱 Data Class – O DNA do dataset

Define:

• RECFM (FB, VB…)

• LRECL

• DSORG

Exemplo:

RECFM=FB
LRECL=80
DSORG=PS

📌 Template padrão corporativo.

---

🚀 Storage Class – Performance e SLA

Define:

• Prioridade

• Backup

• Migração

• Disponibilidade

📌 Onde o negócio fala mais alto que o código.

---

🗄️ Storage Group – O endereço físico

• Conjunto de volumes

• Abstração total

• Usuário não escolhe disco

📌 Você não precisa saber qual disco.
📌 O SMS sabe.

---

📂 Tipos de Data Set – PS, PO, VSAM

📄 PS (Sequential)

• Batch

• Relatórios

• Entrada/Saída simples

---

📚 PO / PDS / PDSE

• Código

• JCL

• Copybooks

📌 PDSE > PDS (sempre que possível).

---

🧬 VSAM

• KSDS

• ESDS

• RRDS

Alta performance, alta complexidade.

📌 VSAM mal dimensionado = pesadelo.

---

📜 JCL x DFSMS – Quem manda?

JCL pede.
DFSMS decide.

Exemplo clássico:

SPACE=(CYL,(100,50))

Resultado:

SPACE=(TRK,(10,5))

Mensagem:

“Some attributes were overridden by ACS routine.”

📌 Tradução:

“Você tentou. Eu mandei.”

---

🧪 Passo a passo prático (vida real)

1. Dataset criado

2. ACS roda

3. Classes atribuídas

4. Volume escolhido

5. Espaço ajustado

6. Catálogo atualizado

Tudo automático.

---

🧙‍♂️ Dicas Bellacosa Mainframe

✔ Naming convention é tudo
✔ Nunca confie só no JCL
✔ Leia o ACS antes de reclamar
✔ ISMF é seu melhor amigo
✔ Storage admin é aliado, não inimigo
✔ PDSE sempre que possível
✔ VSAM exige respeito

---

🥚 Easter Eggs & Curiosidades

🥚 Existem ACS routines com 20+ anos em produção
🥚 Já houve banco parado porque alguém mexeu no ACS sem change
🥚 Muitos datasets “fantasmas” existem só porque ninguém sabe quem usa
🥚 Tape ainda salva mais empresa que cloud hype

---

☕ Conclusão – A frase que resume tudo

“No mainframe, código faz o sistema funcionar.
Storage faz o negócio sobreviver.”

Se quiser, posso:

• 📚 Transformar isso em curso

• 🧪 Criar labs práticos

• 🎓 Adaptar para aula corporativa

• 🔐 Criar versão bancária real

• 📊 Montar mapa mental DFSMS

Só chamar.
O café está quente ☕🖥️

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.

---