Translate

Mostrar mensagens com a etiqueta Integração Mainframe. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Integração Mainframe. Mostrar todas as mensagens

segunda-feira, 29 de julho de 2019

☕🔥 APIs NO IBM MAINFRAME — O MUNDO MODERNO DESCOBRIU AGORA O QUE O z/OS JÁ FAZIA HÁ DÉCADAS

 

Bellacosa Mainframe e o uso de APIs em Mainframe

☕🔥 APIs NO IBM MAINFRAME — O MUNDO MODERNO DESCOBRIU AGORA O QUE O z/OS JÁ FAZIA HÁ DÉCADAS

Hoje o mercado fala sem parar sobre:

  • APIs

  • REST

  • GraphQL

  • gRPC

  • Event Streaming

  • Webhooks

  • Tempo real

  • Microsserviços

E muita gente imagina que isso nasceu:

  • na nuvem

  • no Kubernetes

  • no Node.js

  • no mundo cloud-native

Mas existe uma realidade histórica quase escondida:

O Mainframe sempre foi uma máquina de integração.

Muito antes do termo “API Economy” virar moda…

o IBM Mainframe já fazia:

  • comunicação distribuída

  • transações remotas

  • integração entre sistemas

  • troca de mensagens

  • processamento assíncrono

  • request/reply

  • eventos

  • streaming de dados

E talvez essa seja a parte mais impressionante:

🔥 O z/OS não apenas sobreviveu à era das APIs…
ele virou um dos pilares dela.


☕ O QUE MUITA GENTE NÃO ENTENDE SOBRE APIs

API não é “modinha web”.

API é:

contrato de comunicação.

O formato muda.

A tecnologia muda.

Mas a ideia é a mesma desde os anos 70:

  • um sistema solicita algo

  • outro sistema responde

  • existe um protocolo

  • existe um padrão

  • existe governança

E o Mainframe foi pioneiro nisso.


☕🔥 GRAPHQL NO MAINFRAME — A VOLTA DO “PEDIR SOMENTE O NECESSÁRIO”

GraphQL virou tendência porque resolve um problema clássico:

👉 excesso de dados.

O cliente pede exatamente o que quer.


☕ Mas olha a ironia…

O Mainframe já tinha essa mentalidade há décadas.


Exemplo clássico no CICS + COBOL

Uma transação antiga:

EXEC CICS LINK
     PROGRAM('CLI0001')
     COMMAREA(WS-AREA)
END-EXEC

A COMMAREA levava apenas:

  • campos específicos

  • estruturas necessárias

  • dados filtrados

Não havia desperdício.


☕ GraphQL + z/OS Connect

Hoje o Mainframe moderno usa:

  • z/OS Connect

  • API Connect

  • Db2 REST Services

para expor:

  • COBOL

  • CICS

  • IMS

  • DB2

como APIs modernas.


Exemplo real

Um app mobile pode pedir:

cliente {
  nome
  saldo
}

E o Mainframe responde apenas isso.

Sem payload gigante.


☕🔥 gRPC — O “NOVO RPC” QUE O MAINFRAME JÁ CONHECIA

Quando o mercado descobriu gRPC…

o profissional mainframe veterano provavelmente sorriu.

Porque:

👉 gRPC é basicamente a evolução moderna do RPC.

E RPC já existia no universo IBM há MUITO tempo.


☕ O que é gRPC?

Comunicação:

  • rápida

  • binária

  • eficiente

  • orientada a contratos

usando Protocol Buffers.


☕ O Mainframe fazia isso como?

APPC/LU6.2

Comunicação transacional remota.


DPL (Distributed Program Link)

Programa chama outro remotamente:

EXEC CICS LINK
     SYSID('PRD1')
END-EXEC

Isso é praticamente:

🔥 “gRPC raiz”.


☕ MQ também antecipou isso

Mensagens compactas.

Baixa latência.

Integração confiável.

Comunicação assíncrona.


☕🔥 SOAP — O REINADO ABSOLUTO DO MAINFRAME CORPORATIVO

Antes do REST dominar o mundo…

SOAP era rei absoluto.

E o Mainframe foi um dos maiores ambientes SOAP do planeta.


☕ Por quê?

Porque SOAP entrega algo que o mundo financeiro AMA:

  • contratos rígidos

  • padronização

  • WS-Security

  • governança

  • transações confiáveis

  • XML estruturado


☕ CICS Web Services

O CICS consegue expor programas COBOL como SOAP services.


Fluxo clássico

SOAP Request
     ↓
CICS Pipeline
     ↓
COBOL
     ↓
DB2 / VSAM
     ↓
SOAP Response

☕ O que pouca gente sabe

Grande parte:

  • bancos

  • seguradoras

  • governos

AINDA usam SOAP no Mainframe.

E sinceramente?

🔥 Em sistemas críticos, SOAP ainda é extremamente poderoso.


☕🔥 REST — O MAINFRAME APRENDEU A FALAR “INTERNET”

REST virou padrão porque simplifica integração.

HTTP + JSON.

Simples.

Leve.

Universal.


☕ E o Mainframe?

O Mainframe se reinventou brutalmente aqui.


☕ Hoje temos:

z/OS Connect

Transforma:

  • COBOL

  • IMS

  • CICS

em APIs REST modernas.


☕ Exemplo

Aplicação mobile faz:

GET /clientes/1001

E no backend:

  • COBOL executa

  • DB2 consulta

  • CICS processa

O usuário nem percebe que existe um z/OS por trás.


☕ O REST ajudou o Mainframe a sobreviver

Essa talvez seja uma das maiores viradas históricas do IBM Z.

REST permitiu:

  • integração com cloud

  • apps mobile

  • fintechs

  • Open Banking

  • microsserviços

  • APIs públicas


☕🔥 WEBHOOKS — O MAINFRAME SEMPRE VIVEU DE EVENTOS

Webhook é:

“me avise quando algo acontecer”.


☕ Parece moderno…

Mas o Mainframe já vivia disso.


☕ Exemplos clássicos

WTO/WTOR

Mensagens do sistema disparam ações.


Automation

NetView e System Automation executam workflows baseados em eventos.


MQ Triggering

Fila recebe mensagem → programa inicia automaticamente.

Isso é Webhook conceitualmente.


☕ Exemplo real

Pagamento aprovado:

MQ Message
   ↓
Trigger
   ↓
COBOL Batch
   ↓
Atualização DB2
   ↓
Notificação externa

Event-driven desde antes do termo existir.


☕🔥 SSE (SERVER-SENT EVENTS) — O MAINFRAME SEMPRE AMOU STREAMING

SSE mantém conexão aberta enviando eventos contínuos.

Hoje isso aparece em:

  • dashboards

  • monitoring

  • fintechs

  • trading

  • observabilidade


☕ Mas o Mainframe já fazia streaming há décadas

SMF

Fluxo contínuo de eventos do sistema.


RMF

Monitoramento em tempo real.


OMEGAMON

Streaming operacional contínuo.


☕ Ambientes financeiros usam isso intensamente

Bolsa de valores.

Cartões.

PIX.

Fraude.

Monitoramento de transações.

Tudo depende de fluxo contínuo.


☕🔥 O GRANDE CHOQUE CULTURAL

O mercado moderno acha que inventou:

  • integração

  • APIs

  • eventos

  • streaming

  • observabilidade

Mas o Mainframe já enfrentava esses problemas:

  • nos anos 70

  • nos anos 80

  • nos anos 90

em escala absurda.


☕ O QUE MUDA É O FORMATO

Ontem:

  • SNA

  • APPC

  • MQ

  • CICS LINK

  • COMMAREA

Hoje:

  • REST

  • GraphQL

  • gRPC

  • Kafka

  • Webhooks

Mas a essência continua a mesma:

🔥 sistemas precisam conversar de forma confiável.


☕🔥 O MAIOR MITO SOBRE O MAINFRAME

“Mainframe não conversa com sistemas modernos.”

Isso está completamente errado.

Hoje o IBM Z conversa com:

  • AWS

  • Azure

  • Kubernetes

  • OpenShift

  • APIs REST

  • Kafka

  • aplicações mobile

  • IA generativa

E faz isso mantendo:

  • segurança absurda

  • disponibilidade 24x7

  • integridade transacional

  • throughput gigantesco


☕🔥 A VERDADE QUE O MERCADO COMEÇA A REDESCOBRIR

Quanto mais o mundo moderno cresce…

mais ele percebe a importância de:

  • resiliência

  • observabilidade

  • governança

  • transação confiável

  • mensageria robusta

  • integração desacoplada

E adivinha?

👉 Esses sempre foram pilares do Mainframe.


☕🔥 CONCLUSÃO — O MAINFRAME NÃO FICOU PARA TRÁS

Ele apenas:

evoluiu antes dos outros.

REST, GraphQL, gRPC e Webhooks não substituíram o Mainframe.

Eles se conectaram a ele.

Porque no fim das contas…

🔥 quase todo sistema moderno ainda acaba conversando com um IBM Z em algum momento da vida.


quarta-feira, 25 de abril de 2018

☕🔥 API PROTOCOLS NO IBM MAINFRAME — ENQUANTO O MUNDO DISCUTIA “MICROSSERVIÇOS”, O z/OS JÁ PROCESSAVA O PLANETA EM TEMPO REAL

Bellacosa Mainframe e uma visão das api protocols


☕🔥 API PROTOCOLS NO IBM MAINFRAME — ENQUANTO O MUNDO DISCUTIA “MICROSSERVIÇOS”, O z/OS JÁ PROCESSAVA O PLANETA EM TEMPO REAL

Existe uma frase que resume perfeitamente a história da integração corporativa:

“Toda tecnologia moderna acaba redescobrindo algo que o Mainframe já fazia.”

Hoje o mercado vive cercado de siglas:

  • REST

  • GraphQL

  • SOAP

  • gRPC

  • MQTT

  • WebSockets

  • SSE

  • EDA

  • AMQP

  • Webhooks

E muita gente acredita que isso nasceu:

  • na cloud

  • no Kubernetes

  • nas startups

  • no mundo DevOps

Mas existe uma verdade quase chocante:

🔥 O IBM Mainframe já dominava integração distribuída quando muita dessas tecnologias nem existia.


☕ O MAINFRAME NUNCA FOI “ISOLADO”

Esse talvez seja o maior mito da computação.

Muita gente imagina o Mainframe como:

  • terminal verde

  • sistema fechado

  • ambiente monolítico

  • tecnologia presa ao passado

Só que historicamente o Mainframe SEMPRE foi:

✅ distribuído
✅ integrado
✅ orientado a mensagens
✅ orientado a eventos
✅ transacional
✅ resiliente

Na prática:

👉 o Mainframe foi um dos primeiros grandes “hubs de APIs” corporativas do mundo.


☕🔥 REST — O MAINFRAME APRENDEU A FALAR A LÍNGUA DA INTERNET

REST virou padrão mundial porque simplifica comunicação.

HTTP + JSON.

Simples.

Universal.


☕ Mas veja a ironia…

O Mainframe já fazia integração transacional décadas antes.


☕ Hoje o z/OS usa REST via:

  • z/OS Connect

  • CICS REST APIs

  • Db2 REST Services

  • API Connect

  • OpenShift APIs


☕ Exemplo real

Aplicativo mobile:

GET /contas/1001

☕ O que acontece por trás?

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

Tudo em milissegundos.


☕ O usuário nem percebe

Ele acha que está falando com:

  • cloud

  • microservice

  • fintech moderna

Mas no fundo:

🔥 existe um COBOL no z/OS processando bilhões com segurança absurda.


☕🔥 GRAPHQL — O MAINFRAME SEMPRE DETESTOU DESPERDÍCIO

GraphQL nasceu para resolver:

  • excesso de dados

  • APIs gigantes

  • múltiplas consultas


☕ O conceito é moderno…

Mas a mentalidade é antiga no Mainframe.


☕ COMMAREA no CICS já fazia isso

EXEC CICS LINK
     PROGRAM('CLI001')
     COMMAREA(WS-AREA)
END-EXEC

Somente os campos necessários eram enviados.

Nada de payload gigantesco.


☕ Hoje com GraphQL + DB2

Apps conseguem pedir:

cliente {
   nome
   saldo
}

E o Mainframe retorna exatamente isso.


☕🔥 SOAP — O IMPÉRIO CORPORATIVO QUE O MAINFRAME AJUDOU A CONSTRUIR

Antes do REST…

SOAP era rei absoluto.

E honestamente?

🔥 Em ambientes críticos ele ainda é extremamente forte.


☕ Por quê?

Porque SOAP entrega:

  • contratos rígidos

  • segurança avançada

  • WS-Security

  • governança

  • auditoria

  • confiabilidade


☕ O Mainframe amava isso

Porque bancos e governos PRECISAM disso.


☕ CICS Web Services

Transforma COBOL em serviço SOAP.


☕ Fluxo clássico

SOAP Request
   ↓
CICS Pipeline
   ↓
COBOL
   ↓
DB2
   ↓
SOAP Response

☕ Muitos sistemas financeiros ainda vivem disso

E continuam funcionando perfeitamente.


☕🔥 gRPC — O “RPC MODERNO” QUE O MAINFRAME JÁ CONHECIA

O mercado moderno descobriu:

  • baixa latência

  • comunicação binária

  • chamadas remotas rápidas

e chamou isso de gRPC.


☕ O Mainframe olha e responde:

“Nós já fazíamos isso.”


☕ APPC/LU6.2

Comunicação remota transacional.


☕ DPL (Distributed Program Link)

EXEC CICS LINK
     SYSID('PRD1')
END-EXEC

Programa remoto chamado como se fosse local.

Isso é praticamente:

🔥 gRPC ancestral.


☕🔥 WEBSOCKET — O MAINFRAME SEMPRE GOSTOU DE CONEXÃO PERSISTENTE

WebSocket permite:

  • comunicação bidirecional

  • conexão contínua

  • baixa latência


☕ Isso é perfeito para:

  • trading

  • PIX

  • monitoramento

  • dashboards

  • antifraude


☕ E o Mainframe?

Sempre viveu de sessões persistentes.


☕ VTAM e sessões SNA

Mantinham conexões contínuas décadas antes do WebSocket.


☕ Hoje o z/OS usa isso com:

  • APIs realtime

  • Open Banking

  • streaming financeiro

  • integração cloud


☕🔥 WEBHOOKS — O MAINFRAME SEMPRE FOI EVENT-DRIVEN

Webhook significa:

“me avise quando algo acontecer”.


☕ Parece moderno.

Mas o Mainframe vive disso desde os anos 70.


☕ MQ Triggering

Mensagem chega na fila:

MQ
 ↓
Trigger
 ↓
Programa COBOL inicia

Isso é praticamente um webhook corporativo.


☕ WTO/WTOR também

Eventos operacionais disparam ações automáticas.


☕🔥 EDA — EVENT DRIVEN ARCHITECTURE

Agora chegamos numa parte fascinante.

O mercado moderno fala de:

  • Kafka

  • Event Bus

  • Streaming

  • Async Systems

como se fosse novidade absoluta.


☕ Mas o Mainframe sempre viveu de eventos

Exemplos clássicos

  • MQ

  • CICS transient data

  • SMF

  • JES2 messages

  • RACF alerts

  • NetView automation

Tudo baseado em eventos.


☕ O Mainframe é naturalmente orientado a eventos

Porque em sistemas críticos:

🔥 reagir rápido é sobrevivência.


☕🔥 SSE — STREAMING CONTÍNUO NO DNA DO z/OS

Server-Sent Events enviam dados continuamente.


☕ O Mainframe já fazia isso há décadas

OMEGAMON

Streaming operacional contínuo.


RMF

Métricas em tempo real.


SMF

Fluxo permanente de eventos do sistema.


☕ Ambientes financeiros usam isso brutalmente

  • monitoramento

  • fraude

  • observabilidade

  • auditoria

  • analytics em tempo real


☕🔥 MQTT — O MAINFRAME ENCONTROU A IoT

MQTT domina:

  • sensores

  • IoT

  • dispositivos leves


☕ E o Mainframe?

Hoje ele processa eventos vindos de:

  • caixas eletrônicos

  • POS

  • sensores industriais

  • dispositivos bancários

  • telemetria


☕ IBM MQ facilita isso

MQTT → MQ → z/OS.


☕ O Mainframe virou cérebro central de IoT corporativa

Sim.

Isso realmente existe.


☕🔥 AMQP — O ESPÍRITO DO MQ ESTAVA NA FRENTE DO TEMPO

AMQP formalizou mensageria aberta.

Mas o IBM MQ já fazia:

  • persistência

  • roteamento

  • filas

  • entrega garantida

  • transação

há muito tempo.


☕ IBM MQ É UMA LENDA CORPORATIVA

Porque resolve algo extremamente difícil:

🔥 comunicação confiável entre sistemas gigantescos.


☕🔥 EDI — O “PROTOCOLO INVISÍVEL” QUE MOVE O COMÉRCIO MUNDIAL

Muita gente jovem nunca ouviu falar em EDI.

Mas ele ainda move:

  • logística

  • indústria

  • bancos

  • supply chain

  • varejo mundial


☕ E onde ele sempre foi fortíssimo?

👉 No Mainframe.


☕ Exemplo

Pedido eletrônico:

Empresa A
   ↓
EDI
   ↓
Mainframe
   ↓
ERP
   ↓
Faturamento

Décadas funcionando.


☕🔥 A GRANDE VERDADE QUE O MERCADO ESTÁ REDESCOBRINDO

Quanto mais o mundo cresce…

mais ele percebe que integração corporativa exige:

  • confiabilidade

  • resiliência

  • auditoria

  • governança

  • throughput

  • segurança

E isso sempre foi território natural do Mainframe.


☕🔥 O FUTURO NÃO É “MAINFRAME vs CLOUD”

Esse pensamento morreu.

O futuro é:

Cloud
  +
APIs
  +
Eventos
  +
Mainframe

☕ O IBM Z virou peça central da arquitetura híbrida

Hoje ele conversa com:

  • Kubernetes

  • OpenShift

  • AWS

  • Azure

  • Kafka

  • APIs REST

  • IA generativa

  • microsserviços

sem abandonar:

🔥 estabilidade absurda.


☕🔥 CONCLUSÃO — O MUNDO MODERNO NÃO SUBSTITUIU O MAINFRAME

Ele apenas:

começou finalmente a conversar com ele da forma correta.

REST, GraphQL, MQTT, gRPC e WebSockets não aposentaram o z/OS.

Na verdade…

🔥 eles transformaram o Mainframe no coração silencioso da integração mundial.


terça-feira, 9 de junho de 2015

☕🔥 LABORATÓRIO PRÁTICO — IBM Integration Bus (Broker) Integrando COBOL/MQ com JSON REST

 

Bellacosa Mainframe e o laboratorio de ibm integration bus (broker)


☕🔥 LABORATÓRIO PRÁTICO — IBM Integration Bus (Broker) Integrando COBOL/MQ com JSON REST

Este laboratório simula um cenário REAL de mercado:

Um sistema COBOL no mainframe envia uma mensagem MQ em formato legado, e o IBM Integration Bus (IIB/ACE) transforma tudo em JSON para APIs modernas.

Você aprenderá:

✅ fluxo completo
✅ MQ Input
✅ transformação EBCDIC/Copybook → JSON
✅ ESQL
✅ Message Flow
✅ deploy
✅ testes
✅ troubleshooting


🎯 CENÁRIO DO LAB

Sistema legado (Mainframe)

Envia:

000123JOAO      0000500

Formato:

  • posição fixa

  • padrão COBOL

  • MQ


Broker/IIB/ACE

Recebe:

  • MQ Queue

Transforma:

  • fixed length

  • copybook lógico

  • JSON

Entrega:

  • API REST

  • ou outra fila MQ


🏗️ ARQUITETURA

COBOL Batch/CICS
       ↓
     IBM MQ
       ↓
 MQINPUT NODE
       ↓
 COMPUTE NODE (ESQL)
       ↓
 JSON OUTPUT
       ↓
HTTP/MQ/API

📦 PASSO 1 — PREPARAR O AMBIENTE

Você precisará:

ComponenteFunção
IBM MQMensageria
IBM ACE/IIBIntegração
ToolkitDesenvolvimento
Queue ManagerFilas
MQ ExplorerAdministração

📌 FILAS DO LAB

Entrada

LAB.INPUT

Saída

LAB.OUTPUT

⚙️ PASSO 2 — CRIAR AS FILAS MQ

Script MQSC

DEFINE QLOCAL(LAB.INPUT)
DEFINE QLOCAL(LAB.OUTPUT)

▶️ EXECUTAR

Linux:

runmqsc QM1 < filas.mqsc

Windows:

runmqsc QM1

Cole os comandos.


🔥 PASSO 3 — CRIAR O PROJETO NO ACE TOOLKIT

Novo Application

File → New → Application

Nome:

LAB_MAINFRAME_JSON

🔥 PASSO 4 — CRIAR MESSAGE FLOW

Novo Message Flow

MF_MAINFRAME_JSON

🧩 PASSO 5 — ADICIONAR NODES

Arraste:

NodeFunção
MQInputReceber MQ
ComputeTransformar
MQOutputEnviar saída

🔗 CONECTAR

MQInput → Compute → MQOutput

⚙️ PASSO 6 — CONFIGURAR MQINPUT

Queue Name

LAB.INPUT

Queue Manager

QM1

⚙️ PASSO 7 — CONFIGURAR MQOUTPUT

Queue

LAB.OUTPUT

🧠 PASSO 8 — CRIAR O ESQL

Compute Node

Clique:

Open ESQL

✨ CÓDIGO COMPLETO

CREATE COMPUTE MODULE MAINFRAME_TO_JSON

CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN

    DECLARE MSG CHAR;
    
    SET MSG = CAST(InputRoot.BLOB.BLOB AS CHAR CCSID 1208);

    DECLARE CONTA CHAR;
    DECLARE NOME  CHAR;
    DECLARE SALDO CHAR;

    SET CONTA = SUBSTRING(MSG FROM 1 FOR 6);
    SET NOME  = TRIM(SUBSTRING(MSG FROM 7 FOR 10));
    SET SALDO = SUBSTRING(MSG FROM 17 FOR 7);

    CREATE FIELD OutputRoot.JSON.Data;

    SET OutputRoot.JSON.Data.conta = CONTA;
    SET OutputRoot.JSON.Data.nome  = NOME;
    SET OutputRoot.JSON.Data.saldo = CAST(SALDO AS INTEGER);

    RETURN TRUE;

END;

END MODULE;

🧠 O QUE ESSE ESQL FAZ?


📌 PASSO A PASSO DA LÓGICA

1️⃣ Recebe o BLOB MQ

SET MSG = CAST(InputRoot.BLOB.BLOB AS CHAR CCSID 1208);

Converte:

  • bytes MQ

  • para texto


2️⃣ Extrai os campos

Conta

SET CONTA = SUBSTRING(MSG FROM 1 FOR 6);

Pega:

000123

Nome

SET NOME = TRIM(SUBSTRING(MSG FROM 7 FOR 10));

Pega:

JOAO

Saldo

SET SALDO = SUBSTRING(MSG FROM 17 FOR 7);

Pega:

0000500

📌 MONTA JSON

SET OutputRoot.JSON.Data.conta = CONTA;

Cria:

{
  "conta": "000123"
}

🚀 RESULTADO FINAL

Mensagem saída:

{
  "conta": "000123",
  "nome": "JOAO",
  "saldo": 500
}

🔥 PASSO 9 — DEPLOY

Clique direito

Deploy → Integration Server

📦 PASSO 10 — TESTAR

Enviar MQ Message

Use:

amqsput LAB.INPUT QM1

Digite:

000123JOAO      0000500

ENTER
ENTER novamente.


📥 VERIFICAR SAÍDA

amqsget LAB.OUTPUT QM1

🎉 RESULTADO

{
  "conta":"000123",
  "nome":"JOAO",
  "saldo":500
}

🔥 O QUE VOCÊ APRENDEU AQUI?

Você criou:

✅ integração real
✅ transformação legado → moderno
✅ parsing de layout COBOL
✅ transformação JSON
✅ fluxo MQ
✅ ESQL
✅ Message Flow


🧠 CENÁRIOS REAIS DE MERCADO

Esse padrão é MUITO usado para:

LegadoModerno
COBOLAPI REST
VSAMJSON
CICSCloud
MQKafka
DB2Microservices

🚨 PROBLEMAS COMUNS

❌ CCSID errado

Erro clássico:

caracteres estranhos

Solução:

  • validar UTF-8

  • EBCDIC

  • CCSID MQ


❌ Campo deslocado

Exemplo:

JOAO indo para saldo

Problema:

  • posições incorretas


❌ JSON vazio

Problema:

  • OutputRoot errado


❌ MQInput não lê

Verificar:

  • queue manager

  • channel

  • listener

  • permissões


🔥 LAB AVANÇADO (PRÓXIMOS PASSOS)

Você pode evoluir para:

✅ Copybook COBOL real
✅ XMLNSC
✅ SOAP
✅ REST API
✅ Kafka
✅ integração DB2
✅ CICS Web Services
✅ SAP IDoc
✅ HTTPS OAuth2
✅ JWT
✅ transformação XML ↔ JSON


🏆 DESAFIO EXTRA

Transforme este layout:

000123JOAO      00005000000100SP

Em:

{
  "conta":123,
  "nome":"JOAO",
  "saldo":500,
  "agencia":100,
  "estado":"SP"
}

☕🔥 CONCLUSÃO

Esse laboratório mostra exatamente:

como o IBM Integration Bus/ACE virou a ponte entre o mundo COBOL/mainframe e o universo APIs/cloud.

É literalmente:

✅ legado falando moderno
✅ MQ falando REST
✅ EBCDIC falando JSON
✅ mainframe conectado ao futuro 🚀


terça-feira, 5 de outubro de 2010

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

 

Bellacosa Mainframe explica o JSON


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

“Enquanto muita gente ainda pensava em arquivos texto… o JSON já estava preparando o planeta para microserviços, APIs e integração global.”


🚀 Introdução — O Formato Que Conquistou o Mundo

Se existe algo que une JavaScript, Python, Java, Node.js, Kubernetes, APIs REST, Open Banking, cloud e até o z/OS… esse algo é o JSON.

Sim…

Aquele bloco aparentemente simples:

{
"cliente": "BELLACOSA",
"conta": 12345,
"saldo": 9999.99
}

Hoje parece trivial.

Mas o impacto do JSON na computação foi monstruoso.

Ele virou:

  • o idioma oficial das APIs,
  • a “cola” da internet moderna,
  • o padrão universal de troca de dados,
  • e uma das maiores revoluções silenciosas da computação corporativa.

E o mais curioso?

O JSON nasceu de forma extremamente simples… quase como um “truque elegante” dentro do JavaScript.


🧠 Quem Criou o JSON?

O JSON foi criado por:

👨 Douglas Crockford

Programador, arquiteto de software e evangelista JavaScript.


📅 Data de Criação

O JSON começou a ganhar forma por volta de:

📌 2001

E foi oficialmente popularizado entre:

📌 2002–2005


🌍 O Problema Que o JSON Resolveu

Antes do JSON, integração era quase sempre baseada em:

  • XML
  • CSV
  • Arquivos posicionais
  • Protocolos binários
  • EDI
  • Mensagens proprietárias

O problema?

Tudo era:

  • pesado,
  • verboso,
  • lento,
  • difícil de ler,
  • difícil de debugar.

Exemplo de XML:

<cliente>
<nome>BELLACOSA</nome>
<saldo>9999.99</saldo>
</cliente>

Agora compare com JSON:

{
"nome": "BELLACOSA",
"saldo": 9999.99
}

Menos ruído.
Mais legibilidade.
Mais velocidade.
Mais simplicidade.

E o mercado enlouqueceu.


⚡ O Grande Segredo do JSON

O JSON nasceu inspirado diretamente nos objetos JavaScript.

Na prática:

var cliente = {
nome: "BELLACOSA",
saldo: 9999.99
}

Douglas Crockford percebeu:

“E se isso virar um formato universal de troca de dados?”

E virou.


🔥 O JSON Explodiu Com as APIs REST

Quando APIs REST começaram a dominar o mercado…

o JSON virou praticamente obrigatório.

Porque:

  • era leve,
  • rápido,
  • fácil de parsear,
  • perfeito para internet,
  • amigável para humanos.

Resultado?

O XML começou a perder espaço rapidamente.


☕ O Mainframe Não Ficou de Fora

Aqui começa a parte interessante para o mundo COBOL.

Muita gente achava:

“Mainframe nunca vai falar JSON.”

Erro histórico.

Hoje o z/OS conversa JSON o tempo inteiro:

  • APIs REST
  • z/OS Connect
  • CICS Web Services
  • MQ
  • Kafka
  • Open Banking
  • Microsserviços
  • Cloud híbrida

O JSON virou peça fundamental da modernização mainframe.


🧠 COBOL + JSON = O Casamento Corporativo Moderno

A IBM percebeu rapidamente:

Se o mainframe quisesse continuar reinando…
precisaria falar JSON nativamente.

E então vieram recursos modernos como:

📌 JSON PARSE

e

📌 JSON GENERATE

no Enterprise COBOL.


🚀 Exemplo COBOL Moderno Com JSON

Gerando JSON

IDENTIFICATION DIVISION.
PROGRAM-ID. GERJSON.

DATA DIVISION.

WORKING-STORAGE SECTION.

01 CLIENTE.
05 NOME PIC X(20) VALUE 'BELLACOSA'.
05 SALDO PIC 9(5)V99 VALUE 99999.99.

01 JSON-SAIDA PIC X(200).

PROCEDURE DIVISION.

JSON GENERATE JSON-SAIDA
FROM CLIENTE

DISPLAY JSON-SAIDA.

STOP RUN.

Saída:

{"NOME":"BELLACOSA","SALDO":99999.99}

🔥 Parsing JSON no COBOL

Recebendo API REST

JSON PARSE JSON-ENTRADA
INTO CLIENTE

Isso foi revolucionário no z/OS.

Porque eliminou:

  • parsers manuais,
  • tratamentos absurdos,
  • lógica artesanal,
  • conversões complexas.

🧠 O Que Tornou o JSON Tão Poderoso?

📌 1. Legibilidade Humana

Até operador consegue entender.


📌 2. Estrutura Hierárquica

Permite:

  • objetos,
  • listas,
  • arrays,
  • árvores complexas.

📌 3. Independência de Linguagem

Funciona em:

  • COBOL
  • Java
  • Python
  • Go
  • Node.js
  • Rust
  • RPG
  • PL/I

📌 4. Perfeito Para APIs

JSON praticamente virou:

“o TCP/IP da integração moderna.”


⚠️ Desvantagens do JSON

Nem tudo são flores.


❌ 1. Sem Tipagem Forte

JSON puro não define:

  • decimal fixo,
  • packed decimal,
  • COMP-3,
  • datas reais.

Isso gera problemas em integrações financeiras.


❌ 2. Overhead de Texto

JSON é texto.

Protocolos binários podem ser mais rápidos.


❌ 3. Segurança

Parsing inseguro pode causar:

  • injection,
  • payload malicioso,
  • consumo excessivo de memória.

❌ 4. Precisão Numérica

Problema clássico:

  • valores financeiros,
  • arredondamentos,
  • IEEE floating point.

O mainframe sofre muito menos disso graças ao decimal packed.


🔥 Curiosidades Históricas

☕ JSON NÃO É Linguagem

Apesar do nome:

JavaScript Object Notation

JSON NÃO é uma linguagem de programação.

É apenas um formato de dados.


☕ O JSON Virou Padrão Oficial

RFC oficial:

📌 RFC 8259


☕ XML Dominava Absolutamente

Antes do JSON:

  • SOAP,
  • WSDL,
  • XML Schema,
  • namespaces,
  • tags gigantescas.

Parecia um ritual mágico corporativo.

JSON chegou como uma motosserra.


💣 Easter Egg Histórico

Douglas Crockford chegou a remover referências perigosas do JavaScript porque:

📌 JSON podia executar código involuntariamente

No começo muita gente fazia:

eval(json)

Isso virou um pesadelo de segurança.

Daí nasceram parsers seguros.


🚀 JSON no Mundo Mainframe Moderno

Hoje o JSON está em todo lugar no z/OS:

TecnologiaUso
z/OS ConnectAPIs REST
CICSWeb Services
IMSIntegração moderna
MQMensageria
KafkaStreaming
Db2 RESTAPIs corporativas
Open BankingPayloads financeiros
Cloud híbridaMicrosserviços



🔥 O JSON Mudou o Papel do Programador COBOL

Antigamente:

  • COBOL manipulava arquivos,
  • VSAM,
  • copybooks,
  • EBCDIC.

Hoje o COBOL moderno:

  • consome APIs,
  • gera REST,
  • fala HTTP,
  • troca JSON,
  • integra cloud,
  • conversa com Kubernetes.

O programador COBOL virou:

engenheiro de integração corporativa.


☕ Comparação Filosófica: JSON vs Copybook COBOL

Curiosamente…

JSON lembra MUITO a ideia dos copybooks.

Veja:

Copybook

01 CLIENTE.
05 NOME PIC X(20).
05 SALDO PIC 9(5)V99.

JSON

{
"NOME": "BELLACOSA",
"SALDO": 99999.99
}

Ambos descrevem estrutura de dados.

A diferença?

O JSON atravessa internet, nuvem e APIs.


🧠 O Verdadeiro Motivo do Sucesso do JSON

Não foi tecnologia.

Foi simplicidade.

O JSON venceu porque:

  • humanos entendem,
  • programadores gostam,
  • APIs adoram,
  • clouds dependem,
  • empresas inteiras padronizaram nele.

💣 Conclusão — O JSON Virou a “Nova Linguagem Universal”

O JSON não matou o COBOL.

Na verdade…

Ele ajudou o COBOL a sobreviver à era cloud.

Hoje o mainframe continua relevante porque aprendeu:

  • REST,
  • APIs,
  • microsserviços,
  • containers,
  • integração moderna,
  • e principalmente…
  • JSON.

E talvez essa seja a maior ironia da computação:

O formato que nasceu no JavaScript acabou ajudando o z/OS a continuar dominando o coração financeiro do planeta.


☕ Frase Final no Estilo Bellacosa Mainframe

“O COBOL continua processando bilhões… mas agora conversa com o mundo em JSON.” 🔥🚀

 

sexta-feira, 16 de março de 2007

O que é z/OS Connect?

 

Bellacosa Mainframe olhando o Z/os connect

O que é z/OS Connect?

O z/OS Connect é uma tecnologia da IBM que permite transformar aplicações Mainframe em APIs REST modernas, possibilitando que programas COBOL, CICS, IMS e DB2 sejam consumidos por aplicações Web, Mobile, Cloud e Microsserviços.

Em termos simples:

Programa COBOL
      ↓
z/OS Connect
      ↓
API REST
      ↓
Aplicativo Mobile

Por que o z/OS Connect foi criado?

Durante décadas, aplicações Mainframe eram acessadas através de:

  • Telas CICS

  • MQ

  • Arquivos

  • SOAP/XML

  • Integrações proprietárias

Com a explosão das APIs REST e do mundo Mobile, surgiu a necessidade de expor programas Mainframe de forma moderna.

O z/OS Connect resolve exatamente esse problema.


Definição Simples

O z/OS Connect atua como uma ponte entre:

Mundo Moderno
(API REST + JSON)
          ↓
     z/OS Connect
          ↓
Mundo Mainframe
(COBOL + CICS + IMS + DB2)

Arquitetura Básica

Aplicativo Mobile
         ↓
      JSON
         ↓
    API REST
         ↓
  z/OS Connect
         ↓
     COBOL
         ↓
      DB2

O que ele faz?

Expor aplicações Mainframe como APIs

Transforma:

COBOL
CICS
IMS

em:

REST API

Consumir APIs externas

Também permite que aplicações Mainframe consumam APIs externas.

Exemplo:

COBOL
   ↓
z/OS Connect
   ↓
API Correios

Exemplo Prático

Imagine um programa COBOL que consulta saldo.

Antes:

Terminal 3270
       ↓
CICS
       ↓
COBOL

Depois:

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

Exemplo de Requisição

Chamada REST

GET /clientes/1001

JSON Recebido

{
  "id":1001
}

COBOL Processa

EXEC SQL

SELECT NOME
FROM CLIENTES

END-EXEC.

JSON Retornado

{
  "id":1001,
  "nome":"JOAO SILVA"
}

Componentes Principais

API Requester

Permite que o Mainframe consuma APIs.

COBOL
   ↓
Requester
   ↓
API Externa

API Provider

Permite expor programas como APIs.

API REST
    ↓
Provider
    ↓
COBOL

Integração com CICS

Muito comum.

REST API
     ↓
z/OS Connect
     ↓
CICS
     ↓
COBOL

Integração com IMS

Também suporta IMS.

REST API
     ↓
z/OS Connect
     ↓
IMS
     ↓
COBOL

Integração com DB2

Fluxo típico:

JSON
 ↓
REST
 ↓
COBOL
 ↓
DB2

JSON e Copybook

O z/OS Connect faz o mapeamento:

JSON
   ↔
Copybook COBOL

Exemplo:

JSON:

{
  "conta":"12345"
}

Copybook:

01 REQ-CONTA.
   05 CONTA PIC X(10).

API Mediation Layer

Camada responsável por:

  • Conversão JSON

  • Segurança

  • Mapeamento

  • Roteamento


Segurança

Suporta:

✅ RACF

✅ TLS

✅ OAuth 2.0

✅ JWT

✅ Certificados Digitais

✅ MFA


Open Banking

Grande parte das implementações de Open Finance utilizam:

API REST
      ↓
z/OS Connect
      ↓
COBOL

Benefícios

Modernização

Sem reescrever COBOL.


Reutilização

Aproveita décadas de regras de negócio.


Integração

Conecta:

  • Cloud

  • Mobile

  • APIs

  • Microsserviços


Segurança

Mantém os controles do z/OS.


Exemplo Real

Consulta de saldo:

Aplicativo
      ↓
REST API
      ↓
z/OS Connect
      ↓
CICS
      ↓
COBOL
      ↓
DB2
      ↓
Saldo

Relação com Cloud

Muito utilizado em arquiteturas híbridas.

AWS
Azure
Google Cloud
        ↓
API REST
        ↓
z/OS Connect
        ↓
IBM Z

Relação com LinuxONE

Containers
OpenShift
Kubernetes
        ↓
API REST
        ↓
z/OS Connect
        ↓
COBOL

Ferramentas Associadas

  • Zowe

  • OpenShift

  • API Connect

  • UrbanCode

  • Git

  • Jenkins

  • Ansible


Curiosidades

1. É uma das principais tecnologias de modernização da IBM

2. Permite expor aplicações escritas há décadas sem alterar o código COBOL

3. É amplamente utilizado em bancos e seguradoras

4. Facilita a integração com microsserviços

5. Reduz drasticamente o esforço de criação de APIs


Resumo Rápido

ComponenteFunção
z/OS ConnectGateway de APIs Mainframe
RESTInterface moderna
JSONFormato de dados
COBOLRegra de negócio
CICSProcessamento online
IMSTransações IMS
DB2Banco de dados
RACFSegurança
API ProviderExpor APIs
API RequesterConsumir APIs

Conclusão

O z/OS Connect é a principal tecnologia da IBM para conectar o Mainframe ao mundo das APIs REST. Ele permite transformar programas COBOL, CICS e IMS em serviços modernos baseados em JSON e HTTP, sem necessidade de reescrever aplicações críticas. Por isso, tornou-se peça fundamental em projetos de transformação digital, Open Finance, Cloud Híbrida, Mobile Banking e integração entre Mainframe e microsserviços.


quinta-feira, 22 de fevereiro de 2007

Como se Usa XML em COBOL?

 

Bellacosa Mainframe e o XML no COBOL

Como se Usa XML em COBOL?

O XML tornou-se muito importante no mundo Mainframe quando bancos, seguradoras e governos passaram a integrar aplicações COBOL com sistemas Web, Java, .NET, APIs e serviços externos.

Hoje é comum um programa COBOL:

  • receber XML;

  • gerar XML;

  • consumir Web Services;

  • integrar com CICS Web Services;

  • integrar com z/OS Connect;

  • trocar mensagens SOAP.


O que é XML?

XML significa:

eXtensible Markup Language

É um formato textual para troca de informações.

Exemplo:

<cliente>
   <id>1001</id>
   <nome>JOAO SILVA</nome>
   <saldo>5000.00</saldo>
</cliente>

Por que XML foi importante no Mainframe?

Antes do XML, a troca de dados era normalmente feita através de:

Arquivos Flat
QSAM
VSAM
Copybooks

O XML permitiu integração entre plataformas diferentes.


XML no COBOL Moderno

O Enterprise COBOL possui dois comandos especiais:

XML GENERATE

Gera XML.

XML PARSE

Lê XML.


XML GENERATE

Transforma uma estrutura COBOL em XML.


Exemplo COBOL

01 CLIENTE.
   05 ID-CLI      PIC 9(5).
   05 NOME-CLI    PIC X(30).
   05 SALDO-CLI   PIC 9(7)V99.

Dados

MOVE 1001 TO ID-CLI
MOVE 'JOAO SILVA' TO NOME-CLI
MOVE 5000 TO SALDO-CLI

Geração XML

XML GENERATE XML-SAIDA
   FROM CLIENTE
END-XML

Resultado

<CLIENTE>
   <ID-CLI>1001</ID-CLI>
   <NOME-CLI>JOAO SILVA</NOME-CLI>
   <SALDO-CLI>5000</SALDO-CLI>
</CLIENTE>

Estrutura Completa

01 XML-SAIDA PIC X(5000).

XML GENERATE XML-SAIDA
   FROM CLIENTE
END-XML.

XML PARSE

Faz o caminho inverso.

Transforma XML em dados COBOL.


XML Recebido

<CLIENTE>
   <ID>1001</ID>
   <NOME>JOAO</NOME>
</CLIENTE>

Comando

XML PARSE XML-ENTRADA

   PROCESSING PROCEDURE IS PROC-XML

END-XML

Processing Procedure

A cada tag encontrada o COBOL chama um parágrafo.


Exemplo

PROC-XML.

DISPLAY XML-EVENT
DISPLAY XML-TEXT.

Variáveis Automáticas

Durante o PARSE:

XML-CODE
XML-EVENT
XML-TEXT

são preenchidas automaticamente.


XML-CODE

Retorno da operação.

0 = OK

XML-EVENT

Evento encontrado.

Exemplo:

START-OF-ELEMENT
END-OF-ELEMENT
CONTENT-CHARACTERS

XML-TEXT

Conteúdo da tag.


Exemplo Prático

XML:

<NOME>JOAO</NOME>

Durante o PARSE:

EVENT = CONTENT-CHARACTERS
TEXT  = JOAO

XML e CICS

Muito utilizado em Web Services.

Fluxo:

Cliente
   ↓
SOAP XML
   ↓
CICS
   ↓
Programa COBOL

Exemplo SOAP

<soap:Envelope>
   <soap:Body>

      <ConsultaSaldo>

         <Conta>12345</Conta>

      </ConsultaSaldo>

   </soap:Body>
</soap:Envelope>

CICS Web Services

O CICS pode:

✅ Receber XML

✅ Converter XML para COBOL

✅ Converter COBOL para XML

automaticamente.


DFHWS2LS

Ferramenta CICS.

Converte:

XML
 ↓
COBOL Copybook

DFHLS2WS

Faz o inverso.

Copybook
 ↓
XML

XML e z/OS Connect

Hoje muitas empresas utilizam:

REST API
       ↓
JSON
       ↓
z/OS Connect
       ↓
COBOL

Mas internamente ainda existem muitos serviços XML.


XML e DB2

Dados DB2 podem ser transformados em XML.


Exemplo

SELECT *
FROM CLIENTES

<CLIENTE>
...
</CLIENTE>

XML Schema (XSD)

Define regras para XML.


Exemplo

<xs:element name="CLIENTE"/>

Benefícios do XML

✅ Padronização

✅ Interoperabilidade

✅ Legibilidade

✅ Integração entre plataformas

✅ Suporte nativo no COBOL


Desvantagens

❌ Verboso

❌ Arquivos grandes

❌ Parsing mais lento que JSON


XML x JSON

XML:

<NOME>JOAO</NOME>

JSON:

{
  "nome":"JOAO"
}

Hoje JSON é mais comum em APIs REST.

Mas XML continua muito presente em:

  • SOAP

  • Bancos

  • Governo

  • Seguros

  • Mainframe legado


Exemplo Completo XML GENERATE

WORKING-STORAGE SECTION.

01 CLIENTE.
   05 ID-CLI     PIC 9(5).
   05 NOME-CLI   PIC X(30).

01 XML-SAIDA PIC X(1000).

PROCEDURE DIVISION.

MOVE 1001 TO ID-CLI
MOVE 'JOAO SILVA' TO NOME-CLI

XML GENERATE XML-SAIDA
   FROM CLIENTE
END-XML

DISPLAY XML-SAIDA

STOP RUN.

Resumo Rápido

ComandoFunção
XML GENERATECOBOL → XML
XML PARSEXML → COBOL
XML-CODECódigo retorno
XML-EVENTEvento XML
XML-TEXTConteúdo XML
DFHWS2LSXML → Copybook
DFHLS2WSCopybook → XML
SOAPWeb Service XML
XSDSchema XML

Dica para quem estuda Mainframe

Como você já tem interesse em CICS Web Services e z/OS Connect, o próximo passo natural é montar um laboratório com:

COBOL
   ↓
COPYBOOK
   ↓
DFHLS2WS
   ↓
WSDL
   ↓
SOAP XML
   ↓
CICS Web Services

Esse é exatamente o caminho utilizado em muitos bancos para expor programas COBOL como serviços consumidos por aplicações Java, .NET, Mobile e APIs corporativas.