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

Translate

Mostrar mensagens com a etiqueta REST API. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta REST API. Mostrar todas as mensagens

sexta-feira, 31 de julho de 2026

Do HTML ao IBM Z — Quando um Programador COBOL Descobre que o Front-end Também Faz Parte do Mainframe Moderno

 

Bellacosa Mainframe do Html ao IBM Z uma jornada classica do Heroi

☕ Um Café no Bellacosa Mainframe

Do HTML ao IBM Z — Quando um Programador COBOL Descobre que o Front-end Também Faz Parte do Mainframe Moderno

"Durante muitos anos acreditamos que existiam dois mundos completamente diferentes. De um lado, o navegador. Do outro, o mainframe. Hoje sabemos que eles nunca estiveram tão próximos."


Existe uma cena curiosa que provavelmente todo programador COBOL já viveu.

Você está trabalhando em um programa CICS há horas. Ajusta um COMMAREA, altera uma consulta DB2, recompila, faz o BIND, libera para homologação e, de repente, alguém da equipe Web aparece com uma pergunta aparentemente inocente:

— "Você consegue disponibilizar isso numa API REST?"

Há alguns anos essa pergunta soaria quase como magia.

Hoje ela faz parte do cotidiano.

Foi justamente para reduzir essa distância que nasceu o APPDEV 33 – Introduction to Web Development – Part 2, expandindo os conceitos apresentados na Parte 1 e mostrando que HTML, CSS e JavaScript não competem com COBOL. Eles trabalham juntos.

Na verdade...

Eles dependem um do outro.



A grande mudança silenciosa

Existe uma falsa impressão de que o desenvolvimento Web pertence apenas ao universo JavaScript.

Não pertence.

Da mesma forma que existe a falsa impressão de que o Mainframe termina na tela verde.

Também não termina.

O navegador moderno tornou-se apenas mais um terminal.

Só que muito mais bonito.

Muito mais amigável.

Muito mais inteligente.

E atrás dele continua existindo aquilo que sempre sustentou bancos, seguradoras, governos, companhias aéreas e bolsas de valores:

IBM Z.


O que aprendemos na Parte 1

Na primeira parte aprendemos três pilares fundamentais.

HTML

A estrutura.

Assim como uma BMS MAP define onde cada campo aparecerá na tela 3270, o HTML define onde cada elemento será exibido dentro da página.

É o esqueleto.


CSS

A aparência.

Se na BMS alterávamos atributos como intensidade, cor, proteção e brilho, no navegador fazemos praticamente a mesma coisa utilizando CSS.

Mudam os nomes.

O conceito continua.


JavaScript

O comportamento.

Enquanto COBOL executa regras de negócio no servidor, JavaScript controla a experiência do usuário no navegador.

Ele responde cliques.

Atualiza informações.

Valida formulários.

Move elementos.

Sem precisar recarregar toda a página.


A analogia perfeita

Mundo WebMundo Mainframe
HTMLBMS MAP
CSSAtributos da Tela
JavaScriptInterface
COBOLRegras de Negócio

Quando essa tabela aparece pela primeira vez, muita gente faz exatamente a mesma expressão:

"Ahhh... agora fez sentido."



O navegador é apenas o começo

Quando digitamos:

https://empresa.com

Nossa mente costuma imaginar algo simples.

Mas, nos bastidores, ocorre uma verdadeira corrida de revezamento.

Usuário

↓

Browser

↓

Servidor Web

↓

HTML

↓

CSS

↓

JavaScript

↓

Página pronta

↓

REST API

↓

z/OS Connect

↓

CICS

↓

COBOL

↓

DB2

↓

Resposta

Observe algo interessante.

O navegador praticamente nunca conversa diretamente com o COBOL.

Existe uma camada intermediária.

E isso é excelente.


O guardião entre dois mundos

No ecossistema IBM Z moderno existe um verdadeiro tradutor universal.

z/OS Connect.

Ele recebe chamadas REST.

Converte JSON.

Invoca programas COBOL.

Executa CICS.

Consulta DB2.

Retorna novamente JSON.

Tudo isso escondendo completamente a complexidade do ambiente z/OS.

É quase como um intérprete simultâneo durante uma conferência internacional.

Cada lado continua falando sua própria língua.

Mas todos passam a se entender.


HTML deixou de ser apenas marcação

Quem aprendeu HTML há quinze anos provavelmente conheceu algo parecido com isto.

<div>
<div>
<div>

Funcionava.

Mas era praticamente impossível descobrir o significado daquela estrutura.

Então surgiu o HTML Semântico.

Agora passamos a utilizar elementos como:

<header>

<nav>

<main>

<section>

<article>

<footer>

Essas palavras possuem significado.

E significado muda tudo.

Motores de busca entendem melhor o conteúdo.

Leitores de tela conseguem navegar corretamente.

Ferramentas de Inteligência Artificial interpretam o contexto.

Até os próximos programadores agradecem.

Porque finalmente conseguem entender a organização da página.


CSS cresceu

Durante muito tempo criar layouts era uma atividade quase artesanal.

Tabelas.

Float.

Clear.

Margens.

Gambiarras.

Então surgiu o Flexbox.

De repente bastava escrever poucas linhas.

display:flex;

justify-content:space-between;

align-items:center;

Como mágica.

Tudo se alinhava.

Responsivamente.

Sem sofrimento.

Depois veio o CSS Grid.

E aí o navegador finalmente ganhou um verdadeiro sistema de layout bidimensional.

Header.

Menu.

Conteúdo.

Rodapé.

Tudo organizado como uma planta arquitetônica.

Curiosamente...

É exatamente assim que pensamos quando desenhamos uma aplicação CICS.

Primeiro definimos a arquitetura.

Depois os componentes.

Depois o fluxo.


JavaScript finalmente ganhou vida

No início JavaScript apenas executava comandos.

Hoje ele reage.

Clique.

Teclado.

Mouse.

Touch.

Formulário.

Mudança de valor.

Tudo é evento.

Usuário

↓

Evento

↓

JavaScript

↓

Resposta

Essa simplicidade mudou completamente a experiência da Web.

Não precisamos mais atualizar páginas inteiras.

Alteramos apenas aquilo que realmente mudou.

Essa ideia parece moderna.

Mas, curiosamente, programadores CICS fazem algo parecido há décadas.

Atualizamos apenas determinados campos da tela.

Não a aplicação inteira.



DOM — A página deixa de ser estática

Imagine que exista uma árvore invisível.

Cada botão.

Cada texto.

Cada imagem.

Cada tabela.

Cada formulário.

Tudo faz parte dessa árvore.

Ela recebe um nome.

DOM — Document Object Model.

JavaScript pode caminhar por essa árvore.

Encontrar um elemento.

Alterar seu conteúdo.

Modificar sua aparência.

Inserir novos componentes.

Tudo instantaneamente.

Sem recarregar o navegador.

É isso que transforma páginas estáticas em aplicações.

Parte II : Quando o Navegador Conversa com o Mainframe

Na primeira parte da nossa conversa percebemos algo importante: HTML, CSS e JavaScript não substituem o COBOL. Eles apenas ocupam uma camada diferente da aplicação.

Agora vem a pergunta que todo programador COBOL faz quando termina de aprender os conceitos básicos.

"Tudo bem... mas como exatamente um clique no navegador consegue executar um programa COBOL dentro do IBM Z?"

É justamente aqui que começa a mágica.

Ou melhor...

A engenharia.



A viagem de um clique

Imagine que um cliente acessa o Internet Banking.

Ele vê um botão.

Consultar Saldo

Aparentemente ele apenas clicou.

Mas esse clique inicia uma longa viagem.

Clique

↓

JavaScript

↓

REST API

↓

JSON

↓

z/OS Connect

↓

CICS

↓

Programa COBOL

↓

DB2

↓

Resposta

↓

JSON

↓

JavaScript

↓

Atualização da Tela

Em menos de um segundo tudo isso aconteceu.

Sem o usuário perceber.

Se o sistema estiver rodando em IBM Z, provavelmente essa operação ocorreu em alguns poucos milissegundos.



REST API — A língua franca da Internet

Há vinte anos cada sistema possuía seu próprio protocolo.

Cada fabricante inventava uma maneira diferente de trocar informações.

Era um verdadeiro caos.

REST mudou completamente esse cenário.

Hoje praticamente qualquer sistema consegue conversar com qualquer outro utilizando HTTP.

Isso significa que um navegador, um aplicativo Android, um iPhone, uma Smart TV ou até uma geladeira inteligente podem acessar exatamente a mesma API.

O IBM Z simplesmente tornou-se mais um participante dessa conversa.



JSON — O envelope que viaja pela Internet

Quando um navegador solicita informações, ele normalmente envia algo parecido com isto.

{
   "cliente":12345
}

Poucos milissegundos depois recebe algo semelhante.

{
   "nome":"Maria",
   "saldo":1250.90,
   "limite":5000
}

Isso é JSON.

Leve.

Organizado.

Fácil de interpretar.

Mas existe uma curiosidade.

O JSON praticamente nunca nasce no navegador.

Na maioria das aplicações corporativas ele foi produzido por um programa COBOL.

Ou seja...

Por trás daquele pequeno documento existe toda uma lógica construída durante décadas.



z/OS Connect — O tradutor universal

Imagine um diplomata durante uma reunião internacional.

Um participante fala japonês.

Outro fala português.

Outro inglês.

Outro espanhol.

Todos conseguem conversar porque existe um intérprete.

z/OS Connect faz exatamente esse papel.

Ele entende REST.

Entende HTTP.

Entende JSON.

Depois traduz tudo para o universo do IBM Z.

Do outro lado...

O programa COBOL continua exatamente igual.

Sem precisar conhecer HTML.

Sem conhecer JavaScript.

Sem conhecer navegador.

Ele apenas recebe parâmetros.

Processa.

Responde.

E volta ao trabalho.



CICS continua fazendo o que sempre fez

Muita gente acredita que REST substituiu CICS.

Na verdade aconteceu justamente o contrário.

REST fez ainda mais aplicações dependerem do CICS.

O fluxo normalmente é este.

Browser

↓

REST API

↓

z/OS Connect

↓

CICS

↓

Programa COBOL

Observe que o CICS continua sendo o gerente das transações.

Ele controla segurança.

Sincronismo.

Rollback.

Commit.

Performance.

Disponibilidade.

Nada mudou.

Apenas surgiram novos clientes.

Antes eram terminais 3270.

Hoje são navegadores.



COBOL continua sendo o cérebro

Existe uma frase que gosto muito.

JavaScript encanta. COBOL decide.

É JavaScript quem anima a tela.

É JavaScript quem valida um campo.

É JavaScript quem muda uma cor.

Mas quem realmente decide se um empréstimo será aprovado?

Quem calcula juros?

Quem verifica limite de crédito?

Quem consulta regras fiscais?

Quem processa milhões de transações diariamente?

COBOL.

Sempre ele.

O navegador apenas apresenta o resultado.



DB2 continua guardando o tesouro

Toda aplicação precisa armazenar informações.

Clientes.

Contas.

Contratos.

Apólices.

Empréstimos.

Pedidos.

Cartões.

É aqui que entra o DB2.

O programa COBOL faz consultas.

Atualiza registros.

Executa commits.

Controla integridade.

Depois transforma essas informações em JSON.

E o navegador recebe tudo pronto.

Perceba algo interessante.

O navegador nunca conversa diretamente com o banco.

Isso seria extremamente perigoso.

Existe sempre uma camada intermediária protegendo os dados.



Organização faz diferença

Quando começamos nossos primeiros programas HTML normalmente criamos apenas um arquivo.

index.html

Pouco tempo depois aparecem outros.

style.css

app.js

logo.png

Mais tarde surgem dezenas.

Depois centenas.

É exatamente nesse momento que aprendemos a organizar projetos.

Projeto

│

├── index.html

├── css

├── js

├── images

├── api

Essa organização pode parecer apenas estética.

Não é.

Ela facilita manutenção.

Facilita testes.

Facilita integração contínua.

Facilita Git.

Facilita DevOps.

Curiosamente...

É exatamente o mesmo motivo pelo qual existem COPYBOOKS.



COPYBOOKS nasceram muito antes dos Frameworks

Muitos desenvolvedores Web acreditam que reutilização nasceu com Frameworks modernos.

Na verdade...

Programadores COBOL fazem isso desde os anos 60.

Sempre que escrevemos

COPY CLIENTE.

Estamos reutilizando componentes.

Assim como um projeto Web reutiliza:

componentes

bibliotecas

frameworks

módulos

Mudam os nomes.

O princípio continua exatamente igual.


Git mudou a forma de trabalhar

Durante décadas o controle de versões no Mainframe foi responsabilidade de ferramentas como:

  • Endevor

  • ISPW

  • Librarian

  • Panvalet

Hoje Git tornou-se praticamente obrigatório.

Não importa se o código está em Java.

Python.

COBOL.

REXX.

Assembler.

Todos podem viver no mesmo repositório.

E isso abriu uma porta enorme para DevOps.



DevOps aproximou dois mundos

Antigamente existia uma divisão muito clara.

O desenvolvedor escrevia código.

Outra equipe compilava.

Outra homologava.

Outra implantava.

Hoje pipelines fazem praticamente tudo isso automaticamente.

Commit

↓

Build

↓

Testes

↓

Análise

↓

Deploy

Essa automação não substitui o programador.

Ela elimina tarefas repetitivas.

E permite que ele invista tempo onde realmente faz diferença.

Criando soluções.

Não apertando botões.



O novo profissional IBM Z

Chegamos então ao ponto mais importante de toda esta formação.

O profissional IBM Z moderno não conhece apenas COBOL.

Ele entende a jornada completa.

COBOL

↓

JSON

↓

REST

↓

HTML

↓

CSS

↓

JavaScript

↓

Git

↓

DevOps

↓

Cloud

↓

IBM Z

Isso não significa abandonar o Mainframe.

Significa ampliar horizontes.

Quanto mais camadas você compreende, maior passa a ser seu valor dentro da organização.

Você deixa de ser apenas um programador COBOL.

Passa a ser alguém capaz de conversar com equipes Web, arquitetos de soluções, especialistas em APIs, profissionais DevOps e engenheiros de Cloud.

E isso muda completamente sua carreira.



☕ Um café antes de continuar...

Existe um detalhe curioso que costuma passar despercebido.

Durante décadas ouvimos que "o futuro substituiria o Mainframe".

Mas aconteceu exatamente o contrário.

Foi o Mainframe que aprendeu a conversar com o futuro.

Hoje ele fala REST, entende JSON, integra-se com Cloud, participa de pipelines DevOps, conversa com aplicações móveis e continua executando, silenciosamente, bilhões de transações por dia.

Talvez essa seja a maior lição desta formação.

O IBM Z nunca ficou parado. Nós é que demoramos para perceber o quanto ele evoluiu.

Parte III — O Desenvolvedor IBM Z Moderno e o Futuro que Já Chegou

"O melhor momento para aprender HTML foi quando surgiu. O segundo melhor momento é hoje. Porque o IBM Z já está esperando por você."

Depois de percorrer toda a jornada desta formação, uma pergunta inevitavelmente aparece.

"O que devo aprender agora?"

Essa talvez seja a maior ansiedade de quem vem do mundo COBOL.

São tantas tecnologias...

HTML.

CSS.

JavaScript.

Git.

REST.

JSON.

Cloud.

DevOps.

Containers.

Docker.

Kubernetes.

OpenShift.

Inteligência Artificial.

À primeira vista parece impossível.

Mas existe uma boa notícia.

Você não precisa aprender tudo de uma vez.

Muito menos abandonar o conhecimento acumulado durante anos.

Na verdade, você já possui aquilo que a maioria dos desenvolvedores modernos ainda está tentando adquirir.

Conhecimento de negócio.

E isso vale ouro.


A árvore do conhecimento

Durante a apresentação utilizamos uma imagem bastante simbólica.

Uma árvore.

À primeira vista ela parece apenas um desenho bonito.

Mas existe um significado escondido.

As raízes

São invisíveis.

Pouca gente presta atenção nelas.

Mas sustentam tudo.

No IBM Z elas representam:

  • COBOL

  • JCL

  • CICS

  • DB2

  • VSAM

  • RACF

  • TSO/ISPF

Curiosamente...

São justamente as tecnologias que mais movimentam dinheiro no planeta.

Ninguém faz propaganda delas.

Mas bilhões de transações acontecem todos os dias graças a elas.


O tronco

O tronco representa aquilo que conecta todas as áreas.

Na nossa metáfora...

É o próprio IBM z17.

Não apenas como computador.

Mas como plataforma.

Segura.

Disponível.

Escalável.

Resiliente.

Enquanto centenas de tecnologias aparecem e desaparecem ao longo das décadas...

O IBM Z continua crescendo.


Os galhos

É onde surgem as novidades.

HTML.

CSS.

JavaScript.

REST.

JSON.

Git.

Cloud.

DevOps.

IA.

Todos eles crescem apoiados nas raízes.

Sem elas...

A árvore não existe.


O roadmap de evolução

Ao longo da apresentação surgiu uma estrada colorida.

Ela representa algo muito importante.

Você não aprende tudo ao mesmo tempo.

Você sobe um degrau por vez.

Primeiro passo

HTML.

Aprenda estrutura.

Nada além disso.

Não tente decorar centenas de elementos.

Entenda a lógica.


Segundo passo

CSS.

Faça páginas bonitas.

Aprenda cores.

Espaçamento.

Layouts.

Responsividade.

Não é preciso virar designer.

Apenas tornar a informação agradável.


Terceiro passo

JavaScript.

Agora a página ganha vida.

Botões passam a funcionar.

Campos são validados.

Elementos aparecem.

Desaparecem.

Mudam dinamicamente.

É nesse momento que muitos programadores COBOL começam a sorrir.

Porque finalmente enxergam lógica de programação novamente.


Quarto passo

REST.

Agora você entende que aplicações conversam.

E que praticamente toda integração moderna utiliza APIs.


Quinto passo

JSON.

Descobre que arquivos gigantes de integração deram lugar a pequenos documentos extremamente simples.


Sexto passo

Git.

Talvez seja a ferramenta que mais muda a maneira de trabalhar.

Commits.

Branches.

Merge.

Pull Request.

Code Review.

Tudo passa a fazer parte da rotina.


Sétimo passo

DevOps.

Agora o código não vive mais sozinho.

Ele entra em pipelines.

Executa testes.

É compilado automaticamente.

Implantado.

Monitorado.

Tudo praticamente sem intervenção humana.


Oitavo passo

Cloud.

Você percebe que Cloud não substituiu o Mainframe.

Ela apenas adicionou mais um ambiente de execução.

Na prática...

Os dois trabalham juntos.


Nono passo

Inteligência Artificial.

Chegamos ao presente.

Mas cuidado.

Existe um enorme equívoco acontecendo.

A IA não substitui conhecimento.

Ela acelera conhecimento.

Quanto mais experiência possui o profissional...

Melhores perguntas ele faz.

Melhores respostas recebe.


Um pequeno segredo da IBM

Existe uma curiosidade interessante.

Durante muitos anos, aprender IBM significava decorar comandos.

Hoje não.

A IBM mudou completamente sua estratégia.

Ela deseja profissionais capazes de integrar tecnologias.

É exatamente por isso que vemos cada vez mais cursos envolvendo:

  • Git

  • APIs

  • HTML

  • JavaScript

  • OpenShift

  • Red Hat

  • Linux

  • Python

  • DevOps

  • IA

Tudo convivendo naturalmente com COBOL.


Easter Egg nº 1 — O retorno da BMS

Você provavelmente achou curioso estudar HTML.

Mas observe.

Uma página HTML possui:

Header.

Body.

Campos.

Botões.

Mensagens.

Formulários.

Menus.

Parece familiar?

Porque é.

BMS fazia exatamente isso.

A diferença é que hoje existem milhões de cores.

Animações.

Responsividade.

E um mouse.

No restante...

Os conceitos continuam incrivelmente parecidos.


Easter Egg nº 2 — O navegador virou um terminal 3270

Calma...

Antes de fechar a página dizendo que enlouqueci...

Pense comigo.

O navegador:

Recebe dados.

Envia comandos.

Mostra telas.

Executa transações.

Atualiza informações.

Consulta banco.

Exatamente como um terminal.

A diferença é que o navegador ganhou superpoderes.

Renderiza vídeos.

Executa JavaScript.

Faz chamadas REST.

Mostra gráficos.

Integra mapas.

Mas continua sendo uma interface.

Assim como o 3270 sempre foi.


Easter Egg nº 3 — HTML não substitui COBOL

Esse talvez seja o maior medo de muitos iniciantes.

"Vou precisar abandonar COBOL?"

Não.

Pelo contrário.

Quanto maior a adoção de APIs...

Mais programas COBOL acabam sendo reutilizados.

Muitos sistemas escritos há quarenta anos hoje atendem aplicações Web modernas.

Mudou apenas a porta de entrada.


O maior erro dos iniciantes

Depois de ministrar diversos treinamentos, comecei a perceber um padrão.

O erro raramente é técnico.

É psicológico.

O aluno olha para a quantidade de tecnologias e conclui:

"Jamais vou aprender tudo isso."

Mas ninguém aprende.

Nem mesmo quem trabalha há trinta anos.

Todos continuam estudando.

Inclusive os IBM Fellows.

Inclusive os Distinguished Engineers.

Inclusive quem desenvolveu boa parte dessas tecnologias.

Aprender nunca termina.


O conselho que gostaria de ter ouvido em 1988

Quando comecei minha carreira, imaginava que bastava aprender COBOL.

Depois vieram CICS.

DB2.

JCL.

VSAM.

REXX.

Assembler.

TCP/IP.

MQ.

Java.

Web Services.

XML.

JSON.

REST.

Git.

Cloud.

DevOps.

IA.

No início achei que era um problema.

Hoje percebo que foi um privilégio.

Poucas profissões permitem acompanhar tantas revoluções tecnológicas sem abandonar completamente aquilo que aprendemos décadas atrás.

O programador COBOL continua reconhecendo um IF.

Um PERFORM.

Um MOVE.

Da mesma forma que reconhece hoje um IF em JavaScript.

A lógica continua sendo a mesma.

Mudam apenas as ferramentas.


O verdadeiro objetivo desta formação

Se ao terminar estas aulas você decorar todos os comandos HTML...

O curso terá sido apenas razoável.

Se aprender Flexbox.

Grid.

DOM.

Eventos.

REST.

JSON.

Também será um bom resultado.

Mas existe um objetivo muito maior.

Perder o medo da palavra "Web".

Porque ela deixou de ser um território distante.

Hoje faz parte do ecossistema IBM Z.


Uma última xícara de café...

Quando observo um IBM z17 processando milhares de transações por segundo enquanto um navegador moderno exibe gráficos, animações e respostas instantâneas, lembro-me de como essa história começou.

Lá atrás, um simples terminal verde.

Depois uma tela BMS.

Mais tarde o TCP/IP.

Vieram XML e Web Services.

Depois JSON.

REST.

Cloud.

Git.

DevOps.

Agora Inteligência Artificial.

O curioso é que, em todas essas fases, alguém decretou que o Mainframe estava ficando para trás.

E, em todas elas, o IBM Z respondeu da melhor maneira possível.

Evoluindo.

Sem perder sua essência.

Sem abandonar sua confiabilidade.

Sem deixar de ser o coração silencioso das maiores empresas do planeta.

Talvez essa seja a maior lição desta jornada.

As tecnologias mudam.

As interfaces evoluem.

As linguagens ganham novos recursos.

Mas a lógica, a arquitetura bem construída e a capacidade de resolver problemas reais continuam sendo o verdadeiro diferencial de um grande profissional.

No fim das contas, HTML, CSS, JavaScript, REST, JSON, Git, DevOps e Inteligência Artificial não são o destino.

São apenas novas ferramentas nas mãos de quem já aprendeu, há muito tempo, que um bom programa começa antes mesmo da primeira linha de código.

E enquanto houver desafios para resolver, clientes para atender e sistemas críticos para manter funcionando, sempre haverá espaço para quem estiver disposto a aprender.

Então abasteça a caneca, abra o editor de código e continue estudando.

Porque a próxima grande evolução do IBM Z provavelmente já começou.

E, quem sabe, ela será escrita por você.

Do conceito à prática: os laboratórios da Formação APPDEV

Teoria sem prática é como um programa COBOL que nunca saiu do editor: pode estar elegante, bem comentado e perfeitamente identado, mas ainda não processou uma única transação.

Por isso, a Formação APPDEV não termina quando o último slide desaparece da tela.

Ela continua nos laboratórios.

É nesses ambientes que HTML deixa de ser apenas uma sequência de tags, CSS deixa de ser decoração, JavaScript deixa de ser uma promessa e a integração com o ecossistema IBM Z começa a ganhar forma diante dos nossos olhos.

Prepare a caneca.

Abra o navegador.

E vamos colocar a mão na massa.


IBM Web Development Labs

O primeiro ponto de partida é o laboratório de desenvolvimento Web utilizado durante a formação:

IBM Web Development Labs
https://vagnerbellacosa.github.io/Lab_WebdevelopmentCoursera/

Nesse ambiente, o aluno pode revisar os fundamentos de HTML, CSS e JavaScript, observar a organização de uma aplicação Web e experimentar a construção de páginas diretamente no navegador.

É o lugar ideal para praticar:

  • estruturação de páginas com HTML;

  • aplicação de estilos com CSS;

  • criação de comportamentos com JavaScript;

  • eventos de clique e formulário;

  • manipulação do DOM;

  • organização de componentes;

  • preparação para consumo de APIs.

O objetivo não é apenas copiar códigos.

É alterar.

Quebrar.

Testar.

Corrigir.

Executar novamente.

Programação continua sendo uma ciência experimental, mesmo quando o laboratório cabe dentro de uma aba do navegador.

O endereço desse laboratório aparece diretamente na apresentação APPDEV como recurso para continuidade dos estudos.


LAB IBM IPL Mainframe

Depois de compreender o funcionamento da camada Web, vale retornar ao coração da infraestrutura:

LAB IBM IPL Mainframe
https://vagnerbellacosa.github.io/LAB_IBM_IPLMainframe/

IPL significa Initial Program Load.

É, de maneira simplificada, o processo de inicialização de um sistema IBM Z. Entretanto, compará-lo apenas ao boot de um computador pessoal seria uma simplificação quase ofensiva.

Em um ambiente corporativo, um IPL envolve planejamento, volumes, parâmetros, dispositivos, subsistemas, segurança, disponibilidade e uma sequência cuidadosamente controlada de operações.

O laboratório ajuda o estudante a enxergar o IBM Z não apenas como uma máquina que executa COBOL, mas como uma plataforma completa, composta por diversas camadas trabalhando em conjunto.

Essa visão é fundamental para o Desenvolvedor IBM Z Moderno.

Mesmo que ele não execute um IPL em produção, precisa compreender o ambiente no qual seus programas vivem.

A apresentação disponibiliza esse laboratório como uma etapa complementar da jornada.


Lab IBM Storage Management

Todo programa precisa de dados.

E todo dado precisa morar em algum lugar.

Lab IBM Storage Management
https://vagnerbellacosa.github.io/Lab_IBM_StorageManagement/

Nesse laboratório, o aluno pode ampliar a compreensão sobre armazenamento no ecossistema IBM Z.

Isso inclui conceitos relacionados a:

  • datasets;

  • volumes;

  • DASD;

  • organização de arquivos;

  • gerenciamento de espaço;

  • políticas de armazenamento;

  • disponibilidade;

  • proteção de dados;

  • relacionamento entre aplicação e infraestrutura.

No mundo Web, falamos em arquivos, pastas, objetos, buckets e bancos de dados.

No IBM Z, encontramos datasets sequenciais, PDS, PDSE, VSAM, catálogos, volumes e políticas SMS.

Novamente, mudam as ferramentas e os nomes.

A necessidade permanece a mesma:

guardar a informação correta, no lugar correto, com segurança e disponibilidade.

O link para o laboratório de Storage Management também faz parte dos materiais de continuidade presentes na apresentação.


LAB IBM Capacity

Uma aplicação pode funcionar perfeitamente para dez usuários e entrar em colapso quando o décimo primeiro aparece.

É nesse momento que descobrimos que desenvolver software não significa apenas produzir resultados corretos.

Também significa produzir resultados dentro do tempo esperado.

LAB IBM Capacity
https://vagnerbellacosa.github.io/LAB_IBM_Capacity/

O laboratório de capacidade introduz uma visão essencial para aplicações corporativas:

  • utilização de CPU;

  • consumo de memória;

  • carga de trabalho;

  • crescimento de demanda;

  • gargalos;

  • throughput;

  • tempo de resposta;

  • planejamento de recursos;

  • comportamento do ambiente em períodos de pico.

Imagine uma aplicação Web consultando uma API REST que chama z/OS Connect, entra no CICS, executa COBOL e consulta DB2.

Cada camada consome recursos.

Cada camada pode introduzir espera.

Cada componente precisa ser observado.

O usuário não está preocupado com o número de instruções executadas.

Ele apenas sabe que clicou no botão e está esperando.

Por isso, capacidade e desempenho também fazem parte da experiência do usuário.

O laboratório de Capacity aparece na apresentação como parte da trilha prática recomendada.


Lab War Room Mainframe

Alguns problemas não chegam educadamente durante o horário comercial.

Eles aparecem de madrugada.

No fechamento mensal.

Durante uma grande campanha.

Ou exatamente quando todos acreditavam que a mudança estava sob controle.

Lab War Room Mainframe
https://vagnerbellacosa.github.io/LAB_WarRoom_Mainframe/

O conceito de War Room representa a investigação coordenada de incidentes.

É o lugar — físico ou virtual — onde profissionais de diferentes áreas analisam juntos:

  • sintomas;

  • logs;

  • mensagens;

  • falhas;

  • tempos de resposta;

  • consumo de recursos;

  • dependências;

  • mudanças recentes;

  • comportamento das aplicações;

  • impacto para o negócio.

No ambiente moderno, uma falha aparentemente simples no navegador pode ter começado muito longe dele.

O botão não respondeu.

Mas a causa pode estar em:

JavaScript
    ↓
REST API
    ↓
z/OS Connect
    ↓
CICS
    ↓
COBOL
    ↓
DB2
    ↓
Storage

É por isso que o profissional capaz de compreender toda a cadeia possui enorme valor.

Ele não observa apenas a mensagem de erro.

Ele segue as pegadas.

O laboratório War Room Mainframe também está entre os recursos indicados na apresentação APPDEV.


Para ir mais longe: Bellacosa Mainframe

A formação termina.

O aprendizado, felizmente, não.

Para continuar explorando COBOL, CICS, DB2, JCL, VSAM, APIs, HTML, CSS, JavaScript, DevOps, segurança, arquitetura e cultura Mainframe, visite:

Um Café no Bellacosa Mainframe
https://eljefemidnightlunch.blogspot.com/

O blog funciona como uma grande biblioteca construída ao longo do tempo.

Há artigos para iniciantes.

Conteúdos técnicos aprofundados.

Histórias sobre a evolução da computação.

Analogias com filmes, séries, quadrinhos, ficção científica e cultura popular.

Porque aprender tecnologia também significa construir memórias.

Um conceito técnico pode ser esquecido.

Mas uma boa história costuma permanecer.

A apresentação indica o Bellacosa Mainframe como espaço para aprofundamento e continuidade dos estudos.


Projeto Coursera Web Developer no GitHub

Ler códigos é importante.

Executá-los é melhor.

Modificá-los é onde o aprendizado realmente começa.

Projeto Coursera Web Developer
https://github.com/VagnerBellacosa/Lab_WebdevelopmentCoursera

Nesse repositório, o aluno pode explorar a organização de um projeto real, comparar arquivos, analisar versões e compreender como HTML, CSS e JavaScript convivem dentro de uma estrutura profissional.

Um repositório Git não é apenas um lugar para guardar código.

Ele registra a história do projeto.

Mostra o que mudou.

Quando mudou.

Por que mudou.

E quem realizou a alteração.

Essa rastreabilidade aproxima o desenvolvimento Web das práticas modernas de DevOps utilizadas também no IBM Z.

O projeto e seu endereço no GitHub aparecem entre os materiais finais da apresentação.


Mais repositórios HTML: mão na massa

Para explorar outros exemplos, projetos e experiências relacionadas a HTML, acesse:

Repositórios HTML de Vagner Bellacosa
https://github.com/VagnerBellacosa?tab=repositories&q=html

Aqui vale seguir uma pequena rotina de laboratório:

  1. Escolha um projeto.

  2. Observe a estrutura de diretórios.

  3. Localize o index.html.

  4. Identifique os arquivos CSS.

  5. Encontre os códigos JavaScript.

  6. Execute a aplicação.

  7. Altere um elemento.

  8. Teste novamente.

  9. Quebre alguma coisa propositalmente.

  10. Descubra como corrigir.

O aprendizado verdadeiro começa quando deixamos de ser visitantes do código e passamos a ser seus investigadores.

A apresentação encerra a seção prática justamente apontando para os repositórios HTML disponíveis no GitHub.


Uma trilha prática sugerida

Para aproveitar melhor os materiais, siga esta sequência:

1. IBM Web Development Labs
              ↓
2. Projeto Web Developer no GitHub
              ↓
3. Repositórios HTML
              ↓
4. LAB IBM IPL Mainframe
              ↓
5. Lab IBM Storage Management
              ↓
6. LAB IBM Capacity
              ↓
7. Lab War Room Mainframe
              ↓
8. Bellacosa Mainframe

Começamos pela interface.

Seguimos para o código.

Entramos no controle de versões.

Descemos até a infraestrutura.

Observamos armazenamento e capacidade.

Investigamos incidentes.

E retornamos ao blog para continuar estudando.

Essa é a verdadeira jornada do Desenvolvedor IBM Z Moderno.

Ele não precisa dominar todas as áreas como especialista.

Mas precisa compreender como elas se conectam.


O diploma encerra uma etapa, não a jornada

Ao terminar a Formação APPDEV, o aluno leva muito mais do que alguns comandos HTML, propriedades CSS ou funções JavaScript.

Ele passa a compreender uma cadeia completa:

Usuário
   ↓
Browser
   ↓
HTML + CSS + JavaScript
   ↓
REST API + JSON
   ↓
z/OS Connect
   ↓
CICS
   ↓
COBOL
   ↓
DB2
   ↓
IBM z17

Essa visão integrada é o verdadeiro resultado da formação.

O certificado registra que uma etapa foi concluída.

Os laboratórios demonstram que a prática começou.

O GitHub registra a evolução.

E o conhecimento de negócio transforma tudo isso em valor.

Por isso, quando alguém perguntar o que existe entre um botão HTML e uma transação COBOL, você não precisará mais imaginar dois mundos separados.

Verá uma única arquitetura.

Uma longa linha luminosa atravessando navegador, API, middleware, transação, programa e banco de dados.

De um lado, a experiência do usuário.

Do outro, a confiabilidade do IBM Z.

No meio deles...

O Desenvolvedor IBM Z Moderno.

Com uma caneca de café sobre a mesa e muitos caminhos ainda esperando para serem explorados.


quarta-feira, 8 de outubro de 2025

☕🏛️🔥 O Mainframe Nunca Foi Lento: Você Só Não Entendeu o Que o CICS Está Fazendo nos Bastidores

 

,

Bellacosa Mainframe abre a caixa de pandora os bastidores do CICS

☕🏛️🔥

“O Mainframe Nunca Foi Lento: Você Só Não Entendeu o Que o CICS Está Fazendo nos Bastidores”

Uma Jornada Profunda pelo CICS TS, Processamento Transacional e a Engenharia Invisível que Sustenta o Mundo Digital

Por Bellacosa Mainframe — Para Sysprogs Padawans que Querem Entender o Coração do IBM Z


☕ O Grande Equívoco da TI Moderna

Existe uma frase que todo profissional de mainframe já ouviu:

“Mainframe é coisa antiga.”

E normalmente essa frase vem de alguém que:

  • nunca viu um dump IPCS

  • nunca abriu um CEMT

  • nunca analisou um deadlock

  • nunca precisou garantir integridade para bilhões de dólares em transações

Porque quando você realmente entra no universo do:

🔥 CICS Transaction Server

você percebe algo assustador:

☕ muitos sistemas modernos ainda estão tentando resolver problemas que o CICS já resolvia há décadas.


🏛️ O Que é o CICS de Verdade?

O padawan normalmente aprende:

“CICS é terminal verde.”

ERRADO.

Profundamente errado.

O CICS nunca foi apenas tela 3270.

Ele sempre foi:

  • transaction manager

  • middleware enterprise

  • application server

  • runtime transacional

  • coordenador de recoverability

  • engine de integridade concorrente


☕ O CICS é praticamente um “mini sistema operacional transacional” rodando dentro do z/OS.


🏛️ O Verdadeiro Problema que o CICS Resolve

Vamos simplificar brutalmente:

Imagine:

10 milhões de pessoas

fazendo simultaneamente:

  • PIX

  • saque

  • pagamento

  • cartão

  • reserva aérea

  • compra online

Agora responda:

🔥 como impedir que tudo vire caos?


☕ Como impedir:

  • saldo negativo incorreto

  • pagamentos duplicados

  • corrupção de dados

  • concorrência destrutiva

  • travamentos

  • inconsistência financeira


🏛️ É EXATAMENTE isso que o CICS faz.

Silenciosamente.

Todos os dias.


☕ TRANSACTION

O Conceito Mais Importante do Mundo Enterprise

O usuário vê:

“Transferência realizada.”

Mas internamente existe uma:

🔹 TRANSACTION


☕ Uma transaction representa:

🔥 uma unidade lógica completa de negócio.


🏛️ Exemplo

Debitar conta A
Creditar conta B

Parece simples.

Mas pense profundamente:

🔥 e se ocorrer falha no meio?


☕ É aqui que nasce a engenharia transacional.


🏛️ UNIT OF WORK

O Pacto Sagrado da Integridade

O CICS trata tudo como:

🔹 Unit of Work (UOW)


☕ Significa:

ou tudo acontece…

🔥 ou nada acontece.


🏛️ Isso é Atomicidade.

Uma das propriedades ACID.


☕ Fluxo clássico:

1. Lock contas
2. Validar saldo
3. Debitar origem
4. Creditar destino
5. Commit

🔥 Se QUALQUER etapa falhar:

rollback automático.


☕ O dinheiro não desaparece.

O sistema volta atrás.


🏛️ O Que o Padawan Precisa Entender

Falha NÃO é o problema.

🔥 Corrupção é o problema.


☕ O CICS foi criado para:

🔹 falhar sem destruir integridade.


🏛️ TASK

A Entidade Viva da Transaction

Quando uma transaction inicia…

o CICS cria uma:

🔹 TASK


☕ A TASK é:

🔥 a execução ativa da transaction.


🏛️ Exemplo

Usuário A → TASK A
Usuário B → TASK B
Usuário C → TASK C

☕ Todas simultaneamente.


🏛️ E Aqui Surge o Verdadeiro Monstro:

MULTITASKING

O CICS executa:

🔥 milhares de TASKS concorrentes.


☕ Todas disputando:

  • DB2

  • VSAM

  • MQ

  • CPU

  • memória

  • recursos compartilhados


🏛️ Sem controle isso seria um desastre.

Então entra o:

🔹 CICS Dispatcher


☕ O maestro invisível do ambiente.

Ele controla:

  • prioridades

  • waits

  • CPU

  • scheduling

  • concorrência


🔥 O usuário acha que está sozinho.

Mas existem milhares de tasks coexistindo.


🏛️ REENTRANCY

O Conceito que Todo Sysprog Junior Precisa Gravar na Alma

Aqui muitos iniciantes quebram a cabeça.

O CICS usa:

🔹 reentrant programs


☕ Isso significa:

UMA única cópia do programa na memória.


🏛️ Mas milhares de usuários executando simultaneamente.


☕ Como isso é possível?

Porque:

🔥 o código é compartilhado…

🔥 os dados são isolados.


🏛️ Arquitetura Conceitual

Programa COBOL único
        ↓
Task A → Working Storage A
Task B → Working Storage B
Task C → Working Storage C

☕ Isso economiza memória absurdamente.

Lembre-se:

o CICS nasceu quando memória era caríssima.


🏛️ DEADLOCK

O Congestionamento Invisível

Agora imagine:

Task A segura recurso X
Task B segura recurso Y

Depois:

Task A quer Y
Task B quer X

🔥 BOOM.

Deadlock.


☕ Nenhuma consegue continuar.


🏛️ O CICS detecta isso e mata uma das tasks.

Depois executa:

  • rollback

  • backout

  • liberação de locks


☕ Isso acontece silenciosamente milhares de vezes.


🏛️ O Sysprog Junior Precisa Entender Uma Verdade Dolorosa

Concorrência é MUITO difícil.

Muito mais difícil do que frameworks modernos fazem parecer.


☕ O CICS trata isso desde os anos 60.


🏛️ “MAINFRAME NÃO EVOLUIU”

A Maior Mentira da TI Moderna

O padawan normalmente imagina:

CICS = terminal verde

Mas o CICS moderno possui:

  • REST APIs

  • JSON

  • Java

  • Node.js

  • cloud integration

  • z/OS Connect

  • Liberty JVM

  • Web Services


☕ O COBOL continua lá.

Mas agora falando:

{
  "customer":"Maria"
}

🏛️ z/OS CONNECT EE

A Ponte Entre o Mundo Moderno e o Mainframe

Isso foi revolucionário.

Hoje o fluxo é:

Mobile App
      ↓
REST API
      ↓
z/OS Connect
      ↓
CICS
      ↓
COBOL
      ↓
DB2

☕ O desenvolvedor mobile nem imagina que existe COMMAREA por trás.


🏛️ NODE.JS NO CICS

Sim, JavaScript no Mainframe

Quando o padawan descobre isso normalmente reage assim:

“COMO ASSIM?”

☕ Mas sim.

O CICS moderno suporta:

🔹 Node.js

🔹 Java

🔹 REST

🔹 APIs modernas


🏛️ O COBOL continua fazendo:

  • regras de negócio

  • recoverability

  • integridade

Enquanto:

  • Node.js

  • Java

  • APIs REST

fazem integração moderna.


☕ Isso é arquitetura híbrida enterprise real.


🏛️ O GRANDE SEGREDO DO CICS

O segredo nunca foi:

velocidade pura

O segredo é:

🔥 velocidade COM integridade.


☕ Qualquer sistema pode ser rápido.

Poucos conseguem ser:

  • rápidos

  • concorrentes

  • auditáveis

  • recuperáveis

  • consistentes

ao mesmo tempo.


🏛️ O Sysprog Junior Precisa Entender Outra Verdade

Quando você administra CICS…

você não administra apenas software.

Você administra:

🔥 confiança digital.


☕ Porque bilhões de pessoas dependem disso sem perceber.


🏛️ O Usuário Só Vê:

“PIX realizado”

☕ Mas nos bastidores existem:

  • tasks

  • dispatcher

  • locks

  • rollback

  • syncpoint

  • journaling

  • reentrancy

  • storage management

  • recovery manager


🔥 Tudo funcionando em milissegundos.


🏛️ A Grande Lição Final para o Padawan

O CICS não é apenas um software antigo sobrevivendo.

Ele é:

☕ uma das maiores obras de engenharia transacional já criadas.


🔥 E o mais impressionante:

muitos conceitos modernos ainda derivam diretamente dele.


☕ Frase Final Bellacosa Mainframe

“O usuário vê apenas um aplicativo moderno no celular.
Mas no fundo… existe um CICS coordenando milhares de tasks, protegendo integridade, resolvendo deadlocks e garantindo que o dinheiro continue existindo corretamente no banco.”

sexta-feira, 8 de dezembro de 2023

24 Horas no Bellacosa Mainframe: Jack Bauer, COBOL e a API que precisava entrar no CICS antes que o relógio chegasse a zero graças ao Zos Connect

 

Bellacosa Mainframe e o zos connect

☕ Um Café no Bellacosa Mainframe

24 Horas no Bellacosa Mainframe: Jack Bauer, COBOL e a API que precisava entrar no CICS antes que o relógio chegasse a zero

⏱️ z/OS Connect, REST, JSON, OpenAPI, CICS, IMS, Db2, RACF, SAF, zIIP, OpenTelemetry e o estranho caso em que Jack Bauer descobriu que reescrever 35 anos de COBOL levaria um pouco mais de 24 horas

03:17:42

O telefone toca.

Isso nunca é bom.

Especialmente quando você trabalha com mainframe.

Do outro lado da linha alguém pronuncia aquelas palavras capazes de provocar mais medo em um programador COBOL do que S0C7, SOC4, deadlock no Db2 e café descafeinado juntos:

— Precisamos modernizar o legado.

Silêncio.

O relógio aparece na tela.

03:17:43
03:17:44
03:17:45

Você olha para o terminal 3270.

O CICS está funcionando.

O Db2 está funcionando.

O programa COBOL que consulta clientes está funcionando há décadas.

Milhões de transações passaram por ele.

Então surge a pergunta que deveria ser feita antes de qualquer projeto de modernização:

Se funciona, por que exatamente queremos reescrevê-lo?

Do outro lado alguém responde:

— Porque precisamos acessar isso pelo aplicativo mobile.

Jack Bauer entra na sala.

Olha para o COBOL.

Olha para o arquiteto.

Olha para o relógio.

E diz:

— Então vocês não precisam reescrever o COBOL. Precisam de uma API.

TIC. TIC. TIC. TIC.

Bem-vindo ao mundo do IBM z/OS Connect.

Pegue o café.

Temos 24 horas para colocar REST, JSON e OpenAPI diante de um programa COBOL que nasceu quando ninguém imaginava que um telefone serviria para fazer transferências bancárias.


⏱️ 04:00 — O problema nunca foi necessariamente o COBOL

Imagine que nosso banco fictício possui um programa chamado:

CLIENTE

Ele recebe:

01 CLIENTE-REQUEST.
   05 CLIENTE-ID       PIC 9(09).

E devolve:

01 CLIENTE-RESPONSE.
   05 CLIENTE-NOME     PIC X(40).
   05 CLIENTE-LIMITE   PIC 9(09)V99.
   05 CLIENTE-STATUS   PIC X(01).

Nada particularmente revolucionário.

Talvez esse programa execute dentro do CICS e consulte Db2.

Durante décadas alguma aplicação tradicional soube perfeitamente como conversar com ele.

Então chega uma equipe responsável pelo novo aplicativo mobile.

Ela não sabe o que é:

COMMAREA
EBCDIC
PIC X
PIC 9
COMP
COMP-3
EXEC CICS LINK
TSO
ISPF
3270

E existe uma boa notícia:

ela provavelmente não precisa saber.

A aplicação mobile quer algo como:

GET /clientes/123456789

e espera receber:

{
  "id": 123456789,
  "nome": "JOAO DA SILVA",
  "limite": 15000.00,
  "status": "ATIVO"
}

Aqui aparece o problema arquitetural.

Não temos necessariamente um sistema antigo incapaz de executar a regra de negócio.

Temos dois mundos falando idiomas diferentes.

De um lado:

HTTP
REST
JSON
OpenAPI
OAuth
JWT
Cloud
Mobile
Microservices

Do outro:

COBOL
CICS
IMS
Db2
copybooks
SAF
RACF

Jack Bauer olha para os dois lados.

— Precisamos de um tradutor.

É aqui que entra o IBM z/OS Connect.


⏱️ 05:00 — Afinal, o que diabos é z/OS Connect?

Para um COBOLzeiro começando agora, eu gosto desta definição:

IBM z/OS Connect é uma camada de integração que permite disponibilizar recursos e aplicações do z/OS através de APIs REST e também permite que aplicações z/OS consumam APIs externas.

Leia novamente a última parte.

Porque ela é frequentemente esquecida.

Não existe apenas:

MUNDO MODERNO
      │
      ▼
     API
      │
      ▼
 MAINFRAME

Também pode existir:

 MAINFRAME
      │
      ▼
     API
      │
      ▼
MUNDO EXTERNO

Esses dois caminhos nos levam a dois conceitos fundamentais:

API PROVIDER
API REQUESTER

Guarde esses nomes.

Jack Bauer certamente guardaria.

Ele só não teria tempo de anotá-los.


⏱️ 06:00 — API Provider: quando o mundo bate à porta do CICS

O API Provider resolve aproximadamente este cenário:

Mobile
   │
Web
   │
Cloud
   │
   ▼
REST / JSON
   │
   ▼
z/OS Connect
   │
   ▼
CICS / IMS / Db2
   │
   ▼
COBOL

Imagine novamente nosso programa de consulta de clientes.

O aplicativo envia:

GET /clientes/123456789

z/OS Connect recebe essa requisição.

Ele possui informações suficientes para entender que aquela operação está relacionada a determinado serviço no mainframe.

O JSON pode ser transformado para a estrutura esperada pelo programa.

O programa COBOL executa.

Depois acontece o caminho inverso:

COBOL
   │
estrutura tradicional
   │
   ▼
z/OS Connect
   │
JSON
   ▼
aplicação

Perceba a beleza arquitetural.

O COBOL não precisa acordar numa segunda-feira e dizer:

“A partir de hoje sou desenvolvedor REST.”

Ele continua fazendo aquilo para o qual foi criado.


⏱️ 07:00 — Não estamos transformando COBOL em REST

Essa diferença parece pequena, mas é gigantesca.

Uma simplificação perigosa seria dizer:

COBOL → REST

Não.

O programa COBOL continua sendo COBOL.

Estamos criando uma interface moderna para uma capacidade existente.

Pense assim:

             CONTRATO
              OpenAPI
                 │
                 ▼
            REST / JSON
                 │
                 ▼
          z/OS Connect
                 │
        mapping / routing
                 │
                 ▼
        estrutura COBOL
                 │
                 ▼
              CICS
                 │
                 ▼
              COBOL

Isso nos leva a uma das ideias mais importantes deste café:

Modernização não significa necessariamente reescrita.

Às vezes modernizar significa tornar acessível aquilo que já funciona.


⏱️ 08:00 — A reunião em que alguém quer reescrever tudo

Você conhece a cena.

Sala de reunião.

PowerPoint.

Café ruim.

Alguém aponta para um desenho cheio de caixas coloridas e diz:

— Temos que eliminar o legado.

Pergunte:

— Por quê?

Talvez a resposta seja:

— Porque precisamos disponibilizar consulta de saldo no celular.

Mas o programa de consulta de saldo funciona?

— Sim.

Está performando?

— Sim.

É confiável?

— Sim.

Possui décadas de regras de negócio?

— Sim.

Então talvez o problema não seja:

CONSULTAR-SALDO

Talvez o problema seja somente:

COMO ACESSAR CONSULTAR-SALDO

São problemas completamente diferentes.

Reescrever pode ser necessário em alguns casos.

Mas não deveria ser automaticamente sinônimo de modernização.


⏱️ 09:00 — O tesouro escondido dentro daquele COBOL feio

Aqui mora uma coisa que os novatos precisam aprender cedo.

Você abre um programa de 15 mil linhas.

Encontra:

IF WS-CODIGO = 37
   AND WS-TIPO = 'X'
   AND WS-DATA < 19981231
      MOVE 'S' TO WS-EXCECAO
END-IF

Sua primeira reação pode ser:

— Que porcaria é essa?

Calma.

Talvez esse IF exista porque:

  • uma lei mudou;

  • houve uma fusão bancária;

  • determinado produto foi descontinuado;

  • aconteceu um incidente em produção;

  • alguma regra fiscal antiga precisa continuar sendo respeitada;

  • existem contratos históricos;

  • alguém descobriu uma exceção em 1999.

Código legado não contém apenas instruções.

Ele contém arqueologia empresarial.

Às vezes aquelas linhas horrorosas são conhecimento institucional fossilizado.

O perigo da reescrita é acreditar que compreendemos tudo simplesmente porque entendemos a sintaxe.


⏱️ 10:00 — OpenAPI entra na CTU

O próximo personagem da história é o OpenAPI.

Podemos pensar nele como um contrato descrevendo nossa API.

Por exemplo:

paths:
  /clientes/{id}:
    get:
      summary: Consulta cliente
      parameters:
        - name: id
          in: path
          required: true

Ele documenta coisas como:

endpoint
método HTTP
parâmetros
estrutura de entrada
estrutura de saída
códigos de resposta

Isso permite que diferentes equipes compartilhem um contrato comum.

O desenvolvedor mobile não precisa perguntar:

— Qual é o offset do campo CLIENTE-ID na COMMAREA?

Ele pergunta:

— Qual é o contrato da API?

Essa mudança cultural é enorme.


⏱️ 11:00 — O copybook encontra JSON

Agora chegamos a uma das partes mais interessantes.

No mainframe podemos encontrar:

01 CUSTOMER-DATA.
   05 CUSTOMER-ID      PIC 9(09).
   05 CUSTOMER-NAME    PIC X(40).
   05 CUSTOMER-BALANCE PIC S9(9)V99 COMP-3.

No universo web:

{
  "customerId": 12345,
  "customerName": "MARIA",
  "customerBalance": 3450.25
}

Veja o abismo cultural.

O frontend não quer saber que COMP-3 existe.

Aliás, se você explicar packed decimal durante a daily do React, talvez seja expulso da reunião.

O z/OS Connect pode participar justamente da transformação entre esses formatos.

Conceitualmente:

JSON
 ↓
mapping
 ↓
estrutura nativa
 ↓
COBOL
 ↓
estrutura nativa
 ↓
mapping
 ↓
JSON

E isso é maravilhoso porque preserva uma regra fundamental:

não obrigue todas as aplicações da empresa a conhecer os detalhes internos umas das outras.


⏱️ 12:00 — API Requester: plot twist!

Metade da temporada passou.

Hora da reviravolta.

Até agora o mundo estava chamando o mainframe.

Mas e se o COBOL precisar chamar o mundo?

Imagine um programa bancário precisando consultar uma cotação externa.

A API moderna oferece:

GET /exchange/USD/BRL

Resposta:

{
  "currency": "USD",
  "rate": 5.42
}

Agora temos:

COBOL
  │
  ▼
z/OS Connect
  │
  ▼
REST / JSON
  │
  ▼
API EXTERNA

É o API Requester.

Isso muda muito a percepção do mainframe.

Ele deixa de ser apenas:

“a máquina que os outros sistemas chamam”.

Também pode tornar-se consumidor de serviços modernos.


⏱️ 13:00 — Provider e Requester juntos

Agora nosso desenho fica muito mais interessante:

                    API PROVIDER

Mobile / Cloud ─── REST ───► z/OS Connect
                                  │
                                  ▼
                           CICS / IMS / Db2
                                  │
                                  ▼
                                COBOL
                                  │
                                  │
                           API REQUESTER
                                  │
                                  ▼
                              REST API
                                  │
                                  ▼
                         Serviço externo

Isso é integração bidirecional.

O mainframe deixa de parecer uma ilha.

Ele passa a participar da arquitetura distribuída da empresa.


⏱️ 14:00 — Mas espere: INTERNET → COBOL?

Jack Bauer para no corredor.

Olha para você.

— Você colocou a internet na frente da minha transação bancária?

Boa pergunta.

Porque API sem segurança é apenas uma maneira moderna de criar um incidente.

Aqui entram mecanismos como:

TLS
JWT
SAF
RACF
autenticação
autorização
controle por operação

A ideia não deveria ser:

INTERNET
   │
   ▼
COBOL

Mas algo conceitualmente muito mais parecido com:

REQUEST
   │
   ▼
TLS
   │
   ▼
AUTENTICAÇÃO
   │
   ▼
AUTORIZAÇÃO
   │
   ▼
z/OS Connect
   │
   ▼
SAF / RACF
   │
   ▼
RECURSO

O velho castelo ganhou uma porta moderna.

Não removemos os guardas.


⏱️ 15:00 — Autorização granular

Existe uma diferença importante entre:

VAGNER PODE ACESSAR A API

e:

VAGNER PODE EXECUTAR ESTA OPERAÇÃO?

Considere:

GET /contas/123

versus:

POST /transferencias

Consultar saldo e transferir dinheiro são operações completamente diferentes.

Em segurança empresarial queremos aproximar-nos do princípio:

least privilege

Ou seja:

conceder apenas aquilo que determinado usuário ou identidade realmente necessita.

Isso também mostra por que API modernization não é simplesmente instalar um servidor HTTP na LPAR e comemorar.

Existe arquitetura por trás.


⏱️ 16:00 — O telefone toca novamente

— Jack, a API está lenta.

Pronto.

Começou a produção.

Agora precisamos responder:

onde estão os 800 milissegundos?

Pode ser:

Mobile
  ↓
rede
  ↓
API Gateway
  ↓
z/OS Connect
  ↓
CICS
  ↓
COBOL
  ↓
Db2

Sem observabilidade, todos apontam para o vizinho.

O pessoal web:

— Mainframe está lento.

O mainframe:

— Aqui está normal.

A rede:

— Não é comigo.

O DBA:

— A query levou 2 ms.

E assim nasce uma war room de oito horas.


⏱️ 17:00 — OpenTelemetry encontra SMF

O universo moderno fala muito em:

metrics
logs
traces
OpenTelemetry
Prometheus
Grafana

O mainframe possui sua própria tradição de observabilidade:

SMF
RMF
CICS statistics
CICS monitoring
logs

z/OS Connect vive justamente numa região onde esses universos podem se encontrar.

E existe algo poeticamente maravilhoso nisso.

A turma cloud-native descobre distributed tracing.

O velho sysprog toma um gole de café e responde:

— Interessante. Nós também gostamos de saber para onde foi nosso CPU desde antes de você nascer.

Easter egg número 1: nunca diga a um sysprog veterano que observabilidade foi inventada junto com Kubernetes.

Você poderá assistir a uma palestra improvisada de quatro horas sobre SMF.


⏱️ 18:00 — E aquele papo de 99% no zIIP?

Aqui precisamos impedir um pequeno atentado conceitual.

Você poderá ler que mais de 99% do processamento relacionado ao z/OS Connect pode ser elegível para zIIP em determinadas condições de execução nativa.

Então alguém inevitavelmente concluirá:

“Excelente! 99% do meu COBOL vai para zIIP!”

NÃO.

Jack Bauer bate na mesa.

O relógio para durante dois segundos dramáticos.

A afirmação refere-se ao processamento do z/OS Connect, não magicamente a toda carga que existe atrás dele.

Pense:

HTTP processing
JSON transformation
z/OS Connect runtime
        │
        └────► alta elegibilidade zIIP

Depois:

CICS
COBOL
Db2
outros componentes

possuem suas próprias características e regras.

Esse detalhe é fundamental quando alguém começa a transformar arquitetura técnica em planilha financeira.


⏱️ 19:00 — Containers chegam ao mainframe

Outra surpresa para quem pensa que mainframe significa somente:

JCL + STARTED TASK + 3270

O ecossistema moderno do z/OS Connect também contempla deployment containerizado em cenários suportados.

Entram conceitos como:

OCI containers
OpenShift
z/OS Container Extensions
IBM Z

Ou seja, podemos encontrar arquiteturas muito diferentes.

Mas cuidado.

Não conclua:

“Então qualquer componente pode ser colocado em qualquer lugar.”

Características, features e restrições podem variar conforme o modelo de implantação e versão.

Regra do velho Bellacosa:

Antes de transformar um slide de arquitetura em implementação, leia a documentação da versão que realmente será instalada.

Essa frase evita mais incidentes que muita ferramenta cara.


⏱️ 20:00 — E IBM MQ?

Aqui mora outra armadilha interessante.

Em material introdutório é comum vermos juntos:

CICS
IMS
Db2
IBM MQ

Mas suporte depende da feature e geração utilizada.

O ecossistema histórico do z/OS Connect possui diferenças entre gerações e recursos.

Portanto:

“z/OS Connect suporta X” não é uma informação completa sem perguntar versão, feature e cenário.

Isso vale para MQ e praticamente qualquer produto empresarial com anos de evolução.

Easter egg número 2: em mainframe, a resposta para “isso é suportado?” frequentemente começa com:

“Depende do release.”

Se alguém responder imediatamente “sim” sem perguntar versão, comece a ficar desconfiado.


⏱️ 21:00 — API Management não é z/OS Connect

Outra confusão clássica.

Podemos ter:

CONSUMIDORES
     │
     ▼
API MANAGEMENT
     │
     ▼
z/OS Connect
     │
     ▼
CICS / IMS / Db2

API Management pode cuidar de coisas como:

catálogo
lifecycle
analytics
policies
plans
governança
consumidores

z/OS Connect possui foco específico na integração entre APIs e recursos z/OS.

São papéis complementares.

Pense num aeroporto.

API Management administra boa parte da relação com passageiros, rotas, regras e portas.

z/OS Connect é o intérprete altamente especializado que sabe conversar com aquela aeronave de 300 toneladas chamada CICS.


⏱️ 22:00 — Passo a passo mental para criar nossa API

Vamos montar uma operação conceitual.

Temos:

Programa: CLIENTE
Ambiente: CICS
Entrada: CLIENTE-ID
Saída:
   CLIENTE-NOME
   CLIENTE-LIMITE
   CLIENTE-STATUS

Passo 1 — Descubra a capacidade de negócio

Não comece pelo REST.

Pergunte:

O que esse programa realmente faz?

Resposta:

CONSULTAR CLIENTE

Passo 2 — Entenda entrada e saída

Localize copybooks e estruturas.

05 CLIENTE-ID PIC 9(09).

Saída:

05 CLIENTE-NOME   PIC X(40).
05 CLIENTE-LIMITE PIC 9(09)V99.
05 CLIENTE-STATUS PIC X.

Passo 3 — Pense na API como contrato

Por exemplo:

GET /clientes/{id}

Passo 4 — Defina representação externa

{
   "id": 123,
   "nome": "MARIA",
   "limite": 8000.00,
   "status": "ATIVO"
}

Passo 5 — Configure o mapping

Conceitualmente:

id
   ↕
CLIENTE-ID

nome
   ↕
CLIENTE-NOME

limite
   ↕
CLIENTE-LIMITE

Passo 6 — Configure segurança

Pergunte:

Quem chama?
Como autentica?
Qual identidade chega ao z/OS?
Qual operação pode executar?
Qual recurso SAF protege?

Passo 7 — Teste

Não teste somente:

HTTP 200

Teste também:

dados inválidos
cliente inexistente
timeout
indisponibilidade CICS
falha Db2
credencial inválida
usuário sem autorização
campos limites
concorrência
volume

Passo 8 — Observe

Descubra antes da produção:

latência
throughput
CPU
zIIP
erros
timeouts
dependências

Passo 9 — Documente

OpenAPI não deveria ser decoração.

É parte do contrato entre equipes.

Passo 10 — Só então coloque Jack Bauer de plantão

Preferencialmente não coloque.

Se precisarmos dele, alguma coisa já deu muito errado.


⏱️ 23:00 — O verdadeiro significado de modernização

Agora chegamos à parte que considero mais importante.

Existe uma narrativa confortável:

VELHO = RUIM
NOVO = BOM

Computação real não funciona assim.

Um programa COBOL criado em 1992 pode estar executando uma regra crítica perfeitamente.

Uma aplicação criada há seis meses em Kubernetes pode ser uma catástrofe arquitetural.

Idade não é qualidade.

Tecnologia nova não é automaticamente modernização.

A pergunta deveria ser:

Que problema de negócio estamos tentando resolver?

Se o problema for:

“Precisamos disponibilizar capacidades do mainframe para novos canais.”

Talvez a resposta seja integração.

Não reescrita.


⏱️ 23:42 — O castelo Bellacosa

Imagine o mainframe como um castelo gigantesco.

Dentro dele vivem:

COBOL
CICS
IMS
Db2
RACF
JES2

Durante décadas quem quisesse entrar precisava conhecer os costumes locais:

3270
TSO
ISPF
JCL
copybook
COMMAREA
EBCDIC

Então construímos uma recepção moderna.

Na porta está escrito:

HTTPS
REST
JSON
OpenAPI

O visitante chega.

— Quero consultar a conta 123.

Ele envia:

GET /accounts/123

A recepção entende.

Traduz.

Entra no castelo.

O velho COBOL recebe sua estrutura.

Executa.

Consulta Db2.

Devolve os dados.

A recepção traduz novamente.

O visitante recebe:

{
   "account": 123,
   "balance": 8542.71
}

E vai embora.

Ele nunca soube que CICS existia.

E o CICS nunca precisou aprender React.

Isso é desacoplamento.


⏱️ 23:50 — A curiosidade que muda tudo

Perceba uma consequência filosófica interessante.

Uma aplicação pode ter:

30 anos de idade

e possuir uma interface criada ontem.

Portanto:

A idade da implementação não determina a idade da interface.

Essa frase merece ficar colada perto do monitor.

Podemos ter:

React
   │
REST
   │
API Gateway
   │
z/OS Connect
   │
CICS
   │
COBOL
   │
Db2

Qual é a idade desse sistema?

2026?

2015?

2002?

1989?

A resposta correta talvez seja:

todas elas.

Sistemas empresariais são cidades.

Não são casas.

Uma cidade possui prédios de 1890, metrô de 1970, fibra óptica de 2025 e alguém pagando café pelo celular dentro de um edifício construído quando telefone ainda tinha fio.

Ninguém diz:

“Precisamos demolir Lisboa porque algumas construções são antigas.”

Integramos.

Restauramos.

Substituímos onde necessário.

Preservamos onde faz sentido.


⏱️ 23:55 — Cinco dicas do velho COBOLzeiro

Se você está começando em COBOL e z/OS Connect, guarde estas ideias.

1. Aprenda HTTP e REST.

Você não precisa virar desenvolvedor frontend, mas precisa entender:

GET
POST
PUT
DELETE
headers
status codes
JSON
TLS

2. Aprenda OpenAPI.

O contrato é parte central desse novo mundo.

3. Continue estudando COBOL profundamente.

API nenhuma elimina a necessidade de entender aquilo que existe atrás dela.

4. Aprenda segurança.

Especialmente:

SAF
RACF
TLS
JWT
identidade
autenticação
autorização
least privilege

5. Aprenda observabilidade.

Porque depois do primeiro:

HTTP 200 OK

virá inevitavelmente:

“Por que demorou 1,7 segundo?”

E alguém precisará descobrir.


⏱️ 23:58 — O último plot twist

Jack Bauer finalmente encontra o responsável pelo incidente.

Não era o COBOL.

Não era o CICS.

Não era o Db2.

Não era RACF.

Era uma aplicação distribuída fazendo 47 chamadas redundantes para a mesma API para montar uma única tela.

O sysprog olha para Jack.

Jack olha para o sysprog.

O sysprog pergunta:

— Quer café?

— Quanto tempo temos?

00:01:42

— Dá.


⏱️ 23:59 — O relógio chega ao fim

Agora podemos resumir toda nossa arquitetura:

                     IBM z/OS CONNECT
                            │
             ┌──────────────┴──────────────┐
             │                             │
             ▼                             ▼

        API PROVIDER                  API REQUESTER

      mundo → z/OS                   z/OS → mundo

       REST/JSON                         COBOL
           │                               │
           ▼                               ▼
     z/OS Connect                    z/OS Connect
           │                               │
           ▼                               ▼
   CICS / IMS / Db2                  REST APIs
           │                               │
           ▼                               ▼
         COBOL                       Cloud / SaaS

Ao redor disso existem:

OpenAPI
mapping
security
SAF
RACF
TLS
JWT
OpenTelemetry
SMF
zIIP
containers
OpenShift
API Management
DevOps

Mas existe uma ideia ainda maior envolvendo tudo isso:

MODERNIZAÇÃO
      │
      ▼
não significa obrigatoriamente
      │
      ▼
REESCRITA

Modernização pode significar:

PRESERVAR
    │
    ▼
CAPACIDADES DE NEGÓCIO
    │
    ▼
DESACOPLAR
    │
    ▼
EXPOR POR CONTRATOS MODERNOS
    │
    ▼
INTEGRAR
    │
    ▼
EVOLUIR

☕ Epílogo — 00:00:00

O relógio finalmente chega a zero.

A API está funcionando.

O aplicativo mobile consulta o cliente.

O request entra como REST.

z/OS Connect recebe JSON.

A estrutura chega ao CICS.

O programa COBOL executa.

Db2 responde.

A informação volta.

O usuário vê seu saldo no smartphone.

Ele toca na tela e reclama:

— Nossa, tecnologia moderna é incrível.

No datacenter, silenciosamente, um programa COBOL escrito quando Windows 3.1 era novidade acabou de fazer o trabalho pesado.

Ele não recebeu aplausos.

Não apareceu no aplicativo.

Ninguém colocou seu nome na keynote.

Ele simplesmente executou outra transação.

Como fez milhões de vezes.

Jack Bauer fecha o notebook.

O operador olha para a console.

CICS STATUS: ACTIVE

Tudo normal.

Então o velho COBOLzeiro toma o último gole de café e deixa uma anotação para o turno seguinte:

Não confundam modernização com demolição. Às vezes o sistema não precisa de um coração novo. Precisa apenas de uma porta nova.

Na porta está escrito:

REST
JSON
OpenAPI

Atrás dela continua existindo:

PROCEDURE DIVISION.

    PERFORM PROCESSAR-NEGOCIO.

    GOBACK.

00:00:01

O telefone toca novamente.

— Temos outro problema.

— Qual?

— Agora querem colocar IA acessando a API.

O COBOLzeiro olha para Jack Bauer.

Jack Bauer olha para o relógio.

O relógio começa novamente:

24:00:00
23:59:59
23:59:58...

E em algum lugar muito distante do CPD alguém abre um PowerPoint chamado:

AI MAINFRAME MODERNIZATION
FINAL_v7_REAL_FINAL_AGORA_VAI.pptx

O operador suspira.

— Passa o café.

Easter egg final: se você trabalha em TI há tempo suficiente, sabe que o arquivo FINAL_v7_REAL_FINAL_AGORA_VAI jamais é a versão final.

E talvez essa seja a única constante mais confiável que o próprio mainframe.

☕

quarta-feira, 8 de setembro de 2021

📚 EINA TULLE E O GRIMÓRIO QUE ENSINOU O COBOL A FALAR REST

  

Bellacosa Mainframe apresenta o Swagger

☕ Um Café no Bellacosa Mainframe

📚 EINA TULLE E O GRIMÓRIO QUE ENSINOU O COBOL A FALAR REST

Swagger, OpenAPI, REST, HTTP, JSON, YAML, APIs, contratos, Swagger UI, autenticação, OAuth, JWT, RACF, CICS, IMS, Db2, VSAM, z/OS Connect, CI/CD, observabilidade — e o dia em que um programador COBOL descobriu que 200 OK não significava que a aventura havia terminado.

Sob a tutela de Eina Tulle, de Is It Wrong to Try to Pick Up Girls in a Dungeon?



🎬 PRÓLOGO — BEM-VINDO À GUILDA, AVENTUREIRO

Imagine um jovem programador COBOL chegando para seu primeiro dia em uma grande empresa.

Ele conhece algumas coisas:

IDENTIFICATION DIVISION.
PROGRAM-ID. CONSULTA.

DATA DIVISION.
WORKING-STORAGE SECTION.

01 WS-CLIENTE.
   05 WS-ID       PIC 9(09).
   05 WS-NOME     PIC X(40).

JCL ele está começando a entender.

Já ouviu falar de CICS.

Db2 ainda parece uma dungeon particularmente perigosa.

E então alguém aparece e diz:

— Precisamos criar uma API REST usando OpenAPI.

Nosso aventureiro olha para a tela como Bell Cranel provavelmente olharia para uma criatura vários níveis acima do seu.

API? REST? Swagger? OpenAPI? JSON?

É nesse momento que Eina Tulle empurra seus óculos, abre uma enorme pilha de documentos sobre a mesa da Guilda e responde:

— Antes de entrar na Dungeon, você precisa conhecer o mapa.

E talvez essa seja a melhor definição inicial de OpenAPI para um programador COBOL.

OpenAPI é parte do mapa.

Não é o monstro.

Não é a espada.

Não é o aventureiro.

É uma descrição formal de como encontrar e utilizar aquilo que existe do outro lado da porta.

E essa porta pode terminar justamente em um programa COBOL.



📜 CAPÍTULO 1 — QUANDO NASCEU O SWAGGER?

Nossa história começa muito depois do nascimento do COBOL.

COBOL surgiu em 1959.

CICS apareceu no final da década de 1960.

Db2 chegou comercialmente na década de 1980.

Swagger é praticamente uma criança perto deles.

A especificação Swagger foi criada na Wordnik em 2010 e publicada como projeto open source no ano seguinte. Em 2015, os direitos do projeto foram adquiridos pela SmartBear; naquele mesmo ano, a especificação foi doada para a recém-formada OpenAPI Initiative, sob a Linux Foundation. O Swagger 2.0 tornou-se a base do que passou a ser chamado de OpenAPI Specification. (OpenAPI Initiative)

Portanto:

1959       COBOL
  │
1969       CICS
  │
1980s      Db2
  │
2010       Swagger nasce
  │
2011       projeto/spec é publicado como open source
  │
2015       OpenAPI Initiative
  │
2017       OpenAPI 3.0
  │
2025       OpenAPI 3.2

Em setembro de 2025 foi publicada a especificação OpenAPI 3.2.0. (OpenAPI Initiative Publications)

Curiosamente, enquanto escrevemos em 2026, a página oficial de versões já lista também a 3.2.1. (OpenAPI Initiative Publications)

Mas aqui existe uma regra importantíssima para quem trabalha com mainframe:

A versão mais recente de um padrão não significa automaticamente a versão suportada por cada produto da sua arquitetura.

O IBM z/OS Connect, por exemplo, documenta seus próprios níveis suportados de OpenAPI. Portanto, consulte a matriz do produto antes de simplesmente colocar a versão mais nova no projeto.

Eina escreveria isso no topo da ficha do aventureiro:

Conheça a Dungeon antes de comprar a espada.



🧩 CAPÍTULO 2 — SWAGGER NÃO É OPENAPI

Esta é provavelmente a confusão mais comum.

Durante muito tempo Swagger era tanto o nome da especificação quanto do ecossistema.

Depois da criação da OpenAPI Initiative, houve uma separação conceitual.

Hoje podemos pensar:

OPENAPI
     ↓
ESPECIFICAÇÃO / CONTRATO

SWAGGER
     ↓
FERRAMENTAS / ECOSSISTEMA

A OpenAPI Specification é uma descrição padronizada e independente de linguagem para APIs HTTP. Ela permite que pessoas e programas descubram as capacidades de um serviço sem precisar examinar seu código-fonte. (OpenAPI Initiative Publications)

Já no universo Swagger encontramos ferramentas para trabalhar com esse contrato.

Por exemplo:

Swagger UI
Swagger Editor
Swagger Codegen

Então grave:

OpenAPI descreve. Swagger ajuda você a trabalhar com essa descrição.

Não diga simplesmente:

“Swagger é uma API.”

Não é.



📖 CAPÍTULO 3 — OPENAPI É O COPYBOOK DA FRONTEIRA?

Eina provavelmente faria uma analogia para nosso aprendiz COBOL.

Considere:

01 CLIENTE-REQUEST.
   05 CLIENTE-ID       PIC 9(09).

01 CLIENTE-RESPONSE.
   05 CLIENTE-NOME     PIC X(40).
   05 CLIENTE-STATUS   PIC X(01).
   05 CLIENTE-LIMITE   PIC S9(9)V99 COMP-3.

Um programador COBOL imediatamente reconhece que existe uma estrutura.

Agora observe uma representação externa:

Cliente:
  type: object
  properties:
    id:
      type: integer
    nome:
      type: string
    status:
      type: string
    limite:
      type: number

A semelhança conceitual ajuda.

Mas cuidado.

OpenAPI não é literalmente um COPYBOOK moderno.

OpenAPI consegue descrever muito mais sobre a interface HTTP:

URL
paths
operações
parâmetros
headers
request
response
schemas
autenticação
status codes

Podemos dizer didaticamente:

COPYBOOK
   ↓
estrutura utilizada pelo programa

OPENAPI
   ↓
contrato da interface HTTP

O COPYBOOK pode dizer como o COBOL enxerga determinado dado.

OpenAPI pode dizer como o mundo exterior conversa com o serviço.


🌐 CAPÍTULO 4 — A PORTA DA DUNGEON CHAMA-SE ENDPOINT

Suponha:

GET /api/clientes/101?page=2

Temos diferentes componentes:

GET                 HTTP METHOD

/api/clientes       PATH

101                 PATH PARAMETER

page=2              QUERY PARAMETER

O path parameter normalmente participa da identificação do recurso.

Exemplo:

/clientes/101
/clientes/102
/clientes/103

Já query parameters frequentemente aparecem em filtros, paginação, ordenação etc.:

/clientes?page=2

/clientes?cidade=Itatiba

/clientes?status=ativo&sort=nome

Para quem veio do COBOL, não há magia nisso.

Estamos simplesmente recebendo dados através de outra interface.


🏰 CAPÍTULO 5 — MAS COMO ISSO CHEGA AO MAINFRAME?

Agora entramos na parte divertida.

Imagine:

MOBILE
   │
   │ HTTPS / JSON
   ▼
API GATEWAY
   │
   ▼
z/OS CONNECT
   │
   ▼
CICS
   │
   ▼
COBOL
   │
   ├────────► Db2
   │
   └────────► VSAM

O programa COBOL não precisa transformar-se magicamente em JavaScript.

O IBM z/OS Connect pode atuar como uma camada entre APIs REST e recursos z/OS. A documentação da IBM descreve API providers capazes de transformar requisições REST em chamadas aos subsistemas z/OS e converter dados entre JSON e estruturas nativas consumíveis por COBOL, PL/I e C. (IBM)

Isso é extraordinariamente importante.

Externamente alguém manda:

{
  "clienteId": 101
}

Internamente podemos terminar com algo semelhante a:

01 CLIENTE-REQUEST.
   05 CLIENTE-ID PIC 9(09).

A interface moderna não precisa destruir o legado.

Ela pode encapsulá-lo.


🧙 CAPÍTULO 6 — O GRIMÓRIO OPENAPI

Vamos imaginar uma API:

GET /clientes/{id}

Podemos ter uma descrição OpenAPI simplificada:

openapi: 3.0.3

info:
  title: Cliente API
  version: 1.0.0

paths:
  /clientes/{id}:
    get:
      summary: Consulta cliente
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: integer
      responses:
        '200':
          description: Cliente encontrado
        '404':
          description: Cliente não encontrado

Eina apontaria para isso e perguntaria:

— Onde está o COBOL?

Não está.

E esse é justamente o ponto.

O consumidor não precisa saber se atrás da API temos:

COBOL
Java
Python
CICS
IMS
Db2
VSAM
um microsserviço
ou três kobolds digitando cartões perfurados.

Ele conhece o contrato.

Isso é desacoplamento.


🖥️ CAPÍTULO 7 — SWAGGER UI É O QUADRO DE MISSÕES DA GUILDA

Agora pegamos aquele contrato e apresentamos através de uma interface.

Entra o Swagger UI.

O desenvolvedor consegue explorar coisas como:

GET /clientes/{id}

POST /clientes

PUT /clientes/{id}

DELETE /clientes/{id}

Ele pode encontrar o endpoint, observar parâmetros, analisar schemas e, quando habilitado, executar chamadas diretamente.

O fluxo apresentado nas imagens é muito didático:

OPEN SWAGGER UI
       ↓
FIND ENDPOINT
       ↓
TRY IT OUT
       ↓
ENTER PARAMETERS
       ↓
EXECUTE
       ↓
INSPECT RESPONSE
       ↓
VALIDATE

Excelente para exploração.

Mas existe uma armadilha.

Swagger UI não substitui uma estratégia completa de QA.


💚 CAPÍTULO 8 — O TERRÍVEL MONSTRO VERDE: 200 OK

Nosso aventureiro executa:

GET /clientes/101

Swagger fica feliz:

200 OK

Ele comemora.

Eina bate o livro na mesa.

— Ainda não.

Porque 200 OK diz algo sobre o resultado da requisição HTTP.

Não prova automaticamente que a regra de negócio está correta.

Imagine:

{
  "cliente": 101,
  "saldo": 1000000.00
}

O saldo real era:

1000.00

Tecnicamente:

HTTP       OK
JSON       OK
SCHEMA     OK
NEGÓCIO    ERRADO

Isso deveria soar familiar para qualquer mainframer.

É o equivalente a:

MAXCC=0000

e descobrir depois que o arquivo de saída continha valores incorretos.

RC=0 não é sinônimo de negócio correto.

HTTP 200 também não.


🧪 CAPÍTULO 9 — O QA PRECISA DESCER MAIS ANDARES

Teste pelo menos:

status HTTP
response body
headers
campos obrigatórios
tipos
schema
valores-limite
dados inválidos
autenticação
autorização
timeout
concorrência
idempotência
rollback
indisponibilidade do backend
performance

Suponha:

POST /pagamentos

Cliente envia:

{
   "conta": "12345",
   "valor": 100
}

O backend processa.

Mas ocorre timeout antes de o cliente receber a resposta.

Ele tenta novamente.

Se não houver desenho adequado:

REQUEST 1 → DEBITA R$100

TIMEOUT

REQUEST 2 → DEBITA R$100

Swagger pode estar perfeitamente configurado.

OpenAPI pode estar impecável.

E você acabou de cobrar o cliente duas vezes.

Bem-vindo ao andar onde moram os monstros de verdade.


⚛️ CAPÍTULO 10 — REST NÃO MATOU ACID

Por trás de:

POST /transferencias

pode existir:

UPDATE CONTA A
      ↓
UPDATE CONTA B
      ↓
COMMIT

Se algo falhar:

ROLLBACK

Portanto:

REST
 ↓
JSON
 ↓
z/OS Connect
 ↓
CICS
 ↓
COBOL
 ↓
Db2
 ↓
LOCKS
 ↓
LOG
 ↓
COMMIT / ROLLBACK

A modernização da interface não aboliu cinquenta anos de engenharia transacional.

Isso é uma das coisas mais importantes para um iniciante entender.

API é a porta da Dungeon.

Não é a Dungeon inteira.


🔐 CAPÍTULO 11 — “QUEM É VOCÊ?” E “O QUE VOCÊ PODE FAZER?”

Outra imagem traz uma distinção excelente:

AUTHENTICATION
Quem é você?

AUTHORIZATION
O que você pode fazer?

Podemos encontrar mecanismos como:

Basic Authentication
API Key
Bearer Token
JWT
OAuth 2.0

Agora transporte isso para IBM Z:

APP
 │
 ▼
OAuth / OIDC
 │
 ▼
TOKEN
 │
 ▼
API GATEWAY
 │
 ▼
z/OS Connect
 │
 ▼
SAF / RACF
 │
 ▼
CICS
 │
 ▼
COBOL

Surge uma pergunta arquitetural fundamental:

Qual identidade chega ao recurso protegido?

Porque autenticar alguém na primeira porta não significa automaticamente permitir qualquer operação atrás dela.

É justamente daí que nasce a distinção didática entre:

401
problema de autenticação/credenciais

403
identidade reconhecida,
mas acesso não permitido

A própria oferta atual do z/OS Connect destaca autorização granular por operação para serviços de negócio. (IBM)


🚨 CAPÍTULO 12 — NÃO MANDE SQLCODE -911 PARA O CLIENTE

Imagine:

EXEC SQL
   SELECT SALDO
     INTO :WS-SALDO
     FROM CONTA
    WHERE ID = :WS-ID
END-EXEC

Alguma condição ocorre no Db2.

Você não deveria transformar automaticamente sua implementação interna em contrato público:

{
   "sqlcode": -911
}

Muito menos:

{
   "abend": "ASRA",
   "program": "XPTO1234"
}

Você está vazando detalhes da implementação.

O ideal é existir um mapeamento coerente entre erro interno e contrato externo.

Por exemplo:

Db2: registro inexistente
        ↓
regra da aplicação
        ↓
HTTP 404

Resposta:

{
   "code": "ACCOUNT_NOT_FOUND",
   "message": "Conta não encontrada"
}

Internamente você preserva informações suficientes para diagnóstico:

timestamp
transaction ID
correlation ID
program
CICS transaction
SQLCODE
trace
logs
SMF

O usuário recebe aquilo que precisa.

Operações recebe aquilo que precisa.

Segurança agradece.


🏗️ CAPÍTULO 13 — API-FIRST: DESENHE A MISSÃO ANTES DE ENTRAR NA DUNGEON

Aqui encontramos uma transformação particularmente interessante para equipes mainframe.

Tradicionalmente poderíamos imaginar:

COBOL
 ↓
interface
 ↓
documentação

API-first inverte parte desse raciocínio.

Primeiro definimos:

CONTRATO
 ↓
IMPLEMENTAÇÃO

Imagine:

POST /transferencias

Request:

{
   "origem": "123456",
   "destino": "987654",
   "valor": 250.00
}

Response:

{
   "transacao": "TRX829173",
   "status": "EFETIVADA"
}

Agora várias equipes podem trabalhar sobre o mesmo contrato:

           OpenAPI
              │
    ┌─────────┼──────────┐
    │         │          │
 Mobile      QA       Mainframe
    │         │          │
    ▼         ▼          ▼
 cliente    testes    implementação

E isso não é apenas teoria aplicada ao IBM Z. A IBM documenta desenvolvimento API-first no z/OS Connect usando documentos OpenAPI e ferramentas que geram artefatos de projeto e estruturas de linguagem necessárias à implementação, inclusive para aplicações CICS COBOL ou PL/I. (IBM)

A funcionalidade API-first foi introduzida no z/OS Connect 3.0.69. (IBM)

Para o COBOLzeiro, isso é enorme.

O contrato deixa de ser aquele PDF que alguém atualiza seis meses depois.

Ele passa a participar do processo de engenharia.


🔄 CAPÍTULO 14 — DO SWAGGER AO CI/CD

Agora podemos expandir o workflow apresentado nas imagens:

BUSINESS REQUIREMENT
          ↓
     API DESIGN
          ↓
   OPENAPI CONTRACT
          ↓
    CONTRACT REVIEW
          ↓
        MOCK
          ↓
   BACKEND DEVELOPMENT
          ↓
     z/OS CONNECT
          ↓
     CICS / IMS
          ↓
        COBOL
          ↓
    Db2 / VSAM
          ↓
 FUNCTIONAL TEST
          ↓
 NEGATIVE TEST
          ↓
 CONTRACT TEST
          ↓
 SECURITY TEST
          ↓
 PERFORMANCE TEST
          ↓
       CI/CD
          ↓
      DEPLOY
          ↓
    PRODUCTION

E isso destrói outro mito:

“DevOps não serve para mainframe.”

Serve.

O que muda são ferramentas, processos, controles e características da plataforma.


🔭 CAPÍTULO 15 — A AVENTURA NÃO TERMINA NO DEPLOY

Produção não é:

DEPLOY
  ↓
FIM

Produção é:

DEPLOY
  ↓
OBSERVAR
  ↓
MEDIR
  ↓
INVESTIGAR
  ↓
CORRIGIR

Por isso nosso desenho final começa a ganhar novas peças:

API
 ↓
z/OS Connect
 ↓
CICS
 ↓
COBOL
 ↓
Db2

        ↘ TELEMETRIA
             ↓
        OBSERVABILIDADE

O z/OS Connect também oferece integração com mecanismos tradicionais do z/OS, incluindo rastreamento via SMF, e a linha atual oferece suporte a OpenTelemetry para observabilidade. (IBM)

Isso cria uma combinação particularmente poderosa:

OpenAPI
   =
O QUE FOI CONTRATADO

telemetria
   =
O QUE ESTÁ ACONTECENDO

Quando ambos se encontram, você deixa de simplesmente publicar APIs e começa a operá-las profissionalmente.


🗺️ CAPÍTULO 16 — O MAPA COMPLETO DA DUNGEON

Depois da aula de Eina, nosso jovem COBOLzeiro finalmente consegue desenhar:

                    CONSUMIDORES
                         │
               Web / Mobile / Cloud
                         │
                         ▼
                    HTTPS / REST
                         │
                         ▼
                 ┌───────────────┐
                 │ API CONTRACT  │
                 │    OpenAPI    │
                 └───────┬───────┘
                         │
                 Swagger UI
                         │
                         ▼
                    API GATEWAY
                         │
                   OAuth / JWT
                         │
                         ▼
                  z/OS CONNECT
                         │
           ┌─────────────┼─────────────┐
           │             │             │
           ▼             ▼             ▼
         CICS           IMS           Db2
           │             │
           ▼             ▼
         COBOL         COBOL
           │             │
           └──────┬──────┘
                  │
          ┌───────┼────────┐
          ▼       ▼        ▼
         Db2     VSAM     IMS DB
          │
          ▼
    COMMIT / ROLLBACK
          │
          ▼
    SMF / TELEMETRIA
          │
          ▼
    OBSERVABILIDADE

Agora Swagger deixou de parecer uma tecnologia alienígena.

É apenas mais uma peça da arquitetura.


💡 CAPÍTULO 17 — DEZ CONSELHOS DE EINA PARA O COBOLZEIRO

Antes de liberar nosso aventureiro para a Dungeon, Eina deixaria algumas regras no quadro da Guilda:

  1. Não confunda Swagger com OpenAPI. Um é o ecossistema de ferramentas; o outro é a especificação.

  2. Não trate Swagger UI como ferramenta completa de QA. Explorar endpoints é apenas o começo.

  3. Nunca comemore apenas porque recebeu 200 OK. Valide o negócio.

  4. Não exponha detalhes internos desnecessários. SQLCODE, ABEND e nomes internos não precisam virar sua interface pública.

  5. Teste erros deliberadamente. Token inválido, campo ausente, valor absurdo, backend indisponível e timeout também fazem parte da API.

  6. Pense em idempotência. Principalmente pagamentos e operações financeiras.

  7. Separe autenticação de autorização.

  8. Versione e governe o contrato. Alterar uma API usada por dezenas de consumidores é muito diferente de alterar uma rotina interna isolada.

  9. Use observabilidade desde o desenho. Não espere o primeiro incidente para perguntar como correlacionar uma requisição HTTP com o processamento z/OS.

  10. Não tente transformar COBOL em REST. Crie uma arquitetura em que REST e COBOL façam aquilo que cada tecnologia sabe fazer bem.


🥚 EASTER EGG — A REQUISIÇÃO DAS 03:17

Algumas semanas depois, produção recebe:

03:17:00.317

Uma chamada:

POST /transferencias

Swagger dizia:

201 Created

O dashboard estava verde.

CPU normal.

z/OS saudável.

CICS ativo.

Db2 ativo.

Nenhum grande alarme.

Mesmo assim, o cliente reclamava:

“Minha transferência apareceu duas vezes.”

Nosso jovem programador quase responde:

— Mas recebemos 201!

Ele para.

Lembra da aula.

Procura o correlation ID.

Segue a requisição.

API Gateway.

z/OS Connect.

CICS.

COBOL.

Db2.

COMMIT.

Depois encontra uma segunda requisição, enviada após um timeout do consumidor.

Mesmo payload.

Mesmo valor.

Outro processamento.

E então finalmente compreende a verdadeira lição daquela primeira aventura:

Disponibilidade não garante correção. HTTP correto não garante negócio correto. E observabilidade sem contexto é apenas uma coleção muito cara de luzes verdes.

No dia seguinte ele volta à Guilda.

Eina pergunta:

— Então, aprendeu Swagger?

Ele responde:

— Não.

Ela ergue uma sobrancelha.

— Aprendi sistemas.

Agora ela sorri.


☕ EPÍLOGO — O MAINFRAME NÃO PRECISA APRENDER A SER JOVEM

Existe uma narrativa recorrente na tecnologia:

velho
versus
novo

Mainframe versus cloud.

COBOL versus Java.

CICS versus microsserviços.

Batch versus APIs.

Essa oposição frequentemente é simplista.

Uma arquitetura moderna pode perfeitamente conter:

OpenAPI
Swagger
REST
JSON
OAuth
API Gateway
z/OS Connect
RACF
CICS
COBOL
Db2
VSAM
SMF
OpenTelemetry
CI/CD

Não existe contradição nisso.

Existe integração.

A aplicação mobile não precisa conhecer PIC, COMP-3, COMMAREA ou SQLCODE.

O programa COBOL não precisa conhecer detalhes da interface gráfica do smartphone.

Entre os dois existe um contrato.

OpenAPI.

E ferramentas como Swagger ajudam pessoas e máquinas a compreender e trabalhar com esse contrato.

O IBM z/OS Connect completa uma parte importantíssima dessa ponte, expondo recursos z/OS através de APIs e realizando transformações entre o universo REST/JSON e estruturas utilizadas pelas aplicações z/OS. (IBM)

Talvez seja essa a maior lição sob a tutela de Eina Tulle.

Ela jamais mandaria um aventureiro para a Dungeon simplesmente porque ele tinha uma espada nova.

Primeiro ensinaria:

o mapa
os níveis
os monstros
as regras
as rotas
os riscos
e como voltar vivo.

Swagger UI é uma ferramenta.

OpenAPI é um contrato.

REST é um estilo arquitetural.

HTTP é um protocolo.

JSON é uma representação de dados.

OAuth pode participar da segurança.

z/OS Connect pode fazer a ponte.

CICS pode administrar a transação.

COBOL pode executar a regra de negócio.

Db2 pode preservar os dados.

RACF/SAF pode participar da proteção.

SMF e OpenTelemetry podem ajudar a contar o que aconteceu.

Nenhuma dessas peças, sozinha, é “a modernização”.

A arquitetura aparece quando sabemos como todas elas se relacionam.

E é justamente por isso que talvez a pergunta mais interessante não seja:

“Como substituir COBOL por APIs?”

Mas:

“Como fazer décadas de lógica de negócio confiável participarem de um mundo orientado a APIs sem destruir aquilo que já funciona?”

Quando nosso jovem aventureiro consegue responder isso, ele já não está apenas aprendendo Swagger.

Ele começou a compreender o verdadeiro mapa da Dungeon chamada Enterprise Computing.

E em algum lugar, às 03:17, Eina Tulle fecha o último manual da Guilda e escreve na ficha do aventureiro:

LEVEL UP: COBOL PROGRAMMER → API-AWARE MAINFRAMER.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...