Translate

Mostrar mensagens com a etiqueta zOSAdmin. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta zOSAdmin. Mostrar todas as mensagens

terça-feira, 29 de julho de 2025

Os Principais Aplicativos do z/OS: Um Guia para padawans.

 

Bellacosa Mainframe apresenta os principais softwares no z/OS

Os Principais Aplicativos do z/OS: Um Guia para padawans.

4,424 followers

Salve jovem padawan, inspirado em meu Quiz sobre Z/OS para iniciantes, resolvei dar uma ajudinha com mais material de apoio, este artigo tem como objetivo apresentar com um pouco mais de rigor tecnico. O famoso Z/OS o sistema operacional dos sistemas operacionais. O conjunto de softwares, que tornam realidade toda a velocidade da Alta Plataforma, cuidado da segurança, continuedade e potência no processamento de Dados para milhões de pessoas ao redor do Globo.

No coração do mainframe IBM, o z/OS é o sistema operacional que sustenta algumas das infraestruturas mais críticas do mundo — bancos, governos, seguradoras, grandes varejistas, entre outros. Mas o que faz do z/OS um sistema tão poderoso não é apenas sua robustez, mas também o conjunto de aplicativos e subsistemas que o compõem.

Neste artigo, caro padawan compartilho os principais aplicativos do z/OS, com breves resumos, exemplos de uso e curiosidades históricas. Existem outros softwares, porém não serão listados neste artigo.


1. JES2 – Job Entry Subsystem

Resumo: Gerencia o fluxo de jobs batch no sistema.

História: Desde os primórdios do MVS, os subsistemas JES foram criados para organizar a fila de trabalhos enviados por JCL.

Exemplo: Quando você submete um job (SUBMIT JOB01.JCL), o JES2 é quem o recepciona, enfileira, imprime, armazena no spool e direciona para execução.

📝 Curiosidade: O JES3, com controle centralizado, foi amplamente usado por grandes data centers até ser descontinuado no z/OS 2.5 (RIP).


2. ISPF – Interactive System Productivity Facility

Resumo: Interface interativa em tela 3270 para navegação, edição e gerenciamento de arquivos. Para o terror da geração icones, cores e musiquinhas o 3270, normalmente se apresenta em Tela Negra com Caracteres verdes ao melhor estilo Matrix.

História: Criado nos anos 60 para melhorar a produtividade dos programadores. É uma IDE em linha de comando, apesar de nos atuais Emuladores 3270 é possivel usar o Mouse para apontar e clicar, servindo de atalho as ferramentas.

Exemplo: Editar um programa COBOL, visualizar um dataset, compilar, submeter jobs – tudo via ISPF Panels.

🎨 Curiosidade: Muitos o consideram o “Windows” do mainframe – mas em modo texto! Em grande verdade o Windows foi inspirado no MVS, na epoca do MS-DOS e seus comandos de linha.


3. TSO/E – Time Sharing Option / Extensions

Resumo: Permite aos usuários interagir com o z/OS em sessões simultâneas.

História: Introduzido como uma maneira de utilizar o sistema em modo interativo, antes apenas possível por batch e cartões perfurados. Graças a criação do Disco Rigido pela IBM e dos arquivos VSAM, permitindo muito mais navegabilidade no Sistema.

Exemplo: Digitar comandos como LISTC, ALLOCATE, RENAME diretamente no prompt do TSO.


4. SDSF – System Display and Search Facility

Resumo: Interface para visualizar spool de jobs, status, saída, logs, mensagens do sistema. Trabalha em conjunto com o JES2, numa anologia simples, pense no avô do Gerenciador de Tarefas do Windows na versão linha de comando.

Exemplo: Acompanhar a execução de um job, ler mensagens do JES, verificar uso de CPU.

🔍 Curiosidade: SDSF é indispensável para qualquer operador ou programador acompanhar jobs em tempo real, uso de memoria, programas em execução na CPU e espaço nos discos.


5. RACF – Resource Access Control Facility

Resumo: Sistema de controle de segurança de usuários, recursos e permissões no z/OS. O grande Xeriff do Mainframe, graças a ele, nossos dados são protegidos contra ataques Hacker.

História: Criado nos anos 60 como resposta à necessidade de controle mais rígido de acesso e evitar visitantes não convidados.

Exemplo: Definir que o usuário SILVA pode acessar o dataset FINA.APRIL.REPORT apenas em leitura.

🔐 Curiosidade: O RACF virou sinônimo de segurança em Mainframe, mesmo havendo outros como ACF2 e Top Secret.


6. DB2 for z/OS

Resumo: Banco de dados relacional robusto e altamente escalável.

História: Lançado em 1983, foi um dos primeiros RDBMS comerciais baseados no modelo relacional de Codd.

Exemplo: Aplicações bancárias acessam dados de contas via SQL: SELECT * FROM CLIENTES WHERE ID=123.

💡 Curiosidade: DB2 é um dos pilares da modernização no z/OS, integrando com APIs REST, Java e analytics. Existem versões para todas as outras plataformas, considerado o REI dos Bancos de Dados Relacionais.


7. CICS – Customer Information Control System

Resumo: Gerenciador de transações online de altíssima performance (OLTP).

História: Criado em 1969 para atender bancos e seguradoras, usa arquivos VSAM como apoio fundamental.

Exemplo: Sistema bancário de agência que consulta saldo ou realiza transferências em tempo real.

Curiosidade: É possível expor uma transação COBOL/CICS como um Web Service REST hoje com CICS TS.


8. VTAM – Virtual Telecommunications Access Method

Resumo: Controla a comunicação entre terminais 3270 e aplicações Mainframe.

História: Introduzido com o advento da computação distribuída e redes SNA.

Exemplo: Gerencia a sessão entre uma tela TN3270 no PC e o CICS no z/OS.


9. OMVS / USS – Unix System Services

Resumo: Permite ao z/OS executar comandos, scripts e programas no estilo Unix (POSIX).

História: Introduzido nos anos 90 com o objetivo de integrar melhor o mundo z/OS ao Unix/Linux.

Exemplo: Executar um shell script ou instalar um Java SDK no Mainframe.

🐧 Curiosidade: Muitos sistemas modernos (Node.js, Python, Git, z/OSMF) funcionam dentro do OMVS!


10. z/OSMF – z/OS Management Facility

Resumo: Interface web para administração, provisionamento e automação do z/OS.

História: Criado pela IBM para facilitar a administração gráfica e moderna do z/OS.

Exemplo: Criar workflows, administrar usuários RACF, provisionar ambientes CICS via navegador.

🌐 Curiosidade: Você pode administrar z/OS pelo navegador, inclusive integrando com Jenkins!


11. JCL – Job Control Language

Resumo: Linguagem que comanda a execução de programas no z/OS.

Exemplo: Um job típico chama um programa COBOL, redireciona entrada/saída, especifica parâmetros. Este exemplo é bem simples, sendo apenas ilustrativo, em breve apresentarei um Quiz sobre JCL e mais detalhes da sua escrita e funcionamento.

Explicando por cima, ele é um cartão job com apenas um Step, chamando um arquivo de entrada para leitura e gerando SYSOUT no Spool do SDSF.

//JOB1    JOB 1,'EXEMPLO',
//        CLASS=A,MSGCLASS=X
//STEP1   EXEC PGM=PROGCALC
//INFILE  DD   DSN=ENTRADA.DADOS,DISP=SHR
//OUTFILE DD   SYSOUT=*
//SYSOUT  DD   *

📜 Curiosidade: Embora antigo, o JCL é insubstituível no controle fino do ambiente, uma linguagem de programação interpreta, em formato de script, presente nos Mainframe desde a sua liberação no seculo passado.


Conclusão

Por ora, caro padawan chegamos ao final de nossa jornada para conhecer o z/OS, guarde isso na memoria, o ZOS não é apenas um "sistema operacional", mas um ecossistema robusto, onde cada aplicativo tem um papel essencial no processamento de dados em larga escala, com segurança, performance e confiabilidade.

Para o analista mainframe, conhecer esses aplicativos é como conhecer o seu campo de batalha. E quanto mais você entende como esses componentes se relacionam, mais se destaca como profissional.

Espero ter ajudado e caso surjam duvidas, não tenha receio, pergunte nos comentarios, que vamos enriquecendo este artigo. Ele é um trabalho em curso, vez por outro, revisarei e acrescentarei emendas e mais detalhes.

segunda-feira, 23 de janeiro de 2023

🧠 SMP/E: O Orquestrador Invisível do z/OS — O Dev COBOL Não Vê… Mas Depende Todos os Dias

 


Bellacosa Mainframe apresente o orquestrador de atualizaçõs no Z/OS

🧠 SMP/E: O Orquestrador Invisível do z/OS — O Dev COBOL Não Vê… Mas Depende Todos os Dias

Se você é um dev COBOL sênior, já escreveu milhares de linhas, já enfrentou abends misteriosos, já discutiu copybook em reunião… mas existe uma verdade silenciosa:

Quem realmente controla o seu ambiente não é o COBOL. É o SMP/E.

E se você nunca mergulhou fundo nele… você está dirigindo um Ferrari com os olhos vendados.


🏛️ Origem: Quando instalar software virou um problema sério

Nos primórdios do mainframe:

  • Software era entregue em fitas físicas
  • Instalação era manual
  • Dependências? 😅 Boa sorte…

Foi aí que a IBM criou o:

👉 SMP (System Modification Program)
E depois evoluiu para o SMP/E (Extended)

💥 O objetivo:

Transformar o caos de instalação em um processo controlado, auditável e reversível


🧩 O mundo real: o que você usa… sem perceber

Você roda:

  • COBOL ✔
  • CICS ✔
  • DB2 ✔
  • REXX ✔
  • ISPF ✔

Mas tudo isso chegou ao sistema via:

👉 SMP/E


📦 O conceito mais importante: SYSMOD

Tudo no SMP/E gira em torno de:

👉 SYSMOD (System Modification)

Tipos:

  • FMID → Produto base
  • PTF → Fix oficial
  • APAR → Fix temporário
  • USERMOD → Customização

💥 Regra de ouro:

Se modifica algo → depende de um FMID


🧠 Easter Egg #1 (prova e vida real)

APAR não é elemento — é SYSMOD
(essa derruba muita gente 😄)


🧱 Elementos: o que realmente vai pro sistema

Um SYSMOD é composto por:

  • MOD → executável
  • SRC → source
  • MAC → macro
  • JAR / zFS → mundo UNIX
  • Panels / REXX / CLIST

💥 Tradução COBOL:

Seu load module veio de um MOD, que veio de um SRC, controlado pelo SMP/E


📀 RELFILE: o “pacote de entrega”

Antes do APPLY, existe o pacote:

👉 RELFILE

Hoje:

  • Download via internet

Antes:

  • 📼 Fita magnética

Dentro dele:

  • MCS (metadados)
  • Elementos do software

⚙️ O pipeline sagrado do SMP/E

Aqui está o coração da operação:

RECEIVE → APPLY → ACCEPT

📥 RECEIVE (entrada no sistema)

  • Carrega RELFILE
  • Atualiza GLOBAL ZONE
  • Prepara staging

👉 Ainda não instala nada


⚙️ APPLY (instalação real)

  • Copia elementos para TARGET LIBRARIES
  • Atualiza TARGET ZONE

👉 Agora o software roda


✅ ACCEPT (consolidação)

  • Copia para DISTRIBUTION LIBRARIES
  • Atualiza DLIB ZONE

👉 Vira baseline


🧠 Easter Egg #2 (nível prova)

RECEIVE → GLOBAL
APPLY → TARGET
ACCEPT → DLIB

Se decorar isso → passa em qualquer prova 😎


🗃️ CSI: o cérebro do SMP/E

👉 CSI (Consolidated Software Inventory)

Baseado em VSAM KSDS

Guarda:

  • Versões
  • Dependências
  • Elementos
  • Histórico

💥 É o “CMDB raiz” do mainframe


🧠 Curiosidade forte

Um CSI pode controlar vários produtos ao mesmo tempo


⚠️ O pulo do gato: dependências

Antes de instalar:

  • Prerequisite (PRE) → precisa antes
  • Corequisite (CO) → precisa junto

👉 SMP/E valida automaticamente


🧠 Easter Egg #3

SMP/E pode:

✔ Instalar dependências
✔ Cancelar instalação

Mas nunca:

❌ Instalar versão mais antiga sobre nova
❌ Desinstalar arbitrariamente


🔥 Insight de produção

SMP/E não é apt-get
SMP/E é governança


🏭 Exemplo real (modo Bellacosa)

Você precisa aplicar um fix no CICS:

  1. Recebe PTF
  2. SMP/E verifica:
    • FMID correto
    • PRE/CO ok
  3. APPLY:
    • Atualiza loadlibs
  4. Testa em ambiente
  5. ACCEPT:
    • Consolida baseline

⚠️ Prática avançada (ouro)

👉 Nunca dê ACCEPT imediatamente

Porque:

  • APPLY = reversível
  • ACCEPT = compromisso

🧠 Easter Egg #4 (experiência real)

Erro clássico:

GIMxxxx

👉 80% das vezes:

  • FMID errado
  • Dependência faltando
  • CSI inconsistente

🔌 Interfaces SMP/E

Você pode usar:

  • ISPF
  • Batch (JCL)
  • API

💥 Sim — SMP/E pode ser automatizado


🚀 SMP/E no mundo DevOps

Tradução moderna:

DevOpsSMP/E
PipelineRECEIVE/APPLY/ACCEPT
DeployAPPLY
PromoteACCEPT
ArtifactRELFILE

🧠 Easter Egg final

O mainframe já fazia DevOps… antes de ser moda.


🎯 Conclusão

Se você escreve COBOL e ignora SMP/E:

👉 Você domina a aplicação
👉 Mas não domina o ambiente


🔥 Frase final (pra guardar)

COBOL escreve o sistema.
SMP/E garante que ele exista.