Translate

Mostrar mensagens com a etiqueta Tecnologia IBM Z. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Tecnologia IBM Z. Mostrar todas as mensagens

sábado, 6 de julho de 2024

☕🚀 PADAWAN, YAML NÃO É LINGUAGEM DE PROGRAMAÇÃO. É A FICHA DE CADASTRO DO UNIVERSO DEVOPS!

 

Bellacosa Mainframe e a introdução a YAML

☕🚀 PADAWAN, YAML NÃO É LINGUAGEM DE PROGRAMAÇÃO. É A FICHA DE CADASTRO DO UNIVERSO DEVOPS!

Se você veio do mundo COBOL, JCL, PROC, PARMLIB, SYSIN, cartões perfurados, datasets sequenciais e arquivos de configuração gigantescos, provavelmente já esbarrou em um arquivo chamado:

application.yaml
docker-compose.yaml
kubernetes.yaml
pipeline.yaml

E talvez tenha pensado:

"Mas afinal... que diabos é YAML?"

Sente-se, pegue seu café e venha comigo.

Porque entender YAML hoje é quase tão importante para um desenvolvedor moderno quanto entender JCL era para um programador mainframe nos anos 80.


A HISTÓRIA DO YAML

YAML significa:

YAML Ain't Markup Language

Ou seja:

"YAML não é uma linguagem de marcação."

O nome é um trocadilho.

No início ele significava:

Yet Another Markup Language
(Mais uma linguagem de marcação)

Mas depois os criadores perceberam que YAML não era exatamente uma linguagem de marcação como XML.

Então mudaram para:

YAML Ain't Markup Language


QUANDO O YAML NASCEU?

O projeto surgiu em:

2001

Criado por:

  • Clark Evans

  • Ingy döt Net

  • Oren Ben-Kiki

O objetivo era simples:

Criar algo mais legível que XML.

Na época o XML dominava tudo.

Exemplo XML:

<cliente>
   <nome>João</nome>
   <idade>25</idade>
</cliente>

Os criadores pensaram:

"Por que tanta tag abrindo e fechando?"

Então nasceu YAML.


VERSÕES IMPORTANTES

YAML 1.0

2004

Primeira versão oficial.


YAML 1.1

2005

Mais recursos.

Maior adoção.


YAML 1.2

2009

Versão mais usada atualmente.

Compatibilidade melhor com JSON.


POR QUE O YAML FICOU TÃO POPULAR?

Porque ele resolveu um problema enorme:

Configurações.

Todo sistema precisa delas.

Antes tínhamos:

  • INI

  • XML

  • Properties

  • Arquivos texto

Mas YAML ficou muito mais fácil de ler.


PARA QUE SERVE O YAML?

Basicamente:

Armazenar configuração

Exemplo:

servidor:
  porta: 8080

banco:
  host: localhost

ONDE O YAML É UTILIZADO?

Hoje praticamente em todo lugar.


Kubernetes

Talvez o maior usuário de YAML do planeta.

apiVersion: v1
kind: Pod
metadata:
  name: meu-pod

Docker Compose

version: "3"

services:
  banco:
    image: mysql

Spring Boot

server:
  port: 8080

GitHub Actions

name: Build
on: push

GitLab CI

stages:
  - build
  - deploy

Ansible

- hosts: servidores

O YAML PARA UM COBOLISTA

Imagine um membro PARMLIB.

Por exemplo:

PORTA=8080
HOST=localhost

YAML faz algo semelhante.

Só que organizado hierarquicamente.

servidor:
  host: localhost
  porta: 8080

É como um PARMLIB muito mais moderno.


A REGRA MAIS IMPORTANTE DO YAML

Padawan...

A regra mais importante é:

ESPAÇOS

Não TAB.

Não misture.

Não invente.

Somente espaços.


EXEMPLO VÁLIDO

cliente:
  nome: João
  idade: 25

EXEMPLO INVÁLIDO

cliente:
<TAB>nome: João

Muitos erros acontecem por causa disso.


ESTRUTURA BÁSICA

Tudo gira em torno de:

chave : valor

nome: João

idade: 25

ativo: true

TIPOS DE DADOS

Texto

nome: Bellacosa

Número

idade: 50

Decimal

salario: 3500.99

Booleano

ativo: true

Nulo

valor: null

AGRUPAMENTOS

Podemos criar grupos.

cliente:
  nome: João
  idade: 25

Representa:

{
  "cliente":{
      "nome":"João",
      "idade":25
  }
}

LISTAS

Parecido com OCCURS.

linguagens:
  - COBOL
  - Java
  - Python

Equivale a:

[
 "COBOL",
 "Java",
 "Python"
]

LISTA DE OBJETOS

Muito usada.

funcionarios:

  - nome: João
    cargo: Programador

  - nome: Maria
    cargo: Analista

COMENTÁRIOS

Como no JCL usamos:

//*

No YAML usamos:

# comentário

Exemplo:

# porta da aplicação
porta: 8080

STRINGS

Pode ser:

nome: Bellacosa

Ou:

nome: "Bellacosa"

Ou:

nome: 'Bellacosa'

MULTILINHAS

Muito útil.

descricao: |
  Linha 1
  Linha 2
  Linha 3

Resultado:

Linha 1
Linha 2
Linha 3

EXEMPLO PRÁTICO SPRING BOOT

Imagine uma API Java.

Arquivo:

server:
  port: 8080

spring:
  datasource:
    url: jdbc:mysql://localhost/teste
    username: root
    password: 123

Quando a aplicação sobe:

  • Porta 8080

  • Banco MySQL

  • Usuário root

Tudo configurado via YAML.


EXEMPLO PRÁTICO DOCKER COMPOSE

version: '3'

services:

  mysql:
    image: mysql:8

  app:
    image: minha-api

Traduzindo:

"Suba dois containers"

  • MySQL

  • Aplicação


EXEMPLO PRÁTICO KUBERNETES

Aqui mora o YAML.

Praticamente tudo no Kubernetes é YAML.

apiVersion: v1

kind: Pod

metadata:
  name: bellacosa

spec:

  containers:
    - name: app
      image: nginx

Executa:

kubectl apply -f pod.yaml

E o cluster cria o pod.


COMANDOS IMPORTANTES

YAML em si não possui comandos.

Isso é importante.

Muitos iniciantes confundem.

YAML é apenas:

Estrutura de dados.

Os comandos pertencem à ferramenta.


Exemplo:

Docker:

docker compose up

Kubernetes:

kubectl apply -f arquivo.yaml

Ansible:

ansible-playbook playbook.yaml

GitHub:

Automaticamente lê:

.github/workflows/build.yaml

YAML E JSON

Você sabia?

Todo JSON válido pode ser convertido para YAML.


JSON:

{
  "nome":"João"
}

YAML:

nome: João

Muito mais limpo.


VANTAGENS

Legibilidade

A maior vantagem.


Fácil de aprender

Poucas regras.


Menos verboso

Muito menor que XML.


Hierarquia natural

A indentação mostra tudo.


Amplamente suportado

Praticamente todas as linguagens.


Excelente para DevOps

Docker

Kubernetes

GitHub

Ansible

Terraform

Tudo conversa com YAML.


DESVANTAGENS

Nem tudo são flores.


Sensível a espaços

Um espaço errado:

Tudo quebra.


Difícil para estruturas gigantes

Arquivos enormes viram labirintos.


Erros nem sempre claros

Às vezes o parser reclama na linha 200.

Mas o erro está na linha 30.


Não é ideal para dados complexos

JSON pode ser mais seguro.


ERROS CLÁSSICOS DE INICIANTES

Misturar TAB e espaço

Erro número 1.


Indentação incorreta

Errado:

cliente:
nome: João

Correto:

cliente:
  nome: João

Esquecer hífen em listas

Errado:

linguagens:
 COBOL
 JAVA

Correto:

linguagens:
 - COBOL
 - JAVA

LABORATÓRIO 1

Criar arquivo:

empresa:
  nome: Bellacosa Mainframe
  fundacao: 2024

Salvar:

empresa.yaml

LABORATÓRIO 2

Adicionar funcionários.

empresa:

  nome: Bellacosa Mainframe

  funcionarios:

    - nome: João
      cargo: Programador

    - nome: Maria
      cargo: Analista

LABORATÓRIO 3

Converter para JSON

Resultado:

{
  "empresa":{
    "nome":"Bellacosa Mainframe",
    "funcionarios":[
      {
        "nome":"João",
        "cargo":"Programador"
      },
      {
        "nome":"Maria",
        "cargo":"Analista"
      }
    ]
  }
}

YAML E COBOL

Imagine uma configuração externa.

Antes:

01 PARAMETROS.
   05 PORTA       PIC 9(4).
   05 HOST        PIC X(50).

Lendo de arquivo texto.

Hoje poderíamos ter:

aplicacao:
  host: localhost
  porta: 8080

Uma API Java poderia ler isso.

Uma aplicação Node.js também.

Um container Docker também.

Todos compartilhando o mesmo arquivo.


YAML NO MUNDO MAINFRAME

Muita gente acredita que YAML não tem relação com Mainframe.

Erro enorme.

Hoje encontramos YAML em:

  • OpenShift on Z

  • Kubernetes on IBM Z

  • z/OS Connect

  • IBM Cloud

  • Ansible Automation Platform

  • DevOps Enterprise


Imagine um pipeline CI/CD para COBOL:

stages:

  - build

  - test

  - deploy

Esse YAML pode controlar:

  • Compilação COBOL

  • Link Edit

  • Testes

  • Deploy

Tudo automaticamente.


ANALOGIA BELLACOSA MAINFRAME

Se eu tivesse que explicar YAML para um operador de mainframe dos anos 80, eu diria:

JCL diz O QUE EXECUTAR.

COBOL diz COMO PROCESSAR.

YAML diz COMO CONFIGURAR.

Ele é o formulário de configuração do ecossistema moderno.

Não executa lógica.

Não faz cálculo.

Não substitui COBOL.

Não substitui Java.

Não substitui Python.

Mas conecta todos eles.


CONCLUSÃO

Padawan...

Se nos anos 70 o profissional de tecnologia precisava entender:

  • JCL

  • PROCs

  • PARMLIB

  • SYSIN

Hoje o profissional moderno precisa entender:

  • YAML

  • Docker

  • Kubernetes

  • GitHub Actions

  • CI/CD

YAML tornou-se a linguagem universal da configuração.

Sua sintaxe minimalista, sua legibilidade e sua adoção massiva fizeram dele um dos formatos mais importantes da computação moderna.

E existe uma grande chance de que o próximo arquivo que você abrir em um projeto de nuvem, DevOps, containers, APIs ou automação tenha exatamente esta extensão:

.yaml

ou

.yml

Quando isso acontecer, não tenha medo.

Lembre-se desta regra:

"YAML é para o DevOps o que o PARMLIB foi para o Mainframe: um lugar onde a configuração mora para que o programa possa trabalhar."

E quando você dominar YAML, Kubernetes, Docker e automação, perceberá algo curioso:

O mercado mudou, as ferramentas mudaram, os nomes mudaram...

Mas a ideia continua a mesma desde os tempos do COBOL:

separar a configuração da lógica do programa.

Essa é uma das filosofias mais antigas, elegantes e duradouras da computação. 🚀☕💙


sábado, 3 de abril de 2021

☕💣🚀 PADAWAN, O IMS NÃO É UM BANCO DE DADOS. É UMA CIVILIZAÇÃO DIGITAL QUE SOBREVIVEU A TODAS AS MODAS DA COMPUTAÇÃO!

 

Bellacosa Mainframe e o database ims

☕💣🚀 PADAWAN, O IMS NÃO É UM BANCO DE DADOS. É UMA CIVILIZAÇÃO DIGITAL QUE SOBREVIVEU A TODAS AS MODAS DA COMPUTAÇÃO!

A Anatomia Completa do IMS DB: Como uma Tecnologia Nascida Para Levar o Homem à Lua Continua Movimentando Trilhões de Dólares no Século XXI

Quando alguém escuta a sigla IMS, normalmente imagina um sistema antigo, preso aos anos 1960, escondido em alguma sala refrigerada de um banco.

Mas essa visão está tão errada quanto acreditar que um Boeing 787 voa usando a mesma tecnologia dos irmãos Wright.

O IMS evoluiu.

E evoluiu muito.

O que nasceu em 1966 para ajudar a NASA no Programa Apollo transformou-se em uma das plataformas de gerenciamento de dados mais resilientes da história da computação. Segundo o material estudado, o IMS foi desenvolvido pela IBM em parceria com Rockwell e Caterpillar para apoiar o projeto que levaria o homem à Lua.

Mais de meio século depois, ele continua processando algumas das cargas de trabalho mais críticas do planeta.

E existe uma razão simples para isso:

O IMS não foi construído para ser bonito.

Foi construído para nunca falhar.


O Grande Equívoco dos Novatos

Uma das primeiras armadilhas para quem começa a estudar IMS é tentar compará-lo diretamente com bancos relacionais.

O raciocínio geralmente é:

  • Oracle possui tabelas

  • SQL Server possui tabelas

  • PostgreSQL possui tabelas

  • Então IMS também deve possuir tabelas

Não.

O IMS enxerga o mundo de forma completamente diferente.

Enquanto bancos relacionais organizam informações em linhas e colunas, o IMS organiza informações em árvores hierárquicas.

Imagine uma árvore genealógica.

Existe:

  • um ancestral

  • filhos

  • netos

  • bisnetos

Esse é exatamente o modelo mental utilizado pelo IMS.

A estrutura inteira foi desenhada para representar relacionamentos naturais de dependência.


Por Que a IBM Criou um Banco Hierárquico?

Voltemos para 1966.

Não existiam:

  • bancos relacionais

  • SQL

  • ORM

  • Hibernate

  • Entity Framework

  • MongoDB

  • Kubernetes

A preocupação era outra.

A NASA precisava controlar volumes gigantescos de componentes.

Imagine um foguete Saturn V.

Ele possuía:

  • estágios

  • motores

  • sistemas hidráulicos

  • sistemas elétricos

  • sensores

Cada componente dependia de outro componente.

O modelo hierárquico era extremamente natural para representar essa realidade.

Foi daí que nasceu o IMS.


O Que É um Segmento?

No universo IMS, tudo gira ao redor do conceito de segmento.

O tutorial define segmento como a menor unidade de informação movimentada entre a aplicação e o banco através do DL/I.

Pense nele como um registro lógico.

Exemplo:

CLIENTE
--------
Código
Nome
CPF
Telefone

Esse conjunto de campos forma um segmento.


Campo Não É Segmento

Outro erro comum.

Campo e segmento não são a mesma coisa.

O segmento é o recipiente.

Os campos são os dados armazenados dentro dele.

Exemplo:

CLIENTE
    Código
    Nome
    CPF
    Cidade

CLIENTE = Segmento

Código = Campo

Nome = Campo

CPF = Campo

Cidade = Campo

Parece simples.

Mas essa distinção é fundamental para entender DBDs, PSBs e chamadas DL/I.


O Poder da Hierarquia

Imagine uma seguradora.

Cada cliente possui:

CLIENTE
 ├── APÓLICE
 │     ├── COBERTURA
 │     ├── SINISTRO
 │     └── PAGAMENTO

Perceba algo interessante.

Um sinistro não existe sem uma apólice.

Uma apólice não existe sem um cliente.

Essa dependência natural é exatamente o que o IMS modela de forma brilhante.


O Segmento Root: O Imperador da Galáxia

Toda hierarquia IMS possui um segmento raiz.

O chamado Root Segment.

Ele é o ponto de entrada para todo o restante da estrutura.

Sem ele nada existe.

Na prática:

CLIENTE
 ├── CONTA
 ├── CARTÃO
 └── EMPRÉSTIMO

CLIENTE seria o Root.

Toda navegação começa nele.

Toda recuperação passa por ele.

Toda inserção depende dele.


Parent, Child, Dependents e a Família IMS

Uma das razões pelas quais o IMS é intuitivo é que ele utiliza conceitos familiares.

O material apresenta:

Parent Segment

Segmento que possui filhos abaixo dele.

Child Segment

Segmento que possui um pai acima dele.

Dependent Segment

Qualquer segmento que não seja raiz.

Isso cria uma estrutura extremamente organizada.


Twin Segments: Os Gêmeos do Banco

Uma característica curiosa do IMS é a existência dos Twin Segments.

Imagine:

CLIENTE
 ├── CONTA 001
 ├── CONTA 002
 ├── CONTA 003

Todas são ocorrências do mesmo tipo de segmento.

Logo:

CONTA 001
CONTA 002
CONTA 003

são twins.

Em bancos relacionais isso parece trivial.

No IMS isso influencia diretamente o processamento DL/I.


Database Record: Muito Mais Que Um Registro

Em SQL um registro normalmente significa uma linha.

No IMS não.

Um Database Record é composto pelo Root mais todos os segmentos subordinados.

Exemplo:

CLIENTE
 ├── CONTA
 │    ├── MOVIMENTO
 │    ├── MOVIMENTO
 │    └── MOVIMENTO
 └── CARTÃO

Tudo isso junto forma um único Database Record.

Essa diferença muda completamente a forma de programar.


Database Path: A Estrada Dentro da Árvore

O conceito de Path é outro dos pilares do IMS.

Um Path é o caminho percorrido do Root até um segmento específico.

Exemplo:

CLIENTE
 └── CONTA
      └── MOVIMENTO

O caminho é:

CLIENTE → CONTA → MOVIMENTO

Não é permitido "pular" níveis.

Isso garante consistência estrutural.


DL/I: O Tradutor Universal

Se existe algo que todo programador IMS precisa dominar é o DL/I.

O Data Language Interface é a interface utilizada pelos programas para conversar com o banco.

Pense nele como:

SQL do IMS

Mas muito mais poderoso.

E muito mais perigoso para iniciantes.


Processamento Sequencial: A Filosofia Original

O tutorial mostra que o processamento sequencial segue um padrão fixo:

Primeiro desce.

Depois anda para a direita.

Em outras palavras:

Root
 ↓
Filho
 ↓
Neto
 ↓
Bisneto
 →
Próximo irmão

Isso parece estranho para quem vem de SQL.

Mas oferece uma eficiência impressionante.


Processamento Aleatório: A Arma dos Especialistas

Nem sempre queremos percorrer a árvore inteira.

Às vezes queremos acessar diretamente:

Cliente 999999

Nessa situação usamos Random Processing.

Para isso fornecemos uma chave concatenada.

Exemplo:

BANCO
CLIENTE
CONTA

Essa combinação identifica exatamente o caminho desejado.


Chave Concatenada: A Magia do Desempenho

O tutorial apresenta um conceito frequentemente ignorado pelos novatos:

Concatenated Key.

Ela contém as chaves de todos os segmentos necessários para localizar um ponto específico da árvore.

Exemplo:

AGENCIA = 1234
CLIENTE = 998877
CONTA = 000001

Juntos eles definem um único caminho.

É isso que torna o acesso tão rápido.


Por Que IMS Costuma Ser Mais Rápido Que Bancos Relacionais?

O próprio material destaca que o processamento IMS costuma ser mais rápido que DB2 para determinadas cargas.

O motivo é simples.

Não existe JOIN.

Não existe otimizador tentando adivinhar o melhor plano.

Não existe estatística de tabela.

A estrutura já define previamente o caminho.

O acesso é direto.

Determinístico.

Previsível.


DBD: O DNA do Banco

Chegamos a uma das partes mais importantes.

O DBD.

Database Descriptor.

Se o banco fosse um ser humano, o DBD seria seu DNA.

Ele descreve:

  • segmentos

  • campos

  • relacionamentos

  • método de acesso

  • estrutura física

Nada existe sem o DBD.


DBDGEN: O Ritual Sagrado dos DBAs IMS

O DBD é construído através do DBDGEN.

Quem já trabalhou com IMS sabe:

Criar um DBD não é apenas escrever macros.

É desenhar a forma como os próximos milhões de registros viverão pelos próximos anos.

Um erro de modelagem pode sobreviver décadas.


PSB: A Janela do Programa

O programa COBOL não enxerga o banco inteiro.

Ele enxerga apenas o que o PSB permite.

Imagine um castelo.

O DBD define o castelo.

O PSB define quais portas podem ser abertas.

Isso oferece:

  • segurança

  • isolamento

  • controle


PCB: O Passaporte da Aplicação

Dentro do PSB encontramos os famosos PCBs.

Program Communication Blocks.

Eles informam:

  • qual banco acessar

  • quais segmentos acessar

  • quais operações executar

Sem PCB não existe comunicação.


ACB: A União dos Mundos

O ACB combina:

DBD
+
PSB
=
ACB

O tutorial descreve o ACB como a forma executável do acesso ao banco.

É o elo final entre definição e execução.


DFSRRC00: O Maestro da Orquestra

Uma curiosidade que separa iniciantes de veteranos.

Programas IMS Batch normalmente são executados através do módulo:

DFSRRC00

O material mostra esse papel do módulo de inicialização batch IMS.

Quando um desenvolvedor COBOL executa um programa IMS, frequentemente é esse componente que está coordenando toda a operação.


O Programa COBOL Não Conversa Diretamente Com o Banco

Esse é outro conceito importante.

O fluxo real é:

COBOL
 ↓
DL/I
 ↓
IMS
 ↓
Database

O programa nunca acessa diretamente os dados.

Tudo passa pela camada DL/I.


O Verdadeiro Poder do IMS

Agora chegamos ao ponto que raramente aparece em tutoriais.

O verdadeiro poder do IMS não está em segmentos.

Nem em DBDs.

Nem em PSBs.

Nem mesmo no DL/I.

O verdadeiro poder está na previsibilidade.

Quando um banco movimenta:

  • cartões

  • seguros

  • telecomunicações

  • reservas aéreas

  • operações bancárias

o requisito principal não é inovação.

É sobrevivência.

O IMS foi desenhado para operar continuamente durante décadas.

E conseguiu.


O Que os Desenvolvedores Modernos Podem Aprender com o IMS?

Muita coisa.

Principalmente:

Modelagem importa

O IMS força o arquiteto a pensar antes de criar.

Performance nasce no desenho

Não existe milagre posterior.

Estruturas simples escalam

Uma árvore bem desenhada pode sobreviver cinquenta anos.

Confiabilidade vale mais que moda

Tecnologias modernas aparecem todos os anos.

Pouquíssimas permanecem relevantes por meio século.


Conclusão: O IMS Não Sobreviveu ao Futuro. Ele Ajudou a Construí-lo.

Existe uma frase que gosto de repetir aos alunos:

"O mundo não roda em aplicativos modernos. O mundo roda em sistemas que nunca podem parar."

O IMS é um dos maiores exemplos dessa realidade.

Enquanto gerações de bancos surgiram e desapareceram, o IMS continuou armazenando informações críticas, processando transações e sustentando operações que movimentam parte significativa da economia mundial.

Quando você estuda Root Segments, Paths, DBDGEN, PSBGEN, PCBs e DL/I, não está apenas aprendendo uma tecnologia antiga.

Está estudando uma das arquiteturas mais bem-sucedidas da história da computação corporativa.

E talvez essa seja a maior lição do IMS:

Em tecnologia, longevidade não acontece por acaso. Ela é conquistada através de decisões de arquitetura tão sólidas que continuam funcionando décadas depois que todas as tendências da época desapareceram.