☕ 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 z/OS Connect. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta z/OS Connect. 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.


segunda-feira, 6 de julho de 2026

IA Generativa Muito Além do ChatGPT - Parte II

Bellacosa Mainfram apresenta ia generativa

☕ Um Café no Bellacosa Mainframe

IA Generativa Muito Além do ChatGPT

O Que Todo Programador COBOL Padawan Precisa Saber Sobre RAG, MCP, watsonx, IBM Z, CICS, Db2, APIs e Como a Inteligência Artificial Está Transformando os Sistemas Mais Críticos do Mundo (Parte 2)

"A tecnologia muda. Os princípios permanecem. Empresas não sobrevivem porque adotam modismos, mas porque conseguem evoluir preservando aquilo que já funciona."


Quando a IA Encontra o Mundo Real

Na primeira parte deste artigo vimos que a Inteligência Artificial não veio substituir o Mainframe.

Na verdade, ela depende dele.

Agora vamos responder uma pergunta ainda mais importante:

Como isso acontece dentro de uma grande instituição financeira?

Esqueça por um momento os chatbots públicos.

Imagine um banco que processa:

  • 150 milhões de transações por dia;

  • milhares de PIX por segundo;

  • milhões de cartões;

  • investimentos;

  • empréstimos;

  • seguros;

  • câmbio;

  • previdência.

Todo esse universo continua sendo coordenado por aplicações executando no IBM Z.

A IA entra como uma camada de inteligência.

Não como substituição.


Caso 1 — Atendimento Inteligente

Imagine que um cliente escreve:

"Meu cartão foi recusado. O que aconteceu?"

Sem IA:

  • abertura de chamado;

  • consulta manual;

  • operador verifica sistemas;

  • resposta alguns minutos depois.

Com IA integrada ao Mainframe:

Cliente

↓

Assistente IA

↓

RAG

↓

API REST

↓

CICS

↓

Programa COBOL

↓

Db2

↓

Regras de Negócio

↓

Resposta Personalizada

Resposta:

"Sua compra foi recusada porque ultrapassou o limite diário de segurança definido para transações internacionais. Você pode aumentar esse limite diretamente pelo aplicativo."

Nenhuma informação foi inventada.

Tudo veio do sistema corporativo.


Caso 2 — Explicando Programas COBOL

Imagine um programa com 25.000 linhas.

O desenvolvedor recém-chegado pergunta:

"Como esse programa calcula juros?"

Sem IA:

Dias analisando código.

Com IA:

Programa COBOL

↓

Parser

↓

Embedding

↓

Base Vetorial

↓

LLM

↓

Resumo Técnico

Resposta:

O cálculo de juros ocorre nos parágrafos CALC-JUROS e APLICA-TAXA. A taxa depende do tipo de contrato, perfil do cliente e índice econômico armazenado na tabela FIN_RATE.

O profissional continua responsável pela validação.

Mas economiza horas.


Caso 3 — Documentação Automática

Uma das maiores dores em sistemas legados é documentação desatualizada.

Hoje podemos construir pipelines que façam:

Git

↓

Programa COBOL

↓

Parser

↓

IA

↓

Markdown

↓

Wiki

↓

Confluence

Resultado:

Toda alteração gera documentação automaticamente.


Caso 4 — Geração de Casos de Teste

Imagine este trecho COBOL:

IF SALDO < VALOR-SAQUE
    MOVE "N" TO AUTORIZADO
ELSE
    MOVE "S" TO AUTORIZADO
END-IF

Uma IA pode sugerir automaticamente:

Caso 1

Saldo = 500

Saque = 300

Resultado esperado:

AUTORIZADO = S

Caso 2

Saldo = 300

Saque = 500

Resultado esperado:

AUTORIZADO = N

Caso 3

Saldo = 500

Saque = 500

Resultado esperado:

AUTORIZADO = S

Isso acelera significativamente testes unitários.


Agentes de IA

O próximo passo da evolução são os agentes.

Enquanto um chatbot apenas responde perguntas, um agente executa tarefas.

Imagine:

"Abra um chamado porque houve aumento de ABEND S0C7."

O agente poderá:

  • consultar o SDSF;

  • analisar logs;

  • pesquisar incidentes semelhantes;

  • abrir ticket;

  • notificar equipes;

  • sugerir solução.

Tudo automaticamente.


Arquitetura de um Agente Mainframe

                    Usuário

                       │

                       ▼

               Agente Inteligente

                       │

          ┌────────────┼────────────┐

          ▼            ▼            ▼

      MCP Tool     RAG Engine   Prompt Engine

          │            │            │

          └────────────┼────────────┘

                       ▼

             IBM API Connect

                       │

          ┌────────────┼────────────┐

          ▼            ▼            ▼

      z/OS Connect    MQ      REST APIs

          │

          ▼

      CICS

          │

          ▼

      COBOL

          │

          ▼

     Db2 / VSAM / IMS

Observe que o agente não substitui aplicações.

Ele coordena.


Observabilidade Inteligente

Ferramentas como:

  • OpenTelemetry

  • Grafana

  • Prometheus

  • Instana

  • IBM Z APM Connect

produzem milhões de métricas.

Uma IA consegue resumir tudo.

Exemplo:

Ao invés de mostrar:

CPU = 83%

I/O = 65%

Storage = 72%

Buffer Pool = 94%

Response Time = 1,8s

A IA apresenta:

Detectamos degradação iniciada às 14h23 causada por aumento nas leituras aleatórias do Db2. Existe forte correlação com o deploy realizado às 14h18.

Isso muda completamente a produtividade.


Segurança com IA

Fraudes evoluem diariamente.

A IA ajuda identificando padrões.

Exemplo:

Cliente normalmente utiliza:

São Paulo

09:00 às 20:00

Compras abaixo de R$ 500.

De repente:

Compra de US$ 8.000

Outro continente

03:17 da manhã.

O modelo identifica anomalias antes mesmo da autorização.


IA Não Pode Alucinar

Esse é um ponto crítico.

Em sistemas financeiros:

Não existe "quase certo".

Imagine responder:

Seu saldo é R$ 15.000

quando na verdade são R$ 1.500.

Por isso arquiteturas corporativas utilizam:

  • RAG

  • MCP

  • APIs oficiais

  • Catálogo de Dados

  • Governança

  • Logs

  • Auditoria

Toda resposta precisa ser rastreável.


Engenharia de Prompt para Mainframe

Prompt ruim:

Explique esse programa.

Prompt profissional:

Você é um arquiteto IBM Z.

Analise este programa COBOL.

Explique:

• regras de negócio

• dependências

• tabelas Db2

• transações CICS

• arquivos VSAM

• riscos

• complexidade

• sugestões de testes

Não invente informações.
Indique apenas aquilo identificado no código.

A qualidade muda completamente.


DevOps + IA

Imagine um pipeline.

Git

↓

Pull Request

↓

SonarQube

↓

COBOL Check

↓

IA

↓

Resumo

↓

Code Review

↓

Deploy

Antes mesmo do revisor abrir o código, a IA já produziu:

  • resumo;

  • riscos;

  • impacto;

  • módulos afetados;

  • documentação.


O Papel do Desenvolvedor

Existe medo.

"IA vai substituir programadores."

A história mostra outra coisa.

Quando surgiram:

  • compiladores;

  • IDEs;

  • Git;

  • Java;

  • frameworks;

  • Cloud;

  • DevOps.

Disseram exatamente a mesma coisa.

O profissional mudou.

Não desapareceu.


O Novo Desenvolvedor Mainframe

Nos próximos anos veremos um perfil diferente.

Além de COBOL, ele entenderá:

✓ APIs

✓ JSON

✓ Python

✓ Engenharia de Prompt

✓ RAG

✓ MCP

✓ IA Generativa

✓ DevOps

✓ Observabilidade

✓ Segurança

✓ Arquitetura

Esse profissional será extremamente valorizado.


O Que Ainda Não Será Substituído

A IA pode escrever código.

Mas ela não conhece:

  • estratégia do banco;

  • legislação;

  • decisões executivas;

  • riscos jurídicos;

  • compliance;

  • auditoria;

  • cultura organizacional.

Quem conhece isso?

As pessoas.


Um Possível Futuro

Imagine daqui a alguns anos.

Você chega ao trabalho.

Pergunta:

"Existe algum problema crítico hoje?"

Resposta:

Foram detectadas três degradações.

Corrigi automaticamente duas.

A terceira envolve alteração de regra de negócio.

Já preparei documentação.

Seguem possíveis soluções.

Isso não é ficção.

É exatamente para onde estamos caminhando.


Arquitetura Completa de IA Corporativa para IBM Z

                    ┌──────────────────────────────────────────────┐
                    │              Usuário Final                   │
                    └──────────────────┬───────────────────────────┘
                                       │
                                       ▼
                        Web │ Mobile │ Chatbot │ Teams │ Slack
                                       │
                                       ▼
                  ┌────────────────────────────────────────┐
                  │        Gateway de APIs / WAF           │
                  └────────────────┬───────────────────────┘
                                   │
                    ┌──────────────┼──────────────┐
                    ▼              ▼              ▼
               Autenticação     Auditoria     Rate Limit
                                   │
                                   ▼
                      ┌────────────────────────────┐
                      │      Modelo Generativo     │
                      │        (watsonx.ai)        │
                      └────────────┬───────────────┘
                                   │
                  ┌────────────────┼────────────────┐
                  ▼                ▼                ▼
              Prompt           RAG Engine       MCP Server
             Orchestrator        Vetores        Ferramentas
                  │                │                │
                  └────────────────┼────────────────┘
                                   ▼
                    ┌──────────────────────────────────┐
                    │ APIs Corporativas / z/OS Connect │
                    └────────────────┬─────────────────┘
                                     │
              ┌──────────────────────┼──────────────────────┐
              ▼                      ▼                      ▼
           CICS                 IBM MQ                Batch
              │                      │                      │
              └──────────────┬───────┴──────────────────────┘
                             ▼
                     Aplicações COBOL
                             │
        ┌────────────────────┼────────────────────┐
        ▼                    ▼                    ▼
      Db2                  VSAM                 IMS
                             │
                             ▼
                    Fonte Oficial da Verdade

Considerações Finais

Durante décadas, ouvimos previsões sobre o fim do Mainframe. Entretanto, a realidade mostrou algo diferente: os sistemas que sustentam bancos, seguradoras, governos e grandes empresas continuam evoluindo porque concentram o ativo mais valioso de qualquer organização — seus dados e suas regras de negócio.

A Inteligência Artificial Generativa amplia esse cenário ao adicionar novas capacidades de interpretação, automação e interação. Tecnologias como RAG, MCP, watsonx, APIs, z/OS Connect e modelos privados permitem que aplicações modernas dialoguem com décadas de conhecimento implementado em COBOL, CICS e Db2, sem abrir mão de segurança, governança ou desempenho.

Não estamos testemunhando a substituição do Mainframe, mas o surgimento de uma nova geração de arquiteturas corporativas em que IA e IBM Z trabalham lado a lado. Para os profissionais da área, isso representa uma oportunidade única: dominar tanto os fundamentos dos sistemas críticos quanto as novas ferramentas de Inteligência Artificial.

O futuro pertence aos profissionais capazes de conectar esses dois mundos. Afinal, a inovação mais duradoura não nasce da ruptura, mas da integração inteligente entre o legado que funciona e as tecnologias que apontam para o amanhã.


☕ Continua a conversa no Bellacosa Mainframe

https://eljefemidnightlunch.blogspot.com/2026/07/ia-generativa-muito-alem-do-chatgpt.html




quarta-feira, 1 de julho de 2026

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

 

Bellacosa Mainframe e o Java na Stack Mainframe

☕ Um Café no Bellacosa Mainframe

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

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

Você conhece COBOL.

Sabe fazer um PERFORM UNTIL.

Entende JCL.

Já escreveu programas para CICS.

Conhece Db2, VSAM e talvez IMS.

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

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

Você pensa:

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

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

Não.

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

O Java não veio substituir o COBOL.

Ele veio conversar com ele.

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

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


O maior mito sobre Java no Mainframe

O erro mais comum é procurar um curso chamado:

  • Java para Mainframe

  • Java para z/OS

  • Java para COBOL

antes mesmo de aprender Java.

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

Primeiro aprendemos a linguagem.

Depois aprendemos onde ela roda.

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

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

Essa frase resume toda a filosofia da plataforma Java.


Esqueça a ideia de "Java Mainframe"

Não existe uma linguagem chamada Java Mainframe.

Existe apenas Java.

O mesmo Java roda em:

  • Windows

  • Linux

  • macOS

  • LinuxONE

  • z/OS UNIX System Services (USS)

  • OpenShift

  • Cloud

A mágica acontece graças à JVM.


O que é a JVM?

JVM significa:

Java Virtual Machine

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

O processo funciona assim:

Código Java (.java)

        │

      javac

        │

Bytecode (.class)

        │

        JVM

        │

Sistema Operacional

No mundo IBM Z acontece exatamente a mesma coisa.

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

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

Isso significa que o mesmo programa Java pode executar em:

  • LinuxONE

  • USS

  • Open Liberty

  • CICS JVM Server

  • Batch Java

sem precisar ser reescrito.

É o famoso conceito:

Write Once, Run Anywhere.


O COBOL continua vivo?

Mais vivo do que nunca.

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

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

Por exemplo:

  • cálculo de juros

  • empréstimos

  • cartões

  • PIX

  • investimentos

  • seguros

  • previdência

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

Ele veio criar novas formas de utilizá-las.


O legado não é o problema

Existe uma frase muito repetida no Bellacosa Mainframe:

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

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

Ele funciona.

Foi testado milhões de vezes.

Então surge um aplicativo Android.

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

Ele apenas precisa conversar com esse programa.

É aí que entra a modernização.


Java como ponte entre o mundo moderno e o legado

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

Aplicativo Android

↓

REST API

↓

Java Spring Boot

↓

z/OS Connect

↓

CICS

↓

Programa COBOL

↓

Db2

Observe quem está no meio da conversa.

O Java.

Ele conecta o mundo digital ao legado corporativo.


O papel do z/OS Connect

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

Sua missão é simples.

Transformar programas COBOL em APIs REST.

Imagine um programa CICS chamado:

CONSULTA_CLIENTE

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

Com o z/OS Connect:

GET

/clientes/12345

vira automaticamente:

Programa COBOL

↓

COMMAREA

↓

Resposta JSON

Sem reescrever o COBOL.

Sem alterar décadas de negócio.

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


JSON substituiu a COMMAREA?

Não.

Cada um possui sua função.

Dentro do CICS continua existindo:

  • COMMAREA

  • Containers

  • Channels

Fora do Mainframe:

  • JSON

  • REST

  • OpenAPI

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


Java conversa naturalmente com o Db2

Outro ponto importante.

O Java utiliza JDBC.

Java

↓

JDBC

↓

Db2 for z/OS

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


LinuxONE: onde o Java brilha

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

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

Ele oferece:

  • alta disponibilidade

  • criptografia

  • escalabilidade

  • virtualização

  • containers

  • Kubernetes

  • OpenShift

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

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


Open Liberty

Outro componente importante é o Open Liberty.

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

Nele podemos executar:

  • APIs REST

  • aplicações corporativas

  • microsserviços

  • autenticação

  • integração

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


IBM MQ

Nem toda integração precisa ser REST.

Muitos bancos utilizam filas.

Java

↓

IBM MQ

↓

COBOL

As mensagens ficam armazenadas até serem processadas.

Isso aumenta confiabilidade e desacopla sistemas.


Ansible no mundo Mainframe

Durante muitos anos administrar Mainframe significava executar comandos manualmente.

Hoje isso mudou.

O Ansible automatiza tarefas como:

  • criação de ambientes

  • deploy

  • configuração

  • instalação

  • atualização

  • coleta de informações

  • execução de scripts

Imagine precisar atualizar cinquenta servidores.

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

Exemplo simplificado:

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

Tudo automaticamente.

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

  • z/OS

  • USS

  • CICS

  • RACF

  • datasets

  • JCL

  • operações administrativas

O DevOps chegou definitivamente ao Mainframe.


Cloud no mundo Mainframe

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

A realidade é outra.

Hoje predominam arquiteturas híbridas.

Um exemplo:

Cloud

↓

API Gateway

↓

Java

↓

z/OS Connect

↓

COBOL

Parte da aplicação roda na nuvem.

Parte continua no IBM Z.

Cada ambiente faz aquilo em que é melhor.


Inteligência Artificial no IBM Z

Outro tema que deixou de ser futuro.

Hoje encontramos IA aplicada em:

  • detecção de fraudes

  • análise de crédito

  • observabilidade

  • automação operacional

  • atendimento inteligente

  • copilotos de desenvolvimento

  • geração de código

  • documentação

  • análise de logs

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

O objetivo não é substituir o programador.

É aumentar sua produtividade.


O roteiro Bellacosa para aprender Java

Fase 1 — Pensar como programador Java

Aprenda:

  • variáveis

  • classes

  • objetos

  • métodos

  • encapsulamento

  • herança

  • interfaces

  • exceções

  • Collections

  • Generics

Ainda não pense em Mainframe.


Fase 2 — Ferramentas modernas

Aprenda:

  • Git

  • Maven

  • Gradle

  • JUnit

  • Mockito

  • VS Code

  • IntelliJ IDEA


Fase 3 — Desenvolvimento Web

Estude:

  • HTTP

  • REST

  • JSON

  • XML

  • Servlets

  • APIs


Fase 4 — Spring Boot

Aprenda a criar:

  • microsserviços

  • APIs REST

  • autenticação

  • integração com bancos de dados


Fase 5 — Java Enterprise

Conheça:

  • Open Liberty

  • Jakarta EE

  • MicroProfile


Fase 6 — Java na Stack Mainframe

Agora sim, entre no universo IBM Z:

  • JVM no z/OS

  • USS

  • LinuxONE

  • JDBC para Db2

  • IBM MQ

  • CICS JVM Server

  • JCICS

  • JZOS

  • z/OS Connect EE

  • RACF

  • Open Liberty

  • Batch Java

  • OpenShift


O maior diferencial do programador COBOL

Muitos desenvolvedores Java sabem criar APIs.

Poucos entendem regras de negócio bancárias.

Você já conhece:

  • consistência transacional

  • processamento em lote

  • auditoria

  • integridade

  • alta disponibilidade

  • segurança

Esses conhecimentos não desaparecem.

Eles tornam você um profissional muito mais completo.


Recursos para continuar estudando

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

Java no CICS

Artigos técnicos

Open Liberty

IBM Semeru Runtime

IBM z/OS Connect

LinuxONE

Automação

IA para IBM Z


Um café antes de partir...

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

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

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

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

segunda-feira, 4 de maio de 2026

No-Code : O Que Todo Programador COBOL Precisa Saber Sobre a Revolução do Desenvolvimento Sem Programação

 

Bellacosa Mainframe e o no-code na stack mainframe

☕ Um Café no Bellacosa Mainframe

No-Code

O Que Todo Programador COBOL Precisa Saber Sobre a Revolução do Desenvolvimento Sem Programação

Você Não Está Sendo Substituído. Está Descobrindo Outra Forma de Construir Software.

"Toda década promete eliminar os programadores. Primeiro vieram os geradores de código. Depois os CASE Tools. Em seguida o RAD. Agora é o No-Code. Curiosamente, todas essas tecnologias continuam precisando de bons engenheiros de software."


Introdução

Quem trabalha com IBM Mainframe já ouviu inúmeras previsões durante a carreira.

"COBOL vai acabar."

"O Mainframe será substituído."

"Agora qualquer pessoa poderá criar sistemas."

Quase cinquenta anos depois dessas previsões, os maiores bancos do planeta continuam processando bilhões de transações em COBOL.

Agora surgiu uma nova promessa.

No-Code.

Segundo muitos anúncios de marketing, basta arrastar alguns blocos na tela e qualquer pessoa cria aplicações empresariais.

Será?

Como quase tudo na engenharia de software, a resposta é mais interessante do que parece.

Para um desenvolvedor COBOL, entender No-Code não significa abandonar décadas de conhecimento.

Significa compreender onde essa tecnologia realmente faz sentido.


O que é No-Code?

No-Code é uma abordagem de desenvolvimento onde aplicações são criadas utilizando componentes gráficos, configurações e regras visuais, praticamente sem escrever código tradicional.

Em vez de escrever:

IF SALDO > LIMITE
    MOVE "NEGADO" TO STATUS
END-IF

o desenvolvedor conecta dois blocos:

Saldo >
        \
         > Decisão
        /
Limite >

e define:

Sim → Negar operação

Não → Aprovar

A lógica continua existindo.

A diferença é apenas a forma de representá-la.


O princípio do No-Code

Todo software possui quatro elementos fundamentais:

  • Interface

  • Regras

  • Dados

  • Integrações

No-Code tenta transformar todos esses elementos em componentes reutilizáveis.

Em vez de programar:

Tela
↓

Código

↓

Banco

↓

API

o desenvolvedor monta:

Tela
↓

Blocos

↓

Fluxos

↓

Publicar

A origem do No-Code

Na realidade, No-Code não é novidade.

Ele apenas ganhou um novo nome.

Sua história começa muito antes da Internet.

Década de 1970

Mainframes já possuíam ferramentas declarativas.

CICS BMS

IMS MFS

ISPF Panels

Mapas de tela.

Você descrevia uma tela.

O sistema gerava a interface.

Isso já era uma forma de desenvolvimento declarativo.


Década de 1980

Surgiram os famosos CASE Tools.

Entre eles:

  • Texas Instruments IEF

  • AD/Cycle

  • COOL:Gen

  • Excelerator

  • CA Gen

Essas ferramentas prometiam:

"Desenhe o sistema."

"O software será gerado automaticamente."

Muito parecido com o discurso atual.


Década de 1990

Vieram:

  • Delphi

  • Visual Basic

  • PowerBuilder

  • Oracle Forms

Os componentes eram arrastados para formulários.

Pouco código.

Muito RAD (Rapid Application Development).


Década de 2000

Aplicações Web.

Frameworks.

CMS.

WordPress.

Joomla.

Drupal.

Muitos sites passaram a ser construídos sem programação.


Década de 2010

Cloud.

SaaS.

APIs REST.

Microserviços.

As plataformas começaram a conectar tudo.


Década de 2020

Explosão do verdadeiro No-Code.

Agora existem plataformas completas.

Aplicativos.

Workflows.

IA.

Bots.

Dashboards.

Integrações.

Tudo criado visualmente.


A diferença entre No-Code e Low-Code

Muita gente confunde.

No-Code

Destinado principalmente para usuários de negócio.

Exemplo:

Criar formulário

↓

Criar fluxo

↓

Publicar

Sem programação.


Low-Code

Destinado a desenvolvedores.

Permite código quando necessário.

Exemplo:

Fluxo visual

↓

Componente personalizado

↓

API

↓

Script

↓

Deploy

É muito mais poderoso.


Por que o No-Code cresceu tanto?

Porque o mercado possui um problema enorme.

Faltam desenvolvedores.

Empresas precisam entregar software rapidamente.

Nem toda aplicação exige uma equipe de engenharia.

Imagine criar:

  • formulário interno

  • cadastro

  • workflow de aprovação

  • pesquisa de satisfação

  • controle de férias

Não faz sentido desenvolver tudo em Java.

Nem em COBOL.

Nem em C#.

Uma ferramenta No-Code resolve em poucas horas.


Como funciona internamente?

Esse é um ponto importante.

No-Code não elimina programação.

Ele apenas esconde a programação.

Quando você cria:

Botão

↓

Enviar Email

a plataforma gera algo semelhante a:

HTML

CSS

JavaScript

API

Banco

Autenticação

Logs

Infraestrutura

Ou seja...

Alguém escreveu milhares de linhas de código para que você não precise escrevê-las.


As principais características

Uma plataforma No-Code normalmente possui:

Editor visual

Banco de dados

Autenticação

Controle de usuários

Integração com APIs

Dashboards

Automações

Relatórios

Workflow

Notificações

Segurança

Deploy automático


Principais metodologias

Embora cada fabricante possua sua implementação, quase todas seguem os mesmos conceitos.

Model Driven Development

Primeiro modela.

Depois gera.


Visual Programming

Fluxogramas.

Conexões.

Eventos.


Event Driven

Quando algo acontece...

Executa outra ação.

Cliente cadastrado

↓

Enviar Email

↓

Criar Pedido

↓

Registrar Log

↓

Atualizar CRM

Workflow Automation

Automação baseada em processos.

Muito utilizada em empresas.


Business Process Management (BPM)

Fluxos corporativos.

Aprovações.

Assinaturas.

Validações.

Integrações.


Domain Driven Modeling

A aplicação representa o negócio.

Não a tecnologia.


Vantagens

Desenvolvimento extremamente rápido

Horas.

Não meses.


Menor custo inicial

Poucos desenvolvedores.


Interface pronta

Layouts modernos.


Integração simples

Microsoft

Google

SAP

Salesforce

IBM

Oracle

Tudo via conectores.


Facilidade para prototipação

Ideal para MVP.


Atualizações automáticas

O fornecedor cuida da infraestrutura.


Baixa curva de aprendizado

Analistas conseguem construir aplicações simples.


Desvantagens

Agora vem a parte que o marketing raramente comenta.


Dependência do fornecedor

Seu sistema passa a depender totalmente da plataforma.


Vendor Lock-in

Trocar de ferramenta pode significar reconstruir tudo.


Limitações

Quando surge uma necessidade muito específica...

A plataforma pode simplesmente não permitir.


Performance

Nem sempre é ideal.

Algumas plataformas geram muito código desnecessário.


Escalabilidade

Funciona bem para centenas.

Nem sempre para milhões de usuários.


Licenciamento

Pode ficar caro.

Muito caro.

Especialmente conforme o número de usuários cresce.


Performance

Aqui existe um mito.

"No-Code é lento."

Nem sempre.

Depende da arquitetura.

Uma boa plataforma pode gerar aplicações excelentes.

Outra pode gerar aplicações enormes.

Tudo depende da qualidade do motor interno.


Segurança

Outro ponto crítico.

Toda plataforma precisa oferecer:

Autenticação

Criptografia

Auditoria

Controle de acesso

LGPD

Logs

Versionamento

Backup

Governança

Sem isso, ela dificilmente será aceita em ambientes corporativos.


Como desenvolver uma aplicação No-Code

Vamos imaginar um pequeno sistema de solicitação de férias.

Passo 1

Definir o processo.

Funcionário

↓

Solicita férias

↓

Gestor aprova

↓

RH confirma

↓

Sistema encerra

Passo 2

Criar entidades.

Funcionário

Departamento

Solicitação

Período

Gestor


Passo 3

Criar formulários.

Cadastro.

Consulta.

Aprovação.


Passo 4

Criar regras.

Se gestor aprovar...

Enviar ao RH.

Caso contrário...

Rejeitar.


Passo 5

Criar notificações.

Email.

Teams.

Slack.

WhatsApp.


Passo 6

Criar dashboards.

Solicitações abertas.

Pendentes.

Concluídas.

Tempo médio.


Passo 7

Publicar.

Sem compilação tradicional.


Boas práticas

Sempre modelar o processo primeiro.

Evitar criar fluxos gigantes.

Documentar regras.

Versionar alterações.

Controlar permissões.

Criar ambientes separados.

Testar integrações.

Monitorar desempenho.

Ter plano de contingência.


Os principais riscos

Criar aplicações sem arquitetura.

Duplicar regras.

Ausência de documentação.

Dependência da plataforma.

Integrações mal definidas.

Falta de testes.

Crescimento descontrolado.

Shadow IT.


Oportunidades para o programador COBOL

Aqui está o ponto mais importante deste artigo.

No-Code não compete com COBOL.

Ele complementa.

Imagine este cenário.

Cliente

↓

Portal Web

↓

Power Apps

↓

Power Automate

↓

API REST

↓

z/OS Connect

↓

CICS

↓

COBOL

↓

DB2

Quem executa a lógica crítica?

COBOL.

Quem apenas apresenta uma interface bonita?

No-Code.


O papel do Mainframe

O Mainframe continua sendo responsável por:

Transações financeiras.

Processamento batch.

Contabilidade.

Pagamentos.

Cartões.

PIX.

Previdência.

Folha.

Seguros.

Toda essa lógica permanece exatamente onde sempre esteve.


O papel do No-Code

Construir rapidamente:

Painéis administrativos.

Dashboards.

Consultas.

Workflows.

Aprovações.

Aplicativos internos.

Portais.


A integração perfeita

Hoje, uma arquitetura moderna costuma ser assim:

Usuário
      │
      ▼
Power Apps / Mendix / OutSystems
      │
      ▼
REST API
      │
      ▼
IBM z/OS Connect
      │
      ▼
CICS
      │
      ▼
Programa COBOL
      │
      ▼
DB2 / VSAM / IMS

Perceba que o COBOL não desaparece.

Ele ganha uma nova camada de apresentação.


Principais plataformas No-Code

Entre as mais conhecidas estão:

  • Microsoft Power Apps

  • Microsoft Power Automate

  • Mendix (Siemens)

  • OutSystems

  • AppSheet (Google)

  • Bubble

  • Glide

  • Zoho Creator

  • Airtable

  • Retool

  • ServiceNow App Engine

  • Salesforce Lightning Platform

  • Oracle APEX (frequentemente classificado como Low-Code)

  • IBM watsonx Orchestrate (automação e IA)

  • IBM Business Automation Workflow

Cada uma possui foco diferente: aplicativos corporativos, automação de processos, portais, integração ou desenvolvimento empresarial.


Onde o No-Code NÃO funciona bem?

Há cenários em que o desenvolvimento tradicional continua sendo a melhor escolha:

  • Sistemas bancários de alta criticidade.

  • Motores de processamento em tempo real.

  • Aplicações com requisitos extremos de desempenho.

  • Sistemas embarcados.

  • Softwares que exigem controle detalhado de memória ou hardware.

  • Algoritmos científicos complexos.

  • Grandes motores de processamento batch.

Nesses casos, linguagens como COBOL, Java, C/C++, PL/I ou Assembler continuam sendo mais adequadas.


O futuro do No-Code

A próxima evolução já começou.

Ela combina:

  • No-Code

  • Low-Code

  • Inteligência Artificial Generativa

  • Agentes de IA

  • Automação inteligente

  • APIs

  • RPA

  • Event-Driven Architecture

Em vez de apenas montar telas, o desenvolvedor descreve um processo em linguagem natural, e a plataforma gera boa parte da aplicação. Ainda assim, alguém precisa revisar arquitetura, segurança, integração, testes e governança.


O impacto no ambiente Mainframe

Para o profissional de IBM Z, o maior impacto não é técnico, mas estratégico.

As equipes de negócio querem entregar soluções mais rápido. O Mainframe continua sendo o sistema de registro (System of Record), enquanto plataformas No-Code aceleram a criação de experiências digitais.

Isso aumenta a importância de tecnologias como:

  • IBM z/OS Connect

  • APIs REST

  • OpenAPI

  • IBM MQ

  • Kafka

  • CICS Web Services

  • Db2 Services

  • OAuth e OpenID Connect

  • Arquiteturas orientadas a eventos

O programador COBOL deixa de ser apenas um desenvolvedor de programas batch e online para atuar como um engenheiro de serviços corporativos.


O Novo Perfil do Programador COBOL

O profissional mais valorizado nos próximos anos provavelmente será aquele que combina:

  • COBOL moderno

  • CICS

  • Db2

  • JCL

  • APIs REST

  • JSON

  • Git

  • DevOps

  • Segurança

  • Integração com plataformas Low-Code e No-Code

  • Arquitetura de sistemas

Ele não precisará construir cada tela manualmente. Em vez disso, projetará serviços confiáveis, escaláveis e seguros que poderão ser consumidos por aplicativos web, mobile, IA e plataformas No-Code.


Conclusão

No-Code não representa o fim da programação.

Representa uma mudança de foco.

Assim como os compiladores não eliminaram os programadores Assembly, e as linguagens de alto nível não eliminaram a engenharia de software, as plataformas No-Code não eliminam a necessidade de profissionais experientes.

Elas reduzem o esforço em tarefas repetitivas e aceleram a construção de aplicações simples, mas continuam dependentes de boas decisões de arquitetura, integração, segurança e governança.

No universo IBM Mainframe, essa realidade é ainda mais evidente. O COBOL permanece executando a lógica de negócios que movimenta bancos, seguradoras, governos e grandes empresas. O No-Code entra como uma camada de produtividade e experiência do usuário, consumindo serviços expostos pelo Mainframe por meio de APIs.

O futuro não será uma disputa entre COBOL e No-Code.

Será uma colaboração entre ambos.

O desenvolvedor que compreender essa integração deixará de enxergar o No-Code como ameaça e passará a utilizá-lo como mais uma ferramenta para entregar valor ao negócio.

Porque, no fim das contas, software nunca foi apenas escrever código.

Sempre foi resolver problemas. E essa continua sendo a missão de qualquer engenheiro de software — seja escrevendo milhares de linhas em COBOL, seja conectando componentes visuais que, por trás da interface, ainda dependem da mesma disciplina, do mesmo raciocínio lógico e da mesma engenharia que sustentam os sistemas mais importantes do mundo há décadas.

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...