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.

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.

 

Bellacosa Mainframe e a introdução a YAML

☕🚀 PADAWAN, YAML NÃO É LINGUAGEM DE PROGRAMAÇÃO. É A FICHA DE CADASTRO DO UNIVERSO DEVOPS!

Se você veio do mundo COBOL, JCL, PROC, PARMLIB, SYSIN, cartões perfurados, datasets sequenciais e arquivos de configuração gigantescos, provavelmente já esbarrou em um arquivo chamado:

application.yaml
docker-compose.yaml
kubernetes.yaml
pipeline.yaml

E talvez tenha pensado:

"Mas afinal... que diabos é YAML?"

Sente-se, pegue seu café e venha comigo.

Porque entender YAML hoje é quase tão importante para um desenvolvedor moderno quanto entender JCL era para um programador mainframe nos anos 80.

---

A HISTÓRIA DO YAML

YAML significa:

YAML Ain't Markup Language

Ou seja:

"YAML não é uma linguagem de marcação."

O nome é um trocadilho.

No início ele significava:

Yet Another Markup Language
(Mais uma linguagem de marcação)

Mas depois os criadores perceberam que YAML não era exatamente uma linguagem de marcação como XML.

Então mudaram para:

YAML Ain't Markup Language

---

QUANDO O YAML NASCEU?

O projeto surgiu em:

2001

Criado por:

• Clark Evans

• Ingy döt Net

• Oren Ben-Kiki

O objetivo era simples:

Criar algo mais legível que XML.

Na época o XML dominava tudo.

Exemplo XML:

<cliente>
   <nome>João</nome>
   <idade>25</idade>
</cliente>

Os criadores pensaram:

"Por que tanta tag abrindo e fechando?"

Então nasceu YAML.

---

VERSÕES IMPORTANTES

YAML 1.0

2004

Primeira versão oficial.

---

YAML 1.1

2005

Mais recursos.

Maior adoção.

---

YAML 1.2

2009

Versão mais usada atualmente.

Compatibilidade melhor com JSON.

---

POR QUE O YAML FICOU TÃO POPULAR?

Porque ele resolveu um problema enorme:

Configurações.

Todo sistema precisa delas.

Antes tínhamos:

• INI

• XML

• Properties

• Arquivos texto

Mas YAML ficou muito mais fácil de ler.

---

PARA QUE SERVE O YAML?

Basicamente:

Armazenar configuração

Exemplo:

servidor:
  porta: 8080

banco:
  host: localhost

---

ONDE O YAML É UTILIZADO?

Hoje praticamente em todo lugar.

---

Kubernetes

Talvez o maior usuário de YAML do planeta.

apiVersion: v1
kind: Pod
metadata:
  name: meu-pod

---

Docker Compose

version: "3"

services:
  banco:
    image: mysql

---

Spring Boot

server:
  port: 8080

---

GitHub Actions

name: Build
on: push

---

GitLab CI

stages:
  - build
  - deploy

---

Ansible

- hosts: servidores

---

O YAML PARA UM COBOLISTA

Imagine um membro PARMLIB.

Por exemplo:

PORTA=8080
HOST=localhost

YAML faz algo semelhante.

Só que organizado hierarquicamente.

servidor:
  host: localhost
  porta: 8080

É como um PARMLIB muito mais moderno.

---

A REGRA MAIS IMPORTANTE DO YAML

Padawan...

A regra mais importante é:

ESPAÇOS

Não TAB.

Não misture.

Não invente.

Somente espaços.

---

EXEMPLO VÁLIDO

cliente:
  nome: João
  idade: 25

---

EXEMPLO INVÁLIDO

cliente:
<TAB>nome: João

Muitos erros acontecem por causa disso.

---

ESTRUTURA BÁSICA

Tudo gira em torno de:

chave : valor

nome: João

---

idade: 25

---

ativo: true

---

TIPOS DE DADOS

Texto

nome: Bellacosa

---

Número

idade: 50

---

Decimal

salario: 3500.99

---

Booleano

ativo: true

---

Nulo

valor: null

---

AGRUPAMENTOS

Podemos criar grupos.

cliente:
  nome: João
  idade: 25

Representa:

{
  "cliente":{
      "nome":"João",
      "idade":25
  }
}

---

LISTAS

Parecido com OCCURS.

linguagens:
  - COBOL
  - Java
  - Python

---

Equivale a:

[
 "COBOL",
 "Java",
 "Python"
]

---

LISTA DE OBJETOS

Muito usada.

funcionarios:

  - nome: João
    cargo: Programador

  - nome: Maria
    cargo: Analista

---

COMENTÁRIOS

Como no JCL usamos:

//*

No YAML usamos:

# comentário

Exemplo:

# porta da aplicação
porta: 8080

---

STRINGS

Pode ser:

nome: Bellacosa

---

Ou:

nome: "Bellacosa"

---

Ou:

nome: 'Bellacosa'

---

MULTILINHAS

Muito útil.

descricao: |
  Linha 1
  Linha 2
  Linha 3

Resultado:

Linha 1
Linha 2
Linha 3

---

EXEMPLO PRÁTICO SPRING BOOT

Imagine uma API Java.

Arquivo:

server:
  port: 8080

spring:
  datasource:
    url: jdbc:mysql://localhost/teste
    username: root
    password: 123

Quando a aplicação sobe:

• Porta 8080

• Banco MySQL

• Usuário root

Tudo configurado via YAML.

---

EXEMPLO PRÁTICO DOCKER COMPOSE

version: '3'

services:

  mysql:
    image: mysql:8

  app:
    image: minha-api

---

Traduzindo:

"Suba dois containers"

• MySQL

• Aplicação

---

EXEMPLO PRÁTICO KUBERNETES

Aqui mora o YAML.

Praticamente tudo no Kubernetes é YAML.

apiVersion: v1

kind: Pod

metadata:
  name: bellacosa

spec:

  containers:
    - name: app
      image: nginx

---

Executa:

kubectl apply -f pod.yaml

E o cluster cria o pod.

---

COMANDOS IMPORTANTES

YAML em si não possui comandos.

Isso é importante.

Muitos iniciantes confundem.

YAML é apenas:

Estrutura de dados.

Os comandos pertencem à ferramenta.

---

Exemplo:

Docker:

docker compose up

---

Kubernetes:

kubectl apply -f arquivo.yaml

---

Ansible:

ansible-playbook playbook.yaml

---

GitHub:

Automaticamente lê:

.github/workflows/build.yaml

---

YAML E JSON

Você sabia?

Todo JSON válido pode ser convertido para YAML.

---

JSON:

{
  "nome":"João"
}

---

YAML:

nome: João

Muito mais limpo.

---

VANTAGENS

Legibilidade

A maior vantagem.

---

Fácil de aprender

Poucas regras.

---

Menos verboso

Muito menor que XML.

---

Hierarquia natural

A indentação mostra tudo.

---

Amplamente suportado

Praticamente todas as linguagens.

---

Excelente para DevOps

Docker

Kubernetes

GitHub

Ansible

Terraform

Tudo conversa com YAML.

---

DESVANTAGENS

Nem tudo são flores.

---

Sensível a espaços

Um espaço errado:

Tudo quebra.

---

Difícil para estruturas gigantes

Arquivos enormes viram labirintos.

---

Erros nem sempre claros

Às vezes o parser reclama na linha 200.

Mas o erro está na linha 30.

---

Não é ideal para dados complexos

JSON pode ser mais seguro.

---

ERROS CLÁSSICOS DE INICIANTES

Misturar TAB e espaço

Erro número 1.

---

Indentação incorreta

Errado:

cliente:
nome: João

---

Correto:

cliente:
  nome: João

---

Esquecer hífen em listas

Errado:

linguagens:
 COBOL
 JAVA

---

Correto:

linguagens:
 - COBOL
 - JAVA

---

LABORATÓRIO 1

Criar arquivo:

empresa:
  nome: Bellacosa Mainframe
  fundacao: 2024

Salvar:

empresa.yaml

---

LABORATÓRIO 2

Adicionar funcionários.

empresa:

  nome: Bellacosa Mainframe

  funcionarios:

    - nome: João
      cargo: Programador

    - nome: Maria
      cargo: Analista

---

LABORATÓRIO 3

Converter para JSON

Resultado:

{
  "empresa":{
    "nome":"Bellacosa Mainframe",
    "funcionarios":[
      {
        "nome":"João",
        "cargo":"Programador"
      },
      {
        "nome":"Maria",
        "cargo":"Analista"
      }
    ]
  }
}

---

YAML E COBOL

Imagine uma configuração externa.

Antes:

01 PARAMETROS.
   05 PORTA       PIC 9(4).
   05 HOST        PIC X(50).

Lendo de arquivo texto.

Hoje poderíamos ter:

aplicacao:
  host: localhost
  porta: 8080

Uma API Java poderia ler isso.

Uma aplicação Node.js também.

Um container Docker também.

Todos compartilhando o mesmo arquivo.

---

YAML NO MUNDO MAINFRAME

Muita gente acredita que YAML não tem relação com Mainframe.

Erro enorme.

Hoje encontramos YAML em:

• OpenShift on Z

• Kubernetes on IBM Z

• z/OS Connect

• IBM Cloud

• Ansible Automation Platform

• DevOps Enterprise

---

Imagine um pipeline CI/CD para COBOL:

stages:

  - build

  - test

  - deploy

Esse YAML pode controlar:

• Compilação COBOL

• Link Edit

• Testes

• Deploy

Tudo automaticamente.

---

ANALOGIA BELLACOSA MAINFRAME

Se eu tivesse que explicar YAML para um operador de mainframe dos anos 80, eu diria:

JCL diz O QUE EXECUTAR.

COBOL diz COMO PROCESSAR.

YAML diz COMO CONFIGURAR.

Ele é o formulário de configuração do ecossistema moderno.

Não executa lógica.

Não faz cálculo.

Não substitui COBOL.

Não substitui Java.

Não substitui Python.

Mas conecta todos eles.

---

CONCLUSÃO

Padawan...

Se nos anos 70 o profissional de tecnologia precisava entender:

• JCL

• PROCs

• PARMLIB

• SYSIN

Hoje o profissional moderno precisa entender:

• YAML

• Docker

• Kubernetes

• GitHub Actions

• CI/CD

YAML tornou-se a linguagem universal da configuração.

Sua sintaxe minimalista, sua legibilidade e sua adoção massiva fizeram dele um dos formatos mais importantes da computação moderna.

E existe uma grande chance de que o próximo arquivo que você abrir em um projeto de nuvem, DevOps, containers, APIs ou automação tenha exatamente esta extensão:

.yaml

ou

.yml

Quando isso acontecer, não tenha medo.

Lembre-se desta regra:

☕

"YAML é para o DevOps o que o PARMLIB foi para o Mainframe: um lugar onde a configuração mora para que o programa possa trabalhar."

E quando você dominar YAML, Kubernetes, Docker e automação, perceberá algo curioso:

O mercado mudou, as ferramentas mudaram, os nomes mudaram...

Mas a ideia continua a mesma desde os tempos do COBOL:

separar a configuração da lógica do programa.

Essa é uma das filosofias mais antigas, elegantes e duradouras da computação. 🚀☕💙

IBM MQ vs Kafka : Quando um Programador Descobre que Voltar no Tempo é Fácil no DeLorean..

 

Bellacosa Mainframe e uma comparação ibm mq versus kafka

☕ Um Café no Bellacosa Mainframe

IBM MQ vs Kafka sem Mistérios para Programadores COBOL

Quando um Programador Descobre que Voltar no Tempo é Fácil no DeLorean... Difícil Mesmo é Dar Rollback em uma Transação Bancária

"Estradas? Para onde vamos, não precisamos de estradas." — Doc Brown

No universo Bellacosa Mainframe, porém, Doc Brown provavelmente corrigiria sua famosa frase:

"Mensagens? Para onde vamos, não precisamos apenas de mensagens. Precisamos de COMMIT."

Porque existe uma enorme diferença entre viajar pelo tempo e viajar com dados corporativos.

Um erro temporal pode fazer Marty McFly apagar sua própria existência.

Um erro numa transação bancária pode fazer desaparecer milhões de reais.

E é justamente aqui que entram dois dos maiores protagonistas da arquitetura moderna:

IBM MQ e Apache Kafka.

Embora muita gente os coloque no mesmo ringue, como se fossem dois boxeadores disputando o cinturão mundial da mensageria, a verdade é outra.

Eles nasceram para resolver problemas completamente diferentes.

Hoje vamos embarcar no DeLorean do Bellacosa Mainframe para visitar quarenta anos de evolução dos sistemas distribuídos e descobrir por que o IBM MQ continua sendo uma das tecnologias mais importantes do planeta para sistemas críticos.

Aperte o cinto.

Configure o Flux Capacitor para 88 mph.

E cuidado para não provocar um ABEND em 1955.

---

1985: O primeiro salto temporal

Imagine Marty chegando em Hill Valley.

Ele altera um pequeno evento.

Resultado?

Toda a linha do tempo muda.

Nos computadores acontece exatamente a mesma coisa.

Imagine um banco executando uma transferência.

1. Debita R$ 10.000 da conta A.

2. Cai a energia.

3. Nunca credita a conta B.

Parabéns.

Você acabou de criar uma linha temporal alternativa.

No universo do COBOL isso recebe outro nome:

Estado inconsistente.

É exatamente para impedir esse tipo de paradoxo que existem as transações.

---

O verdadeiro Flux Capacitor chama-se COMMIT

No filme, o Flux Capacitor garante que Marty chegue inteiro ao passado.

Nos sistemas corporativos existe um equivalente.

Ele chama-se:

COMMIT.

Enquanto o COMMIT não acontece...

Nada realmente existe.

É como se todo o processamento estivesse preso num universo paralelo.

Somente quando o commit é confirmado, aquela realidade passa oficialmente a existir.

---

Se o COMMIT nunca acontecer...

Imagine Doc Brown ligando o DeLorean.

A viagem começa.

Mas o capacitor falha.

Resultado?

A viagem inteira é cancelada.

É exatamente isso que um rollback faz.

Tudo volta ao estado anterior.

Como se nada tivesse acontecido.

---

IBM MQ nasceu para impedir paradoxos temporais

Quando a IBM criou o MQSeries (hoje IBM MQ), o objetivo nunca foi ser o software mais rápido do planeta.

O objetivo era outro.

Nunca perder uma mensagem.

Existe uma enorme diferença.

Velocidade é importante.

Confiabilidade é indispensável.

---

Kafka nasceu em outro universo

Apache Kafka surgiu décadas depois.

O problema era completamente diferente.

LinkedIn precisava registrar:

Bilhões de cliques.

Bilhões de visualizações.

Logs.

Eventos.

Métricas.

Streaming.

Analytics.

Machine Learning.

Não importava se um clique perdido acontecesse ocasionalmente.

O importante era processar milhões por segundo.

---

A analogia do DeLorean

Imagine dois veículos.

O DeLorean

Transporta uma única missão extremamente importante.

Não pode falhar.

É o IBM MQ.

---

Um trem-bala japonês

Transporta milhares de passageiros continuamente.

É o Kafka.

---

Os dois são excelentes.

Mas para objetivos completamente diferentes.

---

O problema da viagem temporal distribuída

Agora imagine uma viagem muito mais complicada.

Marty precisa alterar cinco épocas diferentes simultaneamente.

1985 Alternativo.

Todas precisam terminar corretamente.

Ou nenhuma pode acontecer.

É exatamente isso que faz uma transação distribuída.

---

XA Transaction

XA é uma especificação criada para coordenar vários recursos diferentes.

Imagine uma orquestra.

Cada músico representa um sistema.

Db2.

Oracle.

IBM MQ.

IMS.

JMS.

Todos precisam tocar exatamente a mesma música.

No mesmo instante.

Se um violinista errar...

Toda a apresentação para.

---

Two Phase Commit

Aqui aparece o verdadeiro maestro.

O Transaction Manager.

Ele faz duas perguntas.

---

Primeira fase

"Todos estão preparados?"

Db2

— Sim.

MQ

— Sim.

Oracle

— Sim.

Ninguém grava nada ainda.

Todos apenas levantam a mão.

---

Segunda fase

O maestro pergunta novamente.

"Posso executar?"

Agora todos respondem.

Sim.

Somente agora tudo é gravado.

Ou...

Caso alguém responda NÃO...

Todos desfazem absolutamente tudo.

---

Easter Egg nº 1

No filme, Doc Brown nunca aperta o acelerador antes de conferir o Flux Capacitor.

No mundo corporativo, um arquiteto nunca faz COMMIT antes de verificar se todos os recursos responderam "Prepare".

---

Porque isso importa?

Imagine pagar um boleto.

A aplicação faz:

Atualiza Db2

↓

Envia mensagem MQ

↓

Atualiza saldo

↓

Gera comprovante

↓

Envia SMS

↓

Atualiza limite

Agora imagine que o servidor reinicie exatamente entre o passo três e quatro.

Sem XA...

Você pode ter:

Dinheiro debitado.

Sem comprovante.

Sem mensagem.

Sem auditoria.

Um pesadelo.

---

IBM MQ resolve isso elegantemente

Quando o MQ participa de uma transação XA, ele espera o Transaction Manager.

Nada é entregue definitivamente.

Nada desaparece.

Tudo permanece consistente.

---

Persistent Message

Uma das maiores forças do IBM MQ.

Existem dois tipos de mensagens.

Persistent.

Non Persistent.

---

Persistent

Antes de responder:

"Mensagem recebida."

O Queue Manager grava tudo em disco.

Mesmo que falte energia.

Mesmo que o servidor exploda.

Mesmo que haja reboot.

A mensagem continua lá.

---

Curiosidade

Essa característica fez do MQ um dos pilares dos bancos durante décadas.

Enquanto aplicações inteiras eram reiniciadas...

As filas permaneciam intactas.

---

Rollback

Agora vem uma das maiores mágicas do processamento transacional.

Imagine escrever um cheque.

Assinar.

Carimbar.

Guardar.

Depois descobrir que o saldo é insuficiente.

Rollback significa destruir completamente aquela operação.

Como se ela jamais tivesse existido.

---

Marty McFly e o Rollback

No primeiro filme, Marty começa a desaparecer da fotografia.

Felizmente consegue corrigir a linha temporal.

No mundo do IBM MQ isso acontece automaticamente.

Rollback restaura a fotografia original.

---

Kafka pensa diferente

Kafka trabalha com outro paradigma.

Eventos.

Streaming.

Replay.

Histórico.

Retenção.

Consumidores independentes.

É quase uma máquina do tempo.

Os eventos ficam armazenados por dias, semanas ou meses.

Você pode voltar e "reassistir" os acontecimentos.

Essa é uma diferença fascinante.

MQ normalmente preocupa-se com entregar a mensagem.

Kafka preocupa-se também em preservar o histórico de eventos para que consumidores possam relê-los.

---

Throughput

Throughput significa capacidade de processamento.

Imagine duas rodovias.

Rodovia A.

Passam cem caminhões por minuto.

Rodovia B.

Passam cem mil carros por minuto.

Kafka foi projetado para a segunda situação.

---

IBM MQ prefere outra pergunta

Não pergunta:

"Quantas mensagens?"

Pergunta:

"Quantas mensagens chegaram corretamente?"

Essa diferença muda completamente a arquitetura.

---

Exactly Once

Esse termo gera muita confusão.

Existem três possibilidades.

At Most Once

Pode perder.

Nunca duplica.

---

At Least Once

Nunca perde.

Pode duplicar.

---

Exactly Once

Nem perde.

Nem duplica.

No IBM MQ isso é obtido por sessões transacionais e commit/rollback.

No Kafka, há recursos de exatamente uma vez dentro do ecossistema Kafka (produtores idempotentes, transações e Kafka Streams), mas quando entram bancos de dados e outros sistemas externos, normalmente usam-se padrões como Transactional Outbox, CDC e Saga, em vez de XA distribuído.

---

MongoDB

Existe uma observação muito interessante.

MongoDB suporta transações internas.

Mas não participa do padrão XA tradicional.

Por isso arquiteturas modernas normalmente utilizam:

Transactional Outbox.

CDC.

Saga Pattern.

Compensating Transactions.

Tudo isso substitui o velho Two Phase Commit quando múltiplos recursos heterogêneos estão envolvidos.

---

Alta Disponibilidade

Imagine Hill Valley sendo atingida por um raio.

Mesmo assim.

O sistema continua funcionando.

IBM MQ possui recursos empresariais como:

Multi Instance Queue Manager.

HA.

Disaster Recovery.

Logs.

Journal.

Replicação.

Failover.

No z/OS pode integrar-se ao Parallel Sysplex para disponibilidade extraordinária.

---

Disaster Recovery

Imagine perder um Data Center inteiro.

Mesmo assim.

As mensagens continuam existindo.

É exatamente isso que faz o Journal do MQ.

---

Easter Egg nº 2

No filme existe uma torre do relógio.

Ela registra um instante histórico.

No IBM MQ existe o Journal.

Ele registra cada passo importante da vida das mensagens.

---

JMS

Muitos iniciantes confundem.

JMS NÃO é um broker.

JMS é uma API.

Ela permite que aplicações Java conversem com IBM MQ, ActiveMQ, Artemis e outros provedores de mensageria sem ficarem presas a uma implementação específica.

---

Spring Boot

Hoje é extremamente comum encontrar:

Spring Boot

IBM MQ

Db2

@Transactional

JTA

Tudo trabalhando junto.

Uma única anotação Java coordena diversos recursos corporativos.

É como Doc Brown sincronizando todos os relógios de Hill Valley.

---

Onde cada tecnologia vence?

Imagine um banco digital.

Cliente faz PIX.

↓

COBOL no CICS processa.

↓

Db2 grava.

↓

IBM MQ garante entrega.

↓

Kafka distribui eventos.

↓

Machine Learning detecta fraude.

↓

Dashboard atualiza em tempo real.

Percebe?

Nenhuma tecnologia substitui completamente a outra.

Elas cooperam.

---

Curiosidade histórica

O IBM MQ surgiu como MQSeries, em 1993, para facilitar a comunicação confiável entre aplicações distribuídas em diferentes plataformas. Ao longo das décadas evoluiu para integrar z/OS, AIX, Linux, Windows e ambientes em nuvem, mantendo como principal característica a confiabilidade.

O Apache Kafka nasceu no LinkedIn e foi aberto como projeto da Apache Foundation em 2011. Sua proposta revolucionou o processamento de eventos em larga escala, tornando-se um dos pilares das arquiteturas orientadas a eventos modernas.

São tecnologias de épocas diferentes, criadas para resolver dores diferentes.

---

Dicas para o Padawan COBOL

Se você está começando no mundo mainframe, siga esta ordem de estudos:

1. Entenda primeiro o conceito de transação e por que ela existe.

2. Aprenda os fundamentos de COMMIT e ROLLBACK em Db2 e CICS.

3. Estude o funcionamento de uma Queue, incluindo mensagens persistentes e não persistentes.

4. Pratique o envio e recebimento de mensagens com IBM MQ em programas COBOL ou Java.

5. Compreenda como JMS abstrai o acesso ao MQ em aplicações Java.

6. Só depois mergulhe em Kafka, Event Streaming, CDC, Outbox e Saga. Você entenderá muito melhor quando conhecer primeiro a base transacional.

---

O que um arquiteto experiente realmente pergunta?

O iniciante pergunta:

"Qual tecnologia é melhor?"

O arquiteto pergunta:

"Qual problema estou tentando resolver?"

Se o problema é transmitir milhões de eventos para dezenas de consumidores independentes, Kafka provavelmente será a escolha natural.

Se o problema é garantir que uma transferência financeira de R$ 500.000,00 nunca fique pela metade, IBM MQ é uma das respostas mais sólidas já criadas.

Essa mudança de perspectiva separa quem conhece ferramentas de quem entende arquitetura.

---

O Grande Ensinamento do Dr. Emmett Brown

No final de De Volta para o Futuro, Doc Brown aprende que pequenas mudanças podem alterar completamente a história.

Nos sistemas corporativos acontece exatamente o mesmo.

Uma única mensagem perdida pode gerar:

• um pagamento duplicado;

• uma conta inconsistente;

• um pedido entregue duas vezes;

• uma reserva aérea inexistente;

• um prejuízo milionário.

É por isso que bancos, seguradoras, bolsas de valores e governos continuam investindo em tecnologias como IBM MQ mesmo décadas após sua criação.

No Bellacosa Mainframe, existe uma máxima que todo Padawan COBOL deveria gravar como se fosse escrita na lateral do próprio DeLorean:

"Velocidade impressiona. Escalabilidade encanta. Mas é a consistência que mantém a máquina do tempo da empresa funcionando sem criar paradoxos financeiros."

E talvez esse seja o maior segredo da computação corporativa.

No cinema, Doc Brown precisava de 1,21 gigawatts para viajar no tempo.

No mundo dos mainframes, um arquiteto experiente precisa apenas de quatro palavras para evitar um desastre que poderia alterar a história inteira de uma empresa:

COMMIT. ROLLBACK. MQ. CONSISTÊNCIA.