☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta dev cobol. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta dev cobol. Mostrar todas as mensagens

segunda-feira, 6 de julho de 2026

No COBOL e no Futebol : A Distância Entre a Besta e o Bestial é Mínima

 

Bellacosa Mainframe a distancia entre a besta e o bestial é minima

☕ Um Café no Bellacosa Mainframe

A Distância Entre a Besta e o Bestial é Mínima

O Que Todo Programador COBOL Padawan Precisa Saber Sobre Futebol, Carreira, Derrotas, Excelência e Como Não Repetir os Erros da Seleção Brasileira

Existe uma frase que sempre gostei:

A distância entre a besta e o bestial é mínima.

Ela vale para o futebol.

Vale para o mercado financeiro.

Vale para IBM Z.

Vale para COBOL.

Vale para qualquer profissão onde a excelência é construída durante anos e pode desaparecer em apenas alguns minutos.

A derrota da Seleção Brasileira em uma Copa do Mundo costuma gerar um fenômeno curioso. Durante meses ou anos, jogadores são tratados como gênios absolutos. São vendidos por centenas de milhões. Ganham Champions League, Libertadores, Bola de Ouro, títulos nacionais, reconhecimento mundial.

Então chega um único jogo.

Noventa minutos.

Uma eliminação.

E, de repente...

"Não prestam."

"São superestimados."

"Nunca decidiram."

Mas será mesmo?

A resposta é não.

E exatamente aqui existe uma enorme lição para quem trabalha com tecnologia.



Bellacosa Mainframe glorias passadas nao entram em campo

O currículo não entra em campo

Imagine um desenvolvedor COBOL.

Vinte anos de carreira.

Milhares de programas escritos.

Centenas de milhões de transações processadas diariamente.

Zero incidentes graves.

Então...

Em uma madrugada...

Um JOB falha.

Uma alteração gera um ABEND.

O banco fica indisponível.

O cliente vê apenas aquele momento.

Ninguém lembra dos vinte anos anteriores.

O mercado funciona exatamente assim.

Você vale muito...

...até cometer um erro enorme.

Isso parece cruel.

Mas também ensina algo extremamente importante:

Reputação demora décadas para ser construída e segundos para ser questionada.


O futebol não perdoa.

A tecnologia também não.

Grandes craques encerraram a carreira sem conquistar o maior título do futebol.

Zico.

Cruyff.

Puskás.

Di Stéfano.

George Best.

E tantos outros.

Eles deixaram de ser gênios?

Claro que não.

O problema é que o mundo costuma resumir carreiras complexas em um único indicador.

No futebol:

"Copa do Mundo."

Na tecnologia:

"Conhece Cloud?"

"Sabe IA?"

"Tem Kubernetes?"

"Programa em Python?"

Como se décadas de experiência desaparecessem por causa da moda do momento.

Não desaparecem.

Mas também não bastam.


O maior erro da Seleção

Quando analisamos diversas eliminações brasileiras ao longo dos anos, aparece um padrão.

Não foi falta de talento.

Nunca foi.

Talento sempre existiu.

O problema quase sempre esteve em outros fatores.

Planejamento.

Organização.

Adaptação.

Controle emocional.

Leitura do adversário.

Tomada de decisão.

Humildade.

Tudo aquilo que também diferencia um excelente profissional de um profissional apenas talentoso.


COBOL também possui "seleções brasileiras"

Você provavelmente conhece alguém assim.

Sabe tudo de COBOL.

Tudo de JCL.

Tudo de CICS.

Tudo de Db2.

Resolve qualquer dump.

Mas...

Não sabe explicar uma solução.

Não documenta.

Não compartilha conhecimento.

Não conversa com outras equipes.

Não aprende novas tecnologias.

Não entende APIs.

Não conhece Git.

Nunca abriu um VS Code.

Nunca estudou IA.

Nunca aprendeu OpenTelemetry.

Nunca ouviu falar de MCP.

Resultado?

Continua sendo excelente...

...mas apenas dentro de um pequeno espaço.

Enquanto isso, outro profissional talvez saiba menos COBOL.

Muito menos.

Mas entende arquitetura.

Comunicação.

Negócio.

Cloud.

Integração.

Observabilidade.

Automação.

Esse segundo profissional acaba crescendo mais rápido.

Não porque programa melhor.

Mas porque resolve problemas maiores.


O ego derrota muito mais carreiras que a falta de conhecimento

No futebol existe uma frase antiga.

"Time ganha campeonato."

Não estrelas.

No Mainframe isso é ainda mais verdadeiro.

Nenhum sistema bancário sobrevive graças a um único programador.

Existe uma enorme equipe.

Arquitetos.

DBAs.

Operadores.

Analistas.

Segurança.

Infraestrutura.

Storage.

Redes.

Middleware.

Desenvolvimento.

Negócio.

Quando alguém acredita ser indispensável...

Começa sua decadência.


A tecnologia muda o campo

Imagine um craque dos anos 1980 jogando exatamente da mesma maneira hoje.

Provavelmente sofreria.

Não porque ficou ruim.

Mas porque o jogo mudou.

Com COBOL acontece exatamente isso.

Programar COBOL em 2026 não é o mesmo que programar em 1996.

Hoje existe:

  • APIs REST

  • JSON

  • XML

  • Git

  • DevOps

  • CI/CD

  • IA Generativa

  • RAG

  • MCP

  • OpenTelemetry

  • Kafka

  • IBM MQ

  • z/OS Connect

  • Containers

  • VS Code

  • Zowe

  • GitHub Copilot

Quem ignora isso...

Está treinando para um campeonato que já terminou.


O maior adversário nunca foi o concorrente

Sempre fomos nós mesmos.

A seleção brasileira muitas vezes entrou acreditando que venceria apenas pela camisa.

Na tecnologia acontece igual.

"Tenho trinta anos de COBOL."

Ótimo.

E agora?

O mercado pergunta outra coisa.

"O que você aprendeu este ano?"

Essa pergunta separa veteranos relevantes de veteranos nostálgicos.


O verdadeiro craque nunca para de treinar

Cristiano Ronaldo continua treinando.

Messi continua treinando.

LeBron continua treinando.

Djokovic continua treinando.

Nenhum deles diz:

"Já sei tudo."

Então por que um desenvolvedor faria isso?


A derrota também ensina

Existe uma enorme diferença entre fracassar...

...e desperdiçar um fracasso.

Toda derrota entrega dados.

Toda falha produz métricas.

Todo incidente ensina.

Todo ABEND conta uma história.

O problema é quando o profissional apenas procura culpados.

Os melhores fazem outra pergunta.

"O que esse erro está tentando me ensinar?"

Essa pergunta muda completamente uma carreira.


O profissional bestial

Existe um momento em que o conhecimento deixa de ser apenas técnico.

O profissional passa a enxergar padrões.

Antes resolvia problemas.

Agora evita que eles aconteçam.

Antes corrigia JOBs.

Agora melhora processos.

Antes escrevia código.

Agora desenha arquitetura.

Antes respondia chamados.

Agora elimina categorias inteiras de chamados.

Esse é o salto.

Não é escrever mais linhas.

É produzir menos problemas.


A distância entre besta e bestial

Ela realmente é mínima.

A diferença normalmente está em pequenas decisões repetidas durante anos.

Ler um capítulo por dia.

Fazer um laboratório por semana.

Estudar inglês.

Escrever artigos.

Compartilhar conhecimento.

Documentar soluções.

Participar de comunidades.

Ensinar iniciantes.

Aceitar críticas.

Aprender algo novo todos os meses.

Parece pouco.

Mas multiplique isso por dez anos.

Você terá duas pessoas completamente diferentes.


Como não repetir os erros da Seleção

Se eu pudesse deixar alguns conselhos para um COBOL Padawan, seriam estes.

Nunca confie apenas no talento.

Talento sem disciplina desaparece.

Nunca pare de estudar.

Seu maior concorrente talvez ainda esteja na faculdade.

Aprenda negócios.

Programas existem para resolver problemas de empresas.

Quem entende o negócio sempre entrega mais valor.

Aprenda comunicação.

Grandes carreiras raramente são construídas apenas digitando código.

Domine o legado.

Mas converse com o futuro.

COBOL continuará importante.

Mas ele faz parte de um ecossistema muito maior.

Documente tudo.

Sua memória falha.

A documentação permanece.

Automatize tarefas repetitivas.

Tempo economizado vira tempo de aprendizado.

Ensine.

Quem ensina aprende duas vezes.

Aceite feedback.

Orgulho custa caro.

Humildade rende dividendos durante décadas.


O próximo campeonato já começou

Enquanto muitos discutem apenas o último resultado...

Os campeões já estão treinando para o próximo.

No mercado de tecnologia acontece exatamente isso.

Enquanto alguns reclamam da IA...

Outros aprendem a utilizá-la.

Enquanto alguns dizem que COBOL morreu...

Outros integram COBOL com modelos de linguagem.

Enquanto alguns criticam APIs...

Outros conectam sistemas escritos há cinquenta anos com aplicações modernas.

Enquanto alguns vivem do passado...

Outros constroem o futuro.


O verdadeiro título

Talvez você nunca seja o programador mais famoso.

Talvez nunca apareça em uma conferência internacional.

Talvez nunca escreva um livro.

Talvez nunca ganhe um prêmio.

E tudo bem.

Seu verdadeiro título pode ser outro.

Ser aquele profissional em quem todos confiam.

Aquele que mantém milhões de brasileiros utilizando bancos, cartões, seguros, hospitais e serviços públicos sem sequer imaginar que existe um IBM Z trabalhando silenciosamente nos bastidores.

Existe uma enorme beleza nisso.

Porque os melhores sistemas são exatamente aqueles que ninguém percebe que estão funcionando.


Um café antes do apito final

No futebol, um detalhe muda uma Copa.

Na tecnologia, um detalhe muda uma carreira.

A diferença entre a "besta" e o "bestial" raramente está no QI, na faculdade ou no talento nato. Ela está na disciplina silenciosa de quem decide melhorar 1% todos os dias.

Não transforme uma derrota em sentença. Transforme-a em combustível.

Não permita que um sucesso vire acomodação. Faça dele apenas o ponto de partida para o próximo desafio.

A Seleção Brasileira ainda voltará a disputar Copas. Alguns jogadores conquistarão títulos, outros encerrarão a carreira sem levantar a taça mais importante do mundo. Isso faz parte do esporte.

Da mesma forma, você terá projetos brilhantes e projetos difíceis. Terá noites resolvendo ABENDs, incidentes e integrações improváveis. Terá momentos em que será reconhecido e outros em que seu trabalho passará despercebido.

Continue evoluindo.

Continue curioso.

Continue humilde.

Porque, no fim das contas, o mercado não procura apenas quem sabe COBOL.

Procura profissionais capazes de aprender, adaptar-se, colaborar e construir o futuro sem esquecer as lições do passado.

E talvez essa seja a maior definição de excelência.

Não vencer sempre.

Mas nunca parar de evoluir.

Nos encontramos no próximo café.


PS: Não foi de virada a Noruega dominou o tempo todo o jogo, mas com licensa poetica, fica essa errata, somente nos ultimos minutos o Neymar diminuiu o marcador. Vamos ver quantos vão notar e comentar.



segunda-feira, 6 de abril de 2026

💀🔥 SEU COBOL NÃO QUEBROU… FOI O SMP/E QUE REESCREVEU O MUNDO AO REDOR

 

Bellacosa Mainframe falando sobre SMP/E 

💀🔥 “SEU COBOL NÃO QUEBROU… FOI O SMP/E QUE REESCREVEU O MUNDO AO REDOR”

O guia que todo dev sênior precisa ler antes de culpar o programa


Você já viveu isso:

💣 “rodava ontem… hoje ABENDOU… ninguém mexeu no código”

👉 Então deixa eu te contar a verdade que poucos falam no mainframe:

💀 o código raramente muda… o ambiente muda o tempo todo

E quem controla isso?

🔥 SMP/E — System Modification Program / Extended


🕰️ UM POUCO DE HISTÓRIA (POR QUE ISSO EXISTE)

Antes do SMP/E:

  • sysprog copiava módulo na mão
  • sobrescrevia biblioteca sem controle
  • não existia rastreabilidade

Resultado?

💣 ambiente inconsistente
💣 bugs “fantasmas”
💣 caos operacional

O SMP nasceu pra resolver isso… e evoluiu para o SMP/E:

👉 controle
👉 consistência
👉 governança


🧠 SMP/E NA PRÁTICA (SEM ROMANTIZAR)

Pensa assim:

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

Ele decide:

  • qual versão roda
  • quais dependências são válidas
  • o que entra no sistema
  • o que quebra silenciosamente

🔠 ACRÔNIMOS (TRADUÇÃO DE VERDADE)

🔥 SMP/E

👉 System Modification Program / Extended
👉 gerenciador de instalação e manutenção


📦 SYSMOD

👉 pacote de mudança

Tipos:

  • FUNCTION → instala produto
  • PTF → correção oficial
  • APAR → problema reportado
  • USERMOD → customização local

💣 Easter egg:

USERMOD mal feito vira dívida técnica eterna


🧬 CSI

👉 Consolidated Software Inventory

👉 banco VSAM onde tudo é registrado:

  • versões
  • dependências
  • histórico

💀 sem CSI consistente:

você não tem ambiente… tem sorte


🧠 FMID / RMID / UMID

  • FMID → origem (quem criou)
  • RMID → última substituição
  • UMID → updates incrementais

👉 isso é controle de versão REAL (muito antes do Git 😄)


🧱 COMO FUNCIONA O ARMAZENAMENTO

📦 O coração: CSI (VSAM)

👉 dataset VSAM KSDS

Contém:

  • ZONES
  • entradas de elementos
  • relações entre bibliotecas

🧩 ZONES (ARQUITETURA LÓGICA)

ZoneFunção
GLOBALíndice e controle
TARGETo que está rodando
DLIBbase confiável

💡 Insight de sênior:

🔥 TARGET mente
🔥 DLIB não mente


📁 TIPOS DE DATASETS DO SMP/E

🔹 SMPCSI

👉 o banco (VSAM)


🔹 SMPPTS

👉 staging dos SYSMODs (RECEIVE)


🔹 SMPLOG / SMPOUT

👉 logs e mensagens (onde está a verdade)


🔹 TARGET LIBRARIES

👉 executáveis (load modules)


🔹 DISTRIBUTION LIBRARIES (DLIB)

👉 base confiável (source, macros, objetos)


💣 Curiosidade:

DLIB geralmente NÃO é executável
e mesmo assim é mais importante que TARGET


⚙️ COMO O SMP/E FUNCIONA (O FLUXO QUE MANDA EM TUDO)

RECEIVE → APPLY → ACCEPT

🔹 RECEIVE

  • carrega SYSMOD
  • não altera sistema

🔹 APPLY

  • altera TARGET
  • muda runtime

💀 aqui nasce o problema


🔹 ACCEPT

  • atualiza DLIB
  • vira baseline

💣 Easter egg:

APPLY muda o presente
ACCEPT muda o futuro


🖥️ SMP/E NO ISPF (TELA VERDE RAIZ)

Acesso típico:

TSO SMPE

Menu clássico:

  • RECEIVE
  • APPLY
  • ACCEPT
  • RESTORE
  • LIST / REPORT

💡 Dica de sênior:

ISPF é interface…
mas quem manda é o JCL


⚙️ SMP/E VIA BATCH (MUNDO REAL)

Execução padrão:

//SMPE EXEC PGM=GIMSMP
//SMPCSI DD ...
//SYSIN DD *
SET BDY(TZONE).
APPLY CHECK.
/*

💣 Curiosidade:

todo clique no ISPF vira JCL por baixo


🧩 MCS — A LINGUAGEM DO SMP/E

Tudo começa com:

++PTF
++VER
++MOD

🔥 ++VER (O MAIS IMPORTANTE)

Define:

  • FMID
  • dependências
  • aplicabilidade

💀 erro aqui = APPLY FAIL


🔗 DEPENDÊNCIAS (ONDE O BICHO PEGA)

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

💣 80% dos erros de SMP/E:

👉 dependência não resolvida


🏗️ JCLIN — O SEGREDO QUE NINGUÉM TE CONTA

👉 não executa
👉 descreve o link-edit

💡 SMP/E aprende como montar o sistema


💀 erro clássico:

código certo… montagem errada


🧬 TRACKING (O NÍVEL QUE DIFERENCIA)

SMP/E sabe:

FMID → origem
RMID → substituição
UMID → updates

💡 Insight:

  • 1 RMID por elemento
  • vários UMIDs

👉 isso explica comportamento estranho


💣 CASO REAL (VOCÊ JÁ VIU ISSO)

👉 programa mudou comportamento

Causa:

  • novo PTF
  • RMID alterado
  • runtime atualizado

💀 não foi o código


⚠️ TROUBLESHOOTING RÁPIDO

Se der erro:

  1. leia SMPOUT
  2. verifique dependência
  3. cheque HOLDDATA
  4. valide zone
  5. rode APPLY CHECK

🍛 A PENSAR NA HORA DO ALMOÇO

👉 quantos bugs você debugou…

…que eram:

  • mudança de load module
  • alteração de ambiente
  • PTF aplicado

🚀 CONCLUSÃO (NÍVEL SÊNIOR)

💀 SMP/E não instala software
🔥 ele governa o estado do sistema


🔥 FRASE FINAL (ASSINATURA)

💣 “Seu código não mudou…
o mundo ao redor dele mudou — e você não viu.”

 

quarta-feira, 1 de abril de 2026

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

 

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:

TipoO que é
TARGETo que roda
DLIBbase 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.”


segunda-feira, 29 de dezembro de 2025

💥 MQ NÃO É FILA — É O SEGURO DE VIDA DO SEU COBOL

 

Bellacosa Mainframe conheça MQ 

💥 MQ NÃO É FILA — É O SEGURO DE VIDA DO SEU COBOL

O guia definitivo de IBM MQ Fundamentals para quem vive no z/OS

Se você é um dev COBOL experiente, já sabe:
👉 o problema nunca foi o código…
👉 o problema sempre foi integração.

E é exatamente aí que entra o IBM MQ — o componente que transformou o mainframe de “ilha isolada” em coração da arquitetura moderna.


🕰️ ORIGEM — POR QUE O MQ EXISTE?

Antes do MQ:

  • Sistemas conversavam via sockets, arquivos, chamadas diretas
  • Tudo era síncrono
  • Se o destino caía → 💥 tudo quebrava

👉 A IBM criou o MQ (antigo WebSphere MQ) para resolver:

✔ Desacoplamento
✔ Confiabilidade
✔ Escalabilidade
✔ Integração heterogênea

💡 Tradução Bellacosa:

“MQ nasceu para impedir que um sistema derrube o outro.”


🧠 CONCEITO CENTRAL (O QUE MUDA TUDO)

👉 Aplicações não se falam diretamente

Elas falam com filas.


📦 MODELO MENTAL

COBOL A → MQ → COBOL B

✔ A envia
✔ MQ guarda
✔ B consome

👉 Simples… e revolucionário


💥 O TRIO QUE VOCÊ NUNCA ESQUECE

ConceitoPapel
MessageUnidade de dados
QueueArmazenamento
Queue ManagerCérebro

🧠 FRASE DE OURO

“Sem Queue Manager… não existe MQ.”


⚙️ COMO ISSO FUNCIONA (PASSO A PASSO REAL)

🔹 1. Aplicação COBOL envia mensagem

CALL 'MQPUT' USING ...

👉 Não importa:

  • Se o destino está online
  • Onde ele está
  • Qual linguagem usa

🔹 2. MQ armazena na fila

✔ Persistente (disco)
✔ Seguro
✔ Ordenado


🔹 3. Outra aplicação consome

CALL 'MQGET' USING ...

👉 Pode ser:

  • COBOL
  • Java
  • .NET
  • SAP

🔄 ASSÍNCRONO — O PODER REAL

👉 Diferente de CICS sync:

✔ Envia → continua
✔ Não bloqueia
✔ Alta performance

💡 Isso muda tudo em batch + online


💾 PERSISTENT vs NON-PERSISTENT

🔥 Persistent

✔ Gravado em disco
✔ Não perde
✔ Entrega garantida

👉 Use em:

  • Financeiro
  • Débito
  • Liquidação

⚡ Non-persistent

✔ Mais rápido
❌ Pode perder

👉 Use em:

  • Consulta
  • Logs
  • Eventos leves

🔄 UOW — TRANSAÇÃO DE VERDADE

👉 Unit of Work = grupo de mensagens

✔ Tudo ou nada

💡 Exemplo:

  • 4 mensagens
  • 1 falha

👉 MQ faz rollback de todas


💀 DLQ — DEAD LETTER QUEUE

👉 Quando dá ruim:

✔ Mensagem vai para DLQ
✔ Com motivo + código

💡 Easter egg de produção:

DLQ cheia = sistema gritando socorro


🔐 SEGURANÇA (NÍVEL ENTERPRISE)

🧠 OAM (Object Authority Manager)

✔ Controla acesso
✔ Quem pode PUT/GET


🔒 SSL / TLS

✔ Criptografia
✔ Autenticação


🔄 CONVERSÃO DE DADOS (A MÁGICA)

👉 COBOL (EBCDIC) ↔ Java (ASCII)

✔ MQ converte automaticamente

💡 Você nem vê acontecer


⚙️ CUSTOM CONVERSION

👉 Quer regra própria?

✔ Use exits

💡 Muito usado em legado


🧩 PADRÕES DE ARQUITETURA (OURO)


📦 Point-to-Point

✔ 1 → 1
✔ Request/Reply

👉 Clássico COBOL ↔ COBOL


💻 Client/Server

✔ Muitos → 1

👉 Centralização (ex: core bancário)


⚖️ Workload Sharing

✔ 1 fila → vários consumidores

👉 Paralelismo brutal

💡 Padrão:

Competing Consumers


📡 Publish/Subscribe

✔ 1 → muitos
✔ Desacoplado

👉 Base de Event-Driven Architecture


💣 PEGADINHAS QUE DERRUBAM SENIOR

❌ MQ é síncrono → ERRADO
❌ Aplicações se conectam direto → ERRADO
❌ Remote queue armazena mensagem → ERRADO
❌ MQ garante non-persistent → ERRADO


🧠 CENÁRIO REAL (BANCO)

👉 Fluxo típico:

  1. COBOL envia transação (MQPUT)
  2. MQ armazena (persistent)
  3. Workers processam (workload)
  4. Evento dispara (pub/sub)

💥 Tudo via MQ


🔥 CURIOSIDADES (EASTER EGGS)

  • MQ existe desde os anos 90 e ainda domina bancos
  • DLQ handler pode automatizar correções
  • MQ roda em:
    • z/OS
    • Linux
    • Windows
  • Pode transportar até 100MB por mensagem

💥 FRASES QUE DEFINEM MQ

“MQ desacopla no tempo, no espaço e na tecnologia.”

“Se caiu, MQ segura. Se voltou, MQ entrega.”

“COBOL não morreu… ele só ganhou MQ.”


🚀 CONCLUSÃO

Se você domina MQ:

✔ Seus sistemas não quebram fácil
✔ Integração deixa de ser dor
✔ Você pensa como arquiteto


💣 VERDADE FINAL

“MQ não é só middleware…
é o que separa sistemas frágeis de sistemas resilientes.”

 

domingo, 14 de dezembro de 2025

💥 CEMT NÃO MORREU — MAS O CICS EXPLORER DOMINA: O Guia Definitivo para Dev COBOL Sênior no IBM Z

 

Bellacosa Mainframe apresenta o CICS Explorer

💥 CEMT NÃO MORREU — MAS O CICS EXPLORER DOMINA: O Guia Definitivo para Dev COBOL Sênior no IBM Z

Se você vive de COBOL em CICS, já sabe: produção não perdoa.
Durante décadas, o mundo foi verde-preto, com CEMT, CEDA e reflexo condicionado no teclado.

Mas algo mudou.

👉 O CICS Explorer não é só uma interface bonita.
👉 É a camada que conecta o legado ao futuro do IBM Z (z16 / z17).

E se você ignorar isso… vai operar no passado.


🧠 Origem — Por que o CICS Explorer existe?

Antes de 2008:

  • Tudo era via 3270
  • Comandos memorizados
  • Navegação sequencial
  • Pouca visão global

Então a IBM lançou (como SupportPac):

👉 CICS Explorer (2008)

Com um objetivo claro:

💥 Transformar operação CICS em experiência visual, integrada e moderna


🧩 Arquitetura — O que está por trás da mágica

O Explorer não acessa CICS diretamente.

Seu PC (Explorer)

HTTP/HTTPS (CMCI)

CICSPlex SM

Regiões CICS TS (z/OS / z17)

👉 Ou seja: tudo passa pelo CMCI (CICS Management Client Interface)

💎 Sem CMCI = sem Explorer.


💻 O que é o CICS Explorer (de verdade)

Uma aplicação baseada em Eclipse, rodando sobre:

👉 IBM z/OS Explorer (Aqua)

E permite:

  • Operação
  • Administração
  • Monitoramento
  • Deploy
  • Diagnóstico
  • Integração DevOps

☕ Analogia que muda tudo

ConceitoMundo Real
CEMTbisturi
CEDAferramenta de construção
Explorersala de cirurgia completa

👁️ Conceitos fundamentais (que caem em prova e em produção)

🏢 Workspace

Seu ambiente completo.

🧭 Perspective

Layout de trabalho.

👁️ View

Painel com dados específicos.

🗂️ View Set

Grupo de views em abas.


💎 Regra de ouro:

Perspective = organização
View = informação
Workspace = ambiente

🔐 Conectando ao CICS (o básico que derruba muita gente)

Você precisa de:

  • Host/IP
  • Porta CMCI
  • HTTP/HTTPS
  • User RACF
  • CICSplex

🔥 Fluxo real

Network activity → Connected → ou Error

💥 Problemas clássicos

  • Porta errada
  • CMCI fora
  • RACF negando
  • Certificado inválido
  • Firewall bloqueando

👉 Abra sempre o Error Log View


🧪 Exemplo prático (vida real)

🎯 Problema:

Usuário travou sistema.

🔥 No Explorer:

  1. Abrir Tasks View
  2. Filtrar transação
  3. Ver task ativa
  4. Cancelar ou analisar

👉 Sem digitar um único comando.


⚙️ Manipulação de Views — Onde nasce a produtividade

Você pode:

✔️ Criar
✔️ Mover
✔️ Redimensionar
✔️ Filtrar
✔️ Maximizar
✔️ Minimizar
✔️ Fechar (X na aba!)


💥 Easter Egg de prova (e produção)

👉 Fechar view = X na aba, não no painel

[ Local Files X ]

🔎 Filtros — A arma secreta

Em ambientes grandes:

  • 1000+ programas
  • 500+ filas
  • dezenas de regiões

👉 Sem filtro = caos

Com filtro:

💎 precisão cirúrgica


🧭 Perspectives — O verdadeiro poder

Você pode ter várias:

  • 🔥 PROD Monitoring
  • 🧪 TEST
  • 🛠️ Troubleshooting
  • 🧑‍💻 Dev

E alternar em segundos.


💾 Salvando seu layout

Window → Perspective → Save Perspective As

👉 Isso é ouro em produção.


🧠 Explorer vs CEMT/CEDA

SituaçãoMelhor
Incidente crítico imediatoCEMT
Visão geralExplorer
AdministraçãoExplorer
Ação rápida conhecidaCEMT

👉 O profissional sênior usa os dois.


💎 Curiosidades que poucos sabem

🧠 1. É Eclipse disfarçado

Se você domina Eclipse → já domina metade do Explorer.


🔌 2. Tudo é via HTTP

Sim, CICS sendo gerenciado via REST-like (CMCI).


🚀 3. É base para DevOps no mainframe

Pipeline moderno depende disso.


🧩 4. Pode rodar fora do mainframe

Windows, Linux, macOS.


🔥 Easter Eggs de operador experiente

  • 🧊 Minimizar views cria “dock lateral escondido”
  • 🧨 Maximizar view vira modo foco total
  • 🔎 Filtros podem ser combinados
  • 🗂️ Você pode duplicar views com contextos diferentes
  • ⚙️ Customize view melhora MUITO leitura

🚀 Cenário real — Incidente em produção

1) Abrir Perspective "Incident"
2) Maximizar Tasks
3) Filtrar transação
4) Ver recursos associados
5) Analisar logs

👉 Tudo em segundos.


🏆 O que muda na sua carreira

Antes:

⌨️ Operador reativo
📜 Dependente de comando
🧠 Baseado em memória

Depois:

💻 Operador visual
🚀 Diagnóstico rápido
🧭 Visão sistêmica
☕ Mais produtividade


💥 Conclusão provocativa

👉 O CICS Explorer não substitui o 3270.
👉 Ele expande o que você pode fazer.

Mas aqui vai a verdade:

Quem ignora o Explorer vira especialista no passado.

 

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...