 |
| Bellacosa Mainframe como java conversa com o mainframe |
☕ Um Café no Bellacosa Mainframe
Java no IBM Z: Como Java Conversa com COBOL, DB2, CICS e o Mundo Mainframe na Prática
"O Java não chegou para substituir o COBOL. Ele chegou para conversar com ele."
Existe uma lenda que circula há muitos anos entre profissionais de TI.
Ela diz que existem dois mundos completamente diferentes.
De um lado está o mundo Mainframe.
Do outro está o mundo Java.
Na realidade... isso nunca foi verdade.
Hoje, milhares de bancos, seguradoras, governos e bolsas de valores executam aplicações onde Java, COBOL, CICS, DB2, MQ, z/OS Connect e APIs REST trabalham juntos no mesmo IBM Z.
A pergunta deixou de ser:
"Java ou COBOL?"
e passou a ser:
"Como fazer ambos trabalharem juntos?"
Pegue seu café porque hoje vamos abrir a tampa do motor do IBM Z.
A chegada do Java ao Mainframe
Quando Java apareceu em 1995, muitos profissionais de Mainframe olharam com desconfiança.
"Uma linguagem interpretada?"
"Rodando em máquina virtual?"
"Orientada a objetos?"
Parecia impossível competir com COBOL compilado.
Mas havia um detalhe importante.
Java tinha uma vantagem gigantesca.
Escrever uma vez, executar em qualquer lugar
A JVM (Java Virtual Machine) permitia que o mesmo programa funcionasse em:
Windows
Linux
Unix
AIX
IBM Z
A IBM rapidamente percebeu que clientes desejariam executar Java perto dos dados.
E onde estavam os dados?
No DB2.
No VSAM.
No IMS.
No CICS.
No MQ.
Ou seja...
Java precisava ir até o Mainframe.
Não fazia sentido mover bilhões de registros para outro servidor.
Muito mais eficiente era mover o processamento.
O nascimento do Java no z/OS
A IBM portou a JVM para o z/OS.
Depois vieram:
IBM SDK for Java
JZOS
JDBC para DB2
CICS Java
Liberty
WebSphere
OpenJ9 JVM
Hoje Java é cidadão de primeira classe dentro do IBM Z.
A arquitetura moderna
Imagine um banco.
Cliente Web
│
REST API
│
Liberty
│
Java
│
JDBC
│
DB2
Agora imagine outro fluxo.
Cliente
↓
CICS
↓
Programa Java
↓
Programa COBOL
↓
DB2
Ou ainda
Java
↓
MQ
↓
COBOL
↓
IMS
Ou
Java
↓
z/OS Connect
↓
CICS
↓
COBOL
↓
VSAM
Perceba.
O Java raramente trabalha sozinho.
Ele normalmente atua como a camada de integração.
JDBC
JDBC significa:
Java Database Connectivity
É a API padrão do Java para conversar com bancos de dados.
No Mainframe ela conversa principalmente com o DB2.
Exemplo
Connection conn =
DriverManager.getConnection(
"jdbc:db2://servidor:446/BANCO",
"usuario",
"senha");
A partir daí...
PreparedStatement ps =
conn.prepareStatement(
"SELECT NOME,SALDO FROM CLIENTE WHERE ID=?");
ps.setInt(1,100);
ResultSet rs = ps.executeQuery();
Enquanto houver registros
while(rs.next()){
System.out.println(
rs.getString("NOME"));
}
Isso parece simples.
Mas por trás existe uma enorme infraestrutura.
O Driver JDBC
O Driver JDBC entende dois idiomas.
Ele fala Java.
E fala DB2.
É literalmente um tradutor.
Java
↓
Driver JDBC
↓
DRDA
↓
DB2
O desenvolvedor escreve SQL.
O Driver transforma isso em chamadas compreendidas pelo DB2.
O Prepared Statement
No Mainframe quase nunca usamos:
Statement
Preferimos:
PreparedStatement
Por quê?
Porque:
reutiliza plano de acesso
melhora performance
evita SQL Injection
reduz parsing
Exemplo
SELECT *
FROM CLIENTE
WHERE CPF=?
O ponto de interrogação representa um parâmetro.
Como Java conversa com DB2
Internamente ocorre algo semelhante.
Java
↓
JDBC
↓
DRDA
↓
DB2 Thread
↓
Buffer Pool
↓
Tablespace
O Java nunca lê páginas do banco.
Quem faz isso é o DB2.
Como COBOL acessa DB2
No COBOL usamos:
EXEC SQL
SELECT NOME
INTO :WS-NOME
FROM CLIENTE
END-EXEC.
No Java:
String nome=
rs.getString("NOME");
O objetivo é exatamente o mesmo.
A tecnologia muda.
Conversão de tipos
Essa é uma das maiores dúvidas.
Como converter tipos COBOL para Java?
COBOL
PIC X(30)
Java
String
COBOL
PIC X
Java
char
ou
String
COBOL
PIC 9(4)
Java
int
COBOL
PIC 9(9)
Java
long
COBOL
PIC S9(9)V99 COMP-3
Java
BigDecimal
Nunca utilize:
double
para dinheiro.
Sempre:
BigDecimal
Datas
COBOL
PIC X(10)
2026-07-01
Java
LocalDate
ou
LocalDateTime
Boolean
COBOL tradicional não possui boolean.
Normalmente usa:
"S"
"N"
ou
1
0
No Java
boolean
Estruturas COBOL
Imagine
01 CLIENTE.
05 ID.
05 NOME.
05 SALDO.
No Java
class Cliente{
int id;
String nome;
BigDecimal saldo;
}
Observe a semelhança.
O Java apenas encapsula os dados dentro de uma classe.
OO versus Procedural
COBOL
LER CLIENTE
↓
VALIDAR
↓
ATUALIZAR
↓
GRAVAR
Fluxo procedural.
Java
Cliente
↓
objeto
↓
métodos
↓
atributos
Em vez de funções espalhadas,
o comportamento fica dentro do objeto.
Classe
public class Cliente{
private String nome;
private BigDecimal saldo;
public void sacar(){
}
}
A classe reúne:
dados
comportamento
O que seria uma estrutura COBOL equivalente?
WORKING-STORAGE
↓
PROCEDURE DIVISION
↓
PARÁGRAFOS
A ideia é semelhante.
Só muda a organização.
Como Java chama COBOL?
Existem diversas formas.
CICS
Java
↓
EXEC CICS LINK
↓
Programa COBOL
JNI
Java pode chamar código nativo.
MQ
Java envia mensagem.
COBOL recebe.
REST
Java chama uma API exposta pelo COBOL.
Stored Procedures
DB2 executa procedimento COBOL.
Java apenas chama.
CICS
Imagine um caixa eletrônico.
O Java recebe uma requisição REST.
POST
/saque
Java valida.
Depois
EXEC CICS LINK
para
SAQ001
escrito em COBOL.
O COBOL atualiza saldo.
Retorna.
Java transforma em JSON.
Cliente recebe resposta.
Tudo acontece em poucos milissegundos.
JSON
O Java trabalha naturalmente com JSON.
Exemplo
{
"id":100,
"nome":"Maria",
"saldo":2500
}
Classe
Cliente
Bibliotecas como Jackson fazem:
Objeto
↓
JSON
e
JSON
↓
Objeto
automaticamente.
XML
Antes do JSON predominava XML.
<cliente>
<nome>Maria</nome>
</cliente>
Ainda muito utilizado em:
SOAP
WebServices
Integrações legadas.
Conversão COBOL para JSON
Suponha
01 CLIENTE.
05 NOME.
05 CPF.
05 SALDO.
Java monta
{
"nome":"",
"cpf":"",
"saldo":0
}
O mapeamento costuma ser feito por:
Jackson
JAXB
JSON-B
Datasets
Java também pode acessar datasets.
Mas normalmente utiliza:
JZOS.
Exemplo
HLQ.CLIENTES.MASTER
O Java lê registros do dataset.
Sem necessidade de FTP.
VSAM
Também pode acessar
KSDS
ESDS
RRDS
através de APIs específicas.
Arquivos Sequenciais
Java consegue ler datasets RECFM FB.
Cada registro torna-se um array de bytes.
Depois converte.
Bytes
↓
String
↓
Objeto Java
EBCDIC versus ASCII
Outro ponto crítico.
Mainframe usa:
EBCDIC.
Java trabalha internamente em Unicode.
Então existe conversão automática.
EBCDIC
↓
Unicode
↓
String
Sem isso os caracteres apareceriam ilegíveis.
Batch Java
Pouca gente sabe.
Java também roda Batch.
JCL
//STEP1 EXEC PGM=JVMLDM86
ou
BPXBATCH
executando
java MinhaClasse
Exemplo
//JAVA EXEC PGM=BPXBATCH
//STDENV DD *
JAVA_HOME=/usr/lpp/java
/*
O Java executa como qualquer programa batch.
Pode:
ler datasets
acessar DB2
gerar arquivos
enviar MQ
consumir APIs
Java Online
Dentro do CICS.
Ou Liberty.
Recebe milhares de requisições simultâneas.
JSP
Nos anos 2000 a IBM utilizou muito:
JSP
↓
Servlet
↓
Java
↓
DB2
A página dinâmica misturava HTML com Java.
Exemplo
<%=cliente.getNome()%>
Hoje é menos comum.
Frameworks modernos predominam.
Mas muitos sistemas bancários ainda utilizam JSP.
Servlets
O Servlet recebe a requisição.
HTTP
↓
Servlet
↓
Java
↓
DB2
Depois devolve HTML.
Ou JSON.
APIs REST
Hoje a arquitetura mais comum é
Angular
↓
REST
↓
Java
↓
COBOL
↓
DB2
O usuário nem imagina que existe COBOL.
LinuxONE
Agora entra um personagem muito importante.
O LinuxONE.
Ele compartilha praticamente a mesma arquitetura do IBM Z.
Executa:
Linux
Containers
Docker
Kubernetes
OpenShift
Java
IA
Tudo extremamente próximo do z/OS.
Isso reduz:
latência
tráfego de rede
custo
Imagine
LinuxONE
↓
Java
↓
MQ
↓
z/OS
↓
COBOL
Tudo dentro do mesmo hardware.
OpenJ9
A JVM da IBM foi otimizada.
Ela consome menos memória.
Melhora Garbage Collection.
Aproveita processadores IBM Z.
zIIP
Aqui está um dos grandes diferenciais.
Grande parte do processamento Java pode utilizar processadores zIIP.
Resultado:
mais desempenho.
Menor custo de licenciamento.
É uma das razões pelas quais muitas empresas migraram workloads Java para o IBM Z.
Um fluxo completo
Imagine uma transferência bancária.
Celular
↓
HTTPS
↓
API REST
↓
Liberty
↓
Java
↓
Validação
↓
EXEC CICS LINK
↓
COBOL
↓
DB2
↓
COMMIT
↓
Resposta COBOL
↓
Objeto Java
↓
JSON
↓
Cliente
Perceba que cada tecnologia faz aquilo em que é especialista.
Java oferece APIs, integração, orientação a objetos e desenvolvimento web.
COBOL executa regras de negócio consolidadas ao longo de décadas.
CICS coordena as transações com alta disponibilidade.
DB2 garante consistência, integridade e desempenho.
JCL agenda e executa processos batch.
MQ desacopla sistemas e permite comunicação assíncrona.
LinuxONE hospeda aplicações Java, microsserviços e containers próximos aos dados.
IBM Z fornece segurança, escalabilidade, criptografia e confiabilidade.
Não existe competição entre essas tecnologias. Existe colaboração.
Procedural x Orientado a Objetos: uma visão para quem vem do COBOL
Para um programador COBOL, pense da seguinte forma:
No COBOL você cria um programa que manipula registros.
No Java você cria um objeto que representa aquele registro e sabe operar sobre ele.
No COBOL:
LER CLIENTE
VALIDAR CLIENTE
ATUALIZAR CLIENTE
GRAVAR CLIENTE
No Java:
Cliente cliente = repositorio.buscar(id);
cliente.validar();
cliente.atualizarSaldo(valor);
repositorio.salvar(cliente);
A regra de negócio continua praticamente a mesma. O que muda é a forma de organizá-la.
O futuro
Nos últimos anos surgiram novas tecnologias como:
Jakarta EE
Spring Boot
Quarkus
Open Liberty
z/OS Connect EE
APIs REST
GraphQL
Kafka
OpenShift
Red Hat Ansible Automation Platform
IA Generativa integrada ao IBM Z
Mesmo assim, o núcleo dos sistemas bancários continua sendo, em muitos casos, o mesmo:
COBOL processando regras críticas.
CICS coordenando milhões de transações.
DB2 armazenando dados.
Java expondo serviços modernos.
LinuxONE executando aplicações cloud-native próximas ao ambiente z/OS.
Conclusão
Durante muitos anos, criou-se a falsa ideia de que Java substituiria o COBOL. A história mostrou o contrário. O IBM Z evoluiu para unir o melhor dos dois mundos.
O COBOL permanece imbatível na execução de regras de negócio críticas e estáveis. O Java tornou-se a ponte para APIs REST, aplicações web, microsserviços, integração com nuvem, processamento orientado a objetos e experiências digitais modernas.
Hoje, quando um cliente consulta o saldo pelo aplicativo do banco, dificilmente percebe a sofisticada cadeia tecnológica envolvida. Um JSON percorre uma API REST hospedada em Open Liberty, passa por classes Java, utiliza JDBC para acessar o DB2 ou aciona um programa COBOL via CICS. Em segundos, o resultado retorna ao celular com segurança, integridade transacional e disponibilidade próxima de 100%.
Esse é o verdadeiro espírito do IBM Z moderno: não substituir o legado, mas ampliá-lo. Java, COBOL, CICS, DB2, JCL, LinuxONE, APIs e containers deixaram de ser tecnologias concorrentes e passaram a formar um único ecossistema. É justamente essa capacidade de integrar décadas de investimento com inovação contínua que mantém o Mainframe como a espinha dorsal de alguns dos maiores sistemas financeiros, governamentais e corporativos do planeta. E, para o profissional de Mainframe que aprende Java, abre-se uma nova fronteira: compreender não apenas como cada tecnologia funciona isoladamente, mas como elas conversam para sustentar o mundo digital moderno.
