Translate

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

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.

Se quiser, posso aprofundar com:

  • 📦 Um PTF real (anonimizado) e análise linha a linha do MCS
  • 🔍 Diferenças entre APPLY, ACCEPT e RESTORE
  • ⚠️ Como HOLDs afetam APPLY
  • 🧨 Erros comuns ao aplicar PTFs (com mensagens SMP/E reais)

É só falar!

crie um exemplo de mcs do cobol le

Excelente — vamos construir 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