✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes

Mostrar mensagens com a etiqueta JDBC. Mostrar todas as mensagens

sexta-feira, 23 de dezembro de 2022

Java no IBM Z: Como Java Conversa com COBOL, DB2, CICS e o Mundo Mainframe na Prática

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

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

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

LocalDateTime

Boolean

COBOL tradicional não possui boolean.

Normalmente usa:

"S"

"N"

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

↓

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

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.

quarta-feira, 14 de dezembro de 2022

Db2 Connect e a Banheira do Tempo — Quando Quatro Programadores Voltaram a 1986, Encontraram um JDBC no Fliperama e Descobriram que TCP/IP Não Sabia Executar SELECT

Bellacosa Mainframe e o db2 connect e a banheira do tempo

☕ Um Café no Bellacosa Mainframe

Db2 Connect e a Banheira do Tempo — Quando Quatro Programadores Voltaram a 1986, Encontraram um JDBC no Fliperama e Descobriram que TCP/IP Não Sabia Executar `SELECT`

Ou: o jovem padawan COBOL entrou numa banheira instalada ao lado do datacenter, Igor derramou energético sobre o painel do DDF, o Db2 for z/OS abriu um DBAT e todos descobriram que conexão, sessão, transação e pacote não são quatro nomes para a mesma coisa

Prólogo — A banheira que apontava para o mainframe

Era sexta-feira, 23h47, no datacenter Bellacosa Mainframe.

O processamento noturno já havia começado, o café estava com gosto de óleo hidráulico e Igor acabara de instalar uma banheira de hidromassagem ao lado do rack de desenvolvimento.

— Para reduzir o estresse da equipe — explicou ele, segurando um cabo de rede molhado.

Sobre a borda da banheira havia um notebook executando uma aplicação Java. Na tela, uma mensagem nada relaxante:

ERRORCODE=-4499
SQLSTATE=08001

A aplicação precisava consultar uma tabela no Db2 for z/OS, mas não conseguia estabelecer a conexão.

O jovem padawan COBOL examinou o diagrama preso na parede:

Aplicação → API → TCP/IP → Db2

— Parece simples. Se o ping funciona, o banco deveria funcionar.

Nesse instante, Igor deixou cair uma lata de energético sobre o controlador da banheira. As luzes piscaram, o ventilador do mainframe mudou de tom e os três foram transportados para 1986.

Quando abriram os olhos, havia terminais verdes, cabelos volumosos, fitas cassete e um operador perguntando:

— Que negócio é esse de JDBC? É uma banda de rock?

Aquela viagem ensinaria uma lição importante:

Um diagrama simples pode apresentar a direção da estrada, mas não explica quem dirige o carro, qual idioma é falado na fronteira, quem verifica o passaporte e quem executa a SQL quando todos finalmente chegam ao Db2.

1. O que é Db2 Connect?

Db2 Connect é a família de recursos, drivers, clientes, componentes e direitos de uso que permite a aplicações distribuídas acessar bancos Db2 executados principalmente em plataformas host, como:

Db2 for z/OS;
Db2 for IBM i;
Ambientes host compatíveis previstos pela solução;
Outros servidores Db2 suportados, conforme produto, versão e driver.

Imagine uma aplicação Java executada em Linux que precisa consultar uma conta bancária armazenada no Db2 for z/OS.

Os dois sistemas vivem em mundos diferentes:

Aplicação Java
Linux
JDBC
Objetos Java
UTF-8
Containers

Do outro lado:

Db2 for z/OS
DDF
DBAT
Packages
RACF
WLM
Tablespaces

Db2 Connect participa da construção da ponte entre esses mundos.

Mas aqui começa a primeira armadilha: Db2 Connect não é apenas “um conversor de TCP/IP”.

TCP/IP é o transporte. Ele entrega bytes de um endereço a outro. Não conhece:

SELECT;
INSERT;
Cursor;
Package;
COMMIT;
ROLLBACK;
SQLCODE;
Result set;
Unidade de trabalho.

O diálogo de banco utiliza principalmente o DRDA — Distributed Relational Database Architecture. A IBM define Db2 Connect como uma implementação da arquitetura DRDA para acesso distribuído a servidores Db2. IBM — Db2 Connect e DRDA

A arquitetura básica não é apenas:

Aplicação → TCP/IP → Db2

É mais próxima de:

Aplicação
    ↓
API
    ↓
Driver IBM
    ↓
DRDA
    ↓
TLS, quando configurado
    ↓
TCP/IP
    ↓
DDF
    ↓
DBAT
    ↓
Package e SQL
    ↓
Dados

O infográfico original mostra o portal da máquina do tempo. Nosso trabalho é abrir a tampa e descobrir quais peças fazem a viagem acontecer.

2. Aplicação, linguagem, API e driver não são a mesma coisa

O diagrama coloca no mesmo bloco:

JDBC;
ADO.NET;
Python;
SQL;
ODBC;
Db2 CLI;
Perl;
OLE DB;
Embedded SQL;
Ruby.

O problema é que esses elementos pertencem a categorias diferentes.

Categoria	Exemplos	O que representa
Linguagem	Java, Python, Ruby, Perl, PHP, COBOL	Linguagem em que o programa foi escrito
API	JDBC, ODBC, CLI, ADO.NET	Interface usada pelo programa para solicitar serviços do banco
Driver	IBM JCC, IBM ODBC/CLI Driver, IBM .NET Provider	Implementação que conversa efetivamente com o Db2
Linguagem de banco	SQL	Forma de consultar e alterar os dados
Técnica de programação	Embedded SQL, SQLJ	Forma de incorporar SQL ao programa

Dizer que Python, JDBC e SQL são todos “APIs” seria como dizer que COBOL, CICS e EXEC CICS READ são a mesma coisa.

Eles cooperam, mas exercem funções diferentes.

Exemplo Java

Connection conn = DriverManager.getConnection(
    "jdbc:db2://db2host.empresa.com:448/DBP1",
    usuario,
    senha
);

Neste exemplo:

Java é a linguagem;
JDBC é a API;
O IBM Data Server Driver for JDBC and SQLJ implementa a comunicação;
A URL descreve o destino;
DRDA organiza o diálogo com o servidor;
TCP/IP transporta as mensagens.

Exemplo Python

import ibm_db

conexao = ibm_db.connect(
    "DATABASE=DBP1;"
    "HOSTNAME=db2host.empresa.com;"
    "PORT=448;"
    "PROTOCOL=TCPIP;"
    "UID=APPUSER;"
    "PWD=senha;",
    "",
    ""
)

Python continua sendo a linguagem. O módulo e o driver cuidam do acesso. Depois, a aplicação pode executar SQL:

sql = """
    SELECT NOME, SALDO
      FROM CLIENTE
     WHERE ID_CLIENTE = 100
"""

stmt = ibm_db.exec_immediate(conexao, sql)

Exemplo COBOL

EXEC SQL
    SELECT NOME,
           SALDO
      INTO :WS-NOME,
           :WS-SALDO
      FROM CLIENTE
     WHERE ID_CLIENTE = :WS-ID-CLIENTE
END-EXEC.

COBOL é a linguagem. SQL é a linguagem de banco. EXEC SQL delimita o comando embutido. O programa ainda precisa passar por pré-compilação, compilação, linkedição e preparação dos componentes Db2.

O jovem padawan deve guardar:

A API é o painel da banheira. O driver é a máquina escondida embaixo dela. DRDA é o manual de comunicação temporal. TCP/IP é o túnel. O Db2 é o destino.

3. O personagem que o infográfico esqueceu: o driver

O driver é um dos componentes mais importantes da arquitetura.

Ele:

Implementa JDBC, ODBC, CLI ou .NET;
Converte chamadas da aplicação em mensagens entendidas pelo servidor;
Monta e interpreta o protocolo DRDA;
Converte tipos de dados;
Entrega result sets;
Envia COMMIT e ROLLBACK;
Controla propriedades de timeout;
Participa de pooling e concentração de conexões;
Pode colaborar com automatic client reroute;
Pode colaborar com Sysplex workload balancing;
Negocia capacidades com o servidor;
Reporta SQLCODE, SQLSTATE e erros de comunicação.

A IBM distribui drivers e clientes diferentes para JDBC/SQLJ, ODBC/CLI, .NET, OLE DB e outras interfaces. IBM — Tipos de clientes e drivers

Por isso, ao atualizar um driver, não estamos apenas trocando “um arquivo .jar qualquer”.

A atualização pode alterar:

Suporte a TLS;
Conversão de timestamps;
Tipos de dados suportados;
Propriedades de failover;
Comportamento de timeouts;
Pacotes utilizados no servidor;
Recursos de compatibilidade;
Balanceamento no Sysplex.

Uma aplicação pode funcionar com determinada versão do driver em homologação e falhar em produção porque os pacotes correspondentes não foram preparados no Db2 for z/OS.

Easter egg número 1: se Igor disser “é só trocar o db2jcc4.jar escondido e ninguém perceberá”, esconda a senha do RACF e chame o change manager.

4. TCP/IP é a estrada; DRDA é o idioma

Durante a viagem de volta a 1986, o jovem padawan viu um telefone público.

Igor levantou o aparelho e começou a falar COBOL com a telefonista.

— MOVE TELEFONISTA TO WS-CONEXAO.

A telefonista desligou.

O telefone funcionava. A linha estava ativa. Mas ninguém falava o mesmo idioma.

Essa é a diferença entre TCP/IP e DRDA.

TCP/IP estabelece o transporte confiável e ordenado entre endpoints. DRDA define como clientes e servidores de bancos relacionais distribuem solicitações e respostas.

Uma forma didática de separar as camadas é:

SQL          → O que queremos fazer
API          → Como a aplicação solicita
Driver       → Quem implementa a solicitação
DRDA         → Como cliente e Db2 conversam
TLS          → Como o conteúdo pode ser protegido
TCP/IP       → Como os bytes viajam

Por isso, executar:

ping db2host

e receber resposta não prova que o Db2 funciona.

O ping pode confirmar que algum caminho IP está disponível, mas não confirma:

Que a porta do DDF está aberta;
Que o listener está ativo;
Que o firewall permite o tráfego da aplicação;
Que o TLS consegue negociar;
Que o certificado é confiável;
Que o usuário consegue autenticar;
Que o location name está correto;
Que os pacotes existem;
Que o usuário possui autorização;
Que a SQL pode ser executada.

É como chegar à cidade correta e concluir que sua reserva no hotel está garantida.

5. No z/OS, quem abre o portal é o DDF

Quando o destino é Db2 for z/OS, entra em cena o:

DDF — Distributed Data Facility

O DDF é o componente que permite ao Db2 for z/OS participar do processamento distribuído, recebendo e iniciando comunicações com sistemas remotos.

Para uma aplicação externa estabelecer uma conexão, o DDF precisa estar:

Instalado e configurado;
Ativo;
Associado a portas TCP/IP;
Publicado no endereço correto;
Integrado à segurança;
Preparado para o protocolo utilizado.

A IBM deixa claro que o subsistema Db2 for z/OS precisa ter o DDF habilitado para receber conexões JDBC por TCP/IP. IBM — JDBC acessando Db2 for z/OS

No diagnóstico, dois comandos são particularmente conhecidos:

-DISPLAY DDF DETAIL

-DISPLAY LOCATION

Eles podem ajudar a verificar informações como:

Estado do DDF;
Location name;
Endereços;
Portas;
Informações de comunicação;
Características do ambiente distribuído.

Se o DDF estiver parado, a aplicação poderá enxergar o host, alcançar o z/OS e mesmo assim não falar com o Db2.

Easter egg número 2: no filme, a banheira precisava de uma combinação improvável de água, energia e bebida derramada. No datacenter, DDF não deve depender de Igor derramando energético no console.

6. DBAT: o funcionário que recebe o visitante

Depois que a conexão chega ao DDF, o trabalho precisa ser processado. Entra o:

DBAT — Database Access Thread

O DBAT é uma thread de acesso ao banco utilizada no processamento de solicitações distribuídas.

Imagine a recepção de um hotel:

A conexão é o hóspede;
DDF é a recepção;
A autenticação verifica o documento;
O DBAT é o funcionário que atende a solicitação;
O package define determinados recursos e regras de execução;
O Db2 acessa os dados.

Uma conexão lógica não significa necessariamente um DBAT permanentemente dedicado.

O Db2 for z/OS pode utilizar pooling de DBATs. Depois de uma unidade de trabalho, um DBAT elegível pode ser liberado para atender outra conexão. Isso reduz o consumo de recursos em ambientes com grandes quantidades de conexões remotas. IBM — Gerenciamento de DBATs

Também existem high-performance DBATs. Nesse caso, o DBAT permanece associado à conexão através das fronteiras de transação, reduzindo determinados custos de liberação e reassociação, mas mantendo recursos dedicados por mais tempo. IBM — Como DBATs processam conexões remotas

Portanto:

Conexão ≠ DBAT permanentemente ativo

Essa diferença torna-se crucial quando containers entram na história.

Suponha:

50 pods
× 100 conexões máximas
= 5.000 conexões potenciais

Agora o Kubernetes faz autoscaling:

200 pods
× 100 conexões
= 20.000 conexões potenciais

O desenvolvedor olha para uma configuração e pensa:

“Cem conexões é um número pequeno.”

O Db2 olha para o conjunto e vê vinte mil visitantes atravessando o portal temporal.

7. Conexão direta ou servidor Db2 Connect?

Nas arquiteturas antigas, era comum encontrar:

Aplicação
    ↓
Servidor Db2 Connect
    ↓
Db2 for z/OS

O servidor Db2 Connect funcionava como um ponto intermediário de conectividade.

Essa arquitetura ainda pode fazer sentido em situações específicas:

Centralização de determinados componentes;
Ambientes com requisitos legados;
Federation;
Monitores transacionais;
Necessidades operacionais específicas;
Administração concentrada.

Mas não é obrigatório colocar um gateway intermediário em todos os cenários.

Muitas aplicações modernas utilizam:

Aplicação + driver IBM
    ↓
DRDA/TCP/IP
    ↓
Db2 for z/OS

A própria IBM recomenda conexão direta por cliente ou driver em muitos ambientes, reduzindo a necessidade de uma máquina intermediária. IBM — Opções de conexão cliente-servidor

Conexão direta

Vantagens:

Menos saltos de rede;
Menor latência;
Menos infraestrutura intermediária;
Diagnóstico potencialmente mais simples;
Recursos implementados diretamente pelo driver.

Cuidados:

Controle de versões dos drivers;
Distribuição de certificados;
Configuração em múltiplos servidores;
Licenciamento;
Padronização entre equipes.

Gateway Db2 Connect

Vantagens possíveis:

Ponto central de conectividade;
Administração concentrada;
Suporte a arquiteturas específicas;
Menor dispersão de certas configurações.

Cuidados:

Mais um salto;
Mais um componente monitorado;
Possível gargalo;
Possível ponto único de falha;
Maior cadeia de diagnóstico.

Um gateway não é automaticamente ruim. Conexão direta não é automaticamente melhor. A escolha deve nascer dos requisitos, não da nostalgia de um diagrama de 1998.

8. O que acontece durante um `SELECT`?

Considere:

SELECT NOME,
       LIMITE_CREDITO
  FROM CLIENTE
 WHERE CPF = ?

A aplicação Java executa algo aparentemente simples:

ResultSet rs = statement.executeQuery();

Por baixo dessa linha, a banheira do tempo entra em funcionamento:

A requisição da aplicação precisa de uma conexão;
A aplicação solicita essa conexão ao pool;
O pool entrega uma conexão existente ou cria outra;
JDBC recebe a solicitação;
O driver IBM converte os parâmetros;
O driver monta a conversa DRDA;
TLS pode proteger o tráfego;
TCP/IP transporta as mensagens;
DDF recebe a requisição no z/OS;
O usuário é autenticado;
A conexão é associada a um DBAT;
O Db2 identifica o package e o contexto;
As autorizações são verificadas;
A SQL é preparada ou localizada;
O access path é utilizado;
Os dados são lidos;
As linhas retornam por DRDA;
O driver converte os tipos;
JDBC entrega o ResultSet;
A aplicação consome os registros;
COMMIT ou ROLLBACK encerra a unidade de trabalho;
A conexão pode retornar ao pool.

Portanto, “tempo da query” pode significar coisas diferentes:

Espera pelo pool;
Abertura da conexão;
Autenticação;
Negociação TLS;
Transporte de rede;
Espera por DBAT;
Espera por WLM;
Prepare;
Execução;
Locks;
Fetch das linhas;
Conversão no driver;
Processamento na aplicação.

Quando alguém disser “o Db2 demorou oito segundos”, primeiro descubra onde os oito segundos foram gastos.

9. Packages: o detalhe que aparece quando chega o `-805`

Uma conexão pode alcançar o host, atravessar a porta, autenticar o usuário e ainda assim falhar.

Um erro clássico é:

SQLCODE -805
SQLSTATE 51002

Ele normalmente indica que um package necessário não foi encontrado, não está disponível no contexto esperado ou não corresponde ao que está sendo solicitado.

Drivers JDBC e CLI utilizam packages preparados no servidor. A collection NULLID aparece frequentemente nesses ambientes.

A IBM disponibiliza, por exemplo, o utilitário DB2Binder para vincular packages utilizados pelo IBM Data Server Driver for JDBC and SQLJ no Db2 for z/OS. IBM — DB2Binder

É possível também trabalhar com collections diferentes e níveis distintos de APPLCOMPAT.

Exemplo conceitual:

NULLID
NULLID_V12R1M500
NULLID_V12R1M501

Cada collection pode representar uma combinação planejada de packages e compatibilidade.

Isso permite que uma aplicação nova utilize determinadas capacidades sem obrigar todas as aplicações antigas a avançarem imediatamente.

Dica de produção:

Antes de atualizar o driver, confirme quais packages serão necessários, quem realizará o bind, quais opções serão usadas e como será feito o rollback.

Atualizar o .jar e esquecer o servidor é uma maneira elegante de transformar uma melhoria técnica em incidente noturno.

10. `COMMIT`, `ROLLBACK` e a viagem que talvez já tenha acontecido

Considere uma transferência:

UPDATE CONTA
   SET SALDO = SALDO - 100
 WHERE CONTA_ID = 10;

UPDATE CONTA
   SET SALDO = SALDO + 100
 WHERE CONTA_ID = 20;

As duas operações precisam pertencer à mesma unidade de trabalho.

Em JDBC:

connection.setAutoCommit(false);

try {
    debitar.executeUpdate();
    creditar.executeUpdate();
    connection.commit();
} catch (Exception e) {
    connection.rollback();
    throw e;
}

O commit() não acontece apenas dentro da aplicação Java. A solicitação precisa viajar até o servidor e ser processada pelo Db2.

Agora imagine:

A aplicação envia o COMMIT;
O Db2 recebe;
O Db2 confirma a transação;
A resposta retorna;
A rede cai antes de a aplicação receber a confirmação.

A aplicação pode concluir:

“Não recebi sucesso; tentarei novamente.”

Mas o Db2 talvez já tenha confirmado.

Se o retry repetir a operação inteira, podemos debitar o cliente duas vezes.

Esse é o lado realmente perigoso das falhas distribuídas: nem sempre sabemos imediatamente se a viagem temporal ocorreu.

Por isso, operações críticas precisam considerar:

Idempotência;
Identificador único de transação;
Controle de duplicidade;
Reconciliação;
Logs técnicos e de negócio;
Estado desconhecido após falhas;
Estratégias específicas de retry.

Retry não é GO TO TENTE-NOVAMENTE aplicado cegamente a qualquer erro.

11. Pool de conexões: o táxi que retorna à praça

Abrir uma conexão para cada requisição custa caro. Por isso, servidores de aplicações normalmente mantêm pools.

Requisição
    ↓
Solicita conexão
    ↓
Pool entrega uma conexão
    ↓
Aplicação executa SQL
    ↓
Commit ou rollback
    ↓
Conexão retorna ao pool

O problema surge quando a aplicação devolve a conexão em estado inadequado.

Ela pode retornar com:

Transação aberta;
Cursor abandonado;
Isolation level alterado;
CURRENT SCHEMA modificado;
Registros especiais alterados;
Erro não tratado;
Estado inválido após falha de comunicação.

Exemplo:

SET CURRENT SCHEMA = FINANCEIRO;

Se a aplicação devolve a conexão sem restaurar o estado, o próximo usuário pode herdar aquela configuração.

O pool é como um táxi reutilizado. O próximo passageiro não deveria encontrar no banco traseiro:

A carteira do anterior;
Uma transação aberta;
Um cursor;
O schema financeiro;
Nem Igor tentando voltar a 1986.

Boas práticas incluem:

Sempre fechar recursos;
Usar blocos try-with-resources;
Executar rollback em exceções;
Configurar validação de conexões;
Definir timeouts;
Dimensionar mínimo e máximo;
Monitorar espera pelo pool;
Evitar pools enormes em cada instância;
Considerar o total agregado de containers.

12. Segurança: TCP/IP não é colete à prova de balas

A existência de uma conexão TCP/IP não garante que seu conteúdo esteja protegido.

No Db2 for z/OS, TLS pode ser implementado com participação do z/OS Communications Server e AT-TLS. O SECPORT pode identificar a porta utilizada para conexões seguras. IBM — TLS no Db2 for z/OS

Devemos separar quatro perguntas:

Quem é você?

Autenticação:

Usuário e senha;
RACF PassTicket;
Kerberos;
Outros mecanismos previstos pela arquitetura.

A conversa está protegida?

Transporte:

TLS;
Certificados;
Truststore;
Cipher suites;
AT-TLS;
Políticas de rede.

O que você pode fazer?

Autorização:

SELECT;
INSERT;
UPDATE;
DELETE;
EXECUTE em package;
EXECUTE em stored procedure;
Uso de uma collection.

Quem é a aplicação?

Identificação operacional:

Application name;
Workstation;
Client user;
Accounting string;
Correlation ID.

Sem identificação adequada, o monitoramento pode apresentar centenas de conexões chamadas simplesmente de:

db2jcc_application

É como receber 500 viajantes temporais e registrar todos como “Igor”.

13. Por que uma SQL rápida no SPUFI pode ser lenta no Java?

Essa comparação aparece frequentemente:

“No SPUFI leva meio segundo; no Java leva dez segundos. Logo, Java ou Db2 Connect está lento.”

Talvez. Mas ainda não foi provado.

Compare:

A SQL é exatamente igual?
Os valores dos parâmetros são iguais?
O usuário é o mesmo?
O schema é o mesmo?
O package é o mesmo?
O APPLCOMPAT é igual?
O isolation level é igual?
A aplicação executa apenas uma SQL?
O tempo inclui espera no pool?
Há latência de rede?
Quantas linhas retornam?
Qual é o fetch size?
A aplicação processa cada linha lentamente?
Existe gateway intermediário?
Há conversões de tipos?
A conexão foi aberta durante a medição?

SPUFI e aplicação distribuída podem usar caminhos operacionais muito diferentes.

A aplicação talvez faça:

1 consulta para obter clientes
+ 1 consulta para cada cliente

Para mil clientes:

1 + 1.000 = 1.001 SQLs

Esse é o conhecido problema N+1.

O Db2 pode executar cada consulta rapidamente, mas a aplicação acumula mil viagens de rede.

O relatório final dirá “Db2 lento”. O Db2, inocente, estará apenas respondendo mil vezes à mesma insistência.

14. Fetch size: quantas malas entram em cada viagem?

Se uma consulta retorna 100 mil linhas, trazê-las uma por uma pode ser desastroso.

Imagine:

100.000 linhas
÷ 10 linhas por bloco
= 10.000 trocas

Com blocos de cem linhas:

100.000
÷ 100
= 1.000 trocas

Ajustar fetch size e blocagem pode reduzir viagens, mas aumentar indiscriminadamente também não é solução.

Blocos maiores podem:

Consumir mais memória;
Aumentar o volume transferido antecipadamente;
Ser desperdiçados se a aplicação abandonar o cursor;
Pressionar o heap do servidor.

O ajuste deve considerar:

Tamanho médio da linha;
Volume do resultado;
Latência;
Memória disponível;
Padrão de consumo;
Necessidade real do usuário.

A melhor otimização pode ser não buscar 100 mil linhas.

Às vezes, a solução correta é:

FETCH FIRST 100 ROWS ONLY

ou implementar paginação adequada.

15. Data Sharing, Sysplex e a banheira com várias saídas

Em um Db2 Data Sharing Group, vários membros podem atender o workload.

Aplicação
    ↓
Driver com recursos de disponibilidade
    ↓
Location do grupo
    ↓
DB2A / DB2B / DB2C

O driver pode colaborar com:

Sysplex workload balancing;
Automatic client reroute;
Failover;
Afinidade;
Concentração de transporte.

Mas esses recursos precisam ser planejados e configurados. Não surgem apenas porque alguém escreveu “HA” no PowerPoint.

Também é importante compreender:

Reconectar não significa continuar uma transação interrompida exatamente de onde ela parou.

O driver pode encontrar outro membro disponível, mas a aplicação ainda precisa tratar:

Unidade de trabalho anterior;
Commit de resultado incerto;
Cursores perdidos;
Estado da sessão;
Reexecução segura.

Alta disponibilidade reduz interrupções. Não revoga as leis do processamento distribuído.

16. Mapa rápido dos erros

Sintoma	Camada provável	O que verificar
Host desconhecido	DNS	Nome e resolução
`Connection refused`	TCP/DDF	Porta, listener, firewall
Timeout de conexão	Rede	Rota, firewall, endereço
Falha de handshake	TLS	Certificado, truststore, cipher
Usuário inválido	Segurança	Credencial, RACF, método
`SQLCODE -805`	Package	Collection, bind, versão
`SQLCODE -551`	Autorização	Privilégios
`SQLCODE -911/-913`	Concorrência	Lock, deadlock, timeout
`SQLCODE -904`	Recurso	Reason code e resource name
`SQL30081N`	Comunicação	Protocolo, socket e códigos
`-4499`	JDBC/comunicação	Exceções encadeadas e timeout
Muitas conexões ociosas	Pool	Mínimo, máximo e total agregado
Lentidão intermitente	Várias	Pool, DBAT, WLM, lock, rede

Nunca pare na primeira mensagem genérica.

Em JDBC, investigue as exceções encadeadas. Registre:

SQLCODE;
SQLSTATE;
Reason code;
Timestamp;
Host de origem;
Nome da aplicação;
Versão do driver;
Correlation ID;
URL sem senha;
Operação executada;
Estado da transação.

17. Passo a passo do jovem padawan COBOL

Passo 1 — Desenhe o caminho real

Aplicação
→ servidor
→ driver
→ gateway, se houver
→ firewall
→ porta
→ DDF
→ Db2

Não use o desenho idealizado. Use o caminho de produção.

Passo 2 — Identifique o driver

Descubra:

Nome;
Versão;
Arquivo;
Configuração;
Compatibilidade;
Licença aplicável.

Passo 3 — Confirme host, porta e location

Não confunda:

Nome DNS;
Nome do subsistema;
Location name;
Alias;
Nome do data sharing group;
Database da URL JDBC.

Passo 4 — Teste a rede

Verifique:

DNS;
Rota;
Porta;
Firewall;
Origem real da aplicação.

O teste deve ser executado a partir do servidor onde o programa roda, não do notebook do analista.

Passo 5 — Verifique TLS

Confirme:

Porta segura;
Validade do certificado;
Cadeia de confiança;
Truststore;
Nome do host;
Política AT-TLS.

Passo 6 — Verifique DDF

No z/OS:

DDF está ativo?
A porta está correta?
O location está correto?
Existem mensagens DSNL?
A conexão chega?

Passo 7 — Verifique autenticação

Pergunte:

O usuário existe?
Está revogado?
A credencial expirou?
O método é compatível?
O RACF registrou falha?

Passo 8 — Verifique packages

Se houver -805:

Qual package?
Qual collection?
Qual versão do driver?
Houve atualização?
O bind foi feito?
O APPLCOMPAT é compatível?

Passo 9 — Verifique autorização

Se houver -551:

Qual authid?
Qual objeto?
Qual operação?
A autorização é direta ou por papel?
O usuário pode executar o package?

Passo 10 — Verifique a unidade de trabalho

Autocommit está ativo?
Existe commit explícito?
O rollback é garantido?
A conexão volta limpa ao pool?
Há transações longas?

Passo 11 — Verifique performance

Espera no pool;
Tempo de conexão;
Tempo de SQL;
Tempo de fetch;
Tempo da aplicação;
Lock;
DBAT;
WLM;
Número de viagens.

Passo 12 — Documente o resultado

Uma solução que vive apenas na memória do analista sofrerá um DELETE quando ele sair de férias.

18. Curiosidades escondidas na banheira

Curiosidade 1 — O nome histórico pode denunciar a idade do desenho

O infográfico usa “Db2 for i5/OS”. A nomenclatura atual é Db2 for IBM i.

Também aparece algo parecido com “Db2 for x/OS”, provavelmente um erro gráfico para Db2 for z/OS.

Curiosidade 2 — SQL não é API de transporte

SQL descreve operações relacionais. JDBC, ODBC e CLI oferecem interfaces para a aplicação. O driver transforma essas chamadas em comunicação com o servidor.

Curiosidade 3 — “Conectou” não significa “funcionou”

Existem vários marcos:

Host respondeu
≠ porta abriu
≠ TLS negociou
≠ usuário autenticou
≠ package foi encontrado
≠ autorização concedida
≠ SQL executou
≠ commit confirmou

Curiosidade 4 — O nome da aplicação é recurso de produção

Preencher corretamente os atributos do cliente ajuda:

Accounting;
WLM;
Monitoramento;
Profile tables;
Diagnóstico;
Chargeback;
Identificação de ofensores.

Curiosidade 5 — O erro mais perigoso pode vir depois do sucesso

A SQL pode ter sido executada e confirmada, mas a resposta pode ter se perdido. Isso cria estado incerto e torna retries cegos particularmente perigosos.

Curiosidade 6 — Microserviço não reduz automaticamente o consumo

Transformar um monólito em cem containers pode multiplicar:

Pools;
Conexões;
Certificados;
Logs;
Timeouts;
Pontos de falha;
Viagens ao Db2.

A arquitetura ficou distribuída. O bom senso também precisa ser.

19. O mapa mental definitivo

Quando uma aplicação distribuída acessa Db2 for z/OS, pense nesta sequência:

A aplicação pede
A API formaliza
O driver traduz
DRDA organiza
TLS protege
TCP/IP transporta
DDF recebe
RACF autentica
WLM classifica
DBAT trabalha
O package sustenta
Db2 executa
O cursor entrega
COMMIT confirma
O pool reutiliza
A monitoração conta a história

Se cada componente possuir dono, versão, configuração, métrica e procedimento, a arquitetura será administrável.

Se tudo for chamado genericamente de “Db2 Connect”, o incidente será uma excursão temporal sem mapa.

Epílogo — Ninguém voltou para 1986, mas o chamado foi encerrado

De volta ao datacenter, o jovem padawan COBOL examinou novamente o erro:

ERRORCODE=-4499
SQLSTATE=08001

Dessa vez ele não começou pelo SELECT.

Primeiro confirmou:

O servidor de origem;
A versão do driver;
O hostname;
A porta segura;
A cadeia de certificados;
O status do DDF;
As mensagens no z/OS.

Descobriu que o certificado havia sido renovado no servidor, mas o truststore da aplicação ainda continha a cadeia anterior.

A rede funcionava.

O DDF funcionava.

O Db2 funcionava.

A SQL nunca havia chegado ao banco.

Igor olhou para a banheira e perguntou:

— Então podemos colocá-la em produção?

O padawan respondeu:

IF IGOR-IN-PRODUCTION
    MOVE 'N' TO APPROVAL-FLAG
    PERFORM CHAMAR-CHANGE-MANAGER
END-IF

A maior lição daquela noite não foi apenas aprender o que Db2 Connect faz.

Foi compreender que arquiteturas distribuídas são formadas por contratos encadeados. Cada camada promete alguma coisa à camada seguinte:

A aplicação promete usar corretamente a API;
O driver promete implementar a conversa;
DRDA promete organizar o diálogo;
TCP/IP promete transportar;
TLS promete proteger;
DDF promete receber;
DBAT promete processar;
O Db2 promete preservar integridade;
A aplicação promete saber quando confirmar ou desfazer.

Quando uma promessa é quebrada, o erro aparece em algum lugar da cadeia — nem sempre no lugar onde nasceu.

Db2 Connect, portanto, não é uma simples ponte entre um computador e um banco.

É uma máquina do tempo cuidadosamente controlada: leva aplicações escritas hoje até dados acumulados durante décadas, permite que Java, Python, .NET, ferramentas ODBC e sistemas modernos conversem com o Db2 for z/OS e demonstra que o mainframe não está preso ao passado.

O passado continua em produção.

E, ao contrário da banheira de Igor, processa bilhões de transações sem derramar energético no DDF.

sábado, 2 de janeiro de 2021

☕💣🚀 PADAWAN, O IMS NÃO PRECISA SER SUBSTITUÍDO. ELE PRECISA SER LIBERTADO: As 4 Estradas da Transformação Digital no IMS

Bellacosa Mainframe evoluindo em IMS 4 vias para crescer mais

☕💣🚀 PADAWAN, O IMS NÃO PRECISA SER SUBSTITUÍDO. ELE PRECISA SER LIBERTADO!

As 4 Estradas da Transformação Digital no IMS: APIs, Java, SQL e DevOps na Visão da IBM

Quando alguém fala em transformação digital, normalmente surgem palavras como Cloud, Kubernetes, APIs, Microservices, DevOps, Inteligência Artificial e OpenShift.

Logo depois aparece alguém apontando para o mainframe e dizendo:

"Precisamos substituir tudo isso porque é legado."

E é exatamente nesse momento que começam alguns dos projetos mais caros, demorados e arriscados da história da TI corporativa.

O material da IBM "The 4 Paths to Digital Transformation in IMS", apresentado por Haley Fung, mostra uma visão radicalmente diferente. Em vez de substituir o IMS, a estratégia proposta é transformá-lo em um participante ativo do ecossistema digital moderno.

A mensagem principal do documento é simples:

O problema não é o IMS.
O problema é quando o IMS fica isolado.

Durante décadas, o IMS foi responsável por processar algumas das cargas mais críticas do planeta. Bancos, seguradoras, governos, operadoras de telecomunicações e empresas aéreas construíram seus negócios sobre ele.

E agora?

Agora a IBM mostra quatro caminhos principais para trazer o IMS para a era digital:

APIs
Java
Open Database (SQL/JDBC)
DevOps e Cloud

Vamos mergulhar profundamente em cada um deles.

O GRANDE MITO: MODERNIZAR NÃO É REESCREVER

Uma das maiores mentiras da indústria é:

Modernizar = Reescrever.

Não.

A IBM deixa claro que o objetivo é preservar o ativo mais valioso:

Dados
Regras de negócio
Processos transacionais
Disponibilidade
Segurança

Tudo isso já existe dentro do IMS.

A pergunta correta não é:

Como substituir o IMS?

Mas sim:

Como conectar o IMS ao mundo moderno?

Essa diferença de mentalidade pode representar milhões de dólares economizados.

A PRIMEIRA ESTRADA: API-ENABLE EVERYTHING

Transformando transações IMS em APIs REST

Durante décadas, acessar uma transação IMS exigia:

3270
MQ
Sockets proprietários
Middleware especializado

Para um desenvolvedor React, Angular ou Mobile isso parece arqueologia.

A solução apresentada pela IBM é simples:

Transformar ativos IMS em APIs REST.

z/OS Connect Enterprise Edition

O protagonista dessa transformação é:

IBM z/OS Connect EE

Ele permite expor:

Transações IMS TM
Dados IMS DB
Aplicações COBOL
Serviços z/OS

como APIs REST modernas.

O cenário tradicional

Imagine um banco.

Aplicação Mobile
↓
Middleware
↓
Gateway Proprietário
↓
MQ
↓
IMS

Múltiplas camadas.

Complexidade.

Custos.

O cenário moderno

Aplicação Mobile
↓
REST API
↓
z/OS Connect
↓
IMS

Muito mais simples.

Muito mais rápido.

Muito mais alinhado ao mercado.

O FIM DA DEPENDÊNCIA DE ESPECIALISTAS MAINFRAME

Uma observação extremamente interessante da IBM:

Não é necessário conhecimento profundo de mainframe para consumir APIs IMS.

Isso muda completamente a equação.

Um desenvolvedor Node.js pode consumir uma API IMS da mesma forma que consome:

Salesforce
SAP
Oracle Cloud
AWS

Sem saber o que é um PCB.

Sem saber o que é um GU.

Sem saber o que é um PSB.

IMS DE CENTRO DE CUSTO PARA CENTRO DE RECEITA

Essa é uma frase poderosa do material:

Converter IMS de Cost Center para Revenue Center.

Historicamente o IMS era visto como:

Custo operacional
Infraestrutura necessária

Com APIs ele passa a gerar novos negócios.

Exemplo:

Uma seguradora possui regras de cotação em IMS.

Em vez de reescrever tudo:

expõe APIs
integra parceiros
cria novos canais digitais

O IMS continua executando a regra.

O mercado passa a consumi-la.

CASOS REAIS DE SUCESSO

O documento apresenta diversos exemplos.

Um deles reduziu um processo de abertura de contas de:

3 dias
para
menos de 1 segundo.

Resultado:

5.500 novas contas
milhões em novos depósitos
centenas de horas economizadas

Tudo sem substituir o IMS.

A SEGUNDA ESTRADA: JAVA NO IMS

Agora chegamos ao tema mais polêmico.

Quando alguém fala:

Java no Mainframe

sempre surge alguém dizendo:

Isso não faz sentido.

Mas a IBM vem investindo nisso há mais de 15 anos.

POR QUE JAVA?

Porque existe um problema real.

Encontrar:

COBOL Developers
IMS Specialists
DL/I Experts

está cada vez mais difícil.

Enquanto isso existem milhões de desenvolvedores Java no mundo.

A IBM percebeu isso há muito tempo.

NÃO É COBOL VS JAVA

Esse é outro erro comum.

O documento não propõe eliminar COBOL.

Ele propõe:

COBOL + Java

Trabalhando juntos.

ESTRATÉGIA 1: EXTENDER APLICAÇÕES EXISTENTES

Imagine um programa COBOL IMS.

Você possui uma rotina extremamente pesada:

validação
criptografia
cálculo complexo

A IBM sugere mover partes específicas para Java.

Benefícios:

melhor manutenção
maior disponibilidade de profissionais
possibilidade de uso de frameworks modernos

ESTRATÉGIA 2: NOVAS APLICAÇÕES EM JAVA

Outra abordagem:

Criar novas aplicações IMS diretamente em Java.

O banco continua sendo IMS.

As transações continuam sendo IMS.

Mas a lógica é Java.

O SEGREDO CHAMADO zIIP

Aqui está uma das partes mais interessantes.

Java pode utilizar melhor os processadores especializados zIIP.

Para muitos ambientes isso significa:

menor consumo de MIPS
redução de custos
melhor escalabilidade

O MITO DA PERFORMANCE

Existe outro preconceito:

Java é lento.

A IBM apresenta benchmark demonstrando mais de:

25.000 transações por segundo

em workload Java sobre IMS.

Isso desmonta completamente a narrativa de que Java no Z seria apenas experimental.

O MODELO HÍBRIDO MAIS INTELIGENTE

O que muitos clientes estão fazendo?

COBOL continua cuidando do núcleo.

Java assume:

APIs
integrações
componentes modernos
novas funcionalidades

Resultado:

Baixo risco.

Alta velocidade.

A TERCEIRA ESTRADA: OPEN DATABASE

Agora chegamos ao assunto que faz muitos DBAs arregalarem os olhos.

IMS e SQL.

Sim.

IMS e SQL.

O FIM DO "IMS É FECHADO"

Durante muitos anos ouvimos:

IMS é fechado.

A IBM respondeu criando a estratégia Open Database.

JDBC DIRETO NO IMS

O modelo apresentado permite:

Aplicação Java
↓
JDBC
↓
IMS

Sem extrações complexas.

Sem replicações desnecessárias.

Sem ETLs gigantescos.

POR QUE ISSO É REVOLUCIONÁRIO?

Porque tradicionalmente o fluxo era:

IMS
↓
ETL
↓
Data Warehouse
↓
Analytics

Horas depois.

Às vezes dias depois.

Novo modelo

IMS
↓
SQL
↓
Analytics

Quase em tempo real.

IMS COMO FONTE DE IA E ANALYTICS

O material mostra integração com:

Apache Spark
IBM Machine Learning for z/OS
Db2 Analytics Accelerator

Tudo consumindo dados IMS.

Isso é enorme.

Porque o dado mais valioso da empresa geralmente está no IMS.

IMS CATALOG: A JOIA ESCONDIDA

Outro componente importante é o IMS Catalog.

Historicamente:

DBD
PSB
ACB

eram artefatos compreendidos por poucos especialistas.

O Catalog transforma isso em metadados mais acessíveis.

Resultado:

melhor governança
descoberta de dados
integração simplificada

DDL NO IMS

Uma das maiores mudanças modernas.

Desde o IMS 14:

CREATE DATABASE
CREATE TABLE
ALTER DATABASE

passaram a fazer parte do ecossistema IMS.

Para quem passou décadas vivendo apenas de:

DBDGEN
PSBGEN
ACBGEN

isso representa uma mudança cultural gigantesca.

O QUE ISSO SIGNIFICA PARA O DBA?

Significa que o DBA IMS moderno precisa conhecer:

Hierarquia
SQL
Metadata
APIs
Analytics

O perfil profissional está mudando.

A QUARTA ESTRADA: DEVOPS E CLOUD

Agora chegamos à transformação mais profunda.

O FIM DO DESENVOLVIMENTO MAINFRAME ISOLADO

Antigamente:

Desenvolvimento Distribuído
↓
Pipeline Moderno

Mainframe
↓
Mudanças manuais

Dois mundos separados.

A VISÃO DA IBM

Integrar o IMS ao pipeline corporativo.

Mesmas ferramentas.

Mesma metodologia.

Mesmo fluxo.

GIT NO MAINFRAME

O documento mostra integração com:

Git
Jenkins
Maven
Nexus
Artifactory

e outros componentes DevOps.

Hoje isso já é realidade em muitos ambientes.

WAZI

Uma das iniciativas mais interessantes mostradas no material.

IBM Wazi oferece:

VS Code
Eclipse
Red Hat CodeReady
OpenShift

para desenvolvimento z/OS.

O impacto cultural

O novo desenvolvedor pode trabalhar em:

VS Code

e desenvolver para IMS.

Algo impensável vinte anos atrás.

ANSIBLE NO IMS

Essa talvez seja a parte que mais chama atenção de Sysprogs.

A IBM apresenta coleções específicas Ansible para:

z/OS
IMS
automação operacional

IMS COMO INFRAESTRUTURA PROGRAMÁVEL

Imagine executar:

geração de DBD
geração de PSB
geração de ACB
comandos IMS

automaticamente.

O documento mostra exatamente isso através dos módulos:

ims_dbd_gen
ims_psb_gen
ims_acb_gen
ims_command

Para um Sysprog isso é quase ficção científica comparado ao modelo tradicional.

ZOWE: O NOVO ROSTO DO MAINFRAME

Outro destaque é o Zowe.

Ele fornece:

REST APIs
CLI
Automação

para administrar IMS.

Exemplos:

iniciar regiões
parar regiões
consultar transações
automatizar deploys

Tudo através de scripts modernos.

O IMS ESTÁ VIRANDO CLOUD?

Na prática...

Sim.

Ou pelo menos absorvendo conceitos cloud.

z/OS CLOUD BROKER

O documento mostra o z/OS Cloud Broker integrado ao OpenShift.

Isso permite provisionar serviços como:

IMS
Db2
CICS
MQ
z/OS Connect

de forma semelhante ao mundo cloud.

O QUE ISSO SIGNIFICA PARA O FUTURO DO IMS?

A conclusão mais importante do material é que a IBM não vê o IMS como tecnologia do passado.

Ela vê o IMS como:

Plataforma transacional
Fonte de dados
Plataforma API
Plataforma DevOps
Plataforma híbrida

A GRANDE LIÇÃO PARA O PADAWAN MAINFRAME

Se você é:

Desenvolvedor COBOL
DBA IMS
Sysprog
Arquiteto
Gestor

precisa entender uma coisa.

A guerra não é:

COBOL vs Java

Mainframe vs Cloud

IMS vs Microservices

A verdadeira batalha é:

Sistema Isolado vs Sistema Conectado.

O documento da IBM demonstra que o IMS moderno pode participar de:

✅ APIs REST

✅ OpenAPI

✅ Swagger

✅ Java

✅ JDBC

✅ SQL

✅ Analytics

✅ Machine Learning

✅ Git

✅ Jenkins

✅ OpenShift

✅ Ansible

✅ Zowe

✅ DevOps

✅ Hybrid Cloud

sem abandonar décadas de investimento corporativo.

E talvez essa seja a maior lição de todas:

O futuro não pertence aos sistemas novos.
Pertence aos sistemas que conseguem evoluir.

E poucos sistemas na história da computação provaram tantas vezes sua capacidade de evolução quanto o IMS. ☕💣🚀

Fonte analisada: The 4 Paths to Digital Transformation in IMS, Haley Fung, IBM IMS.

Translate

sexta-feira, 23 de dezembro de 2022

Java no IBM Z: Como Java Conversa com COBOL, DB2, CICS e o Mundo Mainframe na Prática

☕ Um Café no Bellacosa Mainframe

Java no IBM Z: Como Java Conversa com COBOL, DB2, CICS e o Mundo Mainframe na Prática

A chegada do Java ao Mainframe

Escrever uma vez, executar em qualquer lugar

O nascimento do Java no z/OS

A arquitetura moderna

JDBC

Exemplo

O Driver JDBC

O Prepared Statement

Como Java conversa com DB2

Como COBOL acessa DB2

Conversão de tipos

COBOL

Datas

Boolean

Estruturas COBOL

OO versus Procedural

Classe

O que seria uma estrutura COBOL equivalente?

Como Java chama COBOL?

CICS

JNI

MQ

REST

Stored Procedures

CICS

JSON

XML

Conversão COBOL para JSON

Datasets

VSAM

Arquivos Sequenciais

EBCDIC versus ASCII

Batch Java

Java Online

JSP

Servlets

APIs REST

LinuxONE

OpenJ9

zIIP

Um fluxo completo

Procedural x Orientado a Objetos: uma visão para quem vem do COBOL

O futuro

Conclusão

quarta-feira, 14 de dezembro de 2022

Db2 Connect e a Banheira do Tempo — Quando Quatro Programadores Voltaram a 1986, Encontraram um JDBC no Fliperama e Descobriram que TCP/IP Não Sabia Executar SELECT

Bellacosa Mainframe e o db2 connect e a banheira do tempo☕ Um Café no Bellacosa Mainframe

Db2 Connect e a Banheira do Tempo — Quando Quatro Programadores Voltaram a 1986, Encontraram um JDBC no Fliperama e Descobriram que TCP/IP Não Sabia Executar SELECT

Ou: o jovem padawan COBOL entrou numa banheira instalada ao lado do datacenter, Igor derramou energético sobre o painel do DDF, o Db2 for z/OS abriu um DBAT e todos descobriram que conexão, sessão, transação e pacote não são quatro nomes para a mesma coisa

Prólogo — A banheira que apontava para o mainframe

1. O que é Db2 Connect?

2. Aplicação, linguagem, API e driver não são a mesma coisa

Exemplo Java

Exemplo Python

Exemplo COBOL

3. O personagem que o infográfico esqueceu: o driver

4. TCP/IP é a estrada; DRDA é o idioma

5. No z/OS, quem abre o portal é o DDF

6. DBAT: o funcionário que recebe o visitante

7. Conexão direta ou servidor Db2 Connect?

Conexão direta

Gateway Db2 Connect

8. O que acontece durante um SELECT?

9. Packages: o detalhe que aparece quando chega o -805

10. COMMIT, ROLLBACK e a viagem que talvez já tenha acontecido

11. Pool de conexões: o táxi que retorna à praça

12. Segurança: TCP/IP não é colete à prova de balas

Quem é você?

A conversa está protegida?

O que você pode fazer?

Quem é a aplicação?

13. Por que uma SQL rápida no SPUFI pode ser lenta no Java?

14. Fetch size: quantas malas entram em cada viagem?

15. Data Sharing, Sysplex e a banheira com várias saídas

16. Mapa rápido dos erros

Bellacosa Mainframe e o db2 connect e a banheira do tempo

☕ Um Café no Bellacosa Mainframe

Db2 Connect e a Banheira do Tempo — Quando Quatro Programadores Voltaram a 1986, Encontraram um JDBC no Fliperama e Descobriram que TCP/IP Não Sabia Executar `SELECT`

8. O que acontece durante um `SELECT`?

9. Packages: o detalhe que aparece quando chega o `-805`

10. `COMMIT`, `ROLLBACK` e a viagem que talvez já tenha acontecido