☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta TSO ISPF. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta TSO ISPF. Mostrar todas as mensagens

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.

sexta-feira, 31 de outubro de 2025

☕💣 “ACHAVA QUE REXX ERA SÓ SCRIPT?” — 10 COISAS QUE TODO PROGRAMADOR COBOL JUNIOR PADAWAN DESCOBRE TARDE DEMAIS NO MAINFRAME IBM Z 💣☕

 

Bellacosa Mainframe apresenta dicas sobre REXX Mainframe que todo padawan deve dominar

☕💣 “ACHAVA QUE REXX ERA SÓ SCRIPT?” — 10 COISAS QUE TODO PROGRAMADOR COBOL JUNIOR PADAWAN DESCOBRE TARDE DEMAIS NO MAINFRAME IBM Z 💣☕

Bellacosa Mainframe apresenta 10 coisas que um dev padawan deve saber e dominar


☕💣 PARA ENCERRAR UMA JORNADA DE REXX — COISAS QUE UM PROGRAMADOR COBOL JUNIOR PADAWAN DEVE SABER 💣☕

Depois de brincar com variáveis, loops, PARSE, EXECIO, ISPF, SDSF e automações mágicas do z/OS… chega o momento em que o jovem Padawan COBOL percebe uma verdade brutal do Mainframe:

👉 REXX não é “só uma linguagem de script”.
REXX é praticamente o “canivete suíço espiritual” do ambiente IBM Z.

É aquela ferramenta que o sysprog usa às 3h da manhã.
É o remendo elegante que salva um batch.
É o automóvel improvisado do operador.
É o cola-tudo universal do TSO/ISPF.

E quando você aprende REXX… você deixa de ser apenas alguém que “programa COBOL”.

Você começa a conversar com o sistema operacional. ☕


🔥 1. O COBOL PROCESSA NEGÓCIO. O REXX CONTROLA O UNIVERSO AO REDOR.

COBOL:

  • calcula folha

  • processa contas

  • fecha banco

  • gera extrato

REXX:

  • automatiza deploy

  • chama utilitários

  • cria menus ISPF

  • lê datasets

  • manipula spool

  • dispara comandos

  • conversa com DB2

  • conversa com CICS

  • conversa com SDSF

  • conversa com JES2

O COBOL é o motor da empresa.

O REXX é o técnico escondido atrás do painel elétrico. ☕


🔥 2. TODO MAINFRAMEIRO SÊNIOR SABE REXX

Isso é quase lei não escrita do IBM Z.

Você pode encontrar:

  • especialista em CICS

  • DBA DB2

  • operador

  • sysprog

  • storage admin

  • automação

  • segurança RACF

Todos usando REXX em algum momento.

Porque chega uma hora em que:
👉 fazer manualmente vira sofrimento.

E o REXX resolve.


🔥 3. O VERDADEIRO PODER ESTÁ NA INTEGRAÇÃO

O Padawan normalmente pensa:

“REXX é linguagem.”

O veterano pensa:

“REXX é integração.”

REXX conversa com:

  • ISPF

  • SDSF

  • TSO

  • JES2

  • DB2

  • CICS

  • USS

  • MQ

  • arquivos

  • datasets

  • comandos do sistema

É por isso que ele continua vivo há décadas.


🔥 4. O REXX ENSINA VOCÊ A ENTENDER O z/OS

Muita gente aprende COBOL sem entender:

  • alocação

  • datasets

  • spool

  • comandos

  • ISPF

  • utilities

  • catalog

  • LPAR

  • JES

Mas quando começa a automatizar com REXX…

☠️ você é obrigado a entender como o ambiente REAL funciona.

E isso acelera absurdamente sua evolução.


🔥 5. REXX É O “PYTHON DO MAINFRAME” ANTES DO PYTHON EXISTIR

Muito antes da moda DevOps…

o mainframe já tinha:

  • automação

  • scripts

  • parsing

  • manipulação textual

  • integração

  • produtividade

E o nome disso era:
☕ REXX.

Inclusive muita ideia moderna já existia ali:

  • scripting rápido

  • administração automatizada

  • wrappers

  • glue language

  • interfaces operacionais


🔥 6. O PROGRAMADOR JÚNIOR DESCOBRE O TRAUMA DO EXECIO

Todo mundo passa por isso.

Primeiro contato:

"EXECIO * DISKR ARQ (STEM DADOS."

Depois:

  • RC estranho

  • dataset vazio

  • stem quebrado

  • linha truncada

  • allocation faltando

E então nasce o verdadeiro mainframeiro.

Porque EXECIO não ensina apenas I/O.

EXECIO ensina humildade. ☕💀


🔥 7. PARSE É UMA DAS COISAS MAIS GENIAIS DO REXX

Quando o Padawan entende:

PARSE VAR LINHA NOME 1 SOBRENOME

a mente explode.

Porque o REXX foi criado para:

  • texto

  • comandos

  • produtividade

  • interpretação dinâmica

O PARSE parece simples…
mas é uma arma absurdamente poderosa.


🔥 8. REXX MOSTRA QUE O MAINFRAME NÃO É “ENGESSADO”

Muita gente de fora imagina:

“Mainframe é rígido.”

Aí o cara vê:

  • menus ISPF customizados

  • automações

  • painéis

  • ferramentas internas

  • monitoramentos

  • integrações

Tudo feito em REXX.

E percebe:
☕ o IBM Z é MUITO mais flexível do que parece.


🔥 9. TODO AMBIENTE TEM “O REXX LENDÁRIO”

Sempre existe.

Aquele EXEC antigo:

  • sem documentação

  • cheio de LABEL

  • cheio de PARSE

  • com 9 mil linhas

  • ninguém sabe quem criou

  • resolve tudo

  • ninguém tem coragem de apagar

O famoso:

“Se mexer nisso o banco para.”

☠️ patrimônio histórico do datacenter.


🔥 10. APRENDER REXX MUDA SUA VISÃO DE CARREIRA

O júnior COBOL pensa em:

  • programa

  • compile

  • JCL

  • output

O cara que aprende REXX começa a enxergar:

  • automação

  • produtividade

  • operação

  • observabilidade

  • tooling

  • administração

  • integração corporativa

E isso aproxima você:

  • do sysprog

  • do operador

  • do DBA

  • da infraestrutura

  • da arquitetura

Você deixa de ver só o programa.

Você começa a enxergar o ecossistema inteiro.


☕ A GRANDE VERDADE FINAL DO MAINFRAME

O REXX ensina algo muito importante:

👉 Mainframe não é só linguagem.
👉 Mainframe é ambiente.
👉 É integração.
👉 É operação.
👉 É automação.
👉 É disciplina.
👉 É convivência com sistemas gigantescos.

E quando o Padawan entende isso…

ele deixa de ser apenas “programador COBOL”.

☕💣 Ele começa lentamente a virar um verdadeiro Mainframeiro. 💣☕


sexta-feira, 24 de outubro de 2025

☕🔥💣 IMS SYSTEM PROGRAMMER: O LADO BRUTAL DO MAINFRAME QUE SEGURA O MUNDO EM PÉ

 

Bellacosa Mainframe e o IMS System Programmer

☕🔥💣 IMS SYSTEM PROGRAMMER: O LADO BRUTAL DO MAINFRAME QUE SEGURA O MUNDO EM PÉ

O que realmente faz um especialista IMS na IBM — e por que poucos conseguem dominar esse universo

Quando alguém escuta:

“IMS System Programmer”

muita gente imagina apenas:

  • instalar software

  • rodar jobs

  • olhar logs

😄

Mas a realidade é MUITO mais pesada.

Na prática, um especialista IMS trabalha literalmente no coração operacional do sistema financeiro mundial.

Porque quando:

  • ATM para

  • autorização de cartão falha

  • telecom cai

  • fila IMS trava

  • Shared Queue degrada

  • DBRC perde sincronismo

o problema não é “apenas TI”.

💣 O impacto pode custar milhões em minutos.

E é exatamente aí que entra o profissional IMS.


🚀 Instalar, Atualizar e Manter IMS com SMP/E

Essa é uma das tarefas mais clássicas — e perigosas — do mundo z/OS.

O:

SMP/E

(System Modification Program Extended)

é o sistema responsável por instalar e manter software no mainframe IBM.

No mundo distribuído você baixa instalador.

No mainframe você trabalha com:

  • FMID

  • HOLDDATA

  • APPLY

  • ACCEPT

  • CSI

  • zones

Ou seja:

engenharia cirúrgica de software corporativo.


☠️ O Terror do APPLY CHECK

Veteranos conhecem o ritual:

SET BDY(TGT1).
APPLY CHECK.

E então começa a tensão.

Porque um PUT errado pode:

💣 quebrar IMS
💣 afetar CICS
💣 impactar DB2
💣 gerar incompatibilidades de SYSPLEX

SMP/E não é apenas “instalação”.

É controle absoluto de manutenção em ambiente crítico.


🌳 Configurar IMS Transaction Manager

Aqui começa o verdadeiro mundo IMS.

O:

IMS TM

(Transaction Manager)

é o cérebro transacional do ambiente.

Ele controla:

  • mensagens

  • filas

  • transações

  • scheduling

  • regiões online

  • comunicação terminal/programa

Quando alguém faz:

💳 pagamento
🏧 saque
📱 consulta saldo

há grandes chances de um IMS TM estar trabalhando por trás.


⚡ IMS Shared Queue — O Monstro do Paralelismo

O Shared Queue foi criado para ambientes gigantescos.

Ele permite que múltiplos IMS compartilhem:

  • filas

  • mensagens

  • workload

em ambiente SYSPLEX.

Isso traz:

✅ escalabilidade
✅ failover
✅ balanceamento
✅ alta disponibilidade

Mas também traz:

😄 pesadelos operacionais.

Porque quando Shared Queue degrada…

o caos pode ficar lindo.


🧠 Common Service Layer — A Cola do Ecossistema

O:

CSL

(Common Service Layer)

é a camada que integra diversos componentes IMS modernos.

Ela fornece:

  • Operations Manager

  • Structured Call Interface

  • Resource Manager

Sem CSL, ambientes modernos IMS praticamente não existem mais.

É ele quem permite gerenciamento mais centralizado e inteligente.


🔥 DBRC — O Guardião da Integridade

Se existe uma entidade sagrada no IMS…

ela se chama:

DBRC

(Database Recovery Control)

O DBRC controla:

  • recovery

  • logs

  • image copy

  • autorização de banco

  • integridade operacional

Ele sabe:

✅ quais logs existem
✅ quais backups são válidos
✅ qual banco pode abrir
✅ quais datasets estão consistentes

Sem DBRC:

💣 recovery vira inferno.


☕ Easter Egg Mainframe

Veteranos dizem:

“No dia que o RECON quebra…
o DBA envelhece 10 anos.”

😄

E honestamente?

Não é exagero.


🌐 IMS Connect — O Portal Entre Mundos

Hoje o IMS conversa com:

  • APIs REST

  • Java

  • JSON

  • mobile banking

  • cloud híbrida

E quem faz muita dessa ponte é o:

IMS Connect

Ele permite integração TCP/IP moderna com o velho mundo DL/I.

Ou seja:

📱 aplicativo no celular
→ API REST
→ IMS Connect
→ IMS TM
→ COBOL
→ DL/I

Cyberpunk corporativo puro.


📊 Monitorar IMS com RMF e SMF

No mundo distribuído muita gente olha dashboard bonito.

No mainframe…

o profissional IMS olha:

  • SMF

  • RMF

  • throughput

  • EXCP

  • CPU

  • enqueue

  • response time

Porque aqui performance é religião.


🚀 SMF — O DNA do z/OS

O:

SMF

(System Management Facility)

registra praticamente tudo.

É o “gravador de caixa preta” do mainframe.

Você consegue analisar:

  • uso CPU

  • transações

  • I/O

  • locks

  • workload

  • comportamento do IMS


⚡ RMF — O Olho da Performance

O:

RMF

(Resource Measurement Facility)

mede:

  • CPU

  • canais

  • memória

  • coupling facility

  • workload

Num ambiente IMS gigantesco, RMF é praticamente um estetoscópio do sistema.


💣 Analisar Abends e Problemas Complexos

Aqui mora a parte mais brutal da profissão.

Porque quando aparece:

U0777
S0C4
DFSxxxx
ABEND878

o especialista IMS entra em modo guerra.

Ele precisa analisar:

  • dumps

  • logs

  • traces

  • control blocks

  • storage overlays

  • waits

  • contention

Muitas vezes sob pressão absurda.


🌳 Alta Disponibilidade — Onde o IMS Brilha

IMS foi criado para:

missão crítica contínua.

Então arquiteturas IMS modernas usam:

  • SYSPLEX

  • Shared Queue

  • Coupling Facility

  • XRF

  • Fast Path

  • HALDB

para entregar:

✅ uptime gigantesco
✅ failover rápido
✅ workload sharing
✅ resiliência extrema


🚀 Disaster Recovery — O Dia do Juízo Final

Todo ambiente sério IMS possui:

DR TEST

Porque eventualmente:

  • data center cai

  • storage falha

  • rede quebra

  • região inteira desaparece

E o IMS precisa sobreviver.

O time testa:

  • recovery

  • restart

  • log apply

  • DBRC

  • reconnect

  • queue rebuild

Tudo sob cronômetro.


⚔️ O Arsenal Obrigatório do Profissional IMS


🟦 JCL

O idioma operacional do z/OS.

Sem JCL você literalmente não entra no jogo.


🟩 TSO/ISPF

O cockpit do operador mainframe.


🟨 JES2

Gerencia jobs, spool e execução batch.


🟪 REXX

O canivete suíço do mainframe.

Automação.

Monitoramento.

Operação.

Recovery.


🟥 SYSPLEX

O conceito que permite múltiplos z/OS trabalharem como um único sistema gigante.

Fundamental para IMS moderno.


☕ O Grande Segredo do Mundo IMS

O mercado moderno adora falar sobre:

  • cloud

  • microservices

  • kubernetes

  • serverless

Mas existe um detalhe curioso:

Boa parte das transações financeiras globais ainda depende de profissionais que dominam:

  • IMS

  • DL/I

  • DBRC

  • Shared Queue

  • SYSPLEX

  • SMP/E

Tecnologias criadas décadas atrás…

mas ainda absurdamente eficientes.


🚀 O Último Bastião da Engenharia Hardcore

Talvez seja isso que torne o universo IMS tão fascinante.

Ele não foi construído para ser bonito.

Foi construído para:

  • sobreviver

  • escalar

  • performar

  • resistir

E enquanto muita tecnologia moderna luta para manter estabilidade básica…

o velho IMS continua processando bilhões de transações silenciosamente.

Como um dinossauro mecânico escondido no subsolo do sistema financeiro mundial.


terça-feira, 21 de outubro de 2025

SCHEDULING: A Verdade Assustadora Sobre a Migração de CA-7, Control-M, ESP, Jobtrac e Zeke para IBM Z Workload Scheduler no IBM z17

 

Bellacosa Mainframe e a migração de scheduling mainframe

☕💣🚨 PADAWAN, NINGUÉM SABE COMO O BATCH FUNCIONA!

A Verdade Assustadora Sobre a Migração de CA-7, Control-M, ESP, Jobtrac e Zeke para IBM Z Workload Scheduler no IBM z17

Existe uma frase que todo profissional experiente de Mainframe já ouviu pelo menos uma vez na vida:

"Não mexe nisso porque ninguém sabe exatamente como funciona."

Normalmente ela aparece durante uma reunião de mudança.

Alguém aponta para um job.

Outro aponta para um scheduler.

Um terceiro pergunta:

— Quem criou isso?

Silêncio.

— Quem mantém isso?

Mais silêncio.

— O que acontece se parar?

Todos ficam nervosos.

Bem-vindo ao mundo real dos schedulers corporativos.

Durante décadas, empresas construíram verdadeiras cidades invisíveis dentro de ferramentas como CA-7, Control-M, ESP, Jobtrac, OPC, OPCESA, IWS, Zeke e Zebb.

Milhares de jobs.

Milhões de execuções.

Bilhões de dólares movimentados.

E, em muitos casos, sem documentação adequada.

Agora imagine o desafio de migrar tudo isso para IBM Z Workload Scheduler (IWS), rodando sobre um moderno IBM z17.

Parece simples?

Não é.

Na realidade, essa é uma das operações mais delicadas que podem acontecer dentro de um ambiente IBM Z.

E existe um motivo muito simples para isso:

O scheduler não é apenas uma ferramenta.

Ele é a memória operacional da empresa.


O Scheduler É o Maestro Invisível

Muita gente acredita que o Mainframe gira em torno de COBOL.

Outros dizem que o coração do ambiente é o DB2.

Há quem defenda o CICS.

Todos estão parcialmente certos.

Mas existe uma verdade que poucos percebem.

Quem coordena tudo é o scheduler.

Imagine uma orquestra.

Os instrumentos são:

  • COBOL

  • PL/I

  • Natural

  • Easytrieve

  • SAS

  • DB2

  • IMS

Os músicos são:

  • Operadores

  • Analistas

  • Desenvolvedores

  • Sysprogs

Mas o maestro é o scheduler.

Sem ele, cada instrumento toca em um momento diferente.

O resultado é caos.

É o scheduler que determina:

  • Quando um job inicia

  • Quem deve executar antes

  • Quem deve executar depois

  • Quem depende de arquivos

  • Quem depende de eventos

  • Quem depende de horários

  • Quem depende de calendários

Ele controla o fluxo invisível que movimenta bancos, seguradoras, governos, operadoras e bolsas de valores.


O Problema Que Ninguém Enxerga

Quando uma empresa anuncia:

"Vamos migrar de CA-7 para IWS."

Muitos imaginam algo parecido com:

Converter definições.

Importar schedules.

Executar testes.

Entrar em produção.

Fim.

Na prática, isso representa talvez 20% do trabalho.

Os outros 80% consistem em descobrir o que realmente está acontecendo.

Porque ao longo dos anos surgiram:

  • Exceções

  • Gambiarras

  • Automatizações locais

  • Processos esquecidos

  • Regras não documentadas

Em muitos ambientes existem jobs executando diariamente há mais de vinte anos sem que ninguém saiba exatamente por quê.

Eles simplesmente existem.

E continuam funcionando.


O Cemitério dos Funcionários Aposentados

Todo grande ambiente Mainframe possui fantasmas.

Não estamos falando de software.

Estamos falando de conhecimento.

O analista que criou a aplicação aposentou-se em 2003.

O operador que entendia o calendário fiscal saiu em 2008.

O administrador que configurou o scheduler foi embora em 2012.

Mas seus jobs continuam vivos.

Suas dependências continuam funcionando.

Suas regras continuam sendo executadas.

E ninguém sabe exatamente como.

A migração acaba funcionando como uma escavação arqueológica.

Cada schedule analisado revela decisões tomadas décadas atrás.


O Universo Oculto das Dependências

Considere uma cadeia aparentemente simples:

JOBA

JOBB

JOBC

Parece fácil.

Mas quando a equipe começa a investigar, descobre algo diferente.

JOBA gera um GDG.

JOBB processa o GDG.

JOBC só executa se o retorno do JOBB for menor que 8.

Além disso:

  • Existe um calendário especial.

  • Existe uma exceção de fechamento.

  • Existe uma regra para feriados estaduais.

  • Existe um trigger de dataset.

  • Existe um evento externo.

De repente aquilo que parecia trivial transforma-se numa rede extremamente complexa.

É exatamente nesse momento que muitas migrações falham.

O Scheduler Como Banco de Conhecimento

Um scheduler antigo acumulou durante anos:

  • Conhecimento operacional
  • Regras de negócio
  • Dependências técnicas
  • Procedimentos de recuperação

Exemplo:

JOBA

JOBB

JOBC

Parece simples.

Mas na realidade pode existir:

JOBA

JOBB

JOBC

Espera arquivo FTP

Dispara evento

Valida dataset

Executa apenas dia útil

Ignora feriados estaduais

Executa calendário especial de fechamento

Essas regras nem sempre estão documentadas.


O Legado de Cada Scheduler

Cada ferramenta possui uma filosofia própria.

E é justamente aí que mora o perigo.

CA-7

O CA-7 cresceu dentro do universo z/OS como uma poderosa plataforma baseada em requisitos e dependências.

Muitas empresas exploraram recursos avançados como:

  • Requirements

  • Dataset Triggering

  • Deadlines

  • Late Jobs

  • Forecasting

Após décadas de customizações, o ambiente torna-se praticamente uma linguagem própria.


Control-M

O Control-M trouxe uma abordagem mais moderna.

Smart Folders.

Eventos.

Variáveis.

Fluxos visuais.

Integrações distribuídas.

O desafio da migração está em reproduzir conceitos que nem sempre possuem equivalência direta dentro do IWS.


ESP

O ESP é frequentemente considerado um dos schedulers mais sofisticados do mundo Mainframe.

Sua capacidade de automação baseada em eventos é impressionante.

Mas essa mesma flexibilidade cria um problema.

Grande parte da lógica operacional pode estar escondida dentro de:

  • Macros

  • Procedures

  • Scripts

Descobrir tudo isso exige uma verdadeira investigação forense.


Jobtrac

O Jobtrac costuma esconder sua complexidade atrás de uma aparência simples.

Mas muitas vezes existem décadas de exceções acumuladas.

São justamente essas exceções que costumam quebrar durante a migração.


Zeke e Zebb

Veteranos do Mainframe conhecem bem esses nomes.

Ainda existem ambientes gigantescos executando processos críticos através deles.

Frequentemente acompanhados de:

  • CLISTs

  • REXX

  • Ferramentas locais

  • Automatizações artesanais

São ambientes extremamente poderosos, porém fortemente dependentes de conhecimento histórico.


O IBM z17 Muda o Jogo

A chegada do IBM z17 cria uma nova realidade operacional.

Mais CPU.

Mais memória.

Mais paralelismo.

Mais integração com IA.

Mais observabilidade.

Mais automação.

Porém existe um efeito curioso.

Problemas antigos tornam-se mais visíveis.

Jobs que antes eram executados de forma sequencial agora podem disputar recursos simultaneamente.

Dependências mal definidas aparecem.

Gargalos históricos tornam-se evidentes.

O z17 não cria os problemas.

Ele apenas ilumina problemas que sempre existiram.


A Descoberta de Dependências

A etapa mais importante de toda migração.

Muitos especialistas consideram essa fase mais importante do que a própria conversão.

O objetivo é responder uma pergunta simples:

"O que realmente depende do quê?"

Parece fácil.

Mas não é.


Análise Profunda de JCL

O JCL é um mapa oculto de dependências.

Um IF/THEN pode alterar completamente o fluxo operacional.

Um COND pode impedir a execução de dezenas de etapas.

Uma simples alteração de RC pode desencadear comportamentos inesperados.

Por isso a análise moderna precisa identificar:

  • EXEC

  • PROC

  • INCLUDE

  • IF/THEN/ELSE

  • COND

  • Restart Points

Tudo isso influencia diretamente a modelagem do scheduler.


O Poder dos Datasets

Datasets contam histórias.

Um arquivo criado por um job normalmente será consumido por outro.

Mapear essas relações permite construir um grafo operacional real.

Em grandes bancos encontramos:

  • Centenas de milhares de datasets

  • Milhares de GDGs

  • Dependências cruzadas

Muitas vezes o scheduler original utilizava apenas o dataset como mecanismo de sincronização.

Se isso não for identificado, a migração falha.

Dataset Flow

Mapeamento de:

//OUTFILE DD DSN=FIN.ARQ.SAIDA

para

//INFILE DD DSN=FIN.ARQ.SAIDA

Criando uma cadeia real de dependências.


GDGs

Muitas dependências estão escondidas em:

DSN=ARQ.CLIENTE(+1)

ou

DSN=ARQ.CLIENTE(0)

O scheduler antigo pode usar triggering baseado nesses datasets.


Catalog Search

Análise de:

  • ICF Catalog
  • SMS
  • GDG Bases

para descobrir relacionamentos não documentados.


O Mundo Esquecido do TSO/ISPF

Aqui mora uma das maiores armadilhas.

Muitas organizações acreditam que todos os jobs passam pelo scheduler.

Nem sempre.

Existem submissões originadas por:

  • REXX

  • CLIST

  • Painéis ISPF

  • Skeletons

  • Ferramentas internas

Às vezes um usuário executa um painel ISPF que gera JCL dinamicamente.

Esse JCL dispara outros jobs.

Que disparam outros processos.

E nada disso aparece claramente no scheduler.

É por isso que uma análise séria precisa incluir todo o ecossistema TSO/ISPF.


Engenharia Reversa do Batch

A migração moderna exige construir um mapa completo do ambiente.

Imagine visualizar:

  • 30.000 jobs

  • 50.000 dependências

  • 10.000 datasets

  • 500 calendários

Tudo conectado.

Esse mapa permite identificar:

  • Gargalos

  • Loops

  • Dependências órfãs

  • Processos redundantes

Muitas empresas descobrem pela primeira vez como seu batch realmente funciona.

Engenharia Reversa de Dependências

Ferramentas modernas constroem grafos completos.

Exemplo:

PAYROLL
├── EMPLOYEE
├── BENEFITS
├── TAX
└── REPORTS

O desafio passa a ser visualizar.

Não apenas converter.


Parallel Tracking: A Fase da Verdade

Nenhum projeto sério faz o corte diretamente.

Primeiro vem o Parallel Tracking.

O scheduler antigo continua operando.

O novo acompanha silenciosamente.

Comparando:

  • Horários

  • Dependências

  • Eventos

  • Return Codes

A cada divergência surge uma oportunidade de aprendizado.

Essa fase costuma revelar dezenas ou centenas de inconsistências que jamais haviam sido percebidas.

Comparar resultados.


Fase 1

Somente observação.

IWS simula.

Não dispara nada.


Fase 2

Shadow Execution.

IWS acompanha:

  • Start times
  • End times
  • RCs

Fase 3

Controlled Production

Parte da carga executa pelo novo scheduler.

Parte pelo antigo.


Fase 4

Cutover

Desligamento definitivo.


Validação de Schedules

Uma validação madura verifica:

Calendários

Dias úteis.

Feriados.

Fechamentos.

Ano fiscal.


Dependências

Job predecessor.

Successor.

Conditional logic.


Eventos

Arquivo recebido.

Dataset criado.

Mensagem emitida.

RC específico.


SLA

O scheduler novo deve cumprir:

  • Tempo de início
  • Tempo de término
  • Deadline 

Os Erros Clássicos

Após participar de inúmeros projetos, alguns padrões se repetem.

Job Não Dispara

Normalmente causado por dependência esquecida.

Job Dispara Antes

Calendário incorreto.

Trigger Perdido

Dataset mudou de nome.

Dependência Fantasma

Job espera algo que já não existe.

Loop Operacional

Um job espera outro.

Que espera o primeiro.

Resultado:

Nada acontece.


O Papel do Troubleshooting Moderno

No passado, investigar problemas exigia navegar por:

  • JESMSGLG

  • JESJCL

  • SYSLOG

  • SDSF

Hoje o cenário mudou.

Ferramentas modernas permitem correlacionar:

  • Eventos

  • Dependências

  • Métricas

  • Logs

  • Consumo de recursos

Tudo em tempo real.

Os incidentes mais comuns são:


Job Não Dispara

Causa:

Dependência perdida.

Exemplo:

Dataset trigger não convertido.


Job Dispara Antes da Hora

Causa:

Calendário incorreto.


Loop de Dependência

Muito comum.

Exemplo:

JOBA espera JOBB
JOBB espera JOBA

Deadlock operacional.


Dependência Fantasma

Job espera um predecessor que já não existe.

Foi removido anos atrás.

Mas continua cadastrado.


Dataset Nunca Criado

Erro clássico.

JCL correto.

Scheduler correto.

Mas o dataset trigger mudou de nome.


Observabilidade no IBM z17

O verdadeiro salto ocorre quando o IWS passa a conversar com ferramentas modernas.

OMEGAMON.

RMF.

SMF.

Instana.

IBM Z Operations Analytics.

Z APM Connect.

Agora é possível enxergar:

  • Fluxos completos

  • Tendências

  • Crescimento da janela batch

  • Jobs reincidentes

  • Processos problemáticos

Não estamos mais falando apenas de scheduling.

Estamos falando de inteligência operacional.


A Chegada da Inteligência Artificial

Talvez a transformação mais interessante dos próximos anos.

Imagine um ambiente capaz de identificar:

  • Dependências suspeitas

  • Calendários inconsistentes

  • Tendências de atraso

  • Possíveis violações de SLA

antes que o problema aconteça.

Com o z17, essa visão deixa de ser ficção.

A IA passa a atuar como um analista operacional virtual.

Monitorando milhares de eventos simultaneamente.

Detectando padrões invisíveis ao ser humano.


O Verdadeiro Objetivo da Migração

O maior erro é tratar a migração como substituição de software.

Não é.

A migração é uma oportunidade rara.

Uma oportunidade de documentar décadas de conhecimento.

De eliminar dependências obsoletas.

De corrigir erros históricos.

De modernizar processos.

De criar governança.

De preparar o ambiente para os próximos vinte anos.


Conclusão: O Scheduler Nunca Foi Apenas um Scheduler

Ao final de uma grande migração, muitas equipes chegam à mesma conclusão.

O problema nunca foi o CA-7.

Nunca foi o Control-M.

Nunca foi o ESP.

Nunca foi o Jobtrac.

Nunca foi o Zeke.

O verdadeiro desafio sempre foi compreender o ecossistema invisível que sustenta a operação.

Porque dentro de cada scheduler existe muito mais do que jobs.

Existem décadas de decisões.

Décadas de conhecimento.

Décadas de regras de negócio.

Décadas de experiência operacional.

E quando uma organização decide migrar para IBM Z Workload Scheduler em um moderno IBM z17, ela não está apenas trocando uma ferramenta.

Ela está reconstruindo o mapa que conecta toda a empresa.

E talvez essa seja a maior descoberta de todas.

O scheduler não controla apenas jobs.

Ele controla o tempo.

E, dentro de uma grande corporação, tempo é exatamente aquilo que mantém o negócio vivo.

quarta-feira, 28 de dezembro de 2022

Da Baixa Plataforma ao IBM Mainframe O Guia Definitivo para Desenvolvedores que Desejam Migrar para o IBM Z

 

Bellacosa Mainframe da baixa para a alta plataforma a jornada do padawan a stack mainframe

☕ Um Café no Bellacosa Mainframe

Da Baixa Plataforma ao IBM Mainframe

O Guia Definitivo para Desenvolvedores que Desejam Migrar para o IBM Z

Você não está voltando ao passado. Está descobrindo onde a Engenharia de Software aprendeu a nunca falhar.

Há uma pergunta que recebo praticamente todas as semanas.

"Vale a pena aprender Mainframe em 2026?"

Minha resposta continua exatamente a mesma.

Sim. E talvez hoje faça ainda mais sentido do que há dez anos.

Enquanto novas linguagens surgem todos os anos, existe uma plataforma que continua processando boa parte da economia mundial com disponibilidade próxima de 100%.

Essa plataforma é o IBM Z.

Mas este artigo não é sobre máquinas.

É sobre pessoas.

Sobre desenvolvedores que dominam Java, Python, C#, Delphi, Go, Rust, Kotlin, C++, Visual Basic e outras tecnologias e desejam entender como esse conhecimento pode abrir as portas do universo Mainframe.

Pegue um café.

Vamos conversar.


Antes de tudo: esqueça os mitos

Existe uma enorme quantidade de desinformação sobre Mainframe.

Você provavelmente já ouviu alguma destas frases:

  • "Mainframe morreu."

  • "Só existem sistemas antigos."

  • "COBOL é uma linguagem ultrapassada."

  • "Ninguém mais aprende isso."

  • "Tudo foi para a nuvem."

Na prática, basta observar quem movimenta bilhões de transações diariamente:

  • bancos;

  • seguradoras;

  • bolsas de valores;

  • companhias aéreas;

  • operadoras de cartão;

  • governos;

  • empresas de logística.

Em muitos casos, o coração desses negócios continua sendo o IBM Z.

Não porque seja antigo.

Mas porque funciona extraordinariamente bem.


Você não está trocando de profissão

Quem vem da baixa plataforma costuma imaginar que precisará começar do zero.

Não precisa.

Você continua sendo desenvolvedor.

Continua resolvendo problemas.

Continua escrevendo software.

A diferença está na prioridade.

Na baixa plataforma normalmente pensamos em:

  • experiência do usuário;

  • frameworks;

  • componentes;

  • bibliotecas;

  • deploy contínuo;

  • microsserviços.

Na alta plataforma pensamos em:

  • continuidade do negócio;

  • disponibilidade;

  • integridade dos dados;

  • desempenho previsível;

  • recuperação de falhas;

  • processamento em larga escala.

O objetivo muda.

A engenharia evolui.


O IBM Z não compete com a nuvem

Um erro comum é imaginar que Cloud e Mainframe disputam espaço.

Na realidade eles trabalham juntos.

Hoje encontramos ambientes onde:

  • APIs REST expõem programas COBOL;

  • Java executa no z/OS;

  • Linux roda dentro do IBM Z;

  • Kubernetes conversa com aplicações corporativas;

  • OpenShift integra workloads;

  • IA analisa dados produzidos pelo Mainframe;

  • Git e VS Code fazem parte do dia a dia.

O IBM Z moderno é uma plataforma integrada ao restante da arquitetura corporativa.


Esqueça a pergunta "Qual linguagem é melhor?"

Essa pergunta perde completamente o sentido no mundo corporativo.

Cada tecnologia resolve problemas diferentes.

Python resolve problemas.

Java resolve problemas.

Rust resolve problemas.

COBOL resolve problemas.

A verdadeira pergunta é:

Qual tecnologia oferece menor risco para aquele negócio?

É exatamente aí que o Mainframe se destaca.


O que realmente muda?

Muito menos do que você imagina.

Você continuará trabalhando com:

  • variáveis;

  • estruturas condicionais;

  • repetições;

  • funções;

  • módulos;

  • arquivos;

  • bancos de dados;

  • APIs;

  • mensagens.

O que muda é a forma de organizar esses componentes.


As maiores mudanças de mentalidade

Disponibilidade

Na Web um servidor pode reiniciar.

Num banco isso pode significar milhões de reais.


Performance previsível

Não basta ser rápido.

É preciso manter o mesmo desempenho durante milhões de transações.


Integridade

Cada registro possui valor financeiro.

Cada atualização precisa ser consistente.


Auditoria

Tudo precisa ser rastreável.


Segurança

Segurança deixa de ser funcionalidade.

Passa a ser requisito básico.


O ecossistema IBM Z

Aprender apenas COBOL é conhecer apenas uma pequena parte da plataforma.

Você encontrará tecnologias como:

  • COBOL

  • JCL

  • CICS

  • Db2

  • IMS

  • VSAM

  • MQ

  • RACF

  • TSO/ISPF

  • SDSF

  • JES2

  • REXX

  • z/OS

  • z/OS Connect

  • Zowe

  • Git

  • VS Code

  • OpenShift

  • Ansible

  • Java

  • Python

É um ecossistema completo.


A melhor estratégia de aprendizagem

Não tente aprender tudo ao mesmo tempo.

Minha recomendação é:

Primeira etapa

  • Conceitos do Mainframe

  • z/OS

  • Dataset

  • Batch

  • Online

Segunda etapa

  • TSO/ISPF

  • JCL

  • SDSF

Terceira etapa

  • COBOL

Quarta etapa

  • Db2

  • VSAM

Quinta etapa

  • CICS

Depois disso você poderá seguir para:

  • APIs

  • MQ

  • DevOps

  • Git

  • Zowe

  • Java

  • Python

  • IA aplicada ao IBM Z


Escolha sua linguagem de origem

Preparei uma série mostrando como cada tecnologia conversa com o universo IBM Z.

☕ Java → COBOL

https://eljefemidnightlunch.blogspot.com/2022/01/do-java-ao-cobol-no-ibm-z-um-guia-para.html

Para quem já desenvolve aplicações corporativas.


☕ Python → COBOL

https://eljefemidnightlunch.blogspot.com/2022/02/de-python-ao-cobol-no-ibm-z-voce-nao.html

Automação, produtividade e integração.


☕ C# → COBOL

https://eljefemidnightlunch.blogspot.com/2022/03/de-c-ao-cobol-no-ibm-z-voce-nao-esta.html

A ponte entre aplicações Microsoft e IBM Z.


☕ Visual Basic → COBOL

https://eljefemidnightlunch.blogspot.com/2022/04/do-visual-basic-ao-cobol-no-ibm-z-voce.html

Quem domina regras de negócio já possui uma enorme vantagem.


☕ Go → COBOL

https://eljefemidnightlunch.blogspot.com/2022/05/de-go-ao-cobol-no-ibm-z-voce-nao-esta.html

Simplicidade encontra estabilidade.


☕ Rust → COBOL

https://eljefemidnightlunch.blogspot.com/2022/06/de-rust-ao-cobol-no-ibm-z-voce-nao-esta.html

Segurança de memória aplicada aos sistemas mais críticos do mundo.


☕ C++ → COBOL

https://eljefemidnightlunch.blogspot.com/2022/07/de-c-ao-cobol-no-ibm-z-voce-nao-esta.html

Arquitetura, desempenho e controle.


☕ Kotlin → COBOL

https://eljefemidnightlunch.blogspot.com/2022/08/de-kotlin-ao-cobol-no-ibm-z-voce-nao.html

A produtividade moderna chegando aos sistemas corporativos.


☕ Delphi → COBOL

https://eljefemidnightlunch.blogspot.com/2022/09/de-delphi-ao-cobol-no-ibm-z-voce-nao.html

RAD, regras de negócio e engenharia corporativa.


Conselhos para quem está começando

✔ Não compare COBOL com Java.

✔ Não compare z/OS com Windows.

✔ Não tente aprender tudo em uma semana.

✔ Leia programas antigos.

✔ Entenda o negócio antes do código.

✔ Aprenda a usar o teclado.

✔ Estude JCL cedo.

✔ Aprenda a interpretar mensagens do sistema.

✔ Não tenha medo da tela preta.

✔ Nunca pare de estudar.


Conclusão

O IBM Z continua sendo uma das plataformas mais importantes da computação mundial.

Ele não representa o passado da tecnologia.

Representa décadas de evolução em disponibilidade, segurança, desempenho e confiabilidade.

Se você domina qualquer linguagem moderna, já possui o ingrediente mais importante: sabe resolver problemas.

Aprender Mainframe significa adicionar uma nova perspectiva à sua carreira e compreender como funcionam alguns dos sistemas mais críticos do planeta.

No Bellacosa Mainframe acreditamos que o melhor desenvolvedor não é aquele que conhece apenas uma plataforma.

É aquele que consegue transitar entre todas elas, levando consigo boas práticas, curiosidade e respeito pela engenharia de software.

 

domingo, 17 de julho de 2022

De C++ ao COBOL no IBM Z : Você Não Está Trocando de Linguagem. Está Descobrindo um Novo Conceito de Engenharia de Software.

 

Bellacosa Mainframe do c++ ao cobol no zos

☕ Um Café no Bellacosa Mainframe

De C++ ao COBOL no IBM Z

Você Não Está Trocando de Linguagem. Está Descobrindo um Novo Conceito de Engenharia de Software.

"Quem domina C++ já aprendeu a controlar memória, desempenho e arquitetura. Aprender COBOL no IBM Z significa descobrir como aplicar essa disciplina ao software que movimenta bancos, bolsas de valores, seguradoras, governos e companhias aéreas há mais de meio século."

Existe um mito que acompanha praticamente todo desenvolvedor C++ quando ouve a palavra COBOL.

"É uma linguagem antiga."

"Não tem orientação a objetos."

"Não tem templates."

"Não tem STL."

"Não tem RAII."

"Não tem ponteiros."

Curiosamente...

Nenhuma dessas características explica por que bilhões de transações financeiras continuam sendo processadas diariamente em IBM Z.

Porque o IBM Z nunca foi uma competição de linguagens.

Sempre foi uma competição de confiabilidade.

E esse é justamente o ponto onde muitos programadores C++ descobrem que já possuem muito mais em comum com o mundo Mainframe do que imaginavam.


O programador C++ já pensa como um engenheiro

Quem programa em C++ normalmente desenvolveu algumas virtudes raras.

Ele sabe que desempenho importa.

Ele entende custo de memória.

Conhece pilha (stack) e heap.

Sabe que concorrência é difícil.

Entende compilação.

Conhece linkedição.

Sabe que ABI existe.

Já ouviu falar em alignment.

Conhece cache.

Sabe otimizar algoritmos.

Entende estruturas de dados.

Aprendeu que software não é apenas escrever código.

É construir sistemas.

E adivinhe?

Essa filosofia é extremamente compatível com o IBM Z.


A maior diferença não é COBOL

A maior mudança será perceber que no Mainframe o protagonista não é a linguagem.

É o ambiente.

No Windows você pensa em:

  • aplicação

  • executável

  • DLL

  • usuário

No IBM Z você passa a pensar em:

  • Job

  • Dataset

  • Região

  • CICS

  • IMS

  • DB2

  • RACF

  • JES2

  • Workload

  • Segurança

  • Disponibilidade

Você deixa de desenvolver apenas programas.

Passa a desenvolver partes de um ecossistema gigantesco.


Bellacosa Mainframe c++ versus cobol no zos

C++ e COBOL possuem mais semelhanças do que parece

À primeira vista parecem opostos.

Mas compare.

Ambos são compilados

Não existe interpretação.

Existe compilador.

Existe otimização.

Existe geração de código objeto.

Existe linkedição.

Existe build.

Tudo isso será familiar.


Ambos valorizam desempenho

No desktop você mede milissegundos.

No Mainframe mede milhões de transações por hora.

A preocupação é a mesma.

Executar rapidamente.

Consumir poucos recursos.

Não desperdiçar CPU.


Ambos valorizam estabilidade

Em C++ um ponteiro inválido pode derrubar um processo.

No Mainframe um erro pode impedir milhões de pagamentos.

A consequência muda.

A responsabilidade também.


Ambos vivem muitos anos

Aplicações C++ frequentemente permanecem décadas.

O mesmo acontece com COBOL.

Você aprenderá rapidamente que software corporativo envelhece muito mais lentamente do que aplicações web.


Ambos exigem disciplina

C++ não perdoa descuidos.

COBOL também não.

A diferença é que os erros costumam aparecer em regras de negócio.

Não em segmentation faults.


Onde tudo muda

Agora começam as diferenças.


Memória

Em C++ você administra memória.

new

delete

smart pointers

RAII

ownership

No COBOL praticamente toda memória já está definida.

Você declara estruturas.

O runtime administra tudo.

Não existe malloc para o desenvolvedor comum.

Você passa menos tempo gerenciando memória.

E muito mais tempo modelando dados.


Dados são o centro do universo

No C++ muitos desenvolvedores começam pensando em objetos.

No COBOL começa-se pensando em registros.

Campos.

Layouts.

Arquivos.

Tabelas.

Copys.

Estruturas.

A pergunta muda.

Em vez de:

"Qual classe criar?"

Você pergunta:

"Como esse registro representa o negócio?"


Legibilidade acima de tudo

Em C++ frequentemente vemos código extremamente compacto.

Templates.

Metaprogramação.

Lambdas.

Concepts.

Operator overloading.

No COBOL o objetivo sempre foi outro.

Código que qualquer desenvolvedor consiga ler daqui vinte anos.

Você rapidamente perceberá que clareza vale ouro.


Regras de negócio

Aqui acontece uma mudança importante.

Grande parte do código COBOL não implementa algoritmos complexos.

Implementa decisões empresariais.

Calcular juros.

Validar CPF.

Fechar folha.

Liquidar títulos.

Atualizar contas.

Emitir boletos.

Processar seguros.

Calcular impostos.

É programação.

Mas profundamente ligada ao negócio.


Batch é uma mudança de mentalidade

Quem veio do Windows costuma pensar em aplicações interativas.

No Mainframe você aprende Batch.

Recebe arquivos.

Valida.

Ordena.

Consolida.

Atualiza bancos.

Gera relatórios.

Tudo cuidadosamente orquestrado.

Muitos iniciantes subestimam Batch.

Depois descobrem que ele continua sendo uma das maiores forças do IBM Z.


Online também existe

Não pense que tudo é Batch.

Você conhecerá o CICS.

Ali surgem conceitos familiares.

Sessões.

Transações.

Chamadas.

Programas.

Controle de fluxo.

Mas com disponibilidade muito maior do que normalmente encontramos em aplicações tradicionais.


Banco de Dados

Se você conhece PostgreSQL, SQL Server ou Oracle, já possui uma excelente base.

Aprender DB2 será muito mais simples.

Você encontrará:

SELECT

INSERT

UPDATE

DELETE

JOIN

CURSOR

COMMIT

ROLLBACK

Índices.

Plano de acesso.

A sintaxe muda pouco.

A engenharia por trás é impressionante.


Arquivos ainda são importantes

Enquanto muitos ambientes modernos vivem exclusivamente de bancos relacionais, o IBM Z continua dominando processamento de arquivos gigantescos.

VSAM.

Sequential Files.

GDG.

Flat Files.

Isso surpreende muitos desenvolvedores.

Mas faz sentido quando milhões de registros precisam ser processados continuamente.


Segurança não é um detalhe

Em muitos ambientes segurança aparece no fim do projeto.

No IBM Z ela nasce junto.

RACF.

Perfis.

Grupos.

Permissões.

Auditoria.

Controle de acesso.

Tudo extremamente integrado.


A melhor trilha para um programador C++

Se eu estivesse orientando um excelente desenvolvedor C++, faria exatamente este caminho.


Etapa 1

Não aprenda COBOL primeiro.

Aprenda IBM Z.

Entenda:

  • o que é um Mainframe

  • por que existe

  • quais problemas resolve

  • disponibilidade

  • redundância

  • processamento de missão crítica

Sem isso COBOL parecerá apenas uma linguagem antiga.


Etapa 2

Aprenda z/OS

Entenda:

  • Dataset

  • PDS

  • PDSE

  • Sequential

  • VSAM

  • Catalog

  • Volume

  • Job

  • Step

Esses conceitos aparecerão diariamente.


Etapa 3

Aprenda TSO/ISPF

Aprenda a navegar.

Editar.

Compilar.

Executar.

Comparar arquivos.

Pesquisar membros.

Como um programador Linux aprende Bash.


Etapa 4

Aprenda JCL

Esse é provavelmente o maior choque.

JCL não é linguagem de programação.

É descrição de execução.

Quem entende JCL entende o Mainframe.


Etapa 5

Agora sim...

COBOL.

Comece apenas com:

IDENTIFICATION DIVISION

DATA DIVISION

WORKING-STORAGE

PROCEDURE DIVISION

IF

PERFORM

EVALUATE

READ

WRITE

MOVE

COMPUTE

Nada mais.


Etapa 6

Arquivos

Aprenda:

Sequential

VSAM

KSDS

ESDS

READ

WRITE

START

REWRITE

DELETE


Etapa 7

SQL

COBOL + DB2.

Aqui você descobrirá onde grande parte dos sistemas corporativos realmente vivem.


Etapa 8

CICS

Aprenda:

COMMAREA

MAP

Pseudo Conversação

LINK

XCTL

RETURN

RESP

Depois Channels e Containers.


Etapa 9

Debug

SDSF

JES2

Spool

Abends

Dump

Mensagens

SYSOUT

SYSUDUMP

SYSABOUT

Aprenda a investigar problemas.


Etapa 10

Modernização

Somente depois disso avance para:

REST

JSON

XML

z/OS Connect

MQ

Kafka

Java

Python

OpenAPI

Git

VS Code

Zowe

Ansible

OpenShift

Porque agora você compreenderá onde essas tecnologias entram.


O que treinar diariamente

Sugiro uma rotina simples.

Segunda

Resolver pequenos exercícios COBOL.

Terça

Ler JCL.

Quarta

Executar Batch.

Quinta

SQL no DB2.

Sexta

Ler código legado.

Sábado

Refatorar programas COBOL.

Domingo

Estudar arquitetura IBM Z.

Em poucos meses você terá construído uma visão muito superior à de quem apenas decorou comandos.


O maior erro de quem vem do C++

O desenvolvedor tenta transformar COBOL em C++.

Não faça isso.

COBOL resolve outro tipo de problema.

Quanto antes aceitar isso, mais rápido aprenderá.


O maior desafio

Não será aprender comandos.

Será aprender o domínio bancário.

Seguros.

Cartões.

Folha.

Tributos.

Previdência.

Liquidação financeira.

No IBM Z, entender o negócio vale tanto quanto dominar a linguagem.


O que um programador C++ aprende com o Mainframe

Depois de algum tempo algo curioso acontece.

Você volta ao C++ diferente.

Mais disciplinado.

Mais cuidadoso.

Mais preocupado com rastreabilidade.

Mais atento à estabilidade.

Mais consciente do impacto de uma mudança.

Porque o IBM Z ensina uma lição rara.

Software não existe apenas para impressionar desenvolvedores.

Existe para manter empresas funcionando.

Existe para pagar salários.

Existe para processar aposentadorias.

Existe para autorizar cartões.

Existe para movimentar bolsas de valores.

Existe para garantir que um avião possa decolar porque milhares de reservas foram processadas corretamente.

Essa responsabilidade muda completamente a forma como enxergamos programação.


Conclusão

Se você domina C++, já possui uma base extraordinária.

Você entende algoritmos, compilação, desempenho e arquitetura. Agora chegou a hora de aprender algo que poucas universidades ensinam: como grandes organizações constroem sistemas capazes de operar 24 horas por dia, sete dias por semana, durante décadas, com confiabilidade quase absoluta.

COBOL no IBM Z não substitui o C++.

Ele complementa sua formação.

Você continuará pensando como engenheiro, mas passará a enxergar software por outra perspectiva: continuidade, governança, auditoria, integridade dos dados e estabilidade operacional.

No Bellacosa Mainframe costumo dizer que aprender IBM Z é como visitar uma usina hidrelétrica depois de anos construindo geradores portáteis.

Os dois produzem energia.

Mas em escalas completamente diferentes.

O mesmo vale para C++ e COBOL.

Você não está abandonando a programação moderna.

Está descobrindo onde muitos dos sistemas mais importantes do planeta aprenderam a nunca falhar.

E essa é uma experiência que transforma qualquer desenvolvedo

quarta-feira, 22 de junho de 2022

De Rust ao COBOL no IBM Z : Você Não Está Abandonando a Programação Moderna. Está Descobrindo Onde a Engenharia de Software Aprendeu a Nunca Falhar.

 

Bellacosa Mainframe do rust ao cobol no zos

☕ Um Café no Bellacosa Mainframe

De Rust ao COBOL no IBM Z

Você Não Está Abandonando a Programação Moderna. Está Descobrindo Onde a Engenharia de Software Aprendeu a Nunca Falhar.

"Rust ensina você a escrever programas seguros. O IBM Z ensina você a manter um país funcionando às três da manhã de uma segunda-feira."

Existe uma pergunta que aparece com frequência quando um desenvolvedor Rust descobre o universo IBM Z:

"Faz sentido aprender COBOL em pleno século XXI?"

Minha resposta costuma ser outra pergunta.

Você quer aprender apenas uma linguagem ou quer aprender como funcionam alguns dos sistemas mais confiáveis do planeta?

Porque existe uma enorme diferença entre essas duas coisas.

Quem programa em Rust normalmente já possui uma mentalidade extremamente valorizada no mundo Mainframe.

Você já aprendeu a respeitar memória.

Já aprendeu que performance importa.

Já aprendeu que concorrência não é brincadeira.

Já aprendeu que estabilidade vale mais que "funcionou na minha máquina".

Na verdade...

Você está muito mais preparado para aprender COBOL do que imagina.

Só precisa trocar algumas lentes.


O maior erro

Muita gente tenta comparar:

Rust × COBOL

Essa comparação é injusta.

Seria como comparar:

  • um bisturi

  • uma usina hidrelétrica

Os dois resolvem problemas.

Mas vivem em mundos completamente diferentes.

Rust nasceu para produzir software extremamente seguro.

COBOL nasceu para processar negócios.

O IBM Z nasceu para garantir que esses negócios nunca parem.

Quando entendemos isso, tudo muda.


O pensamento do desenvolvedor Rust

Quem vive em Rust normalmente pensa em:

  • ownership

  • borrowing

  • lifetimes

  • Result

  • Option

  • Traits

  • Enums

  • Pattern Matching

  • Zero Cost Abstractions

  • Async

  • Tokio

  • Cargo

  • Crates

  • módulos

  • performance

  • segurança

É uma linguagem construída para impedir erros antes mesmo da compilação.

Isso muda completamente a forma de desenvolver.


Bellacosa Mainframe rust versus cobol no zos

O pensamento do desenvolvedor COBOL

Já o programador COBOL pensa em coisas diferentes.

Ele pensa em:

  • regras de negócio

  • consistência

  • auditoria

  • precisão decimal

  • processamento em lote

  • processamento online

  • disponibilidade

  • rastreabilidade

  • recuperação

  • confiabilidade

Observe uma curiosidade.

Rust protege memória.

COBOL protege dinheiro.

Ambos protegem algo extremamente importante.


O choque inicial

O primeiro contato costuma causar estranheza.

O desenvolvedor Rust abre um programa COBOL e pensa:

"Cadê as funções?"

"Cadê os módulos?"

"Cadê os generics?"

"Cadê os traits?"

"Cadê o Cargo?"

É normal.

Porque COBOL foi criado em outra época.

Mas existe um detalhe interessante.

As versões modernas do Enterprise COBOL evoluíram bastante.

Hoje encontramos:

  • variáveis locais

  • recursão

  • XML

  • JSON

  • UTF-8

  • chamadas para Java

  • interoperabilidade com C

  • otimizações sofisticadas

  • integração com APIs REST através do ecossistema IBM Z

Não é o COBOL dos anos 70.


O que você precisa desaprender

Talvez a mudança mais importante seja esta.

No mundo Rust pensamos muito em estruturas de dados.

No mundo Mainframe pensamos primeiro em processos de negócio.

A pergunta deixa de ser:

"Como armazeno isso?"

e passa a ser:

"Como um banco liquida milhões de operações sem perder um centavo?"

É outro tipo de engenharia.


O que continua igual

Mais do que muita gente imagina.

Organização

Rust organiza código.

COBOL também.

Você terá:

  • programas

  • subprogramas

  • copybooks

  • bibliotecas

  • interfaces

A ideia continua sendo dividir responsabilidades.


Legibilidade

Rust valoriza código limpo.

COBOL também.

Aliás...

COBOL talvez seja uma das linguagens mais próximas da linguagem humana.

IF SALDO > LIMITE
    PERFORM BLOQUEAR-CONTA
END-IF

Mesmo quem nunca programou consegue entender.


Modularização

Rust:

mod

COBOL:

CALL

Em ambos os casos você evita duplicação.


Testes

Rust possui uma cultura fantástica de testes.

Leve isso para o Mainframe.

Hoje existem ferramentas como:

  • zUnit

  • COBOL Unit Test

  • COBOL Check

  • integração com Jenkins

  • GitHub Actions

  • GitLab CI

  • Azure DevOps

Você pode continuar praticando TDD.


Performance

Rust busca eficiência.

IBM Z vive disso.

Só que existe uma diferença.

Rust normalmente otimiza microssegundos.

IBM Z otimiza milhões de transações simultâneas.

É outra escala.


O que muda completamente

Agora começam as novidades.


Você deixa de pensar apenas em programas

No Mainframe, um programa nunca vive sozinho.

Ele conversa com um enorme ecossistema.

Você conhecerá:

  • JCL

  • JES2

  • TSO

  • ISPF

  • SDSF

  • RACF

  • CICS

  • Db2

  • VSAM

  • MQ

  • z/OS

Tudo faz parte do mesmo universo.


O sistema operacional é diferente

Windows e Linux nasceram para computadores relativamente independentes.

O z/OS nasceu para um computador compartilhado por milhares de pessoas ao mesmo tempo.

Cada detalhe foi pensado para isso.

É um paradigma completamente diferente.


Batch não é coisa antiga

Essa talvez seja a maior surpresa.

Muitos imaginam que Batch significa tecnologia ultrapassada.

Na verdade...

Batch significa processamento massivo.

Imagine:

  • fechar cartões de crédito

  • calcular juros

  • atualizar milhões de contas

  • gerar extratos

  • enviar PIX agendados

  • consolidar posições financeiras

Tudo isso continua acontecendo diariamente.

E continua extremamente eficiente.


CICS muda sua visão

Depois você conhecerá CICS.

E entenderá que um terminal 3270 pode responder milhares de usuários com latência impressionante.

Sem navegador.

Sem JavaScript.

Sem frameworks gigantescos.

Apenas engenharia.


O que estudar primeiro

Aqui vejo muitos alunos errando.

Eles começam por CICS.

Ou Db2.

Ou IMS.

Não faça isso.

Existe uma ordem muito melhor.


Etapa 1 — Aprenda COBOL puro

Domine:

  • IDENTIFICATION DIVISION

  • ENVIRONMENT DIVISION

  • DATA DIVISION

  • PROCEDURE DIVISION

Depois pratique:

  • IF

  • EVALUATE

  • PERFORM

  • SEARCH

  • OCCURS

  • INDEX

  • tabelas

  • arquivos sequenciais

Escreva muitos programas pequenos.


Etapa 2 — Entenda dados

Rust trabalha muito com estruturas.

No Mainframe você precisa dominar layouts.

Aprenda:

  • PIC

  • COMP

  • COMP-3

  • DISPLAY

  • REDEFINES

  • OCCURS

  • COPYBOOKS

Essa é uma das partes mais importantes.


Etapa 3 — Aprenda JCL

Não existe desenvolvimento Mainframe sem JCL.

Aprenda:

  • JOB

  • EXEC

  • DD

  • PROC

  • COND

  • IF/THEN

  • SORT

  • IDCAMS

  • IEBGENER

Pense no JCL como um orquestrador.


Etapa 4 — TSO e ISPF

Domine o ambiente.

Aprenda:

  • editar

  • compilar

  • navegar datasets

  • membros

  • utilitários

  • SDSF

Isso aumenta muito sua produtividade.


Etapa 5 — Arquivos

Estude:

  • Sequential

  • VSAM KSDS

  • ESDS

  • RRDS

Entenda quando usar cada um.


Etapa 6 — Db2

Agora sim.

Aprenda:

  • SQL

  • Embedded SQL

  • Cursor

  • Commit

  • Rollback

Quem conhece Rust provavelmente já trabalhou com bancos relacionais.

A adaptação será tranquila.


Etapa 7 — CICS

Somente depois.

Aprenda:

  • COMMAREA

  • Channels

  • Containers

  • BMS

  • Transações

  • Program Control


Etapa 8 — Segurança

Conheça RACF.

Entenda:

  • usuários

  • grupos

  • permissões

  • datasets

  • recursos

Segurança faz parte da arquitetura.


Etapa 9 — Observabilidade

Aprenda:

  • SDSF

  • mensagens

  • ABENDs

  • dumps

  • logs

  • SMF

Aqui você começa a pensar como um engenheiro de produção.


O que praticar diariamente

Uma hora por dia já produz resultados impressionantes.

Minha sugestão é:

Segunda

  • resolver exercícios COBOL

Terça

  • ler JCL

Quarta

  • manipular arquivos

Quinta

  • SQL no Db2

Sexta

  • estudar arquitetura IBM Z

Sábado

  • criar pequenos projetos

Domingo

  • revisar tudo

Consistência vale mais que intensidade.


Habilidades que você já possui

Como desenvolvedor Rust você provavelmente já domina:

  • Git

  • GitHub

  • VS Code

  • terminal

  • debugging

  • documentação

  • leitura de RFCs

  • APIs

  • JSON

  • testes automatizados

Continue usando tudo isso.

Hoje é perfeitamente possível editar programas COBOL no VS Code utilizando extensões modernas, Git e pipelines de integração contínua. O desenvolvimento Mainframe está cada vez mais próximo das práticas que você já conhece no ecossistema open source.


O que você deve desenvolver

Além da linguagem, treine a forma de pensar.

Aprenda a fazer perguntas como:

  • O que acontece se este programa falhar às 2h da manhã?

  • Como recuperar uma execução interrompida?

  • Como garantir que nenhuma transação seja perdida?

  • Como auditar cada alteração?

  • Como processar bilhões de registros mantendo integridade?

  • Como manter compatibilidade com programas escritos há décadas?

Essas perguntas definem um engenheiro de software para sistemas críticos.


A maior mudança de mentalidade

No universo Rust, muitas vezes o foco está em construir algo novo.

No universo IBM Z, o foco é evoluir algo que já funciona, sem interromper um serviço essencial.

É uma disciplina diferente. Você aprende a respeitar contratos, compatibilidade, governança e continuidade operacional. Descobre que inovação também significa modernizar com segurança, integrar APIs, automatizar deploys, usar Git, DevOps e observabilidade, sem colocar em risco aplicações que movimentam bilhões de reais todos os dias.


A recompensa

Depois de alguns meses, você perceberá algo curioso.

COBOL deixará de parecer uma linguagem antiga.

Você começará a enxergar padrões de engenharia extremamente maduros.

Verá programas que processam volumes gigantescos há décadas, passando por inúmeras evoluções sem perder estabilidade. Entenderá por que bancos, seguradoras, companhias aéreas e governos continuam confiando no IBM Z para suas operações mais críticas.

E, nesse momento, você descobrirá que aprender Mainframe nunca foi apenas aprender COBOL.

Foi aprender uma maneira diferente de construir software: uma maneira em que disponibilidade, integridade, desempenho, segurança e continuidade têm prioridade absoluta.

Rust continuará sendo uma excelente linguagem para escrever software moderno, rápido e seguro.

COBOL continuará sendo uma excelente linguagem para expressar regras de negócio de forma clara e confiável.

O IBM Z continuará sendo uma das plataformas mais sofisticadas já criadas para executar essas regras em escala global.

Você não está trocando um mundo pelo outro.

Está unindo dois dos maiores exemplos de engenharia de software já produzidos.

E quando um desenvolvedor Rust aprende a pensar como um engenheiro de Mainframe, ele não se torna apenas um programador mais versátil.

Ele passa a compreender como a tecnologia que mantém o mundo funcionando foi construída — e por que continua relevante, décadas depois.

Esse é o verdadeiro objetivo da jornada.

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