Bellacosa Mainframe lahoratorio pratico de ims dl/i crie seu banco de dados hierarquico

☕🔥💣 LABORATÓRIO IMS DL/I: CRIANDO UM BANCO HIERÁRQUICO NA PRÁTICA

Como construir um banco IMS para CURSOS, ALUNOS e NOTAS — passo a passo para programadores COBOL iniciantes

Se você veio do mundo:

• DB2

• Oracle

• SQL Server

• MySQL

prepare-se.

Porque no IMS o mundo funciona de maneira MUITO diferente. 😄

Aqui não existem:

❌ tabelas tradicionais
❌ SELECT com JOIN
❌ modelagem relacional clássica

No IMS nós pensamos em:

🌳 HIERARQUIA

E quando você entende isso…

o “dinossauro” começa a fazer sentido.

---

🚀 Objetivo do Laboratório

Vamos criar um banco IMS para armazenar:

• cursos

• alunos

• notas

Nossa estrutura será:

CURSO
 └── ALUNO
      └── NOTA

Exemplo:

COBOL
 └── JOAO
      └── 9.5

---

🌳 Entendendo a Hierarquia

No IMS existe:

Tipo	Função
ROOT	topo da árvore
CHILD	filho
DEPENDENT	dependente

No nosso caso:

Segmento	Tipo
CURSO	ROOT
ALUNO	CHILD
NOTA	CHILD do ALUNO

---

💾 Estrutura Física Mental

Fisicamente o IMS gravará algo parecido com:

CURSO
   ↓ ponteiro
ALUNO
   ↓ ponteiro
NOTA

O IMS literalmente conecta segmentos usando ponteiros físicos.

---

☕ Etapa 1 — Criando o DBD

O:

DBD

(Database Description)

define a estrutura do banco.

---

📦 DBD Básico

DBD   NAME=ESCOLA,ACCESS=HIDAM

DATASET DD1=ESCOLADB

SEGM  NAME=CURSO,BYTES=50,PARENT=0
FIELD NAME=(CODCURSO,SEQ,U),BYTES=5,START=1

SEGM  NAME=ALUNO,BYTES=80,PARENT=CURSO
FIELD NAME=(MATRIC,SEQ,U),BYTES=6,START=1

SEGM  NAME=NOTA,BYTES=20,PARENT=ALUNO
FIELD NAME=(IDNOTA,SEQ,U),BYTES=4,START=1

DBDGEN
FINISH
END

---

🧠 O Que Está Acontecendo?

---

🌳 CURSO

Segmento ROOT.

Topo da árvore.

---

👨‍🎓 ALUNO

Filho de CURSO.

---

📊 NOTA

Filho de ALUNO.

---

🚀 ACCESS=HIDAM

Define tipo do banco.

HIDAM:

✅ rápido
✅ indexado
✅ muito usado em IMS clássico

---

☕ Etapa 2 — Gerando o DBD

Agora precisamos gerar o banco.

Usamos JCL.

---

📜 JCL DBDGEN

//DBDGEN EXEC PGM=ASMA90
//SYSIN DD *
  DBD ...
/*

Depois fazemos:

DBDGEN

para criar o módulo do banco.

---

🚀 Etapa 3 — Criando o PSB

O:

PSB

(Program Specification Block)

define como programas acessam o banco.

---

📦 Exemplo PSB

PSBGEN  PSBNAME=PSBESC

PCB     TYPE=DB,DBDNAME=ESCOLA,PROCOPT=G

SENSEG  NAME=CURSO
SENSEG  NAME=ALUNO,PARENT=CURSO
SENSEG  NAME=NOTA,PARENT=ALUNO

END

---

🧠 PROCOPT=G

Permite:

GET

Somente leitura.

Depois podemos usar:

PROCOPT	Função
G	read
A	all
I	insert
D	delete

---

☕ Etapa 4 — ACBGEN

Depois geramos:

ACB

O famoso:

Application Control Block

---

📜 JCL ACBGEN

//ACBGEN EXEC PGM=DFSRRC00

---

🚀 Etapa 5 — Inicializando Banco

Criamos datasets IMS.

Normalmente usando:

• IDCAMS

• VSAM

• utilities IMS

---

📦 Exemplo IDCAMS

//IDCAMS EXEC PGM=IDCAMS

 DEFINE CLUSTER -
 (NAME(ESCOLADB))

---

☕ Etapa 6 — Inserindo Dados

Agora vem a parte divertida. 😄

---

👨‍💻 Programa COBOL IMS

CALL 'CBLTDLI'
     USING 'ISRT'
           DB-PCB
           CURSO-AREA

---

🌳 ISRT

Significa:

INSERT SEGMENT

---

📦 Inserindo CURSO

CURSO = COBOL

---

👨‍🎓 Inserindo ALUNO

Depois navegamos:

CURSO → ALUNO

---

📊 Inserindo NOTA

Depois:

ALUNO → NOTA

---

🚀 Estrutura Final

COBOL
 └── JOAO
      └── 9.5

COBOL
 └── MARIA
      └── 8.7

---

☕ Etapa 7 — Consultando Dados

Agora usamos:

GU

(Get Unique)

---

📦 Exemplo

CALL 'CBLTDLI'
     USING 'GU  '
           DB-PCB
           AREA
           SSA.

---

🔑 SSA

Segment Search Argument.

Exemplo:

CURSO(CODCURSO=COBOL)

---

🚀 Navegando Pela Árvore

Agora usamos:

Comando	Função
GU	busca específica
GN	próximo
GNP	próximo filho

---

🌳 Exemplo Navegação

GU CURSO
GN ALUNO
GNP NOTA

---

☕ Etapa 8 — Atualizando Nota

Usamos:

REPL

(Replace)

---

📦 Fluxo

1️⃣ GU NOTA
2️⃣ altera AREA
3️⃣ REPL

---

☕ Etapa 9 — Deletando Registro

Usamos:

DLET

---

📦 Exemplo

CALL 'CBLTDLI'
     USING 'DLET'
           DB-PCB

---

🚀 O Que o Programador Junior Precisa Entender

No IMS:

⚡ você NÃO pensa em tabela.

Você pensa em:

✅ árvore
✅ caminho
✅ navegação
✅ pai-filho
✅ segmentos

---

⚔️ Diferença Mental DB2 vs IMS

---

🟦 DB2

Você pergunta:

SELECT *

---

🌳 IMS

Você navega:

ROOT → CHILD → CHILD

---

☕ Curiosidade Bellacosa Mainframe

O IMS nasceu em:

🚀 1968

para ajudar a NASA no projeto Apollo.

Décadas depois…

a mesma lógica hierárquica ainda processa:

💳 cartões
🏦 bancos
📱 mobile banking
✈️ companhias aéreas
📡 telecom

O “dinossauro” continua vivo.

E absurdamente rápido.

 

Bellacosa Mainframe apresenta conceitos de DL/I em IMS

☕🔥💣 IMS DL/I É O VERDADEIRO NoSQL ORIGINAL?

O dinossauro do mainframe que já fazia navegação hierárquica décadas antes do Vale do Silício inventar o termo “NoSQL”

Existe uma ironia maravilhosa na história da computação.

Durante anos o mercado vendeu a ideia de que:

• NoSQL era revolucionário

• bancos hierárquicos eram ultrapassados

• o futuro havia finalmente derrotado o legado

Então, em algum momento, muita gente percebeu uma coisa desconfortável:

O IMS já fazia várias dessas ideias nos anos 60.

Sim.

Décadas antes de MongoDB, Cassandra, DynamoDB ou Redis existirem…

o velho IMS já trabalhava com:

• navegação hierárquica

• acesso sem SQL

• paths previsíveis

• estruturas não relacionais

• acesso ultrarrápido

• escalabilidade absurda

E isso gera uma pergunta extremamente provocativa:

O IMS DL/I pode ser considerado um NoSQL?

A resposta curta é:

☕ Tecnicamente… SIM.

Mas com algumas nuances MUITO interessantes.

---

🌳 Antes do SQL Existia o Mundo Selvagem

Hoje quase todo desenvolvedor nasce dentro do universo SQL.

Tudo gira em torno de:

SELECT
INSERT
UPDATE
DELETE
JOIN

Mas antes da explosão dos bancos relacionais, o cenário era completamente diferente.

Existiam:

• bancos hierárquicos

• bancos em rede

• ISAM

• VSAM

• estruturas proprietárias

E foi nesse ambiente que nasceu o IMS.

Em 1968.

Durante o projeto Apollo.

Ou seja:

o IMS surgiu ANTES do SQL dominar o planeta.

---

🚀 O Que Define um Banco NoSQL?

Essa é a chave da discussão.

NoSQL normalmente significa:

“Not Only SQL”

Ou seja:

bancos que NÃO dependem do modelo relacional tradicional.

Exemplos modernos:

• MongoDB → documento

• Cassandra → colunar distribuído

• Redis → chave/valor

• Neo4j → grafos

O ponto central é:

O modelo não-relacional.

E aqui o IMS entra com força brutal.

---

🌳 IMS NÃO é Relacional

O IMS trabalha com:

Estruturas hierárquicas

Exemplo:

CLIENTE
 └── CONTA
      └── CARTAO
           └── MOVIMENTO

Isso NÃO é uma tabela relacional.

Não existem JOINs naturais.

Não existe optimizer SQL clássico.

Não existe álgebra relacional.

O acesso ocorre via:

• navegação

• paths

• ponteiros físicos

• hierarquia

Exatamente como muitos NoSQL modernos.

---

⚡ DL/I — O Anti-SQL

Aqui está a maior diferença filosófica.

No SQL você diz:

“O que eu quero.”

O banco decide:

• índice

• plano

• join

• optimizer

No DL/I você diz:

“Como navegar.”

Exemplo clássico:

CALL 'CBLTDLI'
     USING 'GU  '
           PCB
           AREA
           SSA.

O programador controla explicitamente:

• navegação

• path

• posição

• contexto hierárquico

Isso é MUITO mais próximo de certos bancos NoSQL modernos do que muita gente imagina.

---

💾 O IMS Já Fazia “Document Thinking”

Observe a estrutura:

CLIENTE
 └── CONTA
      └── MOVIMENTO

Isso lembra MUITO:

• documentos aninhados

• árvores JSON

• estruturas embedded

Exatamente o tipo de modelagem popularizada décadas depois por MongoDB.

A diferença?

O IMS fazia isso quando memória ainda era luxo.

---

🚀 Então o IMS Era um MongoDB dos Anos 60?

😄

Não exatamente.

Mas existe uma verdade desconfortável:

Muitos conceitos NoSQL modernos já existiam no IMS.

Especialmente:

• hierarquia

• navegação direta

• ausência de JOIN

• acesso por path

• performance orientada ao modelo físico

---

⚔️ Onde o IMS Difere do NoSQL Moderno

Aqui entram diferenças importantes.

---

🌐 Distribuição

Muitos NoSQL modernos nasceram para:

• cloud

• clusters massivos

• commodity servers

• sharding horizontal

O IMS nasceu para:

Mainframe centralizado de missão crítica.

---

🧠 Consistência

Muitos NoSQL modernos sacrificam:

• consistência forte

• ACID completo

em troca de escalabilidade.

O IMS faz o contrário.

Ele foi criado para:

• integridade brutal

• transações críticas

• confiabilidade absoluta

Ou seja:

O IMS é MUITO mais conservador.

---

🔥 O IMS é Quase “Pré-NoSQL”

Talvez a melhor definição seja:

O IMS é um ancestral direto do pensamento NoSQL.

Porque ele já trabalhava com:

✅ modelo não relacional
✅ paths previsíveis
✅ hierarquia
✅ performance orientada à estrutura
✅ ausência de JOIN pesado

Décadas antes do termo existir.

---

🌳 O Grande Segredo: O Modelo Físico

A maioria dos bancos modernos tenta esconder o armazenamento físico.

O IMS faz quase o oposto.

No IMS avançado:

• HDAM

• HIDAM

• DEDB

• randomizers

• root anchor points

influenciam diretamente o comportamento do banco.

O programador IMS clássico precisava entender:

COMO O DADO EXISTE NO DISCO.

Isso é extremamente raro hoje.

---

⚡ Por Que o IMS Continua Tão Rápido?

Porque ele evita camadas gigantescas de abstração.

No SQL moderno:

consulta
 → optimizer
 → parser
 → planner
 → join engine
 → executor

No IMS:

path → ponteiro → segmento

Muito mais direto.

Muito mais previsível.

Muito mais brutal.

---

☕ Easter Egg Mainframe

Existe uma piada cruel no mundo IMS:

“MongoDB reinventou a árvore.
IMS já morava na floresta.”

😄

E honestamente?

Existe bastante verdade nisso.

---

🌳 IMS e JSON — O Paradoxo Moderno

Aqui a coisa fica quase cyberpunk.

Hoje muitos sistemas modernos fazem:

JSON → API REST → z/OS Connect → IMS DL/I

Ou seja:

Aplicações mobile modernas acabam alimentando um banco hierárquico criado antes da internet existir.

Isso é absurdamente fascinante.

---

🚀 O Que os Desenvolvedores Modernos Não Percebem

Muita gente olha o IMS e pensa:

“legado.”

Veteranos enxergam outra coisa:

Engenharia extrema.

Porque o IMS foi construído numa época onde:

• CPU era escassa

• disco era lento

• memória era minúscula

Então a IBM precisou criar um sistema:

• previsível

• eficiente

• econômico

• extremamente otimizado

O resultado?

Uma arquitetura que continua competitiva em workloads específicos até hoje.

---

⚔️ O SQL Venceu… Mas Não Matou o IMS

O SQL venceu o mercado corporativo.

Isso é fato.

Mas ele NÃO substituiu totalmente o IMS.

Porque existem workloads onde:

• previsibilidade

• TPS

• throughput

• latência mínima

são mais importantes que flexibilidade.

Especialmente em:

• bancos

• telecom

• ATM

• autorização financeira

• seguros

---

🌐 O Verdadeiro Paradoxo

O mercado moderno adora chamar IMS de “tecnologia antiga”.

Mas muitas arquiteturas modernas acabaram:

voltando para ideias que o IMS já utilizava.

Inclusive:

• modelos não relacionais

• acesso orientado a documento

• estruturas hierárquicas

• paths previsíveis

• performance baseada no modelo físico

A história da computação é cheia dessas ironias.

---

💣 Então… IMS DL/I É NoSQL?

A resposta mais honesta seria:

SIM.

Mas um NoSQL ancestral.

Um NoSQL criado décadas antes do marketing inventar o termo.

O IMS não nasceu tentando ser moderno.

Ele nasceu tentando sobreviver às limitações brutais dos anos 60.

E talvez justamente por isso ele ainda exista.

Porque no final das contas:

modas tecnológicas mudam.

Mas sistemas que realmente entregam performance absurda em missão crítica raramente desaparecem.

E o velho DL/I continua navegando pela árvore como poucos sistemas modernos conseguem fazer.