 |
| Bellacosa Mainframe e o json no cobol |
☕ Um Café no Bellacosa Mainframe
JSON no COBOL Mainframe
O Guia Definitivo para um Programador Padawan Entender Como o IBM Z Conversa com o Mundo Moderno
"O COBOL nunca teve dificuldade em processar dados. O desafio sempre foi aprender novos idiomas. JSON é apenas mais um idioma."
Introdução
Durante décadas, o mundo Mainframe conversou utilizando formatos extremamente bem definidos.
Arquivos VSAM.
Registros fixos.
Copybooks.
Layouts COBOL.
MQ.
CICS COMMAREA.
IMS.
Tudo extremamente organizado.
Enquanto isso, o restante do mercado passou a utilizar um formato muito mais simples para troca de informações:
JSON (JavaScript Object Notation).
Hoje praticamente toda API REST utiliza JSON.
Aplicativos móveis.
Sites.
Microsserviços.
Open Banking.
Pix.
Cloud.
Inteligência Artificial.
ChatGPT.
IBM watsonx.
Todos utilizam JSON.
E é justamente por isso que um programador COBOL moderno precisa dominar este formato.
A boa notícia?
Desde o Enterprise COBOL V6, a IBM adicionou suporte nativo através dos comandos:
JSON PARSE
JSON GENERATE
Sem bibliotecas externas.
Sem escrever um parser manual.
Sem sofrimento.
O que é JSON?
JSON é simplesmente uma forma de representar dados usando pares:
nome : valor
Exemplo:
{
"cliente": "João",
"idade": 35,
"saldo": 1250.75,
"ativo": true
}
Perceba que ele lembra um registro COBOL.
No COBOL escreveríamos:
01 CLIENTE.
05 NOME PIC X(30).
05 IDADE PIC 9(3).
05 SALDO PIC 9(7)V99.
05 ATIVO PIC X.
A diferença é apenas o formato.
JSON x Copybook
Um copybook descreve campos.
JSON descreve informações.
Copybook:
05 NOME PIC X(30).
JSON
"nome":"Maria"
A IBM simplesmente faz o mapeamento entre ambos.
Estrutura básica
Um objeto:
{
"nome":"Maria",
"idade":28
}
Um vetor
{
"telefones":[
"1111",
"2222"
]
}
Objeto dentro de objeto
{
"cliente":{
"nome":"Carlos",
"cidade":"São Paulo"
}
}
Tudo isso pode ser representado em COBOL.
Como declarar no COBOL
01 WS-CLIENTE.
05 WS-NOME PIC X(30).
05 WS-IDADE PIC 999.
05 WS-SALDO PIC 9(7)V99.
05 WS-ATIVO PIC X.
Agora um campo contendo o JSON.
01 WS-JSON.
05 WS-DADOS PIC X(5000).
Este será o buffer utilizado para leitura ou gravação.
Lendo JSON
Imagine receber:
{
"nome":"Luke",
"idade":22,
"saldo":1500.50,
"ativo":"S"
}
Basta executar:
JSON PARSE WS-DADOS
INTO WS-CLIENTE
END-JSON
Pronto.
A IBM faz todo o trabalho.
Após isso:
WS-NOME = LUKE
WS-IDADE = 22
WS-SALDO = 1500.50
WS-ATIVO = S
Sem IF.
Sem UNSTRING.
Sem parser.
Programa exemplo de leitura
IDENTIFICATION DIVISION.
PROGRAM-ID. JSONREAD.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-JSON.
05 WS-DADOS PIC X(500).
01 WS-CLIENTE.
05 WS-NOME PIC X(30).
05 WS-IDADE PIC 999.
05 WS-SALDO PIC 9(7)V99.
05 WS-ATIVO PIC X.
PROCEDURE DIVISION.
MOVE
'{"nome":"Luke","idade":22,"saldo":1500.50,"ativo":"S"}'
TO WS-DADOS
JSON PARSE WS-DADOS
INTO WS-CLIENTE
END-JSON
DISPLAY WS-NOME
DISPLAY WS-IDADE
DISPLAY WS-SALDO
DISPLAY WS-ATIVO
STOP RUN.
Como funciona internamente
O parser da IBM:
lê caractere por caractere
identifica as chaves
procura o campo correspondente
converte texto para número
grava nas variáveis COBOL
Tudo automaticamente.
Gravando JSON
O caminho inverso também existe.
Suponha:
MOVE "ANA" TO WS-NOME
MOVE 30 TO WS-IDADE
MOVE 999.99 TO WS-SALDO
MOVE "S" TO WS-ATIVO
Agora:
JSON GENERATE WS-DADOS
FROM WS-CLIENTE
END-JSON
Resultado:
{
"nome":"ANA",
"idade":30,
"saldo":999.99,
"ativo":"S"
}
Programa exemplo de geração
IDENTIFICATION DIVISION.
PROGRAM-ID. JSONWRITE.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-DADOS PIC X(1000).
01 WS-CLIENTE.
05 WS-NOME PIC X(30).
05 WS-IDADE PIC 999.
05 WS-SALDO PIC 9(7)V99.
05 WS-ATIVO PIC X.
PROCEDURE DIVISION.
MOVE "ANA" TO WS-NOME
MOVE 30 TO WS-IDADE
MOVE 1500.75 TO WS-SALDO
MOVE "S" TO WS-ATIVO
JSON GENERATE WS-DADOS
FROM WS-CLIENTE
END-JSON
DISPLAY WS-DADOS
STOP RUN.
Gravando em arquivo
Após gerar o JSON basta gravá-lo normalmente.
WRITE REGISTRO-SAIDA
ou
STRING
WS-DADOS
DELIMITED BY SIZE
INTO REGISTRO
END-STRING
WRITE REGISTRO
Pode ser salvo em:
Sequential File
VSAM ESDS
UNIX USS
MQ
FTP
API REST
Kafka
IBM MQ
z/OS Connect
Tratando erros
Nunca assuma que o JSON está correto.
Utilize:
JSON PARSE
...
ON EXCEPTION
DISPLAY "JSON INVALIDO"
NOT ON EXCEPTION
DISPLAY "SUCESSO"
END-JSON
Isso evita que dados inválidos sejam processados.
Exemplo completo
JSON PARSE WS-DADOS
INTO WS-CLIENTE
ON EXCEPTION
MOVE "ERRO" TO WS-STATUS
NOT ON EXCEPTION
MOVE "OK" TO WS-STATUS
END-JSON
Arrays
JSON
{
"produtos":[
"Mouse",
"Teclado",
"Monitor"
]
}
COBOL
05 PRODUTO OCCURS 10 TIMES.
10 NOME PIC X(30).
A IBM faz o relacionamento automaticamente quando os nomes e a estrutura são compatíveis.
Objetos aninhados
JSON
{
"cliente":{
"nome":"Carlos",
"cidade":"Campinas"
}
}
COBOL
01 CLIENTE.
05 DADOS.
10 NOME PIC X(30).
10 CIDADE PIC X(20).
Valores opcionais
Nem sempre todos os campos existirão.
Exemplo
{
"nome":"Pedro"
}
Sem idade.
Sem saldo.
Os campos COBOL permanecerão com seus valores iniciais (SPACES, ZEROS ou VALUE), por isso é importante inicializar a estrutura antes do JSON PARSE, geralmente com:
INITIALIZE WS-CLIENTE
Campos numéricos
Muito cuidado.
JSON
"idade":"ABC"
Jamais poderá alimentar
PIC 999
O parser gerará exceção.
Decimais
JSON
123.45
COBOL
PIC 9(5)V99
O ponto decimal é interpretado automaticamente conforme as regras do compilador e da representação numérica.
Booleanos
JSON
true
false
COBOL não possui um tipo booleano tradicional.
Uma prática comum é utilizar:
05 ATIVO PIC X.
88 CLIENTE-ATIVO VALUE "S".
88 CLIENTE-INATIVO VALUE "N".
Ou mapear para indicadores específicos conforme o padrão da aplicação.
Controle de tamanho
Um erro comum dos iniciantes.
Criar
PIC X(100)
para um JSON de
500 caracteres.
Resultado?
Truncamento.
Sempre dimensione com folga ou utilize áreas compatíveis com o tamanho esperado.
Performance
O parser da IBM é extremamente eficiente.
Mesmo assim:
Evite gerar JSON gigantescos.
Não faça PARSE repetidamente da mesma informação.
Reutilize áreas de trabalho.
Inicialize apenas quando necessário.
Evite cópias desnecessárias do buffer.
Armadilhas
Nomes diferentes
JSON
customerName
COBOL
CLIENTE-NOME
Não haverá correspondência automática sem mecanismos de mapeamento.
Campos obrigatórios
Nem sempre existirão.
Sempre valide.
Tipos incompatíveis
Número enviado como texto.
Texto enviado como número.
Boolean enviado como string.
São causas clássicas de erro.
Caracteres especiais
JSON utiliza UTF-8 com frequência.
Aplicações tradicionais em z/OS podem utilizar EBCDIC.
Em integrações, pode ser necessário converter a codificação antes do JSON PARSE ou após o JSON GENERATE.
Riscos
Os maiores riscos não estão no JSON.
Estão nos dados.
Por exemplo:
JSON malformado.
Dados incompletos.
Campos inesperados.
Tamanho excessivo.
Conteúdo malicioso.
Falhas de conversão de caracteres.
Exposição de informações sensíveis em logs.
Valide sempre a entrada e registre apenas o necessário.
Vantagens
Utilizar JSON no Mainframe oferece inúmeras vantagens:
integração simples com APIs REST;
comunicação natural com aplicações Java, .NET, Python e Node.js;
suporte a microsserviços;
facilidade de integração com nuvem;
menor necessidade de conversões proprietárias;
manutenção mais simples;
suporte nativo do Enterprise COBOL;
excelente desempenho quando comparado a parsers desenvolvidos manualmente.
Onde ele é utilizado?
Hoje praticamente em todos os projetos modernos.
Open Banking
PIX
Internet Banking
Aplicativos Mobile
APIs REST
IBM z/OS Connect
IBM API Connect
IBM MQ
Kafka
Cloud
Inteligência Artificial
IBM watsonx
Integrações híbridas entre IBM Z e plataformas distribuídas
Boas práticas
Um Padawan COBOL deve criar alguns hábitos desde o primeiro dia:
Inicialize as estruturas antes do processamento (
INITIALIZE).Utilize
ON EXCEPTIONe trate todos os erros.Dimensione corretamente o buffer JSON.
Valide obrigatoriedade e formato dos campos.
Documente o layout esperado.
Mantenha os nomes consistentes entre JSON e estrutura COBOL sempre que possível.
Evite expor informações confidenciais em arquivos de log.
Teste com JSONs válidos, inválidos, incompletos e com dados extremos.
Conclusão
Durante muito tempo existiu o mito de que o Mainframe "não falava JSON". Isso deixou de ser verdade há anos. O Enterprise COBOL trouxe comandos nativos que simplificam enormemente a leitura e a geração desse formato, permitindo que aplicações escritas há décadas conversem com APIs modernas, serviços em nuvem, aplicações móveis e plataformas de Inteligência Artificial.
Para um Programador Padawan, aprender JSON significa abrir uma porta para o futuro sem abandonar os fundamentos que fazem do COBOL uma das linguagens mais confiáveis do mundo. Quem domina registros, copybooks e validação de dados aprenderá JSON rapidamente. A diferença está apenas na forma de representar a informação.
O verdadeiro desafio não é escrever JSON PARSE ou JSON GENERATE. É compreender a estrutura dos dados, validar corretamente o conteúdo recebido, tratar exceções, garantir compatibilidade de tipos e proteger informações sensíveis. Esses princípios sempre fizeram parte do desenvolvimento em Mainframe e continuam válidos na era das APIs.
No fim das contas, JSON não substitui o COBOL. Ele amplia sua capacidade de comunicação. E um IBM Z que conversa com o mundo moderno continua fazendo aquilo que sempre fez melhor: processar dados com segurança, desempenho e confiabilidade.
Sem comentários:
Enviar um comentário