Bellacosa Mainframe mergulha no segredo do z/os tecnicas de i/o

🔥 SEU PROGRAMA NÃO ESTÁ LENTO… O GARGALO ESTÁ NO I/O 💀

O guia proibido do IOS, canais e discos que explica por que seu z/OS voa… ou trava

Você pode tunar CPU, ajustar WLM, mexer em COBOL…

👉 mas se o I/O estiver ruim: acabou o jogo.

Porque no mainframe:

💥 performance = I/O bem resolvido

E o que você vai ver agora é o lado invisível do z/OS — onde realmente se ganha (ou perde) desempenho.

---

🧠 1. A VERDADE QUE POUCOS SABEM

👉 O processador NÃO faz I/O

---

💡 Quem faz então?

• IOS (coordena)
• Channel Subsystem (executa lógica)
• SAP (trabalha pesado)
• Devices (fazem o trabalho físico)

---

🔥 Tradução Bellacosa

“CPU pensa… o resto corre atrás do dado.”

---

⚙️ 2. IOS — O MAESTRO DO I/O

O Input/Output Supervisor (IOS) é quem:

• recebe pedidos do programa
• monta requisição
• dispara operação

---

🔥 Ele usa:

👉 Start Subchannel (SSCH)

---

💡 Exemplo

READ arquivo
 ↓
IOS cria ORB
 ↓
envia para channel subsystem

---

🧩 3. CHANNEL SUBSYSTEM — A ENGRENAGEM

Ele é responsável por:

• fila de I/O
• seleção de caminho
• envio de comandos
• interrupções

---

🔥 Estrutura

CPU → Channel → Control Unit → Device

---

🧨 Curiosidade

Você pode ter múltiplos caminhos para o mesmo disco

👉 alta disponibilidade real

---

🔗 4. CCW — A LINGUAGEM DO HARDWARE

z/OS não fala com disco direto.

👉 usa CCW (Channel Command Word)

---

💡 Exemplo

• READ
• WRITE
• SEEK

---

🔥 Tradução

“CCW = comando que o hardware entende”

---

🧱 5. UCB vs SUBCHANNEL — O CASAMENTO

🔹 Subchannel

• criado no POR
• representa hardware

---

🔹 UCB

• criado no IPL
• representa software

---

🔥 Resultado

👉 mapeamento 1:1

---

💡 Insight

sem isso… device não existe pro sistema

---

⚙️ 6. HCD — O ARQUITETO DO DATA CENTER

O HCD define:

• devices
• canais
• paths
• control units

---

🔥 Resultado

👉 cria IODF

---

🧨 Easter Egg

Você pode:

👉 adicionar disco SEM derrubar o sistema 😳

---

🧠 7. O FLUXO REAL DE UM I/O

Programa pede READ
 ↓
IOS cria ORB
 ↓
Start Subchannel
 ↓
Channel seleciona path
 ↓
Control Unit executa
 ↓
Device responde
 ↓
Interrupt → CPU
 ↓
Programa continua

---

💡 Insight

tudo isso acontece em microssegundos

---

💀 8. ERROS — QUANDO O MUNDO CAI

🔥 MIH

• device não respondeu a tempo

---

🔥 HOT I/O

• interrupt infinito

---

🔥 Soluções

• VARY OFFLINE
• CHPID OFFLINE
• recovery

---

⚡ 9. PERFORMANCE — ONDE MORA O PROBLEMA

Tempo de I/O:

IOSQ + Pend + Disconnect + Connect

---

💡 Gargalo clássico

👉 IOSQ alto (fila)

---

🧨 Tradução

“todo mundo quer o mesmo disco ao mesmo tempo”

---

🚀 10. PAV — A REVOLUÇÃO

Antes:

👉 1 disco = 1 operação

---

🔥 Depois do PAV:

👉 múltiplos acessos simultâneos

---

💡 Como?

• base device
• alias devices

---

🔥 Exemplo

Sem PAV:
A → usa disco
B → espera

Com PAV:
A + B → simultâneo

---

⚡ 11. HYPERPAV — INTELIGENTE

• pool dinâmico
• alocação automática

---

💡 Tradução

“usa recurso só quando precisa”

---

🧨 12. SUPERPAV — ESCALA MONSTRA

• ultrapassa limite de 256
• compartilha entre control units

---

🧠 13. PRIORIDADE E WLM

WLM define:

• quem acessa primeiro
• quem espera

---

💡 Insight

nem todo I/O é igual

---

🔥 Exemplo

Tipo	Prioridade
pagamento	alta
batch	baixa

---

⚡ 14. TECNOLOGIAS MODERNAS

🔹 zHPF

• menos overhead
• mais performance

---

🔹 zHyperLink

• latência ultra baixa
• ideal para DB2

---

🧨 CURIOSIDADES (NÍVEL ROOT)

🤯 1. CPU não faz I/O

---

🔥 2. I/O é paralelo desde sempre

---

💀 3. Gargalo quase sempre é disco

---

🧠 4. PAV salvou performance moderna

---

⚡ 5. HyperPAV é invisível para o dev

---

🎯 RESUMO FINAL

✔ IOS coordena

✔ Channel executa

✔ SAP trabalha

✔ UCB representa

✔ PAV acelera

✔ WLM prioriza

---

💥 FRASE FINAL

“No mainframe, não é o código que define a velocidade… é o caminho que os dados percorrem.”

 

🔥 SE O z/OS NÃO SOBE… NADA EXISTE 💀O guia proibido do IPL que todo dev COBOL deveria entender (mas quase ninguém entende)

 

Bellacosa Mainframe fala sobre a iniacialização do ambiente operacional

🔥 SE O z/OS NÃO SOBE… NADA EXISTE 💀

O guia proibido do IPL que todo dev COBOL deveria entender (mas quase ninguém entende)

Você escreve COBOL… compila… roda…
👉 e acha que o sistema “tá lá pronto”.

Errado.

Antes do seu programa existir, acontece um ritual quase místico chamado:

IPL — Initial Program Load

E aqui vai a verdade estilo Bellacosa:

💥 “Se o IPL falhar… o mainframe inteiro simplesmente NÃO EXISTE.”

Hoje você vai entender isso como um padawan do mainframe, mas com visão de Jedi 👊🔥

---

🧠 O QUE É O IPL (O NASCIMENTO DO SISTEMA)

O IPL é o momento em que:

• o hardware ganha vida
• o z/OS é carregado
• os primeiros address spaces são criados

👉 Segundo o material, ele:

• carrega o sistema do disco
• inicializa o kernel
• cria o ambiente completo

---

🔥 Tradução Bellacosa

“IPL é o Big Bang do z/OS.”

---

🧱 OS DATASETS QUE FAZEM O MILAGRE ACONTECER

Sem eles… não tem sistema. Simples assim.

---

🔥 SYS1.NUCLEUS — o coração

Contém:

• NIP (Nucleus Initialization Program)
• RIM (Resource Initialization)
• módulos básicos do kernel

👉 É literalmente o “cérebro inicial”.

---

🔥 SYS1.LPALIB — a memória compartilhada

• módulos do sistema
• SVCs
• rotinas críticas

👉 Vai parar dentro da LPA (já já explico 👀)

---

🔥 SYS1.LINKLIB — o arsenal

• programas do sistema
• inclui o Master JCL

👉 Aqui começa a execução de verdade.

---

🔥 SYS1.PARMLIB — o cérebro de configuração

Define:

• como o sistema vai funcionar
• performance
• segurança

👉 É o /etc do z/OS… só que turbinado.

---

🔥 SYS1.PROCLIB — automação

• procedures (START, etc.)
• inicialização de subsistemas

---

🔥 Outros importantes

• PAGE DATASETS → memória virtual
• SMF → estatísticas
• DUMP → análise de erro

---

💡 Insight de ouro

“z/OS não sobe com código… sobe com DATASETS.”

---

⚙️ I/O CONFIG — O MAPA DO MUNDO

Antes do sistema usar qualquer coisa, ele precisa saber:

• quais devices existem
• onde estão
• como acessar

---

🔹 Quem faz isso?

👉 HCD + IOCDS + IODF

---

🔥 Durante o IPL:

• cada device gera um UCB (Unit Control Block)
• o sistema passa a reconhecer discos, fitas, etc.

---

🧨 Easter Egg

Se o device não está no IODF… ele NÃO EXISTE pro sistema.

---

🧠 PARMLIB — ONDE VOCÊ DOMINA O SISTEMA

🔹 O que é?

Um conjunto de membros tipo:

• IEASYSxx
• LOADxx
• outros

---

🔥 Função

Define:

• memória
• subsistemas
• comportamento do sistema

---

💡 Dica de Jedi

Nunca mexa direto no default:

IEASYS00 → base
IEASYS01 → custom

👉 Se quebrar, você volta.

---

⚡ LOADXX — O DNA DO IPL

Esse cara decide:

• qual nucleus usar
• qual configuração carregar
• qual PARMLIB seguir

---

🔹 Estrutura mental

LOADxx
  ↓
aponta para:
  - NUCLEUS
  - PARMLIB
  - CONFIG

---

🧨 Curiosidade

Um LOADxx pode subir vários sistemas no sysplex 😳

---

🚀 NIP — O CONSTRUTOR DO UNIVERSO

🔹 Nucleus Initialization Program

Ele:

• inicializa memória
• cria control blocks
• cria address spaces

---

🔥 Resultado

transforma hardware em z/OS funcional

---

🧩 LINK PACK AREA (LPA) — ONDE TUDO FICA PRONTO

🔹 Tipos:

• FLPA → fixo
• MLPA → modificado
• PLPA → paginável

---

💡 Tradução

LPA = “biblioteca carregada na memória para todo mundo usar”

---

👥 ADDRESS SPACES — O SISTEMA GANHA VIDA

🔥 Primeiro criado:

👉 MASTER (001 👀)

---

Depois:

• JES
• SMF
• RSM
• GRS
• TRACE
• DUMP

---

💡 Insight

Tudo nasce no IPL. Nada existia antes.

---

⚙️ PASSO A PASSO DO IPL (SIMPLIFICADO)

1. Power on
2. CPU lê DASD (SYSRES)
3. Carrega IPL text (IEAIPL00)
4. Carrega NUCLEUS
5. Executa NIP
6. Lê PARMLIB
7. Configura I/O (IODF)
8. Cria address spaces
9. Inicia subsistemas

👉 Boom 💥 sistema vivo

---

🔧 TUNING (onde os Jedi brilham)

🔥 Onde ajustar:

• PARMLIB
• LPA
• PAGE datasets

---

💡 Exemplos:

• mais memória → melhor performance
• LPA otimizada → menos I/O
• configuração errada → desastre

---

💀 TROUBLESHOOTING (quando tudo dá errado)

🔥 Problemas clássicos:

• dataset não encontrado
• erro no PARMLIB
• device inexistente
• LOADxx incorreto

---

🧨 Sintoma clássico:

👉 Disabled Wait Code

---

💡 Tradução

“Deu ruim antes do sistema existir.”

---

🧨 CURIOSIDADES QUE POUCOS SABEM

🤯 1. O sistema começa praticamente “cego”

Sem PARMLIB → nada funciona

---

🔥 2. O primeiro address space é 001

Nunca 000 (pegadinha de prova)

---

💀 3. IPL falha sem log amigável

Você ganha código e reza 😄

---

🧠 4. Tudo gira em torno de control blocks

Criados desde o início pelo NIP

---

🎯 RESUMO FINAL (nível padawan → jedi)

✔ IPL = nascimento do sistema

✔ SYS1 datasets = base de tudo

✔ PARMLIB = cérebro

✔ LOADxx = DNA

✔ NIP = construtor

✔ LPA = memória compartilhada

✔ Address spaces = vida

---

💥 FRASE FINAL

“Você acha que executa programas…
mas primeiro o z/OS precisa nascer — e esse nascimento é uma obra de engenharia absurda.”

 

 

Bellacosa Mainframe apresenta caçando os vilões em zos performance tuning

🍔💾 Essential z/OS Performance Tuning Workshop achando os vilões

Versão técnica: RMF, SMF e a arte de não tunar errado

O Essential z/OS Performance Tuning Workshop separa, logo de cara, dois tipos de profissionais:

1. Quem acha que faz performance tuning

2. Quem sabe onde olhar primeiro

Essa versão é para o segundo grupo — ou para quem quer migrar do 1️⃣ para o 2️⃣ sem trauma.

---

🎯 Regra zero do workshop

Nunca comece pelo parâmetro. Comece pela observação.

Antes de qualquer ALTER, DEFINE ou SET:

• Qual workload?

• Qual período?

• O que mudou?

• Existe baseline?

Sem isso, tuning vira superstição técnica.

---

🧠 CPU: o falso vilão

Onde olhar no RMF

RMF CPU Activity Report (Postprocessor)

Campos clássicos:

• % Busy

• % LPAR Utilization

• % Logical Processor Dispatch

• % IFA / zIIP / zAAP (quando aplicável)

Interpretação que o workshop ensina

• CPU alta com response time estável → sistema saudável

• CPU média com response time degradando → gargalo fora da CPU

• CPU baixa + atraso → WLM ou I/O

📌 Easter egg técnico:
Se o LPAR Delay cresce, não é falta de tuning — é falta de peso ou política errada.

---

⚙️ WLM: tuning começa aqui, não no SYS1.PARMLIB

RMF Workload Activity Report

Campos críticos:

• Service Class Period

• Velocity

• Average Response Time

• Delay Reasons

Exemplo típico visto no workshop:

Service Class: ONLINE_HI
Velocity Goal: 50
Achieved Velocity: 12
Delay: I/O 65%, Enqueue 20%

👉 Conclusão correta:

• Não adianta subir prioridade

• Não adianta mexer em CPU

• O gargalo não é WLM, é dependência externa

💡 Lição central:

WLM não resolve gargalo físico. Ele apenas escolhe quem sofre primeiro.

---

📊 RMF Monitor III: o “agora dói aqui”

Uso correto (e erro comum)

Monitor III serve para:

• Incidente ativo

• Observação em tempo real

• Confirmação de suspeita

Não serve para:

• Análise histórica

• Decisão estrutural

• Justificativa pós-morte

Campos típicos:

• Address Space Delay

• Device Response Time

• Enqueue Waits

📌 Erro clássico:
Usar Monitor III como prova definitiva em reunião de causa raiz.

---

🗃️ SMF: onde a discussão acaba

SMF 30 – Address Space Accounting

Usado para responder:

• Quem consumiu CPU?

• Quanto?

• Em qual período?

Exemplo prático:

SMF30:
CPU Time: baixo
Elapsed Time: alto

👉 Indício claro:

• Espera externa

• I/O

• Lock

• Dependência de outro job

---

SMF 70 / 72 – CPU e WLM

SMF 72 é o coração do tuning orientado a SLA.

Campos essenciais:

• Service Class Performance Index

• Delay Breakdown

• Period Transitions

📌 Easter egg de workshop:
Performance Index < 1.0 não é vitória se o response time continua ruim.

---

SMF 74 – I/O e Storage

Onde muitos problemas se revelam.

Campos observados:

• Device Response Time

• Pending Time

• Channel Utilization

Exemplo clássico:

• CPU “sobrando”

• Response time alto

• 3390 com Pending elevado

👉 Solução raramente é tuning de parâmetro.
Normalmente é layout, cache, storage tier ou concorrência mal planejada.

---

⚠️ Casos clássicos discutidos no workshop

🔥 “O batch atrasou tudo”

RMF mostra:

• Batch em baixa prioridade

• Online atrasando

SMF revela:

• Batch segurando enqueue crítico

• Online esperando lock

👉 Ajuste correto:

• Revisar serialização

• Reavaliar janela batch

• Não subir prioridade às cegas

---

🔥 “Depois da mudança ficou lento”

Primeira pergunta ensinada no workshop:

Qual foi o último change?

Sem resposta clara:

• tuning suspenso

• investigação começa

📌 Lição dura:

Performance tuning não corrige change mal feito.
Ele só mascara — até piorar.

---

🚀 O que o workshop realmente forma

Não forma “tuner de parâmetro”.
Forma analista de comportamento do sistema.

Quem sai sabendo:

• Correlacionar RMF + SMF

• Defender decisão com dados

• Evitar tuning destrutivo

• Criar baseline útil

No CPD, isso vira reputação.

---

🧠 Frase final  

“RMF mostra o sintoma.
SMF mostra a causa.
WLM executa a decisão — certa ou errada.”

O Essential z/OS Performance Tuning Workshop não ensina atalhos.
Ensina responsabilidade técnica em ambiente onde erro custa caro.

🧪 Plano de Tuning Batch COBOL – IBM Mainframe

 

🧪 Plano de Tuning Batch

COBOL – IBM Mainframe

“Batch lento não é destino, é diagnóstico.”

---

🟥 FASE 0 — PRINCÍPIO SAGRADO

❌ Nunca tune sem medir
❌ Nunca mude tudo de uma vez
❌ Nunca confie só em elapsed time

---

🟦 FASE 1 — IDENTIFICAÇÃO DO PROBLEMA

🎯 Objetivo

Descobrir ONDE o batch gasta tempo:

• CPU?

• I/O?

• Espera?

• Lock?

• Storage?

📌 Ações

☑ Identificar JOB / STEP problemático
☑ Horário de execução
☑ Pico ou fora do pico

🔧 Ferramentas

• SMF 30 (Job)

• SMF 72 (CPU)

• OMEGAMON

• RMF

• SDSF (CPU TIME)

💬 Fofoquinha:

Batch “lento” às vezes só roda no horário errado.

---

🟨 FASE 2 — CPU vs ELAPSED (o divisor de águas)

Situação	Diagnóstico
CPU alto / Elapsed baixo	Código ruim
CPU baixo / Elapsed alto	I/O, lock, espera
Ambos altos	Tudo errado

☑ Compare:

• CPU TIME

• EXCP

• SRB vs TCB

---

🟩 FASE 3 — ANÁLISE DE CPU (quando a conta dói)

🧠 Verificar compilação COBOL

☑ Parâmetros:

OPTIMIZE(2)
TRUNC(BIN)
ARITH(EXTEND)
DATA(31)
RULES

☑ Evitar:

• NUMCHECK em produção sem necessidade

• SSRANGE

• INITCHECK

📉 Ganho típico: 5% a 30%

---

🟪 FASE 4 — CÓDIGO COBOL (o crime mais comum)

🔪 Pontos clássicos de CPU alta

☑ DISPLAY em loop
☑ MOVE repetido
☑ IF aninhado
☑ PERFORM THRU
☑ Conversão implícita de tipos

💡 Melhoria

• Código linear

• Parágrafos curtos

• Cálculo com COMP/COMP-5

🥚 Easter egg:

Um DISPLAY por registro já custou mais que licença de compilador.

---

🟧 FASE 5 — I/O (onde o tempo some)

📊 Analisar

• EXCP alto

• WAIT I/O

• VSAM CI/CA mal dimensionado

☑ Ajustes

• Buffers maiores

• Redução de leitura repetida

• SORT externo em vez de interno

📉 Ganho típico: 10% a 50% de elapsed

---

🟫 FASE 6 — SORT (o vilão invisível)

☑ Verificar:

• SORT interno vs DFSORT

• Quantidade de registros

• Campos de chave

💣 Erro comum:

SORT interno com milhões de registros sem tuning.

☑ Preferir:

EXEC PGM=SORT

---

🟥 FASE 7 — JCL (ninguém olha, mas paga)

☑ Revisar:

• REGION exagerado

• STEPLIB duplicado

• Programas obsoletos rodando

☑ Ajustar:

• DISP correto

• CONCATENATION mínima

• DD redundante removido

---

🟦 FASE 8 — PARALELISMO E JANELA

☑ Avaliar:

• Jobs sequenciais sem dependência

• Execução fora do pico

• Divisão por partição lógica

💬 Fofoquinha:

Batch mais rápido é o que não disputa CPU.

---

🟩 FASE 9 — zIIP / LE (dinheiro dormindo)

☑ Verificar:

• LE habilitado

• Versão do COBOL

• Ambiente preparado

📉 Offload possível:

• XML

• JSON

• Serviços

• Partes do LE

---

🟪 FASE 10 — MEDIR NOVAMENTE (o momento da verdade)

☑ Comparar:

• CPU antes/depois

• Elapsed antes/depois

• EXCP antes/depois

• SMF

☑ Documentar:

• Mudança aplicada

• Ganho real

• Risco

---

☠️ ERROS QUE ARRUÍNAM O TUNING

Erro	Consequência
Mudar tudo de uma vez	Incidente
Não medir SMF	Ilusão
Otimizar DEV só	Nenhum ganho real
Ignorar I/O	Elapsed explode
Culpar o mainframe	Vergonha técnica

---

🎓 RESUMO PADAWAN

✔ Batch lento tem causa
✔ CPU não mente
✔ Código importa
✔ I/O mata
✔ JCL conta
✔ zIIP salva

---

🧠 FRASE FINAL BELLACOSA™

“Tuning não é mágica.
É respeito à máquina.”