Translate

quarta-feira, 15 de abril de 2026

🧪 LAB SMP/E — DO CAOS À ORQUESTRAÇÃO

 

Bellacosa Mainframe Laboratorio SMP/E do caos a orquestração

🧪 LAB SMP/E — DO CAOS À ORQUESTRAÇÃO

🎯 Objetivo do Lab

Você vai executar:

  1. 📦 RECEIVE / APPLY (com erro)
  2. 📊 REPORT (diagnóstico)
  3. 🔗 LINK MODULE (correção)
  4. 🏗️ BUILDMCS (empacotamento)

👉 Resultado final:

Um ambiente corrigido, analisado e exportável


🧱 CENÁRIO DO LAB

👉 Situação:

  • Produto instalado parcialmente
  • Módulo faltando no LMOD
  • PTF aplicada sem dependência

💥 Resultado:

Erro de execução + inconsistência SMP/E


🔥 PASSO 1 — RECEIVE (entrada da manutenção)

//RECEIVE JOB (ACCT),'SMP/E LAB',CLASS=A,MSGCLASS=X
//SMPCSI DD DISP=SHR,DSN=SYS1.SMP.CSI
//SMPPTS DD DISP=SHR,DSN=SYS1.SMP.PTS
//SMPCNTL DD *
SET BOUNDARY(GLOBAL).

RECEIVE SYSMODS
FROMDS('USER.PTF.INPUT')
BYPASS(HOLDSYSTEM).
/*

💡 O que está acontecendo

  • Carrega SYSMOD no SMPPTS
  • Ignora HOLD SYSTEM (perigoso 👀)

⚠️ PASSO 2 — APPLY (com erro proposital)

//APPLY JOB (ACCT),'SMP/E APPLY',CLASS=A,MSGCLASS=X
//SMPCSI DD DISP=SHR,DSN=SYS1.SMP.CSI
//SMPCNTL DD *
SET BOUNDARY(TZONE1).

APPLY PTFS(UX12345)
GROUPEXTEND
BYPASS(HOLDCLASS).
/*

💥 Resultado esperado

Erro tipo:

GIM35901E - REQUIRED SYSMOD NOT FOUND

👉 Tradução:

Dependência faltando


🧠 PASSO 3 — REPORT (diagnóstico inteligente)

//REPORT JOB (ACCT),'SMP/E REPORT',CLASS=A,MSGCLASS=X
//SMPCSI DD DISP=SHR,DSN=SYS1.SMP.CSI
//SMPPUNCH DD SYSOUT=*
//SMPCNTL DD *
SET BOUNDARY(TZONE1).

REPORT CROSSZONE.

REPORT ERRSYSMODS.

REPORT SYSMODS.
/*

🔍 O que você vai ver

  • Dependências faltantes
  • PTFs necessárias
  • Conflitos

💡 E mais importante:
👉 SMPPUNCH com comandos prontos


🔗 PASSO 4 — LINK MODULE (cirurgia)

//LINKMOD JOB (ACCT),'SMP/E LINK',CLASS=A,MSGCLASS=X
//SMPCSI DD DISP=SHR,DSN=SYS1.SMP.CSI
//SMPCNTL DD *
SET BOUNDARY(TZONE1).

LINK MODULE(CSAMPLE)
FROMZONE(TZONE2).
/*

🧠 O que acontece

  • Busca módulo em outra zona
  • Rebuild do LMOD
  • Cria TIEDTO

💡 Resultado:

Executável corrigido sem reinstalar tudo


🏗️ PASSO 5 — BUILDMCS (empacotar o ambiente)

//BUILDMCS JOB (ACCT),'SMP/E BUILD',CLASS=A,MSGCLASS=X
//SMPCSI DD DISP=SHR,DSN=SYS1.SMP.CSI
//SMPPUNCH DD SYSOUT=*
//SMPCNTL DD *
SET BOUNDARY(TZONE1).

BUILDMCS FORFMID(CICS123).
/*

📦 Resultado

No SMPPUNCH:

  • ++FUNCTION
  • ++MOD
  • ++JCLIN

👉 Você criou um:

produto instalável do seu ambiente


🔁 PASSO 6 — APPLY CORRIGIDO

//APPLY2 JOB (ACCT),'SMP/E APPLY OK',CLASS=A,MSGCLASS=X
//SMPCSI DD DISP=SHR,DSN=SYS1.SMP.CSI
//SMPCNTL DD *
SET BOUNDARY(TZONE1).

APPLY PTFS(UX12345)
GROUPEXTEND
CHECK.
/*

💡 Agora

  • Sem erro
  • Dependências resolvidas
  • Ambiente consistente

🎯 LIÇÕES DO LAB (ESSENCIAL)

🧠 1. APPLY sem REPORT = risco

🧠 2. LINK MODULE = solução cirúrgica

🧠 3. BUILDMCS = portabilidade

🧠 4. REPORT = prevenção


💥 EASTER EGGS (NÍVEL BELLACOSA)

😈 Se você ignorar HOLDDATA
👉 vai quebrar produção

😈 Se usar LINK demais
👉 cria acoplamento invisível

😈 Se não usar BUILDMCS
👉 não consegue reconstruir ambiente


🚀 DESAFIO (NÍVEL HARDCORE)

Tente:

  1. Rodar APPLY sem GROUPEXTEND
  2. Ver erro
  3. Resolver com REPORT + FIXCAT

🧠 FRASE FINAL DO LAB

“Quem roda SMP/E executa comando…
quem domina SMP/E controla o sistema.”


terça-feira, 14 de abril de 2026

🧠 SMP/E na Prática: O que são MCS — Modification Control Statements?


Bellacosa Mainframe apresenta SMP/E na pratica o fluxo de um MCS



🧠 SMP/E na Prática : O que são MCS — Modification Control Statements?

Os MCS (Modification Control Statements) são instruções de controle usadas pelo SMP/E para descrever o que um pacote de manutenção contém e como ele deve ser instalado.

👉 Pense no MCS como a “receita” que diz ao SMP/E:

  • quais módulos vão ser substituídos,
  • quais macros entram ou saem,
  • dependências necessárias,
  • pré-requisitos,
  • co-requisitos,
  • SYSMODs substituídos,
  • módulos afetados,
  • e onde tudo deve ser aplicado.

Essas instruções aparecem normalmente dentro de:

  • PTFs (Program Temporary Fixes)
  • APARs
  • USERMODs
  • FMIDs (instalação de produtos)

🧾 Como os MCS são emitidos?

Você não digita MCS manualmente durante a aplicação normal. Eles vêm dentro dos pacotes de manutenção, distribuídos pelo fornecedor (ex.: IBM).

O fluxo típico é:

  1. Você recebe um PTF/APAR.
  2. Dentro dele existem blocos MCS, como:
    • ++VER
    • ++MOD
    • ++MAC
    • ++JCLIN
    • ++HOLD
    • ++IF / ++REQ / ++PRE
  3. Esses blocos descrevem ao SMP/E:
    • quais módulos substituir
    • como montar link-edit
    • dependências
    • regras de instalação

⚙️ Onde o APPLY entra nessa história?

O comando APPLY do SMP/E processa as instruções MCS e efetivamente instala as mudanças no ambiente target.

Fluxo simplificado:

  1. RECEIVE
    • lê os MCS e registra no banco SMP/E.
  2. APPLY
    • valida dependências declaradas nos MCS.
    • verifica PRE/REQ/IF.
    • monta JCL se houver ++JCLIN.
    • atualiza módulos, macros, etc.
  3. ACCEPT
    • confirma no DLIB (distribution library).

🔄 Relação direta entre MCS e APPLY

✔ Os MCS dizem o que fazer.
✔ O APPLY executa o que foi declarado.

Exemplo conceitual:

++VER
++MOD(MYMOD) DISTLIB(AOSL)
++MAC(MYMAC)
++JCLIN

O APPLY vai:

  • validar PREs e REQs,
  • aplicar módulos,
  • montar e executar o JCLIN,
  • atualizar o ambiente.

🧩 O APPLY “lê” os MCS?

Exatamente. O SMP/E usa os MCS como instruções de engenharia. O APPLY:

  • lê os blocos ++VER / ++MOD / ++MAC / ++JCLIN
  • monta a sequência correta
  • valida integridade
  • garante consistência entre FMIDs, SYSMODs e bibliotecas

Sem MCS, o APPLY não saberia o que fazer.


🧪 Exemplo didático

Imagine um PTF que corrige um módulo COBOL:

O MCS pode declarar:

++VER(Z038) FMID(HBB7780).
++MOD(IGYCRCTL) DISTLIB(SIGYLOAD).

O APPLY irá:

  • verificar FMID HBB7780
  • garantir dependências
  • substituir o módulo IGYCRCTL na loadlib correta

🧠 Resumo prático

  • MCS = linguagem que descreve a manutenção.
  • SMP/E = interpretador/engine.
  • APPLY = ação que materializa as mudanças.

Um exemplo de MCS realista para um PTF que altera componentes do IBM Enterprise COBOL for z/OS e depende do runtime do IBM Language Environment (LE).

⚠️ Este é um exemplo didático (estrutura fiel, mas nomes ilustrativos).


📦 Exemplo — MCS de um PTF de COBOL/LE

Imagine um PTF que:

  • Atualiza o módulo IGZCCTL (runtime LE para COBOL)
  • Atualiza o compilador IGYCRCTL
  • Exige um pré-requisito
  • Inclui JCLIN para link-edit

Exemplo MCS

++PTF(UX12345) REWORK(20260413).
++VER(Z038)
FMID(HIGY170)
PRE(UJ99999)
REQ(LE37000).

++HOLD(UX12345)
SYSTEM
REASON(ACTION)
DATE(260413)
COMMENT(
'Este PTF atualiza módulos do compilador COBOL e
componentes de runtime LE. Requer rebind após APPLY.'
).

++MOD(IGYCRCTL) DISTLIB(SIGYCOMP) SYSLIB(SIGYCOMP).
++MOD(IGZCCTL) DISTLIB(SCEERUN) SYSLIB(SCEERUN).

++MAC(IGZMAC01) DISTLIB(SCEEMAC).

++JCLIN.
//LKED EXEC PGM=IEWL,PARM='LIST,XREF,LET'
//SYSLMOD DD DSN=CEE.SCEERUN,DISP=SHR
//SYSLIN DD *
INCLUDE SYSLIB(IGZCCTL)
ENTRY IGZCCTL
NAME IGZCCTL(R)
/*
++END

🧠 O que cada bloco faz?

✔️ ++PTF

Define o SYSMOD e metadados.

✔️ ++VER

Define o FMID alvo (feature a ser mantida) e dependências:

  • PRE → pré-requisitos
  • REQ → requisitos obrigatórios

✔️ ++HOLD

Impede instalação automática e obriga ação manual (por exemplo, rebind).

✔️ ++MOD

Declara módulos a substituir e onde instalá-los.

✔️ ++MAC

Declara macros a atualizar.

✔️ ++JCLIN

Fornece instruções de link-edit que o SMP/E executará no APPLY.


⚙️ Como isso interage com APPLY?

Quando você executa:

SET BDY(TGT1).
APPLY PTFS(UX12345).

O SMP/E irá:

  1. Verificar FMID e PRE/REQ
  2. Validar HOLDS
  3. Copiar módulos declarados em ++MOD
  4. Rodar o JCLIN para link-edit
  5. Registrar o resultado no CSI

🧩 Resumo rápido

  • MCS = contrato do PTF
  • APPLY = motor que executa esse contrato
  • O ++JCLIN evita você montar manualmente link-edits 

segunda-feira, 13 de abril de 2026

🔧 Laboratório Prático – Tuning de VSAM no z/OS

 

Bellacosa Mainframe em mão na massa tuning de VSAM

🔧 Laboratório Prático – Tuning de VSAM no z/OS

🎯 Objetivo do Lab

  • Melhorar desempenho de datasets VSAM
  • Reduzir splits de CI/CA
  • Otimizar acesso por chave
  • Ajustar buffers e freespace
  • Diagnosticar gargalos reais

Tudo isso no contexto de IBM z/OS, usando Virtual Storage Access Method e utilitários como IDCAMS.


🧱 Lab 1 — Diagnóstico inicial (onde dói?)

Antes de mexer, descubra o estado real do dataset.

Passo 1 — Obter estatísticas reais

//STEP1 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
LISTCAT ENTRIES(MEU.VSAM.KSDS) ALL
/*

O que observar

  • CI/CA splits
  • Freespace atual
  • Tamanho médio de registros
  • Número de extents
  • Buffering atual

⚠️ Se você não mede, você só está chutando.


⚡ Lab 2 — Reduzindo CI Splits (onde mora a dor)

CI Split = fragmentação = I/O extra = usuário bravo.

Situação comum

Dataset crescendo e inserções frequentes no meio do arquivo.

Ação — Ajustar FREESPACE

//SYSIN DD *
ALTER MEU.VSAM.KSDS
FREESPACE(20 10)
/*
  • 20% livre em cada CI
  • 10% livre em cada CA

Isso dá “espaço de manobra” para inserções sem quebrar tudo.


🚀 Lab 3 — Buffers: o turbo escondido

Buffers mal configurados matam performance silenciosamente.

Verifique no JCL da aplicação:

//DD1 DD DSN=MEU.VSAM.KSDS,DISP=SHR,AMP='BUFND=20,BUFNI=10'
  • BUFND → dados
  • BUFNI → índice

📈 Regra prática:

  • Aplicações intensivas em leitura → aumente BUFND
  • Acesso por chave → aumente BUFNI

🧪 Lab 4 — Reorganização (o reset saudável)

Com o tempo, fragmentação vira regra.

Backup e Reorg

//REPRO EXEC PGM=IDCAMS
//SYSIN DD *
REPRO INFILE(OLD) OUTFILE(NEW)
/*

✔ Remove fragmentação
✔ Reequilibra índices
✔ Melhora I/O


🧠 Lab 5 — Escolha do tipo certo de dataset

Nem tudo é KSDS.

  • Muitas inserções sequenciais? → considere ESDS
  • Acesso por posição fixa? → RRDS
  • Acesso por chave intenso? → KSDS

Escolher errado custa caro.


🧩 Lab 6 — Medindo impacto (antes x depois)

Sempre compare:

  • tempo de resposta
  • I/O count
  • splits por hora
  • consumo de CPU

Sem isso, não é tuning — é fé.


💣 Erros clássicos (até de sênior)

  • Aumentar buffers sem medir impacto
  • Ignorar freespace
  • Reorg sem revisar parâmetros
  • Copiar parâmetros de outro sistema “porque lá funciona”

Cada ambiente é único.


🏁 Resultado esperado

Se fizer certo, você verá:

  • menos splits
  • menos I/O
  • menor tempo de resposta
  • usuários mais felizes (e menos incidentes às 2h da manhã 😄)

💥 VSAM -> SEU COBOL NÃO GUARDA DADOS — ELE COMANDA UM IMPÉRIO: A VERDADE BRUTAL SOBRE VSAM NO z/OS QUE TODO SÊNIOR DEVERIA DOMINAR

 

Bellacosa Mainframe e o poder do VSAM

💥 VSAM -> SEU COBOL NÃO GUARDA DADOS — ELE COMANDA UM IMPÉRIO: A VERDADE BRUTAL SOBRE VSAM NO z/OS QUE TODO SÊNIOR DEVERIA DOMINAR

Se você programa há anos em COBOL, provavelmente já ouviu a frase: “grava no VSAM”.
Mas o que isso realmente significa no universo do IBM z/OS?

Spoiler: não é só “um arquivo”. É um mecanismo de armazenamento tão robusto que sustenta bancos, seguradoras, governos e varejo global — sem fazer barulho.

Hoje vamos olhar o VSAM como engenheiros de verdade olham: por dentro.


🧬 O começo de tudo — quando “arquivo” não era suficiente

No início da era mainframe, os dados eram armazenados em sequências lineares. Funciona? Sim. Escala? Não.
Com o crescimento de aplicações transacionais, era preciso:

  • acesso direto e rápido,
  • indexação inteligente,
  • controle fino de armazenamento,
  • integridade em workloads absurdos.

E aí nasce o Virtual Storage Access Method, projetado para dar ao mainframe um modelo de armazenamento estruturado, indexado e previsível.

O VSAM não é só um “arquivo”. É uma camada de acesso inteligente a dados.


🏗️ A arquitetura — onde a mágica acontece

No VSAM, você não pensa em linhas ou páginas. Você pensa em estruturas:

📦 KSDS — o queridinho

  • Acesso por chave
  • Ideal para transações
  • Indexado automaticamente

Exemplo real:

Cliente → chave = CPF
Acesso direto em milissegundos.


📦 ESDS — o sequencial turbinado

  • Dados entram em ordem
  • Ótimo para logs e histórico

📦 RRDS — quando posição é tudo

  • Acesso por número de registro
  • Perfeito para tabelas estáveis

📦 LDS — o lado oculto

  • Sem estrutura imposta
  • Usado por componentes internos (ex.: bases internas do IBM Db2 for z/OS)

⚙️ Quem manda aqui é o IDCAMS

Se VSAM é o motor, o IDCAMS é o mecânico.

Criar dataset? DEFINE CLUSTER
Apagar? DELETE
Alterar atributos? ALTER

Exemplo simplificado:

DEFINE CLUSTER (
NAME(MEU.VSAM.KSDS)
INDEXED
KEYS(10 0)
RECORDSIZE(200 200)
TRACKS(10 5)
)

Parece simples… até você errar o tamanho do registro e o mundo desabar 😅


⚡ Performance — o jogo de xadrez

No VSAM, performance não é sorte. É engenharia.

Fatores que importam:

  • tamanho do CI (Control Interval)
  • tamanho do CA (Control Area)
  • splits
  • buffering
  • cache

Se você já viu isso em produção:

IDC3351I ** VSAM OPEN RETURN CODE IS 168

… você já entendeu que VSAM não perdoa descuido.


🔥 VSAM + CICS: casamento que sustenta bancos

Quando um programa roda no IBM CICS Transaction Server, e precisa de dados em milissegundos, quem responde é o VSAM.

Transação chega → CICS dispara → VSAM entrega → cliente feliz.

E quando não entrega… todo mundo descobre rapidinho 😂


🧪 Easter Eggs que quase ninguém comenta

  • VSAM não foi criado só para aplicações: o próprio sistema usa internamente.
  • LDS é muito usado internamente por componentes de sistema.
  • Muitos “bancos de dados” legados são, na verdade, VSAM com lógica de negócio em COBOL.

🧠 Erros clássicos (até de gente experiente)

❌ CI pequeno demais → muitos splits
❌ Key mal definida → gargalo eterno
❌ Ignorar FREESPACE → performance degrada rápido
❌ Tratar VSAM como arquivo texto → sofrimento garantido


🛠️ Dica de ouro — o que separa o sênior do júnior

Júnior pensa:

“Funciona.”

Sênior pensa:

“Funciona em produção às 14h de sexta-feira?”


🚀 Conclusão — dominar VSAM é dominar o core do mainframe

Se você trabalha com COBOL, VSAM não é opcional. É base.
Entender VSAM é entender como dados realmente vivem no mainframe.

E quando você domina isso, você não é só programador —
você é engenheiro de sistemas críticos.

domingo, 12 de abril de 2026

💥 SEU COBOL NÃO É LEGADO — É OURO AUTOMATIZÁVEL: Como o IBM RPA Transforma Mainframe em Máquina de Produtividade

 

Bellacosa Mainframe introduz o IBM RPA

💥 SEU COBOL NÃO É LEGADO — É OURO AUTOMATIZÁVEL: Como o IBM RPA Transforma Mainframe em Máquina de Produtividade

Se você é um dev COBOL raiz, daqueles que já domou JCL, sobreviveu a dumps indecifráveis e conversa com o CICS como quem pede café… então segura essa: RPA não é modinha de mercado — é multiplicador de mainframe.

E quando falamos de RPA corporativo de verdade, estamos falando de IBM — que resolveu levar automação além da superfície e conectar com o coração do legado: o seu COBOL.


🧠 O que é IBM RPA (sem papo de vendedor)

O IBM Robotic Process Automation (RPA) é uma plataforma que cria “robôs de software” capazes de:

  • Simular ações humanas (digitar, clicar, navegar)
  • Integrar sistemas que nunca foram pensados para conversar
  • Automatizar processos repetitivos
  • Orquestrar fluxos complexos (inclusive com IA)

👉 Em linguagem de mainframe:

É como ter um operador batch + usuário TSO + integrador MQ + analista funcional… tudo em um script automatizado.


🕰️ Origem e evolução (sim, isso tem história)

Antes de virar hype:

  • Anos 70–90: Automação já existia… via JCL, CLIST, REXX
  • Anos 2000: Scripts de automação GUI começam a aparecer
  • Pós-2015: Surge o conceito moderno de RPA
  • IBM entra no jogo e evolui para algo corporativo, robusto e integrável com:
    • z/OS
    • APIs REST
    • IA (Watson)

💡 Ou seja:

O RPA moderno é o “REXX com esteróides + interface gráfica + IA”


🔥 Por que isso importa para quem vive no COBOL?

Porque o problema nunca foi o COBOL.

O problema é:

  • Integração com sistemas modernos
  • Processos manuais
  • Interfaces antigas (green screen, alguém? 😏)
  • Dependência humana para tarefas repetitivas

👉 O RPA resolve isso SEM reescrever seu sistema.


💡 Caso real (estilo Bellacosa)

🎯 Cenário

Sistema COBOL no CICS que:

  • Consulta saldo
  • Atualiza registros VSAM
  • Não tem API
  • Só acessível via terminal 3270

😵 Problema

Um time precisa consultar 5.000 registros/dia manualmente


🤖 Solução com IBM RPA

O robô:

  1. Abre emulador 3270
  2. Loga no sistema
  3. Navega pelas telas
  4. Executa transações CICS
  5. Captura dados
  6. Exporta para CSV / envia via API

🧾 Resultado

AntesDepois
6 horas humanas15 minutos
Erros manuaisZero
Stress operacionalEliminado

💥 E o melhor:

Nenhuma linha de COBOL alterada


⚙️ Como funciona por dentro (visão técnica)

O IBM RPA tem três pilares:

1. 🧩 Designer

  • Interface visual (drag & drop)
  • Criação de bots
  • Integração com scripts

2. 🤖 Bots

  • Executam tarefas
  • Podem ser:
    • Attended (com usuário)
    • Unattended (totalmente automáticos)

3. 🎛️ Control Center

  • Orquestra execução
  • Agenda jobs
  • Monitora performance

👉 Sim, é tipo um JES2 moderno… só que para automação 😄


🛠️ Exemplo prático (pseudo fluxo)

START BOT
|
|-- Launch Terminal 3270
|-- Send Keys: USER/PASSWORD
|-- Navigate: CICS TXN ABCD
|-- Read Screen Field
|-- Store Data
|-- Loop Records
|-- Export CSV
|
END BOT

💡 Para um coboleiro:

Isso é basicamente um PERFORM UNTIL… com tela verde no meio


🧪 Easter Eggs que poucos sabem

🔥 1. RPA + MQ = integração invisível
Você pode acionar bots via filas MQ → automação baseada em eventos

🔥 2. RPA pode chamar APIs REST e depois alimentar COBOL
Bridge perfeita entre cloud e z/OS

🔥 3. Pode automatizar ISPF
Sim… ISPF. Aquela telinha azul dos anos 80 😄

🔥 4. Substitui scripts Frankenstein
Adeus .bat + macro Excel + script Python + reza


🧠 Curiosidades que mudam o jogo

  • RPA NÃO é só front-end → pode orquestrar backend
  • RPA NÃO substitui COBOL → potencializa COBOL
  • RPA NÃO é só “clicador” → pode tomar decisões com IA

⚠️ Onde tomar cuidado

RPA NÃO é bala de prata.

Evite usar quando:

  • Existe API bem definida → use integração direta
  • Processo é instável → bot quebra fácil
  • Tela muda frequentemente → manutenção alta

👉 Regra de ouro:

Use RPA para estabilizar o legado, não para mascarar caos


🚀 Passo a passo para começar (mentalidade mainframe)

1. Identifique processos repetitivos

  • Batch manual?
  • Consulta operacional?
  • Input humano?

2. Escolha um “quick win”

  • Algo pequeno, mas visível

3. Modele o fluxo

  • Pense como um JCL + COBOL

4. Crie o bot no IBM RPA

5. Teste como se fosse produção

  • Simule erro
  • Timeout
  • Input inválido

6. Coloque sob controle (governança!)

  • Logs
  • Monitoramento
  • Auditoria

🔥 Insight final (pra fechar com impacto)

Você não precisa modernizar o mainframe jogando ele fora.

Você moderniza quando:

  • Conecta
  • Automatiza
  • Orquestra

E o IBM RPA faz exatamente isso:

Ele não substitui o COBOL…
Ele transforma seu COBOL em uma API viva — mesmo sem API.


☕ Conclusão no estilo Bellacosa

Se o JCL foi o maestro do batch…
Se o CICS foi o rei do online…

Então o RPA é:

💥 O operador invisível que nunca erra, nunca cansa e nunca pede férias

sábado, 11 de abril de 2026

💣 VSAM LENTO? NÃO É O MAINFRAME — É O SEU TUNING! 🔥 Os Segredos de Performance que Ninguém Te Conta

 

Bellacosa Mainframe VSAM lento tuning IDCAMS e outros segredinhos

💣 VSAM LENTO? NÃO É O MAINFRAME — É O SEU TUNING! 🔥 Os Segredos de Performance que Ninguém Te Conta

🧠 1) Escolha o tipo correto de arquivo VSAM

📌 Tradução

O VSAM suporta quatro tipos principais de datasets:

  • ESDS (Entry-Sequenced Data Set) → acesso sequencial
  • KSDS (Key-Sequenced Data Set) → acesso por chave
  • RRDS (Relative Record Data Set) → acesso direto por número relativo
  • LDS (Linear Data Set) → armazenamento bruto (usado por DB2, etc.)

Cada tipo possui características diferentes e deve ser escolhido conforme o padrão de acesso aos dados.


💬 Comentário Bellacosa

Aqui está o primeiro erro clássico de projeto:

❌ “Vou usar KSDS pra tudo porque é mais completo”

👉 Resultado: I/O desnecessário, split, CI/CA fragmentation, e performance indo pro ralo.


🧪 Exemplo prático

✔ Caso ideal:

  • Batch sequencial (ex: faturamento diário)
    ESDS ganha disparado
  • Sistema online CICS com lookup por chave
    KSDS obrigatório
  • Tabela indexada por posição fixa
    RRDS simplifica tudo

🚀 Dica avançada (pouco falada)

Se seu acesso for altamente randômico:

👉 Combine:

  • KSDS
    • SMB + ACCBIAS=DO (Direct Optimized)

Isso muda o jogo de performance.


🧠 2) Otimização de buffers

📌 Tradução

Buffers são áreas de memória usadas para armazenar dados temporariamente durante operações VSAM.

  • Poucos buffers → excesso de I/O
  • Muitos buffers → desperdício de CPU/memória

💬 Comentário Bellacosa

Aqui mora um dos maiores gargalos invisíveis:

VSAM não é lento…
VSAM mal bufferizado é lento.


🧪 Exemplo prático (JCL)

//DD1 DD DSN=SEU.VSAM.KSDS,
// AMP=('BUFND=20','BUFNI=10')
  • BUFND → buffers de dados
  • BUFNI → buffers de índice

🧠 Regra de ouro

Tipo de acessoAjuste
SequencialBUFND alto
RandômicoBUFNI mais importante

🚀 Nível PRO (SMB tuning)

AMP=('ACCBIAS=DO','SMB')
  • DO → acesso randômico otimizado
  • SO → sequencial
  • SW/DW → dinâmico

💣 Isso pode reduzir I/O drasticamente.


🧠 3) Minimizar tamanho de registro

📌 Tradução

O tamanho do registro influencia diretamente:

  • Quantidade de blocos
  • Uso de buffer
  • Transferência de dados

💬 Comentário Bellacosa

Esse é clássico de legado:

“Ah, deixa esse campo aqui... vai que um dia usam”

👉 Resultado:

  • Records inflados
  • CI mal aproveitado
  • Mais EXCP

🧪 Exemplo

❌ Ruim:

Cliente:
- Nome (100 bytes)
- Código (10)
- 20 campos não usados

✔ Melhor:

Cliente:
- Nome (40)
- Código (10)

🚀 Técnicas avançadas

  • Compressão de dados
  • REDEFINES em COBOL
  • Uso de campos variáveis (spanned records com cuidado)

💣 Trade-off real

Registro pequenoRegistro grande
+ menos I/O+ menos splits
- desperdício de espaço- mais dados por I/O

🧠 4) Ajuste da configuração de I/O

📌 Tradução

A configuração de I/O inclui:

  • Tipo de device
  • Velocidade
  • Canais
  • Pathing
  • Alocação

Ferramentas recomendadas:

  • SMF
  • RMF

💬 Comentário Bellacosa

Aqui entramos no território dos sysprogs 🔥

Às vezes o problema NÃO é o VSAM
👉 é o storage, canal ou concorrência


🧪 Exemplo real

Problema:

  • VSAM lento

Análise SMF:

  • Alta contenção em volume

Solução:

  • Redistribuir datasets
  • Melhorar striping
  • Ajustar cache

🚀 Dica ninja

  • Use LSR (Local Shared Resources) em CICS
  • Use RLS (Record Level Sharing) para concorrência

💣 Isso muda completamente o comportamento do VSAM online


🧠 5) Considerações extras (parte mais rica!)

💬 Expansão Bellacosa

Aqui entram os segredos que poucos documentam 👇


🔥 CI SIZE (Control Interval)

  • Sequencial → CI maior (ex: 32K)
  • Randômico → CI menor (ex: 4K ou 8K)

🔥 CA SIZE (Control Area)

  • Afeta splits e performance
  • CA maior → menos splits

🔥 FREESPACE

FREESPACE(20 10)
  • 20% no CI
  • 10% no CA

👉 Reduz splits (ESSENCIAL em KSDS)


🔥 Secondary Allocation

Evite muitos extents:

SPACE=(CYL,(100,50))

🔥 Split (o vilão silencioso)

Quando ocorre:

  • CI Split
  • CA Split

💣 Consequência:

  • Mais I/O
  • Fragmentação
  • Queda brutal de performance

🧪 LAB PRÁTICO (nível Bellacosa 😎)

🎯 Objetivo:

Comparar performance com tuning vs sem tuning


Cenário 1 (ruim)

  • KSDS
  • CI pequeno
  • Sem buffer tuning
  • Sem FREESPACE

Cenário 2 (otimizado)

  • KSDS
  • CI adequado
  • FREESPACE(20 10)
  • SMB + ACCBIAS
  • BUFND/BUFNI ajustado

🔍 Métrica:

  • EXCP count
  • Tempo de execução
  • SMF 64/42

💥 Resultado esperado:

👉 Redução de I/O de 30% a 80% (sim, acontece!)


🏁 Conclusão estilo Bellacosa

VSAM não é velho…
VSAM é mal compreendido.

Quando bem tunado:

💣 Ele compete com banco moderno
💣 Ele escala
💣 Ele é absurdamente eficiente