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.

📘 REPOST: CICS Command Level para padawans

 

CICS Command Level for Padawans

📘 CICS Command Level para padawans

Um guia passo a passo para entender o que é CICS, aprender e planejar um roteiro de estudos com o orquestrador do online em Mainframe.

#ibm #mainframe #cobol #cics #t3270 #vsam #bms #ksds #esds #ceda #ceci #cemt 

Post no Linkedin

1

 

Bellacosa Mainframe conheça o banco de dados DB2 

💥 SEU COBOL TURBINADO MUITO ALÉM DO QSAM — É UM MOTOR DE GUERRA: O VERDADEIRO PAPEL DO DB2 NO IBM z17 QUE QUASE NINGUÉM TE EXPLICOU

---

Se você é dev COBOL sênior e ainda trata o Db2 como “apenas o banco”, deixa eu ser direto:

💀 Você está subestimando o componente mais crítico do seu sistema.

O IBM Db2 no mundo do z/OS — especialmente em arquiteturas modernas como o z17 — não é storage.

👉 É um motor transacional de alta precisão, otimizado ao longo de décadas para um único propósito:
não falhar quando dinheiro, tempo e reputação estão em jogo.

---

🧠 CAPÍTULO 1 — A ORIGEM: ONDE TUDO COMEÇOU

Antes de você escrever seu primeiro:

EXEC SQL SELECT ...

Já existia uma revolução acontecendo dentro da IBM.

---

🕰️ Linha do tempo real (sem romantização)

• 1970 → Modelo relacional (Edgar Codd)
• 1974 → System R (protótipo)
• 1983 → Db2 nasce no mainframe
• Hoje → roda bilhões de transações/dia

---

💀 Easter egg histórico

Db2 não foi feito para ser popular…
foi feito para ser confiável quando ninguém pode errar

Enquanto outros bancos nasceram para aplicações,
👉 Db2 nasceu para instituições

---

🧱 CAPÍTULO 2 — O QUE É DB2 NO MUNDO REAL

Vamos simplificar brutalmente:

👉 Db2 = gerenciador de estado confiável

---

💡 Não é só banco

Ele cuida de:

• consistência (ACID)
• concorrência (locking)
• recuperação (logging + recovery)
• performance (optimizer absurdo)

---

💻 Exemplo COBOL raiz

EXEC SQL
   UPDATE CONTA
   SET SALDO = SALDO - :VALOR
   WHERE ID = :ID
END-EXEC

👉 Parece simples…

Mas por trás disso o Db2:

• trava registros 🔒
• registra log 📝
• garante rollback 🔁
• otimiza acesso ⚡

---

💀 Insight Bellacosa

“Você escreve SQL…
o Db2 executa uma coreografia complexa que você nem vê.”

---

⚙️ CAPÍTULO 3 — DB2 NO IBM z17 (O QUE MUDA)

No z17, Db2 não está sozinho.

Ele trabalha integrado com:

• CICS
• RACF
• WLM
• Parallel Sysplex

---

🔥 Resultado

👉 Você tem:

• escalabilidade horizontal
• altíssima disponibilidade
• latência mínima

---

💣 Easter egg técnico

Um Db2 mal tunado no z/OS não só fica lento…
ele aumenta o custo do mainframe 💸

---

🔄 CAPÍTULO 4 — COMO DB2 PENSA (E VOCÊ NÃO PERCEBE)

Quando você roda:

SELECT * FROM CLIENTE WHERE ID = 10;

👉 Db2 não executa direto.

Ele:

1. Analisa estatísticas (RUNSTATS)
2. Escolhe plano (optimizer)
3. Decide índice vs scan
4. Define estratégia de acesso

---

💀 Insight crítico

“Db2 não executa sua query…
ele decide COMO executar.”

---

🔬 CAPÍTULO 5 — PASSO A PASSO REAL (COBOL + DB2)

---

🧩 Fluxo real

1. COBOL chama SQL
2. DBRM é usado
3. Package executa
4. Db2 processa
5. Resultado retorna

---

💻 Exemplo completo mental

EXEC SQL
   SELECT NOME
   INTO :WS-NOME
   FROM CLIENTE
   WHERE ID = :WS-ID
END-EXEC

---

🔥 O que acontece por trás:

• acesso via índice
• lock aplicado
• leitura buffer pool
• retorno otimizado

---

💀 Insight

“Seu programa parece simples…
o Db2 está fazendo engenharia de alta complexidade.”

---

🧠 CAPÍTULO 6 — FEATURES QUE DEV COBOL IGNORA (E NÃO DEVERIA)

---

⏳ Time Travel Query

Consultar passado:

SELECT * FROM CLIENTE
FOR SYSTEM_TIME AS OF '2020-01-01';

👉 Auditoria sem esforço

---

⚡ MQT (Materialized Query Table)

• pré-calcula resultado
• acelera relatórios

---

🔄 Continuous Ingest

• dados entrando sem travar sistema

---

🤖 Db2 AI (z/OS)

• tuning automático
• previsão de problemas

---

💀 Insight

“Se você não usa essas features…
você está usando só 30% do Db2.”

---

🔐 CAPÍTULO 7 — LOCKING (O PONTO QUE MAIS QUEBRA SISTEMA)

---

💡 O problema

Dois programas acessando o mesmo dado.

---

💥 Resultado possível

• lock
• wait
• deadlock 💀

---

💻 Exemplo clássico

Programa A trava linha
Programa B espera
Sistema degrada

---

💀 Insight definitivo

“A maioria dos problemas de produção não é SQL…
é concorrência mal entendida.”

---

🧠 CAPÍTULO 8 — DB2 NÃO É LEGADO

Vamos acabar com esse mito.

---

❌ Visão errada

“Db2 é coisa antiga”

---

✅ Realidade

Db2 hoje tem:

• REST API
• JSON
• AI
• integração cloud

---

💀 Insight

“Db2 não ficou para trás…
ele simplesmente não fez barulho.”

---

🔥 CAPÍTULO FINAL — A VERDADE QUE NINGUÉM TE CONTA

Se você trabalha com COBOL + Db2:

👉 Você não está mantendo legado

👉 Você está operando infraestrutura crítica global

---

💣 Frase final estilo Bellacosa

“Enquanto o mundo fala de microservices…
o Db2 continua garantindo que o dinheiro chegue no destino.”

 

 

Um Café no Bellacosa Mainframe

2,167 subscribers

Dominando o CICS: Dicas Essenciais para um DEV Jr em Mainframe

Bellacosa Mainframe

4,424 followers

July 23, 2025

Salve jovem padawan, continuando nosso caminho explorando a Alta Plataforma, compartilhando algumas histórias, causos e curiosidade. Além claro de dicas técnicas para evoluir na Stack Mainframe. Este artigo pretende apresentar mais detalhes do OLTP.

O CICS é o coração transacional de milhares de sistemas corporativos pelo mundo. Por trás das aplicações bancárias, financeiras, de seguros e do setor público, o CICS garante integridade, disponibilidade e desempenho para aplicações críticas. Trabalhar bem com CICS é mais do que saber programar em COBOL: exige boas práticas, sensibilidade técnica e visão de arquitetura.

Aqui vão 10 dicas práticas e estratégicas para você se desenrascar no uso do CICS no seu dia a dia:

---

1. Conheça a Estrutura do EIB (Execute Interface Block)

Saber conhecer todas as funcionalidades do CICS, ajuda a criar novas estrategias para solucionar as demandas. Saiba que todo programa CICS, seja em COBOL, PLI ou Natural tem acesso a uma estrutura automática chamada EIB, que guarda informações como:

• EIBDATE – Data atual
• EIBTIME – Horário de início da transação
• EIBTRNID – ID da transação
• EIBCPOSN – Código de posição do cursor

Dica: Use essas variáveis para rastrear execuções e criar logs úteis para debugging sem poluir seus programas com variáveis auxiliares.

---

2. Use Comandos CICS com Tratamento de Erros

Além dos bugs traps do COBOL, o CICS oferece soluções para controlar erros. Lembre-se disso uma anomalia deve ser tratada em código, não deixe o Z/OS trata-la para você, acredite em mim, surpresas desagradáveis aparecem. Nunca subestime um EXEC CICS RECEIVE, WRITE, SEND ou READ sem o devido HANDLE CONDITION.

Dica: Sempre implemente tratamento para NOTFND, MAPFAIL, PGMIDERR e SYSIDERR, mesmo em programas simples.

---

3. Modularize Programas com Comarea e Channels

Separe seu programa por SECTIONs,. cada estrutura em sua seção, assim fica mais facil a manutenção e evoluções. Evite programões monolíticos. Quebre lógicas complexas em subprogramas usando COMMAREA ou, em sistemas modernos, CHANNELS & CONTAINERS.

Dica: Channels são ideais para novos programas, com mais de um container e suporte a dados maiores que 32k.

---

4. Use o CEDA com Consciência.

Na linha de comando do CICS, existem muitas ferramentas, que devemos conhecer e utilizar para estarmos no "Estado da Arte" na codificação de programas Online. O CEDA é o utilitário de administração de recursos do CICS. Ao registrar mapas BMS, programas ou transações:

Dica: Sempre preencha os campos:

• Group: para identificar o módulo
• Language: COBOL, PLI, etc.
• Dynam: YES para programas que serão carregados sob demanda
• Use Newcopy: Após compilar, não esqueça de dar CEMT SET PROGRAM(PROGNAME) NEW

---

5. Use o CEMT para Investigar em Tempo Real

Lembre-se sempre o programa compilado vai para a Loadlib do CICS, o programa na memoria ainda é a versão antiga, por isso devemos fazer o REFRESH manualmente. O comando CEMT permite administrar e consultar o status de quase tudo no CICS e atualizar para a versão mais recente da Loadlib. Alguns exemplos:

• CEMT I TRANS(TRN1) – Consulta transação
• CEMT I PROG(PROG1) – Consulta programa
• CEMT SET PROG(PROG1) NEW – Atualiza módulo compilado, REFRESH.

Dica: Automatize comandos CEMT via scripts em macros de terminal ou CLISTs úteis para refresh em lote.

---

6. Atente-se à Segurança: TransID e Programas

Todo cuidado é pouco. Devemos codificar prevendo o passo-a-passo do usuario, não deixando caminhos alternativos aberto. Bloqueando possíveis injeção de código e usando e abusando do RACF. Programação defensiva e com segurança em CICS não é só papel do RACF. Certifique-se de:

• Definir programas com EXECUTION KEY(CICS), quando possível
• Restringir transações via RACF profiles (FACILITY, SURROGAT, etc.)
• Evitar deixar transações expostas como CEMT, CICS, CSMT

---

7. Mapeie o Fluxo com Ferramentas como InterTest ou Abend-AID

Dica: Use ferramentas como InterTest para depuração interativa e Abend-AID para leitura de dumps mais amigável, com call-stack, EIB, COMMAREA decodificada, etc.

---

8. Mantenha Seus Mapas BMS Atualizados

Sempre que alterar campos em uma tela, recompilar o BMS e não esquecer:

• Executar a assemblagem (DFHMSD)
• Atualizar o CEDA
• Dar NEWCOPY no programa associado

Dica: Gere mapa simbólico .SYM para usar como COPY no COBOL – garante alinhamento com os nomes dos campos.

---

9. Use Transações Utilitárias a seu favor

• CECI – Execução interativa de comandos
• CECS – Exibe o status dos comandos
• CEBR – Exibe conteúdo de TS/TD Queues

Dica: Faça testes rápidos com CECI EXEC CICS SEND TEXT ou WRITEQ TS para prototipagem.

---

10. Invista em Performance

• Prefira acesso a TSQ/TDQ local quando possível
• Use ENQ/DEQ para controle de concorrência leve
• Mantenha CICS region tunada com buffers e threads adequados
• Reuse COMMAREAs com responsabilidade, evitando sobrecarga de dados inúteis

---

Bônus: Curiosidades do CICS

• O CICS nasceu em 1969 para o setor bancário.
• O nome "CICS" é pronunciado como "Kiks".
• É o transacional mais usado no mundo, rodando bilhões de transações por dia.

---

Conclusão

Chegamos ao final desta pequena jornada, visite sempre nossa Newsletter Um Café no Bellacosa Mainframe, procuro responder pedidos, solicitações e melhorar sempre. Caso encontre algo, que discorde, entre em contato, esse é um trabalho em curso, de tempos em tempos, reviso, incluindo mais assuntos e corrigindo algumas gralhas, que sismam em aparecer.

Concluindo e pense com carinho, dominar o CICS é essencial para qualquer analista de sistemas z/OS. Ele vai muito além da tela verde e do COBOL: é um ecossistema poderoso, que exige disciplina, segurança, performance e organização. Ao aplicar essas dicas, você entrega sistemas mais robustos e confiáveis, e se destaca como profissional Mainframe.