✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes

Mostrar mensagens com a etiqueta Web Services. Mostrar todas as mensagens

domingo, 21 de janeiro de 2024

☕🔥 COMMAREA, CHANNELS e CONTAINERS no CICS TS: O Guia Definitivo para Desenvolvedores COBOL Junior

Bellacosa Mainframe e commarea channels e containers no cics ts

☕🔥 COMMAREA, CHANNELS e CONTAINERS no CICS TS: O Guia Definitivo para Desenvolvedores COBOL Junior

Introdução

Todo programador COBOL que inicia no mundo CICS aprende rapidamente três palavras que aparecem em praticamente qualquer aplicação online:

COMMAREA
CHANNEL
CONTAINER

Embora pareçam apenas mecanismos para passagem de parâmetros, na realidade representam três gerações diferentes da evolução do CICS.

Compreender quando utilizar cada abordagem, suas limitações, vantagens, implicações de performance e integração com Web Services, APIs REST e IBM MQ é fundamental para qualquer desenvolvedor que deseje construir aplicações modernas no IBM Z.

A grande dúvida dos iniciantes costuma ser:

"Se a COMMAREA funciona há décadas, por que a IBM criou Channels e Containers?"

A resposta está diretamente relacionada à evolução dos sistemas corporativos.

Como o CICS Enxerga uma Transação

Quando uma transação executa:

Cliente
   |
TRANSAÇÃO
   |
PROGRAMA A

frequentemente o programa precisa:

chamar outro programa
enviar dados
receber retorno
transferir controle

Exemplo:

PROGRAMA A
   |
 LINK
   |
PROGRAMA B

Nesse momento os dados precisam ser transferidos.

É aí que entram COMMAREA, CHANNEL e CONTAINER.

COMMAREA — O Clássico do CICS

COMMAREA significa:

Communication Area

Ela surgiu nos primeiros anos do CICS e se tornou durante décadas o principal mecanismo de comunicação entre programas.

Exemplo:

Programa A:

EXEC CICS LINK
     PROGRAM('CLIENTE')
     COMMAREA(WS-COMMAREA)
     LENGTH(200)
END-EXEC

Programa B:

01 DFHCOMMAREA.
   05 CLI-CODIGO PIC 9(08).
   05 CLI-NOME   PIC X(40).

O CICS copia os dados de um programa para outro.

Como Funciona Internamente

Imagine:

PROGRAMA A
   |
   | 200 bytes
   |
PROGRAMA B

O CICS realiza uma cópia física do conteúdo.

Por isso o tamanho importa.

Limite da COMMAREA

O limite máximo teórico é:

64 KB

Na prática:

65.535 bytes

Porém a maioria dos sistemas utiliza:

32 KB

como limite operacional seguro.

Por quê?

Porque historicamente muitos aplicativos e interfaces foram construídos considerando esse valor.

Exemplo de Layout COMMAREA

01 WS-COMMAREA.
   05 WS-HEADER.
      10 WS-OPERACAO PIC X(08).
      10 WS-USUARIO  PIC X(20).

   05 WS-CLIENTE.
      10 WS-CONTA    PIC 9(10).
      10 WS-NOME     PIC X(40).
      10 WS-SALDO    PIC S9(9)V99 COMP-3.

Total:

82 bytes

Vantagens da COMMAREA

Simplicidade

Extremamente fácil.

EXEC CICS LINK

e pronto.

Compatibilidade

Praticamente todos os sistemas CICS do mundo utilizam COMMAREA.

Performance

Para pequenos volumes:

100 bytes
500 bytes
1 KB
2 KB

é extremamente eficiente.

Desvantagens da COMMAREA

Estrutura rígida

Quem envia e quem recebe devem conhecer exatamente o mesmo layout.

Mudou um campo?

Pode quebrar tudo.

Acoplamento forte

Programa A depende diretamente do layout do Programa B.

Limite de tamanho

Web Services modernos frequentemente ultrapassam:

32 KB
50 KB
100 KB
500 KB

A COMMAREA não foi projetada para isso.

O Problema das APIs Modernas

Imagine um JSON:

{
  "cliente": {
     "nome":"João",
     "enderecos":[...],
     "cartoes":[...],
     "seguros":[...]
  }
}

Facilmente pode ultrapassar:

40 KB
80 KB
150 KB

A COMMAREA começa a sofrer.

Surge o CHANNEL

Para resolver isso a IBM criou:

CHANNEL

Pense nele como um envelope.

O que é um CHANNEL?

Um CHANNEL não contém dados.

Ele contém:

CONTAINERS

Imagine:

CHANNEL CLIENTE

   |
   +-- HEADER
   +-- DADOS
   +-- ENDERECOS
   +-- CARTOES
   +-- SEGUROS

O que é um CONTAINER?

Container é onde os dados ficam armazenados.

Cada container possui:

nome
conteúdo
tamanho

Analogia Simples

COMMAREA:

1 caixa gigante

CHANNEL:

1 armário

CONTAINER:

gavetas do armário

Exemplo de Criação

Criando container:

EXEC CICS PUT CONTAINER
     CONTAINER('CLIENTE')
     CHANNEL('CANAL01')
     FROM(WS-DADOS)
     FLENGTH(500)
END-EXEC

Recuperando Dados

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

Limites dos Containers

Ao contrário da COMMAREA:

64 KB máximo

Containers podem armazenar:

Megabytes

de informação.

Na prática:

JSON grandes
XML grandes
payloads extensos

funcionam muito melhor.

Estrutura Recomendada

Exemplo:

CHANNEL CLIENTE

HEADER
CLIENTE
ENDERECOS
TELEFONES
PRODUTOS
LOGS

Cada informação isolada.

Benefícios dos Channels

Menor acoplamento

Cada container pode evoluir independentemente.

Melhor manutenção

Não é necessário reconstruir um layout monolítico.

Escalabilidade

Ideal para integrações modernas.

COMMAREA vs CHANNEL

Característica	COMMAREA	CHANNEL
Tamanho	64 KB	Muito maior
Estrutura	Única	Múltiplos Containers
JSON	Limitado	Excelente
XML	Limitado	Excelente
APIs REST	Fraco	Excelente
MQ	Bom	Excelente
Evolução	Difícil	Fácil

Uso com Web Services

Quando um Web Service recebe:

<cliente>
 ...
</cliente>

{
 ...
}

normalmente o runtime do CICS utiliza:

CHANNEL
CONTAINER

internamente.

Motivo:

Payloads variáveis.

Uso com z/OS Connect

Praticamente todas as implementações modernas utilizam:

JSON
↓
CHANNEL
↓
COBOL

em vez de COMMAREA.

Uso com IBM MQ

MQ pode trabalhar com ambos.

Modelo Tradicional

MQ
  |
COMMAREA
  |
COBOL

Modelo Moderno

MQ
  |
CHANNEL
  |
CONTAINERS
  |
COBOL

Exemplo MQ

Mensagem recebida:

Pedido
Itens
Cliente
Pagamento

Pode ser dividida em:

PEDIDO
ITENS
CLIENTE
PAGAMENTO

Cada parte em um container.

Quando Usar COMMAREA?

Utilize quando:

✅ aplicações legadas

✅ pequenas estruturas

✅ LINK simples

✅ integração interna

Exemplo:

Consulta Cliente
Consulta Agência
Consulta Conta

Quando Usar CHANNEL?

Utilize quando:

✅ APIs REST

✅ JSON

✅ XML

✅ Web Services

✅ MQ moderno

✅ microsserviços

✅ payloads grandes

Estratégia Utilizada pelos Bancos

O que normalmente vemos hoje:

Core COBOL antigo
      |
   COMMAREA

APIs novas
      |
CHANNEL
CONTAINER

Os dois convivem perfeitamente.

Erros Comuns dos Iniciantes

Não validar tamanho

LENGTH(...)

deve sempre ser controlado.

Alterar layout sem sincronizar

Clássico problema de COMMAREA.

Usar container gigante

Separar logicamente os dados é melhor.

Não documentar containers

Sempre documente:

CLIENTE
ENDERECO
PRODUTO
PAGAMENTO

Boas Práticas

COMMAREA

manter abaixo de 32 KB
usar copybooks
versionar layouts

CHANNELS

containers pequenos
nomes padronizados
separar responsabilidades

MQ

payload desacoplado
evitar estruturas gigantes
utilizar containers temáticos

Conclusão

A COMMAREA continua viva e continuará por muitos anos. Milhares de aplicações bancárias processam bilhões de transações diariamente utilizando esse mecanismo criado há décadas.

Entretanto, o mundo mudou.

JSON, APIs REST, Open Banking, PIX, Web Services, MQ distribuído e arquiteturas orientadas a serviços exigiram uma evolução do modelo tradicional.

Foi exatamente para atender esse novo cenário que surgiram os Channels e Containers.

O desenvolvedor COBOL moderno não deve enxergar COMMAREA e CHANNEL como concorrentes.

Eles são ferramentas diferentes para problemas diferentes.

A regra prática é simples:

COMMAREA para integrações simples e legadas.
CHANNEL e CONTAINER para aplicações modernas, APIs, MQ e Web Services.

Quem domina os dois mundos consegue navegar tanto nos sistemas que sustentam os bancos há décadas quanto nas novas arquiteturas digitais que conectam o IBM Z ao restante do planeta.

E essa é uma das habilidades mais valiosas para qualquer programador COBOL que deseja evoluir para desenvolvedor CICS de alto nível.

quinta-feira, 20 de abril de 2023

Dr. Watson Entra no CICS — O Caso do COBOL que Não Sabia que Era uma API

Bellacosa Mainframe e o cobol falando com a web via api

☕ Um Café no Bellacosa Mainframe

Dr. Watson Entra no CICS — O Caso do COBOL que Não Sabia que Era uma API

Ou: por que o programa que calcula a folha há trinta anos pode conversar com um aplicativo no celular sem trocar de linguagem, trocar de cérebro ou colocar bigode no JSON

“Holmes”, perguntou o Dr. Watson, olhando para o monitor onde um aplicativo de celular acabara de consultar o saldo de uma conta, “então o COBOL finalmente aprendeu Java?”

Sherlock nem levantou os olhos do log de uma transação CICS.

“Não, Watson. E esta é justamente a dedução que separa um arquiteto de alguém que instala uma biblioteca, desenha três setas num PowerPoint e chama a reunião de modernização.”

O espanto do Watson é o de muita gente, inclusive de bons desenvolvedores iniciantes. Eles ouvem “aplicação moderna”, pensam em React, Java, Python, Kubernetes, cloud, aplicativo de celular e JSON. Depois ouvem “COBOL”, imaginam uma sala empoeirada, cartões perfurados e um sistema incapaz de conversar com qualquer coisa que tenha tela sensível ao toque.

É uma imagem divertida, mas errada.

COBOL não precisa “virar Java” para participar do mundo digital. O que ele precisa é de uma porta de entrada bem desenhada, de um contrato claro para trocar dados e de uma camada que traduza a conversa entre os dois mundos. O COBOL continua realizando aquilo que sabe fazer muito bem: aplicar regras de negócio, consultar Db2, ler VSAM, conversar com IMS, validar limites, calcular valores e manter a consistência de uma operação que não pode falhar porque alguém colocou um emoji no campo de observação.

Neste café, Watson será nosso cronista. Ele vai acompanhar a investigação desde o primeiro JSON até o retorno da resposta, descobrir por que um campo aparentemente inocente pode produzir um erro enorme e perceber que modernizar não é demolir a agência bancária para instalar uma máquina de café expresso.

1. A primeira pista: ninguém “fala COBOL” pela internet

Quando um aplicativo mobile pede uma segunda via de boleto ou verifica a margem consignável de um cliente, ele normalmente envia uma requisição HTTP ou HTTPS. HTTP é o protocolo da conversa; HTTPS é essa conversa protegida por TLS. JSON é o formato textual usado para organizar os dados.

Uma solicitação simples poderia ser:

{
  "employeeId": "10025",
  "requestType": "PAYROLL"
}

O aplicativo não está chamando diretamente um PERFORM dentro de um programa COBOL. Ele está chamando uma API, algo como:

POST /payroll/v1/employee-query

O endpoint recebe a chamada, identifica o consumidor, valida a entrada e encaminha os dados para o ativo de negócio correto no z/OS. Esse ativo pode ser um programa COBOL sob CICS, uma transação IMS, uma rotina que consulta Db2 ou até uma composição de serviços.

O ponto decisivo é este: linguagem não é protocolo. Java, .NET, Python e COBOL podem participar da mesma conversa porque todos entendem os acordos de integração: rede, segurança, formatos e contratos. O programa COBOL não precisa entender a moda do framework da semana; a camada de serviço se encarrega de apresentar uma interface estável ao exterior.

Watson anotou: “Portanto, o celular não invade o mainframe; ele toca a campainha certa.” Exatamente.

2. A cena do crime: o caminho real da chamada

O desenho simplificado “COBOL → CICS → HTTP → JSON → aplicação moderna” transmite a ideia geral, mas na vida real as responsabilidades precisam aparecer. Um fluxo comum se parece mais com isto:

Aplicativo mobile / portal / serviço cloud
             |
        HTTPS + JSON
             |
API Gateway e camada de segurança
             |
z/OS Connect, CICS Web API ou serviço CICS
             |
COMMAREA, CHANNEL/CONTAINER, MQ ou chamada de programa
             |
Programa COBOL
             |
Db2, VSAM, IMS, MQ e regras de negócio

Nem toda empresa usa exatamente todos esses blocos. Em algumas, o CICS recebe HTTP diretamente. Em outras, o z/OS Connect expõe uma API REST sobre ativos CICS e IMS. Em outras, uma camada Java no z/OS ou numa plataforma distribuída faz parte da composição. E, quando o processo não exige resposta imediata, IBM MQ pode ser mais apropriado do que manter uma chamada HTTP esperando.

O erro de principiante é tratar todas essas opções como rivais. Elas são ferramentas para problemas diferentes.

Uma consulta de saldo tende a ser síncrona: pergunta, processa, responde.
Um pedido de recálculo de folha de milhões de pessoas pode ser assíncrono: recebe a solicitação, coloca trabalho em fila, processa com controle e devolve um protocolo.
Uma integração antiga pode continuar usando SOAP e XML; uma nova pode preferir REST e JSON.

Não existe medalha para quem força tudo a virar API síncrona. Há apenas incidentes mais elegantes.

3. CICS: o recepcionista que não deixa o visitante chegar à sala-cofre

Para quem começa em COBOL, CICS pode parecer apenas aquele ambiente onde aparecem comandos EXEC CICS. Mas, nesta história, ele é muito mais: é um gerenciador de transações, recursos, segurança e execução online.

Pense no programa COBOL como o especialista que conhece a regra da folha. Ele não deveria receber uma ligação de qualquer pessoa, a qualquer hora, com campos sem validação e a ordem “faz aí”. CICS organiza a entrada, executa a transação sob controle, protege recursos, ajuda a lidar com concorrência e fornece mecanismos para a aplicação funcionar online com previsibilidade.

Quando a integração é feita adequadamente, o serviço não expõe necessariamente o programa legado inteiro. Ele expõe uma capacidade de negócio. Em vez de criar uma API chamada:

EXECUTA-PGM-PG1234-COM-AREA-DE-327-BYTES

você cria:

GET /customers/{id}/payroll-summary

O primeiro nome descreve o porão da casa. O segundo descreve o serviço que a empresa oferece. A diferença parece estética até o dia em que muda o programa interno e cinquenta consumidores externos não deveriam nem perceber.

4. O tradutor entre JSON e COBOL

Aqui está o ponto onde Watson encontra a lupa no chão.

JSON é flexível. Um campo pode vir ou não vir. Um valor pode chegar como texto, número, lista ou objeto. O formato é legível, usa UTF-8 e costuma carregar nomes expressivos.

COBOL, em contrapartida, gosta de estruturas definidas, tamanhos conhecidos e tipos declarados. Um identificador pode ser PIC X(5); uma data pode ter oito posições; um valor monetário pode ser PIC S9(7)V99 COMP-3. Isso não é uma deficiência. É parte da previsibilidade que tornou esses sistemas valiosos.

Uma representação de trabalho para a entrada poderia ser:

01  WS-PAYROLL-REQUEST.
    05  WS-EMPLOYEE-ID       PIC X(5).
    05  WS-REQUEST-TYPE      PIC X(10).

E a saída:

01  WS-PAYROLL-RESPONSE.
    05  WS-STATUS            PIC X(10).
    05  WS-EMPLOYEE-ID       PIC X(5).
    05  WS-EMPLOYEE-NAME     PIC X(40).
    05  WS-SALARY            PIC S9(7)V99 COMP-3.

Uma camada de transformação recebe o JSON, aplica regras de mapeamento e fornece ao COBOL uma estrutura coerente. Na volta, converte o resultado para JSON:

{
  "status": "SUCCESS",
  "employeeId": "10025",
  "employeeName": "JOHN",
  "salary": 4500.00
}

O jovem padawan, hipnotizado pelo exemplo, talvez diga: “Então basta copiar os campos”. Watson, que já viu Holmes derrubar uma tese inteira por causa de uma cinza de charuto, deve desconfiar. Copiar campos é a parte fácil. Definir a semântica correta é o trabalho de verdade.

5. As cinco armadilhas escondidas no JSON

Identificador não é quantidade

O valor "00025" pode ser um código, não o número vinte e cinco. Se o aplicativo moderno o transforma em 25, os zeros à esquerda desaparecem. Para o COBOL e para a regra de negócio, isso pode apontar para outro registro ou simplesmente não encontrar nenhum.

Quando o dado representa identidade — conta, agência, matrícula, CPF formatado, código de produto — trate-o como texto, mesmo que visualmente só tenha dígitos.

Dinheiro não gosta de improviso

No Brasil, um usuário pode escrever 4500,00; JSON numérico usa ponto: 4500.00. Um valor monetário também não deve passar por conversões descuidadas de ponto flutuante. O desenho precisa definir precisão, arredondamento, moeda e comportamento para valores ausentes.

O campo COBOL S9(7)V99 COMP-3 é eficiente internamente, mas não deve “vazar” para o contrato. Externamente, o consumidor precisa de um número JSON ou, em situações que exijam controle absoluto de precisão, de uma convenção bem documentada.

Ausente, nulo, branco e zero são quatro pessoas diferentes

No JSON, um campo pode estar ausente, pode ser null, pode ser string vazia ou pode ser zero. No COBOL, dependendo do mapeamento, tudo isso pode acabar como espaços ou zeros. Se a API não define o comportamento, alguém poderá sem querer alterar um limite para zero ou apagar uma informação válida.

Datas são pequenas bombas-relógio

Defina um padrão externo, normalmente YYYY-MM-DD ou data-hora ISO 8601 com fuso. Nunca deixe cada consumidor decidir se 03/04/2026 significa 3 de abril ou 4 de março. O COBOL pode trabalhar internamente com outro layout, desde que a conversão seja centralizada e testada.

UTF-8, EBCDIC e o acento que virou evidência

O mundo web normalmente trafega UTF-8. O z/OS historicamente trabalha com EBCDIC em muitas áreas. Ferramentas e camadas modernas realizam conversões, mas o time precisa testar nomes com acentos, cedilha, caracteres especiais e limites de tamanho. “João D’Ávila” é um teste melhor do que “JOHN”.

Easter egg do caso: o primeiro incidente muitas vezes não aparece com um número errado. Ele aparece quando “AÇÃO PROMOCIONAL” se transforma em um texto esquisito no extrato e alguém descobre que o ambiente de teste só possuía clientes chamados ANA e JOSE.

6. REST, SOAP, MQ e o falso campeonato de tecnologias

REST com JSON é muito popular porque é simples de consumir por apps web e mobile. SOAP com XML ainda existe em muitas empresas e pode ser adequado em integrações formais já consolidadas. IBM MQ é excelente quando confiabilidade, desacoplamento e processamento assíncrono são mais importantes do que uma resposta imediata.

Veja a escolha pela pergunta de negócio, não pela propaganda:

Caso	Opção frequentemente adequada
Consultar saldo ou status	API REST síncrona
Integrar serviço corporativo antigo	SOAP/XML, se o contrato já existe
Enviar lote, evento ou comando crítico	IBM MQ
Publicar função CICS/IMS para apps digitais	z/OS Connect ou recurso CICS
Fazer o COBOL consumir serviço externo	Cliente HTTP, integração CICS ou camada intermediária

Watson perguntou se REST “substitui” MQ. Holmes respondeu que uma chave inglesa não substitui um extintor. As duas coisas são importantes; apenas não devem ser usadas no mesmo parafuso.

7. A regra de ouro: exponha capacidade, não a anatomia do legado

Um erro comum de modernização é publicar uma API que reproduz o layout interno da COMMAREA, inclusive nomes históricos, campos reservados e indicadores sem significado para o consumidor.

Uma API fraca poderia devolver:

{
  "ws-ind-op": "A",
  "filler-01": "",
  "vlr-pgm": "00000450000",
  "ind-erro": "00"
}

Uma API saudável devolve algo que representa o domínio:

{
  "employeeId": "10025",
  "monthlySalary": 4500.00,
  "currency": "BRL",
  "processingStatus": "COMPLETED"
}

Isso permite modernizar por camadas. Por trás da API, você pode reorganizar programas, substituir um acesso, adicionar validações ou migrar uma parte do fluxo. Se o contrato público continuar compatível, o aplicativo consumidor não precisa saber da cirurgia interna.

É o princípio do strangler pattern: em vez de demolir um sistema inteiro num fim de semana heroico — geralmente seguido de uma segunda-feira traumática — a empresa cerca, substitui ou reorganiza partes aos poucos, mantendo o negócio funcionando.

8. Segurança: a porta moderna precisa ser mais forte, não mais aberta

Expor um serviço de mainframe não significa colocar uma transação CICS diretamente na internet e confiar no bom coração dos robôs. Uma arquitetura séria inclui autenticação, autorização, TLS, rate limiting, auditoria e mascaramento de dados.

Uma resposta para um app não deve devolver ASRA, S0C7, SQLCODE -805 ou o nome da tabela interna. Essas informações são valiosas para diagnóstico, mas péssimas como interface externa e potencialmente úteis para um atacante.

Em vez disso:

{
  "status": "ERROR",
  "code": "EMPLOYEE_NOT_FOUND",
  "message": "Employee was not found."
}

Do lado interno, a equipe mantém o detalhe: correlation ID, usuário técnico, horário, URI, transação CICS, programa chamado, SQLCODE e logs de segurança. Um bom correlation ID é a etiqueta de bagagem da transação: ele permite seguir a mesma solicitação do celular até o programa COBOL, passando pelo gateway e pelo CICS.

Também vale a dica de Watson para qualquer iniciante: não coloque segredo no código. Senhas, tokens, certificados e chaves de API precisam de gestão apropriada, rotação e controle de acesso. Um segredo em fonte COBOL é apenas um incidente aguardando o próximo upload ou print de tela.

9. Passo a passo: como transformar uma regra COBOL em serviço

Vamos supor que a empresa quer publicar a consulta resumida de folha de um funcionário.

Descubra a capacidade de negócio. Não comece pelo programa. Comece pela pergunta: “o que o canal digital precisa saber?”. Aqui: consultar o resumo de folha de um funcionário autorizado.
Mapeie a regra existente. Qual programa COBOL calcula ou consulta o dado? Ele recebe COMMAREA? Usa CHANNEL/CONTAINER? Chama outros módulos? Consulta Db2, VSAM ou IMS? Possui efeitos colaterais?
Defina o contrato da API. Nome, URI, método HTTP, campos obrigatórios, tipos, respostas, erros, versão e exemplos. Um contrato bem escrito é uma peça de engenharia, não burocracia.
Crie uma camada adaptadora se necessário. O programa antigo não precisa ser mutilado para ficar bonito para a API. Um programa ou serviço adaptador pode receber a estrutura externa, validar, chamar a regra existente e montar a resposta.
Implemente o mapeamento. Decida como cada campo JSON vira uma variável COBOL e como cada resultado vira JSON. Documente regras de nulo, espaços, zeros, datas, arredondamento e caracteres.
Proteja a entrada. Autentique o cliente, autorize a operação, valide tamanhos e conteúdo. Não deixe um campo de 40 caracteres cair numa área de 10 porque “em homologação funcionou”.
Teste o caminho feliz e o caminho humano. O caminho feliz é funcionário existente, valor válido e infraestrutura saudável. O caminho humano inclui ID inexistente, requisição duplicada, JSON malformado, campo ausente, timeout, Db2 indisponível, acesso não autorizado e caracteres especiais.
Observe a operação. Inclua logs, métricas, traces e correlation ID. Uma API que funciona só quando alguém está olhando o console não está pronta para produção.
Publique sem quebrar consumidores. Se a versão 1 está em uso, não renomeie um campo de uma hora para outra. Versione, mantenha compatibilidade durante a transição e avise quem consome.
Meça o resultado. Tempo de resposta, volume, erros por tipo, picos, dependências e impacto no CICS/Db2. Modernização sem observabilidade é apenas uma aposta com interface bonita.

10. O que o COBOL iniciante deve aprender primeiro

Você não precisa dominar todos os produtos antes de entender a arquitetura. Comece construindo o mapa mental:

um programa COBOL recebe dados e devolve dados;
CICS coordena muitos programas online e protege a transação;
COMMAREA e CHANNEL/CONTAINER são formas de passar dados entre componentes CICS;
Db2, VSAM e IMS são fontes comuns de dados e regras;
HTTP/HTTPS levam a chamada;
JSON é o envelope legível pelo aplicativo moderno;
uma API estabelece contrato, segurança e governança.

Depois, pratique separação de responsabilidades. Faça um programa COBOL que receba uma estrutura simples, valide um identificador, consulte um dado fictício ou Db2 de laboratório e devolva códigos de retorno claros. Em seguida, imagine como ele seria chamado por uma API. O salto mental mais importante não é decorar cada comando: é aprender a distinguir interface externa, regra de negócio e acesso a dados.

Epílogo — A conclusão de Watson

No fim do caso, o Dr. Watson fechou o caderno.

“Então o COBOL não está sobrevivendo apesar do mundo moderno. Ele pode participar dele porque sua regra continua útil — desde que alguém construa a ponte corretamente.”

Holmes assentiu.

“Precisamente. A tecnologia nova não apaga a necessidade de uma regra correta. Apenas aumenta a velocidade com que uma regra errada consegue chegar ao celular de milhões de pessoas.”

Essa é a grande lição. Modernizar COBOL não significa transformar todo programa em moda tecnológica nem tratar o mainframe como peça de museu. Significa criar integrações bem projetadas, seguras, observáveis e com contratos claros, preservando o que já funciona e mudando aquilo que precisa mudar.

O celular pode ter uma tela brilhante. O gateway pode estar na cloud. A resposta pode vir em JSON. Mas, no coração do processo, pode continuar existindo um programa COBOL que conhece a regra, protege o dado e não se impressiona com o último framework lançado numa sexta-feira.

E, quando a transação precisa fechar corretamente, Watson, é melhor que ele não se impressione mesmo.

sexta-feira, 23 de dezembro de 2022

Java no IBM Z: Como Java Conversa com COBOL, DB2, CICS e o Mundo Mainframe na Prática

Bellacosa Mainframe como java conversa com o mainframe

☕ Um Café no Bellacosa Mainframe

Java no IBM Z: Como Java Conversa com COBOL, DB2, CICS e o Mundo Mainframe na Prática

"O Java não chegou para substituir o COBOL. Ele chegou para conversar com ele."

Existe uma lenda que circula há muitos anos entre profissionais de TI.

Ela diz que existem dois mundos completamente diferentes.

De um lado está o mundo Mainframe.

Do outro está o mundo Java.

Na realidade... isso nunca foi verdade.

Hoje, milhares de bancos, seguradoras, governos e bolsas de valores executam aplicações onde Java, COBOL, CICS, DB2, MQ, z/OS Connect e APIs REST trabalham juntos no mesmo IBM Z.

A pergunta deixou de ser:

"Java ou COBOL?"

e passou a ser:

"Como fazer ambos trabalharem juntos?"

Pegue seu café porque hoje vamos abrir a tampa do motor do IBM Z.

A chegada do Java ao Mainframe

Quando Java apareceu em 1995, muitos profissionais de Mainframe olharam com desconfiança.

"Uma linguagem interpretada?"

"Rodando em máquina virtual?"

"Orientada a objetos?"

Parecia impossível competir com COBOL compilado.

Mas havia um detalhe importante.

Java tinha uma vantagem gigantesca.

Escrever uma vez, executar em qualquer lugar

A JVM (Java Virtual Machine) permitia que o mesmo programa funcionasse em:

Windows
Linux
Unix
AIX
IBM Z

A IBM rapidamente percebeu que clientes desejariam executar Java perto dos dados.

E onde estavam os dados?

No DB2.

No VSAM.

No IMS.

No CICS.

No MQ.

Ou seja...

Java precisava ir até o Mainframe.

Não fazia sentido mover bilhões de registros para outro servidor.

Muito mais eficiente era mover o processamento.

O nascimento do Java no z/OS

A IBM portou a JVM para o z/OS.

Depois vieram:

IBM SDK for Java
JZOS
JDBC para DB2
CICS Java
Liberty
WebSphere
OpenJ9 JVM

Hoje Java é cidadão de primeira classe dentro do IBM Z.

A arquitetura moderna

Imagine um banco.

Cliente Web

      │

 REST API

      │

 Liberty

      │

 Java

      │

 JDBC

      │

 DB2

Agora imagine outro fluxo.

Cliente

↓

CICS

↓

Programa Java

↓

Programa COBOL

↓

DB2

Ou ainda

Java

↓

MQ

↓

COBOL

↓

IMS

Java

↓

z/OS Connect

↓

CICS

↓

COBOL

↓

VSAM

Perceba.

O Java raramente trabalha sozinho.

Ele normalmente atua como a camada de integração.

JDBC

JDBC significa:

Java Database Connectivity

É a API padrão do Java para conversar com bancos de dados.

No Mainframe ela conversa principalmente com o DB2.

Exemplo

Connection conn =
DriverManager.getConnection(
"jdbc:db2://servidor:446/BANCO",
"usuario",
"senha");

A partir daí...

PreparedStatement ps =
conn.prepareStatement(
"SELECT NOME,SALDO FROM CLIENTE WHERE ID=?");

ps.setInt(1,100);

ResultSet rs = ps.executeQuery();

Enquanto houver registros

while(rs.next()){

System.out.println(
rs.getString("NOME"));

}

Isso parece simples.

Mas por trás existe uma enorme infraestrutura.

O Driver JDBC

O Driver JDBC entende dois idiomas.

Ele fala Java.

E fala DB2.

É literalmente um tradutor.

Java

↓

Driver JDBC

↓

DRDA

↓

DB2

O desenvolvedor escreve SQL.

O Driver transforma isso em chamadas compreendidas pelo DB2.

O Prepared Statement

No Mainframe quase nunca usamos:

Statement

Preferimos:

PreparedStatement

Por quê?

Porque:

reutiliza plano de acesso
melhora performance
evita SQL Injection
reduz parsing

Exemplo

SELECT *
FROM CLIENTE
WHERE CPF=?

O ponto de interrogação representa um parâmetro.

Como Java conversa com DB2

Internamente ocorre algo semelhante.

Java

↓

JDBC

↓

DRDA

↓

DB2 Thread

↓

Buffer Pool

↓

Tablespace

O Java nunca lê páginas do banco.

Quem faz isso é o DB2.

Como COBOL acessa DB2

No COBOL usamos:

EXEC SQL

SELECT NOME

INTO :WS-NOME

FROM CLIENTE

END-EXEC.

No Java:

String nome=
rs.getString("NOME");

O objetivo é exatamente o mesmo.

A tecnologia muda.

Conversão de tipos

Essa é uma das maiores dúvidas.

Como converter tipos COBOL para Java?

COBOL

PIC X(30)

Java

String

COBOL

PIC X

Java

char

String

COBOL

PIC 9(4)

Java

int

COBOL

PIC 9(9)

Java

long

COBOL

PIC S9(9)V99 COMP-3

Java

BigDecimal

Nunca utilize:

double

para dinheiro.

Sempre:

BigDecimal

Datas

COBOL

PIC X(10)

2026-07-01

Java

LocalDate

LocalDateTime

Boolean

COBOL tradicional não possui boolean.

Normalmente usa:

"S"

"N"

1

0

No Java

boolean

Estruturas COBOL

Imagine

01 CLIENTE.

   05 ID.

   05 NOME.

   05 SALDO.

No Java

class Cliente{

int id;

String nome;

BigDecimal saldo;

}

Observe a semelhança.

O Java apenas encapsula os dados dentro de uma classe.

OO versus Procedural

COBOL

LER CLIENTE

↓

VALIDAR

↓

ATUALIZAR

↓

GRAVAR

Fluxo procedural.

Java

Cliente

↓

objeto

↓

métodos

↓

atributos

Em vez de funções espalhadas,

o comportamento fica dentro do objeto.

Classe

public class Cliente{

private String nome;

private BigDecimal saldo;

public void sacar(){

}

}

A classe reúne:

dados
comportamento

O que seria uma estrutura COBOL equivalente?

WORKING-STORAGE

↓

PROCEDURE DIVISION

↓

PARÁGRAFOS

A ideia é semelhante.

Só muda a organização.

Como Java chama COBOL?

Existem diversas formas.

CICS

Java

↓

EXEC CICS LINK

↓

Programa COBOL

JNI

Java pode chamar código nativo.

MQ

Java envia mensagem.

COBOL recebe.

REST

Java chama uma API exposta pelo COBOL.

Stored Procedures

DB2 executa procedimento COBOL.

Java apenas chama.

CICS

Imagine um caixa eletrônico.

O Java recebe uma requisição REST.

POST

/saque

Java valida.

Depois

EXEC CICS LINK

para

SAQ001

escrito em COBOL.

O COBOL atualiza saldo.

Retorna.

Java transforma em JSON.

Cliente recebe resposta.

Tudo acontece em poucos milissegundos.

JSON

O Java trabalha naturalmente com JSON.

Exemplo

{
 "id":100,
 "nome":"Maria",
 "saldo":2500
}

Classe

Cliente

Bibliotecas como Jackson fazem:

Objeto

↓

JSON

↓

Objeto

automaticamente.

XML

Antes do JSON predominava XML.

<cliente>

<nome>Maria</nome>

</cliente>

Ainda muito utilizado em:

SOAP

WebServices

Integrações legadas.

Conversão COBOL para JSON

Suponha

01 CLIENTE.

05 NOME.

05 CPF.

05 SALDO.

Java monta

{
 "nome":"",
 "cpf":"",
 "saldo":0
}

O mapeamento costuma ser feito por:

Jackson
JAXB
JSON-B

Datasets

Java também pode acessar datasets.

Mas normalmente utiliza:

JZOS.

Exemplo

HLQ.CLIENTES.MASTER

O Java lê registros do dataset.

Sem necessidade de FTP.

VSAM

Também pode acessar

KSDS
ESDS
RRDS

através de APIs específicas.

Arquivos Sequenciais

Java consegue ler datasets RECFM FB.

Cada registro torna-se um array de bytes.

Depois converte.

Bytes

↓

String

↓

Objeto Java

EBCDIC versus ASCII

Outro ponto crítico.

Mainframe usa:

EBCDIC.

Java trabalha internamente em Unicode.

Então existe conversão automática.

EBCDIC

↓

Unicode

↓

String

Sem isso os caracteres apareceriam ilegíveis.

Batch Java

Pouca gente sabe.

Java também roda Batch.

JCL

//STEP1 EXEC PGM=JVMLDM86

BPXBATCH

executando

java MinhaClasse

Exemplo

//JAVA EXEC PGM=BPXBATCH
//STDENV DD *
JAVA_HOME=/usr/lpp/java
/*

O Java executa como qualquer programa batch.

Pode:

ler datasets
acessar DB2
gerar arquivos
enviar MQ
consumir APIs

Java Online

Dentro do CICS.

Ou Liberty.

Recebe milhares de requisições simultâneas.

JSP

Nos anos 2000 a IBM utilizou muito:

JSP

↓

Servlet

↓

Java

↓

DB2

A página dinâmica misturava HTML com Java.

Exemplo

<%=cliente.getNome()%>

Hoje é menos comum.

Frameworks modernos predominam.

Mas muitos sistemas bancários ainda utilizam JSP.

Servlets

O Servlet recebe a requisição.

HTTP

↓

Servlet

↓

Java

↓

DB2

Depois devolve HTML.

Ou JSON.

APIs REST

Hoje a arquitetura mais comum é

Angular

↓

REST

↓

Java

↓

COBOL

↓

DB2

O usuário nem imagina que existe COBOL.

LinuxONE

Agora entra um personagem muito importante.

O LinuxONE.

Ele compartilha praticamente a mesma arquitetura do IBM Z.

Executa:

Linux
Containers
Docker
Kubernetes
OpenShift
Java
IA

Tudo extremamente próximo do z/OS.

Isso reduz:

latência
tráfego de rede
custo

Imagine

LinuxONE

↓

Java

↓

MQ

↓

z/OS

↓

COBOL

Tudo dentro do mesmo hardware.

OpenJ9

A JVM da IBM foi otimizada.

Ela consome menos memória.

Melhora Garbage Collection.

Aproveita processadores IBM Z.

zIIP

Aqui está um dos grandes diferenciais.

Grande parte do processamento Java pode utilizar processadores zIIP.

Resultado:

mais desempenho.

Menor custo de licenciamento.

É uma das razões pelas quais muitas empresas migraram workloads Java para o IBM Z.

Um fluxo completo

Imagine uma transferência bancária.

Celular

↓

HTTPS

↓

API REST

↓

Liberty

↓

Java

↓

Validação

↓

EXEC CICS LINK

↓

COBOL

↓

DB2

↓

COMMIT

↓

Resposta COBOL

↓

Objeto Java

↓

JSON

↓

Cliente

Perceba que cada tecnologia faz aquilo em que é especialista.

Java oferece APIs, integração, orientação a objetos e desenvolvimento web.
COBOL executa regras de negócio consolidadas ao longo de décadas.
CICS coordena as transações com alta disponibilidade.
DB2 garante consistência, integridade e desempenho.
JCL agenda e executa processos batch.
MQ desacopla sistemas e permite comunicação assíncrona.
LinuxONE hospeda aplicações Java, microsserviços e containers próximos aos dados.
IBM Z fornece segurança, escalabilidade, criptografia e confiabilidade.

Não existe competição entre essas tecnologias. Existe colaboração.

Procedural x Orientado a Objetos: uma visão para quem vem do COBOL

Para um programador COBOL, pense da seguinte forma:

No COBOL você cria um programa que manipula registros.

No Java você cria um objeto que representa aquele registro e sabe operar sobre ele.

No COBOL:

LER CLIENTE
VALIDAR CLIENTE
ATUALIZAR CLIENTE
GRAVAR CLIENTE

No Java:

Cliente cliente = repositorio.buscar(id);
cliente.validar();
cliente.atualizarSaldo(valor);
repositorio.salvar(cliente);

A regra de negócio continua praticamente a mesma. O que muda é a forma de organizá-la.

O futuro

Nos últimos anos surgiram novas tecnologias como:

Jakarta EE
Spring Boot
Quarkus
Open Liberty
z/OS Connect EE
APIs REST
GraphQL
Kafka
OpenShift
Red Hat Ansible Automation Platform
IA Generativa integrada ao IBM Z

Mesmo assim, o núcleo dos sistemas bancários continua sendo, em muitos casos, o mesmo:

COBOL processando regras críticas.
CICS coordenando milhões de transações.
DB2 armazenando dados.
Java expondo serviços modernos.
LinuxONE executando aplicações cloud-native próximas ao ambiente z/OS.

Conclusão

Durante muitos anos, criou-se a falsa ideia de que Java substituiria o COBOL. A história mostrou o contrário. O IBM Z evoluiu para unir o melhor dos dois mundos.

O COBOL permanece imbatível na execução de regras de negócio críticas e estáveis. O Java tornou-se a ponte para APIs REST, aplicações web, microsserviços, integração com nuvem, processamento orientado a objetos e experiências digitais modernas.

Hoje, quando um cliente consulta o saldo pelo aplicativo do banco, dificilmente percebe a sofisticada cadeia tecnológica envolvida. Um JSON percorre uma API REST hospedada em Open Liberty, passa por classes Java, utiliza JDBC para acessar o DB2 ou aciona um programa COBOL via CICS. Em segundos, o resultado retorna ao celular com segurança, integridade transacional e disponibilidade próxima de 100%.

Esse é o verdadeiro espírito do IBM Z moderno: não substituir o legado, mas ampliá-lo. Java, COBOL, CICS, DB2, JCL, LinuxONE, APIs e containers deixaram de ser tecnologias concorrentes e passaram a formar um único ecossistema. É justamente essa capacidade de integrar décadas de investimento com inovação contínua que mantém o Mainframe como a espinha dorsal de alguns dos maiores sistemas financeiros, governamentais e corporativos do planeta. E, para o profissional de Mainframe que aprende Java, abre-se uma nova fronteira: compreender não apenas como cada tecnologia funciona isoladamente, mas como elas conversam para sustentar o mundo digital moderno.

quinta-feira, 28 de janeiro de 2021

☕💣 O DIA EM QUE O MAINFRAME GANHOU UM "SERVIDOR DE APLICAÇÕES GIGANTE": COMO WEB SERVICES CONECTAM z/OS E LINUXONE AO MUNDO MODERNO

Bellacosa Mainframe e uma visão do servidor LinuxOne no Mainframe

☕💣 O DIA EM QUE O MAINFRAME GANHOU UM "SERVIDOR DE APLICAÇÕES GIGANTE": COMO WEB SERVICES CONECTAM z/OS E LINUXONE AO MUNDO MODERNO

Introdução

Durante décadas, o Mainframe foi visto como uma fortaleza isolada. Enquanto servidores Unix, Windows e Linux dominavam o mundo da internet, o z/OS continuava processando milhões de transações bancárias, governamentais e corporativas sem precisar aparecer para o usuário final.

Mas o mundo mudou.

Aplicativos móveis precisavam consultar saldos bancários.

Sites de e-commerce precisavam verificar estoques.

APIs precisavam conversar com programas COBOL.

Microsserviços precisavam acessar dados armazenados em DB2.

Foi nesse momento que surgiu uma das arquiteturas mais interessantes da computação corporativa moderna:

LinuxONE executando aplicações web e APIs enquanto o z/OS continua processando o negócio.

Na prática, o LinuxONE tornou-se uma espécie de "porta de entrada" para o Mainframe.

Hoje vamos entender como tudo isso funciona.

A Origem do Problema

Imagine um programa COBOL criado em 1985.

Ele processa contas correntes.

Funciona perfeitamente.

Executa milhares de transações por segundo.

Mas existe um problema:

Ele não fala HTTP.

Não entende JSON.

Não sabe o que é REST.

Não conhece APIs.

O programa espera receber informações através de:

CICS
MQ
Arquivos VSAM
DB2
Transações 3270

Enquanto isso, um aplicativo Android espera algo como:

{
   "conta":"12345",
   "saldo":2500.50
}

Era necessário criar uma ponte.

Surge o LinuxONE

LinuxONE é uma plataforma Linux executando diretamente sobre hardware IBM Z.

Fisicamente ele utiliza o mesmo equipamento do Mainframe.

Porém logicamente é outro ambiente.

Podemos ter:

IBM Z

├── LPAR z/OS
│   ├── CICS
│   ├── DB2
│   ├── IMS
│   └── COBOL
│
└── LPAR LinuxONE
    ├── Apache
    ├── NGINX
    ├── Java
    ├── Spring Boot
    ├── Node.js
    └── Python

Os dois ambientes compartilham o mesmo hardware.

A comunicação ocorre internamente.

Sem sair do datacenter.

Sem atravessar a internet.

Com latência extremamente baixa.

Arquitetura Moderna

Visualmente temos:

Internet
    │
    ▼
Load Balancer
    │
    ▼
NGINX / Apache
(LinuxONE)
    │
    ▼
API REST
(Spring Boot)
    │
    ▼
IBM MQ
    │
    ▼
CICS
(z/OS)
    │
    ▼
COBOL
    │
    ▼
DB2

Observe que:

O usuário nunca acessa o COBOL diretamente.

Ele conversa com uma API.

A API conversa com o Mainframe.

O Mainframe responde.

A API devolve JSON.

O Papel do Servidor de Páginas

Normalmente utilizamos:

Apache HTTP Server
NGINX
IBM HTTP Server

Exemplo:

Cliente
   │
   ▼
Apache
   │
   ▼
Spring Boot
   │
   ▼
MQ
   │
   ▼
COBOL

O Apache recebe:

GET /clientes/123

E encaminha para a aplicação Java.

Criando uma API no LinuxONE

Suponha que queremos consultar saldo bancário.

Endpoint:

GET /saldo/12345

Aplicação Spring Boot:

@RestController
public class SaldoController {

   @GetMapping("/saldo/{conta}")
   public Saldo obterSaldo(
      @PathVariable String conta) {

      return servico.consultar(conta);
   }
}

Quando a chamada chega:

GET /saldo/12345

o Spring Boot inicia o fluxo.

Como o LinuxONE Conversa com o z/OS

Existem várias opções.

1. IBM MQ

Mais utilizada.

Fluxo:

API
 │
 ▼
MQ REQUEST
 │
 ▼
z/OS
 │
 ▼
COBOL
 │
 ▼
MQ RESPONSE
 │
 ▼
API

O Java envia mensagem.

O COBOL processa.

A resposta retorna.

Exemplo de Mensagem MQ

JSON enviado:

{
  "conta":"12345"
}

Fila:

REQ.SALDO

Resposta:

{
   "saldo":2500.50
}

Fila:

RESP.SALDO

Exemplo COBOL Consumindo MQ

Pseudo código:

CALL 'MQGET'

MOVE CONTA TO WS-CONTA

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

CALL 'MQPUT'

Comunicação Via CICS Web Services

Outra possibilidade.

O CICS pode expor serviços diretamente.

Arquitetura:

LinuxONE
   │
HTTP
   │
CICS
   │
COBOL

Nesse caso não usamos MQ.

A API chama o próprio CICS.

Exemplo de Chamada

Java:

RestTemplate rest =
    new RestTemplate();

String resposta =
    rest.getForObject(
       url,
       String.class
    );

Chamando:

https://cics.banco.com/saldo

Comunicação Via z/OS Connect

Hoje é uma das soluções mais elegantes.

Arquitetura:

Aplicativo
    │
    ▼
API REST
    │
    ▼
z/OS Connect
    │
    ▼
CICS
IMS
DB2
COBOL

O z/OS Connect converte:

JSON ↔ COBOL

automaticamente.

Exemplo

Cliente envia:

{
   "conta":"12345"
}

z/OS Connect converte para:

01 REQUISICAO.
   05 CONTA PIC X(10).

Sem programação manual.

Configurando Apache no LinuxONE

Instalação:

sudo yum install httpd

Iniciar:

systemctl start httpd

Habilitar:

systemctl enable httpd

Teste:

curl localhost

Configurando Proxy para API

Arquivo:

/etc/httpd/conf/httpd.conf

Exemplo:

ProxyPass /api http://localhost:8080

ProxyPassReverse /api
http://localhost:8080

Fluxo:

Apache
    │
    ▼
Spring Boot

Configurando Spring Boot

Aplicação:

server.port=8080

Executar:

java -jar banco.jar

Teste:

curl http://localhost:8080/saldo/12345

Configurando IBM MQ

Criar Queue Manager:

crtmqm QM1

Iniciar:

strmqm QM1

Criar fila:

DEFINE QLOCAL(REQ.SALDO)

Criar fila resposta:

DEFINE QLOCAL(RESP.SALDO)

Fluxo Completo da Transação

Passo 1

Usuário abre aplicativo.

Android

Passo 2

Aplicativo envia:

GET /saldo/12345

Passo 3

Apache recebe.

Passo 4

Apache encaminha para Spring Boot.

Passo 5

Spring Boot envia mensagem MQ.

Passo 6

MQ entrega ao z/OS.

Passo 7

COBOL processa.

Passo 8

DB2 retorna saldo.

Passo 9

COBOL responde MQ.

Passo 10

Spring Boot recebe.

Passo 11

Spring Boot gera JSON.

Passo 12

Apache devolve ao cliente.

Resultado:

{
   "conta":"12345",
   "saldo":2500.50
}

Segurança da Arquitetura

Normalmente utilizamos:

RACF

Controla acesso no z/OS.

TLS

Criptografia HTTPS.

JWT

Autenticação moderna.

OAuth2

Integração com aplicações externas.

Fluxo:

Cliente
   │
JWT
   ▼
API
   │
MQ
   ▼
COBOL

Vantagens do LinuxONE

Não altera o COBOL

O sistema continua funcionando.

Escalabilidade

Mais APIs podem ser criadas.

Segurança

Tudo permanece dentro do IBM Z.

Menor latência

Comunicação interna.

Modernização gradual

Não exige reescrever aplicações.

Caso Real de Banco

Muitos bancos utilizam:

App Mobile
      │
      ▼
Kubernetes
(LinuxONE)
      │
      ▼
APIs Java
      │
      ▼
MQ
      │
      ▼
CICS
      │
      ▼
COBOL
      │
      ▼
DB2

O cliente acredita estar falando com uma aplicação moderna.

Mas no fundo uma rotina COBOL criada décadas atrás continua executando a lógica principal do negócio.

O Futuro

Hoje vemos LinuxONE executando:

Docker
Kubernetes
OpenShift
Python
Java
Node.js
IA Generativa
APIs REST
Microsserviços

Enquanto o z/OS continua executando:

COBOL
CICS
IMS
DB2
Batch

Os dois mundos coexistem.

Não existe substituição.

Existe integração.

Conclusão

O LinuxONE transformou a forma como o Mainframe conversa com o mundo moderno. Em vez de expor diretamente aplicações COBOL, as organizações passaram a utilizar APIs REST, servidores web, microsserviços e containers executando lado a lado com o z/OS no mesmo hardware IBM Z.

Na prática, o LinuxONE atua como uma camada de apresentação e integração, enquanto o z/OS continua sendo o coração do processamento transacional. O resultado é uma arquitetura capaz de unir décadas de investimento em aplicações COBOL com tecnologias modernas como Spring Boot, Kubernetes, OpenShift, APIs REST, JSON e autenticação OAuth.

É por isso que muitos especialistas afirmam que o futuro do Mainframe não está em substituir sistemas legados, mas em conectá-los ao ecossistema digital. E nessa missão, LinuxONE e z/OS formam uma das parcerias mais poderosas já criadas dentro da computação corporativa.

segunda-feira, 2 de novembro de 2020

CICS Conversacional e Pseudo-Conversacional - Parte III

Bellacosa Mainframe e a conversação em cics parte III

☕ Um Café no Bellacosa Mainframe

CICS Conversacional e Pseudo-Conversacional

Parte 3 — Channels, Containers, BMS Avançado, APIs, Observabilidade e o Futuro do CICS

"Salve novamente, jovem Padawan Mainframe! Já entendemos por que a pseudo-conversação venceu, como a COMMAREA funciona e como o CICS se integrou ao mundo REST. Agora vamos explorar o lado mais moderno do CICS, descobrir como ele conversa com aplicações em nuvem, conhecer boas práticas utilizadas em bancos e seguradoras e entender por que muitos engenheiros consideram o CICS uma das obras-primas da engenharia de software."

Pegue seu terceiro café, deixe o CEDF ligado, abra uma aba do OMEGAMON, outra do SDSF e vamos continuar.

O problema da COMMAREA

Durante décadas a COMMAREA foi suficiente.

64 KB.

Poucos campos.

Poucos estados.

Poucos dados.

Era perfeito.

Mas o mundo mudou.

Hoje temos:

JSON

JWT

XML

SOAP

REST

Objetos complexos

Payloads gigantes

A chegada dos Channels

A IBM precisava resolver isso.

E resolveu.

CICS TS 3.1

Introduziu:

Channels

Containers

O que é um Channel?

Pense em um diretório.

CLIENTE
│
├── CPF
├── ENDERECO
├── LIMITE
├── HISTORICO
└── TOKEN

O Channel funciona exatamente assim.

Um agrupador.

Pode conter vários Containers.

O que é um Container?

Container é um objeto.

Armazena informações.

Pode conter:

Texto

XML

JSON

Estruturas COBOL

Blobs

Imagens

Arquivos

Comparativo

Tecnologia	Capacidade
COMMAREA	64 KB
TSQ	MB
Container	GB
DB2	TB

Exemplo COBOL

Criando.


EXEC CICS PUT CONTAINER

CONTAINER('CLIENTE')

CHANNEL('CADASTRO')

FROM(WS-DADOS)

FLENGTH(WS-TAM)

END-EXEC.

Recuperando.


EXEC CICS GET CONTAINER

CONTAINER('CLIENTE')

CHANNEL('CADASTRO')

INTO(WS-DADOS)

END-EXEC.

BMS continua vivo?

Muito.

Talvez mais vivo do que muita gente imagina.

Grandes bancos.

Seguradoras.

Cartões.

Previdência.

Companhias aéreas.

Utilities.

Governo.

BMS avançado

Poucos desenvolvedores usam.

SEND MAP ACCUM

Acumula telas.

Exemplo


EXEC CICS SEND MAP

ACCUM

END-EXEC

SEND PAGE

Paginação.

SEND CONTROL

Controle terminal.

ERASEAUP

Limpa apenas campos editáveis.

CURSOR

Posicionamento dinâmico.

Exemplo

Cursor no CPF.



MOVE -1 TO CPFL



EXEC CICS SEND

MAP('TELA1')

CURSOR

END-EXEC

APIs no CICS

Aqui muita gente se surpreende.

O CICS é praticamente um Application Server.

Suporta.

HTTP

HTTPS

SOAP

REST

TCP/IP

JMS

JSON

XML

Exemplo moderno

Aplicativo Android.

↓

API Gateway

↓

z/OS Connect

↓

CICS

↓

COBOL

↓

DB2

z/OS Connect

Talvez uma das melhores ideias da IBM.

Transforma.

COBOL

API REST.

Sem reescrever.

Sem Java.

Sem Node.

Sem Python.

Exemplo.

Cliente faz:

GET /clientes/123

Internamente.

CICS chama.


PERFORM CONSULTA-DB2

Retorna.

{

"id":123,

"nome":"Bellacosa"

}

Web Open Interface

WOI.

Pouco conhecido.

Muito poderoso.

Permite integração.

HTTP.

TCP.

Sockets.

Event Processing

Outro recurso fantástico.

CICS captura eventos.

Exemplo.

Cliente alterou endereço.

Evento.

Publica MQ.

Outro sistema consome.

Observabilidade

Década de 80.

Console.

Dump.

IPCS.

Hoje.

OpenTelemetry.

Prometheus.

Grafana.

OMEGAMON.

Instana.

Elastic.

Métricas interessantes

Task Time.

CPU.

Response.

DB2.

MQ.

VSAM.

O CICS morreu?

Pergunta clássica.

Resposta curta.

Não.

Resposta longa.

Muito pelo contrário.

Ele evoluiu.

Muito.

Anos 70

3270

Anos 80

BMS

Anos 90

2000

SOAP

2010

REST

2020

Containers

2025

OpenTelemetry

APIs

Cloud híbrida

Problemas comuns

COMMAREA gigante

Erro clássico.

Não usar pseudo

Aplicação lenta.

Múltiplos SEND

Desnecessário.

Não verificar RESP

Perigoso.

MDT ligado em tudo

Tráfego excessivo.

Dicas Bellacosa Mainframe

Utilize sempre

DATAONLY.

Sempre valide

RESP.

Use CEDF

Use CECI

Use Channels

Projetos novos.

Mantenha COMMAREA pequena

Nomeie MAPSET adequadamente

Exemplo.


CLI001


CLI002


CLI003

Easter Eggs Mainframe

Programadores antigos adoravam esconder mensagens.

Exemplo.



* MAY THE COBOL BE WITH YOU

Outro clássico.



* IF IT WORKS



* DON'T TOUCH

Mais um.



* WRITTEN 1987



* STILL RUNNING

Curiosidade

Diversos sistemas escritos em 1986.

Rodam hoje.

No z16.

No z17.

Praticamente sem alterações.

Trocaram.

CPU.

Storage.

Rede.

Interface.

Mas o COBOL.

Continua.

O CICS.

Continua.

O DB2.

Continua.

E milhões de transações continuam acontecendo diariamente.

Considerações finais

Aprender CICS conversacional e pseudo-conversacional é muito mais do que aprender comandos.

É entender como a IBM resolveu problemas de escalabilidade décadas antes da popularização da computação em nuvem.

É descobrir que conceitos como:

Stateless

Session Management

API Gateway

Observabilidade

Microserviços

Persistência de contexto

Já estavam presentes, de certa forma, em arquiteturas concebidas nos anos 70.

Talvez seja por isso que o CICS continue sendo uma das tecnologias mais fascinantes do IBM Z.

Porque ele não apenas sobreviveu ao tempo.

Ele evoluiu com ele.

E provavelmente continuará executando aplicações críticas quando muitos frameworks modernos já forem apenas uma nota de rodapé na história da computação.

No IBM Z, cada transação conta uma história. Cada COMMAREA guarda uma memória. E cada RETURN é apenas uma promessa de que a próxima task continuará exatamente de onde paramos.

Até o próximo café no Bellacosa Mainframe.

sexta-feira, 4 de setembro de 2020

CICS Conversacional e Pseudo-Conversacional - Parte II

Bellacosa Mainframe e a conversação em cics parte II

☕ Um Café no Bellacosa Mainframe

CICS Conversacional e Pseudo-Conversacional

Parte 2 — Escalabilidade, COMMAREA, Channels, Web Services e Boas Práticas

"Na primeira parte aprendemos que programas conversacionais gostam de ficar esperando o usuário pensar, enquanto programas pseudo-conversacionais executam como ninjas do IBM Z: aparecem, trabalham, desaparecem e retornam apenas quando necessários. Agora vamos entender por que a IBM praticamente transformou a pseudo-conversação em padrão de mercado."

Pegue mais um café, abra o CEDF, deixe o CEMT pronto e vamos continuar nossa jornada.

Os problemas do modelo Conversacional

O modelo conversacional é elegante.

É simples.

É intuitivo.

Mas infelizmente é extremamente caro.

Vamos imaginar um banco.

Cenário

50.000 usuários.

Cada usuário demora:

20 segundos

para preencher uma tela.

Aplicação Conversacional

Programa fica ativo.

Task permanece viva.

TCB permanece associado.

TCA permanece ocupada.

Storage continua reservado.

EIB continua residente.

Tudo isso...

Durante vinte segundos.

Resultado

Pouca escalabilidade.

Maior uso de CPU.

Maior consumo de memória.

Possibilidade de gargalos.

O fenômeno Think Time

Um dos maiores inimigos do CICS.

Think Time.

Tempo em que o usuário está apenas pensando.

Exemplos:

Lendo uma tela.

Pegando um documento.

Atendendo telefone.

Procurando CPF.

Conversando com cliente.

Conversacional

Think Time = recursos desperdiçados

Pseudo

Think Time = recursos liberados

A IBM fez uma escolha inteligente

Ao invés de esperar.

Finaliza a task.

Salva contexto.

Cria nova task depois.

Visualmente:

Task 1

Mostra tela

RETURN


=================


Usuário pensa


=================


Task 2


Recebe dados


Processa


RETURN

Múltiplas telas

Poucos desenvolvedores COBOL iniciantes percebem.

Uma pseudo-conversação pode navegar por dezenas de telas.

Exemplo:

Consulta

Inclusão

Alteração

Confirmação

Resumo

Help

Paginação

Exemplo

↓

PF5

↓

CONSULTA

↓

ENTER

↓

DETALHE

↓

PF3

↓

Tudo utilizando.

COMMAREA.

COMMAREA

Provavelmente um dos conceitos mais importantes do CICS.

Ela guarda estado.

Entre uma task.

E outra.

Exemplo:


01 WS-COMM.

   05 WS-MODO PIC X.

   05 WS-PAGINA PIC 99.

   05 WS-CPF PIC 9(11).

   05 WS-NOME PIC X(30).

Limitação

COMMAREA possui limite.

64 KB.

Antigamente

Era suficiente.

Hoje.

JSON.

REST.

SOAP.

XML.

JWT.

Podem ultrapassar facilmente.

64 KB.

Surge Channels e Containers

Introduzidos para resolver isso.

COMMAREA

64 KB

Container

Gigabytes.

Exemplo


EXEC CICS PUT CONTAINER

CONTAINER('CLIENTE')

FROM(WS-DADOS)

END-EXEC

Recuperando.


EXEC CICS GET CONTAINER

CONTAINER('CLIENTE')

INTO(WS-DADOS)

END-EXEC

Qual utilizar?

Sistemas antigos

COMMAREA

Novos projetos

Channels

Containers

EIBCALEN

Nos projetos antigos.

Era rei.



IF EIBCALEN = ZERO


PERFORM PRIMEIRA-VEZ


ELSE


PERFORM RETORNO


END-IF

Pseudo-Conversação com BMS

Fluxo típico.

SEND MAP

↓

RETURN

↓

Usuário ENTER

↓

Nova Task

↓

RECEIVE

↓

DB2

↓

SEND

↓

RETURN

Web Services no CICS

Muitos acreditam.

Que CICS é apenas 3270.

Isso está muito longe da realidade.

CICS suporta.

SOAP.

REST.

JSON.

XML.

MQ.

JMS.

TCP/IP.

HTTP.

HTTPS.

Exemplo

Angular

↓

API

↓

zOS Connect

↓

CICS

↓

COBOL

↓

DB2

Visualmente



Browser


   │


REST API


   │


zOS Connect


   │


CICS


   │


COBOL


   │


DB2

O COBOL muda?

Quase nada.

Exemplo


PERFORM VALIDA


PERFORM CONSULTA-DB2


PERFORM RETORNA-DADOS

Interface muda.

Negócio permanece.

SOAP

Muito usado.

Seguradoras.

Governo.

ERP.

REST

Dominante.

OpenAPI.

Swagger.

JSON.

BMS ainda é importante?

Sim.

Muito.

Milhares de aplicações.

Continuam em produção.

Além disso.

BMS ensina.

Arquitetura.

Separação de responsabilidades.

Persistência de contexto.

Gerenciamento de estado.

Problemas comuns

MAPFAIL

Usuário apertou PF3.

Sem alterar dados.

INVREQ

Sequência incorreta.

LENGERR

Área pequena.

ASRA

S0C7.

S0C4.

S0CB.

Como debugar?

CEDF.

Excelente.


CEDF ON

Programa para.

Comando por comando.

CECI

Muito útil.

Exemplo


CECI RECEIVE MAP

CEMT

Consultar recursos.


CEMT I TASK


CEMT I PROG


CEMT I TRAN

Boas práticas

Sempre usar pseudo-conversação

Utilizar COMMAREA pequena

Preferir Containers

Projetos novos.

Não salvar tabelas grandes

Na COMMAREA.

Usar MDT apenas quando necessário

Utilizar DATAONLY

Reduz tráfego.

Evitar múltiplos SEND

Na mesma task.

Validar EIBRESP

Sempre.

Exemplo



IF EIBRESP NOT = DFHRESP(NORMAL)

PERFORM TRATA-ERRO


END-IF

Curiosidade Bellacosa Mainframe

Alguns bancos possuem aplicações pseudo-conversacionais escritas em 1986.

Elas foram migradas.

De 3090.

Para 9672.

Para z900.

Para z990.

Para z9.

Para z10.

Para z14.

Para z16.

E continuam praticamente inalteradas.

Easter Egg Mainframe

Nos anos 80.

Muitos desenvolvedores colocavam comentários curiosos.

Exemplo.



* MAY THE COBOL BE WITH YOU

Ou.



* DO NOT TOUCH


* WORKS SINCE 1987

Ou o clássico.



* IF YOU CHANGE THIS


* BUY COFFEE FOR THE TEAM

Continua...

Na Parte 3 veremos:

✔ Web Open Interface (WOI);

✔ CICS Event Processing;

✔ Programas COBOL completos;

✔ Pseudo-conversação com múltiplos MAPSETs;

✔ BMS avançado;

✔ Channels versus TSQ;

✔ Segurança RACF;

✔ Web Services SOAP e REST detalhados;

✔ Observabilidade moderna;

✔ OpenTelemetry;

✔ Curiosidades e easter eggs pouco conhecidos do universo CICS.

sexta-feira, 13 de março de 2020

☕💣 APIs RESTful: O Dia em Que os Sistemas Descobriram Como Conversar Sem Trocar JCL

Bellacosa Mainframe introdução a API RestFul

☕💣 APIs RESTful: O Dia em Que os Sistemas Descobriram Como Conversar Sem Trocar JCL

Imagine a seguinte situação.

Você está em um banco em 1985. Um programa COBOL executando em um IBM Mainframe processa milhões de transações diariamente. Tudo funciona perfeitamente.

Agora avance para 2026.

O mesmo banco continua utilizando COBOL, CICS, DB2 e z/OS para movimentar bilhões de dólares todos os dias. Porém, existe um detalhe importante: os clientes não acessam mais o sistema através de terminais 3270.

Eles utilizam aplicativos móveis, internet banking, chatbots, APIs, inteligência artificial e até relógios inteligentes.

A pergunta é:

Como um aplicativo moderno conversa com um sistema desenvolvido há décadas?

A resposta, em grande parte dos casos, está em uma tecnologia chamada API RESTful.

Hoje vamos conhecer sua história, origem, criador, funcionamento, curiosidades e entender por que ela se tornou uma das tecnologias mais importantes da computação moderna.

O Que é uma API?

API significa:

Application Programming Interface

Interface de Programação de Aplicações.

Uma API é um conjunto de regras que permite que dois sistemas conversem entre si.

Pense nela como um atendente de restaurante.

Você não entra na cozinha para preparar sua comida.

Você faz um pedido ao garçom.

O garçom leva o pedido.

A cozinha processa.

O garçom retorna o resultado.

A API faz exatamente isso.

Ela recebe solicitações.

Encaminha para o sistema responsável.

Obtém uma resposta.

Entrega o resultado ao solicitante.

O Que Significa REST?

REST significa:

Representational State Transfer

O termo surgiu oficialmente em:

Ano: 2000

Criado por:

Roy Thomas Fielding

Durante sua tese de doutorado na Universidade da Califórnia (UC Irvine).

O trabalho recebeu o nome:

Architectural Styles and the Design of Network-based Software Architectures

Nele, Fielding descreveu um conjunto de princípios para criar sistemas distribuídos mais simples, escaláveis e independentes.

Curiosamente, REST não é uma tecnologia.

Não é um produto.

Não é um software.

Não é um protocolo.

É um estilo arquitetural.

Quem é Roy Fielding?

Roy Fielding é uma das figuras mais importantes da história da Internet.

Além de criar o conceito REST, ele também participou da especificação de tecnologias fundamentais da Web.

Entre elas:

HTTP 1.0
HTTP 1.1
URI
Apache HTTP Server

Sim.

O mesmo protocolo HTTP que usamos diariamente para acessar sites recebeu contribuições diretas do criador do REST.

Poucas pessoas sabem disso.

Data de Criação

O conceito REST foi publicado oficialmente em:

2000

Portanto, em 2026, o REST possui:

26 anos de existência

Mesmo assim continua sendo a arquitetura dominante para integração de sistemas.

Algo raro em tecnologia.

Existe uma Versão do REST?

Não.

Esse é um detalhe interessante.

REST não possui:

Release 1
Release 2
Versão 10

REST é apenas um conjunto de princípios arquiteturais.

O que evolui são as tecnologias utilizadas ao seu redor:

HTTP
JSON
XML
OpenAPI
Swagger
OAuth
JWT

Por isso não existe algo como:

"REST versão 3.0"

Como Funciona uma API RESTful?

Uma API RESTful utiliza recursos identificados por URLs.

Exemplos:

/clientes
/contas
/cartoes
/emprestimos

Cada URL representa um recurso.

O cliente realiza operações utilizando métodos HTTP.

Os Principais Métodos HTTP

GET

Utilizado para consultar informações.

Exemplo:

GET /clientes/1001

Resposta:

{
  "codigo":1001,
  "nome":"João Silva"
}

POST

Utilizado para criar registros.

Exemplo:

POST /clientes

PUT

Atualiza um recurso existente.

Exemplo:

PUT /clientes/1001

DELETE

Remove um recurso.

Exemplo:

DELETE /clientes/1001

Uma Analogia Mainframe

Imagine um sistema CICS.

No passado, um terminal 3270 enviava uma transação.

Hoje um aplicativo celular faz uma chamada REST.

Fluxo:

App Mobile
      |
      v
API REST
      |
      v
CICS
      |
      v
COBOL
      |
      v
DB2

Para o programa COBOL, pouco muda.

Ele continua processando regras de negócio.

A diferença está na forma de acesso.

Por Que REST Ficou Tão Popular?

Antes do REST, muitas integrações utilizavam:

RPC
CORBA
DCOM
SOAP

Essas tecnologias eram poderosas, porém complexas.

REST trouxe:

Simplicidade
Escalabilidade
Facilidade de implementação
Menor consumo de recursos

O resultado foi uma adoção massiva.

O Papel do JSON

Embora REST não exija JSON, ambos praticamente cresceram juntos.

JSON significa:

JavaScript Object Notation

Exemplo:

{
  "conta":"12345",
  "saldo":1500.75
}

Comparado ao XML:

<conta>
   <numero>12345</numero>
   <saldo>1500.75</saldo>
</conta>

JSON é menor, mais simples e mais rápido de processar.

Por isso tornou-se o padrão de mercado.

Características Obrigatórias do REST

Roy Fielding definiu restrições importantes.

Cliente-Servidor

Cliente e servidor são independentes.

O aplicativo não precisa conhecer detalhes internos do sistema.

Stateless

Cada requisição deve conter todas as informações necessárias.

O servidor não depende de estados anteriores.

Essa característica facilita escalabilidade.

Cache

Respostas podem ser armazenadas temporariamente.

Isso reduz processamento e tráfego.

Interface Uniforme

Todas as APIs seguem padrões semelhantes.

Isso facilita aprendizado e manutenção.

Sistema em Camadas

O cliente não sabe quantos componentes existem entre ele e o servidor.

Pode haver:

Firewalls
Gateways
Balanceadores
Proxies

Tudo permanece transparente.

REST e o Mundo Mainframe

Muitos profissionais acreditam que REST e Mainframe são mundos diferentes.

Nada poderia estar mais distante da realidade.

Hoje encontramos APIs REST acessando:

COBOL
PL/I
Natural
CICS
IMS
DB2
VSAM

Praticamente todos os grandes bancos utilizam essa arquitetura.

Exemplo Real

Imagine um aplicativo bancário.

Quando o cliente consulta saldo:

GET /contas/123456/saldo

A API recebe a solicitação.

Ela chama um serviço no CICS.

O CICS executa um programa COBOL.

O COBOL consulta DB2.

O resultado retorna em JSON.

O cliente vê o saldo instantaneamente.

Tudo em poucos milissegundos.

REST no z/OS

Atualmente existem diversas tecnologias IBM para expor aplicações como APIs.

Entre elas:

z/OS Connect
CICS Web Services
CICS REST APIs
IBM API Connect
IMS Connect
MQ REST Gateway

Essas ferramentas transformam aplicações legadas em serviços modernos.

Curiosidade Histórica

Muitos dos sistemas considerados "modernos" dependem diretamente de aplicações desenvolvidas há décadas.

Quando você:

Faz um PIX
Passa cartão
Compra passagem aérea
Faz saque bancário

Existe uma grande chance de um programa COBOL estar envolvido.

E frequentemente o acesso ocorre através de APIs REST.

REST vs SOAP

Uma comparação clássica.

REST	SOAP
Simples	Complexo
Leve	Pesado
JSON	XML
Fácil adoção	Configuração extensa
Mais popular atualmente	Muito usado em legado corporativo

Apesar disso, SOAP continua presente em diversos ambientes bancários.

Segurança em APIs REST

Uma API aberta seria extremamente perigosa.

Por isso existem mecanismos de proteção.

Os principais:

HTTPS
OAuth 2.0
JWT
API Keys
OpenID Connect

Eles garantem:

Autenticação
Autorização
Criptografia
Auditoria

REST e a Era da Inteligência Artificial

A explosão da IA aumentou ainda mais a importância das APIs.

Quando um chatbot consulta informações de um sistema corporativo, normalmente utiliza APIs.

Quando um assistente virtual consulta saldo bancário, utiliza APIs.

Quando aplicações integram modelos de IA com sistemas empresariais, utilizam APIs.

REST tornou-se o idioma universal da integração digital.

O Futuro do REST

Novas tecnologias surgiram.

Entre elas:

GraphQL
gRPC
AsyncAPI

Mesmo assim, REST continua dominante.

O motivo é simples.

Bilhões de aplicações já utilizam esse modelo.

Sua simplicidade continua sendo sua maior vantagem.

Conclusão

APIs RESTful representam uma das maiores revoluções silenciosas da computação moderna.

Criadas por Roy Fielding em 2000, elas permitiram que sistemas de diferentes gerações passassem a conversar de maneira simples, eficiente e padronizada.

Graças ao REST, aplicativos móveis conseguem acessar programas COBOL.

Plataformas de IA conseguem consultar sistemas bancários.

Empresas integram milhares de aplicações diariamente.

E o mais curioso:

Enquanto muita gente acredita que o Mainframe ficou preso ao passado, ele continua movimentando a economia mundial utilizando tecnologias modernas de integração.

Afinal, por trás de muitos aplicativos considerados revolucionários existe algo extremamente familiar para nós, mainframeiros:

um programa COBOL processando regras de negócio com a mesma confiabilidade de décadas atrás.

A diferença é que agora ele conversa com o mundo através de APIs RESTful.

☕💣 Moral da história: REST não substituiu o Mainframe. Pelo contrário. Tornou-se uma das principais pontes que conectam a robustez do COBOL, CICS e DB2 ao universo de aplicativos, nuvem, microsserviços e inteligência artificial.

segunda-feira, 12 de março de 2007

O que são APIs e seu Uso no Mainframe?

Bellacosa Mainframe apresenta API na Stack Mainframe

O que são APIs e seu Uso no Mainframe?

As APIs (Application Programming Interfaces) revolucionaram a forma como sistemas trocam informações. Hoje, elas são a principal ponte entre aplicações modernas, dispositivos móveis, plataformas Cloud e os sistemas Mainframe que processam as operações mais críticas do mundo.

Quando você consulta saldo pelo celular, faz um PIX, compra com cartão ou utiliza um aplicativo bancário, existe uma grande chance de uma API estar conversando com um programa COBOL executando em um Mainframe IBM Z.

O que é uma API?

API significa:

Application Programming Interface

Ou seja:

Interface de Programação de Aplicações

É um conjunto de regras que permite que um sistema solicite serviços ou informações de outro sistema.

Analogia Simples

Imagine um restaurante:

Cliente
   ↓
Garçom
   ↓
Cozinha
   ↓
Resposta

Nesse cenário:

Cliente = Aplicação
Garçom = API
Cozinha = Sistema Mainframe

A API recebe o pedido, encaminha para o sistema correto e devolve a resposta.

Exemplo do Dia a Dia

Aplicativo bancário:

App Mobile
      ↓
API
      ↓
COBOL
      ↓
DB2
      ↓
Resposta

O cliente vê apenas a tela do aplicativo.

Nos bastidores, uma API conversa com o Mainframe.

Por que APIs são importantes?

Antes das APIs, a integração era feita através de:

Arquivos
FTP
MQ
Batch
Troca de datasets

Essas soluções funcionavam, mas eram mais lentas e complexas.

As APIs permitem:

✅ Integração em tempo real

✅ Menor acoplamento

✅ Reutilização de serviços

✅ Facilidade de manutenção

✅ Integração com Cloud

Principais Tipos de API

REST

O mais utilizado atualmente.

Comunica-se normalmente usando:

HTTP
HTTPS
JSON

Exemplo:

GET /clientes/1001

Resposta:

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

SOAP

Muito utilizado em Mainframe.

Baseado em:

XML
WSDL
HTTP

Exemplo:

<ConsultaSaldo>
   <Conta>12345</Conta>
</ConsultaSaldo>

GraphQL

Mais moderno.

Permite solicitar apenas os dados necessários.

APIs e o Mainframe

O Mainframe tradicionalmente trabalha com:

COBOL
CICS
IMS
DB2
VSAM

As APIs funcionam como uma camada de integração.

Arquitetura Moderna

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

Como o Mainframe Consome APIs?

Existem dois cenários.

1. Mainframe Expondo APIs

O COBOL oferece serviços para outros sistemas.

Exemplo:

Programa COBOL
      ↓
API REST
      ↓
Aplicativo Mobile

2. Mainframe Consumindo APIs

O COBOL chama um serviço externo.

Exemplo:

COBOL
   ↓
API Correios
   ↓
Consulta CEP

APIs REST no Mainframe

Hoje são extremamente comuns.

Utilizam:

HTTP
HTTPS
JSON
REST

Métodos HTTP

GET

Consulta dados.

GET /clientes

POST

Inclui dados.

POST /clientes

PUT

Atualiza dados.

PUT /clientes/1001

DELETE

Remove dados.

DELETE /clientes/1001

JSON e COBOL

Uma integração moderna normalmente utiliza:

JSON
   ↓
JSON PARSE
   ↓
COBOL

ou:

COBOL
   ↓
JSON GENERATE
   ↓
API

z/OS Connect

Uma das tecnologias mais importantes da IBM atualmente.

Permite transformar:

Programa COBOL

API REST

sem reescrever a aplicação.

Fluxo com z/OS Connect

Cliente REST
        ↓
JSON
        ↓
z/OS Connect
        ↓
Copybook COBOL
        ↓
Programa COBOL
        ↓
DB2

APIs e CICS

O CICS possui suporte para:

REST
JSON
SOAP
HTTP
Web Services

Exemplo:

REST API
    ↓
CICS
    ↓
COBOL

APIs e IMS

O IMS também pode ser exposto através de APIs.

Exemplo:

API REST
      ↓
IMS Connect
      ↓
IMS TM
      ↓
Programa COBOL

APIs e DB2

Consultas podem ser disponibilizadas através de APIs.

Exemplo:

SELECT SALDO
FROM CLIENTES

↓

{
  "saldo":5000
}

Open Banking e APIs

Grande parte do Open Finance utiliza:

REST
JSON
OAuth
TLS

integrados ao Mainframe.

Segurança das APIs

Aspecto fundamental.

Normalmente utilizam:

HTTPS
TLS
OAuth 2.0
JWT
Certificados Digitais
RACF

Exemplo de Fluxo Seguro

App
 ↓
OAuth
 ↓
API
 ↓
RACF
 ↓
COBOL

Benefícios para o Mainframe

✅ Modernização sem reescrever COBOL

✅ Integração com Cloud

✅ Integração Mobile

✅ Exposição de serviços legados

✅ Reutilização de regras de negócio

✅ Menor custo de transformação digital

Desafios

❌ Segurança

❌ Governança

❌ Controle de versões

❌ Performance

❌ Monitoramento

Tecnologias Comuns

Tecnologia	Função
REST	APIs modernas
JSON	Formato de dados
SOAP	Web Services XML
z/OS Connect	Expor COBOL como API
CICS	Processamento transacional
IMS Connect	APIs para IMS
DB2	Banco de dados
RACF	Segurança

Curiosidade

Muitos bancos processam milhões de chamadas de APIs por dia que, nos bastidores, executam programas COBOL escritos há décadas. O aplicativo parece moderno, mas a regra de negócio continua protegida e executada no Mainframe.

Resumo Rápido

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

Conclusão

As APIs são interfaces que permitem a comunicação entre sistemas. No Mainframe, elas desempenham um papel essencial na modernização das aplicações COBOL, conectando sistemas IBM Z a aplicativos móveis, plataformas Cloud, microsserviços e ecossistemas digitais modernos. Tecnologias como REST, JSON, CICS Web Services, IMS Connect e z/OS Connect tornaram possível integrar décadas de investimento em Mainframe ao mundo das APIs de forma segura, escalável e eficiente.

Translate

domingo, 21 de janeiro de 2024