Translate

Mostrar mensagens com a etiqueta Automacao Mainframe. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Automacao Mainframe. Mostrar todas as mensagens

sábado, 30 de maio de 2026

☕🔥 LABORATÓRIO DEFINITIVO — IBM Z SYSTEM AUTOMATION, ZOWE CLI E DEVOPS PARA SYSprog PADAWAN

 

Bellacosa Mainframe e o laboratorio pratico de IBM System Automation

☕🔥 LABORATÓRIO DEFINITIVO — IBM Z SYSTEM AUTOMATION, ZOWE CLI E DEVOPS PARA SYSprog PADAWAN

20 Exercícios Práticos no Estilo Bellacosa Mainframe

Existe um momento na vida do sysprog padawan em que ele para de apenas observar o console verde…
e começa a automatizar o universo.

Este laboratório foi criado para:

  • iniciantes

  • operadores

  • sysprogs juniors

  • estudantes IBM Z

  • aventureiros do Zowe

  • guerreiros do NetView

Aqui você aprenderá:
✅ SA REST Server
✅ Swagger UI
✅ Zowe CLI
✅ Dynamic Resources
✅ APIs REST
✅ Curl
✅ Ansible
✅ Integração DevOps

Tudo em exercícios práticos.

Prepare o café.
Ajuste o SDSF.
E vamos entrar no hyperspace do IBM Z moderno.


☕ LAB 1 — ENTENDENDO O ECOSSISTEMA

Objetivo

Identificar os componentes da arquitetura moderna do SA.


Exercício

Explique o papel dos seguintes componentes:

  • System Automation

  • REST Server

  • Zowe CLI

  • Ansible Collection


Solução

ComponenteFunção
SA z/OSmotor de automação
REST Servergateway API
Zowe CLIinterface shell moderna
Ansibleautomação declarativa

☕ LAB 2 — ACESSANDO O SWAGGER UI

Objetivo

Explorar a documentação REST.


Exercício

Abra no navegador:

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

Liste:

  • endpoints

  • métodos HTTP

  • exemplos JSON


Solução

Você verá:

  • GET

  • POST

  • DELETE

  • responses

  • parameters

  • CURL examples


☕ LAB 3 — IDENTIFICANDO HTTP VERBS

Objetivo

Entender operações REST.


Exercício

Associe:

VerboFunção
GET?
POST?
DELETE?

Solução

VerboFunção
GETconsulta
POSTcriação/request
DELETEremoção

☕ LAB 4 — TESTANDO API VIA SWAGGER

Objetivo

Executar chamada REST real.


Exercício

Execute:

GET /resources

Solução esperada

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

☕ LAB 5 — TESTANDO CURL

Objetivo

Executar API sem browser.


Exercício

Monte um CURL para listar resources.


Solução

curl -X GET https://server/resources

☕ LAB 6 — INSTALANDO ZOWE CLI

Objetivo

Preparar ambiente moderno.


Exercício

Liste os pré-requisitos do Zowe.


Solução

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

Instalação:

npm install -g @zowe/cli

☕ LAB 7 — LISTANDO PLUGINS

Objetivo

Conhecer extensões do Zowe.


Exercício

Qual comando lista plugins instalados?


Solução

zowe plugins list

☕ LAB 8 — INSTALANDO O PLUGIN SA

Objetivo

Integrar SA ao Zowe.


Exercício

Instale o plugin System Automation.


Solução

zowe plugins install @ibm/system-automation-for-zowe-cli

☕ LAB 9 — EXPLORANDO HELP

Objetivo

Aprender ajuda integrada.


Exercício

Obtenha ajuda do plugin SA.


Solução

zowe sa --help

☕ LAB 10 — GERANDO HELP HTML

Objetivo

Visualizar documentação web.


Exercício

Gere ajuda HTML.


Solução

zowe sa --help-web

☕ LAB 11 — LISTANDO RESOURCES

Objetivo

Consultar runtime SA.


Exercício

Liste todos os resources automatizados.


Solução

zowe sa list resources

☕ LAB 12 — LISTANDO TEMPLATES

Objetivo

Conhecer templates dinâmicos.


Exercício

Liste templates disponíveis.


Solução

zowe sa list templates

☕ LAB 13 — CRIANDO DYNAMIC RESOURCE

Objetivo

Entender provisioning dinâmico.


Exercício

Explique o conceito de dynamic resource.


Solução

Resource criado:

  • em runtime

  • sem rebuild total

  • sem restart global

Conceito semelhante a:

  • containers

  • pods

  • runtime provisioning


☕ LAB 14 — DELETANDO RESOURCE

Objetivo

Operar lifecycle.


Exercício

Delete resource GFBJOST.


Solução

zowe sa del res --name GFBJOST

☕ LAB 15 — ANALISANDO O REST SERVER

Objetivo

Entender arquitetura.


Exercício

Explique a diferença entre:

  • OPT_EMBEDDED_WEBSERVER

  • OPT_LIBERTY_DEPLOYED


Solução

ModoCaracterística
EmbeddedTomcat embutido
Libertydeploy WebSphere Liberty

☕ LAB 16 — CONFIG FILES ZOWE

Objetivo

Entender profiles.


Exercício

Explique:

  • base profile

  • sa profile


Solução

ProfileUso
basepropriedades genéricas
sapropriedades específicas SA

☕ LAB 17 — ENTENDENDO ANSIBLE

Objetivo

Introdução DevOps.


Exercício

Explique o que é automação declarativa.


Solução

Você descreve:

o estado desejado.

O Ansible executa:

automaticamente.


☕ LAB 18 — PLAYBOOK BÁSICO

Objetivo

Criar resource via YAML.


Exercício

Crie playbook simples.


Solução

- hosts: zos
  roles:
    - sa_create_dynamic_resource

☕ LAB 19 — PIPELINE DEVOPS

Objetivo

Entender integração moderna.


Exercício

Explique fluxo:

Git
 ↓
Pipeline
 ↓
Ansible
 ↓
REST API
 ↓
SA

Solução

Esse fluxo:

  • automatiza deploy

  • cria resources

  • inicia aplicações

  • integra mainframe ao DevOps


☕ LAB 20 — O SYSprog DO FUTURO

Objetivo

Reflexão final.


Exercício

Explique por que:

o mainframe moderno não vive apenas de ISPF e SDSF.


Solução

Porque o IBM Z moderno agora usa:

  • APIs REST

  • JSON

  • YAML

  • Zowe

  • Ansible

  • AIOps

  • observabilidade

  • pipelines DevOps

O sysprog moderno precisa dominar:

  • operação clássica

  • automação moderna

  • integração híbrida


☕ DESAFIO FINAL DO PADAWAN

Monte um cenário onde:

  • um Git Push

  • dispara um pipeline

  • executa Ansible

  • cria dynamic resource

  • inicia aplicação automaticamente no IBM Z.

Se você conseguir explicar esse fluxo…
você deixou de ser apenas operador.

E começou sua transformação em:

IBM Z Platform Engineer.


☕ FRASE FINAL DO LABORATÓRIO

“O futuro do mainframe não é abandonar o legado.
É conectar o legado ao universo das APIs, automação e DevOps.”

— Bellacosa Mainframe

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.


domingo, 24 de maio de 2026

☕🖥️ A GRANDE ORQUESTRA DO IBM MAINFRAME — QUEM SÃO OS GUARDIÕES DO DATACENTER MAIS PODEROSO DO MUNDO? 🔥

 

Bellacosa Mainframe e a grande orquestra do IBM Mainframe

☕🖥️ A GRANDE ORQUESTRA DO IBM MAINFRAME — QUEM SÃO OS GUARDIÕES DO DATACENTER MAIS PODEROSO DO MUNDO? 🔥

A imagem mostra algo que muita gente fora do universo mainframe nunca entende direito:

👉 um ambiente IBM Mainframe NÃO funciona apenas com “programadores COBOL”.

Ele é praticamente uma cidade tecnológica viva.

Cada profissional controla uma parte crítica do ecossistema.
Quando tudo funciona… ninguém percebe.
Quando algo falha… bancos, governos, seguradoras, cartões, aeroportos e bolsas de valores podem literalmente parar.

Vamos entrar no “datacenter secreto” no estilo Bellacosa Mainframe. ☕💾


🧠 VISÃO GERAL DA EQUIPE MAINFRAME

Na prática, um grande ambiente IBM Z possui:

  • Operadores

  • SysProg

  • SysAdmin

  • Segurança RACF

  • Redes VTAM/TCPIP

  • Performance/Capacity

  • Automação

  • Gerentes do Computer Center

  • Desenvolvedores COBOL/PLI/Natural/Assembler

  • DBA DB2

  • Storage

  • Scheduler

  • Disaster Recovery

  • Middleware

Cada um possui poderes específicos.

E SIM…
há guerras silenciosas entre áreas. 😅


🧑‍💼 1. COMPUTER CENTER MANAGER

☕ “O Maestro do Datacenter”

É o comandante operacional.

Ele não necessariamente configura tudo…
mas coordena TUDO.


🎯 Conhecimento Básico

Precisa entender:

  • Mainframe architecture

  • SLA

  • Incident management

  • Capacity

  • Segurança

  • Auditoria

  • Gestão de crises

  • Escala 24x7

  • ITIL

  • Continuidade


🔥 Principais Atividades

  • Coordenar mudanças

  • Aprovar deploys críticos

  • Gerenciar incidentes severos

  • Controlar equipes

  • Planejar capacidade

  • Coordenar DRP (Disaster Recovery)


🛠️ Ferramentas

  • ServiceNow

  • Control-M

  • Omegamon

  • z/OSMF

  • Jira

  • CA7

  • Tivoli


📋 Responsabilidades

  • Garantir disponibilidade

  • Evitar indisponibilidade bancária

  • Controlar janelas batch

  • Aprovar mudanças críticas


🧨 Easter Egg

Em muitos bancos:

“Se o gerente do datacenter ligar de madrugada…
alguém vai perder o sono.”

😅


🤖 2. AUTOMATION ADMINISTRATOR

☕ “O Senhor dos Robôs do z/OS”

Esse cara automatiza o caos.

Sem ele:
o operador enlouquece.


🎯 Conhecimento Básico

  • REXX

  • NetView

  • System Automation

  • OPS/MVS

  • JES2

  • Console automation

  • SDSF


🔥 Principais Atividades

  • Automatizar mensagens

  • Reiniciar tasks automaticamente

  • Monitorar jobs

  • Criar respostas automáticas

  • Reduzir intervenção humana


🛠️ Ferramentas

  • IBM System Automation

  • CA OPS/MVS

  • NetView

  • REXX

  • SDSF


📋 Exemplo Real

Mensagem:

IEC161I DATA SET FULL

A automação pode:

  1. Detectar erro

  2. Abrir alerta

  3. Alocar novo volume

  4. Reiniciar processo

  5. Avisar operador

Tudo sozinho.

🔥


🧨 Curiosidade

Alguns ambientes possuem:

  • MAIS DE 100 MIL REGRAS AUTOMÁTICAS

Sim…
um “mini cérebro artificial” antes da IA moderna.


👨‍💻 3. SYSTEM PROGRAMMER (SYSPROG)

☕ “O Feiticeiro Supremo do Mainframe”

Esse é o mago negro do IBM Z.

Pouquíssimas pessoas chegam nesse nível.


🎯 Conhecimento Básico

Precisa dominar:

  • z/OS

  • JES2/JES3

  • IPL

  • PARMLIB

  • PROCLIB

  • VTAM

  • SMP/E

  • RACF

  • Dump analysis

  • APF

  • LPA

  • Catalog

  • Unix System Services

E muitas vezes:
Assembler.

😳


🔥 Principais Atividades

  • Instalar produtos IBM

  • Aplicar PTFs

  • Fazer IPL

  • Resolver abends sistêmicos

  • Ajustar performance

  • Gerenciar subsistemas


🛠️ Ferramentas

  • SMP/E

  • IPCS

  • SDSF

  • RMF

  • Omegamon

  • ISPF

  • HCD

  • z/OSMF


📋 Passo a Passo Real — IPL

Cenário:

Atualização crítica do z/OS.

Passos:

  1. Validar PARMLIB

  2. Verificar APF libraries

  3. Aplicar maintenance SMP/E

  4. Fazer backup

  5. Agendar janela

  6. Derrubar subsistemas

  7. Executar IPL

  8. Validar JES2

  9. Subir CICS/DB2

  10. Liberar produção


🧨 Easter Egg SysProg

Os SysProgs antigos dizem:

“Se você nunca derrubou um LPAR em produção…
você ainda é júnior.”

💀


🌐 4. NETWORK ADMINISTRATOR

☕ “O Guardião Invisível da VTAM”

Sem rede…
o terminal 3270 vira decoração.


🎯 Conhecimento Básico

  • VTAM

  • TCP/IP

  • SNA

  • OSA

  • HiperSockets

  • TN3270

  • FTP

  • MQ


🔥 Atividades

  • Configurar conectividade

  • Resolver timeout

  • Ajustar rotas

  • Integrar distribuído

  • Configurar criptografia


🛠️ Ferramentas

  • NETSTAT

  • VTAM commands

  • TCPIP stack

  • Wireshark

  • Omegamon Network


📋 Exemplo

Usuários não conseguem acessar CICS.

Investigação:

  1. TESTAR TN3270

  2. Verificar VTAM ACTIVE

  3. Validar TCPIP

  4. Conferir porta

  5. Analisar firewall

  6. Validar certificado TLS


🧨 Curiosidade

Muitos ambientes antigos ainda possuem:

  • SNA rodando em produção em 2026.

SIM.
Tecnologia dos anos 70 ainda movendo bilhões.

🔥


🔐 5. SECURITY ADMINISTRATOR

☕ “O Mestre do RACF”

Esse profissional controla:
quem pode tocar no quê.


🎯 Conhecimento Básico

  • RACF

  • ACF2

  • TopSecret

  • SAF

  • MFA

  • PassTickets

  • Digital Certificates


🔥 Atividades

  • Criar acessos

  • Auditar usuários

  • Segregar funções

  • Investigar violações

  • Configurar MFA


🛠️ Ferramentas

  • RACF commands

  • SMF

  • zSecure

  • CARLa

  • MFA Server


📋 Exemplo Passo a Passo

Novo analista COBOL:

  1. Criar USERID

  2. Associar GROUP

  3. Liberar TSO

  4. Liberar dataset

  5. Liberar CICS

  6. Validar DB2

  7. Ativar MFA


🧨 Easter Egg RACF

O maior medo de um sysprog:

ICH408I USER NOT AUTHORIZED

😅


📊 6. PERFORMANCE/CAPACITY SPECIALIST

☕ “O Economista do Mainframe”

Ele controla:
CPU = dinheiro.


🎯 Conhecimento

  • RMF

  • SMF

  • WLM

  • CPU tuning

  • IO tuning

  • Paging

  • Buffer pools


🔥 Atividades

  • Analisar gargalos

  • Planejar crescimento

  • Ajustar WLM

  • Reduzir MIPS/MSU

  • Evitar sobrecarga


🛠️ Ferramentas

  • RMF

  • MXG

  • Omegamon

  • Mainview

  • IntelliMagic


📋 Exemplo

Batch noturno atrasou.

Investigação:

  1. CPU saturation?

  2. IO contention?

  3. EXCP elevado?

  4. DB2 lock?

  5. Paging?

  6. Canal congestionado?


🧨 Curiosidade

Em bancos:

1% de otimização

milhões economizados.

💀


🖥️ 7. OPERATOR

☕ “O Piloto da Nave Mainframe”

Muita gente subestima o operador.

ERRO GRAVE.

Ele é quem mantém a operação viva 24x7.


🎯 Conhecimento Básico

  • JES2

  • SDSF

  • Console

  • Batch

  • CICS

  • IPL básico

  • Recovery

  • Procedures


🔥 Principais Atividades

  • Monitorar jobs

  • Responder mensagens

  • Controlar spool

  • Reiniciar tasks

  • Executar comandos

  • Acionar suporte


🛠️ Ferramentas

  • SDSF

  • HMC

  • Omegamon

  • NetView

  • Console z/OS


📋 Exemplo Real — Job Preso

Situação

Job travado há 4 horas.


Operador faz:

1. Verifica SDSF

ST
DA
QUEUE

2. Analisa mensagem

IEC501A

3. Descobre fita offline


4. Aciona storage


5. Monta volume


6. Responde console

R xx,YES

7. Job continua

🔥


🧨 Easter Egg Operador

Operador veterano consegue:

  • identificar problema “pelo barulho do console”.

Sim…
isso existe. 😅


👨‍💻 E OS DEVELOPERS?

☕ “Os Arquitetos do Negócio”

Os developers criam:

  • COBOL

  • PLI

  • Assembler

  • Natural

  • JCL

  • CICS

  • DB2


🎯 Conhecimento

  • Regras bancárias

  • Batch

  • Online

  • VSAM

  • SQL

  • APIs

  • MQ

  • Web Services


🔥 Atividades

  • Criar programas

  • Corrigir abends

  • Fazer tuning SQL

  • Integrar APIs

  • Modernizar legado


🛠️ Ferramentas

  • IDz

  • Endevor

  • Changeman

  • File-AID

  • Abend-AID

  • DB2 SPUFI


📋 Exemplo Real

PIX falhando.

Developer:

  1. Analisa logs

  2. Verifica MQ

  3. Confere DB2

  4. Debuga COBOL

  5. Ajusta timeout

  6. Faz bind DBRM

  7. Libera produção


💀 A VERDADE QUE NINGUÉM CONTA

No mainframe:

  • SysProg culpa rede

  • Rede culpa segurança

  • Segurança culpa developer

  • Developer culpa DB2

  • Operador culpa automação

  • Automação culpa mensagem IBM

  • IBM culpa maintenance faltando

😅


☕ O ECOSSISTEMA REAL

Um grande IBM Mainframe pode ter:

  • milhares de jobs/hora

  • petabytes

  • milhões de transações CICS

  • uptime absurdo

  • processamento financeiro global

E tudo depende dessa equipe funcionando como uma orquestra.


🧨 O MAIOR EASTER EGG DO MAINFRAME

A maioria das pessoas acha que:

“mainframe morreu.”

Enquanto isso…

  • bancos

  • cartões

  • bolsa

  • governos

  • aviação

  • seguradoras

continuam rodando em IBM Z silenciosamente.

💀🖥️☕

domingo, 17 de maio de 2026

☕🖥️ O SYSprog z/OS NÃO É “SÓ MAIS UM PROFISSIONAL DE TI” — É O ENGENHEIRO QUE IMPEDE O MUNDO DE PARAR ☕🖥️

 

Bellacosa Mainframe ilustra a importancia do Sysprog Mainframe

☕🖥️ O SYSprog z/OS NÃO É “SÓ MAIS UM PROFISSIONAL DE TI” — É O ENGENHEIRO QUE IMPEDE O MUNDO DE PARAR ☕🖥️

Existe uma frase silenciosa no universo corporativo que pouca gente fora do mainframe entende:

“Quando o mainframe para, a empresa inteira descobre que ele existia.”

E é exatamente aí que entra uma das profissões mais raras, mais complexas e mais subestimadas da tecnologia moderna:

o z/OS System Programmer.

Muita gente imagina TI como:

  • frontend colorido,
  • startup hype,
  • app mobile,
  • container,
  • influencer de LinkedIn falando “cloud-native”.

Enquanto isso…

em algum datacenter refrigerado absurdamente caro:

  • bilhões de transações financeiras continuam passando,
  • cartões continuam autorizando,
  • PIX continua existindo,
  • companhias aéreas continuam operando,
  • seguradoras continuam processando,
  • governos continuam funcionando.

E frequentemente tudo isso está apoiado em:

IBM Z + z/OS.


☕ O MAINFRAME NÃO MORREU. ELE VIROU INFRAESTRUTURA CIVILIZACIONAL.

O erro mais comum do iniciante é imaginar o mainframe como:

“computador velho dos anos 70”.

Na prática?

O IBM Z moderno possui:

  • criptografia por hardware,
  • IA embarcada,
  • Linux,
  • containers,
  • OpenShift,
  • APIs REST,
  • automação,
  • integração cloud híbrida,
  • throughput monstruoso,
  • uptime absurdo.

O mainframe não compete com notebook.

Ele compete com:

PARAR O MUNDO.


☕ O QUE UM z/OS SYSTEM PROGRAMMER REALMENTE FAZ?

O sysprog não é apenas “administrador”.

Ele é:

  • engenheiro operacional,
  • arquiteto de disponibilidade,
  • especialista em recuperação,
  • analista de performance,
  • guardião de segurança,
  • cirurgião de infraestrutura crítica.

É o profissional que:

  • instala,
  • mantém,
  • corrige,
  • automatiza,
  • protege,
  • recupera,
  • ajusta
    o z/OS.

Se um desenvolvedor cria a aplicação…

o sysprog garante:

que a infraestrutura continue respirando.


☕ EXEMPLO REAL — O CAOS QUE UM SYSprog EVITA

Imagine:

  • um banco internacional,
  • Black Friday,
  • milhões de acessos,
  • PIX em massa,
  • cartões autorizando em tempo real.

Agora imagine:

  • uma falha de storage,
  • perda de path FICON,
  • congestionamento WLM,
  • JES spool lotado,
  • RACF falhando autenticação.

O usuário final só verá:

“Aplicativo indisponível”.

Mas nos bastidores:

  • operadores entram em emergência,
  • sysprogs analisam RMF,
  • storage teams validam control units,
  • dumps começam a ser coletados,
  • IPLs são discutidos,
  • GDPS talvez seja ativado.

E é exatamente nessas horas que nasce o verdadeiro valor do sysprog.


☕ O MAIOR ERRO DO INICIANTE

O novato geralmente pensa:

“Vou aprender COBOL e pronto.”

Não.

O universo enterprise é MUITO maior.

O profissional moderno precisa entender:

  • sistema operacional,
  • segurança,
  • storage,
  • automação,
  • redes,
  • recuperação,
  • tuning,
  • workflows,
  • APIs,
  • cloud híbrida.

O z/OS moderno virou:

uma plataforma enterprise gigantesca.


☕ A TRILHA REAL PARA VIRAR SYSprog

Aqui está algo que pouca gente fala claramente:

Você NÃO vira sysprog em:

  • 2 semanas,
  • bootcamp mágico,
  • vídeo motivacional.

É uma construção gradual.


☕ FASE 1 — APRENDER A “LÍNGUA” DO MAINFRAME

Antes de tudo:

  • TSO/ISPF,
  • JCL,
  • SDSF,
  • datasets,
  • VSAM,
  • catálogo,
  • JES2.

Sem isso o aluno fica perdido.

É como tentar virar piloto sem entender painel de avião.


☕ DICA DE OURO

Muita gente tenta estudar apenas teoria.

Erro fatal.

Mainframe precisa:

laboratório.

Mesmo usando:

  • Hercules,
  • TK4/TK5,
  • zPDT,
  • ADCD,
  • ambientes educacionais,

o importante é:

  • errar,
  • quebrar,
  • restaurar,
  • analisar.

Sysprog nasce no troubleshooting.


☕ O VERDADEIRO TERROR: SMP/E

Todo sysprog veterano respeita uma entidade quase mística chamada:

SMP/E.

O sistema de manutenção do z/OS.

E aqui o iniciante descobre:

  • coexistência,
  • target zones,
  • distribution zones,
  • HOLDDATA,
  • APPLY,
  • ACCEPT,
  • regressões.

Um patch errado pode:

  • quebrar IPL,
  • destruir JES,
  • afetar RACF,
  • causar outage enterprise.

Por isso:

quem domina SMP/E vira ouro no mercado.


☕ RACF — A MURALHA DO IMPÉRIO

Hoje:

  • LGPD,
  • PCI,
  • compliance,
  • auditoria,
  • segurança bancária

são prioridades absolutas.

E no mainframe:

RACF é religião.

O sysprog moderno precisa entender:

  • perfis,
  • grupos,
  • permissões,
  • datasets,
  • certificados digitais,
  • SAF,
  • auditoria.

Porque segurança enterprise não aceita improviso.


☕ O SYSprog MODERNO PRECISA APRENDER PYTHON

Aqui vem o choque cultural.

Muita gente pensa:

“Mainframe é só COBOL.”

Errado.

Hoje o sysprog moderno usa:

  • Python,
  • APIs,
  • automação,
  • Ansible,
  • z/OSMF,
  • REST,
  • OpenShift.

O mundo mudou.

O profissional preso apenas em:

  • painel verde,
  • comandos manuais,
  • operação artesanal

começa a ficar para trás.


☕ O FUTURO É AUTOMAÇÃO

Antigamente:

  • sysprog fazia tudo manualmente.

Hoje:

  • pipelines automatizados,
  • workflows,
  • Infrastructure as Code,
  • provisionamento automático,
  • automação operacional

viraram tendência forte.

Por isso a IBM empurra:

  • Ansible for IBM Z,
  • z/OSMF,
  • OpenShift,
  • integração híbrida.

☕ WLM — O “CÉREBRO INVISÍVEL” DO z/OS

Uma das áreas mais fascinantes do mainframe moderno é o:

Workload Manager.

O WLM decide:

  • quem recebe CPU,
  • prioridade,
  • resposta,
  • throughput,
  • metas de serviço.

Enquanto sistemas distribuídos frequentemente brigam com escalabilidade…

o z/OS já fazia gerenciamento inteligente de workload há décadas.


☕ O UNIVERSO HARDCORE: IODF, IOCDS E FICON

Aqui chegamos no território lendário dos sysprogs veteranos.

Essa é a camada:

  • hardware,
  • canais,
  • control units,
  • topologia física,
  • storage enterprise.

Pouquíssimos profissionais dominam profundamente:

  • HCD,
  • IODF,
  • IOCDS,
  • FICON,
  • channel subsystem.

Quando alguém domina isso:

o mercado inteiro percebe.


☕ O FUTURO PROFISSIONAL PRECISA ENTENDER UMA VERDADE

Mainframe NÃO é tecnologia do passado.

Mainframe é:

tecnologia da continuidade operacional.

E isso muda completamente a mentalidade.

Enquanto startups pensam:

“deploy rápido”.

O mainframe pensa:

“não podemos parar”.


☕ A MENTALIDADE CERTA PARA CRESCER

O profissional que evolui no mainframe normalmente possui:

  • disciplina,
  • curiosidade,
  • paciência,
  • lógica,
  • gosto por troubleshooting,
  • gosto por documentação,
  • responsabilidade.

Porque:

ambiente enterprise não perdoa improviso.


☕ O QUE ESTUDAR HOJE?

Se eu aconselhasse alguém começando AGORA:

Base obrigatória

  • z/OS
  • TSO/ISPF
  • JCL
  • JES2
  • SDSF

Depois

  • RACF
  • SMP/E
  • USS
  • TCP/IP
  • SMS

Avançado

  • WLM
  • RMF
  • Sysplex
  • GDPS
  • HCD/IOCDS

Modernização

  • Python
  • REXX
  • Ansible
  • z/OSMF
  • APIs REST
  • OpenShift

☕ A IMPORTÂNCIA DO ZXPLORE

O ZXPLORE é extremamente forte porque organiza:

  • trilhas,
  • progressão,
  • fundamentos,
  • especializações.

Ela ajuda o aluno a:

  • não estudar aleatoriamente,
  • construir base sólida,
  • entender arquitetura enterprise.

E no mainframe:

base sólida vale mais que modinha tecnológica.


☕ CONCLUSÃO — O SYSprog É O “ENGENHEIRO CIVIL” DA COMPUTAÇÃO ENTERPRISE

Se o desenvolvedor constrói aplicações…

o sysprog sustenta:

  • a fundação,
  • a energia,
  • a segurança,
  • a continuidade,
  • a estabilidade.

Ele é o profissional que trabalha silenciosamente para garantir:

  • disponibilidade,
  • resiliência,
  • recuperação,
  • performance,
  • segurança.

E talvez essa seja a parte mais fascinante do universo IBM Z:

Enquanto o mundo inteiro fala sobre inovação…

o mainframe continua:

  • processando trilhões,
  • protegendo bancos,
  • sustentando governos,
  • mantendo infraestruturas críticas vivas.

Como diria no estilo Bellacosa Mainframe:

“Cloud impressiona em apresentações.
Mainframe impressiona quando o caos começa.” ☕🖥️

segunda-feira, 10 de novembro de 2025

🚀☕ O REXX VIROU OPERADOR DE MAINFRAME! — Quando Scripts Ganham Superpoderes no z/OS ☕🚀

 

Bellacosa Mainframe apresenta o REXX em modo batch JCL script versus compilado

🚀☕ O REXX VIROU OPERADOR DE MAINFRAME! — Quando Scripts Ganham Superpoderes no z/OS ☕🚀

“O dia em que você descobre que REXX consegue conversar diretamente com o console do MVS… é o dia em que você percebe que o Mainframe nunca foi apenas um computador.”

— Bellacosa Mainframe Chronicles


😮 O GRANDE MAL-ENTENDIDO SOBRE REXX

Muita gente acha que REXX é apenas:

  • linguagem de automação simples,
  • script de login TSO,
  • “CLIST melhorado”,
  • ferramentinha de produtividade.

Mas isso é como dizer que:

  • um z15 é “um computador grande”.

REXX no z/OS é MUITO mais profundo.

Quando você entra em:

  • compilação,
  • batch,
  • console MVS,
  • automação operacional,

o REXX deixa de ser “script” e começa a virar:

🔥 interface viva do sistema operacional.


🧠 O MOMENTO EM QUE O REXX MUDA DE NÍVEL

Existe um ponto na jornada Mainframe em que ocorre uma transformação mental.

É quando você percebe que um EXEC consegue:

✅ emitir comandos de operador
✅ capturar mensagens do sistema
✅ automatizar JES2
✅ monitorar jobs
✅ analisar IPL
✅ operar subsistemas
✅ rodar em batch
✅ virar código compilado
✅ esconder source
✅ ganhar performance absurda

Nesse momento o REXX deixa de ser:

"SAY 'HELLO WORLD'"

e vira:

"D IPLINFO"
"D A,L"
"F CICS,EMERG"

😳


☕ O REXX NÃO FOI CRIADO “ONTEM”

Criado por Mike Cowlishaw na IBM nos anos 70, o REXX nasceu com uma filosofia quase revolucionária:

“A linguagem deve ser legível para humanos.”

Enquanto outras linguagens:

  • complicavam,
  • abreviavam,
  • obscureciam,

o REXX dizia:

IF SALDO < 0 THEN
SAY 'VOCÊ ESTÁ DEVENDO'

Isso parecia simples…

Até alguém descobrir que ele podia controlar o MVS inteiro.

💀


🏛️ O REXX NO CORAÇÃO DO z/OS

Pouca gente percebe o quanto o REXX está infiltrado no ecossistema IBM:

ÁreaUso
ISPFdiálogos
SDSFautomação
RACFadministração
JES2operações
DB2utilities
CICSscripts
NetViewautomação
TSOcomandos
z/OS UNIXintegração

REXX é quase um “sistema nervoso” invisível do Mainframe.


⚡ QUANDO O INTERPRETADOR VIRA LIMITAÇÃO

O interpretador REXX é fantástico:

  • flexível,
  • amigável,
  • poderoso.

Mas existe um problema.

Ele lê:

linha por linha

Toda vez.

Imagine um loop gigantesco:

DO I = 1 TO 5000000
X = I * I
END

O interpretador precisa:

  • analisar sintaxe,
  • resolver símbolos,
  • interpretar operações,
  • gerenciar tipos,

em tempo real.

Resultado:
🐢


🚀 O DIA EM QUE O REXX GANHA TURBO

A IBM resolveu isso criando o:

IBM REXX Compiler

Agora o fluxo vira:

SOURCE REXX

COMPILER

CEXEC / OBJECT

EXECUÇÃO MUITO MAIS RÁPIDA

O ganho pode ser brutal.

Em alguns testes:

  • 6x
  • 8x
  • 10x mais rápido.

😳


💥 O DETALHE QUE MUITA GENTE NÃO SABE

O compilador não melhora apenas performance.

Ele muda completamente a confiabilidade do programa.


🧨 O INTERPRETADOR TEM UMA PEGADINHA

Veja:

IF 1 = 2 THEN
SAY 'ERRO

O interpretador:

  • nunca entra no IF,
  • nunca detecta erro.

Agora o compilador…

💀

Ele analisa tudo.

Resultado:

  • syntax validation global,
  • detecção estrutural,
  • análise completa.

Isso transforma REXX em linguagem enterprise séria.


🕵️ O XREF — A FEATURE SUBESTIMADA

Quem já herdou um REXX com:

  • 20 mil linhas,
  • 900 variáveis,
  • 300 CALLs,
  • labels aleatórios,

sabe o inferno que isso é.

Então entra o:

XREF

Cross Reference Listing.

Ele lista:

  • variáveis,
  • funções,
  • labels,
  • comandos host,
  • referências.

Exemplo:

USERID BUILT-IN 6(f)
SYSVAR SYSTM RTN 7(f)

Isso é ouro puro para:

  • manutenção,
  • auditoria,
  • engenharia reversa,
  • modernização.

👀 EASTER EGG #1 — O REXX “SECRETO”

Pouca gente conhece:

PARSE VERSION V
SAY V

Resultado:

REXX370

ou:

REXXC370

🔥

Você consegue descobrir:

  • se o código está compilado,
  • qual engine está rodando,
  • versão do interpretador.

Quase um “SHOW VERSION” interno do REXX.


🧠 O QUE É CEXEC?

O compilador pode gerar:

TipoDescrição
CEXECREXX compilado
OBJECTobject module

O CEXEC continua:

  • sendo REXX,
  • mas compilado.

Já OBJECT pode:

  • virar LOAD MODULE,
  • ser link-editado,
  • chamado como programa.

😈 O “LADO OCULTO” DO CONDENSE

Existe uma opção misteriosa:

CONDENSE

Ela:

  • compacta,
  • “embaralha”,
  • reduz tamanho.

O resultado parece:

ÆØ§µ▒╬╫╩

😵

Muitos juniors acham que:

  • dataset corrompeu,
  • encoding morreu,
  • EBCDIC explodiu.

Não.

É só REXX compilado condensado.


⚙️ REXX EM BATCH — A PORTA PARA AUTOMAÇÃO REAL

Agora começa a magia operacional.

O REXX pode rodar:

  • foreground,
  • TSO,
  • batch,
  • scheduler,
  • automation.

E aí entra uma entidade lendária do z/OS:

IKJEFT01


👑 IKJEFT01 — O “REI INVISÍVEL” DO TSO BATCH

Quem trabalha com Mainframe inevitavelmente encontra:

//STEP1 EXEC PGM=IKJEFT01

Esse programa:

  • cria ambiente TSO/E,
  • habilita comandos TSO,
  • executa CLIST,
  • executa REXX.

É quase um:

"TSO portátil dentro do batch"

💻 EXEMPLO REAL

//BELLA JOB CLASS=A,MSGCLASS=X
//STEP1 EXEC PGM=IKJEFT01
//SYSEXEC DD DSN=VAGNER.REXX.EXEC,DISP=SHR
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
%BELLA01
/*

🔥 O REXX EXECUTADO

/* REXX */

SAY 'BELLACOSA MAINFRAME ONLINE'

ADDRESS TSO
"LISTCAT LEVEL(SYS1)"

SAY 'FIM'

😮 MAS EXISTE UMA VERSÃO MAIS “ROOT”

E aí chegamos no:

IRXJCL


☠️ IRXJCL — O “MODO HARDCORE”

Com:

//STEP1 EXEC PGM=IRXJCL

o REXX roda:

  • diretamente no MVS,
  • sem TSO/E.

🔥

Agora começam as restrições.


💀 O ERRO CLÁSSICO

Isso NÃO funciona:

ADDRESS TSO "ALLOC ..."

Porque:
❌ não existe TSO.


🧠 O QUE MUDA?

AmbienteRecursos
IKJEFT01TSO completo
IRXJCLMVS puro

👑 AGORA CHEGAMOS AO “CHEAT CODE” DO z/OS

ADDRESS CONSOLE

Quando alguém aprende isso…
não existe volta.


🤯 O REXX CONSEGUE VIRAR OPERADOR MVS

Sim.

Você pode emitir:

D IPLINFO
D A,L
D U,VOL=TSO001

diretamente do EXEC.

😳


⚠️ ISSO É PODER OPERACIONAL REAL

Agora o REXX pode:

  • monitorar sistema,
  • detectar falhas,
  • responder eventos,
  • automatizar operações,
  • capturar mensagens WTO,
  • agir sozinho.

Isso é praticamente a base conceitual:

  • do NetView,
  • OPS/MVS,
  • System Automation.

🧩 EASTER EGG #2 — O TOKEN FANTASMA

Existe um conceito fascinante:

CART

Command And Response Token.

Exemplo:

"CART IPL001"
"DISPLAY IPLINFO"

O CART funciona como:

  • identificador,
  • etiqueta,
  • correlation-id do comando.

Muito parecido com:

  • tracing distribuído moderno,
  • request-id de APIs,
  • observabilidade cloud.

😳

O Mainframe já fazia isso décadas atrás.


💬 CAPTURANDO A RESPOSTA DO MVS

Agora entra:

GETMSG()

RC = GETMSG('MSG.','SOL','IPL001',,30)

E pronto.

As mensagens do console vão parar:

  • dentro de variáveis REXX.

🤯


🚀 EXEMPLO COMPLETO — “OPERADOR AUTOMÁTICO”

/* REXX */

ADDRESS TSO
"CONSPROF SOLDISPLAY(NO) SOLNUM(400)"
"CONSOLE ACTIVATE"

ADDRESS CONSOLE

"CART IPL001"
"DISPLAY IPLINFO"

RC = GETMSG('MSG.','SOL','IPL001',,30)

DO I = 1 TO MSG.0
SAY MSG.I
END

ADDRESS TSO
"CONSOLE DEACTIVATE"

😳 O QUE ESSE CÓDIGO FEZ?

Ele:
✅ ativou console MCS
✅ virou operador do z/OS
✅ executou comando MVS
✅ capturou respostas
✅ armazenou tudo em STEM variables

Tudo usando REXX.


☕ E AÍ VOCÊ PERCEBE…

O Mainframe nunca foi “ultrapassado”.

Ele sempre foi:

  • automatizável,
  • observável,
  • integrável,
  • scriptável.

Muito antes de:

  • DevOps,
  • IaC,
  • observability,
  • automation frameworks,
  • cloud scripting.

🧠 O REXX ERA “DEVOPS” ANTES DO DEVOPS EXISTIR

Pense:

HojeMainframe fazia
Python automationREXX
IaCPROCs/JCL
MonitoringWTO/GETMSG
Event DrivenConsole automation
ObservabilityCART
CI/CDEndevor/Changeman
ScriptingTSO/E

😳


👑 CONCLUSÃO — O DIA EM QUE O REXX DEIXA DE SER “LINGUAGEM”

Quando você domina:

  • Compiler,
  • IKJEFT01,
  • IRXJCL,
  • ADDRESS CONSOLE,
  • GETMSG,
  • CART,

o REXX deixa de ser:

"uma linguagem"

e vira:

🔥 Interface operacional viva do z/OS 🔥

E talvez esse seja o segredo mais subestimado do Mainframe moderno.


☕ Bellacosa Mainframe Final Thought

“Quem aprende REXX de verdade percebe uma coisa assustadora:

o Mainframe não é apenas um sistema…

ele conversa com você.” 🚀☕