Bellacosa Mainframe apresenta EzNoSQL no Z/OS

💣🔥 EzNoSQL no z/OS — O Golpe Silencioso: COMO O MAINFRAME APRENDEU JSON SEM PEDIR PERMISSÃO

Se você é COBOL júnior e acha que NoSQL é coisa de cloud, segura essa:
o mainframe não só entendeu… como absorveu o conceito sem quebrar uma linha de negócio.

---

🧬 Origem — de onde veio essa “mutação”?

Tudo começa com um problema real:

👉 Sistemas core em z/OS
👉 Dados rígidos em Db2, VSAM, IMS
👉 Mundo moderno falando JSON, REST, mobile, eventos

💥 Conflito inevitável.

A IBM já vinha preparando o terreno com:

• Suporte a JSON no Db2
• z/OS Connect expondo APIs
• Integração com cloud

👉 O EzNoSQL for z/OS® surge como uma resposta pragmática:

💣 “E se a gente trouxer o modelo NoSQL pra dentro do mainframe ao invés de empurrar o mainframe pra fora?”

---

📅 História e lançamento

Diferente de produtos clássicos da IBM, o EzNoSQL não nasceu como um “big bang” tipo CICS ou Db2.

👉 Ele aparece por volta da década de 2010 (era pós-cloud), como parte da estratégia de:

• Modernização de aplicações
• APIs REST
• Dados semi-estruturados

💡 Não é um produto mainstream amplamente divulgado como CICS ou Db2
👉 É mais nichado, usado em arquiteturas modernas híbridas

---

🧠 O que ele realmente é (explicação raiz)

Pensa assim, jovem COBOLista:

👉 VSAM = registro fixo
👉 Db2 = tabela estruturada
👉 EzNoSQL = documento flexível (tipo JSON)

Exemplo:

{
  "conta": "123",
  "cliente": "Bellacosa",
  "apps": ["mobile", "web"],
  "config": {
    "notificacao": true
  }
}

💣 Isso no mundo antigo exigiria:

• várias tabelas
• joins
• redesign

👉 Aqui: 1 documento

---

⚙️ Como ele funciona na prática

Arquitetura típica:

App → API → z/OS Connect → COBOL → EzNoSQL

Integra com:

• CICS
• z/OS
• Segurança via RACF

---

🚀 Vantagens (o lado poderoso)

🔥 1. Modernização sem reescrita

Você não precisa jogar COBOL fora.

👉 Você evolui.

---

⚡ 2. JSON nativo no mainframe

Perfeito para:

• APIs REST
• Mobile
• Integrações modernas

---

🛡️ 3. Segurança absurda

Tudo herdado do mainframe:

• RACF
• auditoria
• controle fino

---

🧩 4. Integração natural

Nada de ETL maluco ou sync externo.

---

⚠️ Desvantagens (a parte que ninguém te conta)

❌ 1. Não é cloud-native puro

Não compete diretamente com:

• MongoDB
• Cassandra

---

❌ 2. Escalabilidade diferente

Mainframe escala verticalmente
NoSQL moderno escala horizontalmente

---

❌ 3. Curva de entendimento

COBOL + JSON = choque cultural no começo 😅

---

🧪 Exemplo mental (modo Bellacosa)

🎯 Problema

Cliente muda preferências toda hora.

No Db2:

• ALTER TABLE?
• nova coluna?
• impacto em batch?

💣 Dor.

---

🎯 Com EzNoSQL

{
  "cliente": "123",
  "preferencias": {
    "tema": "dark",
    "idioma": "pt-BR",
    "notificacao": true
  }
}

👉 Mudou? Só adiciona campo.

SEM ALTER TABLE.
SEM impacto global.

---

🧠 Curiosidades (nível raiz)

💡 EzNoSQL não substitui Db2
👉 Ele resolve outro tipo de problema

💡 Ele é mais comum em:

• bancos
• fintechs
• modernização de legado

💡 Muitas vezes você usa sem perceber:
👉 “camada invisível” por trás de APIs

---

🥚 Easter Egg (essa é boa)

💣 O maior segredo:

Muita empresa diz:

👉 “Estamos usando microserviços modernos”

Mas por trás…

👉 ainda existe COBOL chamando algo tipo EzNoSQL no z/OS 😎

---

🧠 Insight profundo (pra você crescer rápido)

👉 O futuro NÃO é:

• COBOL vs NoSQL
• Mainframe vs Cloud

💣 O futuro é:

Mainframe + NoSQL + APIs + eventos

---

🧪 Analogia final (pra fixar de vez)

• Db2 = planilha Excel organizada
• VSAM = arquivo binário rápido
• EzNoSQL = JSON flexível tipo API moderna

---

🚀 Conclusão

O EzNoSQL for z/OS® é uma peça estratégica:

👉 Ele permite que o mainframe:

• fale JSON
• exponha APIs
• se conecte ao mundo moderno

💣 Sem perder:

• performance
• segurança
• confiabilidade
•  

 

Bellacosa Mainframe e a evolucao do cobol e armazenamento de dados

☕ Um Café no Bellacosa Mainframe

Dr. House Entra no CPD — O Caso do Arquivo que Queria Ser Banco, do Cartão que Virou COBOL e do VSAM que Acordou Falando JSON

Ou: como cartões perfurados, fitas, QSAM, VSAM, IMS, Db2 e VSAMDB formam a árvore genealógica dos dados corporativos — e por que “colocar JSON” não cura automaticamente a arquitetura

“Todo mundo mente”, diz o Dr. Gregory House.

No CPD, isso significa: todo mundo diz que “é só um arquivo”.

E lá estamos nós, numa sala branca demais, com o monitor exibindo um SOC7, dois analistas discutindo se o problema é “no VSAM” e um gerente garantindo que basta transformar tudo em JSON para modernizar o legado antes do fim do trimestre.

House olha para a tela, manca até o quadro, escreve KSDS ≠ DB2, sublinha três vezes e sentencia:

“Não é lúpus. É falta de modelo de dados.”

Para um programador COBOL iniciante, a confusão é compreensível. Afinal, o que exatamente são cartão perfurado, fita, QSAM, VSAM, IMS, Db2 e essa nova criatura chamada VSAMDB? São todos arquivos? Todos bancos? Todos formas de guardar informação?

A resposta curta é: não.

A resposta útil é que essas tecnologias são capítulos de uma mesma história. Cada uma resolveu um problema real de sua época. E, em um IBM Z moderno, várias podem coexistir no mesmo sistema, trabalhando discretamente enquanto alguém no LinkedIn anuncia que acabou de descobrir “dados”.

Vamos abrir o prontuário.

---

Prólogo — Antes do banco havia o buraco

Antes de alguém escrever:

SELECT NOME
  FROM CLIENTE
 WHERE CPF = :WS-CPF

alguém precisava representar informação de forma que uma máquina pudesse ler.

A ideia mais antiga e persistente da computação corporativa é simples:

Dados possuem formato.
Formato possui posição.
E posição errada gera desastre com excelente documentação posterior.

O cartão perfurado foi um dos primeiros grandes símbolos disso. Em sua versão clássica, ele possuía 80 colunas. Cada coluna podia codificar uma letra, número ou instrução mediante furos.

Um cartão poderia conter o cadastro de um funcionário:

Colunas  1-06  Matrícula
Colunas  7-36  Nome
Colunas 37-46  Salário
Colunas 47-48  Departamento
Colunas 49-80  Reserva

Um cartão, um registro. Mil cartões, mil registros. Um programador derruba o baralho no chão, mil problemas novos.

Curiosidade: boa parte do famoso formato fixo do COBOL herdou a disciplina dos cartões.

Colunas	Uso tradicional no COBOL
1–6	Número de sequência
7	Indicador de comentário ou continuação
8–11	Area A
12–72	Area B
73–80	Identificação/sequência

É por isso que o COBOL antigo parece ter sido desenhado por alguém que não confiava em espaços em branco. Porque foi.

As colunas 73 a 80 podiam ajudar a reordenar o programa caso o baralho caísse. Hoje chamamos isso de controle de versão; naquela época, era o estagiário ajoelhado no chão, tentando decidir se o cartão 003417 vinha antes ou depois do 003418.

House observa o cartão e diz:

“O paciente não morreu por ser antigo. Morreu porque alguém ignorou o layout.”

Essa frase vale para um cartão de 1968, um copybook de 1988 e um payload JSON de 2026.

---

1. Fita perfurada — o registro saiu caminhando em fila indiana

A fita perfurada é parecida com o cartão, mas usa papel contínuo. Em vez de registros separados em fichas, a informação segue numa longa sequência de caracteres.

[início] → caractere 1 → caractere 2 → caractere 3 → ... → [fim]

Ela foi comum em teletipos, telecomunicações, automação e equipamentos que precisavam transmitir ou registrar informação de forma linear.

A fita tinha uma característica fundamental: acesso sequencial.

Se você queria chegar ao registro 1.000, precisava atravessar os 999 anteriores. Não existia uma chave, um índice ou uma lupa digital dizendo “vá direto ao CPF 123”.

Parece medieval, mas não é uma ideia morta. A lógica sequencial continua presente em:

• arquivos texto;

• logs;

• streams;

• eventos;

• mensagens;

• fitas de backup;

• arquivos batch gigantescos;

• processamento de entrada e saída em lote.

A diferença é que hoje o rolo de papel virou storage de alta capacidade, nuvem, fita virtual ou biblioteca robótica. Mas a lógica ainda é a mesma: o próximo registro é o próximo registro.

Meio	Organização	Melhor uso
Cartão perfurado	Registro individual	Entrada de dados e programas
Fita perfurada	Fluxo contínuo	Comunicação e automação
Fita magnética	Muitos registros em sequência	Backup, arquivo e batch
Disco indexado	Registro por chave	Consulta direta
Banco de dados	Dados com regras e relações	Sistemas corporativos complexos

A fita magnética sucedeu a fita perfurada com mais capacidade, velocidade e confiabilidade. Continua excelente quando você processa muito dado em ordem. Mas tente localizar um contrato específico numa fita: ela sorrirá educadamente e pedirá que você espere a leitura chegar até ele.

Não é defeito. É especialização.

---

2. QSAM — o garçom que traz registros sem mostrar a cozinha

Quando falamos em QSAM, a primeira correção de House seria:

“QSAM não é armazenamento. É método de acesso. Pare de chamar tudo de banco.”

QSAM significa Queued Sequential Access Method, ou Método de Acesso Sequencial com Fila.

Ele permite que o programa COBOL leia ou grave registros sequencialmente sem precisar administrar blocos físicos, buffers, canais de I/O e detalhes de dispositivo.

O programa pede:

“Leia o próximo registro.”

E o z/OS resolve o restante.

A palavra Queued existe porque o sistema usa filas e buffers para antecipar trabalho. Enquanto o programa processa o registro atual, o sistema pode já estar buscando o próximo bloco. É como uma cozinha eficiente: o garçom entrega seu café enquanto a máquina já está preparando o seguinte.

Sem QSAM, o programador precisaria trabalhar mais próximo do I/O físico, usando por exemplo o BSAM (Basic Sequential Access Method).

Método	O que o programador pede
QSAM	“Dê-me o próximo registro.”
BSAM	“Leia este bloco físico neste buffer e me avise quando terminar.”

QSAM é o caminho mais natural para arquivos batch tradicionais.

Em COBOL:

SELECT ARQ-CLIENTE ASSIGN TO ENTRADA
    ORGANIZATION IS SEQUENTIAL
    ACCESS MODE IS SEQUENTIAL
    FILE STATUS IS WS-FS-CLIENTE.

Depois:

OPEN INPUT ARQ-CLIENTE

PERFORM UNTIL WS-FIM-ARQ = 'S'
    READ ARQ-CLIENTE
        AT END
            MOVE 'S' TO WS-FIM-ARQ
        NOT AT END
            PERFORM PROCESSA-CLIENTE
    END-READ
END-PERFORM

CLOSE ARQ-CLIENTE

Parece banal. E é justamente por isso que funciona há tanto tempo.

Um job de folha de pagamento pode ler milhões de funcionários, um por um, calcular descontos, gerar demonstrativos e criar um arquivo de saída. Se os dados estão ordenados, QSAM é uma ferramenta extremamente eficiente.

Registro, bloco e dataset: a trindade que confunde o padawan

Conceito	Significado
Registro	Unidade lógica: cliente, venda, funcionário
Bloco	Grupo de registros movimentado numa operação de I/O
Dataset	Arquivo do z/OS que contém os registros

O COBOL pensa em registros. O disco prefere blocos. O z/OS faz a mediação para que ninguém precise negociar diretamente com o prato magnético como se fosse uma sessão de terapia.

É daí que surgem atributos clássicos:

• RECFM=FB: registros de tamanho fixo, bloqueados;

• RECFM=VB: registros de tamanho variável, bloqueados;

• LRECL: tamanho lógico do registro;

• BLKSIZE: tamanho do bloco de I/O.

Se um arquivo possui LRECL=120, cada registro lógico possui 120 bytes. Mas o sistema pode transferir diversos desses registros por vez num bloco maior. Isso reduz I/O e melhora desempenho.

House pega o relatório de performance, vê um arquivo mal bloqueado e murmura:

“Não é CPU. Nunca é CPU. É I/O ruim fingindo que é CPU.”

Guarde essa frase. Ela salvará horas de diagnóstico.

---

3. VSAM — o arquivo ganhou chave, memória e atitude

O VSAM significa Virtual Storage Access Method. Ele também é um método de acesso do z/OS, mas é muito mais sofisticado que um arquivo sequencial comum.

VSAM não é, em sentido estrito, um gerenciador relacional de banco de dados. Ele não oferece SQL, JOIN, chave estrangeira, catálogo de negócio ou integridade referencial automática.

Ele oferece outra coisa: acesso rápido e eficiente a registros, especialmente por chave.

Os tipos mais conhecidos são:

Tipo	O que faz	Exemplo
KSDS	Localiza registro por chave	Cliente pelo CPF
ESDS	Armazena registros na ordem de inclusão	Log de eventos
RRDS	Localiza por número relativo	Tabela por posição
LDS	Espaço linear para uso especializado	Estruturas físicas internas

O favorito dos sistemas COBOL/CICS é o KSDS (Key-Sequenced Data Set).

Imagine um cadastro cujo campo-chave é o número da conta:

SELECT ARQ-CONTA ASSIGN TO CONTAKS
    ORGANIZATION IS INDEXED
    ACCESS MODE IS DYNAMIC
    RECORD KEY IS CONTA-NUMERO
    FILE STATUS IS WS-FS-CONTA.

E depois:

MOVE WS-CONTA-PROCURADA TO CONTA-NUMERO

READ ARQ-CONTA KEY IS CONTA-NUMERO
    INVALID KEY
        DISPLAY 'CONTA NAO ENCONTRADA'
END-READ

O programa não precisa ler todas as contas anteriores. Ele vai direto à chave.

Mas há uma diferença importante entre VSAM e Db2:

Em VSAM, a aplicação normalmente precisa proteger as regras de negócio.
Em Db2, muitas regras podem ser declaradas e impostas pelo banco.

Se você apagar um cliente em VSAM e esquecer de apagar seus contratos, o VSAM não dará um discurso moral. Ele obedecerá. Com grande velocidade, eficiência e absoluta ausência de julgamento.

Por isso, programas VSAM exigem disciplina:

• validar status;

• controlar atualização concorrente;

• tratar FILE STATUS;

• desenhar cuidadosamente as chaves;

• definir recuperação;

• garantir consistência entre arquivos relacionados.

O VSAM é um canivete suíço. Nas mãos certas, resolve muito. Nas mãos erradas, também corta.

---

4. IMS — a árvore que não pede permissão para ser rápida

O IMS é um gerenciador de banco de dados hierárquico e também possui um poderoso gerenciador de transações, o IMS TM.

Sua estrutura é uma árvore:

CLIENTE
 ├── CONTA
 │    ├── MOVIMENTO
 │    └── LIMITE
 └── SEGURO
      └── COBERTURA

Em vez de tabelas relacionadas por colunas, existem segmentos pai e filho.

Para chegar a um movimento, o programa costuma percorrer o caminho esperado: cliente → conta → movimento. Isso parece rígido perto de SQL — porque é. Mas essa rigidez traz previsibilidade e altíssimo desempenho para transações repetitivas.

As operações DL/I clássicas têm nomes que parecem siglas de um pronto-socorro:

Chamada DL/I	Significado
GU	Busca um segmento específico
GN	Busca o próximo segmento
GNP	Busca o próximo filho do pai atual
ISRT	Insere
REPL	Atualiza
DLET	Remove

O IMS é excelente quando se conhece o caminho da transação e se precisa executar esse caminho milhões de vezes com resposta previsível.

É por isso que ele segue forte em bancos, seguros, reservas, telecomunicações e sistemas onde “talvez responda em alguns segundos” não é uma frase aceitável.

House olha o modelo hierárquico e comenta:

“Vocês chamam de legado. Eu chamo de sistema que já sobreviveu a três aquisições, duas crises e cinco arquitetos.”

---

5. Db2 — quando os dados precisam conversar entre si

O Db2 for z/OS é o modelo relacional em sua forma corporativa: tabelas, SQL, índices, integridade, bloqueios, logs, recuperação, COMMIT, ROLLBACK e processamento massivo.

Ele é ideal quando os dados possuem muitos relacionamentos:

CLIENTE → CONTA → MOVIMENTO
    │
    ├── CARTAO
    ├── EMPRESTIMO
    └── ENDERECO

No Db2, você pode escrever uma pergunta que ninguém imaginou quando o sistema foi criado:

SELECT C.NOME, COUNT(*)
  FROM CLIENTE C
  JOIN CONTA A
    ON A.ID_CLIENTE = C.ID_CLIENTE
  JOIN MOVIMENTO M
    ON M.ID_CONTA = A.ID_CONTA
 WHERE M.DATA_MOVIMENTO >= CURRENT DATE - 90 DAYS
 GROUP BY C.NOME

Essa é a força do banco relacional: ele permite explorar relações sem exigir que o caminho inteiro esteja congelado no código.

Db2 também trabalha com propriedades ACID:

Letra	Significado
A	Atomicidade: tudo acontece ou nada acontece
C	Consistência: regras permanecem válidas
I	Isolamento: transações concorrentes não se atropelam
D	Durabilidade: após o COMMIT, o dado sobrevive

Em termos físicos, o Db2 usa estruturas do z/OS e, tradicionalmente, datasets VSAM LDS para seus objetos de armazenamento. Mas isso não significa que o programador deva abrir um table space Db2 com READ NEXT.

Você conversa com Db2 por SQL. Ele cuida do porão.

Abrir a estrutura interna do Db2 como se fosse arquivo comum seria equivalente a um médico abrir o tórax do paciente para conferir se o marca-passo está funcionando porque “parecia mais rápido”.

Não faça isso. House não aprovaria.

---

6. VSAMDB e EzNoSQL — o VSAM aprendeu JSON, mas não virou MongoDB

Agora chegamos ao paciente mais novo da ala: VSAMDB.

VSAMDB é uma capacidade do DFSMS/VSAM que permite armazenar documentos JSON ou BSON em um dataset especial. O EzNoSQL for z/OS fornece APIs de mais alto nível para acessar esses documentos.

A ideia é tentadora:

{
  "_id": "CLI-00018472",
  "nome": "Ana Silva",
  "telefones": [
    {
      "tipo": "celular",
      "numero": "+55-11-99999-0000"
    }
  ],
  "preferencias": {
    "idioma": "pt-BR",
    "canal": "email"
  }
}

Em vez de criar várias tabelas ou um copybook com dezenas de ocorrências, você armazena o documento como um todo.

Isso é útil quando:

• os atributos variam muito;

• há estruturas aninhadas;

• os dados serão usados por COBOL, Java, Python ou C;

• a aplicação precisa de acesso rápido por chave;

• há baixo interesse em JOINs complexos;

• o dado é mais parecido com configuração, metadado ou estado operacional do que com contabilidade.

O VSAMDB oferece chave primária e índices alternativos. A IBM o posiciona como banco JSON chave-valor, com compartilhamento no Sysplex, consistência transacional e APIs para várias linguagens. O suporte direto do Enterprise COBOL 6.5 para ler, gravar, atualizar e excluir documentos JSON em VSAMDB tornou-se disponível em 2025.

Mas atenção: JSON não é magia de modernização.

Transformar isto:

01  REG-CLIENTE.
    05 CLI-CPF             PIC 9(11).
    05 CLI-NOME            PIC X(40).
    05 CLI-LIMITE          PIC S9(9)V99 COMP-3.
    05 CLI-STATUS          PIC X.

nisto:

{
  "cpf": "12345678901",
  "nome": "ANA SILVA",
  "limite": 5000.00,
  "status": "A"
}

não resolve automaticamente:

• quem é o dono do dado;

• quais campos são obrigatórios;

• quais regras impedem uma atualização inválida;

• como manter compatibilidade com os programas antigos;

• como relacionar cliente, conta, contrato e movimento;

• como produzir relatórios corporativos;

• como recuperar o ambiente após uma falha;

• como evitar que cinco equipes inventem cinco significados para status.

NoSQL significa “não somente SQL”, não “sem regras, sem responsabilidade e sem consequências”.

House escreve no quadro:

JSON ≠ Arquitetura
API REST ≠ Modernização
Cloud ≠ Diagnóstico

E, pela primeira vez no dia, ninguém discorda.

---

7. Por que quase ninguém vê VSAMDB em projetos reais?

A observação de que “nunca vi projeto usando” é bastante razoável.

Primeiro, porque o recurso é relativamente novo para o ciclo de vida de sistemas z/OS. Muitas aplicações corporativas já escolheram sua estratégia de dados há anos: VSAM, IMS, Db2, MQ, CICS, replicação, Data Virtualization, APIs ou combinação de tudo isso.

Segundo, porque VSAMDB exige preparo operacional. Ele se apoia em VSAM RLS, que envolve ambiente Sysplex, Coupling Facility, SMSVSAM, classes SMS e planejamento de consistência e recuperação. Não é uma simples biblioteca que o desenvolvedor instala numa sexta-feira após o almoço.

Terceiro, porque grande parte das APIs modernas não precisa armazenar JSON internamente.

Uma API pode receber JSON, convertê-lo para um copybook, chamar um programa COBOL/CICS, consultar Db2 ou VSAM e devolver JSON ao consumidor.

Aplicação web
    ↓ JSON
API
    ↓ Copybook / SQL / chamada CICS
Sistema de registro em Db2, IMS ou VSAM
    ↓
Resposta JSON

O JSON, nesse caso, é o envelope de integração. O sistema de registro continua no formato que melhor protege o negócio.

O diagnóstico diferencial de House

Sintoma	Melhor suspeito
Preciso de tabelas, relacionamentos e SQL	Db2
Preciso de transações previsíveis em volume extremo	IMS
Preciso de registro rápido por chave	VSAM KSDS
Preciso processar tudo em ordem	QSAM
Preciso de documentos flexíveis por chave, compartilhados entre linguagens	VSAMDB / EzNoSQL
Preciso expor legado por REST	z/OS Connect, CICS ou camada de API
Preciso “modernizar porque o diretor viu uma palestra”	Solicitar exames adicionais

---

8. Passo a passo: como escolher sem cometer um ABEND arquitetural

Passo 1 — Faça a pergunta certa

Não comece perguntando “qual tecnologia é moderna?”.

Pergunte:

• O acesso é sequencial ou por chave?

• Existem muitas relações entre entidades?

• O formato muda com frequência?

• A transação precisa responder em milissegundos?

• O dado exige integridade rígida?

• O processamento é batch, online ou ambos?

• Quem consumirá o dado: COBOL, Java, Python, analistas, API externa?

Passo 2 — Descubra o formato natural do dado

Um registro de folha mensal costuma ser previsível. QSAM pode ser perfeito.

Uma conta por número é naturalmente um KSDS.

Uma cadeia cliente → conta → movimento pode funcionar muito bem em IMS.

Um universo de relacionamento entre clientes, produtos, contratos, indicadores e consultas pode pedir Db2.

Uma estrutura de preferências, metadados ou configuração que muda bastante pode ser candidata a JSON/VSAMDB.

Passo 3 — Não trate storage como decisão isolada

Dados nunca vivem sozinhos. Eles possuem:

• dono;

• regras;

• retenção;

• auditoria;

• segurança RACF;

• backup;

• recuperação;

• performance;

• integração;

• custo operacional.

A pergunta não é apenas “onde gravar?”. É “como este dado continuará correto às três da manhã, durante uma falha, com duas transações concorrentes e um auditor pedindo evidência?”.

Passo 4 — Teste a recuperação antes de declarar vitória

Todo projeto parece moderno até a primeira falha.

Teste:

• queda durante atualização;

• processamento duplicado;

• concorrência;

• COMMIT e ROLLBACK;

• backup;

• restore;

• reprocessamento batch;

• índice corrompido;

• mensagem repetida;

• dado JSON com atributo inesperado.

Se o projeto só funciona em apresentação, ele não é arquitetura. É trailer.

Passo 5 — Escolha a ferramenta pelo problema, não pelo marketing

Um sistema pode usar QSAM, VSAM, Db2, IMS, MQ e JSON ao mesmo tempo. Isso não é bagunça por definição. Pode ser uma arquitetura madura, em que cada componente faz aquilo que sabe fazer.

O erro é colocar tudo numa única tecnologia por dogma.

---

Epílogo — O velho não é o doente

Cartões perfurados ensinaram que dados precisam de layout. Fitas ensinaram que sequência importa. QSAM ensinou a esconder a complexidade do I/O. VSAM ensinou acesso direto por chave. IMS ensinou que hierarquia pode ser rápida. Db2 ensinou que relações e regras podem ser declaradas. VSAMDB ensina que documentos JSON também podem morar no z/OS.

Nenhuma dessas tecnologias é “a resposta universal”.

O programador COBOL iniciante não precisa decorar todas de uma vez. Precisa aprender a olhar para o problema e perguntar:

“Que tipo de dado é este?
Como ele será acessado?
Que regra não pode ser violada?
E quem vai me ligar quando der errado?”

House fecha o prontuário, olha para o FILE STATUS, para o SQLCODE, para o PCB STATUS e para o JSON recém-chegado.

“O paciente não está velho.
Ele só tem dependências, dados críticos, regras de negócio e vinte milhões de usuários.
Diferente de vocês, ele merece um diagnóstico.”

E no fundo do CPD, um programa COBOL compilado há décadas continua processando a realidade — registro por registro, COMMIT por COMMIT, sem jamais ter pedido permissão para ser relevante.

Fontes para continuar a investigação

• EzNoSQL for z/OS — IBM

• VSAMDB e acesso via VSAM RLS — IBM Documentation

• Enterprise COBOL 6.5 e suporte a VSAMDB — IBM

• z/OS 3.2 e APIs EzNoSQL para Python — IBM