Bellacosa Mainframe comenta sobre cobol quebrando e a busca por culpados smp/e nos bastidores

🔥💀 “SEU COBOL NÃO QUEBROU… FOI O SMP/E QUE MEXEU NOS BASTIDORES”

O guia que todo dev COBOL deveria ler antes de culpar o programa

---

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

💣 “o programa rodava ontem… hoje ABENDOU… e ninguém mexeu em nada”

👉 Spoiler: alguém mexeu sim
👉 E provavelmente foi o SMP/E

---

🧠 A VERDADE QUE NINGUÉM TE CONTA

No mundo do mainframe, seu COBOL não vive sozinho.

Ele depende de:

• load modules
• bibliotecas
• runtime
• serviços do sistema

E tudo isso é controlado por um cara invisível:

💀 SMP/E — o gerente silencioso do ambiente

---

🕰️ UM POUCO DE HISTÓRIA (QUE EXPLICA TUDO)

Antes dos anos 80…

• sysprog fazia manutenção manual
• copiava módulos na mão
• sobrescrevia código sem controle

Resultado?

💣 ambiente inconsistente
💣 sistema instável
💣 caos

Então nasceu o SMP (depois SMP/E):

👉 pra trazer controle, rastreabilidade e sanidade

---

🔥 TRADUZINDO PRA VOCÊ, DEV COBOL

Pensa assim:

seu programa = ponta do iceberg
smp/e = quem controla o iceberg inteiro

---

⚙️ O QUE O SMP/E FAZ (NA VIDA REAL)

• instala produtos (CICS, DB2, z/OS)
• aplica correções (PTFs)
• atualiza módulos que você usa
• controla versões do ambiente

💡 Ou seja:

🔥 ele pode mudar seu runtime sem você tocar no código

---

💀 O FLUXO QUE DECIDE SEU DESTINO

receive → apply → accept

🧩 RECEIVE

👉 baixa a mudança
👉 não altera nada ainda

---

💥 APPLY

👉 altera o ambiente
👉 muda módulos que seu programa usa

💀 é aqui que seu COBOL pode “mudar de comportamento”

---

🏁 ACCEPT

👉 oficializa a mudança
👉 vira baseline

---

⚠️ EASTER EGG (VIDA REAL)

💣 “ninguém mexeu no programa”
👉 mas alguém fez APPLY ontem à noite

---

🧱 TARGET vs DLIB (A CHAVE DO UNIVERSO)

👉 Isso aqui explica MUITA coisa:

Tipo	O que é
TARGET	o que roda
DLIB	base confiável

---

💡 Cenário clássico:

• APPLY alterou TARGET
• seu programa usa nova versão
• comportamento mudou

👉 você nem viu acontecer

---

♻️ RESTORE — O HERÓI ESQUECIDO

Quando dá ruim:

👉 SMP/E pode restaurar versão da DLIB

restore = desfazer desastre

💡 Sim… dá pra “voltar no tempo”

---

🧠 CSI — O CÉREBRO DO SISTEMA

SMP/E não trabalha no escuro.

Ele mantém um banco chamado:

🔥 CSI (Consolidated Software Inventory)

Ali ele sabe:

• o que está instalado
• versões
• dependências
• histórico

---

💀 Sem CSI consistente:

você não tem ambiente… tem uma bomba relógio

---

📦 SYSMOD — O PACOTE QUE MUDA TUDO

Tudo que entra no sistema vem assim:

👉 SYSMOD

Tipos:

• PTF → correção
• APAR → problema corrigido
• FUNCTION → nova funcionalidade
• USERMOD → customização

---

💡 Curiosidade:

USERMOD mal feito = pesadelo eterno 😄

---

🧠 MCS — A LINGUAGEM SECRETA

Dentro do SYSMOD existe:

++ alguma coisa

Isso são MCS (instructions)

Exemplo:

++VER
++MOD
++HOLD

---

💡 Tradução:

SMP/E não “decide”… ele executa ordens do SYSMOD

---

💣 DEPENDÊNCIAS (ONDE O BICHO PEGA)

Tipos:

• PRE → precisa antes
• REQ → precisa junto
• SUP → substitui

---

💥 Se faltar dependência:

APPLY FAILED

👉 e o sysprog entra em guerra

---

🧬 TRACKING — O NÍVEL NINJA

SMP/E sabe exatamente o nível de cada módulo:

FMID = origem
RMID = última substituição
UMID = updates

---

💡 Isso permite:

• saber versão real
• evitar conflito
• diagnosticar erro

---

⚠️ EASTER EGG DE PRODUÇÃO

💣 “o bug apareceu do nada”

👉 não apareceu

👉 o RMID mudou 😄

---

🧠 VISÃO DE GUERRA (PRA DEV COBOL)

Se você entender SMP/E:

✅ você para de culpar o programa
✅ entende mudanças de ambiente
✅ conversa melhor com sysprog
✅ vira profissional diferenciado

---

🔥 UMA GRANDE VERDADE

💀 COBOL quebra raramente
💀 ambiente quebra frequentemente

---

🍛 A PENSAR NA HORA DO ALMOÇO

👉 Quantos erros você já debugou…

…que na verdade eram:

• mudança de load module
• alteração de runtime
• PTF aplicada

---

🧪 MÃO NA MASSA (MENTALIDADE)

Próxima vez que algo quebrar:

❌ não pergunte:

“quem mudou o programa?”

✅ pergunte:

“teve APPLY recente?”

---

🚀 FRASE FINAL (ESTILO BELLACOSA)

🔥 “Seu programa não mudou…
o mundo ao redor dele mudou.”

Bellacosa Mainframe apresenta COBOL LE Enterprise

🚀 Do COPY ao CORE Bancário: A Jornada Jedi de um Programa COBOL no z/OS (ou: como um .CBL vira dinheiro no mundo real)

“Padawan, muitos escrevem código. Poucos entendem como ele realmente vive.” 💙

Se você acha que COBOL é só um DISPLAY "HELLO", prepare-se.
No mainframe, um programa não nasce pronto — ele passa por uma verdadeira linha de produção industrial de software.

Hoje vamos percorrer essa jornada completa, estilo Bellacosa Mainframe™, com:

🔥 Passo a passo real
🧠 Conceitos que diferenciam dev júnior de arquiteto
💎 Easter eggs históricos
🏦 Exemplos do mundo bancário
⚙️ Bastidores que ninguém te conta

---

🧙‍♂️ Capítulo 1 — O nascimento: o código fonte

Tudo começa com um membro em um PDS ou PDSE:

USER.COBOL.SOURCE(PROG1)

Exemplo simples:

IDENTIFICATION DIVISION.
PROGRAM-ID. CPRIME.

PROCEDURE DIVISION.
    DISPLAY "MAY THE MAINFRAME BE WITH YOU".
    STOP RUN.

💡 Curiosidade Jedi:
COBOL foi criado para ser legível por pessoas de negócio. Por isso parece “verbal”.

---

📚 Capítulo 2 — COPY: os pergaminhos antigos

Nenhum sistema corporativo vive sem COPYBOOKS.

COPY CLIENT-RECORD.

Esses artefatos ficam nas bibliotecas apontadas por:

//SYSLIB DD DSN=CORP.COPYLIB

💎 Easter egg:
Grandes bancos têm copybooks mais antigos que muitos desenvolvedores.

---

⚙️ Capítulo 3 — Compilação: o forno industrial (IGYCRCTL)

Agora entra o compilador Enterprise COBOL.

//COMPILE EXEC PGM=IGYCRCTL

📥 Entradas principais

DD	Função
SYSIN	Código fonte
SYSLIB	Copybooks
SYSUTx	Área de trabalho

📤 Saídas

DD	Resultado
SYSPRINT	Mensagens
SYSLIN	Object code

👉 O objeto ainda NÃO é executável.

---

🧠 Analogia moderna

Mainframe	Linux
Compile	gcc -c
Objeto	.o

---

💥 Capítulo 4 — O Binder: alquimia digital (IEWL)

Agora o objeto vira programa executável.

//LKED EXEC PGM=IEWL

📥 Entrada

SYSLIN → objeto compilado

📤 Saída

SYSLMOD → executável final

💎 Easter egg:
Antes do Binder moderno, isso se chamava “link-edit”.

---

📦 Program Object: o formato moderno

Hoje o resultado normalmente é um:

👉 Program Object em PDSE

Não mais um load module antigo.

---

🧬 Capítulo 5 — O espírito invisível: Language Environment (LE)

Aqui está o segredo que separa aprendizes de mestres.

💥 Programas COBOL não rodam sozinhos.

Eles precisam do LE.

O LE fornece:

✔️ Memória
✔️ Inicialização
✔️ Tratamento de erros
✔️ Serviços runtime
✔️ Interoperabilidade

---

🧠 Analogia suprema

Plataforma	Runtime
Java	JVM
.NET	CLR
z/OS	⭐ LE

---

⚙️ Capítulo 6 — Opções de runtime (CEEOPTS)

Exemplo famoso:

ALL31(ON)

Permite usar memória acima da linha de 16 MB.

🧪 Override via JCL

//CEEOPTS DD *
ALL31(ON)
/*

🚫 Nunca no código COBOL.

---

🏦 Capítulo 7 — Onde o programa pode rodar?

Um único executável pode viver em vários mundos:

Ambiente	Uso típico
Batch	Processamento massivo
CICS	Transações online
IMS	Sistemas críticos
Db2 SP	Lógica no banco
TSO	Execução interativa
USS	Scripts UNIX

❌ System exit — proibido (sem LE)

---

🐧 Capítulo 8 — USS e o mundo moderno

Você também pode compilar no UNIX do z/OS:

cob2 -q'RENT,LIST' pgm1.cbl

💡 O mainframe também fala “Linux”.

---

🧩 Capítulo 9 — Compatibilidade histórica (o verdadeiro poder)

Enterprise COBOL consegue recompilar código:

✔️ VS COBOL II (anos 80)
✔️ COBOL for OS/390

Mas não diretamente:

❌ OS/VS COBOL
❌ COBOL-68 / COBOL-74

💥 Isso é o que mantém sistemas funcionando por décadas.

---

🧙‍♂️ Capítulo 10 — A verdadeira força do mainframe

Um programa COBOL pode:

💥 Processar milhões de transações por segundo
💥 Rodar por décadas sem reescrita
💥 Integrar com APIs modernas
💥 Conviver com código de 40 anos atrás

---

🏆 Pipeline final — a jornada completa

Source (.CBL)
   ↓
Compile (IGYCRCTL)
   ↓
Object module
   ↓
Binder (IEWL)
   ↓
Program Object
   ↓
Execution (Batch / CICS / IMS / etc.)

---

💎 Easter egg final

💰 Grande parte do dinheiro do planeta passa por sistemas exatamente assim.

Cada saque, compra com cartão ou transferência:

👉 Pode estar executando código COBOL semelhante ao seu.

---

🧠 Conclusão 

Padawan, aprender COBOL não é aprender uma linguagem.

É entender uma arquitetura de computação empresarial completa, refinada por mais de meio século.

🚀 O código é apenas o começo.
🏗️ O processo é o verdadeiro poder.
💙 O mainframe é a fábrica invisível do mundo moderno.

 

Bellacosa Mainframe e o teste de cobol para padawan

☕ O Dia em que um Padawan COBOL Enfrentou o Teste Avançado… e Descobriu os Segredos do Mainframe

“Muito antes de microservices, Kubernetes e modinhas passageiras, havia tabelas OCCURS, SORTs colossais e programas que movem bilhões… silenciosamente.”

Se você é um Padawan do COBOL, prepare seu café ☕ — hoje vamos atravessar uma jornada digna de Jedi Mainframe.

Este artigo é inspirado em um cenário real: um teste avançado de COBOL cobrindo tabelas, SORT, subprogramas, comunicação interprogramas e OO COBOL.

E sim… isso é exatamente o que sustenta bancos, seguradoras e governos.

---

🧠 Capítulo 1 — A Força das Tabelas OCCURS

Todo Padawan descobre cedo que:

COBOL não tem “arrays”… tem tabelas.

Exemplo clássico:

01 Salary-Table.
   02 Salary PIC 9(4) OCCURS 100 TIMES.

Para zerar a tabela:

MOVE 1 TO Counter
PERFORM UNTIL Counter > 100
   MOVE 0 TO Salary(Counter)
   ADD 1 TO Counter
END-PERFORM

🧩 Easter Egg #1 — O jeito Jedi

Um Mestre COBOL faria:

INITIALIZE Salary-Table

💥 Mesma coisa. Menos CPU. Mais elegância.

---

🏥 Capítulo 2 — Tabelas Multinível: O Labirinto dos Índices

Considere:

01 Patient-Table.
   02 Ward OCCURS 10 TIMES.
      03 Patient OCCURS 120 TIMES.
         04 Patient-Name PIC X(50).

Para acessar:

Patient-Name(ward-index, patient-index)

👉 Ordem: de fora para dentro

⚠️ Pegadinha mortal

Se errar a ordem ou quantidade de subscritos:

💥 Pode sobrescrever memória
💥 Pode causar S0C4
💥 Pode derrubar um batch inteiro às 3h da manhã

---

⚡ Capítulo 3 — Índices vs Subscripts: Velocidade da Luz

Padawans usam:

Salary(5)

Mestres usam:

SET idx TO 5
Salary(idx)

Porque:

Característica	Subscript	Index
Tipo	Número	Offset
Performance	Média	Alta
Uso em SEARCH ALL	❌	✅

🧩 Easter Egg #2

Índices não podem receber MOVE:

MOVE 1 TO idx   *> ERRO
SET idx TO 1    *> CORRETO

---

🔍 Capítulo 4 — SEARCH vs SEARCH ALL

🐢 SEARCH (sequencial)

Procura um a um.

🚀 SEARCH ALL (binário)

Divide ao meio repetidamente.

Mas exige:

✔️ Tabela ordenada
✔️ Índice
✔️ Chave correta

Exemplo:

SEARCH ALL Stock
   WHEN Stock-Symbol(idx) = "IBM"
      PERFORM Found
END-SEARCH

🧩 Curiosidade histórica

Em grandes bancos:

SEARCH ALL pode reduzir milhões de comparações para poucas dezenas.

---

🔄 Capítulo 5 — SORT: O Motor Invisível do Batch

O SORT interno envolve três arquivos:

1️⃣ Entrada
2️⃣ Work file (SD)
3️⃣ Saída

SORT Sort-Work
   ON ASCENDING KEY Customer-ID
   USING Input-File
   GIVING Output-File

🔥 Regra de ouro

O Sort Work File:

❌ Não é aberto
❌ Não é fechado
❌ Não é manipulado diretamente

👉 O sistema cuida disso.

---

🧪 Capítulo 6 — INPUT/OUTPUT PROCEDURE: Magia Avançada

Sem USING/GIVING, você controla tudo:

Entrada → RELEASE

RELEASE Sort-Record

Saída → RETURN

RETURN Sort-Work

💡 Isso permite filtrar, transformar ou gerar dados durante o SORT.

---

🧩 Capítulo 7 — Subprogramas: Modularidade Jedi

Chamador:

CALL "PROCESS-1" USING parm-area

Subprograma:

LINKAGE SECTION.
01 parm-area PIC X(100).

PROCEDURE DIVISION USING parm-area.

🔥 Regra importante

Por padrão:

👉 Parâmetros são BY REFERENCE
👉 Alterações retornam ao chamador

---

🌐 Capítulo 8 — Comunicação entre Programas

Tipos de dados compartilhados:

Tipo	Escopo
GLOBAL	Programa + subprogramas embedded
EXTERNAL	Todo o run unit
LOCAL	Apenas o programa

🧩 Easter Egg #3

EXTERNAL é como memória compartilhada “secreta” entre módulos.

Usar demais = pesadelo de manutenção.

---

🧬 Capítulo 9 — OO COBOL: O Lado Moderno da Força

Sim, COBOL também tem:

✔️ Classes
✔️ Objetos
✔️ Herança
✔️ Métodos
✔️ Factory

Exemplo simplificado:

CLASS-ID. Account.

FACTORY.
WORKING-STORAGE SECTION.
01 Interest PIC 9V99.

OBJECT.
WORKING-STORAGE SECTION.
01 Balance PIC 9(7)V99.

🔥 Diferença crucial

Seção	Papel
FACTORY	Nível classe (static)
OBJECT	Nível instância

---

⚔️ Capítulo 10 — INVOKE vs CALL

Padawan erra:

CALL obj "method"

Mestre usa:

INVOKE obj "method"

👉 CALL → programas
👉 INVOKE → métodos OO

---

☕ Epílogo — O Verdadeiro Poder do COBOL

Após atravessar tabelas, SORTs, subprogramas e OO…

O Padawan percebe:

COBOL não é antigo.
COBOL é maduro.

Ele roda onde:

💰 O dinheiro circula
🏦 As transações acontecem
🌍 O mundo confia

---

🧠 Curiosidade Final (Easter Egg Supremo)

Estima-se que:

Mais de 70% das transações financeiras globais ainda passam por sistemas COBOL.

Enquanto você lia este artigo…

Provavelmente bilhões foram movimentados por código parecido com os exemplos acima.

---

🚀 Se você chegou até aqui…

Você já não é apenas um Padawan.

Está iniciando o caminho para:

🥋 Mestre do Mainframe

 

Bellacosa Mainframe explica smp/e para padawans

🔥💀 DÚVIDAS FREQUENTES SOBRE SMP/E

“o que todo mundo já errou… mas não admite”

---

🧠 1. SMP/E é só para sysprog?

👉 Resposta curta: SIM (na prática)

👉 Resposta real:

• Dev COBOL não usa direto
• Mas é impactado o tempo todo

💡 Se você é dev e entende SMP/E:

você para de sofrer debug desnecessário

---

⚙️ 2. Qual a diferença entre RECEIVE, APPLY e ACCEPT?

👉 Clássico:

RECEIVE → carrega
APPLY   → instala (TARGET)
ACCEPT  → oficializa (DLIB)

💥 Dica:

APPLY muda o ambiente
ACCEPT muda o futuro

---

💀 3. Posso dar APPLY direto em produção?

👉 Pode…

👉 Mas também pode:

• quebrar sistema
• gerar incidente
• trabalhar de madrugada 😄

💡 Regra:

sempre APPLY CHECK + ambiente clone

---

🔁 4. O que faz o RESTORE?

👉 Volta para versão anterior usando DLIB

💡 Tradução:

botão “desfazer desastre”

---

🧩 5. O que é SYSMOD?

👉 Tudo que entra no SMP/E

Tipos:

• PTF → correção
• APAR → bug
• FUNCTION → produto
• USERMOD → custom

---

🧠 6. O que é CSI?

👉 Banco de dados do SMP/E

Guarda:

• o que está instalado
• histórico
• dependências

💀 Sem CSI:

você está cego

---

🧬 7. O que são FMID, RMID e UMID?

👉 Controle de versão real:

• FMID → origem
• RMID → última substituição
• UMID → updates

💡 SMP/E sabe mais do sistema do que você 😄

---

⚠️ 8. O que é HOLDDATA?

👉 Bloqueio de instalação

Tipos:

• ERROR
• SYSTEM
• USER

💥 Ignorar HOLD:

pedir problema

---

🔗 9. Por que o APPLY falha?

👉 90% dos casos:

• dependência (PRE/REQ)
• HOLDDATA
• zone errada
• FMID incorreto

---

🧠 10. O que é ++VER?

👉 A linha mais importante do SYSMOD

Define:

• onde instalar
• dependências
• compatibilidade

💡 Se der erro:

começa por aqui

---

🏗️ 11. O que é JCLIN?

👉 “manual de montagem” do load module

💡 Não executa… mas ensina o SMP/E

---

📦 12. Onde o SMP/E roda?

👉 Dentro do z/OS

Interfaces:

• ISPF (tela)
• JCL (produção)

❌ não é HMC

---

⚙️ 13. SMP/E automatiza manutenção?

👉 Sim (e deveria)

Com:

• REXX
• RECEIVE ORDER
• scripts

---

💣 14. Por que meu COBOL mudou comportamento?

👉 Possíveis causas:

• novo PTF
• alteração de load module
• mudança no runtime

💀 não foi seu código

---

🧠 15. Como evitar problemas com SMP/E?

👉 Checklist:

✔ APPLY CHECK
✔ validar dependências
✔ analisar HOLDDATA
✔ testar em clone
✔ só depois produção

---

🔥 BÔNUS — VERDADE FINAL

💀 “o erro raramente está no COBOL…
está no que mudou ao redor dele”

 

 

Bellacosa Mainframe em uma missao possivel troubleshooting smp/e

🔥💀 TROUBLESHOOTING SMP/E PARA PADAWAN

“Quando o APPLY falha… começa o seu treinamento”

---

🧠 REGRA Nº1 (GRAVA ISSO)

💣 SMP/E NÃO ERRA
💣 ELE TE AVISA — VOCÊ NÃO ENTENDEU A MENSAGEM

---

🔍 1. ONDE OLHAR PRIMEIRO?

Quando algo falhar:

👉 NÃO OLHE O JCL PRIMEIRO

Olhe:

• 📄 SMPLOG
• 📄 SMPOUT

💡 ali está a verdade

---

⚠️ 2. ERRO MAIS COMUM — DEPENDÊNCIA

💥 Sintoma:

GIM35901E APPLY PROCESSING FAILED

👉 Causa:

• faltou PRE
• faltou REQ

---

🔥 Como resolver:

👉 use:

APPLY CHECK

👉 ou:

LIST SYSMODS

💡 descubra o que está faltando

---

🧩 3. HOLD DATA (PEGADINHA CLÁSSICA)

💥 Sintoma:

SYSMOD HELD

👉 Tradução:

“não instala isso ainda, jovem padawan”

---

🔥 Solução:

• verificar HOLDDATA
• ou usar (com cuidado 😈):

BYPASS(HOLDERR,HOLDSYS)

💡 nunca faça isso sem saber o impacto

---

💀 4. ZONE ERRADA (ERRO DE INICIANTE)

💥 Sintoma:

• nada acontece
• ou erro estranho

👉 Causa:

SET BDY errado

---

🔥 Correto:

GLOBAL → RECEIVE
TARGET → APPLY
DLIB   → ACCEPT

---

🧨 5. CSI INCONSISTENTE

💥 Sintoma:

• erro sem sentido
• comportamento estranho

👉 Causa:

• CSI fora de sincronia

---

🔥 Solução:

• revisar zones
• rodar REPORT
• validar histórico

---

⚙️ 6. ELEMENTO NÃO ENCONTRADO

💥 Sintoma:

ELEMENT NOT FOUND

👉 Causa:

• FMID errado
• elemento não pertence àquela zone

---

🔥 Solução:

👉 verificar:

++VER FMID(...)

---

🔁 7. QUANDO TUDO DER ERRADO

👉 use o poder supremo:

RESTORE

💥 volta versão estável da DLIB

---

🧠 CHECKLIST DE SOBREVIVÊNCIA

Antes de APPLY:

✔ RECEIVE ok
✔ APPLY CHECK rodado
✔ dependências resolvidas
✔ HOLDDATA analisado
✔ zone correta

---

⚠️ EASTER EGG (REALIDADE)

💣 “funcionava ontem”

👉 ontem não tinha APPLY 😄

---

🧠 DICA DE OURO

Sempre pergunte:

teve mudança de smp/e?

antes de:

debugar cobol

---

🔥 FRASE FINAL

💀 “o erro não está no código…
está no nível do sistema”