Translate

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

terça-feira, 21 de julho de 2026

Batman, Robin e o Mainframe : Como um Desenvolvedor COBOL Entra em um IBM Z pela Primeira Vez sem Acionar o Bat-Sinal do Operador

 

Bellacosa Mainframe o mainframe na batcaverna

☕ Um Café no Bellacosa Mainframe

Batman, Robin e o Mainframe

Como um Desenvolvedor COBOL Entra em um IBM Z pela Primeira Vez sem Acionar o Bat-Sinal do Operador


Conheça o Bat-computer dos anos 1960

https://youtu.be/uTf1wuKf65w

Conteúdo

✔ O que acontece quando o operador liga o computador (IPL)

✔ O nascimento do z/OS

✔ Como JES2 acorda o Data Center

✔ Por que ninguém entra diretamente no COBOL

✔ TSO explicado como se fosse a Batcaverna

✔ O Menu Principal do ISPF

✔ O que faz cada opção

  • Option 0
  • Option 1
  • Option 2
  • Option 3
  • Option 4
  • Option 6
  • Option 7
  • Option 9
  • SDSF

A jornada completa

POWER ON

      │

      ▼

     IPL

      │

      ▼

    z/OS

      │

      ▼

    JES2

      │

      ▼

    RACF

      │

      ▼

 LOGIN

      │

      ▼

     TSO

      │

      ▼

    ISPF

      │

      ▼

EDIT COBOL

      │

      ▼

COMPILE

      │

      ▼

LINK

      │

      ▼

RUN

      │

      ▼

SDSF

      │

      ▼

OUTPUT

O Menu Principal do ISPF explicado como uma Batcaverna

Cada opção será comparada a um equipamento do Batman.

Exemplo:

Option 2 – EDIT

"É o laboratório onde Bruce Wayne modifica seus gadgets.

Aqui você modifica programas COBOL, JCL, PROC, CLIST, REXX, membros PDS, datasets inteiros.

Se Alfred fosse programador, passaria metade da vida aqui."


Comandos TSO essenciais

LISTCAT

ALLOC

FREE

PROFILE

LISTDS

DELETE

RENAME

COPY

RECEIVE

TRANSMIT

OUTTRAP

EXEC

LOGOFF

TIME

HELP

LISTA

STATUS

E dezenas de exemplos.


Editando programas

LINHAS

COLUNAS

PREFIX

A

B

C

M

MM

CC

RR

OO

DD

CUT

PASTE

UNDO

RECOVER

HEX ON

COLS

RESET

FIND

CHANGE

LOCATE

RFIND

RCHANGE


Trabalhando com datasets

PDS

PDSE

SEQ

VSAM

Como copiar

Como renomear

Como mover

Como comparar

Como fazer backup


FTP no Mainframe

FTP tradicional

IND$FILE

Download

Upload

Modo ASCII

Modo Binary

Erros comuns


O ciclo completo do desenvolvedor COBOL

Editar

Salvar

Compilar

Analisar erros

Corrigir

Recompilar

Executar

Analisar SYSOUT

Consultar SDSF

Localizar ABEND

Corrigir

Repetir


O que aparece no SDSF

ST

DA

I

O

LOG

H

JESMSGLG

JESJCL

SYSOUT

OUTPUT

Como interpretar tudo.


Fluxo completo de compilação

Editor

JCL

JES2

Initiator

Compilador COBOL

Linkedit

Load Library

Execução

Relatórios

Arquivos

DB2

CICS

MQ


Erros clássicos

S806

S0C7

S322

SB37

IEC141I

JCL ERROR

DATASET NOT FOUND

NOT AUTHORIZED

MEMBER NOT FOUND

SPACE

DISP

CATALOG

Cada um explicado com linguagem simples.


Comparações divertidas

O Operador = Alfred

O RACF = Comissário Gordon

O JES2 = Central de Rádio de Gotham

O ISPF = Batcomputador

O SDSF = Batmonitor

O COBOL = Batmóvel

O JCL = Plano do Batman

O Compilador = Lucius Fox

O CICS = Bat-Sinal

O DB2 = Arquivo da Batcaverna

O MQ = Correio do Coringa


Easter Eggs

🦇 "Alguns dizem que o primeiro operador de mainframe já conhecia Batman antes mesmo da televisão colorida."

🦇 "Todo programador acredita que seu primeiro S0C7 foi culpa do compilador."

🦇 "Existe uma lenda segundo a qual nenhum desenvolvedor encontrou um JCL perfeito na primeira compilação."

🦇 "Assim como Robin apertava o botão errado, todo iniciante já digitou LOGOFF sem querer."

🦇 "O verdadeiro vilão nunca foi o Joker. Sempre foi o SPACE=(TRK,(1,1))."


Curiosidades históricas

  • nascimento do TSO
  • surgimento do ISPF
  • evolução do SDSF
  • JES2 × JES3
  • porque o 3270 não envia caractere por caractere
  • como nasceu o PF3
  • por que existem datasets
  • por que COBOL ainda usa colunas
  • por que o mainframe continua usando telas verdes
  • o que realmente acontece durante um IPL

sexta-feira, 17 de abril de 2026

💥 Operador de CICS Não Aperta Botão: Ele Evita Caos em Milhões de Transações (E Quase Ninguém Percebe)

 

Bellacosa Mainframe descreve as atividade de um operador mainframe em CICS

💥 Operador de CICS Não Aperta Botão: Ele Evita Caos em Milhões de Transações (E Quase Ninguém Percebe)

Se você acha que o operador de mainframe só “fica olhando tela verde”… cuidado.
No universo do CICS, ele é o guardião silencioso que impede filas travadas, regiões colapsando e clientes reclamando no app do banco.

Hoje vamos abrir essa caixa-preta no estilo Bellacosa Mainframe: direto, provocativo e com aquele tempero de quem já viu CICS pegando fogo às 3 da manhã. ☕


🧠 O Papel REAL do Operador de CICS

O operador não programa… mas mantém o sistema RESPIRANDO.

Ele atua em três frentes:

🔹 1. Monitoramento contínuo

  • Região CICS ativa?
  • Transações fluindo?
  • CPU explodindo?
  • Tasks presas?

🔹 2. Intervenção rápida

  • Mata transação travada
  • Habilita/desabilita recursos
  • Responde incidentes antes do usuário perceber

🔹 3. Comunicação

  • Aciona suporte (sysprog, dev, DBA)
  • Documenta incidentes
  • Traduz problema técnico em impacto real

👉 Em resumo:
O operador não resolve tudo — mas sabe exatamente quando algo está errado.


⚙️ Comandos CICS que TODO operador deve dominar

Dentro do CICS (via terminal ou console), esses são os clássicos:

🔥 CEMT — O CANIVETE SUÍÇO

O mais importante. Se o operador souber só um… que seja esse.

Exemplos:

CEMT I TASK

→ Lista tasks ativas

CEMT I TRANS

→ Mostra transações

CEMT SET TRANS(xxxx) DISABLED

→ Desabilita transação problemática

CEMT SET FILE(nome) CLOSED

→ Fecha arquivo (VSAM/DB2 ligado)

CEMT SET TASK(xxxx) PURGE

→ Mata task travada

💡 Dica Bellacosa:
Se você usou PURGE mais de 3x no dia… tem problema estrutural.


🔥 CEDA — Definições (nível mais avançado)

CEDA I TRANS(xxxx)

→ Ver definição da transação

👉 Operador usa menos, mas precisa reconhecer.


🔥 CECS / CECI — Testes

Mais usados por dev, mas operador esperto sabe identificar uso indevido.


🖥️ Onde o SDSF entra no jogo?

Aqui começa o poder real.

O SDSF é o radar do operador.


🔍 Telas que ele MAIS usa:

🔹 ST (Status)

  • Ver address space do CICS
  • CPU, memória, status

👉 Identificar se o CICS está:

  • Loopando
  • Travado
  • Consumindo CPU absurda

🔹 DA (Display Active)

  • Tasks no z/OS
  • Ver impacto fora do CICS

🔹 LOG

  • Mensagens do sistema

👉 Aqui mora o OURO.

Exemplo:

  • AICA abends
  • DFHxxxx mensagens
  • Falhas de recurso

💡 Easter egg:
Se aparecer DFHAC2001 com frequência…
👉 Pode apostar: alguém esqueceu commit ou está em loop.


🔹 SP (Spool)

  • Logs de jobs
  • Dumps

🚨 Quando o CICS está “aberto” — o que se espera do operador?

CICS aberto = ambiente em produção, usuários ativos.

O operador precisa:

✅ 1. Garantir disponibilidade

  • Região UP
  • Transações habilitadas

✅ 2. Detectar anomalias

  • Lentidão
  • Travamentos
  • Picos

✅ 3. Agir ANTES do caos

  • Kill de tasks
  • Disable de transação problemática

✅ 4. Seguir procedimento

  • Nada de “inventar moda”
  • Produção NÃO é laboratório

🧨 Situações clássicas (vida real)

💣 Caso 1 — Loop infinito

Sintoma:

  • CPU 100%
  • Usuários travados

Ação:

CEMT I TASK
CEMT SET TASK(xxxx) PURGE

💣 Caso 2 — Arquivo travado

Sintoma:

  • Transações não respondem

Ação:

CEMT SET FILE(nome) CLOSED
CEMT SET FILE(nome) OPEN

💣 Caso 3 — Transação problemática

CEMT SET TRANS(xxxx) DISABLED

🕵️ Curiosidade raiz (história real de datacenter)

Um operador notou que o CICS estava “normal”…
Mas usuários reclamavam.

Ele fez algo simples:

CEMT I TASK

Percebeu centenas de tasks iguais.

👉 Era um bug em produção gerando loop silencioso.

Ele matou UMA task… e o problema sumiu.

💡 Moral:
Nem sempre o problema é barulhento.


🎯 Dicas nível Bellacosa (ouro puro)

🔥 Nunca saia dando PURGE sem entender
🔥 Sempre olhe o SDSF antes de agir
🔥 Aprenda a reconhecer padrões (isso separa operador de operador)
🔥 Documente TUDO
🔥 Conheça mensagens DFH (isso é superpoder)


🧩 Easter Egg técnico

Se você digitar:

CEMT I SYSTEM

Vai ver:

  • Status geral
  • Recursos
  • Saúde do CICS

👉 Pouca gente usa… mas deveria.


🚀 Conclusão

O operador de CICS não é figurante.
Ele é o primeiro firewall humano entre o sistema e o caos.

Enquanto desenvolvedores escrevem código…
👉 Ele garante que o sistema NÃO PARE.

E quando tudo está funcionando perfeitamente…










👉 Foi porque ele fez o trabalho certo — e ninguém percebeu.


quinta-feira, 26 de março de 2026

☕ O Segredo Mais Importante do z/OS Que Quase Ninguém Explica: Address Spaces & Tasks (O “Multiverso” do Mainframe)

 

Bellacosa Mainframe explorando address spaces & tasks

☕ O Segredo Mais Importante do z/OS Que Quase Ninguém Explica: Address Spaces & Tasks (O “Multiverso” do Mainframe)

🧙‍♂️ Padawan, aproxime-se.
Se você entender profundamente Address Spaces e Tasks, você atravessa a porta de entrada do mundo Sysprog. Sem isso, z/OS parece magia. Com isso, vira engenharia.

Pegue seu café. Vamos abrir o capô do mainframe. ☕


🌌 Capítulo 1 — O z/OS Não Executa Programas. Executa Universos.

Em um PC comum você pensa:

“Vou rodar um programa.”

No z/OS, o raciocínio é outro:

⭐ “Vou criar um ambiente isolado onde programas poderão existir.”

Esse ambiente é o:

🏢 Address Space

Ele contém:

  • Memória virtual privada
  • Identidade de segurança
  • Recursos
  • Estruturas de controle
  • Tasks (unidades de execução)
  • Programas rodando

👉 Tudo roda dentro de um address space.

Exceto funções internas do kernel — e isso é assunto para um Jedi Master.


🔎 Como ver o “multiverso” ao vivo

Abra o SDSF:

SDSF → DA

Cada linha é um universo independente:

  • MASTER
  • JES2
  • TCPIP
  • IBMUSER
  • CICS
  • Jobs batch
  • Processos UNIX

Um sistema real pode ter centenas.

🥚 Easter Egg #1:
O MASTER é sempre ASID 1.
Se ele cair… você tem problemas maiores do que um dump.


🔒 Capítulo 2 — O Isolamento Que Salvou o Mainframe

Cada address space tem memória privada.

Um programa em A NÃO pode acessar a memória de B.

Isso evita:

  • Corrupção entre aplicações
  • Vazamento de dados
  • Quedas sistêmicas
  • Caos total

🧠 Mas há um truque genial…

Cada espaço acha que possui toda a memória.

Sim. Toda.


🧭 Virtual Memory — A Ilusão Controlada

Dois programas podem usar o mesmo endereço:

x'2795'

E acessar memórias físicas diferentes.

Isso ocorre graças à:

⭐ DAT — Dynamic Address Translation

Virtual → Page Tables → Real Memory

👉 Daí o nome Address Space.

Cada universo tem seus próprios endereços.


🤝 Compartilhamento? Só com permissão

Quando necessário:

  • Common Storage (CSA/ECSA)
  • Cross-memory services
  • Program Call
  • Serviços autorizados

Exemplo clássico:

CICS falando com DB2.


🧵 Capítulo 3 — Dentro do Universo: Tasks

Um address space sozinho não executa nada.

Quem executa são:

🧵 Tasks (TCBs ou SRBs)

⭐ Task = menor unidade despachável

O dispatcher agenda tasks nos CPUs.


⚡ Paralelismo real

Se houver 10 CPUs → até 10 tasks executando simultaneamente.

Mas…

🥚 Easter Egg #2:
A maioria das tasks está esperando algo — não executando.

Porque sistemas corporativos são I/O-bound.


⏳ Estados típicos

🟢 Running

No CPU agora

🟡 Ready

Quer CPU, mas aguarda

🔴 Waiting

Esperando evento:

  • I/O
  • Lock
  • Resposta externa
  • Timer
  • Memória

📦 Uma task pode executar vários programas

Mas:

❗ Apenas um por vez

Exemplo COBOL clássico:

MAIN
CALL VALIDATE
CALL CALCULATE
CALL UPDATE
CALL PRINT
STOP RUN

Tudo na mesma task.


⚙️ Quer paralelismo? Crie novas tasks.

ATTACH → nova TCB

Exemplo batch paralelo:

Task A → Arquivo1
Task B → Arquivo2
Task C → Arquivo3

🐧 Padawans vindos do UNIX

Boa analogia:

z/OSUNIX
Address SpaceProcess
Task (TCB)Thread

E sim:

⭐ Cada thread USS é uma task.


👑 Capítulo 4 — A Task Raiz: RCT

Quando um address space nasce:

  1. Cria-se a Region Control Task (RCT)
  2. Outras tasks são iniciadas
  3. Programas executam nelas

Hierarquia:

Address Space
└── RCT
├── Task A
└── Task B

🥚 Easter Egg #3:
Se a RCT terminar… o address space inteiro termina.

Sem órfãos. Sem bagunça.


⚡ Capítulo 5 — O Primo Ninja: SRB

Existem dois tipos de tasks:

🧵 TCB — normal

Aplicações, batch, TSO, etc.

⚡ SRB — especial

Serviços do sistema.

Diferenças fundamentais:

TCBSRB
Pode esperarGeralmente não
Longo prazoCurto
LocalPode ser cross-memory
AplicaçõesSistema

SRBs são criados via:

SCHEDULE

Não automaticamente.


🧠 Capítulo 6 — Memória Compartilhada entre Tasks

Dentro do mesmo address space:

👉 Tasks compartilham memória.

Isso permite cooperação rápida.

Mas também risco.

Programas autorizados podem proteger áreas — aplicações comuns raramente fazem isso.


🏛️ Capítulo 7 — Como Address Spaces Nascem

Criados quando surge um workload independente:

  • IPL do sistema
  • START de serviço
  • Logon TSO
  • Job batch selecionado pelo JES
  • Processo UNIX iniciado

❌ NÃO quando:

  • Um programa começa
  • Um comando TSO é digitado
  • Uma subrotina é chamada

🥚 Easter Egg #4:
Criar address space é caro. z/OS evita fazer isso sem necessidade.


🧾 Capítulo 8 — ASCB, ASID e Jobname

Cada address space é registrado por um:

⭐ ASCB — Address Space Control Block

Contém:

  • ASID (ID interno)
  • Jobname (nome visível)
  • Ponteiros para TCBs
  • Estado
  • Dados de gerenciamento

Operador vê:

👉 JOBNAME

Sistema usa:

👉 ASID


👨‍💼 Capítulo 9 — Administração na Vida Real

Operadores controlam address spaces, não tasks.

Comandos típicos:

S TCPIP
P CICS
C JOB123
F JES2,QUIESCE

Tasks só entram em cena quando algo dá errado.


💥 Capítulo 10 — Por Que Isso Faz o Mainframe Ser o Mainframe

Essa arquitetura permite:

✔ Escalabilidade massiva
✔ Isolamento forte
✔ Alta disponibilidade
✔ Throughput absurdo
✔ Recuperação controlada
✔ Multi-tenant seguro


🏆 O Insight Jedi

🏢 Address Space = Ambiente

🧵 Task = Execução

💻 Program = Código executado

Ou, no idioma Bellacosa:

“O z/OS não roda programas.
Ele mantém universos onde programas vivem.”


☕ Missão do Padawan

Se você entendeu este artigo, já ultrapassou 80% dos iniciantes em mainframe.

O próximo passo é dominar:

  • Dispatching e WLM
  • Storage Manager
  • JES internals
  • Subsystems architecture
  • Dump analysis

💬 Último conselho

🧙‍♂️ “Quem entende Address Spaces e Tasks não apenas usa o z/OS… começa a pensar como ele.”


 

terça-feira, 17 de março de 2026

O Que Todo Programador COBOL Padawan Precisa Saber Sobre Como o Java Evoluiu de uma Linguagem Acadêmica para um dos Pilares da Computação Moderna

 

Bellacosa Mainframe e a evolucao do java

☕ Um Café no Bellacosa Mainframe

A Evolução Contínua do Java

O Que Todo Programador COBOL Padawan Precisa Saber Sobre Como o Java Evoluiu de uma Linguagem Acadêmica para um dos Pilares da Computação Moderna

"Você não está apenas aprendendo Java. Está estudando uma linguagem que, assim como o COBOL, sobreviveu às mudanças tecnológicas, reinventou-se diversas vezes e continua sendo uma das plataformas mais importantes do planeta."


Introdução

Existe uma frase muito comum no mundo da tecnologia:

"Java morreu."

Curiosamente, ela é repetida praticamente todos os anos... há mais de vinte anos.

Enquanto isso...

  • Bancos continuam utilizando Java.

  • Empresas aéreas utilizam Java.

  • Amazon utiliza Java.

  • Netflix utiliza Java.

  • Google utiliza Java.

  • IBM utiliza Java.

  • Android nasceu utilizando Java.

  • Bilhões de dispositivos executam código Java diariamente.

Parece familiar?

Quem trabalha com COBOL já ouviu exatamente a mesma história.

Há décadas anunciam a morte do COBOL.

E, décadas depois, ele continua processando trilhões de dólares diariamente.

Java e COBOL compartilham algo muito raro:

São linguagens que aprenderam a evoluir sem abandonar seu passado.

Essa talvez seja sua maior qualidade.


O nascimento do Java

Em 1991, a Sun Microsystems iniciou um projeto chamado Green Project.

O objetivo inicial não era criar uma linguagem para internet.

Era desenvolver software para eletrodomésticos inteligentes.

O líder do projeto era James Gosling.

O primeiro nome da linguagem era...

Oak

(nome inspirado em um carvalho que existia em frente ao escritório.)

Como já existia outra linguagem chamada Oak, escolheram outro nome.

Durante uma reunião, enquanto tomavam café...

Surgiu o nome:

Java

Inspirado no famoso café produzido na ilha de Java, na Indonésia.

Coincidência?

Talvez seja por isso que um Café no Bellacosa Mainframe combina tanto com Java.


O maior acerto da história

Em 1995 surgiu um slogan que mudou a computação.

Write Once, Run Anywhere

Escreva uma vez.

Execute em qualquer lugar.

Na época isso parecia impossível.

Cada sistema operacional utilizava APIs diferentes.

Java resolveu esse problema através da JVM.


Bellacosa Mainframe timeline do java

A JVM

Ao contrário do COBOL, que normalmente gera código nativo para z/OS ou outro sistema operacional, Java gera um arquivo intermediário:

Bytecode

Esse bytecode é executado pela:

Java Virtual Machine

Resultado:

Windows

Linux

Mac

IBM Z

AIX

Cloud

Containers

Tudo executa exatamente o mesmo programa.

Foi uma revolução.


Java 8 — O novo começo (Março/2014)

Muitos especialistas dizem que existem dois Java:

Antes do Java 8.

Depois do Java 8.

E existe um bom motivo para isso.

Lambdas

Antes:

Collections.sort(lista,new Comparator<Pessoa>(){...});

Depois

lista.sort((a,b)->a.nome.compareTo(b.nome));

Muito menos código.

Muito mais legibilidade.


Stream API

Antes

for
if
for
if

Depois

clientes.stream()
.filter(...)
.map(...)
.collect(...)

A programação tornou-se declarativa.


Optional

Acabou boa parte dos famosos:

NullPointerException

Date and Time API

Finalmente uma API moderna para datas.


Curiosidade

O Java 8 ainda é uma das versões mais utilizadas no mundo corporativo.

Muitas empresas migraram diretamente do Java 8 para o Java 17 ou Java 21.


Java 9 — Modularização (Setembro/2017)

Projeto:

Jigsaw

Imagine o Java como um enorme sistema COBOL.

Antes era um único monólito.

Agora tornou-se modular.

Benefícios:

  • aplicações menores

  • inicialização mais rápida

  • segurança

  • encapsulamento


JShell

Pela primeira vez o Java ganhou um REPL.

Como o TSO READY.

Você digita.

Executa.

Vê o resultado.

Sem compilar projetos inteiros.


Java 10 (Março/2018)

Poucas novidades.

Mas uma delas mudou completamente o estilo de programação.

var

Antes

HashMap<String,List<Cliente>> mapa=

Depois

var mapa=

Muito mais simples.


Dica Bellacosa

var não significa linguagem fracamente tipada.

O tipo continua existindo.

O compilador apenas o deduz.


Java 11 LTS (Setembro/2018)

Primeira versão LTS após o Java 8.

Grande parte das empresas migrou diretamente para ela.


HTTP Client

Finalmente uma API moderna.

Sem bibliotecas externas.


TLS melhorado

Mais segurança.


Garbage Collection

Novos algoritmos.


Remoção do JavaFX

Agora distribuído separadamente.


Easter Egg

A Oracle removeu diversas APIs antigas.

Muitos sistemas antigos "pararam de compilar".

Foi um grande choque para empresas.


Java 17 LTS (Setembro/2021)

Talvez a maior evolução desde o Java 8.


Records

Antes

Classe

Construtor

Getter

Setter

Equals

HashCode

ToString

Depois

record Cliente(...)

Fim.


Sealed Classes

Controle rigoroso de herança.

Muito útil para arquiteturas grandes.


Pattern Matching

Menos código.

Mais clareza.


Curiosidade

Os compiladores modernos conseguem otimizar Pattern Matching melhor do que cadeias enormes de if.


Java 21 LTS (Setembro/2023)

Aqui aconteceu algo gigantesco.


Project Loom

Virtual Threads.

Imagine um CICS.

Agora imagine milhões de transações simultâneas.

Era necessário criar milhões de Threads.

Muito caro.

Agora...

Virtual Threads.

Criadas praticamente como objetos.

Muito mais leves.


Analogia Mainframe

No z/OS existe décadas de engenharia para lidar com milhares de usuários simultaneamente.

Java começou a aproximar-se dessa eficiência.


Sequenced Collections

Coleções finalmente ganharam ordenação consistente.


Record Patterns

Mais elegância.


Foreign Function & Memory API

Interoperabilidade sem JNI tradicional.


Java 23

Versão intermediária.

Não LTS.

Seu objetivo principal foi amadurecer recursos que chegariam às versões futuras.

Isso faz parte da estratégia moderna do OpenJDK: lançar inovações em ciclos rápidos para que sejam testadas e refinadas antes de integrarem uma versão LTS.

Entre os destaques estão a continuidade do aperfeiçoamento das Virtual Threads, do Pattern Matching e das APIs em incubação relacionadas à JVM, desempenho e experiência do desenvolvedor.


Java 25 LTS (Setembro/2025)

Mais uma versão de suporte de longo prazo.

O foco esteve em:

  • maior estabilidade

  • otimizações da JVM

  • melhor gerenciamento de memória

  • reforços de segurança

  • consolidação de recursos introduzidos nas versões anteriores

Para empresas, o Java 25 representa uma excelente opção para novos projetos corporativos que buscam longevidade.


Java 26 (Março/2026)

O Java 26 dá continuidade ao ciclo semestral do OpenJDK.

Embora não seja uma versão LTS, ela demonstra o compromisso da plataforma com evolução constante.

Os temas centrais incluem:

  • evolução da JVM

  • melhorias de performance

  • otimizações do compilador JIT

  • avanços em segurança

  • preparação para futuras funcionalidades voltadas à inteligência artificial, computação em nuvem e aplicações distribuídas

Mais do que adicionar recursos isolados, o Java 26 mostra que a plataforma continua refinando sua arquitetura para os desafios da próxima década.


O que um COBOL Padawan pode aprender com Java?

Muito mais do que sintaxe.

Java ensina conceitos modernos que complementam a experiência adquirida no mainframe.

Entre eles:

  • Programação Orientada a Objetos

  • APIs REST

  • Microsserviços

  • Containers

  • Kubernetes

  • Mensageria (Kafka, MQ)

  • Programação Funcional

  • Programação Reativa

  • Virtual Threads

  • Cloud Native

Todos esses conceitos dialogam cada vez mais com ambientes IBM Z modernos.


Curiosidades

☕ O mascote Duke

O mascote oficial do Java chama-se Duke.

Foi criado ainda na Sun Microsystems e continua sendo um dos símbolos mais conhecidos da linguagem.


☕ Java e COBOL convivem

É comum encontrar sistemas onde:

COBOL
↓

CICS

↓

MQ

↓

Java

↓

REST

↓

Angular

↓

Aplicativo

As duas linguagens não competem.

Elas colaboram.


☕ IBM Z executa Java

Muita gente acredita que Java é exclusivo da nuvem.

Na realidade, a IBM investe há décadas em uma JVM altamente otimizada para o IBM Z.

O resultado é a execução de aplicações Java com excelente desempenho, aproveitando recursos avançados do hardware, como criptografia, processamento paralelo e alta disponibilidade.


☕ Java também fala com COBOL

Existem várias formas de integração:

  • CICS Transaction Gateway

  • IBM MQ

  • z/OS Connect

  • JDBC

  • Web Services

  • APIs REST

  • JNI (em cenários específicos)

Essa interoperabilidade permite modernizar aplicações sem reescrever décadas de regras de negócio.


☕ Por que existem versões LTS?

Nem toda empresa pode atualizar seus sistemas a cada seis meses.

As versões Long-Term Support (LTS) recebem suporte prolongado, correções de segurança e estabilidade, tornando-se a escolha ideal para ambientes corporativos.


☕ A cadência de lançamentos

Desde 2018, o Java segue um calendário previsível:

  • Março → versão intermediária

  • Setembro → versão intermediária ou LTS (quando aplicável)

Essa previsibilidade facilita o planejamento de atualizações em grandes organizações.


Easter Eggs

☕ Duke escondido

Diversos exemplos oficiais da Oracle possuem pequenas aparições do Duke.

É quase um "Wally" para desenvolvedores Java.


☕ Café

O logotipo do Java representa uma xícara de café.

Até hoje.

Poucas linguagens possuem uma identidade visual tão reconhecida.


☕ Java e a Ilha de Java

O nome não veio da linguagem.

Veio do café.

E o café veio da ilha indonésia.


☕ O slogan que virou realidade

"Write Once, Run Anywhere" foi alvo de muitas piadas nos anos 1990 ("Write Once, Debug Everywhere"), mas a maturidade da JVM transformou essa promessa em uma das maiores vantagens da plataforma.


Dicas do Bellacosa Mainframe

  • Aprenda conceitos, não apenas sintaxe. Um bom engenheiro entende arquitetura antes de decorar comandos.

  • Mantenha-se em versões LTS para projetos corporativos, salvo quando houver necessidade de testar novidades.

  • Explore a JVM. Entender Garbage Collection, JIT e gerenciamento de memória faz tanta diferença quanto conhecer JCL e parâmetros de execução no mainframe.

  • Experimente o JShell. É uma excelente ferramenta para aprender rapidamente novos recursos da linguagem.

  • Estude integração com IBM Z. Java e COBOL convivem muito bem quando unidos por APIs, mensageria e serviços.


Conclusão

Java não é apenas uma linguagem de programação.

É uma plataforma que evoluiu continuamente por mais de três décadas, mantendo um raro equilíbrio entre inovação e compatibilidade. Assim como o COBOL, ela demonstra que tecnologias sólidas não sobrevivem por acaso: sobrevivem porque conseguem se adaptar às mudanças sem perder a confiança de quem depende delas.

Para um Programador COBOL Padawan, conhecer a evolução do Java significa ampliar sua visão sobre arquitetura de software, computação distribuída e modernização de sistemas. O futuro das aplicações corporativas não será construído escolhendo entre COBOL ou Java, mas integrando o melhor dos dois mundos.

No Bellacosa Mainframe, costumamos dizer que um bom profissional não segue modismos: ele compreende a história da tecnologia para tomar melhores decisões no presente. A trajetória do Java, da versão 8 à 26, é um excelente exemplo de como inovação contínua e estabilidade podem caminhar lado a lado — uma lição que vale tanto para a JVM quanto para o universo do IBM Z. Afinal, as linguagens passam por transformações, mas os princípios da boa engenharia permanecem. E é justamente essa mentalidade que transforma um Padawan em um verdadeiro Mestre da Computação.

terça-feira, 11 de novembro de 2025

🔥💣 SYSREXX: O “KUBERNETES INVISÍVEL” DO z/OS QUE JÁ EXISTIA ANTES DA NUVEM 💣🔥

 

Bellacosa Mainframe SysRexx o REXX como framework

🔥💣 SYSREXX: O “KUBERNETES INVISÍVEL” DO z/OS QUE JÁ EXISTIA ANTES DA NUVEM 💣🔥

Quando o REXX deixou de ser linguagem… e virou infraestrutura operacional do Mainframe ☕🚀

“Enquanto o mundo moderno descobria automação… o z/OS já executava automações sistêmicas em paralelo dentro do próprio núcleo operacional.”

Existe um momento na história do Mainframe em que o REXX sofre uma mutação absurda.

Ele deixa de ser:

  • simples linguagem de scripts
  • ferramenta TSO
  • automação de rotina

…e se transforma em algo muito maior:

☕ Uma camada operacional inteligente do próprio z/OS.

Esse momento atende pelo nome de:

🔥 SYSREXX (System REXX)

E pouca gente percebe a profundidade arquitetural disso.

Porque o SYSREXX não é “apenas REXX fora do TSO”.

💣 O SYSREXX é praticamente:

  • um runtime operacional
  • um engine de automação
  • um orquestrador interno
  • um mini middleware sistêmico
  • um framework de operações embutido no z/OS

Décadas antes:

  • Kubernetes
  • PowerShell
  • DevOps
  • ChatOps
  • AIOps
  • Infrastructure as Code

…o Mainframe já possuía:

automação operacional orientada a eventos usando REXX.


☕ O DIA EM QUE O REXX VIROU “PARTE DO SISTEMA”

Durante anos o REXX viveu:

  • no TSO
  • em CLISTs
  • em automações ISPF
  • em SDSF
  • em jobs batch

Mas a IBM percebeu algo:

O mundo começava a exigir:

  • integração web
  • automação rápida
  • observabilidade
  • APIs operacionais
  • gerenciamento simplificado

Então nasceu o SYSREXX.

A própria IBM define o objetivo assim:

“Required an infrastructure to support web based initiatives interacting with z/OS components.”

Traduzindo para Bellacosa Mainframe:

🔥 “Precisávamos transformar o z/OS em algo programável em tempo real.”


🚀 O SYSREXX É UM SUBSYSTEM DE VERDADE

Esse é o primeiro choque.

Muita gente imagina:

“Ah… deve ser só um EXEC diferente.”

Negativo.

O SYSREXX nasce como:

AXR

Uma Started Task real.

Ela:

  • cria workers
  • controla filas
  • gerencia requests
  • dispara ambientes TSO
  • administra automações
  • integra console e APIs

💣 Isso é arquitetura enterprise raiz.


☕ O QUE O SYSREXX FAZ?

Ele permite executar EXECs:

  • fora do TSO
  • fora do Batch
  • via console
  • via APIs
  • via programas assembler
  • via automação sistêmica

Ou seja:

🔥 O REXX vira uma API operacional do z/OS.


🧠 O DETALHE QUE QUASE NINGUÉM PERCEBE

O SYSREXX introduziu no Mainframe conceitos que hoje chamamos de:

  • workers
  • queues
  • asynchronous execution
  • runtime isolation
  • service execution
  • orchestration

Observe a arquitetura lógica IBM:

  • Listener
  • Queue Control
  • Worker Tasks
  • Async Processing
  • Console Interface
  • AXREXX API

💣 Isso parece arquitetura cloud moderna.

Só que no z/OS.


🔥 TSO=NO — O MODO “TURBO”

Aqui mora uma engenharia genial.

O modo:

TSO=NO

executa EXECs:

  • em ambiente compartilhado
  • alta velocidade
  • baixo overhead
  • até 64 workers paralelos

Resultado:

performance absurda.


☕ O PREÇO DA VELOCIDADE

Mas existe um detalhe importante.

A IBM alerta:

“Recommend no Data Set Allocation here.”

Porque:

  • o ambiente é compartilhado
  • workers são reutilizados
  • problemas podem contaminar outros EXECs

🔥 Isso é extremamente importante.


🚨 O “VAZAMENTO FANTASMA”

Imagine um EXEC mal escrito:

/* REXX */

"ALLOC FI(TEST) DA('SYS1.PARMLIB') SHR"
EXIT

Sem FREE.

O dataset:

  • continua alocado
  • influencia EXECs futuros
  • causa bugs aleatórios

💣 Bem-vindo ao terror operacional invisível do SYSREXX.


🚀 TSO=YES — O MODO “ISOLADO”

Aqui o EXEC ganha:

  • Address Space própria
  • ambiente TSO dinâmico
  • acesso a datasets
  • comandos POSIX
  • SYSCALL
  • maior segurança

Mas…

☕ não é um TSO “completo”.

E aqui muitos profissionais caem.


🔥 A ARMADILHA DO TSO DINÂMICO

O SYSREXX usa:

IKJTSOEV

para criar:

Dynamic TSO Environment

Mas o TMP tradicional NÃO existe completamente.

Resultado:

  • alguns comandos falham
  • alguns control blocks inexistem
  • alguns LOADs explodem

E então aparece o famoso:

ABEND306

💣 O Mainframe lembrando:

“Você entrou numa área avançada.”


☕ AXRCMD — O SUPERPODER ABSURDO

Aqui o SYSREXX vira praticamente um operador automatizado.

Exemplo:

/* REXX */

Rc = AXRCMD("D IPLINFO",OUT.,5)

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

🔥 O EXEC:

  • envia comando MVS
  • captura resposta
  • processa output
  • toma decisões

Isso muda completamente o jogo.


🚀 O MAINFRAME COMEÇA A “SE OBSERVAR”

Com AXRCMD você pode:

  • monitorar jobs
  • verificar DASD
  • analisar JES2
  • inspecionar XCF
  • observar STORAGE
  • controlar devices
  • automatizar recovery

Tudo em REXX.


☕ EXEMPLO “OPS AI RAIZ”

Imagine isso:

/* REXX */

Signal On Failure

Rc = AXRCMD("D A,L",OUT.,5)

If Rc <> 0 Then Do
Call AXRWTO "ERRO NO DISPLAY"
Exit 8
End

Do I = 1 To OUT.0

If Pos("CICS",OUT.I) > 0 Then Do

If Pos("NOT ACTIVE",OUT.I) > 0 Then Do

Call AXRWTO "CICS FORA DO AR"

Rc2 = AXRCMD("S CICSPROD",MSG.,10)

Call AXRWTO "RESTART AUTOMATICO EXECUTADO"

End
End
End

Exit 0

Failure:
Call AXRWTO "ABEND NO MONITOR"
Exit 16

💣 Isso é praticamente:

  • observabilidade
  • detecção automática
  • autorecovery
  • AIOps

Só usando SYSREXX.


🔥 AXRMLWTO — O “PAINEL OPERACIONAL”

Essa função é maravilhosa.

Ela permite gerar:

  • WTOs multiline
  • outputs organizados
  • blocos formatados
  • relatórios operacionais

Exemplo:

Connect='IPLCHK'

Call AXRMLWTO '=== STATUS IPL ===','Connect','L'

Do I = 1 To OUT.0
Call AXRMLWTO OUT.I,'Connect','D'
End

Call AXRMLWTO '=== FIM ===','Connect','DE'

O console vira praticamente:

uma dashboard textual enterprise.


☕ O SYSREXX É O “POWERSHELL DO MAINFRAME”

Mas com diferenças importantes:

  • mais integrado
  • mais seguro
  • mais próximo do kernel
  • mais operacional
  • absurdamente eficiente

🔥 O EASTER EGG MAIS INSANO

Pouca gente percebe…

Mas o SYSREXX já fazia:

ChatOps operacional

Muito antes do Slack existir.

Observe:

@1STATUS
@1CICSCHK
@1JES2INFO
@1DASDMON

💣 Isso é praticamente:

  • slash commands
  • bots operacionais
  • automação conversacional

No console do z/OS.

Décadas atrás.


☕ O MAINFRAME JÁ FAZIA “SERVERLESS”

Pense nisso.

Você:

  • dispara EXEC
  • runtime nasce
  • executa lógica
  • devolve resultado
  • encerra worker

🔥 Isso lembra o quê?

Lambda.
Functions.
Serverless.

Só que:

no Mainframe.


🚀 O SYSREXX COMO “DEVOPS INVISÍVEL”

Hoje falam:

  • DevOps
  • GitOps
  • AIOps
  • Platform Engineering

Mas o z/OS já possuía:

  • automação sistêmica
  • workers paralelos
  • filas
  • eventos
  • execução assíncrona
  • automação declarativa

O SYSREXX era isso.


☕ O DETALHE MAIS BONITO DO SYSREXX

A IBM poderia ter criado:

  • linguagem nova
  • engine nova
  • framework novo

Mas ela escolheu:

REXX.

Porque:

  • simples
  • legível
  • humana
  • rápida
  • poderosa

🔥 CONCLUSÃO

O SYSREXX é uma das tecnologias mais subestimadas do z/OS.

Ele transformou o REXX em:

  • infraestrutura
  • automação enterprise
  • motor operacional
  • plataforma sistêmica
  • interface programável do Mainframe

E talvez o mais impressionante:

☕ O mundo moderno reinventou muitos conceitos que o Mainframe já dominava há décadas.

Enquanto muita gente ainda estava aprendendo a automatizar servidores distribuídos…

🔥 o z/OS já executava automações inteligentes dentro do próprio coração do sistema operacional. 🔥

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

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

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

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