Translate

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

terça-feira, 19 de maio de 2026

☕💥 Guia Completo do CICS TS — O Coração Invisível Que Ainda Mantém o Mundo Financeiro Vivo no IBM Z 🖥️🔥

 

Bellacosa Mainframe apresenta o cics ts para padawans

☕💥 Guia Completo do CICS TS — O Coração Invisível Que Ainda Mantém o Mundo Financeiro Vivo no IBM Z 🖥️🔥

Existe um detalhe curioso sobre a computação moderna que pouca gente fora do universo enterprise percebe.

Enquanto milhões discutem cloud, Kubernetes, IA generativa e microsserviços, existe um sistema silencioso processando bilhões de transações financeiras com níveis absurdos de disponibilidade, consistência e performance que praticamente nenhum ambiente distribuído conseguiu reproduzir em escala global.

Esse sistema atende bancos, seguradoras, bolsas de valores, operadoras de cartão, governos, companhias aéreas e gigantes do varejo.

E no centro dessa engenharia quase “alienígena” existe uma criatura lendária chamada:

IBM CICS TS (Customer Information Control System Transaction Server)

Sim…

O famoso CICS.

O “monstro sagrado” do IBM Z.

O middleware transacional que sobreviveu décadas de revoluções tecnológicas enquanto inúmeros “substitutos definitivos” desapareceram da história.

E talvez o mais impressionante:

A maioria das pessoas usa CICS todos os dias sem sequer imaginar.


☕ O Que É o CICS TS?

O IBM CICS TS é um monitor transacional online para IBM Z.

Mas essa definição é pequena demais para explicar sua importância.

Na prática, o CICS é:

  • Um gerenciador de transações

  • Um ambiente de execução

  • Um middleware enterprise

  • Um controlador de recursos

  • Um servidor de aplicações

  • Um roteador de workloads

  • Um orquestrador de segurança

  • Um ecossistema inteiro de processamento online

Ele foi criado para resolver um problema extremamente complexo:

Como permitir milhares — ou milhões — de usuários simultâneos executando transações críticas sem destruir a integridade dos dados?

Esse problema continua existindo até hoje.

E o CICS continua sendo uma das melhores respostas já criadas.


☕ O Significado Real de “TS”

Muita gente fala apenas “CICS”.

Mas o nome atual é:

CICS TS = CICS Transaction Server

O “TS” surgiu quando o produto evoluiu de um simples monitor transacional para uma plataforma enterprise gigantesca.

Hoje o CICS TS oferece:

  • APIs modernas

  • REST

  • JSON

  • SOAP

  • Web Services

  • integração com cloud

  • OpenTelemetry

  • observabilidade

  • containers Java

  • Liberty

  • eventos em tempo real

  • integração com Kafka

  • z/OS Connect

  • APIs híbridas

Ou seja:

O CICS moderno não é “legacy”.

Ele é um sistema transacional enterprise híbrido.


☕ A História Que Quase Ninguém Conhece

O CICS nasceu em 1968.

Isso mesmo.

ANTES da internet moderna.

ANTES do Unix virar padrão.

ANTES do PC existir.

ANTES da computação distribuída.

E mesmo assim seus conceitos arquiteturais continuam modernos.

Isso assusta muita gente.

Porque mostra que alguns engenheiros da IBM literalmente projetaram sistemas décadas à frente do tempo.


☕ O Verdadeiro Papel do CICS no Banco

Imagine um banco sem CICS por 10 minutos.

Agora imagine:

  • PIX parado

  • TED indisponível

  • cartão recusando

  • ATM travado

  • saldo inconsistente

  • autorização falhando

  • filas congestionadas

  • compensação interrompida

O caos.

O CICS existe exatamente para impedir isso.

Ele foi criado para ambientes onde:

  • falha custa milhões

  • inconsistência destrói empresas

  • downtime vira desastre nacional


☕ Como o CICS Funciona na Prática

O modelo do CICS é elegantemente brutal.

Ele recebe milhares de solicitações concorrentes:

  • terminais 3270

  • APIs REST

  • MQ

  • Web Services

  • aplicações móveis

  • gateways financeiros

  • integrações Java

  • middlewares distribuídos

E transforma tudo isso em transações controladas.

Cada transação possui:

  • contexto

  • controle

  • rollback

  • recovery

  • segurança

  • sincronização

  • isolamento

O objetivo é simples:

Garantir integridade absoluta.


☕ O Conceito Mais Importante: Transação

No CICS, tudo gira ao redor de transações.

Uma transação precisa ser:

  • rápida

  • consistente

  • recuperável

  • segura

  • atômica

Se ocorrer falha:

  • rollback

  • recovery

  • journaling

  • syncpoint

O sistema volta ao estado consistente.

Isso parece “normal” hoje.

Mas quando o CICS nasceu isso era engenharia futurista.


☕ O Modelo Pseudo-Conversacional

Aqui está uma das maiores genialidades do CICS.

Ao invés de manter sessões gigantes consumindo memória eternamente, o CICS criou o conceito pseudo-conversacional.

Fluxo simplificado:

  1. usuário envia dados

  2. programa processa

  3. estado é salvo

  4. tarefa termina

  5. recursos são liberados

  6. usuário responde depois

  7. contexto é restaurado

Resultado:

  • escalabilidade absurda

  • menor consumo

  • maior throughput

  • eficiência monstruosa

Esse conceito continua brilhante até hoje.


☕ Regiões CICS — O Mundo Interno

O universo CICS é dividido em regiões.

As mais famosas:

TOR — Terminal Owning Region

Responsável pela comunicação de entrada.

Recebe conexões.

Distribui workloads.


AOR — Application Owning Region

Onde a lógica de negócio roda.

Os programas COBOL vivem aqui.

É o “cérebro operacional”.


FOR — File Owning Region

Gerencia acesso aos datasets e arquivos.

Controla VSAM e recursos compartilhados.


WUI — Web User Interface

Interface administrativa moderna.


JVM Server

Permite workloads Java dentro do CICS.


☕ O Ciclo de Vida de uma Transação

Uma transação passa por múltiplas fases:

1. Attach

O CICS cria a task.


2. Dispatch

A tarefa recebe CPU.


3. Execute

Programa COBOL roda.

Comandos EXEC CICS são processados.


4. File Access

DB2, VSAM, MQ, APIs.


5. Syncpoint

Commit ou rollback.


6. Termination

Task encerrada.

Recursos liberados.


☕ EXEC CICS — A Linguagem Sagrada

Programas COBOL interagem com o CICS usando:

EXEC CICS
   SEND MAP('TELA1')
END-EXEC

ou:

EXEC CICS
   READ FILE('CLIENTE')
END-EXEC

O EXEC CICS funciona como uma API nativa do monitor transacional.

É praticamente uma “linguagem dentro da linguagem”.


☕ BMS — A Engenharia das Telas 3270

Antes de frameworks web existirem…

O CICS já possuía geração dinâmica de interfaces.

Isso acontecia via:

BMS — Basic Mapping Support

O BMS define:

  • campos

  • atributos

  • proteção

  • intensidade

  • validação

  • layouts

Tudo otimizado para terminais 3270.

E absurdamente eficiente.


☕ VSAM + CICS — A Dupla Histórica

Durante décadas:

VSAM + CICS + COBOL

foram a espinha dorsal do sistema financeiro mundial.

O VSAM oferecia:

  • acesso rápido

  • alta confiabilidade

  • baixa latência

  • recuperação eficiente

O CICS coordenava tudo.


☕ CICS + DB2 — A Evolução Enterprise

Com o crescimento do SQL, o DB2 tornou-se dominante.

Hoje o modelo clássico é:

  • CICS

  • COBOL

  • DB2

  • MQ

  • RACF

  • z/OS

A famosa “stack dourada” do IBM Z.


☕ Segurança no CICS

O CICS moderno integra profundamente com:

RACF

Controle de:

  • usuários

  • transações

  • programas

  • recursos

  • datasets

  • APIs

Tudo auditável.

Tudo rastreável.

Tudo controlado.


☕ Performance — O Verdadeiro Monstro

Aqui mora algo que impressiona engenheiros modernos.

O CICS consegue:

  • milhões de transações por segundo

  • latência extremamente baixa

  • uso eficiente de CPU

  • altíssimo throughput

  • estabilidade absurda

E muitas vezes usando menos recursos que arquiteturas distribuídas gigantescas.


☕ O Dispatcher do CICS

O dispatcher controla:

  • prioridades

  • tasks

  • waits

  • dispatching

  • TCBs

  • QR TCB

  • Open TCBs

É uma engenharia refinada ao extremo.

Muitos gargalos críticos surgem exatamente aqui.


☕ QR TCB — O Gargalo Clássico

A famosa QR TCB é quase uma entidade mitológica no mundo mainframe.

Ela controla grande parte do processamento serializado.

Quando ocorre saturação:

  • response time explode

  • filas aumentam

  • CPU sobe

  • throughput despenca

Performance tuning em CICS frequentemente gira ao redor disso.


☕ Open TCB — A Revolução Moderna

O CICS evoluiu para múltiplos TCBs paralelos.

Isso permitiu:

  • maior paralelismo

  • workloads Java

  • threadsafe

  • redução de contenção

  • melhor escalabilidade

Essa foi uma mudança gigantesca.


☕ Threadsafety — O Conceito Que Mudou Tudo

Programas threadsafe podem executar fora da QR.

Resultado:

  • menos serialização

  • mais paralelismo

  • maior throughput

  • menor contenção

Hoje isso é fundamental.


☕ Recovery Manager — O Guardião da Consistência

O CICS possui mecanismos sofisticados de recovery:

  • journaling

  • logging

  • syncpoints

  • backout

  • restart

  • warm start

  • cold start

  • emergency restart

Se algo falha…

O sistema tenta preservar integridade absoluta.


☕ CICS e APIs Modernas

Aqui muita gente fica surpresa.

O CICS moderno fala:

  • REST

  • JSON

  • HTTP

  • SOAP

  • XML

  • OpenAPI

Sim…

Você pode expor COBOL como API REST.

E milhões de empresas fazem isso diariamente.


☕ z/OS Connect — O Portal Entre Dois Mundos

O z/OS Connect EE revolucionou integração.

Ele transforma programas CICS em APIs modernas.

Isso permitiu:

  • integração cloud

  • mobile

  • fintechs

  • microsserviços

  • open banking

Sem reescrever décadas de negócio crítico.


☕ CICS Event Processing

O CICS moderno consegue gerar eventos em tempo real.

Exemplo:

  • transação executada

  • limite excedido

  • fraude detectada

  • cliente premium acessou

  • falha ocorreu

Esses eventos podem alimentar:

  • Kafka

  • Splunk

  • Elastic

  • SIEM

  • observabilidade

  • analytics


☕ Observabilidade Moderna no CICS

O CICS atual entrou oficialmente na era observability.

Hoje temos integração com:

  • OpenTelemetry

  • Grafana

  • Instana

  • Elastic

  • Splunk

  • OMEGAMON

O mundo “caixa preta do mainframe” acabou.


☕ CICS + Java

Sim…

Java dentro do CICS existe.

A IBM criou:

  • JVM Server

  • Liberty Profile

  • integração híbrida

  • APIs Java

  • containers modernos

Tudo coexistindo com COBOL.

É literalmente computação de múltiplas eras convivendo no mesmo ambiente.


☕ O Mito do “Legacy”

Existe uma confusão enorme aqui.

Muita gente chama CICS de legado porque ele é antigo.

Mas “antigo” não significa “obsoleto”.

Pelo contrário.

O CICS continua sendo utilizado porque:

  • funciona

  • escala

  • é resiliente

  • é auditável

  • é seguro

  • é eficiente

  • custa menos do que falhas

O verdadeiro problema não é o CICS.

O problema é engenharia ruim ao redor dele.


☕ O Erro das Empresas Modernas

Muitas organizações tentaram “matar o mainframe”.

Resultado comum:

  • explosão de custo

  • perda de performance

  • inconsistência

  • caos operacional

  • outages

  • rollback do projeto

Então descobriram algo doloroso:

Reproduzir décadas de engenharia transacional é absurdamente difícil.


☕ O Futuro do CICS

O futuro do CICS provavelmente será:

  • híbrido

  • API-first

  • integrado com IA

  • observável

  • conectado à cloud

  • orientado a eventos

  • automatizado

  • cada vez mais invisível

O usuário final nunca verá o CICS.

Mas continuará dependendo dele diariamente.


☕ O Grande Segredo do Mainframe

O público vê:

  • apps bonitos

  • fintechs modernas

  • bancos digitais

  • IA generativa

Mas nos bastidores…

Existe uma infraestrutura brutal garantindo que:

  • dinheiro não suma

  • transações não se corrompam

  • contas permaneçam consistentes

  • bilhões de operações sobrevivam diariamente

E o CICS continua sendo uma das maiores obras de engenharia da história da computação.


☕ Conclusão — O Sistema Que Sobreviveu a Tudo

O CICS sobreviveu:

  • ao nascimento do PC

  • à era Unix

  • à internet

  • ao client/server

  • à virtualização

  • à cloud

  • aos microsserviços

  • ao hype eterno do “fim do mainframe”

E continua processando o coração financeiro do planeta.

Talvez porque tecnologia enterprise real não seja sobre moda.

Talvez seja sobre:

  • estabilidade

  • consistência

  • engenharia

  • previsibilidade

  • confiança

Enquanto bilhões dependem disso…

O CICS continuará vivo.

Silencioso.

Invisível.

E absurdamente indispensável.

segunda-feira, 30 de março de 2026

🔥 SEU COBOL PODE VIRAR API… E VOCÊ NEM SABIA 😳IBM HTTP Server no z/OS — a porta secreta que conecta o mainframe ao mundo

 

Bellacosa Mainframe e o servidor web dentro Mainframe

🔥 SEU COBOL PODE VIRAR API… E VOCÊ NEM SABIA 😳

IBM HTTP Server no z/OS — a porta secreta que conecta o mainframe ao mundo

Se você ainda acha que mainframe é “tela verde + batch”…
👉 você está anos atrás.

Existe um componente rodando silenciosamente no z/OS que transforma:

COBOL legado → API moderna → web → mobile → cloud

Esse cara é o IBM HTTP Server (IHS).
E hoje você vai entender como ele funciona de verdade — no estilo Bellacosa 👊🔥


🌐 O QUE É O IBM HTTP SERVER?

O IHS (IBM HTTP Server) é o web server oficial da IBM.

👉 Baseado no Apache, mas com:

  • integração com z/OS
  • segurança enterprise (RACF)
  • performance absurda

💡 Tradução direta:

“É o Apache… só que preparado pra rodar num banco de bilhões.”


🧠 COMO ELE FUNCIONA (VISÃO REAL)

Quando alguém acessa:

https://empresa.com/api/clientes

Acontece isso:

Cliente (browser/app)

IBM HTTP Server (z/OS)

Backend (CICS / COBOL / DB2)

Resposta HTTP

🔥 Insight importante

O IHS NÃO executa COBOL diretamente.

Ele:

  • recebe requisição
  • encaminha para outro componente (ex: CICS, WAS)
  • devolve resposta

🏗️ ARQUITETURA TÍPICA

Internet

IHS (porta 80/443)

WebSphere / z/OS Connect

COBOL / CICS / DB2

⚙️ INSTALAÇÃO (nível z/OS raiz)

🔹 Requisitos básicos

  • z/OS instalado
  • TCP/IP ativo
  • USS (UNIX System Services)
  • Dataset do produto (SMP/E)

🔥 Onde ele vive?

👉 No USS (Unix do z/OS)

Exemplo de path:

/usr/lpp/ihs

💡 Insight

Se não conhece USS… já começou errado no mundo moderno do mainframe.


📦 INSTALAÇÃO via SMP/E

Resumo do processo:

  1. RECEIVE
  2. APPLY
  3. ACCEPT

👉 padrão IBM para software


⚙️ CONFIGURAÇÃO

Arquivo principal:

httpd.conf

🔹 Exemplo simples

Listen 8080

ServerName localhost

DocumentRoot "/u/ihs/htdocs"

<Directory "/u/ihs/htdocs">
AllowOverride None
Require all granted
</Directory>

💡 Tradução

  • porta → onde escuta
  • document root → onde estão arquivos
  • directory → permissões

🚀 EXECUÇÃO NO z/OS

Você pode iniciar via:

🔹 USS (direto)

apachectl start

🔹 Ou via JCL (mainframe raiz 👇)

//IHSSTART JOB ...
//STEP1 EXEC PGM=BPXBATCH
//STDOUT DD SYSOUT=*
//STDERR DD SYSOUT=*
//STDPARM DD *
SH /usr/lpp/ihs/bin/apachectl start
/*

🔥 Tradução Bellacosa

JCL chama UNIX… que sobe o servidor web 😳


🧪 TESTES (o momento da verdade)

Após subir:

🔹 Teste básico

curl http://localhost:8080

🔹 Ou browser:

http://hostname:8080

🧩 INTEGRAÇÃO COM COBOL

🔥 Cenário real

Você tem:

  • programa COBOL em CICS

Quer expor como API:

👉 Caminho:

IHS → z/OS Connect → CICS → COBOL

💡 Resultado

  • COBOL vira REST API
  • JSON entra / sai
  • mundo moderno conversa com legado

🔐 SEGURANÇA

🔹 Recursos:

  • SSL/TLS
  • certificados digitais
  • integração com RACF

🧨 Easter Egg

Você pode proteger endpoint HTTP com regras RACF.

👉 Sim, segurança de banco direto na web.


⚡ PERFORMANCE

🔥 Diferenciais no z/OS:

  • alta disponibilidade
  • integração com sistema
  • throughput absurdo

💡 Insight

O gargalo raramente é o IHS…
geralmente é o backend (COBOL/DB2)


🧨 CURIOSIDADES (nível Bellacosa)

🧠 1. Apache dentro do mainframe

Sim, mas adaptado e otimizado.


🔥 2. COBOL pode responder HTTP

Com ajuda de outros componentes.


💀 3. Web pode rodar sem sair da máquina

Com HiperSockets (memória ↔ memória).


🤯 4. Você pode ter API moderna…

rodando código de 30 anos.


⚠️ PROBLEMAS COMUNS

  • porta já em uso
  • erro de permissão USS
  • SSL mal configurado
  • backend não responde

🧠 DICAS DE OURO

💡 Dica 1

Sempre valide:

netstat -a | grep 8080

💡 Dica 2

Logs são sua vida:

logs/error_log
logs/access_log

💡 Dica 3

Entenda o fluxo completo

IHS raramente é o problema — ele só repassa.


🎯 RESUMO FINAL

✔ IHS = web server do z/OS

✔ Baseado em Apache

✔ Roda no USS

✔ Integra com COBOL via outros serviços

✔ Permite API, web e cloud


💥 FRASE FINAL

“O IBM HTTP Server é o tradutor…
que faz o mundo moderno entender o que o COBOL sempre soube fazer.”

 

sábado, 14 de dezembro de 2024

JSON em COBOL no IBM Z: O Holocron das APIs Modernas

 

Bellacosa Mainframe COBOL com JSON

JSON em COBOL no IBM Z: O Holocron das APIs Modernas

Como um Linguagem Criada em 1959 Aprendeu a Conversar com APIs, Mobile, Open Banking e a Nuvem

Por muitos anos, o universo COBOL parecia limitado a arquivos VSAM, DB2, IMS, CICS, JCLs e relatórios batch executados silenciosamente nos datacenters. Entretanto, a transformação digital trouxe novos desafios e uma nova linguagem passou a dominar a comunicação entre aplicações modernas: JSON (JavaScript Object Notation).

Hoje, smartphones, microsserviços, OpenShift, Open Banking, PIX, aplicações em nuvem e plataformas de inteligência artificial utilizam JSON como principal formato de intercâmbio de informações. E o mais interessante é que o Enterprise COBOL para IBM Z evoluiu para participar naturalmente desse ecossistema.

Com a introdução das instruções JSON PARSE e JSON GENERATE no Enterprise COBOL 6.x, programas COBOL passaram a compreender, produzir e consumir documentos JSON de forma nativa, eficiente e segura, permitindo a integração com APIs REST, IBM MQ, Kafka, z/OS Connect e arquiteturas modernas baseadas em eventos.

Esta série especial Bellacosa Mainframe apresenta uma jornada completa para o jovem Padawan COBOL compreender desde os conceitos básicos até técnicas avançadas utilizadas por especialistas IBM Z.


📖 Capítulo 1 – O Despertar do JSON

Quando o Padawan Descobre que COBOL Pode Falar a Linguagem das APIs

Neste primeiro holocron, exploramos os fundamentos do JSON, sua história, a chegada do suporte nativo ao Enterprise COBOL, diferenças entre JSON e XML, conceitos de UTF-8 e EBCDIC, além dos primeiros exemplos utilizando JSON GENERATE.

➡️ https://eljefemidnightlunch.blogspot.com/2024/07/json-em-cobol-no-ibm-z-o-holocron-das.html


📖 Capítulo 2 – JSON PARSE

Quando o Padawan Aprende a Transformar Texto em Estruturas COBOL

Aqui mergulhamos na instrução JSON PARSE, aprendendo a converter documentos JSON em estruturas COBOL, trabalhar com objetos aninhados, vetores utilizando OCCURS, tratar exceções, validar payloads recebidos e compreender os desafios relacionados à segurança e ao processamento de grandes volumes de dados.

➡️ https://eljefemidnightlunch.blogspot.com/2024/09/json-em-cobol-no-ibm-z-o-holocron-das.html


📖 Capítulo 3 – JSON GENERATE

Quando o Padawan Aprende a Construir APIs REST com COBOL

No terceiro capítulo, estudamos JSON GENERATE, recursos como SUPPRESS, NAME OF, tratamento de campos opcionais, construção de respostas para APIs REST, geração de payloads PIX e Open Banking, além de recomendações de desempenho e proteção contra exposição acidental de informações sensíveis.

➡️ https://eljefemidnightlunch.blogspot.com/2024/10/json-em-cobol-no-ibm-z-o-holocron-das.html


📖 Capítulo 4 – JSON Jedi Master

z/OS Connect, MQ, Kafka, OpenShift, OWASP e as Técnicas Jedi do IBM Z

No capítulo final, elevamos o nível de conhecimento para arquiteturas corporativas modernas. Exploramos o papel do z/OS Connect, integração com IBM MQ, Kafka, OpenShift, APIs de alto desempenho, conceitos da OWASP API Top 10, estratégias de observabilidade, segurança, escalabilidade e as melhores práticas adotadas por equipes especializadas em IBM Z.

➡️ https://eljefemidnightlunch.blogspot.com/2024/11/json-em-cobol-no-ibm-z-o-holocron-das.html


O Conselho Final do Mestre Bellacosa

Durante décadas, disseram aos desenvolvedores COBOL que sua missão terminava em arquivos sequenciais e terminais verdes. O JSON mostrou exatamente o contrário. Ele permitiu que programas escritos há décadas passassem a conversar com smartphones, microsserviços, aplicações em nuvem e plataformas digitais espalhadas por toda a galáxia tecnológica.

COBOL não precisou abandonar sua robustez, estabilidade ou capacidade de processar milhões de transações por segundo. Ele apenas aprendeu um novo idioma.

E talvez esta seja a maior lição deste Holocron:

COBOL não é uma tecnologia do passado.

COBOL é um veterano experiente que aprendeu a falar a língua do futuro.

Que o JSON PARSE esteja com você. E que o JSON GENERATE jamais exponha uma senha em produção. 🚀💙🖥️


Para ir mais longe

🔥☕ Como se Usa JSON em COBOL?

Nos últimos anos, o JSON (JavaScript Object Notation) tornou-se o formato mais utilizado para integração entre aplicações modernas, APIs REST, Mobile, Cloud e Mainframe.

https://eljefemidnightlunch.blogspot.com/2007/02/como-se-usa-json-em-cobol.html

🔥☕ JSON: O “COBOL DOS DADOS MODERNOS”? — A Linguagem Invisível Que Dominou APIs, Nuvem e Até o Mainframe

https://eljefemidnightlunch.blogspot.com/2010/10/json-o-cobol-dos-dados-modernos.html


sábado, 9 de novembro de 2024

JSON em COBOL no IBM Z: O Holocron das APIs Modernas – JSON Jedi Master - Parte IV

 

Bellacosa Mainframe e o json no cobol parte iv

JSON em COBOL no IBM Z: O Holocron das APIs Modernas

Parte 4 – JSON Jedi Master

z/OS Connect, MQ, Kafka, OpenShift, APIs de Alto Desempenho, Segurança OWASP e as Técnicas Jedi do IBM Z

Por Bellacosa Mainframe


"O Padawan aprende JSON PARSE. O Cavaleiro domina JSON GENERATE. O Mestre compreende que JSON é apenas a linguagem utilizada para conectar mundos inteiros."

Mestre Bellacosa Sysprog Jedi


Introdução

Chegamos ao último holocron.

Na Parte 1 aprendemos:

  • JSON

  • JSON GENERATE

  • UTF8

  • APIs

Na Parte 2:

  • JSON PARSE

  • Arrays

  • OCCURS

  • Segurança

Na Parte 3:

  • JSON GENERATE avançado

  • SUPPRESS

  • NAME OF

  • APIs REST

Agora chegamos ao nível do Mestre.

O momento em que COBOL deixa de apenas processar JSON.

E passa a ser um participante ativo de arquiteturas modernas.


O grande segredo

Muitos ainda imaginam.

COBOL

Batch

Relatório

Fim.

Mas o IBM Z moderno é muito diferente.

Hoje podemos encontrar:

COBOL

JSON

API

Mobile

Cloud

Kafka

OpenShift

IA

Aplicações Web


O papel do JSON

JSON tornou-se.

O idioma universal.


Imagine.

Banco.

Aplicativo.

PIX.

Open Finance.

Cartão.

Seguro.

Marketplace.

IoT.


Praticamente todos utilizam.

JSON.


z/OS Connect

Talvez seja a tecnologia mais importante.

Para o COBOL moderno.


O que é?

Uma ponte.

Entre.

IBM Z.

E.

REST APIs.


Visualmente.

Smartphone

↓

REST

↓

z/OS Connect

↓

COBOL

↓

DB2

Exemplo

Usuário.

Consulta saldo.

Aplicativo.

HTTPS

z/OS Connect

JSON

COBOL

DB2

JSON

Aplicativo


Tudo transparente.


COBOL não vê HTTP

Na maioria dos casos.

Não.


Ele apenas recebe.

Estrutura.

COBOL.

Já preenchida.


Exemplo.

01 WS-CONTA.


05 AGENCIA.


05 CONTA.



JSON PARSE.

Feito.

Automaticamente.


MQ

Outro caso.

Muito comum.


Mensagem.

Chega.

MQ.


Payload.

JSON.


COBOL.

Processa.


Exemplo.

{

"tipo":"pix",

"valor":100

}

COBOL.

Recebe.


Executa.

Negócio.


Responde.


JSON GENERATE.


MQPUT.


Fim.


Kafka

Sim.

Também.


Arquitetura.

COBOL

↓

MQ

↓

Kafka Bridge

↓

Kafka

↓

Analytics

Muito utilizado.


Open Finance.


Fraudes.


IA.


Big Data.


OpenShift

Outro mundo.

Interessante.


Microsserviços.

Containers.

Kubernetes.


COBOL.

Participa.


Arquitetura.

OpenShift

↓

REST

↓

zOS Connect

↓

COBOL

↓

IMS

DB2

Muito elegante.


APIs síncronas

Cliente.

Espera.

Resposta.


Exemplo.

Saldo.


API.

Responde.

200 ms.


APIs assíncronas

MQ.

Kafka.

Evento.


Mais modernas.


GraphQL

Também possível.


Embora.

Menos comum.


Segurança

Aqui começa.

O lado sombrio.


OWASP.

Existe.

Também.

Para APIs.


OWASP API Top 10

Excelente leitura.


Problemas.

Mais comuns.


Excesso.

Dados.


Exposição.

Sensível.


Autorização.

Fraca.


Payload.

Gigante.


DoS.


Exemplo ruim

COBOL.

01 CLIENTE.


05 CPF.


05 SENHA.


05 TOKEN.

JSON GENERATE.


API.


Exposta.


Desastre.


Melhor

Criar DTO.


Exemplo.

01 API-CLIENTE.


05 NOME.


05 LIMITE.

Muito melhor.


JWT

Muito utilizado.


JSON Web Token.


Aplicação.

Recebe.


Valida.


Autoriza.


COBOL.

Pode.

Consumir.


Ou.

Delegar.


TLS

Obrigatório.

Hoje.


HTTPS.

Sempre.


Nunca.

HTTP.


Rate Limit

Muito importante.


Evita.

DoS.


Exemplo.

Chamadas.

Por minuto.


Logs

Essenciais.


Exemplo.

2026-06-25


PIX


100 reais


OK

Muito útil.


Auditoria.


Performance

JSON.

Tem custo.


Parser.

CPU.


Serializer.

CPU.


Mas.

IBM Z.

É extremamente eficiente.


Benchmarks.

Mostram.

Milhares.

TPS.


Sem dificuldades.


JSON gigantesco

Cuidado.


Exemplo.

50 MB.


Parser.

Vai sofrer.


CPU.

Memória.


Melhor.

Paginar.


Streaming

Excelente opção.


Processar.

Em partes.


Mais eficiente.


Cache

Pode ajudar.


JSON.

Já montado.


Evita.

JSON GENERATE.

Toda vez.


Curiosidade

Muitos bancos.

Geram.

Milhões.

JSON.

Por hora.


E.

Grande parte.

Nasce.

Em COBOL.


Curiosidade 2

Usuário.

Abre.

App.


Consulta.

Saldo.


Recebe.

JSON.


Origem.

Programa COBOL.

Escrito.


Executando.

Num.

IBM z17.


Curiosidade 3

Muitos.

Open Banking.

Brasileiros.

Passam.

Por.

COBOL.

Sem.

Que.

Usuário.

Perceba.


Bellacosa Best Practices

Regra 1

Nunca.

Gerar.

JSON.

Com STRING.


Regra 2

JSON GENERATE.

Sempre.


Regra 3

JSON PARSE.

Sempre.


Regra 4

Versione.

APIs.


Exemplo.

v1

v2

v3


Regra 5

OpenAPI.

Swagger.

Documente.


Regra 6

Nunca.

Expor.

Campos internos.


Regra 7

Teste.

UTF8.


Regra 8

Monitore.

SMF.

RMF.

Logs.


Regra 9

Valide.

Payloads.


Regra 10

Use.

OWASP.

API Top 10.


Quando usar JSON?

Excelente.

REST.

Open Banking.

PIX.

Cloud.

Kafka.

MQ.

OpenShift.

Mobile.

Marketplace.

IoT.

Microsserviços.


Quando evitar?

Batch.

VSAM.

Arquivos internos.

Processamento.

Fechado.


O Conselho Final do Mestre Bellacosa

Durante muito tempo, disseram ao desenvolvedor COBOL que seu universo terminava em arquivos sequenciais, JCLs, relatórios impressos e terminais verdes.

JSON mostrou que isso nunca foi verdade.

JSON permitiu que programas escritos décadas atrás passassem a conversar com smartphones, aplicativos financeiros, plataformas Open Banking, clusters OpenShift, sistemas Kafka e serviços espalhados por diversas nuvens.

Talvez essa seja a maior beleza do IBM Z moderno.

Ele não obriga ninguém a abandonar o COBOL.

Ele apenas entrega novas ferramentas.

E diz:

Continue usando seus níveis 01, 05, 10 e OCCURS.

Continue confiando na robustez do Enterprise COBOL.

Continue processando milhões de transações por segundo.

Eu apenas ensinarei seu programa a falar o idioma utilizado pela galáxia digital.

E talvez essa seja a verdadeira lição do Holocron JSON.

JSON não substituiu COBOL.

JSON apenas permitiu que COBOL expandisse sua voz para além dos corredores do datacenter, alcançando praticamente qualquer sistema capaz de compreender uma simples mensagem cercada por chaves e aspas.


Fim do Holocron Bellacosa Mainframe

JSON em COBOL no IBM Z – Parte 1 a Parte 4 concluídas

"Que o JSON PARSE esteja com você. E que o JSON GENERATE nunca produza um campo SENHA por engano." 🚀💙🖥️


sexta-feira, 11 de outubro de 2024

JSON em COBOL no IBM Z: O Holocron das APIs Modernas – JSON GENERATE - Parte III

 

Bellacosa Mainframe e o json em cobol parte iii

JSON em COBOL no IBM Z: O Holocron das APIs Modernas

Parte 3 – JSON GENERATE

Quando o Padawan Aprende a Construir APIs REST com COBOL e Descobre que Também Pode Falar com a Galáxia

Por Bellacosa Mainframe


"JSON PARSE ensina COBOL a escutar. JSON GENERATE ensina COBOL a responder. Um Mestre Jedi precisa dominar ambos."

Mestre Bellacosa Sysprog Jedi


Introdução

Nas jornadas anteriores, o jovem Padawan descobriu algo extraordinário.

Primeiro aprendeu que COBOL moderno fala JSON.

Depois aprendeu a utilizar JSON PARSE.

Agora chega o momento em que ele percebe uma verdade ainda mais impressionante.

COBOL não apenas entende JSON.

COBOL também consegue produzir JSON de forma elegante, otimizada e extremamente rápida.

E isso é feito através de uma instrução quase tão poderosa quanto um sabre de luz recém-montado.

JSON GENERATE


O que é JSON GENERATE?

JSON GENERATE é um serializador.

Seu objetivo é simples.

Transformar estruturas COBOL em texto JSON.

Visualmente.

WORKING STORAGE


↓

JSON GENERATE


↓

JSON


↓

REST API


↓

Aplicativo


↓

Microsserviço

Em outras palavras.

Ele faz exatamente o oposto de JSON PARSE.


Antes do Enterprise COBOL 6

A vida era difícil.

Muitos sistemas faziam:

STRING

"{"

'"id":'

WS-ID

','
'"nome":"'

WS-NOME

'"'

"}"

INTO WS-BUFFER

Problemas.

Vírgulas.

Aspas.

Espaços.

Campos vazios.

Arrays.

Escape.

Tudo manual.


Padawan sofria.


O nascimento de JSON GENERATE

Enterprise COBOL Version 6.

Introduziu.

JSON GENERATE.


Mudou completamente.

Integrações.


Hoje.

Muito utilizado.

6.3

6.4

6.5


Primeiro exemplo

Passo 1

Estrutura COBOL

01 WS-CLIENTE.


05 WS-ID.
PIC 9(5).


05 WS-NOME.
PIC X(30).


05 WS-IDADE.
PIC 999.

Passo 2

JSON Buffer

01 WS-JSON.

PIC X(500).

Passo 3

Popular

MOVE 100

TO WS-ID


MOVE 'Bellacosa'

TO WS-NOME


MOVE 52

TO WS-IDADE

Passo 4

Gerar

JSON GENERATE

WS-JSON


FROM WS-CLIENTE

Passo 5

Display

DISPLAY WS-JSON

Resultado.

{

"id":100,

"nome":"Bellacosa",

"idade":52

}

Pronto.

API pronta.


Como funciona internamente?

Compilador gera.

Serializer.


Percorre.

Estrutura.

Campo.

Por campo.


Converte.

Numéricos.

Strings.

Booleans.

Occurs.


Escreve.

JSON.


Visualmente.

WS-ID


↓

Serializer


↓

"id":100

Memória

JSON continua sendo.

Texto.


Exemplo.

01 WS-JSON.

PIC X(10000).

Buffer.

Grande.


Serializer.

Preenche.


Pouco overhead.


Muito eficiente.


Campos vazios

Problema comum.


Exemplo.

MOVE SPACES

TO WS-NOME

Resultado.

"name":""

Nem sempre desejado.


SUPPRESS

Ferramenta poderosa.


Exemplo conceitual.

JSON GENERATE

WS-JSON


FROM WS-DADOS


SUPPRESS

Campos vazios.

Não aparecem.


Muito usado.

Em APIs.


OMITTED

Outra técnica.


Campo opcional.


Excelente.

Open Banking.

PIX.


NAME OF

Talvez a funcionalidade favorita.

Do Bellacosa.


COBOL.

05 WS-NOME.

JSON desejado.

"customerName"

NAME OF permite.

Mapear.


Muito elegante.


Exemplo API PIX

COBOL.

01 PIX.


05 CHAVE.


05 VALOR.


05 DATA.

JSON.

{

"chave":"abc",


"valor":100,


"data":"2026-06-25"

}

JSON GENERATE.

Faz.

Tudo.


Arrays

Muito útil.


COBOL.

05 TELEFONES.


10 TEL OCCURS 5.

JSON.

"telefones":[


"1111",


"2222"

]

Automático.


Objetos aninhados

COBOL.

01 CLIENTE.


05 DADOS.


10 ID.


10 NOME.



05 ENDERECO.


10 CIDADE.


10 CEP.

Resultado.

{

"cliente":{


"id":1,

"nome":"Bellacosa"


},

"endereco":{


"cidade":"SP"

}

}

Muito elegante.


Null

JSON suporta.


COBOL não.


Precisamos.

Decidir.


Campo vazio.


Campo omitido.


Valor padrão.


Muito importante.


UTF8

Outro cuidado.


JSON.

UTF8.


COBOL.

EBCDIC.


Conversão.

Necessária.


Especialmente.

Acentos.


José.

São Paulo.


Ç.

Ã.


Sempre testar.


Segurança

Poucos lembram.


JSON GENERATE.

Também possui.

Riscos.


Exemplo.

Dados internos.


Senha.


CPF.


Token.


Acidentalmente.

Expostos.


Exemplo.

01 CLIENTE.


05 SENHA.


PIC X(20).

JSON GENERATE.

Sem SUPPRESS.


API.

Expõe.

Senha.


Muito perigoso.


Boa prática

Criar.

Estrutura.

Específica.

API.


Nunca.

Gerar.

Diretamente.

Working Storage.

Inteira.


Pretty JSON

COBOL.

Não gera.

JSON bonito.


Compacto.


Mais eficiente.


Consumidor.

Pode formatar.


Performance

Excelente.


Serializer.

Nativo.


Compilado.


Muito rápido.


Melhor.

Que STRING.


Melhor.

Que montar.

Na mão.


Benchmark aproximado

Manual.

100%


JSON GENERATE.

Muito menor.

CPU.


Menos bugs.


Mais manutenção.


Curiosidade

Muitos aplicativos bancários.

Recebem.

JSON.

Gerado.

Por COBOL.


Usuário.

Nunca percebe.


Abre app.


Consulta saldo.


Recebe.

JSON.


Origem.

COBOL.

No z17.


APIs modernas

JSON GENERATE é usado.

Em.

z/OS Connect

CICS

Liberty

MQ

Kafka

OpenShift

Cloud Pak


Praticamente.

Todo lugar.


Bellacosa Best Practices

Sempre

Criar DTO.

Separado.


Sempre

Usar SUPPRESS.


Sempre

Validar UTF8.


Sempre

Versionar JSON.


Sempre

Documentar.

Swagger.

OpenAPI.


Nunca

Expor.

Campos internos.


Nunca

Montar.

JSON.

Na mão.

Com STRING.


Comparação

TécnicaRecomendada
STRINGNão
UNSTRINGNão
INSPECTNão
Parser próprioEvitar
JSON GENERATESim
JSON PARSESim

O Conselho do Mestre Bellacosa

Durante muitos anos, o programador COBOL era visto como alguém responsável apenas por arquivos sequenciais, relatórios batch e transações CICS.

JSON GENERATE mudou essa percepção.

Ele permitiu que sistemas escritos décadas atrás começassem a responder chamadas REST, conversar com aplicativos móveis, participar do Open Finance e integrar-se naturalmente a arquiteturas modernas baseadas em APIs.

Talvez essa seja uma das maiores virtudes do Enterprise COBOL.

Ele não exige que o desenvolvedor abandone tudo aquilo que aprendeu.

Ele simplesmente acrescenta novas habilidades.

E diz ao Padawan:

Continue usando seus níveis 01, 05 e 10.

Continue escrevendo programas robustos.

Continue confiando na estabilidade do IBM Z.

Eu apenas ensinarei seu código a responder em uma linguagem compreendida por praticamente toda a galáxia digital.


Continua na Parte 4

JSON Jedi Master – z/OS Connect, MQ, Kafka, OpenShift, APIs de Alto Desempenho, Segurança OWASP e Técnicas Avançadas para o Mestre Bellacosa do IBM Z.

sábado, 7 de setembro de 2024

JSON em COBOL no IBM Z: O Holocron das APIs Modernas – JSON PARSE - Parte II

 

Bellacosa Mainframe e o json no cobol parte II

JSON em COBOL no IBM Z: O Holocron das APIs Modernas

Parte 2 – JSON PARSE

Quando o Padawan Aprende a Transformar Texto em Estruturas COBOL

Por Bellacosa Mainframe


"JSON é apenas texto. O verdadeiro poder está em fazer COBOL compreender esse texto como se fosse uma estrutura nativa do IBM Z."

Mestre Bellacosa Sysprog Jedi


Introdução

Na Parte 1, o Padawan descobriu algo surpreendente.

COBOL moderno fala JSON.

Aprendemos:

  • JSON GENERATE

  • UTF-8

  • CCSID

  • Enterprise COBOL 6.x

  • APIs REST

  • JSON em memória

  • Segurança básica

Agora chegamos ao momento em que o programa COBOL deixa de apenas produzir JSON.

Ele começa a entender JSON.

E isso acontece através de uma instrução quase mágica.

JSON PARSE


O que é JSON PARSE?

JSON PARSE é o tradutor universal.

Ele recebe.

Texto.

Transforma.

Em estruturas COBOL.


Visualmente.

JSON


↓

JSON PARSE


↓

WORKING STORAGE


↓

Programa COBOL

Exemplo.

Recebemos.

{
"id":100,

"nome":"Bellacosa",

"idade":52
}

COBOL deseja.

01 CLIENTE.

05 ID.

PIC 9(5).


05 NOME.

PIC X(30).


05 IDADE.

PIC 999.

JSON PARSE faz isso.

Automaticamente.


Quando surgiu?

IBM introduziu.

JSON PARSE

Enterprise COBOL

Version 6.


Mais utilizado hoje.

6.3

6.4

6.5


Mudou completamente.

Integrações.


Primeiro programa JSON PARSE

Passo 1

Estrutura COBOL

01 WS-CLIENTE.


05 WS-ID.
PIC 9(5).


05 WS-NOME.
PIC X(30).


05 WS-IDADE.
PIC 999.

Passo 2

Buffer JSON

01 WS-JSON.

PIC X(500).

Passo 3

Popular

MOVE

'{"id":100,

"nome":"Bellacosa",

"idade":52}'


TO WS-JSON

Passo 4

Parse

JSON PARSE

WS-JSON

INTO WS-CLIENTE

Passo 5

Display

DISPLAY WS-ID.


DISPLAY WS-NOME.


DISPLAY WS-IDADE.

Resultado.

100


Bellacosa


52

Pronto.

JSON virou COBOL.


O que acontece internamente?

Compilador cria.

Parser interno.


Percorre.

Caractere.

Por caractere.


Reconhece.

Chaves.

Aspas.

Números.

Vetores.


Mapeia.

Campos.


Visualmente.

{


"id"



100



}


↓

COBOL


ID=100

Como funciona na memória?

JSON continua sendo texto.


Exemplo.

Buffer


500 bytes

Parser lê.


Move dados.


Para.

Working Storage.


Resultado.

WS-ID


100



WS-NOME


Bellacosa

Sem ponteiros.

Sem árvore.

Sem DOM.


Muito eficiente.


Objetos Aninhados

JSON suporta.

Estruturas.

Dentro.

De estruturas.


Exemplo.

{

"cliente":{

"id":1,

"nome":"Bellacosa"

}

}

COBOL.

01 CLIENTE.


05 DADOS.


10 ID.


10 NOME.

Muito elegante.


Arrays

Chegamos.

Ao lado divertido.


JSON.

{

"telefones":[

"1111",

"2222"

]

}

COBOL.

05 TELEFONES.

10 TEL OCCURS 10.


15 NUMERO.


PIC X(20).

Parser.

Preenche.


COUNT IN

Muito útil.


Exemplo.

JSON PARSE

WS-JSON


INTO WS-DADOS


COUNT IN WS-CONTADOR

Retorna.

Quantidade.

Itens.


Excelente.

Para.

Arrays.


ON EXCEPTION

Fundamental.

Nunca esquecer.


Exemplo.

JSON PARSE

WS-JSON


INTO WS-CLI


ON EXCEPTION


DISPLAY 'ERRO'

Padawan.

Sempre use.


Exemplo inválido

JSON.

{


"id":100


"nome":"Bellacosa"

Aspa.

Faltando.


Parser.

Falha.


ON EXCEPTION.

Executado.


JSON Malicioso

Poucos falam.

Mas existe.


Payload.

Gigante.


Exemplo.

50 MB.


Consome.

CPU.


Memória.


Tempo.


DoS.


Negação.

Serviço.


Boa prática

Validar.

Tamanho.


Exemplo.

IF WS-LEN > 100000

DISPLAY 'ERRO'

Muito recomendado.


Nomes diferentes

JSON.

Pode vir.

{

"customer_name":"Bellacosa"

}

COBOL.

05 WS-NOME.

Problema.


Precisamos.

Mapear.


Enterprise COBOL possui.

NAME OF.

SUPPRESS.


Falaremos.

Parte 3.


UTF8

Grande inimigo.


JSON.

UTF8.


COBOL.

EBCDIC.


José.

Pode quebrar.


Ç.

Ã.

É.


Atenção.

Sempre.


JSON NULL

JSON.

{


"nome":null
}

COBOL.

Não possui.

Null textual.


Precisamos.

Tratar.


Muito importante.


Performance

Excelente.


JSON PARSE.

É compilado.


Muito rápido.


Melhor.

Que parser.

Manual.


Evite.

UNSTRING


INSPECT


STRING

Desnecessário.


JSON PARSE.

Resolve.


Curiosidades

Muitos bancos.

Recebem.

Milhões.

JSON.

Por dia.


Aplicativos.

PIX.

Cartão.

Open Finance.


Tudo passa.

Por.

JSON.


E em muitos casos.

Existe.

COBOL.

No fim.

Da cadeia.


Debug

Exemplo.

DISPLAY WS-JSON

Muito útil.


Ou.

IBM Debug Tool.


Fault Analyzer.


Dump.


Quando usar?

Excelente.

REST

MQ

Kafka

zOS Connect

Mobile

Open Banking

PIX

Cloud


Quando evitar?

Arquivos internos.


VSAM.


Relatórios.


Batch tradicional.


Bellacosa Best Practices

Sempre

Use ON EXCEPTION


Sempre

Validar tamanho


Sempre

Testar UTF8


Sempre

Documentar JSON


Sempre

Versionar APIs


O Conselho do Mestre Bellacosa

JSON PARSE é provavelmente uma das maiores evoluções já incorporadas ao Enterprise COBOL.

Ele permite que um programa escrito há vinte ou trinta anos compreenda payloads produzidos por smartphones, microsserviços, plataformas OpenShift e aplicações espalhadas pela Internet.

O jovem Padawan deve perceber uma verdade importante.

JSON continua sendo apenas texto.

Mas JSON PARSE transforma esse texto em algo que COBOL entende profundamente.

Estruturas.

Campos.

Vetores.

Níveis.

OCCURS.

Variáveis.

E talvez essa seja a maior beleza do IBM Z moderno.

Ele não exige que o desenvolvedor abandone décadas de conhecimento.

Ele apenas oferece novas ferramentas.

E diz:

Continue programando em COBOL.

Continue usando seus níveis 01, 05 e 10.

Continue confiando em sua experiência.

Eu apenas ensinarei ao seu programa a compreender uma nova linguagem falada por toda a galáxia digital.


Continua na Parte 3

JSON GENERATE – Quando o Padawan Aprende a Construir APIs REST com COBOL, Criar Payloads Elegantes, Controlar Campos, Suprimir Dados e Falar com Microsserviços do Futuro.


quinta-feira, 18 de julho de 2024

JSON em COBOL no IBM Z: O Holocron das APIs Modernas – O Despertar do JSON - Parte I

 

Bellacosa Mainframe e o json no cobol parte I

JSON em COBOL no IBM Z: O Holocron das APIs Modernas

Parte 1 – O Despertar do JSON

Quando o Padawan Descobre que COBOL Pode Falar a Linguagem das APIs

Por Bellacosa Mainframe


"Por décadas, COBOL falou VSAM, DB2, IMS e MQ. Hoje ele também conversa com APIs, microsserviços e nuvens distantes. O idioma escolhido pela galáxia moderna chama-se JSON."

Mestre Bellacosa Sysprog Jedi


Introdução

Durante muitos anos, a vida do desenvolvedor COBOL era relativamente previsível.

Ele acordava.

Abria o ISPF.

Editava um programa.

Fazia um READ em um VSAM.

Consultava um DB2.

Chamava um CICS.

Enviava uma mensagem MQ.

Executava o JOB.

Analisava o SDSF.

E ia tomar café.

Então, por volta da década de 2010, uma nova criatura começou a aparecer nas especificações técnicas.

Ela vinha acompanhada de nomes estranhos.

REST.

OpenAPI.

Swagger.

Microservices.

Kubernetes.

OpenShift.

APIs.

Mobile.

Cloud.

E no meio de tudo isso, um pequeno formato textual se tornou praticamente o idioma universal da integração moderna.

Seu nome era:

JSON

(JavaScript Object Notation)

E então o jovem Padawan COBOL perguntou:

Mestre...

Quer dizer que meu programa COBOL de 30 anos pode conversar com um aplicativo Android?

Pode responder uma API REST?

Pode enviar dados para um microsserviço em OpenShift?

Pode participar de uma arquitetura moderna?

O mestre sorri.

Olha para o IBM z17.

E responde:

Sim.

E o idioma utilizado para essa conversa provavelmente será JSON.


O que é JSON?

JSON significa:

JavaScript Object Notation.

Mas não se deixe enganar pelo nome.

Hoje JSON pertence ao mundo inteiro.

Não é apenas JavaScript.

É utilizado por:

  • COBOL

  • Java

  • Python

  • Go

  • Rust

  • Node.js

  • C#

  • Kotlin

  • Swift

  • APIs REST

  • OpenShift

  • Kafka

  • IBM MQ

  • z/OS Connect

Praticamente tudo.


Exemplo simples

Um cliente.

Em COBOL.

Temos:

01 WS-CLIENTE.

   05 WS-ID.

      PIC 9(5).

   05 WS-NOME.

      PIC X(30).

   05 WS-IDADE.

      PIC 999.

Em JSON.

{
  "id":100,
  "nome":"Bellacosa",
  "idade":52
}

Mesmo dado.

Representações diferentes.


Por que JSON venceu XML?

Muitos veteranos perguntam:

Mestre...

Mas XML não fazia isso antes?

Sim.

Fazia.

E ainda faz.

Mas JSON trouxe algumas vantagens.


XML

<cliente>

<id>100</id>

<nome>Bellacosa</nome>

</cliente>

JSON

{
"id":100,
"nome":"Bellacosa"
}

Menor.

Mais leve.

Mais rápido.

Mais amigável.


JSON chegou tarde ao COBOL?

Sim.

Durante muitos anos, programadores precisavam utilizar:

Parsers.

Ferramentas externas.

Java.

C.

SAX.

DOM.

Bibliotecas proprietárias.

Era desagradável.


Quando surgiu suporte nativo?

IBM introduziu suporte moderno em:

Enterprise COBOL V6

Especialmente.

COBOL 6.1

6.2

6.3

6.4

6.5


Duas instruções mudaram tudo.

JSON PARSE

JSON GENERATE

Essas duas instruções transformaram COBOL em um cidadão de primeira classe no universo das APIs.


O que é JSON PARSE?

É o tradutor.

Recebe texto.

Produz estruturas COBOL.


Visualmente.

JSON


↓

JSON PARSE


↓

WORKING STORAGE

O que é JSON GENERATE?

Faz o contrário.

WORKING STORAGE


↓

JSON GENERATE


↓

Texto JSON

Primeiro exemplo do Padawan

Passo 1

Criar estrutura.

01 WS-CLIENTE.

   05 WS-ID.

      PIC 9(5).

   05 WS-NOME.

      PIC X(30).

   05 WS-IDADE.

      PIC 999.

Passo 2

Criar buffer.

01 WS-JSON.

PIC X(200).

Passo 3

Popular dados.

MOVE 100

TO WS-ID


MOVE 'BELLACOSA'

TO WS-NOME


MOVE 52

TO WS-IDADE

Passo 4

Gerar JSON.

JSON GENERATE WS-JSON

FROM WS-CLIENTE

Passo 5

Display.

DISPLAY WS-JSON

Resultado.

{
"id":100,
"nome":"BELLACOSA",
"idade":52
}

Pronto.

COBOL falando JSON.


Como funciona internamente?

Aqui começa a magia.

O compilador gera código otimizado.

Percorre estrutura COBOL.

Mapeia campos.

Converte.

Monta texto.

Tudo automaticamente.


Visualmente.

WORKING STORAGE


↓

Field Scanner


↓

Serializer


↓

UTF-8


↓

JSON Buffer

Como JSON fica na memória?

JSON é texto.

Normalmente.

UTF-8.


Exemplo.

{"nome":"Bellacosa"}

Na memória.

7B

22

6E

6F

6D

65

Bytes.


CCSID

Muito importante.

Padawan frequentemente esquece.

IBM Z trabalha com:

EBCDIC.

JSON trabalha com:

UTF-8.


Complicação.


Exemplo.

COBOL.

EBCDIC

API.

UTF8

Conversão necessária.


Exemplo

Nome.

José


UTF8.

Dois bytes.


EBCDIC.

Outro código.


Pode quebrar.


Segurança

Muito importante.

JSON pode ser perigoso.


Exemplo.

Payload enorme.

{
"clientes":[

100000 itens

]
}

Pode consumir.

CPU.

Memória.

Tempo.


Boa prática.

Validar tamanho.


JSON Injection

Também existe.


Nunca confiar.

Em entrada.

Externa.


Sempre validar.


Arrays

JSON suporta.

{
"clientes":[

{"id":1},

{"id":2}

]
}

COBOL.

OCCURS.


Excelente integração.


Objetos aninhados

{
"cliente":{

"id":1,

"endereco":{

"cidade":"SP"

}

}
}

COBOL.

Níveis.


Muito elegante.


Curiosidade

JSON PARSE.

Não cria ponteiros.

Não cria DOM.

Não cria árvore.


Preenche estruturas COBOL.

Diretamente.


Extremamente eficiente.


Performance

Muito boa.


JSON GENERATE.

É rápido.


Muito mais rápido.

Do que escrever.

String manualmente.


Exemplo ruim.

STRING

'{'

'"nome":"'

WS-NOME

'"'

'}'

Terrível.


JSON GENERATE.

Melhor.


Quando usar?

Excelente para.


APIs.

REST.

MQ.

Kafka.

OpenShift.

Mobile.

Cloud.

Microsserviços.


Quando evitar?


Arquivos internos.

VSAM.

Batch puro.

Relatórios.


Curiosidade Bellacosa

Muitos programas COBOL modernos já trabalham com JSON diariamente.

E boa parte dos usuários finais jamais imagina.

Ao abrir um aplicativo bancário.

Consultar saldo.

Fazer PIX.

Solicitar empréstimo.

Atualizar cadastro.

Frequentemente existe um programa COBOL recebendo JSON silenciosamente em algum lugar do IBM Z.


O Conselho do Mestre Bellacosa

Durante décadas, COBOL foi visto como uma linguagem presa a cartões perfurados, arquivos sequenciais e relatórios impressos.

JSON mudou essa percepção.

JSON permitiu que programas escritos há décadas conversassem com aplicações móveis, microsserviços em OpenShift, APIs em nuvem e plataformas digitais espalhadas pela galáxia tecnológica.

E talvez essa seja a maior lição desta primeira jornada.

COBOL não precisou deixar de ser COBOL.

Não precisou abandonar sua robustez.

Não precisou reescrever milhões de linhas.

Ele simplesmente aprendeu um novo idioma.

E hoje pode dizer:

Eu ainda sou COBOL.

Ainda processo milhões de transações por segundo.

Ainda executo no IBM Z.

Mas agora também falo JSON.

E posso conversar com praticamente qualquer sistema da galáxia.


Continua na Parte 2

JSON PARSE – Transformando Texto em Estruturas COBOL: Arrays, Objetos Aninhados, OCCURS, Tratamento de Erros e o Lado Sombrio dos Payloads Maliciosos.


quarta-feira, 1 de maio de 2024

☕💣 OPERADOR, O TRELLO ACABOU DE RECEBER ORDENS DE UM AGENTE PYTHON! — Construindo um Organizador Inteligente de Tarefas do Zero e Entendendo Como Nasce um Agente de IA

Bellacosa Mainframe crie um agente organizador Trello com o Python


☕💣 OPERADOR, O TRELLO ACABOU DE RECEBER ORDENS DE UM AGENTE PYTHON! — Construindo um Organizador Inteligente de Tarefas do Zero e Entendendo Como Nasce um Agente de IA

Imagine a seguinte cena.

São 2 horas da manhã.

O operador monitora dezenas de sistemas.

Há tarefas para acompanhar, chamados para abrir, solicitações para registrar, atividades para priorizar e uma equipe inteira esperando informações.

De repente surge uma pergunta:

"Por que ainda estamos criando tarefas manualmente?"

Foi exatamente essa pergunta que levou ao nascimento dos primeiros sistemas de automação, dos workflows corporativos e, mais recentemente, dos Agentes de Inteligência Artificial.

Hoje vamos construir um projeto extremamente importante para quem está entrando no universo dos agentes: um Organizador de Tarefas em Python integrado ao Trello.

Mas não vamos apenas escrever código.

Vamos entender arquitetura, dependências, APIs, tratamento de erros, segurança, evolução para IA e como tudo isso se conecta ao mundo corporativo e até ao universo Mainframe.

Pegue seu café.

O job acabou de entrar na fila.


O Que Estamos Construindo?

Nosso projeto será um agente capaz de:

  • Conectar-se ao Trello

  • Criar tarefas automaticamente

  • Consultar tarefas existentes

  • Mover tarefas entre listas

  • Organizar fluxos de trabalho

  • Servir como base para futuros agentes inteligentes

Visualmente teremos algo assim:

Python Agent
      ↓
API REST
      ↓
Trello
      ↓
Cards
      ↓
Workflow

Parece simples.

Mas essa mesma arquitetura é utilizada em:

  • Jira

  • ServiceNow

  • Salesforce

  • SAP

  • Zendesk

  • GitHub

  • Azure DevOps

E até em plataformas de automação como N8N.


O Que é um Agente?

Muita gente acredita que um agente é sinônimo de IA.

Não necessariamente.

Um agente é um software que:

  • Observa

  • Analisa

  • Decide

  • Executa

Nosso primeiro agente ainda não terá inteligência artificial.

Mas ele já será capaz de agir sozinho.

Isso é exatamente o primeiro estágio da evolução.


O Trello Como Ambiente de Trabalho

Antes de escrever uma linha de código precisamos preparar o Trello.

Crie uma conta.

Depois crie um Board.

Exemplo:

Projeto DIO

Agora crie três listas:

To Do

Doing

Done

Quem já trabalhou com Kanban reconhecerá imediatamente o modelo.

O fluxo é simples:

Pendente
    ↓
Executando
    ↓
Concluído

Obtendo as Credenciais

Assim como um terminal CICS exige autenticação, a API do Trello também exige.

Você precisará obter:

  • API Key

  • API Token

Essas informações funcionam como usuário e senha para seu agente.

Sem elas o Trello recusará todas as solicitações.


Instalando o Python

Verifique a instalação:

python --version

ou

python3 --version

Resultado esperado:

Python 3.10+

Se aparecer erro:

python não é reconhecido

Significa que o Python não está instalado ou não foi adicionado ao PATH.


Criando o Ambiente Virtual

Uma das melhores práticas modernas.

Crie:

python -m venv venv

Ative:

Windows

venv\Scripts\activate

Linux

source venv/bin/activate

Quando ativado:

(venv)

aparecerá antes do prompt.


Instalando Dependências

Nosso agente precisa conversar com APIs.

Instalaremos:

pip install requests python-dotenv

Essas bibliotecas possuem funções importantes.

Requests:

Consumir APIs REST

Dotenv:

Carregar variáveis seguras

Estrutura do Projeto

Organização é fundamental.

Criamos:

agente_trello/

├── app.py
├── trello.py
├── view.py
├── .env
├── requirements.txt
└── README.md

Observe que estamos separando responsabilidades.

Essa é uma prática muito valorizada em ambientes corporativos.


O Papel do app.py

Ele funciona como o maestro.

Controla:

  • Menus

  • Fluxo principal

  • Chamadas ao agente

Em Mainframe seria semelhante ao programa principal que coordena outros módulos.


O Papel do trello.py

Aqui fica toda a comunicação com a API.

Esse módulo:

  • Cria Cards

  • Consulta Cards

  • Move Cards

  • Testa conexão

Em uma analogia com COBOL:

Programa Principal
      ↓
Sub-rotina de acesso
      ↓
Banco/API

O Papel do view.py

Responsável pela apresentação.

Separar interface da lógica é uma prática extremamente importante.

Isso permite futuramente trocar:

Terminal

por

Web

ou

Dashboard

sem alterar a lógica do agente.


Variáveis de Ambiente

Nunca coloque credenciais no código.

Use:

TRELLO_KEY=
TRELLO_TOKEN=
TODO_ID=
DOING_ID=
DONE_ID=

Isso protege informações sensíveis.

É o equivalente moderno de esconder senhas em datasets protegidos por RACF.


Primeiro Teste

Execute:

python app.py

Escolha:

1 - Testar conexão

Se tudo estiver correto:

Conexão OK

Problemas Comuns

Erro 401

Unauthorized

Significa:

  • Token inválido

  • Chave inválida


Erro 404

Not Found

Significa:

  • Lista inexistente

  • ID incorreto


Erro de Importação

ModuleNotFoundError

Normalmente:

pip install requests

resolve.


Criando Seu Primeiro Card

Selecione:

Criar tarefa

Digite:

Estudar Agentes

O agente enviará:

{
  "name":"Estudar Agentes"
}

para o Trello.

Resultado:

Card criado

Instantaneamente.


Listando Tarefas

O agente consulta a API.

Recebe:

[
 {
   "name":"Estudar Python"
 }
]

e exibe:

Estudar Python

Simples.

Mas extremamente poderoso.


Movendo Tarefas

Imagine:

To Do

Ao iniciar:

Doing

Ao terminar:

Done

Nosso agente realiza isso automaticamente.

Na prática ele apenas altera um identificador interno do Trello.

Mas para o usuário parece mágica.


O Que Está Acontecendo nos Bastidores?

Quando você cria um card:

Python
   ↓
HTTP POST
   ↓
API Trello
   ↓
Banco de Dados Trello
   ↓
Resposta JSON

Isso é exatamente o mesmo conceito utilizado por:

  • APIs bancárias

  • APIs governamentais

  • APIs corporativas


Transformando em um Agente Inteligente

Agora vem a parte interessante.

Suponha que uma tarefa seja criada:

Sistema parado em produção

Uma IA pode analisar.

Resultado:

Prioridade Alta

O agente decide:

Mover para Urgente

sem intervenção humana.

Nesse momento ele deixa de ser apenas automação.

Passa a tomar decisões.


Integrando OpenAI

Exemplo conceitual:

prioridade = analisar_tarefa(descricao)

Resposta:

ALTA

O agente pode então:

if prioridade == "ALTA":
    mover_para_urgente()

Agora temos comportamento inteligente.


Integrando Ollama

Nem sempre você quer depender da nuvem.

Com Ollama é possível executar modelos locais.

Exemplos:

  • Llama

  • DeepSeek

  • Mistral

Tudo rodando em sua máquina.


Integração com N8N

Imagine:

Novo E-mail
       ↓
Webhook
       ↓
N8N
       ↓
Agente Python
       ↓
Trello

Nenhum ser humano participa.

O processo inteiro acontece sozinho.


E o Mainframe?

Agora vem a parte favorita do Bellacosa.

Imagine um JOB.

BILLJOB

executa.

O agente monitora o JES2.

Detecta:

ABEND S0C7

Automaticamente:

Lê SYSOUT

Depois:

Cria Card Trello

Em seguida:

Notifica equipe

E finalmente:

Abre incidente

Tudo sozinho.

Percebe o potencial?


O Caminho da Evolução

Nível 1:

Script

Nível 2:

Automação

Nível 3:

Workflow

Nível 4:

Agente

Nível 5:

Multiagentes

É exatamente essa trilha que está sendo seguida pela indústria.


Conclusão

Muitos enxergam esse projeto apenas como um exercício simples da DIO.

Mas ele é muito mais que isso.

Você está aprendendo:

  • Python

  • APIs REST

  • Integração entre sistemas

  • Variáveis de ambiente

  • Automação

  • Arquitetura de agentes

  • Fundamentos de IA

  • Boas práticas corporativas

O Organizador de Tarefas é apenas o começo.

A mesma arquitetura pode evoluir para:

  • Assistentes corporativos

  • Agentes DevOps

  • Agentes FinOps

  • Agentes Mainframe

  • Agentes de atendimento

  • Agentes de monitoramento

E talvez, em um futuro não muito distante, você veja uma mensagem parecida com esta aparecendo no terminal:

☕💣 OPERADOR!

Detectei um problema no sistema.

Já analisei os logs.
Já consultei incidentes anteriores.
Já criei o Card no Trello.
Já notifiquei a equipe.

Deseja apenas acompanhar... ou quer que eu resolva o problema também?