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

terça-feira, 4 de junho de 2019

☕💥 A Jornada do Padawan COBOL – Parte 6 Desvendando o Universo dos CALLs no Mainframe

 

Bellacosa Mainframe apresenta o CALL em Cobol Parte VI

☕💥 A Jornada do Padawan COBOL – Parte 6

Desvendando o Universo dos CALLs no Mainframe

CICS LINK, XCTL, COMMAREA, Channels, Containers, APIs REST, MQ, Java e os Segredos dos Arquitetos da Nova República IBM Z

Ou como descobrir que um programa COBOL escrito em 1987 pode responder uma API REST em menos tempo do que muita startup consegue carregar um framework

Por Vagner Bellacosa – Bellacosa Mainframe


O dia em que o Padawan descobre que CALL não é a única forma de chamar programas

Até agora aprendemos:

✅ CALL estático

✅ CALL dinâmico

✅ Binder

✅ RENT

✅ CEEDUMP

✅ LPA

✅ LE

Mas um dia o Padawan entra em um ambiente CICS.

Abre um programa.

E encontra isto:

EXEC CICS LINK
     PROGRAM('PGM0001')
     COMMAREA(WS-COMM)
END-EXEC

E pensa:

Ué...

Cadê o CALL?


O universo paralelo do CICS

Em Batch usamos:

CALL 'VALIDA'

No CICS temos:

LINK

XCTL

START

RETURN

LOAD

DELETE


LINK

É praticamente o CALL do CICS.

Exemplo

EXEC CICS LINK
     PROGRAM('CPFVAL')
     COMMAREA(WS-COMMAREA)
END-EXEC

Visualmente


CLIENTE01


↓

LINK


↓

CPFVAL


↓

RETORNA


↓

CLIENTE01



Programa chamador continua vivo.

Igual ao CALL.


Vantagens

Retorna controle

Compartilha contexto

Excelente modularização

Pode executar milhares de vezes


XCTL

Agora a coisa muda.


Exemplo

EXEC CICS XCTL
     PROGRAM('MENU0001')
END-EXEC

Visualmente


TELA01

↓

XCTL

↓

MENU0001



TELA01 morre




Não retorna.

Nunca.


É quase um:

exit();

Quando usar?

Troca definitiva.

Menu.

Workflow.

Navegação.


LINK versus XCTL

CaracterísticaLINKXCTL
RetornaSimNão
Consome stackSimNão
PerformanceBoaExcelente
WorkflowMédioIdeal

COMMAREA

A rainha do CICS.


Ela transporta dados.


Exemplo

01 WS-COMM.

05 WS-CPF PIC X(11).

05 WS-NOME PIC X(30).

05 WS-RC PIC 99.

LINK

EXEC CICS LINK
PROGRAM('CPFVAL')
COMMAREA(WS-COMM)
LENGTH(100)
END-EXEC

Subprograma

DFHCOMMAREA.

O limite

64 KB


Padawan feliz.

Arquiteto preocupado.


Channels e Containers

IBM resolveu.


Nasce o conceito:

CHANNEL

CONTAINER


Praticamente JSON.

Mas IBM.


Exemplo

EXEC CICS PUT CONTAINER
CONTAINER('CLIENTE')
CHANNEL('CANAL1')
FROM(WS-CLIENTE)
END-EXEC

Ler

EXEC CICS GET CONTAINER
CONTAINER('CLIENTE')
CHANNEL('CANAL1')
INTO(WS-CLIENTE)
END-EXEC

Vantagens

Gigabytes.

Múltiplos objetos.

Flexível.


MQ

Padawan evolui.

Conhece IBM MQ.


Exemplo

CALL 'MQPUT'

Visualmente



COBOL

↓

MQPUT


↓

QUEUE


↓

JAVA


↓

API




Assíncrono.

Bonito.

Elegante.

IBM aprova.


APIs REST

O grande sonho.


"Posso expor COBOL como API?"

Sim.


Muito.


zOS Connect

O mago moderno.


Ele converte

REST

em

COBOL


Visualmente



POST /cliente



↓

zOS Connect



↓

COBOL



↓

DB2



↓

JSON




Cliente pensa:

Microserviço.


Realidade:

COBOL 1989.


Exemplo

API

{
"id":123
}

COBOL

01 WS-ID PIC 9(9).

Java

Sim.

Java conversa.


JNI.

LE.

DLL.


Exemplo

CobolService.executar();

COBOL

CALL 'PROCESSA'

Python

Sim.

Também.


API REST.

MQ.

Kafka.


Tudo possível.


Metal C

Território avançado.


Muito usado.

IBM Z.

Baixa latência.


zIIP

Arquiteto sorri.

Financeiro também.


Pode descarregar CPU.


Exemplo

JSON parsing.

REST.

MQ.

DB2 DRDA.


SMF 110

O espião do CICS.


Captura:

Tempo

CPU

LINK

XCTL

DB2

MQ


APA

Application Performance Analyzer


Mostra:

Hotspots

CALLs

Loops

CPU


Strobe

Ferramenta lendária.


Veteranos adoram.


Exemplo real

Programa

1000 LINKs

Tempo

5 segundos

Após otimização

400 ms


Truques Bellacosa

Dica 1

LINK

Retorna.


Dica 2

XCTL

Não retorna.


Dica 3

Channels > COMMAREA

Projetos novos.


Dica 4

MQ desacopla.


Dica 5

REST não mata COBOL.

REST promove COBOL.


Easter Egg Mainframe

Muitos bancos possuem.

Programa.

APIGEN01

Dentro.

EXEC CICS LINK

PROGRAM('LEG1987')

END-EXEC

API moderna.

Swagger.

OAuth.

OpenAPI.

JWT.

Kubernetes.

No final...

Executa.

MOVE SALDO TO WS-SALDO

Escrito em 1987.

Funciona.

Processa bilhões.

Ninguém reclama.


Checklist Jedi da Integração

✅ Preferir LINK

✅ XCTL para troca definitiva

✅ Evitar COMMAREA grande

✅ Usar Channels

✅ Monitorar SMF110

✅ Medir CPU

✅ Utilizar MQ

✅ Explorar zOS Connect

✅ Aproveitar zIIP

✅ Testar latência

✅ Documentar APIs


A Filosofia Jedi do CALL – Parte 6

O Padawan iniciante acredita:

COBOL só conversa com COBOL.

O desenvolvedor intermediário pensa:

COBOL pode consumir APIs.

O Arquiteto IBM Z entende:

COBOL conversa com qualquer tecnologia capaz de trocar bytes, mensagens, estruturas, JSON, XML ou eventos.

E é exatamente por isso que alguns dos sistemas mais modernos do planeta possuem uma arquitetura semelhante a esta:

Mobile

↓

API Gateway

↓

REST

↓

zOS Connect

↓

CICS LINK

↓

COBOL

↓

DB2

↓

MQ

↓

Analytics

↓

IA

Enquanto o cliente enxerga apenas um botão escrito "Consultar Saldo", um pequeno exército de programas COBOL, escritos ao longo de quarenta anos, continua executando silenciosamente milhões de chamadas por segundo, provando mais uma vez que, no Mainframe, a Força nunca esteve na moda da tecnologia, mas na sua capacidade de durar décadas sem perder desempenho, segurança e confiabilidade.


Próxima aventura do Padawan COBOL – Parte 7

Assembler, BALR, BASSM, PC-Bit, SVC, LE Internals, SRBs, TCBs, Cross Memory Services, zIIP, HiperDispatch e os segredos obscuros dos Sysprogs Jedi do IBM Z.


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