 |
| Bellacosa Mainframe explora o json |
☕ Um Café no Bellacosa Mainframe
🕵️♂️ INSPETOR CLOUSEAU E O MISTÉRIO DAS CHAVES ENTRE CHAVES
JSON, APIs, arrays, objetos, jq, curl, Kubernetes, Terraform, CI/CD, observabilidade e o estranho caso do mainframe acusado de não saber conversar com o mundo moderno.
🎬 PRÓLOGO — Havia uma chave onde não deveria haver uma chave
Paris, algum momento entre um incidente de produção e uma reunião que deveria ter sido um e-mail.
O telefone toca.
— Inspetor Clouseau? Temos um problema.
Clouseau ajeita o sobretudo.
— Naturalmente. Se não houvesse problema, não estariam ligando para o maior detetive da França.
— Uma aplicação parou de funcionar.
— Sabotage!
— Não sabemos.
— Ransomware!
— Também não.
— Mainframe!
Silêncio.
Do outro lado da linha, alguém respira fundo.
— Inspetor... o erro diz:
Unexpected token } in JSON
Clouseau estreita os olhos.
— Aha! Então temos um suspeito.
Ele pega a lupa.
Na tela aparece:
{
"customer": "Bellacosa",
"status": "ACTIVE",
}
Clouseau observa durante vários segundos.
— Onde está o criminoso?
O programador aponta.
"ACTIVE",
^
Uma vírgula.
Uma pequena vírgula.
Um caractere com poucos pixels havia derrubado uma automação inteira.
E assim começava uma investigação que levaria Clouseau por APIs, pipelines, Kubernetes, Terraform, logs, curl, jq e finalmente até um velho programa COBOL que, como quase sempre acontece nessas histórias, estava sendo acusado injustamente.
Porque o verdadeiro mistério não era:
“O que é JSON?”
Era muito maior:
Como sistemas completamente diferentes conseguem conversar sem precisar conhecer a implementação interna uns dos outros?
E essa pergunta nos leva diretamente ao coração da computação moderna.
🕵️ CAPÍTULO 1 — O primeiro suspeito: JSON
JSON significa JavaScript Object Notation.
Mas esse nome frequentemente provoca o primeiro erro conceitual.
JSON não é JavaScript.
Também não é uma linguagem de programação.
Não possui IF, PERFORM, métodos, classes ou algoritmos.
JSON é essencialmente uma representação textual de dados estruturados.
A especificação padronizada pela IETF, RFC 8259, define JSON como um formato textual e independente de linguagem para intercâmbio de dados estruturados. Ela estabelece quatro tipos primitivos — string, number, boolean e null — além de dois tipos estruturados: object e array.
Clouseau imediatamente faz uma anotação:
SUSPEITO: JSON
CRIME: transportar dados
ARMA: { }
CÚMPLICE: [ ]
Mas transportar dados não parece exatamente um crime.
Na verdade, essa simplicidade explica boa parte do sucesso do JSON.
Imagine:
{
"name": "Vagner",
"technology": "COBOL",
"experience": 35,
"active": true
}
Não existe programa sendo executado ali.
Existe apenas uma afirmação estruturada sobre dados.
🧱 CAPÍTULO 2 — Clouseau encontra um COPYBOOK disfarçado
Para quem vem do COBOL, talvez exista uma maneira muito melhor de entender JSON do que começar falando de JavaScript.
Imagine:
01 CUSTOMER.
05 CUSTOMER-ID PIC 9(8).
05 CUSTOMER-NAME PIC X(40).
05 CUSTOMER-STATUS PIC X(10).
05 CUSTOMER-BALANCE PIC S9(9)V99 COMP-3.
O programador mainframe olha para isso e imediatamente enxerga uma estrutura.
Existe um grupo.
Dentro dele existem campos.
Cada campo possui significado, tamanho e representação.
Agora imagine uma representação conceitualmente equivalente:
{
"customerId": 12345678,
"customerName": "BELLACOSA",
"customerStatus": "ACTIVE",
"customerBalance": 15872.35
}
Clouseau olha para o COPYBOOK.
Olha para o JSON.
Olha novamente para o COPYBOOK.
— São irmãos!
Não exatamente.
Mas a intuição é excelente.
O COPYBOOK descreve uma estrutura muito mais rígida: posição, tamanho, representação numérica, agrupamento etc.
JSON trabalha de outra maneira:
"customerName" : "BELLACOSA"
│ │
│ └── valor
│
└── chave
Em vez de perguntar:
“Em qual posição começa esse campo?”
perguntamos:
“Qual é o valor associado a esta chave?”
Essa diferença parece pequena.
Arquitetonicamente, é gigantesca.
🔑 CAPÍTULO 3 — O estranho caso das chaves
Um objeto JSON utiliza:
{
}
E contém pares:
chave : valor
Por exemplo:
{
"system": "CICS",
"region": "CICSPRD1",
"status": "UP"
}
A RFC especifica objetos como coleções de pares nome/valor e recomenda que os nomes sejam únicos. Também é importante não construir aplicações que dependam da ordem das propriedades de um objeto.
Isso produz uma diferença interessante em relação ao pensamento tradicional de registros posicionais.
Em:
BELLACOSA 000001 ACTIVE
o significado depende fortemente da convenção sobre onde cada informação está.
Em:
{
"name": "BELLACOSA",
"id": 1,
"status": "ACTIVE"
}
parte do significado acompanha o próprio dado.
O formato ficou mais verboso.
Mas também muito mais autodescritivo.
Clouseau imediatamente conclui:
— Então quanto maior o arquivo, melhor!
Não, Clouseau.
Continue investigando.
📦 CAPÍTULO 4 — Os cúmplices chamados Arrays
Então aparece:
[
]
Se {} representa um objeto, [] representa um array.
Por exemplo:
{
"regions": [
"CICSPRD1",
"CICSPRD2",
"CICSTST1"
]
}
A RFC define arrays como sequências ordenadas de valores.
Para um programador COBOL, existe uma associação mental extremamente útil:
05 TRANSACTION OCCURS 100 TIMES.
Não significa que OCCURS e JSON Array sejam tecnicamente a mesma coisa.
Não são.
Mas ambos representam a ideia fundamental:
há múltiplas ocorrências de alguma coisa.
Podemos ter objetos dentro do array:
{
"regions": [
{
"name": "CICSPRD1",
"status": "UP"
},
{
"name": "CICSPRD2",
"status": "DOWN"
}
]
}
Agora nossa estrutura começa a ficar interessante.
🪆 CAPÍTULO 5 — Clouseau descobre objetos dentro de objetos
Então surge o verdadeiro terror do iniciante:
{
"customer": {
"id": 12345,
"accounts": [
{
"type": "CHECKING",
"balance": 1500.25
},
{
"type": "SAVINGS",
"balance": 8700.00
}
]
}
}
Clouseau olha para aquilo.
— Mon Dieu. Alguém colocou um JSON dentro do JSON.
Sim.
E pode colocar outro.
E outro.
Porque JSON forma naturalmente uma árvore.
customer
│
├── id
│
└── accounts
│
├── [0]
│ ├── type
│ └── balance
│
└── [1]
├── type
└── balance
E isso muda completamente a maneira de ler estruturas grandes.
Em vez de tentar compreender cinquenta linhas simultaneamente, seguimos um caminho:
customer
↓
accounts
↓
[0]
↓
balance
Mentalmente:
customer.accounts[0].balance
Quem trabalhou com estruturas hierárquicas, IMS ou grupos COBOL talvez perceba algo curioso.
Essa maneira de pensar não é tão alienígena quanto parece.
O vocabulário mudou.
A árvore não.
🧬 CAPÍTULO 6 — JSON tem tipos, mas Clouseau quase perdeu essa pista
Observe:
{
"name": "Bellacosa",
"age": 52,
"active": true,
"error": null
}
Temos:
"Bellacosa" → string
52 → number
true → boolean
null → null
Além deles existem:
{} → object
[] → array
Isso é muito importante.
Veja:
{
"cpu": 90
}
e:
{
"cpu": "90"
}
Visualmente parecem quase iguais.
Semanticamente não são.
No primeiro:
90 = número
No segundo:
"90" = texto
E agora aparece um problema particularmente interessante para quem vem de COBOL.
💰 CAPÍTULO 7 — O mistério do dinheiro desaparecido
No COBOL podemos escrever:
05 BALANCE PIC S9(11)V99 COMP-3.
Isso diz muita coisa.
JSON simplesmente oferece:
{
"balance": 123456789.99
}
Mas qual precisão deve ser utilizada?
Qual representação interna?
Qual escala?
O consumidor usa double?
decimal?
BigDecimal?
A própria RFC permite que implementações imponham limites de precisão e intervalo aos números JSON. (RFC Editor)
Agora Clouseau encontrou uma pista realmente importante.
Quando atravessamos fronteiras tecnológicas:
COBOL COMP-3
↓
JSON number
↓
Java / JavaScript / Python
↓
Banco de dados
precisamos pensar cuidadosamente em precisão.
Especialmente para:
dinheiro
identificadores gigantes
timestamps
medições científicas
números com precisão decimal obrigatória
Às vezes uma API deliberadamente envia determinados valores como strings:
{
"amount": "123456789.99"
}
e define no contrato como interpretá-los.
Não porque JSON esteja quebrado.
Mas porque interoperabilidade também significa preservar significado.
👻 CAPÍTULO 8 — Null não significa desaparecido
Clouseau encontra dois arquivos.
Arquivo A:
{}
Arquivo B:
{
"telephone": null
}
— São iguais!
Não necessariamente.
No primeiro:
a propriedade não existe.
No segundo:
a propriedade existe e seu valor é null.
Essa distinção pode ser crucial em APIs.
Imagine uma operação de atualização.
{
"telephone": null
}
poderia significar:
remova o telefone.
Enquanto:
{}
poderia significar:
não altere o telefone.
Isso depende do contrato da API, mas demonstra uma lição muito maior:
Sintaxe não determina sozinha a semântica.
E essa frase vai voltar à nossa investigação.
🚨 CAPÍTULO 9 — O JSON era válido. O sistema caiu mesmo assim
Imagine:
{
"customerId": 123,
"withdrawal": 999999999
}
Perfeitamente válido como JSON.
Mas o cliente possui:
Saldo = R$ 27,50
Portanto existem diferentes níveis de validade:
SINTAXE
↓
ESTRUTURA / SCHEMA
↓
SEMÂNTICA
↓
REGRA DE NEGÓCIO
Um documento pode ser sintaticamente perfeito e ainda assim estar completamente errado para aquela aplicação.
Clouseau começa a compreender que seu erro inicial foi perguntar:
“O JSON está correto?”
A pergunta certa seria:
“Correto em qual camada?”
Isso é uma extraordinária pergunta para troubleshooting.
🌐 CAPÍTULO 10 — O JSON sai de casa e encontra uma API
Agora chegamos ao ponto em que JSON conquistou grande parte do mundo moderno.
Imagine:
Aplicação
│
│ HTTP Request
▼
┌───────────────┐
│ API │
└───────────────┘
│
│ HTTP Response
▼
Aplicação
O corpo pode conter:
{
"customer": 12345,
"status": "ACTIVE"
}
Mas aqui Clouseau comete outro erro.
— HTTP é JSON!
Não.
HTTP é o protocolo.
JSON pode ser o formato do conteúdo transportado.
Também não devemos transformar:
REST = JSON
em identidade matemática.
Podemos ter APIs utilizando outros formatos.
A distinção conceitual é importantíssima:
HTTP
├── status
├── headers
└── body
└── talvez JSON
Um:
HTTP 500
é uma informação sobre a interação HTTP.
Um:
{
"error": "database unavailable"
}
é conteúdo.
Misturar essas camadas torna troubleshooting muito mais difícil.
🔦 CAPÍTULO 11 — Clouseau encontra o curl
Precisamos investigar uma API.
Entra em cena:
curl
Por exemplo:
curl https://api.example.com/customers/123
A resposta:
{
"id": 123,
"name": "Bellacosa",
"status": "ACTIVE"
}
Agora conseguimos interrogar diretamente a API.
Mas uma resposta real pode possuir milhares de linhas.
Clouseau pega sua lupa.
Existe uma ferramenta melhor.
🔬 CAPÍTULO 12 — jq: a lupa do detetive DevOps
Entra:
jq
Se tivermos:
{
"customer": {
"name": "Bellacosa",
"accounts": [
{
"type": "CHECKING",
"balance": 1500
},
{
"type": "SAVINGS",
"balance": 8700
}
]
}
}
podemos perguntar:
jq '.customer.name'
Resultado:
"Bellacosa"
Ou:
jq '.customer.accounts[0].balance'
Resultado:
1500
Ou ainda:
jq '.customer.accounts[].balance'
Resultado:
1500
8700
Mas aqui está o salto conceitual.
jq não é apenas um pretty printer.
Ele permite consultar, selecionar e transformar árvores JSON.
Imagine:
curl -s https://api.example.com/accounts |
jq '.accounts[] | select(.balance > 5000)'
Agora temos uma pequena investigação automatizada:
API
↓
curl
↓
JSON
↓
jq
↓
filtro
↓
informação
É quase um SQL para a árvore JSON — não literalmente, mas é uma excelente analogia mental inicial.
☸️ CAPÍTULO 13 — O crime chega ao Kubernetes
Clouseau entra em uma sala cheia de YAML.
— Finalmente escapamos do JSON.
Não exatamente.
YAML e JSON aparecem frequentemente em papéis complementares nesse ecossistema.
Quando observamos objetos Kubernetes, três regiões são particularmente interessantes:
metadata
spec
status
Uma forma conceitual de enxergá-las:
metadata → quem sou eu?
spec → como desejo que eu esteja?
status → como estou agora?
E aqui aparece algo muito mais importante do que aprender chaves e colchetes.
A ideia de desired state.
Você declara:
quero 3 réplicas
O sistema observa:
existem 2
E tenta reconciliar:
DESEJADO
│
▼
┌──────────────┐
│ RECONCILIAÇÃO│
└──────────────┘
│
▼
ATUAL
Isso é arquitetura.
JSON é apenas uma das formas pelas quais podemos observar ou transportar essa representação.
🏗️ CAPÍTULO 14 — Terraform entra na delegacia
Clouseau encontra outro arquivo.
Agora temos infraestrutura descrita e administrada de forma declarativa.
Terraform consegue produzir representações JSON de plans e state com:
terraform show -json
A documentação oficial descreve essa saída como uma representação legível por máquinas do plano ou estado, justamente para permitir processamento automatizado. (HashiCorp Developer)
Isso possibilita:
Terraform
↓
JSON
↓
jq / programa
↓
policy
↓
pipeline
Por exemplo, conceitualmente:
terraform show -json plan.tfplan |
jq '.resource_changes[]'
De repente JSON deixou de ser apenas “arquivo de configuração”.
Virou uma interface entre ferramentas.
Mas há uma pista de segurança importante: a HashiCorp alerta que terraform show -json pode revelar valores sensíveis do state em texto claro. (HashiCorp Developer)
Portanto:
JSON + automação ≠ automaticamente seguro
🏭 CAPÍTULO 15 — O JSON invade o CI/CD
Imagine uma pipeline:
SOURCE
↓
BUILD
↓
TEST
↓
PACKAGE
↓
DEPLOY
↓
MONITOR
Cada etapa precisa comunicar informações.
Build:
{
"buildId": 8731,
"status": "SUCCESS"
}
Teste:
{
"tests": 428,
"passed": 427,
"failed": 1
}
Deployment:
{
"environment": "PRODUCTION",
"version": "4.17.2",
"status": "DEPLOYED"
}
Perceba o padrão.
JSON começa a funcionar como um envelope universal de metadados.
Ferramenta A não precisa conhecer toda a implementação de B.
Precisa conhecer o contrato.
E aqui chegamos ao verdadeiro personagem principal desta história.
Não é JSON.
É o contrato.
📜 CAPÍTULO 16 — O verdadeiro suspeito era o contrato
Considere:
{
"customerId": 12345
}
Um desenvolvedor decide melhorar o nome:
{
"customer_id": 12345
}
Ambos são JSON perfeitamente válidos.
Mas o consumidor procura:
customerId
Resultado:
NULL
ERROR
FAILED
ABEND
PIPELINE BROKEN
Clouseau grita:
— JSON defeituoso!
Não.
O JSON está perfeito.
O contrato foi quebrado.
Esse problema nos leva a:
versionamento
schema
compatibilidade
contract testing
governança
backward compatibility
E isso explica por que simplesmente dizer “usamos JSON” quase não nos diz nada sobre a maturidade de uma arquitetura.
🧾 CAPÍTULO 17 — COPYBOOK encontra JSON Schema
Aqui surge uma comparação extremamente interessante para o mundo mainframe.
COPYBOOK:
05 CUSTOMER-ID PIC 9(8).
JSON:
{
"customerId": 12345678
}
O JSON isoladamente diz pouco sobre as restrições do campo.
Um schema pode estabelecer expectativas muito mais detalhadas.
Assim aparece uma associação conceitual:
COPYBOOK
│
├── estrutura
├── tipos
└── contrato
e:
JSON
+
JSON Schema
│
├── estrutura
├── tipos
└── contrato
Eles não são equivalentes tecnicamente.
Mas a comparação é pedagogicamente poderosa.
O veterano COBOL descobre então uma coisa divertida:
O mundo distribuído passou décadas reinventando maneiras de dizer:
“Este dado precisa obedecer a um layout.”
Clouseau sorri.
O mainframe também.
📡 CAPÍTULO 18 — O COBOL finalmente aparece
Agora chegamos à vítima injustamente acusada.
Temos:
Mobile
Web
Cloud
Parceiros
Microsserviços
│
▼
REST
│
▼
JSON
│
▼
z/OS Connect
│
▼
CICS
│
▼
COBOL
│
▼
Db2 / VSAM / IMS
E alguém diz:
“Transformamos COBOL em JSON.”
Não exatamente.
COBOL continua COBOL.
CICS continua CICS.
Db2 continua Db2.
O que criamos é uma fronteira de representação.
Externamente:
{
"account": "123456",
"balance": 7500.25
}
Internamente podemos ter algo semelhante a:
01 ACCOUNT-DATA.
05 ACCOUNT-NUMBER PIC X(6).
05 ACCOUNT-BALANCE PIC S9(7)V99 COMP-3.
Existe então uma transformação:
REPRESENTAÇÃO EXTERNA
↕
MAPEAMENTO
↕
REPRESENTAÇÃO INTERNA
Essa ideia é fundamental para modernização de mainframe.
Modernizar não exige necessariamente destruir aquilo que funciona.
Às vezes significa simplesmente oferecer novas interfaces para capacidades existentes.
📟 CAPÍTULO 19 — O incidente das 03:17
São 03:17.
Naturalmente.
Um alerta chega:
{
"timestamp": "2026-09-17T03:17:42Z",
"service": "payment-api",
"severity": "critical",
"transaction": "PAYMENT",
"backend": "CICS",
"responseTime": 8421,
"status": "timeout"
}
Há algumas décadas talvez tivéssemos:
20260917031742 PAYAPI CRIT PAY CICS 8421 TIMEOUT
Perfeitamente processável.
Mas agora cada informação possui identidade explícita.
Isso facilita:
indexação
correlação
pesquisa
dashboards
alertas
automação
machine learning
IA
Imagine milhões desses eventos.
Podemos perguntar:
Mostre severity=critical
onde backend=CICS
e responseTime > 5000
nas últimas duas horas.
Essa é uma das razões pelas quais structured logging tornou-se tão poderoso.
JSON não é somente intercâmbio de APIs.
Pode ser também a matéria-prima da observabilidade.
🔥 CAPÍTULO 20 — Clouseau encontra um JSON quebrado
Finalmente chega o incidente clássico:
parse error
O arquivo:
{
"system": "CICS"
"status": "UP"
}
Clouseau investiga Kubernetes.
Nada.
Investiga RACF.
Nada.
Investiga Db2.
Nada.
Investiga TCP/IP.
Nada.
Quatro horas depois alguém percebe:
{
"system": "CICS",
↑
"status": "UP"
}
Faltava uma vírgula.
JSON possui uma gramática pequena, mas rígida. Strings e nomes usam aspas duplas; objetos usam {}, arrays usam []; os literais são true, false e null em minúsculas.
Uma boa investigação segue:
ERROR
↓
VALIDATE
↓
LOCATE
↓
FIX
↓
RE-RUN
↓
VERIFY
Não:
ERROR
↓
ALTERA 17 COISAS
↓
RESTART
↓
REZA
Embora Clouseau prefira o segundo método.
🧠 CAPÍTULO 21 — O programador COBOL percebe que já conhecia metade disso
Depois de horas de investigação, Clouseau reúne todos na biblioteca.
Como todo bom detetive.
Na parede:
COPYBOOK
↓
ESTRUTURA
JSON
↓
REPRESENTAÇÃO
JSON SCHEMA
↓
CONTRATO
HTTP / REST
↓
COMUNICAÇÃO
curl
↓
CLIENTE / INVESTIGAÇÃO
jq
↓
CONSULTA / TRANSFORMAÇÃO
KUBERNETES
↓
ESTADO DESEJADO
TERRAFORM
↓
INFRAESTRUTURA DECLARATIVA + ESTADO
CI/CD
↓
AUTOMAÇÃO
OBSERVABILIDADE
↓
TELEMETRIA E INVESTIGAÇÃO
Então vem a revelação.
Para alguém com décadas de mainframe, boa parte dos conceitos fundamentais não é nova.
Já conhecíamos:
campos
registros
grupos
ocorrências
layouts
contratos
interfaces
serialização
validação
mensagens
transações
logs
monitoramento
Mudaram as ferramentas.
Mudaram as representações.
Mudou o ecossistema.
Mas muitos problemas fundamentais permaneceram.
🕵️♂️ EPÍLOGO — Clouseau revela o verdadeiro culpado
Todos estão reunidos.
JSON está sentado numa cadeira.
COBOL em outra.
Kubernetes parece nervoso.
Terraform evita contato visual.
YAML insiste que sua indentação está perfeitamente correta.
Clouseau começa:
— Mesdames et messieurs... descobri o criminoso.
Silêncio.
Ele aponta dramaticamente.
Para ninguém.
— O culpado é... JSON!
O assistente cochicha:
— Inspetor, JSON não fez nada.
— Exatamente! Isso prova como ele é astuto.
Mas talvez exista uma conclusão melhor.
JSON não revolucionou a computação porque inventou dados estruturados.
Isso já existia muito antes dele.
Também não inventou hierarquias, contratos, mensagens ou serialização.
Sua grande força foi oferecer uma representação extremamente simples e amplamente interoperável para que sistemas heterogêneos pudessem conversar sobre dados.
Um programa COBOL de décadas atrás pode participar de uma arquitetura moderna:
COBOL
│
CICS
│
API
│
JSON
│
Cloud
│
Kubernetes
│
CI/CD
│
Observability
│
IA
E isso revela algo que Clouseau quase conseguiu descobrir.
O mainframe não precisa falar a linguagem interna do Kubernetes.
Kubernetes não precisa entender COMP-3.
O aplicativo mobile não precisa conhecer um COPYBOOK.
O sistema consumidor precisa conhecer o contrato na fronteira.
É justamente aí que JSON conquistou seu espaço.
☕ A MORAL DO CASO
Quando alguém disser:
“Mainframe é tecnologia antiga; JSON é tecnologia moderna.”
Clouseau provavelmente derrubará uma estante tentando responder.
Nós podemos fazer melhor.
Um registro COBOL, uma mensagem MQ, um documento XML, um JSON de API e um evento de observabilidade pertencem a gerações e ecossistemas diferentes, mas todos atacam variações de uma questão muito antiga:
Como representar informação de maneira que outro componente consiga compreendê-la corretamente?
A tecnologia muda.
As chaves mudam.
Os protocolos mudam.
Os nomes ficam mais modernos.
Mas o problema fundamental permanece.
E talvez seja por isso que um programador que passou décadas olhando:
01 CUSTOMER.
05 CUSTOMER-ID PIC 9(8).
não deveria sentir medo ao encontrar:
{
"customer": {
"id": 12345678
}
}
Ele não entrou em outro universo.
Apenas encontrou uma nova maneira de escrever uma velha ideia.
E no corredor da produção, às 03:17, o Inspetor Clouseau ainda procura aquela vírgula desaparecida. ☕🕵️♂️
.png)
