🔥💎 MANUAL DO SYSPROG MODERNO — Python no z/OS 💎🔥

Bellacosa Mainframe apresenta o Manual do Sysprog usando Python

 🔥💎 MANUAL DO SYSPROG MODERNO — Python no z/OS 💎🔥

(Guia prático, estratégico e “de campo” para quem quer dominar a automação moderna no IBM Z)

---

🧠 1) A Nova Mentalidade do Sysprog

O sysprog clássico garantia que o sistema não caísse.
O sysprog moderno garante que o sistema:

🚀 Escale
🔄 Se automatize
🌐 Se integre
🛡️ Seja resiliente
⚡ Entregue valor contínuo

👉 Python é a ferramenta-chave dessa transição.

---

🐍 2) Onde Python Vive no z/OS

🐧 USS — UNIX System Services

Python roda aqui.

Pense como:

z/OS
 └── USS (POSIX / UNIX)
      └── Python

Capacidades:

• Processos POSIX

• Shell

• Arquivos zFS

• Sockets

• APIs modernas

• Ferramentas open source

💎 É o “Linux dentro do mainframe” — mas com DNA z/OS.

---

🧰 3) Kit Essencial do Sysprog Python

🔧 Ferramentas Fundamentais

🧱 ZOAU (IBM Z Open Automation Utilities)

O canivete suíço da automação.

Permite:

• Manipular datasets

• Submeter jobs

• Emitir comandos

• Executar utilitários

• Trabalhar com PDS/PDSE

• Integrar com Python e shell

👉 Sem ZOAU, Python no z/OS fica limitado.

---

🌐 Zowe (complementar)

• APIs REST para z/OS

• CLI moderna

• Integração com pipelines

• DevOps-friendly

💎 ZOAU = automação local
💎 Zowe = automação distribuída

---

📁 4) Domínio Total de Dados

🧾 Trabalhando com Datasets

Tipos principais:

• PS (sequencial)

• PDS/PDSE (bibliotecas)

• GDG (versionamento)

• VSAM (via ferramentas)

Com Python + ZOAU:

👉 Criar
👉 Ler
👉 Escrever
👉 Copiar
👉 Excluir
👉 Catalogar

---

⏳ Datasets Temporários

Usos típicos:

• Pipelines batch

• Conversões

• Dados intermediários

Helper importante:

👉 tmp_name() — gera nome válido

⚠️ Não aloca — apenas sugere.

---

📦 Load Modules

Automação comum:

• Deploy de programas

• Validação de bibliotecas

• Copiar PDSEs

• Preparar ambientes

---

🧾 5) Controle de Jobs (JES)

🔄 Automação Batch Completa

Python pode:

🔥 Submeter JCL
🔥 Monitorar status
🔥 Detectar ABEND
🔥 Ler spool
🔥 Extrair resultados
🔥 Disparar ações

👉 Isso cria pipelines inteligentes no mainframe.

---

🖥️ 6) Operador Virtual

⚡ Comandos de Sistema

Python pode emitir:

• D A,L

• START/STOP

• VARY

• Consultas

• Diagnóstico

💎 É como ter um operador automatizado 24/7.

⚠️ Requer permissões RACF adequadas.

---

🌉 7) Integração Híbrida — O Verdadeiro Poder

Python conecta z/OS com:

☁️ Cloud
🌐 APIs REST
🐧 Linux on Z
📊 Analytics
🤖 AI
📦 Microservices

💡 Exemplo real

1. Job COBOL gera dataset

2. Python extrai dados

3. Converte para JSON

4. Envia para API cloud

5. Atualiza dashboard

👉 Zero mudança no COBOL.

---

🔐 8) Segurança Profissional

❌ Nunca faça

• Hardcode de senhas

• Arquivos plaintext

• Credenciais em scripts

• Bypass de controles

✅ Faça

• Credential vault

• RACF controls

• Environment injection

• Auditoria

💎 Segurança no z/OS é parte da arquitetura, não opcional.

---

⚠️ 9) Armadilhas Clássicas

🔤 EBCDIC vs UTF-8

O “trauma inicial”.

Sempre verifique encoding ao:

• Ler datasets

• Gerar arquivos

• Integrar sistemas

---

📁 Arquivo ≠ Dataset

Diferenças críticas:

• Stream vs registro

• LRECL

• RECFM

• Blocos

• Catalogação

---

📦 PyPI ≠ compatível automaticamente

Alguns pacotes exigem port ou não funcionam.

---

🏭 10) Scripts de Produção

Um script profissional deve ter:

✅ Logs claros
✅ Tratamento de exceções
✅ Retorno adequado (RC)
✅ Idempotência
✅ Configuração externa
✅ Documentação
✅ Monitoramento

👉 Pense como software corporativo, não script pessoal.

---

⚙️ 11) Execução em Batch

🔹 Via BPXBATCH

Integra USS ao JES.

Exemplo conceitual:

JCL → BPXBATCH → Python → USS → z/OS recursos

---

🧠 12) Quando Python é a Melhor Escolha

Use quando precisar:

🔥 Automação complexa
🔥 Integração externa
🔥 Manipulação de dados
🔥 Orquestração
🔥 DevOps
🔥 Monitoramento
🔥 Self-healing

---

❌ Quando NÃO Usar

Não substitui:

• COBOL transacional massivo

• Código de baixo nível

• Componentes críticos de performance

• Kernel z/OS

• Drivers

👉 Python é o maestro, não o motor.

---

💎 13) Casos de Uso de Elite

🏦 Bancos e grandes empresas usam para:

• Deploy automatizado de aplicações

• Monitoramento inteligente

• Gestão de capacidade

• Integração com cloud

• Automação de incidentes

• Compliance automatizado

• CI/CD mainframe

---

🥚 14) Easter Eggs & Curiosidades

🥚 Python não substitui REXX — ambos coexistem

REXX domina TSO clássico
Python domina automação moderna

---

🥚 O mainframe hoje é uma das plataformas mais “open” do mundo

Suporta:

• Linux

• Containers

• Kubernetes

• Open source

• APIs modernas

• Cloud integration

---

🥚 Muitos shops usam Python silenciosamente

Porque modernização é vantagem competitiva.

---

🥚 Python no z/OS é estratégico para o futuro da plataforma

IBM aposta nisso para atrair novas gerações.

---

🏆 Conclusão — O Sysprog Moderno

👉 Não é apenas operador do sistema
👉 É arquiteto de automação
👉 Engenheiro de integração
👉 Guardião da confiabilidade

Python é a linguagem que permite isso.

IPL Simulator

 

Bellacosa Mainframe Apresenta IPL Simulator

Um Simulador Mockup que exibe mensagens em formato terminal 3270, fazendo passo a passo o IPL e outras funcionalidades do Start de um Mainframe.

Experimente e conheça as atividades de um Operator, Sysprog e SysAdmin da Stack Mainframe

SImulator em ação

https://vagnerbellacosa.github.io/LAB_IBM_IPLMainframe/

#ibm #mainframe #ipl #sysprog #sysadmin #mockup #simulator #screen #t3270

 

🧙‍♂️ REXX em Modo Jedi Avançado

Quando o script deixa de ser código e vira governo do sistema

“Todo mundo escreve REXX.
Poucos entendem o que realmente estão controlando.”

---

☕ Introdução – REXX não é uma linguagem, é uma posição de poder

No mundo distribuído, scripts automatizam tarefas.
No mainframe, REXX governa fluxos.

REXX não nasceu para competir com COBOL, PL/I ou Python.
Ele nasceu para orquestrar, colar, conectar e, quando mal usado, derrubar produção em silêncio.

Entrar no modo Jedi do REXX significa entender que:

Você não escreve REXX para resolver problemas.
Você escreve REXX para controlar o sistema que resolve problemas.

---

🧠 Capítulo 1 – ADDRESS: o sabre de luz do REXX

Se você só usa ADDRESS TSO, você ainda é um Padawan.

O verdadeiro poder começa quando você entende que ADDRESS é um roteador de autoridade:

• ADDRESS TSO → usuário

• ADDRESS ISPEXEC → interface

• ADDRESS SDSF → JES

• ADDRESS CONSOLE → operador

• ADDRESS OPERCMDS → sistema

• ADDRESS LINK / LINKMVS / LINKPGM → MVS puro

🧩 Insight Jedi

ADDRESS define quem executa.
REXX apenas decide quando.

No modo Jedi, o REXX não executa — ele coordena entidades que têm poder real.

---

📦 Capítulo 2 – Data Stack: o lado invisível da Força

Todo REXX poderoso depende do Data Stack.
Quem não domina a stack, não domina REXX.

O Data Stack é:

• STDIN/STDOUT do mainframe

• Pipe de comunicação invisível

• Fonte de 80% dos bugs silenciosos

Jedi sabe:

• Quando usar PUSH (LIFO)

• Quando usar QUEUE (FIFO)

• Quando isolar com NEWSTACK

• Quando limpar antes de sair

Stack suja = decisão errada baseada em lixo.

---

🛡️ Capítulo 3 – SYSREXX: quando o script vira operador invisível

SYSREXX não é um nome bonito.
É uma categoria mental.

SYSREXX é:

• REXX que roda sem você

• REXX que toma decisões

• REXX que opera produção

Ele normalmente envolve:

• Batch

• SDSF

• GETMSG

• CART

• OPERCMDS

• CONSOLE

Verdade desconfortável

SYSREXX mal governado é mais perigoso que operador humano.

Operador erra uma vez.
SYSREXX erra toda vez, automaticamente.

---

🔐 Capítulo 4 – OPERCMDS: o Dark Side do REXX

OPERCMDS é o ponto onde engenharia vira ética.

Quem usa OPERCMDS sem checklist:

• Não está automatizando

• Está delegando autoridade sem supervisão

Regras Jedi absolutas

• OPERCMDS sem log é proibido

• OPERCMDS sem GETMSG é irresponsável

• OPERCMDS em loop é incidente garantido

• OPERCMDS sem RACF é suicídio institucional

Não é sobre conseguir executar o comando.
É sobre merecer executar o comando.

---

🔗 Capítulo 5 – LINK / LINKMVS / LINKPGM: REXX como maestro

Aqui o REXX para de ser script e vira maestro de orquestra.

• COBOL executa regra

• ASM executa velocidade

• Utilities executam trabalho pesado

• REXX coordena tudo

No modo Jedi:

• REXX não faz I/O pesado

• REXX não replica lógica de negócio

• REXX chama quem sabe fazer melhor

REXX não substitui COBOL.
REXX governa COBOL.

---

🧪 Capítulo 6 – Checklists: a diferença entre mestre e herói morto

Padawans confiam no código.
Jedis confiam em processo.

Checklist não é burocracia.
Checklist é memória externa para evitar arrogância técnica.

Checklist Jedi inclui:

• Segurança RACF

• Data Stack limpa

• RC validado

• Mensagem interpretada

• Log auditável

• Rollback possível

REXX sem checklist é talento desperdiçado.

---

⚖️ Capítulo 7 – REXX vs Shell vs Python: maturidade arquitetural

O Jedi não briga por linguagem.

Ele sabe que:

• REXX governa o core

• Shell conecta ao Unix

• Python conecta ao futuro

A arquitetura madura combina, não substitui.

Trocar REXX por Python no core do z/OS não é modernização.
É amnésia técnica.

---

🧠 Capítulo 8 – A mentalidade Jedi REXX

Um Jedi REXX:

• Pensa em risco antes de pensar em sintaxe

• Prefere previsibilidade a elegância

• Documenta o óbvio

• Desconfia de RC=0

• Nunca confia em automação sem auditoria

Frase final (para colar na parede do data center):

REXX não é uma linguagem de programação.
É uma linguagem de responsabilidade.

---

☕ Epílogo – Um Café no Bellacosa Mainframe

O REXX Jedi não aparece no LinkedIn dizendo que “automatizou tudo”.
Ele aparece quando nada quebrou.

E no mainframe, isso é o maior elogio possível.

 

🔐 Guia de Segurança – OPERCMDS em REXX Mainframe

OPERCMDS não é automação.
OPERCMDS é autoridade delegada de operador.

---

1️⃣ O que é OPERCMDS (sem romantizar)

OPERCMDS permite que um REXX envie comandos de operador MVS/JES como se estivesse no console do sistema.

Exemplos do que isso significa na prática:

• Cancelar jobs

• Parar subsistemas

• Exibir status do sistema

• Interferir diretamente na produção

📌 Conclusão:
Quem controla OPERCMDS, controla o sistema.

---

2️⃣ Princípio Zero: quando NÃO usar OPERCMDS

❌ Não use OPERCMDS se:

• O comando pode ser feito via SDSF read-only

• É apenas consulta de status

• É um script de usuário final

• Não existe logging/auditoria

👉 OPERCMDS só entra quando não há alternativa segura.

---

3️⃣ Pré-requisitos obrigatórios de segurança

Antes de QUALQUER ADDRESS OPERCMDS:

• Autorização formal da área de segurança

• Perfil RACF específico (não genérico)

• Execução restrita (SYSREXX / batch controlado)

• Script armazenado em library protegida

• Alteração via change management

🧠 OPERCMDS sem RACF é uma bomba-relógio.

---

4️⃣ Classificação de comandos OPERCMDS

🟢 Classe 1 – Consulta (menor risco)

Exemplos:

• D A

• D J,L

• D OMVS

Regras:

• Preferir leitura

• Log obrigatório

• Nunca usar como gatilho de ação direta

---

🟡 Classe 2 – Controle (alto risco)

Exemplos:

• CANCEL jobname

• P subsystem

• S subsystem

Regras:

• Só em SYSREXX

• Validação prévia obrigatória

• RC + mensagem analisados

• Execução única (sem loop)

---

🔴 Classe 3 – Impacto sistêmico (crítico)

Exemplos:

• Z EOD

• VARY

• FORCE

📌 Regra absoluta:
REXX NÃO deve executar esses comandos automaticamente.

---

5️⃣ Checklist técnico antes do comando

Antes de executar OPERCMDS:

• O comando foi validado?

• Existe confirmação lógica (não humana)?

• O ambiente é o correto (LPAR, sistema)?

• O job alvo realmente existe?

• O comando é idempotente?

• Existe timeout / proteção contra loop?

---

6️⃣ Captura e validação de mensagens (obrigatório)

Nunca execute OPERCMDS “cego”.

Fluxo correto:

1. Executar comando

2. Capturar mensagem

3. Interpretar resposta

4. Só então decidir próxima ação

Ferramentas:

• GETMSG

• CART

• Data Stack

📌 OPERCMDS sem GETMSG é irresponsável.

---

7️⃣ Tratamento de RC e mensagens

• RC analisado imediatamente

• Mensagem validada (texto, não só RC)

• Erro gera abort controlado

• Sucesso gera log explícito

• Nenhum “continue anyway”

🥚 RC = 0 não significa sucesso operacional.

---

8️⃣ Logs e Auditoria (não negociável)

Todo OPERCMDS deve gerar:

• Quem executou

• Quando executou

• Qual comando

• Qual retorno

• Qual decisão foi tomada

Regras:

• Log em dataset protegido

• SYSOUT identificado

• Retenção definida

🧠 Sem log, não há defesa em auditoria.

---

9️⃣ Proteções obrigatórias no código

• Nunca hardcode jobnames críticos

• Nunca aceitar input direto do usuário

• Nunca rodar em loop sem limite

• Nunca executar em ambiente errado

• Nunca assumir sucesso

📌 REXX é rápido — erros também.

---

🔟 OPERCMDS em Batch vs TSO

Ambiente	Recomendação
TSO interativo	❌ Evitar
ISPF	⚠️ Só leitura
Batch controlado	✅ Recomendado
SYSREXX	✅ Ideal

---

1️⃣1️⃣ Governança e Versionamento

• Header com aviso de risco

• Versão explícita

• Responsável técnico

• Revisão periódica

• Aprovação da operação

---

1️⃣2️⃣ Frases que salvam produção

❝ OPERCMDS não falha — pessoas falham ❞
❝ Automação sem controle é incidente futuro ❞
❝ Se pode derrubar o sistema, precisa de checklist ❞

---

🧠 Conclusão – mentalidade correta

OPERCMDS não é para mostrar poder técnico.
É para reduzir risco operacional com disciplina.

 

Bellacosa Mainframe Python no Mainframe poder operacional

🔥 “Python no Mainframe NÃO é Modernização — É Poder Operacional”

🐍 Systems Programming no z/OS para quem já viu tudo (ou acha que viu)

Se você é sysprog, arquiteto ou operador veterano de IBM Z, provavelmente já ouviu:

“Vamos usar Python para modernizar o mainframe.”

Spoiler técnico: isso está errado.

Python no z/OS não serve para “modernizar”.
Serve para algo muito mais perigoso (e valioso):

💎 Aumentar drasticamente o poder operacional do sistema sem tocar nas aplicações.

---

🧠 A Verdade que Poucos Dizem

O mainframe nunca precisou ser “modernizado” em confiabilidade, throughput ou consistência.

O que precisava evoluir era:

• Automação

• Integração externa

• Observabilidade

• Velocidade operacional

• Onboarding de novos talentos

• Orquestração híbrida

👉 Python resolve exatamente isso.

Sem reescrever COBOL.
Sem migrar CICS.
Sem mexer no coração do banco.

---

🏛️ Python não substitui nada — ele governa

Historicamente:

• 🧓 JCL governa batch

• 🧓 REXX governa TSO/automação clássica

• 🧓 Utilities governam dados

• 🧓 Operators governam o sistema

Hoje:

🐍 Python pode orquestrar TODOS ao mesmo tempo.

Isso muda o jogo.

---

🐧 Onde Python realmente roda

Não é “Python no z/OS kernel”.

👉 Ele roda no USS — UNIX System Services.

Pense assim:

Aplicações críticas (COBOL, CICS, IMS)
        ↓
       z/OS
        ↓
       USS (POSIX)
        ↓
      Python

💎 É um parasita benigno extremamente poderoso.

---

🧰 O Arsenal Real: ZOAU

Sem ZOAU, Python no mainframe é só scripting Unix.

Com ZOAU, ele vira:

🧱 Sysprog automation framework

Capacidades reais:

• Manipular datasets MVS

• Submeter e monitorar jobs

• Emitir comandos de operador

• Trabalhar com load libraries

• Executar utilitários clássicos

• Integrar pipelines

👉 É basicamente um super-REXX moderno com esteróides open source.

---

🧾 Caso de Uso REAL (não de marketing)

🔥 Self-Healing Batch

Imagine:

1. Job crítico ABEND S0C7

2. Python monitora spool automaticamente

3. Detecta padrão de erro conhecido

4. Executa comando para liberar recurso

5. Submete job de restart

6. Notifica time via API corporativa

7. Registra auditoria

⏱️ Tempo humano envolvido: zero.

Nenhuma linha de COBOL alterada.

---

🖥️ Operador Virtual 24/7

Python pode emitir comandos como:

• D A,L

• D R,L

• F CICS,EMT

• VARY ONLINE

• Diagnósticos

• Consultas sistêmicas

⚠️ Claro, com RACF adequado.

👉 Você cria um operador que:

• Não dorme

• Não entra em pânico

• Não digita errado

• Não esquece procedimentos

---

🌉 O Verdadeiro Ouro: Integração Híbrida

O mundo não roda só em z/OS.

Python conecta o mainframe com:

☁️ Cloud
🌐 APIs REST
📊 Plataformas analíticas
🐧 Linux on Z
🤖 IA
📦 Microservices

💡 Pipeline clássico em bancos hoje

COBOL → Dataset → Python → JSON → Kafka/API → Analytics

Aplicação intacta.
Valor multiplicado.

---

🔤 A Armadilha Mortal: EBCDIC

Todo sysprog passa por isso.

Primeiro script Python lendo dataset:

“Por que isso parece hieróglifo alienígena?”

Bem-vindo ao choque cultural:

🧓 z/OS tradicional → EBCDIC
🌐 Mundo moderno → UTF-8

💎 Easter egg: muitos bugs de integração não são lógica — são encoding.

---

📁 Dataset ≠ Arquivo (e isso importa)

Python espera streams.

Datasets são:

• Orientados a registros

• Têm LRECL

• RECFM

• Blocos

• Semântica própria

👉 Ignorar isso gera scripts que funcionam em teste e explodem em produção.

---

🔐 Segurança: o sistema continua soberano

Python não bypassa nada.

Tudo passa por:

• RACF/SAF

• Permissões USS

• Perfis de dataset

• Autorizações operacionais

• Auditoria

💎 Isso é uma das razões pelas quais Python no mainframe é aceito em ambientes regulados.

---

🏭 Onde Python brilha de verdade

💎 Não no core transacional

COBOL continua rei do throughput massivo.

🔥 Mas em tudo ao redor:

• Deploy automatizado

• Monitoramento inteligente

• Compliance

• Orquestração

• DevOps

• Migrações

• Operações

• Integração externa

• Observabilidade

👉 Ele governa o ecossistema.

---

🥚 Fofoquice de bastidor

Muitos grandes bancos usam Python no z/OS há anos…

…e não falam publicamente.

Motivos:

• Vantagem competitiva

• Redução de custo operacional

• Aceleração de entrega

• Menos dependência de skills raras

---

🧠 O Novo Perfil de Sysprog

O sysprog moderno não é apenas:

🧰 Especialista em parâmetros e dumps

É também:

🚀 Engenheiro de automação
🌐 Arquiteto híbrido
📊 Observability engineer
🔒 Guardião da segurança operacional
🤖 Designer de sistemas autônomos

Python é a ferramenta que permite isso.

---

⚡ Conclusão Provocativa

👉 O mainframe não está ficando “mais moderno”.

👉 O resto do mundo está finalmente ficando compatível com ele.

Python é a ponte.

---

💎 Frase para guardar

“COBOL executa o negócio.
Python garante que o negócio continue executando.”

 

 

Bellacosa Mainframe e um Checklist de Auditoria Z/OS

📋 Checklist Executável de Auditoria z/OS (SMP/E + RACF)

Objetivo: permitir que o sysprog execute, colecione evidências e registre conformidade antes (e durante) uma auditoria.

---

🧭 Como usar este checklist

• Execute cada item na ordem

• Cole comandos/outputs como evidência

• Marque OK / N/A / FAIL

• Anexe decisões e aprovações quando houver

---

🔐 1) Controle de Acesso (RACF)

1.1 CSI protegido

• Evidência (exemplo):

RLIST DATASET HLQ.SMP.CSI ALL

• Esperado: UACC=NONE, ALTER restrito

1.2 Bibliotecas SMP/E protegidas

• Evidência:

RLIST DATASET HLQ.SMP.* ALL

1.3 IDs privilegiados revisados

• Evidência:

LISTUSER * SPECIAL

---

📦 2) Integridade do SMP/E (CSI)

2.1 CSI acessível e íntegro

• Evidência: job SMP/E simples (ex.: LIST)

2.2 Backup periódico do CSI

• Evidência: política / job de backup

---

🔁 3) Processo RECEIVE / APPLY / ACCEPT

3.1 RECEIVE documentado

• Evidência: output RECEIVE

3.2 APPLY CHECK executado

• Evidência:

SET BDY(TARGET).

APPLY CHECK.

3.3 APPLY aprovado e executado

• Evidência: output APPLY

3.4 ACCEPT autorizado

• Evidência: output ACCEPT + aprovação

---

🚨 4) Gestão de ++HOLD e ++ERROR

4.1 HOLDS analisados

• Evidência: cover letter / decisão

4.2 ERRORS tratados

• Evidência: APAR / mitigação

---

🧩 5) USERMOD

5.1 USERMOD identificado e justificado

• Evidência: histórico SMP/E

5.2 Plano de remoção definido

• 
  

---

🧪 6) Evidências Técnicas

6.1 Outputs arquivados

• 
  

6.2 JCL versionado

• 
  

---

🔄 7) Rollback / RESTORE

7.1 Processo RESTORE definido

• Evidência:

SET BDY(TARGET).

RESTORE.

---

🛡️ 8) Segurança e Atualizações

8.1 PTFs de segurança atualizados

• 
  

8.2 Backlog controlado

• 
  

---

🧾 9) Assinaturas e Responsáveis

• Sysprog: __________________ Data: //____

• Segurança: ________________ Data: //____

• Auditoria: ________________ Data: //____

---

🏁 Resultado Final

• 
  

Observações:

---

Checklist executável, evidenciável e auditável — estilo Bellacosa Mainframe.

Checklist executável criado com sucesso ✅

Ele já está pronto para:

• 🧪 execução técnica real (com comandos e evidências)

• 🛡️ auditoria interna e externa

• 📄 impressão / PDF

• 🎓 treinamento de sysprogs

Checklist Executável De Auditoria Z/os (smp/e + Racf)