El Jefe Midnight Lunch

✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes

Mostrar mensagens com a etiqueta otimização. Mostrar todas as mensagens

sexta-feira, 27 de fevereiro de 2026

☕ Se Você Ainda Usa Subscript… o Batch Já Está Rindo de Você

Bellacosa Mainframe apresenta guia de tabelas no COBOL

☕ “Se Você Ainda Usa Subscript… o Batch Já Está Rindo de Você”

O Guia Jedi de Tabelas COBOL que Todo Padawan Precisa Antes que o CPU Account Chegue 💸

“No Mainframe, memória é preciosa… mas CPU é dinheiro vivo.”

Padawan, aproxime-se do terminal. Hoje vamos falar de um dos poderes mais silenciosos — e mais subestimados — do universo COBOL:

🛰️ TABELAS. ÍNDICES. BUSCAS. MEMÓRIA PURA.

Se você domina isso… domina o coração do batch.
Se não domina… o batch domina você.

🧠 Parte 1 — A Verdade Oculta: OCCURS Não É Só Um Array

Muitos iniciantes pensam:

“Ah, OCCURS é só um array.”

Não, jovem padawan.
É um buffer estruturado diretamente na memória do programa.


01 EMP-TABLE.
   05 EMP-ENTRY OCCURS 100 TIMES.
      10 EMP-ID     PIC 9(6).
      10 EMP-NAME   PIC X(30).

Isso cria 100 registros contíguos.
Sem ponteiros. Sem heap. Sem frescura.

💡 Curiosidade:
COBOL foi projetado quando memória era absurdamente cara — por isso layouts são fixos e previsíveis.

⚔️ Parte 2 — Subscript vs Index: A Batalha dos Dois Caminhos

🔢 Subscript (o caminho do aprendiz)


MOVE EMP-NAME (WS-I) TO PRINT-NAME

✔ Simples
✔ Numérico
❌ Mais lento
❌ Recalcula endereço toda vez

⚡ Index (o caminho do Jedi)


05 EMP-ENTRY OCCURS 100 TIMES
   INDEXED BY EMP-IDX.

Uso:


SET EMP-IDX TO 1
MOVE EMP-NAME (EMP-IDX) TO PRINT-NAME

✔ Ponteiro interno
✔ Muito mais eficiente
✔ Necessário para SEARCH
✔ Não é numérico

🧙‍♂️ Easter Egg técnico:
Internamente, o índice é um deslocamento binário — não um número “1, 2, 3”.

🪄 Parte 3 — O Erro que Entrega o Padawan

Se você já escreveu isso:


ADD 1 TO EMP-IDX

🚨 O compilador não apenas desaprova…
ele julga sua linhagem inteira.

Índice só aceita:


SET EMP-IDX UP BY 1
SET EMP-IDX DOWN BY 1
SET EMP-IDX TO 1

💡 Índice NÃO é variável numérica.

🔍 Parte 4 — SEARCH: A Varredura do Deserto

Busca sequencial:


SEARCH EMP-ENTRY
   AT END DISPLAY "NOT FOUND"
   WHEN EMP-ID (EMP-IDX) = TARGET-ID
      DISPLAY "FOUND"
END-SEARCH

Características:

✔ Examina um a um
✔ Não precisa ordenar
✔ Começa na posição atual do índice

💎 Dica avançada:


SET EMP-IDX TO 5

Vai procurar do elemento 5 até o fim.

👉 Muito usado para retomar processamento após checkpoint.

🚀 Parte 5 — SEARCH ALL: O Salto no Hiperespaço

Busca binária:


SEARCH ALL EMP-ENTRY
   WHEN EMP-ID (EMP-IDX) = TARGET-ID
      DISPLAY "FOUND"
END-SEARCH

Mas cuidado…

⚠️ Regra de Ferro:

👉 A tabela DEVE estar ordenada pela chave da busca

Sem isso:

💀 Pode não encontrar valores existentes
💀 Não gera erro
💀 Bugs fantasma nas madrugadas de fechamento

📊 Comparação brutal

Método	Comparações (1 milhão itens)
Serial	até 1.000.000
Binária	~20

💸 Sim, isso vira dinheiro na fatura de CPU.

🔄 Parte 6 — SORT em Memória: O Poder Esquecido

Poucos padawans sabem:

COBOL pode ordenar uma tabela OCCURS inteira.


SORT EMP-ENTRY ASCENDING KEY EMP-ID

Se não especificar chave…

👉 Usa a KEY definida na tabela.


ASCENDING KEY EMP-ID

🧬 Parte 7 — REDEFINES: O Lado Negro da Memória

Aqui começa a magia obscura.


01 RAW-DATA PIC X(24).

01 EMP-TABLE REDEFINES RAW-DATA.
   05 EMP OCCURS 4 TIMES.
      10 EMP-ID PIC 9(2).
      10 EMP-NAME PIC X(4).

Nenhum byte é movido.

👉 Apenas reinterpretado.

🎯 Exemplo clássico


"10JOAO15MARIA20CARL"

Pode virar:

ID	Nome
10	JOAO
15	MARIA
20	CARL

💡 Isso é parsing sem custo de CPU.

🧹 Parte 8 — INITIALIZE: O Reset Jedi


INITIALIZE EMP-TABLE

Resultado:

✔ Alfanuméricos → espaços
✔ Numéricos → zeros

✈️ Variante poderosa


INITIALIZE EMP-TABLE
   REPLACING ALPHANUMERIC DATA BY "ABC"

Todos os campos recebem "ABC".

📚 Parte 9 — VALUE: Carregando a Tabela na Compilação


01 CITY-TABLE VALUE "LHRPEKMELJFK".
   02 CITY PIC X(3) OCCURS 4 TIMES.

Distribuição:

1 → LHR
2 → PEK
3 → MEL
4 → JFK

💡 Zero custo em runtime.

🏦 Parte 10 — O Que Bancos REALMENTE Fazem

Tabelas OCCURS são usadas para:

✔ Parâmetros carregados em memória
✔ Tabelas de códigos
✔ Conversões
✔ Regras de negócio
✔ Buffers massivos
✔ Lookups ultra rápidos

Em muitos sistemas críticos, elas substituem chamadas a banco.

🧠 Curiosidade Histórica

COBOL foi criado quando:

🧊 CPU era lenta
💾 Memória era caríssima
📼 Disco era ainda mais lento

Por isso:

👉 Processar em memória sempre foi o caminho do mestre.

🏆 Conclusão — O Segredo que Separa Padawans de Mestres

Se você entendeu este artigo…

Você aprendeu a:

✔ Controlar memória manualmente
✔ Otimizar CPU
✔ Implementar buscas eficientes
✔ Manipular dados sem cópia
✔ Pensar como um engenheiro mainframe

☕ Regra Suprema do Batch

“Quem domina tabelas… domina o tempo de execução.”

sábado, 24 de janeiro de 2026

💥 VOCÊ NÃO TEM PROBLEMA DE CPU — VOCÊ TEM FALTA DE VISIBILIDADE

Bellacosa Mainframe apresenta ferramenta de analise performance em z/os

💥 VOCÊ NÃO TEM PROBLEMA DE CPU — VOCÊ TEM FALTA DE VISIBILIDADE

🔬 Sampling Tools no z/OS: O Raio-X que expõe o que seu COBOL está escondendo

Se você é dev COBOL sênior, já viveu isso:

“O batch está lento… deve ser DB2.”
“CPU alta… deve ser o código.”
“Está demorando… talvez seja I/O…”

💣 Spoiler: na maioria das vezes… está todo mundo errado.

E é aqui que entram os Sampling Performance Tools — as ferramentas que transformam achismo em evidência.

🧠 Origem — Por que sampling nasceu?

Nos primórdios do mainframe, performance era analisada com:

Dumps
Traces pesados
Logs extensos

Problema?

❌ Alto overhead
❌ Impacto em produção
❌ Volume absurdo de dados

👉 A solução foi genial:

“E se observarmos o sistema em intervalos regulares… e usarmos estatística?”

Assim nasceram ferramentas como:

Compuware Strobe
IBM Application Performance Analyzer
CA Mainframe Application Tuner
Macro4 FreezeFrame

🔬 O conceito que muda tudo

📸 Sampling = tirar fotos da CPU

Imagine:


t1 → COBOL
t2 → DB2
t3 → VSAM
t4 → COBOL

Depois de milhares de amostras:


COBOL → 50%
DB2   → 30%
VSAM  → 20%

💥 Pronto. Você tem a verdade.

💣 O maior erro de todo dev COBOL

“Vou otimizar meu código…”

Sem saber:

onde está o problema
quanto ele pesa
se ele é realmente o culpado

👉 Isso é tuning no escuro.

🧠 O que o sampling realmente revela

✔ Módulo que consome CPU
✔ Offset (sim, linha lógica!)
✔ WAIT vs EXEC
✔ I/O vs DB2 vs ENQ
✔ System services (SVC, segurança, console)

🔥 Easter Egg (que poucos sabem)

🔍 Offset é praticamente um “GPS do bug”

Exemplo:


PROG001 offset X'1A' → 65% CPU

👉 Isso te leva direto para o trecho do COBOL

⚙️ Como usar na prática (passo a passo profissional)

1️⃣ Defina o alvo

Job batch
Step específico (sempre que possível)

2️⃣ Configure corretamente

👉 Regra de ouro:


Samples → 1000 a 1500 por minuto
Duração → 15 a 30 minutos

3️⃣ Use “Measure to Step End”

Especialmente para batch:

Nunca confie na duração média

4️⃣ Ative apenas coletores necessários

DB2 → se houver SQL
CICS → se for online
MQ → se houver mensagens

💣 Ativar tudo = overhead inútil

5️⃣ Execute e aguarde

Nunca analise:

❌ sessão ativa
❌ poucos samples

6️⃣ Leia o relatório como um especialista

📊 Caso 1


EXEC 90%
WAIT 10%

👉 Problema = CPU (código)

📊 Caso 2


EXEC 30%
WAIT 70%

👉 Problema = recurso externo (VSAM, DB2, lock)

🔥 Caso real (estilo produção)

Sintoma

Batch de 2 horas

Sampling mostra


DB2 → 60%
COBOL → 25%
VSAM → 15%

Diagnóstico

👉 NÃO é COBOL
👉 É SQL

Ação

Criar índice
Ajustar WHERE
Reduzir chamadas

Resultado

💥 2h → 20 min

🐢 VSAM — o vilão silencioso

Sampling revela coisas como:

CI/CA splits
excesso de I/O
buffer ruim

💣 VSAM mal definido destrói performance sem aviso

🧠 DB2 — o assassino elegante

Um único SQL pode consumir mais CPU que todo o COBOL

Sampling mostra:

tempo por SQL
frequência
impacto total

⚠️ Limitações (que você PRECISA entender)

❌ Não é trace
❌ Não mostra sequência exata
❌ Não mede rede (TCP/IP)
❌ Pode ignorar zIIP (em alguns casos)

🔥 Curiosidade (nível insider)

Sampling normalmente foca em CPU “cobrada” (GP)

Se você usa muito:

zIIP

👉 Pode estar vendo só parte da história

💣 Erros clássicos em produção

❌ 100 samples/min → inútil
❌ duração longa (6h) → desperdício
❌ não usar step end → perde o problema
❌ ativar todos coletores → overhead
❌ otimizar COBOL sem olhar DB2

🧠 Modelo mental definitivo


Sampling responde:
→ Onde está o problema?
→ Quem está causando?
→ Por quê?

Você resolve:
→ Como corrigir

🔥 Frases pra guardar

“Sem sampling, você tem opinião.
Com sampling, você tem evidência.”

“CPU alta não é problema.
CPU mal usada é.”

“O gargalo não está no código…
está na forma como ele acessa dados.”

🚀 Conclusão

Sampling Tools não são só ferramentas.

São:

🧠 Um modelo mental
🎯 Um método de diagnóstico
💥 Um divisor entre júnior e especialista

💣 A verdade final

“Você não melhora performance olhando código…
você melhora entendendo comportamento.”

quinta-feira, 22 de janeiro de 2026

💥 DB2 A REGRA QUE MUDA TUDO

Bellacosa Mainframe explorando o DB2

💥 DB2 A REGRA QUE MUDA TUDO

👉 O otimizador NÃO “ama índice”
👉 Ele escolhe o menor custo estimado

💡 Tradução Bellacosa:

Índice ruim pode ser pior que scan completo 😱

🧠 1. TABLESPACE SCAN vs INDEX SCAN

⚡ INDEX SCAN (ACCESSTYPE = 'I')

✔ Busca direta
✔ Poucas linhas retornadas
✔ Usa chave/index

👉 Ideal para:


WHERE ID = 100

🐢 TABLESPACE SCAN (ACCESSTYPE = 'R')

✔ Varre tudo
✔ Melhor quando retorna MUITAS linhas

👉 Ideal para:


SELECT * FROM CLIENTES

💣 CENÁRIO REAL 1 — “ÍNDICE IGNORADO”

🧪 Query


SELECT * 
FROM CLIENTES
WHERE CIDADE = 'SAO PAULO';

👉 Você criou índice em CIDADE… mas Db2 usa SCAN 😬

🧠 Por quê?

👉 Baixa seletividade

Se:

80% da tabela = “SAO PAULO”

Então:

Índice não compensa

🛠️ Solução

✔ Criar índice composto:


CREATE INDEX IDX1 
ON CLIENTES (CIDADE, ID);

✔ Ou melhorar filtro

💣 CENÁRIO REAL 2 — “MATCHCOLS BAIXO”

🧪 Índice:


CREATE INDEX IDX2 
ON CLIENTES (CIDADE, NOME);

🧪 Query:


SELECT * FROM CLIENTES
WHERE NOME = 'ANA';

😬 Resultado

👉 MATCHCOLS = 0

🧠 Por quê?

👉 Ordem do índice importa!

🛠️ Correção

✔ Criar índice correto:


CREATE INDEX IDX3 
ON CLIENTES (NOME);

💣 CENÁRIO REAL 3 — “SELECT * MATA PERFORMANCE”

🧪 Query


SELECT * FROM CLIENTES
WHERE ID = 10;

🧠 Problema

Mesmo com índice:

👉 Pode forçar acesso à tabela (data page)

🛠️ Otimização (Index Only Access)


SELECT ID FROM CLIENTES
WHERE ID = 10;

✔ Usa só o índice
✔ Muito mais rápido

💣 CENÁRIO REAL 4 — “RUNSTATS TE TRAIU”

🧪 Situação

Índice existe
Query boa
Mesmo assim: SCAN 😡

🧠 Causa

👉 Estatísticas desatualizadas

🛠️ Solução


RUNSTATS TABLESPACE DB1.TS1;

💡 Sem isso:

Otimizador “chuta”

🚀 CENÁRIO REAL 5 — “RANGE SCAN”

🧪 Query


SELECT * FROM CLIENTES
WHERE ID BETWEEN 1 AND 100;

🧠 Possível acesso

✔ Index range scan
✔ Ou scan completo (depende do volume)

🧠 DECISÃO DO OTIMIZADOR

Ele avalia:

Cardinalidade
Seletividade
Cluster ratio
Número de páginas
Estatísticas (RUNSTATS)

💥 GOLDEN RULES (nível expert)

🥇 1. Índice ≠ sempre melhor

🥇 2. Ordem do índice é tudo

🥇 3. RUNSTATS é obrigatório

🥇 4. SELECT * é inimigo

🥇 5. WHERE define performance

🔥 CHECKLIST DE GUERRA

Antes de subir:

✔ EXPLAIN rodado
✔ ACCESSTYPE correto
✔ MATCHCOLS adequado
✔ Índice alinhado ao WHERE
✔ RUNSTATS atualizado

😎 FRASES DE ARQUITETO

“Isso tá com baixa seletividade”
“Esse índice não casa com o predicado”
“O access path tá custando caro”
“Isso aí vai virar tablespace scan em produção”

Uma revisão das regras do Db2

💣 VISÃO FINAL (MENTALIDADE)

👉 Você não escreve SQL…
👉 Você negocia com o otimizador

Translate

domingo, 26 de abril de 2026

💣🔥 O MAINFRAME NÃO PERDOA: 1 LINHA DE CÓDIGO PODE CUSTAR MILHARES 🔥💣

💣🔥 O MAINFRAME NÃO PERDOA: 1 LINHA DE CÓDIGO PODE CUSTAR MILHARES 🔥💣

🧠 Performance eom contexto real de guerra

⚙️ Explicação — o que está POR TRÁS disso

🔥 Por que isso é ainda MAIS crítico em 2026?

💣 Análise técnica aprofundada dos pontos

1. 🗃️ DB2 Cursor mal usado = desperdício brutal

2. 💾 SORT vs I/O: a guerra invisível

3. 🔢 COMP vs COMP-3 — detalhe que vira milhões

4. ⚠️ SSRANGE — o vilão silencioso

🧨 O que ELE NÃO falou (mas deveria)

🧠 1. COBOL “bonito” pode ser lento

🧠 2. I/O é o verdadeiro inimigo

🧠 3. Batch Window é política, não técnica

💡 Exemplos reais (estilo “guerra de produção”)

🧪 Easter Eggs de Mainframe 🕵️

🎯 Conclusão — a verdade nua e crua

🚀 Pergunta provocativa

💣🔥 CHECKLIST CIRÚRGICO DE PERFORMANCE — COBOL + DB2 (NÍVEL PRODUÇÃO) 🔥💣

🧠 1. ACESSO AO DB2 (onde mais se perde dinheiro)

🔍 Checklist rápido:

💣 Cirurgia clássica:

⚙️ 2. LOOPS COBOL (o assassino silencioso)

🔍 Checklist:

💡 Dica de ouro:

💾 3. I/O (o verdadeiro vilão)

🔍 Checklist:

💣 Regra brutal:

🔢 4. TIPOS DE DADOS (COMP vs COMP-3)

🔍 Checklist:

💡 Impacto real:

⚠️ 5. PARÂMETROS DE COMPILAÇÃO

🔍 Checklist:

💣 Clássico erro:

🧮 6. SORT (onde muita gente erra feio)

🔍 Checklist:

💡 Insight:

🧠 7. DESIGN DO PROGRAMA

🔍 Checklist:

💣 Verdade dura:

🔥 8. JCL E EXECUÇÃO

🔍 Checklist:

📊 9. MONITORAMENTO (quem não mede, perde dinheiro)

🔍 Checklist:

💡 Ferramentas típicas:

🧪 10. MICRO-OTIMIZAÇÕES QUE VIRAM MILHARES 💸

🧨 CHECK FINAL (modo produção)

🎯 FECHAMENTO ESTILO MAINFRAME ROOT

sexta-feira, 27 de fevereiro de 2026

☕ Se Você Ainda Usa Subscript… o Batch Já Está Rindo de Você

☕ “Se Você Ainda Usa Subscript… o Batch Já Está Rindo de Você”

O Guia Jedi de Tabelas COBOL que Todo Padawan Precisa Antes que o CPU Account Chegue 💸

🛰️ TABELAS. ÍNDICES. BUSCAS. MEMÓRIA PURA.

🧠 Parte 1 — A Verdade Oculta: OCCURS Não É Só Um Array

⚔️ Parte 2 — Subscript vs Index: A Batalha dos Dois Caminhos

🔢 Subscript (o caminho do aprendiz)

⚡ Index (o caminho do Jedi)

🪄 Parte 3 — O Erro que Entrega o Padawan

🔍 Parte 4 — SEARCH: A Varredura do Deserto

🚀 Parte 5 — SEARCH ALL: O Salto no Hiperespaço

⚠️ Regra de Ferro:

👉 A tabela DEVE estar ordenada pela chave da busca

📊 Comparação brutal

🔄 Parte 6 — SORT em Memória: O Poder Esquecido

🧬 Parte 7 — REDEFINES: O Lado Negro da Memória

🎯 Exemplo clássico

🧹 Parte 8 — INITIALIZE: O Reset Jedi

✈️ Variante poderosa

📚 Parte 9 — VALUE: Carregando a Tabela na Compilação

🏦 Parte 10 — O Que Bancos REALMENTE Fazem

🧠 Curiosidade Histórica

🏆 Conclusão — O Segredo que Separa Padawans de Mestres

☕ Regra Suprema do Batch

sábado, 24 de janeiro de 2026

💥 VOCÊ NÃO TEM PROBLEMA DE CPU — VOCÊ TEM FALTA DE VISIBILIDADE

💥 VOCÊ NÃO TEM PROBLEMA DE CPU — VOCÊ TEM FALTA DE VISIBILIDADE

🔬 Sampling Tools no z/OS: O Raio-X que expõe o que seu COBOL está escondendo

🧠 Origem — Por que sampling nasceu?