Translate

Mostrar mensagens com a etiqueta devops mainframe. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta devops mainframe. Mostrar todas as mensagens

sexta-feira, 29 de maio de 2026

☕🔥 “DO 3270 AO DEVOPS” — O GUIA DEFINITIVO DO SYSprog PADAWAN PARA IBM Z SYSTEM AUTOMATION, ZOWE E APIs MODERNAS

 

Bellacosa Mainframe e o IBM Z System Automation


☕🔥 “DO 3270 AO DEVOPS” — O GUIA DEFINITIVO DO SYSprog PADAWAN PARA IBM Z SYSTEM AUTOMATION, ZOWE E APIs MODERNAS

Existe um momento na vida de todo sysprog padawan em que ele percebe uma verdade assustadora:

“O mainframe moderno não vive mais apenas de ISPF, SDSF e comandos verdes.”

E nesse instante começa a jornada.

Uma jornada que leva o operador clássico do:

  • INGLIST

  • INGAMS

  • TSO

  • NetView

  • Automation Table

para um novo universo:

  • REST APIs

  • Swagger

  • Zowe CLI

  • Ansible

  • YAML

  • DevOps

  • GitOps

  • AIOps

Sim…
o IBM Z mudou.

E se você ainda imagina que automação no mainframe significa apenas:

START CICS
STOP DB2

então prepare seu café porque hoje vamos entrar no:

IBM Z System Automation MODERNO.


☕ O QUE É IBM Z SYSTEM AUTOMATION?

O IBM Z System Automation (SA z/OS):

é o cérebro operacional do mainframe.

Ele é responsável por:

  • iniciar subsistemas

  • parar aplicações

  • monitorar ambientes

  • tratar falhas

  • executar recovery automático

  • coordenar dependências

Pense nele como:

o “Kubernetes” do mundo enterprise tradicional.


🔥 EXEMPLO PRÁTICO

Imagine:

Você possui:

  • DB2

  • CICS

  • MQ

  • Batch

  • WebSphere

Tudo depende um do outro.

O SA sabe:

  • o que iniciar primeiro

  • o que depende do quê

  • como reagir a falhas

  • como automatizar recovery


☕ O MUNDO ANTIGO DO SYSprog

Durante décadas:

o mainframe foi operado principalmente via 3270.

Comandos clássicos:

INGLIST
INGAMS
INGREQ
INGSET

Painéis verdes.
PF Keys.
Automation Tables.
Policy Database.

Funcionava maravilhosamente.

E ainda funciona.

Mas o mundo mudou.


🔥 O PROBLEMA

Enquanto Linux e Cloud evoluíam para:

  • APIs

  • pipelines

  • automação declarativa

  • integração CI/CD

o mainframe parecia isolado.

Até que a IBM começou uma revolução silenciosa.


☕ NASCE O SYSTEM AUTOMATION OPERATIONS REST SERVER

Esse componente:

mudou tudo.

O SA ganhou:

APIs REST modernas.

Agora qualquer software consegue conversar com o mainframe usando:

  • HTTP

  • JSON

  • REST

  • CURL


🧠 O QUE ISSO SIGNIFICA?

Antes:

Operador
   ↓
3270
   ↓
NetView

Agora:

Pipeline DevOps
      ↓
REST API
      ↓
IBM Z System Automation

☕ O QUE O REST SERVER CONSEGUE FAZER?

Ele permite:

✅ listar resources
✅ iniciar aplicações
✅ parar subsistemas
✅ criar dynamic resources
✅ deletar resources
✅ refresh policy
✅ consultar requests
✅ interagir com automation managers


🔥 MAS EXISTE UMA LIMITAÇÃO IMPORTANTE

O REST API:

NÃO edita a policy.

Ele opera:

o runtime.

Ou seja:

  • você controla recursos

  • mas não altera definições da policy

Isso é importante para:

  • segurança

  • governança

  • integridade operacional


☕ SWAGGER UI — O LABORATÓRIO SECRETO DO SYSprog

Depois que o REST Server está ativo:

nasce o Swagger UI.

URL típica:

http://server:port/ibm/sa/swagger-ui/index.html

🔥 O QUE É ISSO?

Uma interface web interativa que mostra:

  • endpoints

  • parâmetros

  • JSON

  • responses

  • códigos HTTP

E MAIS:

você pode testar chamadas ao vivo.


☕ EXEMPLO REAL

Consultar resources:

GET /resources

Resposta:

{
 "resource":"CICSA",
 "status":"UP"
}

🔥 AGORA O SYSprog COMEÇA A VIRAR DEVOPS ENGINEER

Porque:

APIs permitem integração total.


☕ CURL — O PODER BRUTO

O Swagger ainda mostra comandos CURL.

Exemplo:

curl -X GET https://server/resources

Agora imagine:

  • scripts

  • automação

  • pipelines

  • monitoramento externo

Tudo falando com SA.


☕ E ENTÃO SURGE O ZOWE CLI

O Zowe foi outra revolução gigantesca.

Ele trouxe:

shell moderno para o mainframe.


🔥 ANTES

3270

🔥 AGORA

zowe sa list resources

🧠 O ZOWE É COMO UM “LINUX TERMINAL” PARA z/OS

E isso reduz brutalmente:

a barreira de entrada no mainframe.


☕ POR QUE ISSO É IMPORTANTE?

Hoje muitos profissionais:

  • conhecem Linux

  • usam Git

  • usam shell

  • usam pipelines

Mas:

  • não conhecem ISPF

  • não conhecem PF Keys

  • não conhecem 3270

O Zowe resolve isso.


☕ COMO O ZOWE FUNCIONA?

Arquitetura:

Zowe CLI
    ↓
SA Plug-in
    ↓
REST Server
    ↓
IBM Z System Automation

🔥 O ZOWE NÃO SUBSTITUI O NETVIEW

Ele é:

uma interface adicional.


☕ INSTALANDO O ZOWE

Pré-requisitos:

✅ Node.js
✅ npm
✅ gnome-keyring (Linux)

Instalação:

npm install -g @zowe/cli

☕ INSTALANDO O PLUGIN SA

zowe plugins install

☕ COMANDOS IMPORTANTES

Listar resources:

zowe sa list resources

Deletar dynamic resource:

zowe sa del res --name TESTE1

Ajuda:

zowe sa --help

Ajuda HTML:

zowe sa --help-web

☕ DYNAMIC RESOURCES — O CONCEITO MAIS IMPORTANTE

Isso aqui muda completamente a automação do mainframe.


🔥 O QUE É UM DYNAMIC RESOURCE?

Um recurso criado:

em runtime.

Sem:

  • rebuild

  • refresh completo

  • restart global


🧠 ISSO É MUITO “CLOUD-LIKE”


☕ ANALOGIA MODERNA

CloudSA
PodDynamic Resource
kubectlZowe
YAMLPlaybook
DeploymentTemplate

☕ ENTRA O ANSIBLE

Agora chegamos ao nível Jedi.


🔥 O QUE É O ANSIBLE?

Ferramenta de automação declarativa baseada em:

YAML.


🧠 “DECLARATIVA” SIGNIFICA:

Você descreve:

o estado desejado.

E o Ansible executa.


☕ IBM Z SYSTEM AUTOMATION ANSIBLE COLLECTION

A IBM criou uma collection específica para SA.

Ela oferece duas roles:

sa_create_dynamic_resource
sa_delete_dynamic_resource

☕ EXEMPLO DE PLAYBOOK

- hosts: zos
  roles:
    - sa_create_dynamic_resource

🔥 O QUE ACONTECE?

Playbook
   ↓
REST API
   ↓
SA REST Server
   ↓
INGDYN CREATE

☕ ISSO É REVOLUCIONÁRIO

Porque agora:

o mainframe entra no pipeline DevOps.


☕ CENÁRIO REAL

Imagine:

Developer faz:

git push

Pipeline executa:

Ansible
 ↓
Deploy
 ↓
Create dynamic resource
 ↓
Start application

Tudo automático.


☕ O SYSprog DO FUTURO

O profissional moderno não será apenas:

operador de console.

Ele será:

  • automation engineer

  • platform engineer

  • DevOps specialist

  • API integrator


☕ AIOPS — O PRÓXIMO PASSO

A IBM está indo além.

Agora fala-se em:

AIOps.

Artificial Intelligence for IT Operations.


🔥 O OBJETIVO

Usar:

  • analytics

  • machine learning

  • observability

  • automation

para criar:

sistemas autônomos.


☕ O SA FAZ PARTE DISSO

Hoje o SA integra:

  • observabilidade

  • automation

  • REST APIs

  • eventos

  • workflows


☕ O SYSprog PADAWAN PRECISA ENTENDER UMA VERDADE

O mainframe:

não está parado no tempo.

Na verdade:

ele está se tornando uma plataforma híbrida programável.


☕ O QUE VOCÊ DEVE ESTUDAR AGORA?

Depois desse curso:

  • REST APIs

  • JSON

  • YAML

  • Python

  • Zowe

  • Ansible

  • Git

  • OpenShift

  • z/OSMF

  • SMU


☕ DICA DE OURO DO LOBO VELHO

Aprenda:

os dois mundos.

Porque o profissional mais poderoso será aquele que souber:

✅ INGLIST
✅ NetView
✅ Policy
✅ Automation Tables

MAS TAMBÉM:

✅ APIs
✅ Zowe
✅ YAML
✅ Ansible
✅ DevOps


☕ CONCLUSÃO

O IBM Z moderno está atravessando a maior transformação operacional desde o surgimento do Sysplex.

O que antes era:

  • centralizado

  • fechado

  • baseado em 3270

está se tornando:

  • orientado a APIs

  • integrado a pipelines

  • declarativo

  • automatizado

  • cloud-aware

E o IBM Z System Automation é uma das peças centrais dessa transformação.

O sysprog padawan que aprender isso agora:

estará anos à frente do mercado.

Porque o futuro do mainframe:

não é abandonar o legado.

É integrar o legado ao futuro.


sexta-feira, 15 de maio de 2026

☕💣 15 COISAS SOBRE SMP/E QUE TODO SYSProg JUNIOR DESCOBRE TARDE DEMAIS ☕💣

 

Bellacosa Mainframe e uma lista com 15 curiosidades sobre o SMP/E

☕💣 15 COISAS SOBRE SMP/E QUE TODO SYSProg JUNIOR DESCOBRE TARDE DEMAIS ☕💣

O SMP/E parece “só um instalador”.

Até o dia em que ele destrói seu APPLY, trava uma maintenance window ou começa uma guerra silenciosa com o RACF às 3 da manhã.

Aí você percebe:

o SMP/E não é ferramenta.
É uma entidade cósmica do z/OS.

Então pega o café porque aqui vão algumas das curiosidades mais fascinantes — e assustadoras — do universo SMP/E.


☕ 1 — O SMP/E EXISTE DESDE A ERA DOS DINOSSAUROS CORPORATIVOS

Antes do SMP/E existia o:

SMP (System Modification Program)

O “E” de Extended veio depois.

E mesmo assim MUITA lógica histórica do MVS clássico ainda vive dentro dele.

Ou seja:

parte do SMP/E moderno carrega DNA dos anos 70.

☕ 2 — O CSI É BASICAMENTE O “BANCO DE DADOS DA VERDADE”

O CSI:

Consolidated Software Inventory

é o coração do SMP/E.

Ele sabe:

  • o que está instalado,

  • o que falta,

  • pré-requisitos,

  • dependências,

  • supersedes,

  • HOLDDATA.

Se o CSI corromper:

o desespero psicológico começa.

☕ 3 — APPLY NÃO INSTALA “ARQUIVOS”

Essa é uma das maiores surpresas para iniciantes.

O SMP/E NÃO funciona igual Windows Installer.

Ele trabalha com:

  • ELEMENTS,

  • MODs,

  • MACs,

  • SRCs,

  • RELFILEs,

  • SYSMODs.

Ou seja:

o SMP/E pensa em engenharia de software,
não em “copiar arquivo”.

☕ 4 — O RECEIVE ORDER FEZ O MAINFRAME ENTRAR NA INTERNET SEM FAZER BARULHO

Muita gente acha que cloud inventou automação.

Enquanto isso o z/OS já fazia:

  • download automático,

  • SSL/TLS,

  • autenticação por certificado,

  • automação de manutenção,

anos antes de muita startup existir.


☕ 5 — O SMP/E USA JAVA… E ISSO ASSUSTA VETERANOS

Nada é mais engraçado que ver um SYSProg raiz descobrir:

javahome=
classpath=

dentro de uma JCL SMP/E.

O sujeito cresceu no:

IEBGENER
IDCAMS
IEFBR14

e de repente precisa debugar TLS Java.


☕ 6 — O HOLDDATA É O “SISTEMA NERVOSO” DA MANUTENÇÃO

HOLDDATA não é “só um arquivo”.

Ele avisa:

  • PTF problemática,

  • conflito,

  • ação manual,

  • PE error,

  • bypass necessário.

Veteranos respeitam HOLDDATA como:

um oráculo antigo do datacenter.

☕ 7 — EXISTE GENTE QUE TEM MEDO DE CONTENT(ALL)

E com razão.

O primeiro:

RECEIVE ORDER CONTENT(ALL)

de um ambiente antigo pode baixar um apocalipse de manutenção acumulada.

Tem ambiente que parece:

um tsunami de PTFs vindo do passado.

☕ 8 — O SMP/E CONSEGUE SABER DEPENDÊNCIAS MELHOR QUE MUITO GERENTE

Ele entende:

  • pré-requisitos,

  • co-requisitos,

  • supersedes,

  • incompatibilidades.

Ou seja:

o SMP/E sabe mais sobre o software do banco
do que metade da equipe.

☕ 9 — RACF E SMP/E TÊM UMA RELAÇÃO COMPLICADA

Quando SSL entra na história…

o SYSProg descobre:

  • keyring,

  • certificados,

  • trust chain,

  • RDATALIB,

  • DIGTCERT.

E aí nasce o clássico:

“isso é problema do RACF ou do SMP/E?”

Ninguém sabe.


☕ 10 — O SMP/E É MAIS PRÓXIMO DE UM GERENCIADOR DEVOPS DO QUE VOCÊ IMAGINA

Na prática ele já fazia:

  • versionamento,

  • rollback lógico,

  • controle de dependência,

  • inventory,

  • automação,

  • compliance.

Muito antes da palavra DevOps virar moda.


☕ 11 — APPLY CHECK SALVOU MAIS CARREIRAS QUE BACKUP

Veteranos SEMPRE fazem:

APPLY CHECK

Porque APPLY direto é:

esporte radical corporativo.

☕ 12 — O SMP/E NÃO “ESQUECE” FACILMENTE

O CSI guarda histórico detalhado.

Então quando alguém pergunta:

“quem aplicou isso?”

o SMP/E normalmente sabe.

É praticamente auditoria forense do z/OS.


☕ 13 — EXISTEM SYSProgs QUE AMAM MAIS O SMP/E QUE O ISPF

Parece exagero.

Até você perceber que:

um bom SYSProg mede estabilidade pela qualidade da maintenance strategy.

☕ 14 — O RECEIVE ORDER TRANSFORMOU O MAINFRAME EM UM CLIENTE CLOUD

Isso parece absurdo.

Mas o z/OS hoje:

  • autentica via TLS,

  • usa certificados digitais,

  • conversa com APIs,

  • baixa conteúdo remoto,

  • automatiza updates.

Ou seja:

o mainframe virou um cidadão da internet moderna.

☕ 15 — O SMP/E ENSINA UMA LIÇÃO BRUTAL SOBRE O z/OS

O iniciante acha que mainframe é:

“tela verde e COBOL”

O SMP/E mostra que o mundo real é:

  • engenharia de software,

  • segurança enterprise,

  • criptografia,

  • automação,

  • integração,

  • compliance,

  • arquitetura crítica.

E talvez seja por isso que o z/OS continua vivo.

Porque no final…

ninguém no planeta leva manutenção enterprise tão a sério quanto o mainframe.

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.”


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.

 

quinta-feira, 11 de dezembro de 2025

💥 CEMT NÃO MORREU — MAS O CICS EXPLORER DOMINA: Como Manipular Dados no CICS Explorer no IBM z17 (Guia Definitivo para Dev COBOL Sênior)

 

Bellacosa Mainframe em aquilo que não tem contaram sobre CICS Explorer Data

💥 CEMT NÃO MORREU — MAS O CICS EXPLORER DOMINA: Como Manipular Dados no CICS Explorer no IBM z17 (Guia Definitivo para Dev COBOL Sênior)

Se você vive de COBOL em CICS, já sabe:
o terminal 3270 moldou gerações — mas o jogo mudou.

No IBM z17 com CICS Explorer, você não apenas “consulta recursos”…
👉 você visualiza, filtra, manipula e governa o runtime em tempo real.

E mais: com muito mais segurança, contexto e velocidade.

Este guia é direto ao ponto, profundo e prático — do jeito que um dev COBOL sênior precisa.


🧠 De onde veio o CICS Explorer (e por que ele importa)

Antes:

  • CEMT INQ TRANS
  • CEDA DEFINE
  • CEMT SET FILE
  • Telas fragmentadas
  • Memorização pesada
  • Contexto limitado

Agora:

👉 Interface baseada em Eclipse
👉 Integração com CMCI
👉 Visão consolidada
👉 Operação gráfica + inteligente

💡 O Explorer não substitui o CEMT — ele o abstrai e potencializa.


🔥 O que significa “Manipulating CICS Explorer Data”

No Explorer, “dados” não são só registros.

São recursos vivos do CICS:

  • Transações
  • Programas
  • Arquivos VSAM
  • Filas TS/TD
  • Tasks
  • Conexões
  • Métricas runtime
  • Definições BAS/CSD

👉 Você está manipulando o estado do sistema em produção.


🧩 1) Views: seu novo painel operacional

Cada view é uma tabela dinâmica:

  • Linha = recurso
  • Coluna = atributo

Exemplo (Local Transactions):

NAME | STATUS | PROGRAM | PRIORITY | USE COUNT | DUMPING

💡 Isso substitui múltiplos comandos CEMT.


⚡ Personalização que muda o jogo

Você pode:

✔ Mostrar/ocultar colunas
✔ Reordenar (drag & drop)
✔ Filtrar dados
✔ Ordenar por qualquer atributo


💥 Exemplo real

Você está investigando lentidão:

ANTES:
NAME | GROUP | DESCRIPTION | PROGRAM | PRIORITY | STATUS

DEPOIS:
NAME | STATUS | PRIORITY | USE COUNT | RESPONSE TIME

👉 Em segundos, você enxerga o problema.


🔀 2) Drag & Drop: simples, poderoso, subestimado

Clique no cabeçalho → arraste → solte.

Parece trivial.

👉 Mas em produção isso economiza minutos — e minutos salvam SLA.


🔍 3) Filtering: o bisturi do operador

Ambientes reais têm:

  • Centenas de transações
  • Múltiplas regiões
  • CICSPlex

Sem filtro = caos.

Com filtro:

NAME LIKE PAY*
STATUS = ENABLED
PRIORITY > 200

👉 Você reduz milhares de linhas para o que importa.


📊 4) Sorting: enxergando padrões invisíveis

Clique na coluna → ordena.

Use para:

  • Identificar gargalos
  • Ver consumo alto
  • Detectar anomalias

💡 Ordenar por USE COUNT ou CPU revela muito mais do que logs.


✏️ 5) Editor View: onde o poder mora

Duplo clique em um recurso → abre o Editor.

Aqui você:

  • Visualiza todos os atributos
  • Modifica valores
  • Aplica mudanças em tempo real

🧠 Tipos de atributos

🔽 Lista (seguro)

  • ENABLED / DISABLED
  • TRANDUMP / NOTRANDUMP

⌨️ Freeform (perigoso 😅)

  • PRIORITY
  • TIMEOUT
  • Limites

💥 Exemplo prático (vida real)

Transação com abend intermitente:

  1. Abrir Editor
  2. Alterar:
DUMPING = TRANDUMP
  1. Ctrl + S
  2. Reproduzir erro
  3. Analisar dump

👉 Sem restart. Sem JCL. Sem drama.


🟡 O famoso “>” — detalhe que salva carreira

Se aparecer:

> PRIORITY = 255

👉 Significa:

⚠️ Alterado
⚠️ NÃO salvo

💡 Esse símbolo já causou incidentes reais.


💾 Salvamento — onde muitos erram

Você só aplica mudanças com:

✔ Ctrl + S
✔ Ícone de disquete
✔ Fechar + confirmar

👉 Enter NÃO salva.


🛡️ Validação: o guardião silencioso

Se você tentar algo inválido:

❌ Não salva
❌ Mostra erro
❌ Protege o CICS

Exemplo:

PRIORITY = 9999 → rejeitado

📚 Help do CICS Explorer — sua arma secreta

Aqui está um diferencial absurdo.


⚡ F1: magia instantânea

Em uma view:

👉 Explica a tela

Em um atributo:

👉 Explica o campo

  • Significado
  • Valores válidos
  • Impacto
  • Dependências

💬 Infopop (easter egg de produtividade)

Pop-up rápido com ajuda contextual.

👉 Não abre janela
👉 Não quebra fluxo
👉 Fecha com ESC

💡 É como um “Google interno do CICS”.


🔎 Busca avançada

Você pode buscar:

  • Termos técnicos
  • Mensagens
  • Atributos
  • Procedimentos

🏢 Easter egg corporativo (nível elite)

Você pode integrar documentação interna:

  • Runbooks
  • Playbooks
  • Procedimentos
  • Guias de incidente

👉 E pesquisar tudo via Help.

🔥 Isso transforma o Explorer em um portal DevOps mainframe.


📜 Error Log — a caixa preta do Explorer

Acesse:

Window > Show View > Error Log

Mostra:

  • Informational
  • Warning
  • Error

💥 Quando usar

  • Conexão falha
  • Operação não funciona
  • Comportamento estranho
  • Debug de ambiente

🧠 Dica de ouro

Leia nessa ordem:

  1. Error
  2. Warning
  3. Info

👉 Isso conta a história do problema.


🏆 Workflow completo (nível sênior)

Situação: problema em produção.

Você:

  1. Filtra a view
  2. Reorganiza colunas
  3. Ordena por impacto
  4. Identifica recurso
  5. Abre Editor
  6. Ajusta atributo
  7. Salva
  8. Monitora
  9. Usa Help se necessário
  10. Consulta Error Log

👉 Tudo no Explorer.

Sem sair. Sem 3270.


🤯 Curiosidades que poucos sabem

  • O Explorer é baseado em Eclipse RCP
  • Usa CMCI (HTTP) para comunicação
  • Pode integrar docs internas
  • Funciona como cliente DevOps
  • Substitui dezenas de comandos CEMT
  • Permite operação multi-região (CICSPlex)

💎 Conclusão (sem romantizar)

👉 O CEMT não morreu.
👉 Mas o Explorer mudou o jogo.

Para um dev COBOL sênior:

  • Não é só UI
  • É produtividade
  • É segurança
  • É velocidade
  • É visão sistêmica

🚀 Em uma frase

👉 Quem domina CICS Explorer não opera CICS — governa o ambiente.