Translate

sábado, 18 de abril de 2026

⚠️ O Erro Silencioso em VSAM: Como Escolher KSDS vs ESDS vs RRDS Pode Derrubar Seu Sistema (Sem Você Perceber)

 

Bellacosa Mainframe erros silenciosos no VSAM e cabum no sistema

⚠️ O Erro Silencioso em VSAM: Como Escolher KSDS vs ESDS vs RRDS Pode Derrubar Seu Sistema (Sem Você Perceber)

🔥 KSDS vs ESDS vs RRDS — A visão que só aparece em produção

🧠 Primeiro: o erro clássico

Muita gente aprende assim:

  • KSDS = com chave
  • ESDS = sequencial
  • RRDS = relativo

👉 Isso é tecnicamente correto…
👉 Mas arquiteturalmente incompleto

A decisão real é:

Como o sistema acessa, cresce e evolui ao longo do tempo?


🟦 1. KSDS (Key-Sequenced Data Set) — O “DB2 simplificado”

💡 O que ele realmente é

Um KSDS é basicamente um índice + dados organizados por chave.

👉 Pense como:

  • “mini banco de dados”
  • com acesso direto via índice

📌 Quando ele brilha (vida real)

✔ Sistemas OLTP (CICS principalmente)
✔ Lookup online em alta frequência
✔ Dados vivos (update/delete constantes)


🏦 Exemplo real (CICS bancário)

Arquivo: ACCT-MASTER (KSDS)
Chave: ACCOUNT-NUMBER

CICS READ FILE('ACCT') RIDFLD(WS-ACC)

👉 Aqui não existe “loop”
👉 É acesso direto → milissegundos


⚙️ Internamente (ponto que poucos exploram)

  • CI (Control Interval)
  • CA (Control Area)
  • Índice B-tree

Quando você faz INSERT fora de ordem:

👉 💥 CI SPLIT
👉 💥 CA SPLIT


🚨 Problema clássico de produção

Sistema crescendo + inserts aleatórios:

  • aumento de I/O
  • fragmentação
  • queda de performance

🔧 Solução clássica

//REORG EXEC PGM=IDCAMS
//SYSIN DD *
REPRO INFILE(IN) OUTFILE(OUT)
/*

👉 Rebalanceia tudo
👉 Melhora locality de acesso


🧠 Insight avançado

Se você vê:

  • KSDS com 90% inserts sequenciais
    👉 talvez ESDS fosse melhor

🟨 2. ESDS (Entry-Sequenced Data Set) — O “log natural”

💡 O que ele realmente é

Um ESDS é:

“append-only storage com endereço físico (RBA)”


📌 Quando ele brilha

✔ Batch pesado
✔ Logs
✔ Trilhas de auditoria
✔ Streaming de eventos


🧾 Exemplo real

Arquivo: TRANS-LOG (ESDS)

WRITE REGISTRO
WRITE REGISTRO
WRITE REGISTRO

👉 Sempre no final
👉 Sem reorganização de chave


🚀 Por que ele é rápido?

  • Sem index
  • Sem split
  • Escrita linear

👉 É praticamente I/O sequencial puro


⚠️ Limitação crítica

Você não faz:

READ WHERE ID = X

👉 Você precisa:

  • RBA (posição física)
    ou
  • ler sequencialmente

🔥 Caso real (erro clássico)

Projeto usando KSDS para log:

  • CI split constante
  • alto consumo de CPU

👉 Troca para ESDS:

  • batch caiu de 2h → 40 min

🧠 Insight avançado

ESDS é perfeito para:

👉 event sourcing no mainframe

(sim, isso existe e funciona muito bem)


🟥 3. RRDS (Relative Record Data Set) — O “array do mainframe”

💡 O que ele realmente é

Um RRDS é:

“um vetor indexado por posição (RRN)”


📌 Quando ele brilha

✔ Tabelas fixas
✔ Configuração
✔ Lookup ultra rápido sem chave


🧾 Exemplo real

RRN 1 → Config geral
RRN 2 → Limites
RRN 3 → Parâmetros regionais

Código:

READ FILE RRDS-FILE
RECORD NUMBER IS WS-RRN

👉 Acesso direto
👉 Sem índice
👉 Sem busca


⚡ Performance

  • O(1) direto
  • extremamente previsível

⚠️ Problemas

❌ Espaço desperdiçado
❌ Não escala bem
❌ Difícil de evoluir


🔥 Caso real

RRDS com 10.000 slots
Uso real: 300

👉 97% vazio
👉 storage desperdiçado


🧠 Insight avançado

RRDS é ótimo quando:

👉 você quer comportamento determinístico (tipo tabela estática em memória)


⚖️ Comparação prática (nível arquiteto)

CritérioKSDSESDSRRDS
Acesso por chave
Acesso sequencial
Acesso diretovia RBAvia RRN
Insertmédio🔥 rápidofixo
Update⚠️ difícillimitado
Espaçoeficienteeficiente❌ pode desperdiçar
Complexidademédiabaixabaixa

🧠 Decisão real (mentalidade de produção)

✔ Use KSDS quando:

👉 O negócio fala em ID, chave, busca direta


✔ Use ESDS quando:

👉 O sistema fala em log, trilha, histórico, append


✔ Use RRDS quando:

👉 O sistema fala em posição fixa, tabela estática


🔥 O insight que separa júnior de sênior

VSAM não é sobre “tipo de arquivo”
É sobre padrão de acesso + comportamento do dado


🚨 Anti-patterns clássicos

❌ KSDS para log
❌ ESDS para lookup
❌ RRDS para dados dinâmicos


💥 Extra (nível especialista)

🔄 Combinações reais em sistemas grandes

  • KSDS → dados ativos
  • ESDS → histórico/log
  • RRDS → parâmetros

👉 Isso é MUITO comum em sistemas CICS/Batch

sexta-feira, 17 de abril de 2026

💥 Operador de CICS Não Aperta Botão: Ele Evita Caos em Milhões de Transações (E Quase Ninguém Percebe)

 

Bellacosa Mainframe descreve as atividade de um operador mainframe em CICS

💥 Operador de CICS Não Aperta Botão: Ele Evita Caos em Milhões de Transações (E Quase Ninguém Percebe)

Se você acha que o operador de mainframe só “fica olhando tela verde”… cuidado.
No universo do CICS, ele é o guardião silencioso que impede filas travadas, regiões colapsando e clientes reclamando no app do banco.

Hoje vamos abrir essa caixa-preta no estilo Bellacosa Mainframe: direto, provocativo e com aquele tempero de quem já viu CICS pegando fogo às 3 da manhã. ☕


🧠 O Papel REAL do Operador de CICS

O operador não programa… mas mantém o sistema RESPIRANDO.

Ele atua em três frentes:

🔹 1. Monitoramento contínuo

  • Região CICS ativa?
  • Transações fluindo?
  • CPU explodindo?
  • Tasks presas?

🔹 2. Intervenção rápida

  • Mata transação travada
  • Habilita/desabilita recursos
  • Responde incidentes antes do usuário perceber

🔹 3. Comunicação

  • Aciona suporte (sysprog, dev, DBA)
  • Documenta incidentes
  • Traduz problema técnico em impacto real

👉 Em resumo:
O operador não resolve tudo — mas sabe exatamente quando algo está errado.


⚙️ Comandos CICS que TODO operador deve dominar

Dentro do CICS (via terminal ou console), esses são os clássicos:

🔥 CEMT — O CANIVETE SUÍÇO

O mais importante. Se o operador souber só um… que seja esse.

Exemplos:

CEMT I TASK

→ Lista tasks ativas

CEMT I TRANS

→ Mostra transações

CEMT SET TRANS(xxxx) DISABLED

→ Desabilita transação problemática

CEMT SET FILE(nome) CLOSED

→ Fecha arquivo (VSAM/DB2 ligado)

CEMT SET TASK(xxxx) PURGE

→ Mata task travada

💡 Dica Bellacosa:
Se você usou PURGE mais de 3x no dia… tem problema estrutural.


🔥 CEDA — Definições (nível mais avançado)

CEDA I TRANS(xxxx)

→ Ver definição da transação

👉 Operador usa menos, mas precisa reconhecer.


🔥 CECS / CECI — Testes

Mais usados por dev, mas operador esperto sabe identificar uso indevido.


🖥️ Onde o SDSF entra no jogo?

Aqui começa o poder real.

O SDSF é o radar do operador.


🔍 Telas que ele MAIS usa:

🔹 ST (Status)

  • Ver address space do CICS
  • CPU, memória, status

👉 Identificar se o CICS está:

  • Loopando
  • Travado
  • Consumindo CPU absurda

🔹 DA (Display Active)

  • Tasks no z/OS
  • Ver impacto fora do CICS

🔹 LOG

  • Mensagens do sistema

👉 Aqui mora o OURO.

Exemplo:

  • AICA abends
  • DFHxxxx mensagens
  • Falhas de recurso

💡 Easter egg:
Se aparecer DFHAC2001 com frequência…
👉 Pode apostar: alguém esqueceu commit ou está em loop.


🔹 SP (Spool)

  • Logs de jobs
  • Dumps

🚨 Quando o CICS está “aberto” — o que se espera do operador?

CICS aberto = ambiente em produção, usuários ativos.

O operador precisa:

✅ 1. Garantir disponibilidade

  • Região UP
  • Transações habilitadas

✅ 2. Detectar anomalias

  • Lentidão
  • Travamentos
  • Picos

✅ 3. Agir ANTES do caos

  • Kill de tasks
  • Disable de transação problemática

✅ 4. Seguir procedimento

  • Nada de “inventar moda”
  • Produção NÃO é laboratório

🧨 Situações clássicas (vida real)

💣 Caso 1 — Loop infinito

Sintoma:

  • CPU 100%
  • Usuários travados

Ação:

CEMT I TASK
CEMT SET TASK(xxxx) PURGE

💣 Caso 2 — Arquivo travado

Sintoma:

  • Transações não respondem

Ação:

CEMT SET FILE(nome) CLOSED
CEMT SET FILE(nome) OPEN

💣 Caso 3 — Transação problemática

CEMT SET TRANS(xxxx) DISABLED

🕵️ Curiosidade raiz (história real de datacenter)

Um operador notou que o CICS estava “normal”…
Mas usuários reclamavam.

Ele fez algo simples:

CEMT I TASK

Percebeu centenas de tasks iguais.

👉 Era um bug em produção gerando loop silencioso.

Ele matou UMA task… e o problema sumiu.

💡 Moral:
Nem sempre o problema é barulhento.


🎯 Dicas nível Bellacosa (ouro puro)

🔥 Nunca saia dando PURGE sem entender
🔥 Sempre olhe o SDSF antes de agir
🔥 Aprenda a reconhecer padrões (isso separa operador de operador)
🔥 Documente TUDO
🔥 Conheça mensagens DFH (isso é superpoder)


🧩 Easter Egg técnico

Se você digitar:

CEMT I SYSTEM

Vai ver:

  • Status geral
  • Recursos
  • Saúde do CICS

👉 Pouca gente usa… mas deveria.


🚀 Conclusão

O operador de CICS não é figurante.
Ele é o primeiro firewall humano entre o sistema e o caos.

Enquanto desenvolvedores escrevem código…
👉 Ele garante que o sistema NÃO PARE.

E quando tudo está funcionando perfeitamente…










👉 Foi porque ele fez o trabalho certo — e ninguém percebeu.


quinta-feira, 16 de abril de 2026

💥 CICS Não é Legado: Como o CICS TS 6.3 Está Processando Milhões de Transações por Segundo (Enquanto o Mundo Ainda Subestima o Mainframe)

 

Bellacosa Mainframe apresenta o CICS TS versão 6.3

💥 CICS Não é Legado: Como o CICS TS 6.3 Está Processando Milhões de Transações por Segundo (Enquanto o Mundo Ainda Subestima o Mainframe)

🧠 CICS Transaction Server – visão geral atual

O produto que manda no jogo é o
👉 IBM CICS Transaction Server for z/OS

  • Middleware transacional de altíssimo volume
  • Base de praticamente todos os bancos, seguradoras e governos
  • Arquitetura cooperativa de multitarefa (quase um “mini-OS dentro do z/OS”)

🚀 Versão mais recente (estado da arte)

👉 Versão atual: CICS TS 6.3
👉 Data de GA: 05 de setembro de 2025

📌 Importante:

  • A linha 6.x segue modelo continuous delivery
  • Atualizações continuam saindo (inclusive em 2026)

🧬 Evolução recente (6.1 → 6.2 → 6.3)

🟢 CICS TS 6.1 (2022)

  • Base da nova geração
  • Foco:
    • APIs modernas
    • Cloud enablement
    • Melhor governança operacional

🟡 CICS TS 6.2 (2024)

  • Performance tuning pesado
  • Melhorias operacionais reais (não só dev)
  • Consolidação da documentação (6.x unificado)

💡 Destaque Bellacosa:

Aqui o CICS começou a “respirar DevOps de verdade”


🔵 CICS TS 6.3 (2025 – atual)

  • Foco forte em:
    • Observabilidade (OpenTelemetry)
    • Segurança
    • Automação operacional
    • Integração com APIs modernas

Exemplo prático:

  • Flush automático de dados de telemetria (SMF + observabilidade moderna)

🔐 Segurança evoluída

  • HSTS (HTTP Strict Transport Security)
  • Melhor visibilidade de login (tentativas, timestamps)

⚙️ Limites operacionais (o que ninguém te explica direito)

Agora vem o ouro 👇 (estilo Bellacosa raiz)

👥 Limite de usuários

👉 Não existe limite fixo definido pelo CICS

Depende de:

  • Região (QR TCB)
  • Storage (EDSAs / GDSA / RDSA)
  • Tuning de SIT

💡 Na prática:

  • Milhares de usuários simultâneos são comuns
  • Bancos operam com dezenas de milhares

🧵 Limite de tasks (TCLASS / MAXTASKS)

👉 Controlado por:

  • MXT (Max Tasks global da região)
  • TCLASS (limite por tipo de workload)

💥 Valores típicos:

  • MXT: 500 até 2000+ (ou mais em ambientes modernos)
  • Pode escalar dependendo de CPU e tuning

📌 Importante:

  • Cada transação = 1 TASK
  • CICS é cooperativo (não preemptivo)

🔁 Limite de transações por segundo (TPS)

👉 Não existe limite fixo no produto

Depende de:

  • CPU (MSU / MIPS)
  • I/O (VSAM / DB2 / MQ)
  • Locking
  • Design da aplicação

💥 Casos reais:

  • 10.000+ TPS → comum
  • 50.000+ TPS → ambientes financeiros pesados

🧠 Limite de memória (Storage)

Controlado por:

  • DSAs:
    • CDSA
    • EDSA
    • RDSA
  • 31-bit vs 64-bit storage

💡 Tendência moderna:
👉 mover tudo possível para 64-bit storage (above the bar)


🧬 Limite de regiões CICS

👉 Ilimitado na prática (depende do z/OS)

Arquiteturas modernas usam:

  • CICSPlex SM
  • TOR / AOR / FOR separation

🏗️ Arquitetura operacional (visão de campo)

🧩 Componentes chave

  • QR TCB → coração da região
  • Open TCBs → paralelismo real (DB2, MQ, Java)
  • Dispatcher CICS → controla multitarefa
  • Program Control (PC)
  • Task Control (TC)

🔄 Modelo de execução

  1. Terminal / API chama transação
  2. CICS cria TASK
  3. Dispatcher gerencia CPU
  4. TASK usa serviços:
    • VSAM
    • DB2
    • MQ
  5. Commit (syncpoint)

🔥 O que realmente mudou (visão prática)

Antes (CICS clássico)

  • 3270
  • COBOL puro
  • VSAM pesado
  • Transação síncrona

Agora (CICS moderno)

  • REST via z/OS Connect
  • APIs JSON
  • Observabilidade (OpenTelemetry)
  • Integração cloud
  • DevOps pipeline

💥 Em resumo:
👉 CICS virou Application Server corporativo de missão crítica


📊 Pontos fortes atuais

  • Escalabilidade absurda (vertical + horizontal)
  • Resiliência (quase zero downtime)
  • Integração híbrida (legacy + cloud)
  • Segurança nível bancário

⚠️ Gargalos reais (sem romantizar)

  • Aplicação mal escrita = gargalo (não o CICS)
  • Lock em VSAM/DB2
  • TASK segurando CPU (não liberando)
  • Storage mal dimensionado
  • Falta de paralelismo (Open TCB subutilizado)

🧠 Conclusão estilo Bellacosa

CICS hoje não é legado.

👉 É core digital escondido atrás de APIs modernas

E a versão 6.3 consolida isso:

  • Mais observável
  • Mais seguro
  • Mais integrado
  • Mais preparado para cloud






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