IBM COBOL Check: A Ferramenta Que Trouxe Testes Unitários Modernos Para o Mundo do Mainframe

 

Bellacosa Mainframe e o IBM Cobol Check

☕💣🚀 OPERADOR, O COBOL GANHOU UM JUNIT!

IBM COBOL Check: A Ferramenta Que Trouxe Testes Unitários Modernos Para o Mundo do Mainframe

Se você trabalhou anos com COBOL, provavelmente já viveu esta situação:

Altera o programa
↓
Compila
↓
Executa o JCL
↓
Espera o batch
↓
Confere SYSOUT
↓
Descobre erro
↓
Volta para o início

Durante décadas essa foi a rotina natural do desenvolvedor Mainframe.

Enquanto isso, no mundo Java, C#, Python e JavaScript, os programadores criavam centenas de testes automatizados que validavam cada função antes mesmo do deploy.

Então surgiu uma pergunta:

"Por que COBOL não pode fazer o mesmo?"

Foi exatamente dessa necessidade que nasceu o COBOL Check.

---

O Que é o IBM COBOL Check?

O COBOL Check é um framework de testes unitários para COBOL inspirado diretamente em ferramentas como:

• JUnit (Java)

• NUnit (.NET)

• PyTest (Python)

• RSpec (Ruby)

Seu objetivo é permitir que desenvolvedores criem testes automatizados para programas COBOL de forma granular, validando regras de negócio sem depender de execuções batch completas. (GitHub)

Na prática, ele permite testar:

• Parágrafos

• Seções

• Regras de negócio

• Cálculos

• Validações

• Programas inteiros

Tudo de forma automatizada.

---

Quem Criou o COBOL Check?

Muita gente pensa que é um produto comercial da IBM.

Na realidade, o COBOL Check nasceu dentro do ecossistema do Open Mainframe Project, com apoio da comunidade Mainframe moderna e contribuições de empresas que utilizam COBOL em larga escala. (GitHub)

Seu propósito era resolver um problema antigo:

Como fazer microtestes em aplicações COBOL do mesmo modo que fazemos em Java?

---

Quando Foi Lançado?

O projeto apareceu publicamente no final da década de 2010 dentro do movimento de modernização DevOps para IBM Z.

Ele surgiu durante a onda de iniciativas Open Source voltadas ao Mainframe, juntamente com projetos como:

• Zowe

• IBM Z Open Editor

• DBB

• Galasa

e rapidamente ganhou destaque por trazer testes unitários para COBOL de forma simples. (GitHub)

---

O Problema Que Ele Resolve

Imagine um programa bancário.

CALCULA-JUROS.
    COMPUTE JUROS =
       SALDO * TAXA.

Sem testes unitários você normalmente:

1. Compila.

2. Executa JCL.

3. Alimenta arquivos.

4. Analisa relatórios.

5. Verifica resultados.

Tudo isso para validar uma única regra.

Com COBOL Check você cria um teste automatizado.

---

A Grande Ideia

O conceito é exatamente o mesmo do JUnit.

Você cria:

Código

CALCULA-DESCONTO.

Teste

TEST-DESCONTO.

Execução

PASS

ou

FAIL

Simples assim.

---

Como Funciona Internamente?

O COBOL Check cria um ambiente de teste que:

• Executa trechos específicos do programa

• Injeta dados de entrada

• Compara resultados

• Gera relatórios

Ele também oferece suporte para:

• Assertions

• Stubs

• Mocks

• Verificação de chamadas

• Relatórios JUnit XML

• Relatórios HTML (GitHub)

Isso o aproxima bastante dos frameworks modernos.

---

Sistemas Suportados

O foco principal é:

IBM z/OS

Utilizando:

• Enterprise COBOL

• JCL

• Ambientes tradicionais de produção

Também pode ser utilizado em ambientes modernos ligados ao ecossistema Open Mainframe.

---

Dependências

Uma instalação típica envolve:

Compilador COBOL

Normalmente:

• Enterprise COBOL V5+

• Enterprise COBOL V6+

Ambiente z/OS

• TSO

• ISPF

• USS (quando aplicável)

Ferramentas modernas

Frequentemente combinado com:

• Git

• Jenkins

• Zowe

• DBB

• IBM Z Open Editor (Marketplace do Visual Studio)

---

Como Instalar

O processo varia conforme a empresa.

Em geral:

1. Obter o projeto

Disponível através do repositório oficial do Open Mainframe Project. (GitHub)

2. Fazer upload

Copiar os fontes para datasets do ambiente.

Exemplo:

USER.COBOLCHECK.SOURCE

3. Compilar

Executar os jobs de instalação.

//COMPILE EXEC IGYWCL

4. Configurar bibliotecas

Adicionar:

STEPLIB
SYSLIB
COPYLIB

5. Validar instalação

Executar os exemplos fornecidos.

---

Primeiro Exemplo Passo a Passo

Vamos criar algo simples.

---

Programa

IDENTIFICATION DIVISION.
PROGRAM-ID. CALC01.

WORKING-STORAGE SECTION.
01 WS-VALOR PIC 9(5).
01 WS-DESCONTO PIC 9(5).

PROCEDURE DIVISION.

    COMPUTE WS-DESCONTO =
       WS-VALOR * 10 / 100.

    GOBACK.

---

Cenário de Teste

Queremos provar que:

1000 = 100 de desconto

---

Caso de Teste

MOVE 1000 TO WS-VALOR

PERFORM CALCULO

ASSERT WS-DESCONTO = 100

---

Resultado

TESTE 001
PASS

---

Testando Múltiplos Cenários

Você pode criar vários testes.

Caso 1

1000 -> 100

Caso 2

2000 -> 200

Caso 3

5000 -> 500

Resultado:

3 TESTS
3 PASSED

---

Assertions

Uma das partes mais importantes.

Exemplo:

ASSERT TRUE

ASSERT FALSE

ASSERT EQUAL

ASSERT NOT EQUAL

Muito parecido com:

assertEquals()
assertTrue()
assertFalse()

---

Mocks

Outro recurso extremamente poderoso.

Imagine um programa que acessa:

DB2
VSAM
IMS
MQ

Você não quer depender desses recursos durante o teste.

Então cria um Mock.

---

Exemplo Conceitual

Produção:

READ CLIENTE

Teste:

MOCK CLIENTE

Resultado:

CLIENTE SIMULADO

Sem acessar banco real.

---

Stubs

Parecido com Mock.

Você substitui componentes complexos por versões simplificadas.

Exemplo:

CONSULTA-SERASA

vira

CONSULTA-SERASA-STUB

Permitindo testes rápidos.

---

Relatórios

Após executar os testes você pode gerar:

HTML

PASS
FAIL
TOTAL

XML

Formato compatível com:

• Jenkins

• GitHub Actions

• Azure DevOps

• GitLab CI/CD (GitHub)

---

Integração com Jenkins

Fluxo clássico:

Git Commit
      ↓
Build
      ↓
COBOL Check
      ↓
Relatório
      ↓
Deploy

Se um teste falhar:

BUILD FAILED

Sem deploy.

---

Integração com Git

Imagine:

Pull Request

Antes da aprovação:

Executar COBOL Check

Resultado:

Todos os testes passaram

Só então ocorre o merge.

---

Benefícios Para Bancos

Os maiores usuários são:

• Bancos

• Seguradoras

• Telecom

• Governo

Porque possuem milhões de linhas COBOL.

Alterar uma linha sem proteção pode gerar:

S0C7
Abends
Valores incorretos
Erros financeiros

O COBOL Check reduz drasticamente esse risco.

---

Curiosidade #1

Muitos programadores COBOL experientes inicialmente desconfiaram da ideia.

A reação típica era:

"Teste unitário é coisa de Java."

Hoje isso mudou completamente.

---

Curiosidade #2

O projeto nasceu justamente porque ferramentas comerciais existentes geralmente testavam programas inteiros, mas não permitiam testar pequenos blocos de lógica com granularidade suficiente. (GitHub)

---

Curiosidade #3

Uma das metas do COBOL Check era incentivar melhores práticas de desenvolvimento, como:

• Separação de responsabilidades

• Modularização

• Refatoração segura

Conceitos já populares no mundo Java. (GitHub)

---

Dicas de Ouro

Dica 1

Comece pelos cálculos.

São os testes mais fáceis.

---

Dica 2

Não tente cobrir o sistema inteiro.

Comece pelos módulos críticos.

---

Dica 3

Automatize tudo.

Teste manual não escala.

---

Dica 4

Integre com Jenkins.

O ganho de produtividade é enorme.

---

Dica 5

Execute testes a cada alteração.

Não espere a homologação.

---

Erros Comuns

Erro 1

Criar testes enormes.

Ruim:

Testar 20 regras juntas

Bom:

1 regra = 1 teste

---

Erro 2

Depender de dados reais.

Use mocks.

---

Erro 3

Não automatizar.

Se o teste depende de ação humana:

Você perdeu metade do benefício.

---

Easter Egg Mainframe ☕

Existe uma ironia divertida na história.

Durante décadas ouvimos:

"COBOL é antigo."

Mas hoje encontramos no mundo COBOL:

✅ Git

✅ VS Code

✅ Pipelines CI/CD

✅ DevOps

✅ Open Source

✅ APIs REST

✅ Containers

✅ Testes Unitários

✅ Inteligência Artificial

Enquanto muitos sistemas "modernos" desaparecem após poucos anos, aplicações COBOL escritas nos anos 70 continuam processando bilhões de dólares diariamente.

O COBOL Check é um símbolo dessa evolução.

Ele mostra que o Mainframe não ficou parado no tempo.

Pelo contrário.

O gigante apenas incorporou as melhores ideias do desenvolvimento moderno sem abrir mão da estabilidade que o tornou lendário.

---

Conclusão

O COBOL Check representa uma das iniciativas mais importantes da modernização do desenvolvimento Mainframe.

Ele trouxe para o COBOL conceitos consagrados por ferramentas como JUnit, permitindo:

• Testes unitários automatizados

• Mocks e Stubs

• Relatórios HTML e XML

• Integração com CI/CD

• Maior qualidade de código

• Refatoração segura

• Menor risco em produção (GitHub)

No estilo Bellacosa Mainframe, podemos resumir assim:

O COBOL Check é a prova definitiva de que o COBOL não ficou preso ao passado. O gigante aprendeu a testar como os sistemas modernos, mas continua entregando a confiabilidade que mantém bancos, governos e grandes empresas funcionando todos os dias. ☕💣🚀

 

 

Bellacosa Mainframe apresenta o GIT para padawans em Mainframe

💥 Git no z/OS: O Casamento IMPROVÁVEL que Virou Revolução DevOps no Mainframe

---

🧠 Contexto: Antes era “impossível”… hoje é padrão

Em 2018, falar de git rodando dentro do z/OS era quase heresia.

• Não existia Z Open Automation Utilities
• Open Source no mainframe? Ainda engatinhando
• DevOps? Só no mundo distribuído

Hoje… 👇
👉 Temos comunidade ativa
👉 Bash rodando no USS
👉 Ferramentas open source integradas
👉 E sim… git funcionando NATIVAMENTE no z/OS

💣 Traduzindo: o mainframe deixou de ser isolado e entrou no jogo moderno.

---

🔗 Parte 1 — Conectando z/OS ao GitHub (SSH)

Aqui começa a mágica.

🧩 Problema clássico

z/OS “raiz” muitas vezes não tem DNS configurado.

🔧 Solução (tradução + comentário)

vi /etc/resolv.conf

Adicione:

nameserver 8.8.8.8

💡 Comentário Bellacosa:
Isso aqui parece simples, mas é o que separa você de:

❌ “Host desconhecido”
✔️ Integração com o mundo externo

---

🔄 Restart do resolver

opercmd "stop resolver"
opercmd "start resolver"

💥 Aqui entra realidade de mainframe:

• Precisa permissão
• Ou chama o sysprog amigo 😎

---

🔍 Teste de DNS

host github.com

Se vier IP → 🎯 sucesso

---

🔐 Parte 2 — Criando chave SSH (segurança de verdade)

ssh-keygen -t rsa -b 4096 -C "seu-email"

👉 Isso gera:

• chave privada (fica no z/OS)
• chave pública (vai pro GitHub)

---

🚀 Ativando agente SSH

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa

---

📋 Copiando chave pública

vi ~/.ssh/id_rsa.pub

Cola no GitHub:

• Settings
• SSH Keys
• New Key

---

💡 Insight Bellacosa:
Isso elimina senha.
Você entra no mundo:

👉 autenticação forte
👉 automação
👉 pipelines DevOps reais

---

🧰 Parte 3 — Instalando Git no z/OS

Aqui é onde muita gente trava.

📦 Solução moderna:

zopen install -y git

🔥 Isso instala:

• git
• dependências
• bash (ESSENCIAL!)

---

💡 Tradução prática:
Você acabou de transformar seu z/OS em um mini Linux dentro do USS.

---

🧪 Testando conexão com GitHub

ssh git@github.com

Saída esperada:

You've successfully authenticated, but GitHub does not provide shell access.

💣 Isso aqui é perfeito.
Significa:

👉 conexão OK
👉 autenticação OK
👉 pronto pra usar git

---

⚙️ Parte 4 — Configuração do ambiente

Edite o profile:

vi ~/.profile

Adicione:

git config --global user.name  "Seu Nome"
git config --global user.email "seu-email"
git config --global init.defaultBranch main
bash

---

💡 Insight poderoso:

👉 O bash aqui muda o jogo
👉 Você sai do shell limitado e entra num ambiente moderno

---

🔄 Reinicie sessão e valide

ps

Se aparecer:

bash

🎯 Missão cumprida

---

📂 Parte 5 — Clonando repositório

git clone git@github.com:usuario/repositorio.git
cd repositorio

💡 Aqui começa o DevOps REAL no mainframe.

---

🌿 Trabalhando com branch (fluxo moderno)

Criar branch

git checkout -b WordPressChange

---

Adicionar alteração

git add setenv.sh

---

Validar

git status

---

Commit

git commit

---

Enviar pro GitHub

git push origin WordPressChange

---

💥 TRADUÇÃO BELLACOSA:

Você acabou de fazer isso no z/OS:

👉 versionamento moderno
👉 branch strategy
👉 integração com GitHub
👉 colaboração distribuída

🔥 ISSO É DEVOPS NO MAINFRAME

---

🧠 Camada EXTRA — O que ninguém te conta

💣 1. USS é o segredo

Sem USS (Unix System Services), isso aqui não existiria.

---

💣 2. Git não entende dataset nativo

Você está trabalhando com:

👉 arquivos USS
👉 não diretamente com PDS/VSAM

---

💣 3. Ponte com COBOL

Fluxo real:

1. Código COBOL no USS
2. Versionado com git
3. Deploy → dataset
4. Compilação via JCL

🔥 Isso conecta dois mundos.

---

💣 4. Open Source salvando o mainframe

Sem a comunidade:

👉 nada disso existiria
👉 IBM acelerou depois

---

🧪 Exemplo real (mentalidade enterprise)

Imagine:

• Squad distribuído
• Dev Java + Dev COBOL
• Pipeline CI/CD

👉 GitHub → z/OS → compile → deploy → CICS

🔥 Isso já é realidade hoje

---

🏁 Conclusão estilo Bellacosa

💥 O que antes era “mainframe isolado” virou:

👉 plataforma integrada
👉 DevOps-ready
👉 open source friendly

E o git?

👉 virou a ponte entre gerações de tecnologia

---

☕ Frase pra fechar no estilo raiz:

“O mainframe não ficou ultrapassado…
você que ainda não viu ele rodando com git.” 😎🔥

 

 

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. 🚀☕💙