Translate

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

quarta-feira, 1 de julho de 2026

Java na Stack Mainframe: O Roteiro Definitivo para um Programador COBOL Padawan Entrar no Mundo Java, IA, Cloud e Modernização do IBM Z

 

Bellacosa Mainframe e o Java na Stack Mainframe

☕ Um Café no Bellacosa Mainframe

Java na Stack Mainframe: O Roteiro Definitivo para um Programador COBOL Padawan Entrar no Mundo Java, IA, Cloud e Modernização do IBM Z

Imagine que você acabou de entrar em um grande banco.

Você conhece COBOL.

Sabe fazer um PERFORM UNTIL.

Entende JCL.

Já escreveu programas para CICS.

Conhece Db2, VSAM e talvez IMS.

Mas, em uma reunião, alguém diz:

"Vamos desenvolver essa nova API em Java, publicar pelo z/OS Connect, automatizar o deploy com Ansible e integrar um agente de IA."

Você pensa:

"Será que vou precisar esquecer tudo o que aprendi em Mainframe?"

A resposta é uma das melhores notícias que um profissional IBM Z pode receber:

Não.

Na verdade, tudo o que você aprendeu continua extremamente valioso.

O Java não veio substituir o COBOL.

Ele veio conversar com ele.

Hoje, o IBM Z é uma plataforma híbrida, onde aplicações COBOL escritas há décadas convivem com microsserviços Java, APIs REST, containers, LinuxONE, automação, inteligência artificial e cloud híbrida.

Neste artigo vamos construir um roteiro completo para que um COBOL Padawan evolua para um desenvolvedor Java dentro da Stack Mainframe.


O maior mito sobre Java no Mainframe

O erro mais comum é procurar um curso chamado:

  • Java para Mainframe

  • Java para z/OS

  • Java para COBOL

antes mesmo de aprender Java.

Isso é equivalente a querer aprender CICS antes de entender COBOL.

Primeiro aprendemos a linguagem.

Depois aprendemos onde ela roda.

Essa é exatamente a recomendação feita por Ian Burnett, engenheiro da equipe de desenvolvimento do IBM CICS:

"Java continua sendo Java. Salvo quando você utiliza recursos específicos do IBM Z, o mesmo código roda em diversas plataformas."

Essa frase resume toda a filosofia da plataforma Java.


Esqueça a ideia de "Java Mainframe"

Não existe uma linguagem chamada Java Mainframe.

Existe apenas Java.

O mesmo Java roda em:

  • Windows

  • Linux

  • macOS

  • LinuxONE

  • z/OS UNIX System Services (USS)

  • OpenShift

  • Cloud

A mágica acontece graças à JVM.


O que é a JVM?

JVM significa:

Java Virtual Machine

Ela é responsável por executar o bytecode produzido pelo compilador Java.

O processo funciona assim:

Código Java (.java)

        │

      javac

        │

Bytecode (.class)

        │

        JVM

        │

Sistema Operacional

No mundo IBM Z acontece exatamente a mesma coisa.

A diferença é que existe uma JVM otimizada para o processador IBM Z.

Hoje a IBM utiliza principalmente o IBM Semeru Runtime, baseado no OpenJDK, otimizado para z/OS e LinuxONE.

Isso significa que o mesmo programa Java pode executar em:

  • LinuxONE

  • USS

  • Open Liberty

  • CICS JVM Server

  • Batch Java

sem precisar ser reescrito.

É o famoso conceito:

Write Once, Run Anywhere.


O COBOL continua vivo?

Mais vivo do que nunca.

Os maiores bancos do mundo ainda executam bilhões de linhas de COBOL.

Esses programas representam décadas de regras de negócio.

Por exemplo:

  • cálculo de juros

  • empréstimos

  • cartões

  • PIX

  • investimentos

  • seguros

  • previdência

O Java não veio substituir essas aplicações.

Ele veio criar novas formas de utilizá-las.


O legado não é o problema

Existe uma frase muito repetida no Bellacosa Mainframe:

O legado não é um peso. É um patrimônio.

Imagine um programa COBOL que calcula crédito há trinta anos.

Ele funciona.

Foi testado milhões de vezes.

Então surge um aplicativo Android.

O aplicativo não precisa reescrever a lógica.

Ele apenas precisa conversar com esse programa.

É aí que entra a modernização.


Java como ponte entre o mundo moderno e o legado

Hoje uma aplicação bancária pode seguir este fluxo:

Aplicativo Android

↓

REST API

↓

Java Spring Boot

↓

z/OS Connect

↓

CICS

↓

Programa COBOL

↓

Db2

Observe quem está no meio da conversa.

O Java.

Ele conecta o mundo digital ao legado corporativo.


O papel do z/OS Connect

O z/OS Connect EE é uma das tecnologias mais importantes da modernização IBM Z.

Sua missão é simples.

Transformar programas COBOL em APIs REST.

Imagine um programa CICS chamado:

CONSULTA_CLIENTE

Antes, somente aplicações CICS conseguiam chamá-lo.

Com o z/OS Connect:

GET

/clientes/12345

vira automaticamente:

Programa COBOL

↓

COMMAREA

↓

Resposta JSON

Sem reescrever o COBOL.

Sem alterar décadas de negócio.

Essa talvez seja a maior revolução do IBM Z nos últimos anos.


JSON substituiu a COMMAREA?

Não.

Cada um possui sua função.

Dentro do CICS continua existindo:

  • COMMAREA

  • Containers

  • Channels

Fora do Mainframe:

  • JSON

  • REST

  • OpenAPI

O z/OS Connect faz a tradução entre esses mundos.


Java conversa naturalmente com o Db2

Outro ponto importante.

O Java utiliza JDBC.

Java

↓

JDBC

↓

Db2 for z/OS

Para quem conhece SQL em COBOL, aprender JDBC costuma ser bastante natural.


LinuxONE: onde o Java brilha

Quando falamos de Java no IBM Z, é impossível não falar do LinuxONE.

O LinuxONE é uma plataforma Linux construída sobre a mesma arquitetura IBM Z.

Ele oferece:

  • alta disponibilidade

  • criptografia

  • escalabilidade

  • virtualização

  • containers

  • Kubernetes

  • OpenShift

Para aplicações Java, é um ambiente extremamente eficiente.

Muitos microsserviços modernos executam em LinuxONE enquanto continuam acessando o legado z/OS.


Open Liberty

Outro componente importante é o Open Liberty.

Ele é um servidor Java moderno, extremamente leve e compatível com Jakarta EE e MicroProfile.

Nele podemos executar:

  • APIs REST

  • aplicações corporativas

  • microsserviços

  • autenticação

  • integração

Tudo isso podendo acessar COBOL via z/OS Connect ou IBM MQ.


IBM MQ

Nem toda integração precisa ser REST.

Muitos bancos utilizam filas.

Java

↓

IBM MQ

↓

COBOL

As mensagens ficam armazenadas até serem processadas.

Isso aumenta confiabilidade e desacopla sistemas.


Ansible no mundo Mainframe

Durante muitos anos administrar Mainframe significava executar comandos manualmente.

Hoje isso mudou.

O Ansible automatiza tarefas como:

  • criação de ambientes

  • deploy

  • configuração

  • instalação

  • atualização

  • coleta de informações

  • execução de scripts

Imagine precisar atualizar cinquenta servidores.

Em vez de acessar um por um, basta executar um Playbook.

Exemplo simplificado:

- Atualizar Open Liberty
- Reiniciar serviço
- Validar aplicação

Tudo automaticamente.

No IBM Z existem coleções específicas para:

  • z/OS

  • USS

  • CICS

  • RACF

  • datasets

  • JCL

  • operações administrativas

O DevOps chegou definitivamente ao Mainframe.


Cloud no mundo Mainframe

Quando falamos em Cloud, muitas pessoas imaginam abandonar o Mainframe.

A realidade é outra.

Hoje predominam arquiteturas híbridas.

Um exemplo:

Cloud

↓

API Gateway

↓

Java

↓

z/OS Connect

↓

COBOL

Parte da aplicação roda na nuvem.

Parte continua no IBM Z.

Cada ambiente faz aquilo em que é melhor.


Inteligência Artificial no IBM Z

Outro tema que deixou de ser futuro.

Hoje encontramos IA aplicada em:

  • detecção de fraudes

  • análise de crédito

  • observabilidade

  • automação operacional

  • atendimento inteligente

  • copilotos de desenvolvimento

  • geração de código

  • documentação

  • análise de logs

Modelos como IBM Granite e watsonx podem trabalhar lado a lado com aplicações Java e COBOL.

O objetivo não é substituir o programador.

É aumentar sua produtividade.


O roteiro Bellacosa para aprender Java

Fase 1 — Pensar como programador Java

Aprenda:

  • variáveis

  • classes

  • objetos

  • métodos

  • encapsulamento

  • herança

  • interfaces

  • exceções

  • Collections

  • Generics

Ainda não pense em Mainframe.


Fase 2 — Ferramentas modernas

Aprenda:

  • Git

  • Maven

  • Gradle

  • JUnit

  • Mockito

  • VS Code

  • IntelliJ IDEA


Fase 3 — Desenvolvimento Web

Estude:

  • HTTP

  • REST

  • JSON

  • XML

  • Servlets

  • APIs


Fase 4 — Spring Boot

Aprenda a criar:

  • microsserviços

  • APIs REST

  • autenticação

  • integração com bancos de dados


Fase 5 — Java Enterprise

Conheça:

  • Open Liberty

  • Jakarta EE

  • MicroProfile


Fase 6 — Java na Stack Mainframe

Agora sim, entre no universo IBM Z:

  • JVM no z/OS

  • USS

  • LinuxONE

  • JDBC para Db2

  • IBM MQ

  • CICS JVM Server

  • JCICS

  • JZOS

  • z/OS Connect EE

  • RACF

  • Open Liberty

  • Batch Java

  • OpenShift


O maior diferencial do programador COBOL

Muitos desenvolvedores Java sabem criar APIs.

Poucos entendem regras de negócio bancárias.

Você já conhece:

  • consistência transacional

  • processamento em lote

  • auditoria

  • integridade

  • alta disponibilidade

  • segurança

Esses conhecimentos não desaparecem.

Eles tornam você um profissional muito mais completo.


Recursos para continuar estudando

Além dos fundamentos de Java, vale explorar materiais específicos sobre Java no ecossistema IBM Z.

Java no CICS

Artigos técnicos

Open Liberty

IBM Semeru Runtime

IBM z/OS Connect

LinuxONE

Automação

IA para IBM Z


Um café antes de partir...

Se existe uma mensagem que todo Padawan COBOL deve levar deste artigo, é esta:

Você não está mudando de profissão. Está ampliando sua stack.

O COBOL continua sendo o coração de milhares de sistemas críticos. O Java tornou-se a ponte que conecta esse legado ao mundo das APIs, aplicativos móveis, microsserviços, cloud híbrida e inteligência artificial. Tecnologias como z/OS Connect, LinuxONE, Open Liberty, Ansible e watsonx não substituem décadas de conhecimento acumulado; elas o potencializam.

O profissional mais disputado da próxima década não será apenas o especialista em COBOL nem apenas o especialista em Java. Será aquele capaz de unir os dois mundos, preservando a confiabilidade do legado enquanto entrega inovação com velocidade. Esse é o verdadeiro espírito da Stack Mainframe: tradição e modernização trabalhando lado a lado. E essa jornada começa aprendendo Java, mas nunca esquecendo as lições que o Mainframe ensinou.

sábado, 27 de junho de 2026

O Grande Equívoco: A Modernização Não é Sair do Mainframe

 

Bellacosa Mainframe e a modernizacao na Stack mainframe



☕ Um Café no Bellacosa Mainframe

O Grande Equívoco: A Modernização Não é Sair do Mainframe

A primeira provocação é justamente esta.

A maior parte das pessoas lê:

Modernizar COBOL → Java → Kubernetes → Cloud

Mas essa não é necessariamente a melhor resposta.

Modernizar é diferente de migrar.

Existem quatro estratégias clássicas.

1. Encapsular

Não mexe no COBOL.

Expõe APIs.

COBOL

CICS

z/OS Connect

REST

Mobile

Exemplo:

ContaCorrente.cbl

vira

GET /saldo

em minutos.


2. Refatorar

Melhora código COBOL.

COBOL 74

Enterprise COBOL 6.5

AMODE 64

JSON PARSE

XML

UTF-8

LE

Continua rodando no Z.


3. Reescrever

Maior risco.

COBOL

Java

COBOL

Go

COBOL

C#

Mas...

80% dos projetos falham.

Motivos:

regras escondidas

efeitos colaterais

batchs esquecidos

interfaces desconhecidas

JCL perdido

scheduller

CA7

Control-M

MQ

etc.


4. Replatform

Executar COBOL fora do Z.

Micro Focus

Rocket

Heirloom

Raincode

AWS Blu Age


Etapa 1 — Mainframe

A imagem mostra.

IBM Z

COBOL

DB2

CICS

JCL

Correto.

Mas faltam dezenas de peças.

IMS

MQ

VSAM

RACF

SMF

RMF

WLM

JES2

DFSMS

GDG

TSO

ISPF

SMP/E

NetView

SA zOS

e muitas outras.

Um banco médio pode ter:

50 milhões de linhas COBOL

300 mil JCL

12 mil CICS

200 TB DB2

40 anos de histórico


Bellacosa Mainframe e o mainframe no Brasil


Etapa 2 — Discovery

Talvez seja a etapa mais importante.

Porque ninguém conhece realmente o sistema.

José aposentou em 2009.

Maria saiu em 2017.

Carlos faleceu.

O conhecimento sumiu.


Descobrir significa:

inventário

mapear

catalogar

entender


Exemplo

Programa

PAGA100

CALL PAGA101

CALL PAGA102

READ VSAM001

EXEC SQL

UPDATE CLIENTE

PUT MQ

SUBMIT JCL

Só isso já gera um grafo enorme.


Ferramentas

IBM ADDI

IBM Wazi Analyze

Sonar

Understand

CAST

Manta


Etapa 3 — Regras de Negócio

Este talvez seja o maior patrimônio.

Exemplo.

IF IDADE > 65

AND TEMPO-CONTRIB > 15

AND DATA-CORTE < 20211231

MOVE 'S' TO BENEFICIO

Isso não está em documento.

Está no código.

Há empresas cujo negócio inteiro está aqui.


A Regra Oculta

Um banco descobriu:

IF CODIGO = 87

MOVE 0 TO JUROS

Perguntaram.

Por quê?

Resposta:

"Ninguém sabe."

Era uma lei de 1986.

Implementada por um programador.

Nunca documentada.


Etapa 4 — Dependency Graph

Excelente ideia.

Pouca gente faz.

Visualmente.

Programa A

Programa B

VSAM

MQ

DB2

Batch

Scheduler

API


Ferramentas modernas conseguem mostrar isso.

Parece Neo4J.

Um mapa da galáxia.


Etapa 5 — IA

A IA é promissora.

Mas ainda está longe da autonomia.

Ela consegue:

explicar COBOL

gerar documentação

resumir JCL

identificar copybooks

sugerir Java

gerar testes


Ela não consegue sozinha.

Decidir.

Esta regra bancária pode mudar?

Não sabe.


Exemplo.

COBOL

COMPUTE TAXA =
SALDO * 0.01875

IA pergunta:

Por que 1,875%?

Arquiteto responde:

Resolução BACEN 2147.

Pronto.

Conhecimento capturado.


Etapa 6 — Documentação

Hoje muitas empresas possuem.

Zero documentação.

Somente:

SYS1.PROCLIB

JCL

COBOL

Copybooks


IA pode gerar.

Markdown

Confluence

Draw.io

OpenAPI

Mermaid


Etapa 7 — Reengenharia

Imagem cita.

Java

.NET

Go

Node

Boa visão.

Mas há diferenças.

Java

Excelente.

Ecossistema corporativo.

Spring.


Go

Ótimo.

Microserviços.

Baixo consumo.


Node

Excelente APIs.

Menor adequação para batchs enormes.


.NET

Muito usado em seguradoras.


E Rust?

Começa aparecer.

Muito seguro.

Mas pouco adotado.


Contêineres

Aqui existe um mito.

Containerizar não significa melhorar.

Empacotar um sistema ruim.

Produz.

Um container ruim.


Docker resolve.

Empacotamento.

Não arquitetura.


Kubernetes

Muito poderoso.

Mas caro operacionalmente.

Exige.

SRE

Observabilidade

GitOps

Segurança


Para muitas empresas.

OpenShift.

É mais comum.


Cloud

A parte mais polêmica.

A imagem sugere.

Nuvem.

Como destino natural.

Nem sempre.


Muitos estão voltando.

Cloud Repatriation.

37Signals.

Dropbox.

Basecamp.

Bancos.


Motivos.

Custos.

Latência.

Compliance.

Egress.

Licenciamento.


Observabilidade

Excelente ponto.

Antigamente.

SMF.

RMF.

Omegamon.

Hoje.

Prometheus

Grafana

OpenTelemetry

Elastic


Imagine.

SMF 110

OpenTelemetry

Grafana

Isso já acontece.


O Papel da IA

A figura acerta em cheio aqui.

A IA não substitui.

O arquiteto.

O analista.

O especialista de negócio.

Ela atua como.

Copiloto.


Ela lê.

20 milhões linhas COBOL.

Em minutos.


Mas ela não sabe.

Que:

Cliente Ouro

é diferente de

Cliente VIP

Porque isso é semântico.

É negócio.


Minha visão sobre a frase central


A maior oportunidade tecnológica da próxima década não será abandonar o Mainframe, mas integrá-lo ao ecossistema moderno de APIs, IA, DevOps, observabilidade e computação híbrida.

O IBM Z não está desaparecendo. Está se tornando um nó de alto valor dentro de arquiteturas distribuídas, orientadas a eventos e assistidas por IA.

Acredito que estamos diante de uma das maiores ondas de transformação desde a popularização da internet comercial e da computação em nuvem, mas provavelmente ela não será uma história de "COBOL versus Java". Será uma história de preservar décadas de capital intelectual enquanto se adicionam capacidades modernas, reduzindo risco, aumentando a velocidade de entrega e mantendo a confiabilidade que fez o Mainframe sobreviver por mais de meio século. Afinal, substituir tecnologia é relativamente simples; substituir quarenta anos de conhecimento de negócio embutido em milhões de linhas de código é muito mais difícil.


Bellacosa Mainframe e os ciclos historicos na tecnologia mainframe


A história do software pode ser entendida como uma sucessão de grandes ondas tecnológicas. Nos anos 1960 surgiu a Crise do Software, quando projetos se tornavam caros, atrasados e difíceis de manter, motivando o nascimento da Engenharia de Software. A Crise do Petróleo dos anos 1970 aumentou a pressão por eficiência, impulsionando a automação bancária, industrial e governamental.

Nos anos 1980 ocorreu o movimento de downsizing, migrando parte do processamento de grandes sistemas centralizados para servidores menores e estações de trabalho. Na década de 1990 surgiu o rightsizing, buscando equilibrar custos, desempenho e confiabilidade, reconhecendo que nem tudo deveria sair do mainframe.

A popularização da Internet revolucionou os negócios, exigindo aplicações conectadas, comércio eletrônico e integração global. No final dos anos 1990, o Y2K mobilizou milhares de profissionais para corrigir sistemas legados, preservando um enorme patrimônio tecnológico e renovando plataformas críticas.

A partir dos anos 2000, a Cloud Computing trouxe elasticidade, pagamento sob demanda e novas arquiteturas distribuídas, embora também revelasse desafios de custo, governança e dependência de fornecedores. Atualmente, a onda da Inteligência Artificial acelera desenvolvimento, documentação, testes e modernização de sistemas legados. Diferentemente das revoluções anteriores, a IA não elimina o conhecimento humano: amplia a capacidade dos especialistas de compreender, preservar e evoluir décadas de regras de negócio.

domingo, 15 de março de 2026

Como um Aplicativo Moderno Conversa com um Mainframe IBM Z? Do Terminal Verde ao Smartphone.

 

Bellacosa Mainframe como um aplicativo moderno conversa com um mainframe ibm z

☕ Um Café no Bellacosa Mainframe

Como um Aplicativo Moderno Conversa com um Mainframe IBM Z?

Do Terminal Verde ao Smartphone.

O Mainframe Mudou Menos do que Você Imagina. O Mundo ao Redor Mudou Muito.

Existe uma pergunta que acompanha praticamente todo desenvolvedor que chega ao universo IBM Z:

"Se o mainframe é tão antigo, como um aplicativo Android consegue conversar com ele?"

Ou então:

"Como um site feito em HTML, CSS e JavaScript consegue consultar o saldo da minha conta que está em um programa COBOL escrito há trinta anos?"

A resposta é uma das histórias mais fascinantes da engenharia de software.

Porque, ao contrário do que muita gente imagina, o COBOL nunca aprendeu HTML.

O CICS nunca aprendeu JavaScript.

O DB2 nunca começou a falar React.

Quem evoluiu foi toda a infraestrutura em volta deles.

E essa talvez seja a maior lição que o IBM Z ensina.

Os sistemas realmente importantes não são reescritos toda vez que aparece uma tecnologia nova.

Eles aprendem novas formas de conversar.


Primeiro precisamos esquecer uma ideia errada.

Quando você abre um aplicativo do banco no Android, provavelmente imagina algo parecido com isto:

Android
    ↓
COBOL

Não.

Quase nunca.

Na realidade existem diversas camadas entre eles.

Hoje uma simples consulta de saldo pode atravessar meia dúzia de tecnologias antes de chegar ao programa COBOL.

Algo muito mais parecido com isto.

Android

↓

Internet

↓

API Gateway

↓

Servidor Java

↓

Middleware

↓

CICS

↓

Programa COBOL

↓

DB2

E cada uma dessas camadas existe por um motivo.

Nenhuma delas apareceu por acaso.


Bellacosa Mainframe fluxo teorico em 1980

Vamos voltar quarenta anos.

Imagine um banco em 1985.

Não existia internet.

Não existia smartphone.

Não existia navegador.

O usuário estava diante de um terminal 3270.

Usuário

↓

Terminal IBM 3270

↓

Controladora

↓

Mainframe

↓

CICS

↓

COBOL

O terminal era extremamente simples.

Ele praticamente desenhava caracteres na tela.

Nada de janelas.

Nada de mouse.

Nada de ícones.

Nada de JavaScript.

O CICS enviava uma tela.

O usuário digitava.

A tela inteira voltava.

O COBOL processava.

Outra tela era enviada.

Era um diálogo baseado em telas.

Hoje chamamos isso de arquitetura orientada a transações.

Na época era simplesmente computação.


Bellacosa Mainframe e o fluxo moderno 

Como funcionava o login?

O operador digitava:

Usuário

Senha

A tela era enviada inteira para o CICS.

O CICS chamava um programa COBOL.

O COBOL verificava:

  • usuário

  • senha

  • permissões

Depois consultava RACF.

Ou outro sistema de segurança.

Se estivesse tudo correto...

Outra tela aparecia.

Observe uma coisa interessante.

Mesmo naquela época já existia autenticação centralizada.

Já existia controle de acesso.

Já existia auditoria.

Muito antes da internet existir.


Bellacosa Mainframe e o fluxo teorico em 1990

Então chegou a arquitetura Cliente-Servidor.

Década de 90.

Agora surgiu o Windows.

Visual Basic.

PowerBuilder.

Delphi.

C++.

Os usuários queriam janelas bonitas.

Botões.

Menus.

Mouse.

Mas...

O COBOL continuava funcionando perfeitamente.

Então nasceu uma ideia simples.

Criar uma camada intermediária.

Windows

↓

Servidor

↓

CICS

↓

COBOL

O Windows deixou de conversar diretamente com o CICS.

Agora existia um servidor traduzindo tudo.

Era o nascimento do middleware moderno.



Depois chegou a Internet.

Essa mudou tudo.

Agora qualquer navegador precisava conversar com o banco.

Mas HTML não entende COBOL.

JavaScript não conhece CICS.

Foi necessário criar outra ponte.

Browser

↓

Apache

↓

Java

↓

CICS

↓

COBOL

Observe.

O COBOL continuava igual.

Quem mudou foi o tradutor.


Bellacosa Mainframe e o fluxo teorico em 2000

O nascimento dos Application Servers

Na década de 2000 apareceram servidores como:

  • IBM WebSphere

  • JBoss

  • WebLogic

  • Tomcat

Agora um servlet Java recebia a requisição.

Esse servlet chamava:

  • CICS

  • MQ

  • IMS

  • DB2

O navegador nunca falava diretamente com o mainframe.

Ele conversava com Java.

Java conversava com o IBM Z.


E onde entra o MQ?

Imagine um restaurante.

Você faz um pedido.

A cozinha está ocupada.

O garçom não fica parado esperando.

Ele coloca o pedido na fila.

Depois entrega quando estiver pronto.

MQ faz exatamente isso.

Aplicação

↓

Fila

↓

MQ

↓

COBOL

É comunicação assíncrona.

Muito mais segura.

Muito mais confiável.

Se o programa estiver indisponível por alguns segundos...

A mensagem continua esperando.

Nada é perdido.


Depois vieram os Web Services.

Agora o mundo falava XML.

Surgiram SOAP.

WSDL.

XSD.

O fluxo ficou parecido com isto.

HTML

↓

SOAP

↓

Application Server

↓

CICS

↓

COBOL

O COBOL ainda não entendia XML.

Mas havia componentes convertendo XML em estruturas COBOL.

Era tradução.

Sempre tradução.


Bellacosa Mainframe e o fluxo teorico em 2010

REST mudou novamente o cenário.

Agora quase tudo conversa usando HTTP.

GET

POST

PUT

DELETE

E normalmente JSON.

{
    "conta":12345
}

O navegador envia JSON.

O COBOL continua trabalhando com COPYBOOK.

Alguém precisa converter.

Quem faz isso?

Hoje normalmente:

  • z/OS Connect

  • CICS Web Services

  • Java

  • API Gateway



O nascimento do z/OS Connect

Essa talvez tenha sido uma das maiores evoluções do IBM Z.

Agora o fluxo pode ser assim.

React

↓

REST

↓

JSON

↓

z/OS Connect

↓

CICS

↓

COBOL

O desenvolvedor React acredita que está falando com uma API qualquer.

Na realidade...

Existe um programa COBOL do outro lado.

Sem ele perceber.


Vamos acompanhar uma consulta de saldo.

Você toca no botão.

Consultar Saldo

O aplicativo cria um JSON.

{
    conta:1234
}

Esse JSON segue pela internet.

HTTPS.

TLS.

Chega ao API Gateway.

O Gateway verifica:

  • certificado

  • autenticação

  • limite

  • token

  • autorização

Se tudo estiver correto...

Encaminha ao z/OS Connect.


O que faz o z/OS Connect?

Ele transforma isto:

JSON

naquilo:

COPYBOOK COBOL

Por exemplo.

JSON.

{
 cliente:100
}

vira

01 CLIENTE.

   05 CODIGO PIC 9(5).

Nenhum COBOL precisou ser alterado.

Ele continua recebendo estruturas COBOL.

Como sempre recebeu.


Agora entra o CICS.

O CICS recebe a requisição.

Seleciona uma Task.

Reserva memória.

Cria o ambiente.

Chama o programa COBOL.

Tudo isso acontece em poucos milissegundos.


O COBOL faz exatamente o que fazia em 1992.

Consulta DB2.

Ou VSAM.

Ou IMS.

Calcula saldo.

Verifica limites.

Executa regras de negócio.

Nada mudou.

As regras continuam ali.

Testadas durante décadas.


O retorno começa.

O COBOL devolve uma estrutura.

01 SALDO.

   05 VALOR PIC S9(9)V99.

O CICS devolve ao z/OS Connect.

O z/OS Connect transforma.

COPYBOOK

↓

JSON

Agora temos.

{
   "saldo":2450.80
}

O aplicativo Android recebe.

Atualiza a tela.

O usuário acredita que tudo aconteceu diretamente.

Na verdade dezenas de componentes participaram.


E onde entra Java?

Em muitos lugares.

Pode existir:

Android

↓

REST

↓

Spring Boot

↓

MQ

↓

COBOL

Ou

Angular

↓

Spring

↓

CICS TG

↓

COBOL

Ou

React

↓

Java

↓

IMS

↓

DB2

Java normalmente funciona como uma camada de negócios moderna.


E Node.js?

Também.

React

↓

Node.js

↓

REST

↓

z/OS Connect

↓

COBOL

Nada impede.

O IBM Z conversa com praticamente qualquer linguagem moderna.


E Python?

Também.

Python pode consumir APIs REST normalmente.

Python

↓

HTTPS

↓

JSON

↓

API

↓

Mainframe

O Python não sabe que existe um COBOL atrás da API.

Nem precisa saber.


E C#?

Exatamente igual.

C#

↓

REST

↓

Gateway

↓

Mainframe

E Go?

Também.


Rust?

Também.


Kotlin?

Também.


Flutter?

Também.


React Native?

Também.


Bellacosa Mainframe e o fluxo teorico em 2020

O protocolo mudou.

O conceito permaneceu.

Essa talvez seja a maior descoberta para um Padawan.

Muitos acreditam que aprender IBM Z significa abandonar tudo que conhecem.

Na verdade...

Você continua trabalhando com exatamente os mesmos conceitos.

Existe uma requisição.

Existe uma resposta.

Existe autenticação.

Existe autorização.

Existe uma camada de negócio.

Existe persistência.

Existe tratamento de erro.

Existe auditoria.

Existe segurança.

Esses conceitos nunca mudaram.

Mudaram apenas os protocolos.


O login moderno

Hoje um login costuma seguir aproximadamente este caminho.

Usuário

↓

Aplicativo

↓

HTTPS

↓

API Gateway

↓

OAuth2

↓

OpenID Connect

↓

JWT

↓

Servidor

↓

Mainframe

Depois do login o aplicativo recebe um Token.

JWT

Nas próximas chamadas ele envia apenas o Token.

O Gateway valida.

Se estiver correto...

A requisição segue.

O COBOL nem precisa conhecer JWT.

Alguém já validou antes.


O que continua exatamente igual?

Muito mais do que você imagina.

Ainda existem:

  • transações

  • commits

  • rollback

  • controle de concorrência

  • integridade

  • logs

  • auditoria

  • segurança

  • alta disponibilidade

  • recuperação

  • controle de acesso

  • regras de negócio

Esses pilares continuam praticamente idênticos há décadas.


O que realmente mudou?

Mudou quase tudo ao redor.

Antes:

3270

Hoje:

Android
iPhone
React
Angular
Vue
Windows
Electron
Flutter

Antes:

SNA

Hoje:

TCP/IP
HTTPS
REST
gRPC

Antes:

Tela 3270

Hoje:

JSON

Antes:

Terminal

Hoje:

API

Antes:

Monolito fechado

Hoje:

Microserviços consumindo APIs

Antes:

Operador interno

Hoje:

Milhões de usuários simultâneos

Mas o coração permanece surpreendentemente parecido.


O segredo do IBM Z

Existe uma frase que gosto de repetir aos meus alunos.

O mundo moderno não substituiu o mainframe. Aprendeu a conversar com ele.

Quando você abre um aplicativo de banco no celular, dificilmente imagina que aquela animação elegante, construída em Kotlin, Swift ou Flutter, pode terminar em um programa COBOL executando dentro de um CICS no IBM Z. No entanto, é exatamente isso que acontece milhões de vezes por dia.

O desenvolvedor do aplicativo pensa em telas, componentes, animações e experiência do usuário. O desenvolvedor de APIs pensa em REST, JSON, OAuth e microsserviços. O arquiteto de integração pensa em API Gateway, mensageria, balanceamento e observabilidade. E, no centro desse ecossistema, o COBOL continua fazendo o que sempre fez com excelência: aplicar regras de negócio, proteger dados e garantir que uma transferência de dinheiro, uma compra com cartão ou o pagamento de um benefício aconteçam com precisão absoluta.

Essa é a verdadeira evolução do software. Não jogar fora décadas de conhecimento, mas construir novas camadas sobre uma base sólida.


A Última Xícara de Café

Padawan, quando alguém disser que "o aplicativo conversa diretamente com o banco", lembre-se desta jornada invisível.

Um simples toque na tela percorre redes, protocolos, gateways, autenticação, criptografia, APIs, conversores de JSON para COPYBOOK, gerenciadores de transações, filas de mensagens, programas COBOL e bancos de dados, antes de retornar como um número exibido em poucos milissegundos.

A tela mudou.

A linguagem mudou.

Os protocolos mudaram.

As ferramentas mudaram.

Mas a essência continua a mesma desde os primeiros dias da computação corporativa: receber uma solicitação, validar quem a fez, executar regras de negócio com segurança, acessar dados de forma íntegra e devolver uma resposta confiável.

É por isso que o IBM Z continua relevante. Não porque resiste ao novo, mas porque se adapta a ele sem abrir mão daquilo que realmente importa: confiabilidade, disponibilidade, segurança e consistência.

No fim das contas, Android, Windows, HTML, JavaScript, Java, Node.js, Python, Go ou Rust não competem com o mainframe. Eles são apenas novos idiomas para conversar com um dos computadores mais confiáveis já construídos.

E talvez essa seja a maior lição desta conversa: a tecnologia muda; a boa engenharia permanece.

 


sexta-feira, 6 de março de 2026

Você usa React todos os dias… e talvez esteja falando com um programa COBOL de 60 anos.

 

Bellacosa Mainframe apresenta o casamento improvavel React + Cobol

☕ Um Café no Bellacosa Mainframe

☕ React conversa com COBOL?

A arquitetura invisível que conecta Web Apps modernos ao Mainframe

Se você usa internet banking, aplicativo de seguros ou sistemas corporativos modernos, existe uma chance enorme de que, por trás daquela interface elegante construída em React, esteja rodando um programa COBOL em um mainframe.

Sim.

JavaScript moderno conversando com uma tecnologia criada nos anos 1950.

E isso não é exceção — está se tornando arquitetura padrão em grandes empresas.


🧭 O mito da substituição do mainframe

Durante décadas surgiu uma narrativa repetida no mercado:

“O mainframe será substituído.”

Mas o que realmente aconteceu foi algo diferente.

O que mudou não foi o core, mas sim a interface.

Hoje, a arquitetura moderna segue um padrão cada vez mais comum:

Frontend moderno (React / Angular / Mobile)

API Gateway / Microservices

z/OS Connect / MQ / APIs

CICS / COBOL / DB2 no Mainframe

Ou seja:

React não substitui o mainframe.
React expõe o mainframe.


⚙️ A ponte tecnológica: APIs no z/OS

Ferramentas modernas permitem transformar transações tradicionais em APIs REST.

Entre elas:

  • IBM z/OS Connect

  • IBM API Connect

  • MQ / Event Streaming

  • OpenLegacy

  • GraphQL gateways

Com isso, um programa COBOL pode virar algo como:

GET /api/account/12345

Que internamente chama:

CICS PROGRAM GETACCT01

Tudo sem reescrever décadas de lógica de negócio.


🧩 Onde o React entra na arquitetura

O React se tornou uma escolha popular porque oferece:

  • UI altamente responsiva

  • arquitetura baseada em componentes

  • integração simples com APIs REST

  • enorme ecossistema

Uma stack moderna típica pode ser:

React
Node.js / BFF
API Gateway
z/OS Connect
CICS / COBOL
DB2

Resultado:

  • UX moderna

  • core estável

  • risco reduzido


📊 Curiosidade pouco conhecida

Estudos frequentemente citados no mercado indicam que:

  • cerca de 90% das transações financeiras globais passam por mainframes

  • grande parte dessas aplicações hoje é acessada via interfaces web modernas

Ou seja:

Quando você abre um portal moderno em React, pode estar falando com um COBOL rodando há décadas.


🥚 Easter eggs do mundo React + Mainframe

🥚 O padrão “Strangler Fig”

Arquitetos chamam essa estratégia de:

Strangler Fig Pattern

A ideia é:

  • manter o sistema legado

  • expor APIs

  • construir novas interfaces ao redor.

Gradualmente, o sistema evolui sem reescrita massiva.


🥚 JavaScript rodando dentro do mainframe

Muita gente não sabe, mas hoje existem runtimes de:

  • Node.js para z/OS

  • Python para z/OS

Ou seja, JavaScript pode rodar dentro do próprio mainframe.


🥚 React no ecossistema mainframe

Projetos como Zowe utilizam tecnologias modernas como:

  • React

  • TypeScript

  • APIs REST

para criar interfaces modernas para administração de ambientes z/OS.


☕ Comentário Bellacosa

Um erro comum é pensar que modernização significa:

substituir tudo.

Mas a realidade da engenharia de sistemas críticos é outra.

O que vemos hoje é uma arquitetura híbrida:

Interface moderna
+
Core extremamente confiável

E poucas plataformas oferecem um core tão confiável quanto o mainframe.


🚀 Conclusão

React e Mainframe não são concorrentes.

São camadas diferentes da mesma arquitetura.

Enquanto React cuida da experiência do usuário, o mainframe continua sendo o motor de processamento que sustenta o negócio.

Talvez o maior segredo da tecnologia corporativa moderna seja exatamente este:

O futuro da web muitas vezes roda em um computador criado há mais de meio século.

E isso diz muito sobre a engenharia por trás do Mainframe.



https://www.linkedin.com/posts/vagnerbellacosa_ibm-mainframe-cobol-activity-7436178528905248768-G-Al?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAF2qx0B5Ef0IGUpO8f7SxDHV-EQ5-EMG54

https://dio.me/articles/voce-usa-react-todos-os-dias-e-talvez-esteja-falando-com-um-programa-cobol-de-60-anos-f1cdaa899115?utm_source=link&utm_campaign=mgm-voce-usa-react-todos-os-dias-e-talvez-esteja-falando-com-um-programa-cobol-de-60-anos-f1cdaa899115&utm_medium=article

 

segunda-feira, 20 de outubro de 2025

A Maior Mentira da Modernização Mainframe: Por Que Transformar COBOL em Java Não Resolve Quase Nada

Bellacosa Mainframe o cobol nao é o problema



☕💣🚨 PADAWAN, O COBOL NÃO É O PROBLEMA! O VERDADEIRO MONSTRO ESTÁ ESCONDIDO DENTRO DO SISTEMA

A Maior Mentira da Modernização Mainframe: Por Que Transformar COBOL em Java Não Resolve Quase Nada



A Guerra Contra o COBOL

Existe uma frase que se repete há mais de 30 anos:

"Precisamos eliminar o COBOL."

O curioso é que enquanto essa frase era repetida por consultorias, vendors, CIOs e arquitetos corporativos, o COBOL continuava fazendo aquilo que sempre fez:

  • pagando aposentadorias;

  • processando cartões;

  • calculando seguros;

  • movimentando bilhões em transações;

  • sustentando governos inteiros.

O COBOL nunca foi o problema.

O problema sempre foi outro:

ninguém mais sabia exatamente o que estava escondido dentro dele.


O Dia em Que a Empresa Descobriu Que Ninguém Entendia o Sistema

Imagine um banco.

Ele possui:

  • 18 milhões de linhas COBOL;

  • 4.000 jobs batch;

  • 1.500 copybooks;

  • centenas de tabelas DB2;

  • regras de negócio escritas desde 1987.

Um consultor chega e diz:

"Vamos converter tudo para Java."

A diretoria aprova.

O projeto custa dezenas de milhões.

Três anos depois...

O sistema agora roda em Java.

E o problema continua exatamente igual.

Porque ninguém entendeu o negócio.

Apenas trocaram a sintaxe.


O Efeito "Jobol"

O artigo menciona um termo fantástico:

JOBOL

Java + COBOL

Código Java que continua pensando como COBOL.

Exemplo:

COBOL

IF CLIENTE-ATIVO = 'S'
   COMPUTE DESCONTO = VALOR * 0.10
END-IF

Convertido automaticamente:

if(clienteAtivo.equals("S")){
    desconto = valor * 0.10;
}

Parece moderno.

Mas pergunte:

  • Por que 10%?

  • Desde quando?

  • Existe legislação envolvida?

  • Existe exceção?

Ninguém sabe.

A lógica foi transportada.

O conhecimento não.


O Easter Egg Mais Perigoso do Mainframe

Todo sistema antigo possui algo parecido.

Um trecho de código aparentemente absurdo:

IF DATA = '31121999'
   MOVE ZERO TO TAXA
END-IF

O programador novo pergunta:

"Quem colocou isso?"

Ninguém sabe.

Remove.

Produção explode.

Meses depois descobrem:

Aquilo corrigia um problema de cálculo criado por uma mudança tributária em 1999.

O código era feio.

Mas carregava uma regra de negócio invisível.


O Mainframe Guarda Mais Conhecimento Que os Documentos

Muitas empresas acreditam que possuem documentação.

Não possuem.

Possuem:

  • manuais desatualizados;

  • diagramas antigos;

  • apresentações esquecidas.

O verdadeiro conhecimento está em:

  • COBOL;

  • PL/I;

  • Natural;

  • JCL;

  • PROC;

  • CICS;

  • IMS;

  • DB2;

  • VSAM.

O código virou documentação viva.


Laboratório Bellacosa

Descobrindo Conhecimento Escondido

Imagine um programa de cálculo de seguro.

Passo 1

Procure constantes misteriosas.

MOVE 0.732 TO FATOR-AJUSTE

Pergunta:

Por que 0.732?


Passo 2

Procure datas mágicas.

IF DATA > '01012015'

Pergunta:

O que aconteceu em 2015?


Passo 3

Procure exceções.

IF UF = 'SP'

Pergunta:

Por que somente São Paulo?


Passo 4

Converse com usuários antigos.

Muitas vezes eles sabem mais que a documentação.


Resultado

Você começa a reconstruir o domínio do negócio.

Exatamente o que o DDD propõe.


Domain Driven Design Explicado Para Mainframeiros

Muita gente acha que DDD é moda.

Na verdade, o mainframe fazia DDD sem saber.


Exemplo

Sistema de seguros.

Temos:

Domínio

Seguros

Subdomínio

Sinistros

Contexto delimitado

Regulação

Linguagem ubíqua

Termos que o negócio entende:

  • apólice;

  • prêmio;

  • segurado;

  • franquia;

  • indenização.


O Erro Clássico

Código moderno:

processEntity()

Código orientado ao domínio:

aprovarIndenizacao()

Qual transmite melhor o negócio?


O Grande Segredo dos Batchs

Existe uma verdade inconveniente.

Muitas regras de negócio não estão nos programas.

Estão na sequência dos jobs.


Exemplo:

JOB001 - IMPORTA CLIENTES
JOB002 - CALCULA JUROS
JOB003 - EMITE FATURAS
JOB004 - GERA ARQUIVO BACEN

Troque a ordem.

O banco para.

O fluxo batch também é conhecimento corporativo.


O Perigo da Reescrita Total

Todo arquiteto sonha com:

"Vamos reescrever tudo."

Na prática:

Forças

  • arquitetura limpa;

  • tecnologias novas;

  • documentação moderna.

Fraquezas

  • altíssimo risco;

  • anos de projeto;

  • perda de regras escondidas.

Perigos

  • divergência de cálculo;

  • problemas regulatórios;

  • inconsistências financeiras.


A Estratégia Que Mais Funciona

O artigo cita o conceito mais inteligente da modernização moderna.

Strangler Fig

A Figueira Estranguladora.

Ela cresce ao redor da árvore antiga.

Até substituí-la.


No Mainframe

Fase 1

COBOL continua funcionando.

Fase 2

Criamos APIs.

Fase 3

Novos sistemas consomem APIs.

Fase 4

Partes são substituídas.

Fase 5

O legado diminui gradualmente.

Sem Big Bang.

Sem suicídio corporativo.


Raincode: O Que Muita Gente Não Entendeu

Muitos acreditam que Raincode é uma ferramenta de migração.

Na verdade:

É uma ferramenta de sobrevivência.

Ela permite:

  • retirar carga do Z;

  • migrar gradualmente;

  • reduzir custos;

  • ganhar tempo.

Mas atenção:

Ela não resolve:

  • arquitetura ruim;

  • regras escondidas;

  • documentação ausente.


A Nova Função do Especialista COBOL

Aqui está a maior mudança dos próximos anos.

O programador COBOL deixa de ser:

  • mantenedor;

  • bombeiro de produção;

  • operador de emergência.

E passa a ser:

Arqueólogo Digital

A pessoa capaz de responder:

"Por que o sistema faz isso?"

Essa resposta vale mais que escrever código.


Curiosidade Histórica

Muitas regras de negócio existentes hoje foram criadas por programadores que já faleceram ou estão aposentados há décadas.

Mesmo assim:

  • seus algoritmos continuam rodando;

  • suas decisões continuam afetando clientes;

  • suas validações continuam protegendo empresas.

Em alguns casos, o código virou literalmente um patrimônio intelectual da organização.


O Verdadeiro Inimigo

Não é COBOL.

Não é JCL.

Não é CICS.

Não é IMS.

Não é DB2.

O verdadeiro inimigo é:

🚨 conhecimento implícito.

Aquilo que ninguém documentou.

Aquilo que ninguém explica.

Aquilo que só existe dentro do código.


Conclusão Bellacosa Mainframe

O mercado passou décadas tentando responder à pergunta errada.

Perguntavam:

"Como eliminamos o COBOL?"

Quando deveriam perguntar:

"Como preservamos o conhecimento do negócio?"

Porque uma empresa pode trocar:

  • COBOL por Java;

  • Java por C#;

  • C# por Rust;

  • Rust por IA Generativa.

Mas se perder o conhecimento embutido em 40 anos de operação...

não estará modernizando.

Estará apenas reconstruindo um problema antigo com ferramentas novas.

E como todo velho operador sabe:

"Trocar a cor do terminal não muda o que acontece quando você aperta ENTER." ☕💣🚨

quarta-feira, 11 de junho de 2025

Laboratório Prático de Java para IBM Mainframe 20 Labs para Transformar um Programador COBOL em um Desenvolvedor Java para IBM Z

 

Bellacosa Mainframe e um laboratorio java para mainframers

☕ Um Café no Bellacosa Mainframe

Laboratório Prático de Java para IBM Mainframe

Metodologia do Laboratório

Este laboratório foi desenvolvido para programadores COBOL iniciantes no ecossistema IBM Z, utilizando uma metodologia prática baseada no conceito learning by doing (aprender fazendo). Em vez de ensinar Java de forma isolada, cada conceito é apresentado em paralelo com tecnologias já conhecidas pelo desenvolvedor Mainframe, como COBOL, JCL, CICS, DB2, VSAM e z/OS. Dessa forma, o aluno estabelece uma associação natural entre os dois ambientes, reduzindo a curva de aprendizado e compreendendo como ambas as linguagens coexistem na arquitetura corporativa moderna.

Os vinte laboratórios evoluem gradualmente, começando pelos fundamentos da linguagem Java, passando por orientação a objetos, tratamento de exceções, coleções, acesso ao DB2 via JDBC, processamento Batch, APIs REST, WebSphere Liberty, IBM MQ, z/OS Connect, automação com Ansible, DevOps, LinuxONE e containers. Cada exercício apresenta objetivos claros, arquitetura, código comentado, desafios práticos e solução completa.

Ao final do treinamento, espera-se que o desenvolvedor compreenda o papel estratégico do Java no IBM Z e no LinuxONE, saiba como a JVM é executada nessas plataformas, desenvolva aplicações Batch e Online, integre serviços Java com programas COBOL e DB2, automatize processos utilizando ferramentas modernas e participe de projetos de modernização sem abandonar os sólidos fundamentos do Mainframe. O objetivo não é substituir o COBOL, mas formar profissionais capazes de transitar com segurança por todo o ecossistema IBM Z.

20 Labs para Transformar um Programador COBOL em um Desenvolvedor Java para IBM Z

Objetivo: Capacitar um programador COBOL Junior a compreender como o Java funciona dentro do ecossistema IBM Z, sempre relacionando os novos conceitos com aquilo que ele já conhece em COBOL, JCL, CICS e DB2.


Filosofia do Laboratório

Este não é um curso tradicional de Java.

É um curso pensado para quem já conhece Mainframe.

Durante todos os exercícios faremos comparações entre:

  • COBOL × Java

  • JCL × JVM

  • CICS × Liberty

  • SQL Embutido × JDBC

  • VSAM × Collections

  • Batch × Java Batch

  • Online CICS × REST APIs

O objetivo é diminuir o choque entre os dois mundos.


Ambiente sugerido

Desenvolvimento

  • VS Code

  • IBM Z Open Editor

  • Java 21 LTS

  • Maven

  • Git

  • Zowe CLI

Mainframe

  • IBM z/OS

  • USS (Unix System Services)

  • Enterprise COBOL

  • DB2

  • CICS TS

  • z/OS Connect

  • IBM MQ

  • WebSphere Liberty

Opcional

  • LinuxONE

  • Docker

  • OpenShift

  • Ansible


LAB 01 — Primeiro Programa Java

Objetivo

Criar o famoso Hello World.

O que aprender

  • Classe

  • Método main()

  • JVM

  • Compilação

Exercício

Criar

HelloMainframe.java

Executar

javac HelloMainframe.java

java HelloMainframe

Solução

Exibir

Olá IBM Z

LAB 02 — Comparando COBOL e Java

Objetivo

Criar um programa que recebe nome e idade.

Comparar com

WORKING-STORAGE
DISPLAY
ACCEPT

Aprender

  • Scanner

  • Variáveis

  • String

  • int

Solução

Programa imprime

Olá João

Você possui 30 anos

LAB 03 — Estruturas de Decisão

Comparar

COBOL

IF
ELSE
END-IF

com

Java

if

else

Exercício

Calcular maioridade.


LAB 04 — Estruturas de Repetição

Comparar

PERFORM UNTIL

com

for

while

Exercício

Exibir números de 1 a 100.


LAB 05 — Métodos

Comparar

SECTION

PARAGRAPH

com

Métodos Java

Criar método

calcularIR()

LAB 06 — Orientação a Objetos

Primeiro contato.

Criar

Cliente
Conta

Banco

Aprender

  • classe

  • objeto

  • atributos

  • métodos


LAB 07 — Collections

Comparar

Tabela OCCURS

com

ArrayList

Exercício

Cadastrar clientes.


LAB 08 — Tratamento de Exceções

Comparar

IF SQLCODE

IF FILE STATUS

com

try

catch

Gerar erro proposital.

Capturar erro.


LAB 09 — Leitura de Arquivos

Comparar

Sequential File

com

BufferedReader

Ler arquivo

CLIENTES.TXT

LAB 10 — Escrevendo Arquivos

Criar

RELATORIO.TXT

Comparar

WRITE

com

FileWriter.


LAB 11 — JDBC + DB2

Objetivo

Primeira conexão com DB2.

Aprender

  • Driver JDBC

  • Connection

  • Statement

  • ResultSet

Consulta

SELECT *

CLIENTE

Solução

Exibir registros na tela.


LAB 12 — PreparedStatement

Comparar

EXEC SQL

com

PreparedStatement

Inserir cliente.

Depois atualizar.

Depois excluir.


LAB 13 — Java Batch

Criar um processamento Batch.

Fluxo

Ler Arquivo

↓

Validar

↓

Atualizar DB2

↓

Gerar Relatório

Executar usando JCL.


LAB 14 — Java no USS

Entrar no Unix System Services.

Executar

java

javac

jar

Aprender

  • PATH

  • JAVA_HOME

  • CLASSPATH


LAB 15 — WebSphere Liberty

Criar primeira aplicação.

Executar

localhost:9080

Primeira API REST.


LAB 16 — Java + MQ

Criar

Produtor

Consumidor

Enviar mensagens.

Comparar com Batch desacoplado.


LAB 17 — Java + CICS

Criar aplicação Java.

Consumir programa COBOL.

Fluxo

Java

↓

CICS

↓

COBOL

Entender integração.


LAB 18 — Java + z/OS Connect

Criar API REST.

Consumir programa COBOL.

Resultado

GET

/clientes

Retorna

JSON.


LAB 19 — Deploy Automatizado

Criar Pipeline.

Ferramentas

  • Git

  • Maven

  • Jenkins

  • Zowe

  • Ansible

Deploy automático.


LAB 20 — Projeto Final

Sistema Bancário Completo

Arquitetura

Cliente

↓

REST API

↓

Spring Boot

↓

Liberty

↓

MQ

↓

CICS

↓

COBOL

↓

DB2

O Projeto

Cadastrar clientes.

Consultar clientes.

Atualizar clientes.

Excluir clientes.

Gerar relatório Batch.

Consultar API REST.

Executar deploy automático.


Estrutura sugerida

MainframeJavaLabs

│

├── Lab01_HelloJava

├── Lab02_Variaveis

├── Lab03_IF

├── Lab04_FOR

├── Lab05_Metodos

├── Lab06_OO

├── Lab07_Collections

├── Lab08_Exceptions

├── Lab09_Arquivos

├── Lab10_FileWriter

├── Lab11_JDBC

├── Lab12_PreparedStatement

├── Lab13_JavaBatch

├── Lab14_USS

├── Lab15_Liberty

├── Lab16_MQ

├── Lab17_CICS

├── Lab18_zOSConnect

├── Lab19_Ansible

└── Lab20_ProjetoFinal

O que cada laboratório deve conter

Para que o aprendizado seja realmente prático, todos os 20 laboratórios devem seguir a mesma estrutura:

  • Objetivo: o que será aprendido e por que isso é importante no IBM Z.

  • Conceitos COBOL equivalentes: comparação direta entre os conceitos de COBOL e Java.

  • Arquitetura: diagrama do fluxo da aplicação.

  • Pré-requisitos: softwares, datasets, tabelas DB2 ou configurações necessárias.

  • Passo a passo: instruções detalhadas de implementação.

  • Código comentado: explicando cada linha e sua função.

  • Compilação e execução: tanto no ambiente local quanto no z/OS, quando aplicável.

  • Análise dos resultados: como validar se tudo funcionou corretamente.

  • Desafios extras: exercícios para expandir o laboratório.

  • Solução completa: código-fonte, JCL, scripts Maven/Gradle, SQL e arquivos de configuração.

Competências desenvolvidas

Ao concluir os 20 laboratórios, o programador COBOL Junior terá desenvolvido competências para:

  • Escrever aplicações Java orientadas a objetos.

  • Compreender a execução da JVM no IBM Z.

  • Criar programas Batch em Java executados por JCL.

  • Desenvolver APIs REST com Spring Boot e WebSphere Liberty.

  • Integrar aplicações Java com programas COBOL via CICS e z/OS Connect.

  • Acessar tabelas DB2 utilizando JDBC e PreparedStatement.

  • Utilizar IBM MQ para comunicação assíncrona.

  • Trabalhar com USS (Unix System Services).

  • Automatizar builds e deploys com Maven, Git, Jenkins, Zowe e Ansible.

  • Entender o papel do LinuxONE, Docker e OpenShift na modernização do ecossistema IBM Z.

Resultado esperado

Ao final desse laboratório, o aluno deixará de enxergar Java como uma tecnologia "concorrente" do COBOL. Em vez disso, compreenderá como ambas as linguagens coexistem no IBM Z, cada uma exercendo um papel específico na arquitetura corporativa moderna. Esse conhecimento amplia significativamente as oportunidades profissionais e prepara o desenvolvedor para atuar em projetos de modernização, integração por APIs e DevOps, mantendo o COBOL como o coração das regras de negócio e o Java como a ponte entre o Mainframe e o restante do mundo.


quarta-feira, 28 de maio de 2025

Java no IBM Mainframe: Quando o Programador COBOL Descobre que a JVM Também Mora no z/OS

 

Bellacosa Mainframe e o java no mundo mainframe

☕ Um Café no Bellacosa Mainframe

Java no IBM Mainframe: Quando o Programador COBOL Descobre que a JVM Também Mora no z/OS

"O futuro do Mainframe nunca foi COBOL ou Java. Sempre foi COBOL e Java trabalhando juntos."


Durante muitos anos surgiu um mito que assustou milhares de programadores COBOL.

"O Java vai substituir o COBOL."

O tempo mostrou exatamente o contrário.

Hoje, praticamente todos os grandes bancos, seguradoras, operadoras de cartão, bolsas de valores e órgãos governamentais utilizam COBOL e Java lado a lado, cada um fazendo aquilo em que é melhor.

Na realidade, aprender Java não significa abandonar o COBOL.

Significa entender como funciona o restante do ecossistema moderno do IBM Z.

Se você é um programador COBOL Junior, este artigo é praticamente um mapa mostrando onde o Java entra na arquitetura Mainframe e por que ele pode transformar sua carreira.

Pegue seu café.

Hoje vamos conhecer um dos moradores mais importantes do IBM Z.


O dia em que o Java chegou ao Mainframe

Quando a Sun Microsystems lançou o Java em 1995, sua proposta era revolucionária.

Write Once, Run Anywhere.

Escreva uma vez.

Execute em qualquer lugar.

Enquanto isso, o Mainframe continuava executando milhões de linhas de COBOL.

A IBM rapidamente percebeu que aquela linguagem seria importante.

Ao invés de ignorá-la, fez algo típico da empresa:

levou o Java para dentro do z/OS.

Poucos anos depois surgiu a JVM para Mainframe.

Desde então, cada geração do IBM Z recebeu melhorias específicas para acelerar Java.

Hoje existem instruções de hardware dedicadas para execução da JVM.

Ou seja:

O Java não está "rodando emulado" no Mainframe.

Ele roda utilizando otimizações do próprio processador IBM Z.


Onde o Java aparece no Mainframe?

Muito mais lugares do que imaginamos.

Você provavelmente já utiliza sistemas Java sem perceber.

Exemplos:

  • Internet Banking

  • Aplicativos Mobile

  • APIs REST

  • Microserviços

  • IBM MQ

  • WebSphere Liberty

  • CICS Java

  • Batch Java

  • z/OS Connect

  • IBM Z Open Automation Utilities

  • Ansible

  • Jenkins

  • Zowe

  • Eclipse

  • IBM Developer for z/OS

  • Spring Boot para z/OS

Em muitos ambientes, o COBOL continua sendo o responsável pelas regras de negócio.

O Java apenas conversa com ele.


A arquitetura moderna

Imagine um banco.

Cliente
     │
Internet
     │
API REST
     │
Spring Boot
     │
z/OS Connect
     │
CICS
     │
Programa COBOL
     │
DB2

Perceba algo interessante.

O Java raramente substitui o COBOL.

Ele funciona como uma ponte.


Java Batch

Quando pensamos em Mainframe normalmente lembramos de processamento Batch.

A boa notícia é que Java também executa Batch.

Por exemplo:

Leitura de arquivos

↓

Validação

↓

Processamento

↓

Atualização DB2

↓

Geração de Relatórios

A execução ocorre através do JCL.

Exemplo simplificado:

//JAVAJOB JOB
//STEP01 EXEC PGM=JVMLDM86
//STDENV DD *
JAVA_HOME=/usr/lpp/java
CLASSPATH=/u/apps/meuapp.jar
/*

Na prática, o JCL prepara o ambiente.

Quem executa o processamento é a JVM.


Um pequeno programa Java

public class HelloMainframe {

    public static void main(String[] args){

        System.out.println("Olá IBM Z!");

    }

}

Compilação:

javac HelloMainframe.java

Execução:

java HelloMainframe

No z/OS funciona praticamente da mesma forma.

A diferença está no ambiente preparado pelo JCL.


Java Online

Agora imagine uma aplicação bancária.

O cliente faz um PIX.

O aplicativo envia uma requisição.

Essa requisição chega ao Mainframe.

Quem recebe?

Pode ser um programa Java.

Ou um serviço REST.

Depois disso:

Java

↓

CICS

↓

COBOL

↓

DB2

↓

Resposta JSON

Tudo ocorre em poucos milissegundos.


Java dentro do CICS

Muitos desenvolvedores não sabem.

O CICS executa programas Java.

Isso permite:

  • APIs REST

  • SOAP

  • JSON

  • XML

  • JMS

  • MQ

Tudo dentro do ambiente transacional.

O COBOL continua executando a lógica principal.

O Java cuida da integração.


Java e DB2

Uma das maiores vantagens do Java é sua integração com bancos relacionais.

O acesso normalmente ocorre através do JDBC.

Exemplo:

Connection conn =
DriverManager.getConnection(url,user,password);

PreparedStatement ps =
conn.prepareStatement(
"SELECT NOME FROM CLIENTES");

ResultSet rs = ps.executeQuery();

No Mainframe ocorre exatamente o mesmo conceito.

A diferença está no driver utilizado.

Normalmente utiliza-se o IBM Data Server Driver.


JDBC ou SQL Embutido?

Programadores COBOL costumam perguntar:

"Se existe SQL Embutido, por que usar JDBC?"

Porque são tecnologias diferentes.

COBOL

EXEC SQL
SELECT ...
END-EXEC

Java

PreparedStatement

O resultado final é semelhante.

Ambos acessam o DB2.


Vantagens do PreparedStatement

Nunca monte SQL concatenando Strings.

Ruim:

"SELECT * FROM CLIENTES WHERE ID="+id;

Correto:

PreparedStatement

Além de mais rápido, evita SQL Injection.


Java e Stored Procedures

Outra integração muito comum.

Java

↓

Stored Procedure DB2

↓

SQL

↓

Resultado

Muitos bancos utilizam esse modelo.


Java conversando com COBOL

Existem diversas formas.

Por exemplo:

  • CICS LINK

  • MQ

  • REST

  • SOAP

  • z/OS Connect

  • JNI

  • Arquivos

  • Stored Procedures

Na maioria dos projetos modernos, REST e MQ são os campeões.


Java e IBM MQ

Imagine dezenas de sistemas conversando.

Ao invés de chamadas diretas, utiliza-se filas.

Java

↓

MQ

↓

COBOL

Se o COBOL estiver ocupado...

A mensagem continua aguardando.

Isso aumenta a disponibilidade.


Java e z/OS Connect

Talvez esta seja a tecnologia que mais mudou o Mainframe.

Antes:

Aplicações externas precisavam conhecer CICS.

Hoje:

REST

↓

JSON

↓

z/OS Connect

↓

COBOL

Quem desenvolve a API geralmente utiliza Java.


WebSphere Liberty

O Liberty tornou-se praticamente o servidor Java padrão do IBM Z.

Leve.

Moderno.

Compatível com Jakarta EE.

Executa:

  • REST

  • MicroProfile

  • JWT

  • OAuth

  • OpenAPI

Tudo muito integrado ao z/OS.


Java e LinuxONE

Aqui surge uma dúvida.

LinuxONE é Mainframe?

Sim.

É a mesma arquitetura IBM Z.

A diferença é que executa Linux como sistema operacional principal.

Nesse ambiente podemos instalar:

  • Java

  • Spring Boot

  • Docker

  • Kubernetes

  • Kafka

  • PostgreSQL

  • MongoDB

  • Redis

Tudo rodando sobre hardware IBM.

É comum encontrar arquiteturas híbridas:

LinuxONE

↓

Java

↓

API

↓

MQ

↓

z/OS

↓

COBOL

Java e Containers

Hoje o Java roda perfeitamente em containers.

Exemplo:

Docker

↓

Java

↓

Spring Boot

No IBM Z isso normalmente acontece utilizando:

  • Red Hat OpenShift

  • Kubernetes

  • LinuxONE


Java e OpenShift

Imagine centenas de APIs.

Em vez de dezenas de servidores, utiliza-se OpenShift.

Cada API Java roda em um container.

Quando aumenta o acesso...

O OpenShift cria novos containers automaticamente.


Java e Ansible

Aqui está uma surpresa para muitos programadores COBOL.

O Ansible também administra aplicações Java.

Por exemplo:

  • Deploy

  • Atualização

  • Reinício

  • Configuração

  • Instalação

  • Coleta de logs

Tudo automatizado.

Um Playbook simples:

- hosts: zos

  tasks:

    - name: Reiniciar Liberty

      command: server stop liberty

    - name: Iniciar Liberty

      command: server start liberty

Java e Zowe

O Zowe aproximou muito o Mainframe do mundo Open Source.

Com ele podemos:

  • enviar JCL

  • consultar Jobs

  • acessar datasets

  • acessar USS

  • automatizar builds

Tudo usando JavaScript, Node.js ou Java.


Java e USS

O UNIX System Services é praticamente um Linux dentro do z/OS.

É nele que encontramos:

/usr/lpp/java

Ali estão instalados:

  • JVM

  • Bibliotecas

  • Ferramentas

  • Scripts

Grande parte das aplicações Java vive dentro do USS.


Java e Git

Hoje é comum encontrar projetos Java armazenados no GitHub.

Fluxo típico:

Git

↓

Jenkins

↓

Compilação

↓

Testes

↓

Deploy

↓

Liberty

Tudo automático.


Java e DevOps

Mainframe moderno faz DevOps.

Ferramentas comuns:

  • Git

  • GitHub

  • GitLab

  • Jenkins

  • UrbanCode Deploy

  • Ansible

  • Zowe CLI

  • Maven

  • Gradle

  • SonarQube


Maven

Quase todo projeto Java utiliza Maven.

Arquivo:

pom.xml

Ali ficam:

  • dependências

  • plugins

  • versão

  • compilação

É o equivalente ao gerenciamento de bibliotecas do projeto.


Gradle

Outro gerenciador bastante utilizado.

Mais flexível.

Mais rápido em projetos grandes.


Java e APIs REST

Hoje praticamente toda integração passa por APIs.

Exemplo simples:

GET

/clientes/123

Resposta:

{
 "id":123,
 "nome":"João"
}

Quem produz esse JSON?

Na maioria das vezes:

Java.

Quem consulta o DB2?

COBOL.


Curiosidades

Pouca gente sabe que:

  • O IBM Z possui otimizações específicas para Java.

  • Existe JIT Compiler dedicado.

  • A JVM recebe melhorias a cada geração do processador.

  • Grande parte das ferramentas IBM modernas utiliza Java.

  • O IBM Developer for z/OS é baseado em Eclipse, escrito em Java.

  • O IBM Installation Manager é Java.

  • Diversos componentes do IBM MQ possuem módulos Java.

  • O z/OS Explorer e o CICS Explorer também são baseados em Eclipse.

Ou seja...

Mesmo sem programar Java, você provavelmente já utiliza softwares escritos nessa linguagem todos os dias.


Dicas para quem vem do COBOL

1. Aprenda Orientação a Objetos

É a maior mudança de mentalidade.

COBOL organiza programas.

Java organiza objetos.


2. Domine Collections

Aprenda:

  • List

  • Set

  • Map

  • Queue

Você utilizará essas estruturas constantemente.


3. Entenda Exceptions

Em COBOL temos:

IF SQLCODE

Em Java temos:

try{

}
catch(Exception e){

}

É outra forma de tratar erros.


4. Não tenha medo do Garbage Collector

COBOL trabalha muito com controle explícito de memória.

Java possui coleta automática.

Isso reduz vazamentos de memória, mas exige entender como o Garbage Collector funciona para escrever aplicações eficientes.


5. Aprenda SQL antes de JDBC

Quem domina SQL aprende JDBC muito mais rapidamente.

O banco continua sendo o mesmo.


6. Conheça o ecossistema

Não estude apenas a linguagem.

Conheça também:

  • Spring Boot

  • Maven

  • Gradle

  • Git

  • Docker

  • OpenShift

  • Ansible

  • Zowe

  • Liberty

  • MQ

  • z/OS Connect


Um roteiro de estudos para o Programador COBOL Junior

Uma boa sequência é:

  1. Fundamentos da linguagem Java (variáveis, classes, objetos e herança).

  2. Coleções, exceções, entrada/saída e programação funcional com Streams.

  3. JDBC e acesso ao DB2.

  4. Maven ou Gradle para gerenciamento de dependências.

  5. Git e GitHub.

  6. Spring Boot e criação de APIs REST.

  7. IBM MQ para mensageria.

  8. WebSphere Liberty e implantação de aplicações Java no z/OS.

  9. z/OS Connect para expor programas COBOL como APIs.

  10. LinuxONE, Docker e OpenShift.

  11. Zowe CLI para integração com o ambiente Mainframe.

  12. Ansible para automação de deploy, configuração e administração.

Essa jornada amplia sua visão do ecossistema IBM Z e faz de você um profissional muito mais versátil.

O que muda na carreira?

Há vinte anos, um programador COBOL precisava conhecer principalmente JCL, CICS e DB2.

Hoje isso continua importante, mas o cenário mudou.

O profissional mais valorizado é aquele que entende o fluxo completo da aplicação:

  • O aplicativo móvel envia uma requisição.

  • Uma API Java recebe a chamada.

  • O z/OS Connect faz a integração.

  • O CICS executa a transação.

  • O COBOL aplica as regras de negócio.

  • O DB2 armazena e recupera os dados.

  • O MQ garante comunicação assíncrona quando necessário.

  • O Liberty hospeda os serviços.

  • O OpenShift escala os containers.

  • O Ansible automatiza o ambiente.

  • O Zowe integra tudo ao pipeline de DevOps.

Perceba que o COBOL continua no centro da operação. O Java amplia as possibilidades de integração, modernização e entrega contínua.

Conclusão

Existe uma frase muito conhecida no universo Mainframe:

"As regras de negócio ficam onde elas sempre estiveram; o que muda é a forma de acessá-las."

É exatamente isso que aconteceu com o Java no IBM Z.

Ele não chegou para substituir o COBOL, mas para conectar o Mainframe ao restante do mundo: aplicações web, dispositivos móveis, microsserviços, nuvem híbrida, APIs, automação e DevOps. Enquanto o COBOL continua executando com confiabilidade as transações críticas, o Java oferece a flexibilidade necessária para construir novas interfaces e integrar tecnologias modernas.

Para o programador COBOL Junior, aprender Java significa entender como as aplicações corporativas são construídas hoje. Você continuará valorizando conceitos clássicos como JCL, CICS, DB2 e VSAM, mas também passará a dominar ferramentas como Maven, Spring Boot, Liberty, MQ, Zowe, OpenShift e Ansible.

No fim das contas, o mercado não procura especialistas em uma única linguagem. Procura profissionais capazes de navegar por todo o ecossistema IBM Z. E, nesse ecossistema, COBOL e Java não são rivais — são parceiros que, juntos, mantêm funcionando alguns dos sistemas mais importantes do planeta.


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