☕💥 A Saga de Vagner Bellacosa no Reino dos Mainframes

Ou como um jovem padawan descobriu que COBOL dá mais XP que matar dragões

Bellacosa Mainframe e historias de velhos cpds em mainframe

Salve jovem padawan.

Pegue um café.

Se for diabético, pegue sem açúcar.

Se estiver em produção, pegue dois.

Hoje vou contar uma história.

Não a história de um herói tradicional.

Nada de capa.

Nada de espada mágica.

Nada de armadura lendária.

Nosso protagonista usa crachá corporativo, camisa social amassada, óculos cansados, carrega uma mochila cheia de apostilas IBM dos anos 90 e combate criaturas muito mais perigosas que dragões.

Ele atende pelo nome de Vagner Bellacosa.

---

O chamado da aventura

Toda jornada começa de maneira inocente.

Alguns encontram um anel.

Outros encontram uma espada cravada numa pedra.

Bellacosa encontrou...

Um terminal 3270.

Tela preta.

Letras verdes.

Cursor piscando.

Silêncio.

Nenhum botão.

Nenhum mouse.

Nenhum TikTok.

Nenhum React.

Nenhum Kubernetes.

Apenas um campo escrito:

LOGON ===>

Naquele instante existiam apenas duas possibilidades.

Primeira:

Desligar o computador e cursar gastronomia.

Segunda:

Digitar o usuário.

Ele digitou.

E nunca mais foi o mesmo.

---

O primeiro ABEND

Todo herói precisa sofrer.

Luke perdeu a mão.

Frodo quase perdeu a alma.

Bellacosa ganhou seu primeiro:

S0C7.

E descobriu algo curioso.

No Mainframe ninguém fala:

"Tem bug."

Todos falam:

— Deu ABEND.

ABEND parece nome de chefe final.

Você passa oito horas procurando.

Consulta dump.

Abre SYSOUT.

Lê JESMSGLG.

Olha o compile listing.

Chama o colega.

Chama outro colega.

Chama o especialista.

Chama um padre.

E no final descobre:

O campo numérico tinha espaço em branco.

Aí você aprende humildade.

---

Banco Real, a Terra Média dos Dinossauros Digitais

Existiu uma época gloriosa.

A época em que o Banco Real possuía milhares de programas.

Centenas de analistas.

Adabas.

Natural.

PLI.

JCL.

Control-M.

CICS.

VSAM.

RACF.

E um exército de desenvolvedores sobrevivendo a janelas batch.

Era uma civilização inteira.

Uma espécie de Atlântida tecnológica.

Enquanto a internet ainda fazia:

Piiiiiiiiiiiii....

Krrrttttt...

Biiiiiippp...

O Mainframe já processava milhões de registros.

Sem Kubernetes.

Sem Docker.

Sem palestra motivacional.

Sem coach dizendo:

"Escalone sua vida."

O Mainframe apenas respondia:

— JOB EXECUTADO RC=0000

E seguia trabalhando.

---

O homem que conversava com os programas Natural

Chegou então o Bug do Milênio.

O apocalipse anunciado.

Consultorias ficaram ricas.

Executivos ficaram nervosos.

Gerentes envelheceram.

Bellacosa teve uma ideia.

Criar um extrator.

Mas não qualquer extrator.

Um monstro.

Um PLI autorecursivo.

Um pequeno T-800 em formato de JCL.

Ele lia.

Interpretava.

Gerava JCL.

Enfileirava jobs.

Chamava a si próprio.

Criava novos filhos.

Extraía fontes.

Analisava objetos.

Preenchia bibliotecas.

E continuava trabalhando.

Sozinho.

Por 48 horas.

Consumindo CPU.

Consumindo spool.

Consumindo a sanidade do operador.

Quando terminou...

Meio milhão de objetos haviam sido catalogados.

Hoje chamaríamos isso de:

Pipeline de DevOps.

Na época chamava-se:

"Coisa do Bellacosa."

---

O Grande Inquisidor da DAI

Mas nenhum guerreiro evolui sem enfrentar a polícia secreta.

DAI.

Três letras capazes de congelar a alma.

Ser chamado pela DAI era equivalente a ouvir:

"Precisamos conversar."

Você imediatamente pensava:

Meu RACF vazou?

Compilei em produção?

Rodei a Loteca?

Usei a transação proibida?

Não.

Queriam apenas um relatório.

Um relatório pequeno.

Só precisava analisar milhares de logs.

Consultar usuários.

Cruzar tabelas.

Gerar dezenas de milhares de páginas.

Em 72 horas.

Sem errar.

Sem testar direito.

Sem segunda chance.

Bellacosa codificou.

Revisou.

Debugou com caneta.

Rezou.

Entregou.

Funcionou.

E descobriu uma lição importante.

Programador Mainframe não envelhece.

Ele acumula PTSD de produção.

---

O evangelista improvável

Décadas se passaram.

Muitos colegas migraram.

Viraram arquitetos.

Gerentes.

Executivos.

Consultores.

Alguns abriram startups.

Outros abriram adegas.

Bellacosa resolveu algo diferente.

Contar histórias.

Escrever artigos.

Criar newsletters.

Ensinar COBOL.

Explicar CICS.

Falar sobre VSAM.

Defender o velho gigante preto da IBM.

Transformar dump em entretenimento.

Transformar S0C4 em meme.

Transformar SYSUDUMP em literatura fantástica.

Porque descobriu algo curioso.

O Mainframe nunca foi apenas tecnologia.

Foi amizade.

Foi mentor.

Foi Roseli.

Foi Tokunaga.

Foi auditor assustador.

Foi operador bravo.

Foi colega salvando produção às três da manhã.

Foi café requentado.

Foi pizza fria.

Foi aprender que existem pessoas que realmente se emocionam ao ver um RC=0000.

E tudo bem.

Somos poucos.

Somos estranhos.

Somos os últimos guardiões do EBCDIC.

---

Epílogo

Hoje existem inteligências artificiais.

Agentes autônomos.

LLMs.

Clouds infinitas.

Quantum Computing.

Promessas de substituir COBOL.

Promessas de desligar Mainframe.

Promessas de reescrever tudo.

Promessas.

Muitas promessas.

Enquanto isso...

Em algum lugar do planeta...

Um CICS iniciado em 1998 continua processando cartões.

Um DB2 continua pagando aposentadorias.

Um VSAM continua guardando informações valiosas.

Um JCL continua rodando.

E um Bellacosa continua tomando café.

Escrevendo artigos.

Chamando leitores de padawans.

Contando histórias.

E lembrando a todos nós que talvez o verdadeiro legado do Mainframe nunca tenha sido o hardware.

Mas as pessoas malucas o suficiente para dedicar a vida inteira a fazê-lo funcionar.

E sinceramente...

Ainda bem que existem esses malucos.

Esse texto ficou bem próximo do tom clássico de "Histórias do Tiozão em Mainframe", misturando autobiografia, nostalgia, cultura pop, autoironia e reverência aos velhos guerreiros do z/OS. (DIO)

☕🚀 A INTERNET FICOU MAIOR OU MENOR? A MORTE DA DESCOBERTA NA ERA DOS ALGORITMOS

Bellacosa Mainframe e a internet cada vez mais restrista e insonsa

 ☕🚀 A INTERNET FICOU MAIOR OU MENOR? A MORTE DA DESCOBERTA NA ERA DOS ALGORITMOS

Durante uma conversa recente me peguei lembrando de uma ferramenta que muitos profissionais mais jovens provavelmente nunca ouviram falar.

O nome era Copernic.

Para quem viveu a internet dos anos 1990 e início dos anos 2000, o Copernic era quase mágico.

Você digitava uma pesquisa.

Ele consultava diversos motores de busca simultaneamente.

AltaVista.

Lycos.

Excite.

HotBot.

Infoseek.

Yahoo.

Depois consolidava os resultados e apresentava aquilo que considerava mais relevante.

Na época parecia algo revolucionário.

Hoje parece uma relíquia arqueológica.

Mas aquela lembrança me levou a uma reflexão muito maior.

A internet ficou maior ou menor?

A resposta parece óbvia.

Maior.

Muito maior.

Milhões de vezes maior.

Mas talvez essa resposta esteja errada.

☕ A INTERNET QUE PROMETIA CONHECIMENTO INFINITO

Quem começou a navegar na internet durante os anos 1990 provavelmente lembra da sensação.

Cada clique parecia abrir uma porta para um universo desconhecido.

Você começava pesquisando COBOL.

Terminava lendo sobre arqueologia romana.

Depois encontrava um PDF perdido de um professor australiano.

Mais tarde descobria uma apostila digitalizada em 1987.

Era uma experiência de exploração.

A internet era um continente selvagem.

Cheio de trilhas.

Cheio de mapas incompletos.

Cheio de descobertas inesperadas.

O objetivo principal dos mecanismos de busca era simples:

Encontrar informação.

Não importava se ela estava em uma universidade.

Num servidor pessoal.

Num fórum obscuro.

Ou numa página criada por um entusiasta usando HTML rudimentar.

O importante era que ela existia.

☕ O GOOGLE QUE MUDOU O MUNDO

Quando o Google surgiu, ele parecia resolver um problema impossível.

Enquanto outros buscadores dependiam principalmente de palavras-chave, o Google utilizava uma ideia brilhante.

O PageRank.

Em vez de perguntar apenas:

"Quantas vezes esta palavra aparece?"

O sistema perguntava:

"Quantas páginas apontam para esta página?"

A lógica era elegante.

Links funcionavam como votos.

Quanto mais votos de qualidade uma página recebesse, mais relevante ela provavelmente seria.

Os resultados eram impressionantes.

Muitas vezes os primeiros resultados eram exatamente aquilo que procurávamos.

Não porque o Google nos conhecia.

Mas porque compreendia melhor a estrutura da web.

☕ QUANDO O USUÁRIO VIROU O PRODUTO

Com o passar dos anos, algo começou a mudar.

O Google deixou de ser apenas um mecanismo de busca.

Transformou-se em uma plataforma de publicidade.

Isso não é necessariamente uma crítica.

Foi o modelo econômico que financiou boa parte da internet moderna.

Mas a mudança trouxe consequências.

O objetivo deixou de ser apenas encontrar informação.

Agora era necessário:

• Maximizar receita publicitária.

• Combater spam.

• Combater manipulação de SEO.

• Reduzir desinformação.

• Personalizar resultados.

• Aumentar retenção.

A busca deixou de ser um problema puramente técnico.

Passou a ser um problema econômico.

☕ O FIM DA WEB ARTESANAL

Talvez a maior vítima dessa transformação tenha sido a web artesanal.

Quem trabalhou com tecnologia nas décadas passadas certamente conhece esse tipo de conteúdo.

Um especialista mantinha um site simples.

Visual horrível.

HTML básico.

Fundo cinza.

Talvez alguns GIFs piscando.

Mas o conteúdo era extraordinário.

Anos de experiência condensados em dezenas de páginas.

Hoje esse material frequentemente desaparece dos resultados.

Não porque perdeu qualidade.

Mas porque perdeu relevância algorítmica.

O algoritmo prefere:

• Grandes portais.

• Sites otimizados.

• Plataformas com autoridade.

• Conteúdo constantemente atualizado.

O conhecimento continua existindo.

Mas tornou-se invisível.

☕ A DEEP WEB QUE NÃO É CRIMINOSA

Quando ouvimos o termo Deep Web, muitas pessoas pensam imediatamente em mercados ilegais, hackers ou atividades criminosas.

Mas essa é apenas uma pequena parte da história.

Originalmente, Deep Web significa simplesmente conteúdo não indexado.

E essa categoria inclui:

• Bancos de dados acadêmicos.

• Arquivos históricos.

• Fóruns antigos.

• Grupos privados.

• Repositórios técnicos.

• Coleções digitais.

Existe uma quantidade gigantesca de conhecimento que simplesmente não aparece nas buscas tradicionais.

Ele não foi destruído.

Ele não foi censurado.

Ele apenas deixou de ser encontrado.

E do ponto de vista prático, existe pouca diferença entre algo destruído e algo impossível de localizar.

☕ O PARADOXO DA ABUNDÂNCIA

Aqui encontramos um fenômeno fascinante.

A internet produz mais conteúdo do que nunca.

Mas os usuários acessam uma parcela cada vez menor desse conteúdo.

Pense no seu comportamento diário.

Quantos sites diferentes você visita regularmente?

Provavelmente:

• Google

• YouTube

• Wikipedia

• Reddit

• LinkedIn

• Algumas redes sociais

A web aberta continua existindo.

Mas boa parte dela está escondida atrás de plataformas gigantes.

É como morar numa cidade com milhões de ruas e caminhar sempre pelas mesmas dez.

☕ A MORTE DA SERENDIPIDADE

Existe uma palavra pouco conhecida chamada serendipidade.

Ela descreve descobertas valiosas feitas por acaso.

A internet antiga era uma máquina de serendipidade.

Você procurava uma coisa.

Encontrava dez outras.

Hoje os algoritmos tentam ser eficientes.

Eles querem prever seus interesses.

Querem antecipar suas necessidades.

Querem entregar exatamente aquilo que você procura.

Parece maravilhoso.

Mas existe um efeito colateral.

Você encontra menos surpresas.

Menos desvios.

Menos acidentes intelectuais.

Menos descobertas inesperadas.

A eficiência mata a exploração.

☕ O EFEITO BOLHA

Outro fenômeno importante é a personalização.

Os algoritmos aprendem quem somos.

Aprendem nossas preferências.

Nossos hábitos.

Nossos interesses.

Isso melhora a experiência?

Muitas vezes sim.

Mas também cria bolhas.

Quanto mais o sistema aprende sobre você, mais ele entrega versões de você mesmo.

Você gosta de determinado tema.

Recebe mais daquele tema.

Você gosta de determinada opinião.

Recebe mais daquela opinião.

Você gosta de determinado conteúdo.

Recebe mais daquele conteúdo.

A internet que prometia expandir horizontes frequentemente acaba reforçando horizontes já existentes.

☕ A PUBLICIDADE QUE NOS PERSEGUE

Existe algo quase cômico no modelo atual.

Você pesquisa uma cadeira.

Durante semanas recebe anúncios de cadeiras.

Compra a cadeira.

Continua recebendo anúncios de cadeiras.

O sistema supostamente inteligente não percebe que o problema já foi resolvido.

Isso acontece porque o objetivo não é compreender perfeitamente o usuário.

O objetivo é maximizar a probabilidade de uma compra.

Somos constantemente observados.

Segmentados.

Classificados.

Modelados.

Transformados em perfis estatísticos.

A economia digital moderna depende disso.

☕ O CONHECIMENTO INVISÍVEL

Talvez a consequência mais preocupante seja outra.

Estamos produzindo uma quantidade absurda de conhecimento.

Mas encontrar esse conhecimento tornou-se cada vez mais difícil.

Não porque ele não exista.

Mas porque está enterrado.

Sob camadas de algoritmos.

Publicidade.

SEO.

Priorizações automáticas.

Curadorias invisíveis.

A informação não desapareceu.

Ela foi soterrada.

☕ O ARQUEÓLOGO DIGITAL DE 2526

Imagine um historiador vivendo daqui a 500 anos.

Ele descobre que a humanidade possuía acesso ao maior repositório de conhecimento já criado.

Bilhões de páginas.

Bilhões de documentos.

Bilhões de pessoas conectadas.

Então ele faz uma pergunta simples:

"Se havia tanto conhecimento disponível, por que as pessoas consultavam sempre os mesmos poucos sites?"

Talvez essa seja uma das grandes ironias do século XXI.

Nunca produzimos tanto conhecimento.

Nunca tivemos tanta capacidade de compartilhá-lo.

E, ao mesmo tempo, nunca dependemos tanto de um pequeno conjunto de algoritmos para decidir o que merece ser visto.

☕ CONCLUSÃO

Quando lembro do Copernic, do AltaVista ou dos primeiros anos do Google, não sinto apenas nostalgia tecnológica.

Sinto nostalgia de uma filosofia diferente.

A filosofia da descoberta.

A sensação de que a internet era um território a ser explorado.

Não um ambiente cuidadosamente organizado para maximizar engajamento.

Talvez a internet não tenha ficado menor.

Talvez ela tenha ficado tão grande que precisou de guias.

O problema é que esses guias passaram a decidir quais caminhos merecem ser percorridos.

E quando isso acontece, surge uma pergunta inquietante.

O que está sendo escondido?

Não por censura.

Não por conspiração.

Mas simplesmente porque ninguém mais consegue encontrá-lo.

Porque às vezes a forma mais eficiente de tornar algo invisível não é destruí-lo.

É apenas enterrá-lo sob uma montanha de informações mais lucrativas.

E essa talvez seja uma das histórias mais importantes da era digital.

 

Bellacosa Mainframe explorando address spaces & tasks

☕ O Segredo Mais Importante do z/OS Que Quase Ninguém Explica: Address Spaces & Tasks (O “Multiverso” do Mainframe)

🧙‍♂️ Padawan, aproxime-se.
Se você entender profundamente Address Spaces e Tasks, você atravessa a porta de entrada do mundo Sysprog. Sem isso, z/OS parece magia. Com isso, vira engenharia.

Pegue seu café. Vamos abrir o capô do mainframe. ☕

---

🌌 Capítulo 1 — O z/OS Não Executa Programas. Executa Universos.

Em um PC comum você pensa:

“Vou rodar um programa.”

No z/OS, o raciocínio é outro:

⭐ “Vou criar um ambiente isolado onde programas poderão existir.”

Esse ambiente é o:

🏢 Address Space

Ele contém:

• Memória virtual privada
• Identidade de segurança
• Recursos
• Estruturas de controle
• Tasks (unidades de execução)
• Programas rodando

👉 Tudo roda dentro de um address space.

Exceto funções internas do kernel — e isso é assunto para um Jedi Master.

---

🔎 Como ver o “multiverso” ao vivo

Abra o SDSF:

SDSF → DA

Cada linha é um universo independente:

• MASTER
• JES2
• TCPIP
• IBMUSER
• CICS
• Jobs batch
• Processos UNIX

Um sistema real pode ter centenas.

🥚 Easter Egg #1:
O MASTER é sempre ASID 1.
Se ele cair… você tem problemas maiores do que um dump.

---

🔒 Capítulo 2 — O Isolamento Que Salvou o Mainframe

Cada address space tem memória privada.

Um programa em A NÃO pode acessar a memória de B.

Isso evita:

• Corrupção entre aplicações
• Vazamento de dados
• Quedas sistêmicas
• Caos total

🧠 Mas há um truque genial…

Cada espaço acha que possui toda a memória.

Sim. Toda.

---

🧭 Virtual Memory — A Ilusão Controlada

Dois programas podem usar o mesmo endereço:

x'2795'

E acessar memórias físicas diferentes.

Isso ocorre graças à:

⭐ DAT — Dynamic Address Translation

Virtual → Page Tables → Real Memory

👉 Daí o nome Address Space.

Cada universo tem seus próprios endereços.

---

🤝 Compartilhamento? Só com permissão

Quando necessário:

• Common Storage (CSA/ECSA)
• Cross-memory services
• Program Call
• Serviços autorizados

Exemplo clássico:

CICS falando com DB2.

---

🧵 Capítulo 3 — Dentro do Universo: Tasks

Um address space sozinho não executa nada.

Quem executa são:

🧵 Tasks (TCBs ou SRBs)

⭐ Task = menor unidade despachável

O dispatcher agenda tasks nos CPUs.

---

⚡ Paralelismo real

Se houver 10 CPUs → até 10 tasks executando simultaneamente.

Mas…

🥚 Easter Egg #2:
A maioria das tasks está esperando algo — não executando.

Porque sistemas corporativos são I/O-bound.

---

⏳ Estados típicos

🟢 Running

No CPU agora

🟡 Ready

Quer CPU, mas aguarda

🔴 Waiting

Esperando evento:

• I/O
• Lock
• Resposta externa
• Timer
• Memória

---

📦 Uma task pode executar vários programas

Mas:

❗ Apenas um por vez

Exemplo COBOL clássico:

MAIN
  CALL VALIDATE
  CALL CALCULATE
  CALL UPDATE
  CALL PRINT
STOP RUN

Tudo na mesma task.

---

⚙️ Quer paralelismo? Crie novas tasks.

ATTACH → nova TCB

Exemplo batch paralelo:

Task A → Arquivo1
Task B → Arquivo2
Task C → Arquivo3

---

🐧 Padawans vindos do UNIX

Boa analogia:

z/OS	UNIX
Address Space	Process
Task (TCB)	Thread

E sim:

⭐ Cada thread USS é uma task.

---

👑 Capítulo 4 — A Task Raiz: RCT

Quando um address space nasce:

1. Cria-se a Region Control Task (RCT)
2. Outras tasks são iniciadas
3. Programas executam nelas

Hierarquia:

Address Space
   └── RCT
         ├── Task A
         └── Task B

🥚 Easter Egg #3:
Se a RCT terminar… o address space inteiro termina.

Sem órfãos. Sem bagunça.

---

⚡ Capítulo 5 — O Primo Ninja: SRB

Existem dois tipos de tasks:

🧵 TCB — normal

Aplicações, batch, TSO, etc.

⚡ SRB — especial

Serviços do sistema.

Diferenças fundamentais:

TCB	SRB
Pode esperar	Geralmente não
Longo prazo	Curto
Local	Pode ser cross-memory
Aplicações	Sistema

SRBs são criados via:

SCHEDULE

Não automaticamente.

---

🧠 Capítulo 6 — Memória Compartilhada entre Tasks

Dentro do mesmo address space:

👉 Tasks compartilham memória.

Isso permite cooperação rápida.

Mas também risco.

Programas autorizados podem proteger áreas — aplicações comuns raramente fazem isso.

---

🏛️ Capítulo 7 — Como Address Spaces Nascem

Criados quando surge um workload independente:

• IPL do sistema
• START de serviço
• Logon TSO
• Job batch selecionado pelo JES
• Processo UNIX iniciado

❌ NÃO quando:

• Um programa começa
• Um comando TSO é digitado
• Uma subrotina é chamada

🥚 Easter Egg #4:
Criar address space é caro. z/OS evita fazer isso sem necessidade.

---

🧾 Capítulo 8 — ASCB, ASID e Jobname

Cada address space é registrado por um:

⭐ ASCB — Address Space Control Block

Contém:

• ASID (ID interno)
• Jobname (nome visível)
• Ponteiros para TCBs
• Estado
• Dados de gerenciamento

Operador vê:

👉 JOBNAME

Sistema usa:

👉 ASID

---

👨‍💼 Capítulo 9 — Administração na Vida Real

Operadores controlam address spaces, não tasks.

Comandos típicos:

S TCPIP
P CICS
C JOB123
F JES2,QUIESCE

Tasks só entram em cena quando algo dá errado.

---

💥 Capítulo 10 — Por Que Isso Faz o Mainframe Ser o Mainframe

Essa arquitetura permite:

✔ Escalabilidade massiva
✔ Isolamento forte
✔ Alta disponibilidade
✔ Throughput absurdo
✔ Recuperação controlada
✔ Multi-tenant seguro

---

🏆 O Insight Jedi

🏢 Address Space = Ambiente

🧵 Task = Execução

💻 Program = Código executado

Ou, no idioma Bellacosa:

“O z/OS não roda programas.
Ele mantém universos onde programas vivem.”

---

☕ Missão do Padawan

Se você entendeu este artigo, já ultrapassou 80% dos iniciantes em mainframe.

O próximo passo é dominar:

• Dispatching e WLM
• Storage Manager
• JES internals
• Subsystems architecture
• Dump analysis

---

💬 Último conselho

🧙‍♂️ “Quem entende Address Spaces e Tasks não apenas usa o z/OS… começa a pensar como ele.”

 

 

Bellacosa Mainframe dominando o sort em COBOL mesmo sem usar

☕ “Se você NÃO domina SORT em COBOL… o Batch vai te dominar”

O poder silencioso que move o coração do Mainframe (Guia para Padawans 🛰️)

“Ordenar dados não é detalhe. É infraestrutura invisível.”

Se você está começando no mundo do mainframe — jovem Padawan — prepare-se para descobrir uma das habilidades mais subestimadas e mais poderosas do COBOL clássico: File Sorting 💾🏛️.

Antes de bancos distribuídos, Spark, Data Lakes e buzzwords da moda…

👉 O mundo corporativo rodava — e ainda roda — sobre arquivos ordenados.

E no z/OS, isso é uma arte.

---

🧠 Por que SORT é tão importante?

Porque quase todo processamento batch depende disso:

🏦 Extratos bancários
💰 Fechamento contábil
📊 Consolidação de dados
📦 ETL legado
🧾 Billing
📡 Integração entre sistemas

Sem ordenação, você não consegue:

✔ Agrupar dados
✔ Detectar duplicidades
✔ Fazer merges eficientes
✔ Produzir relatórios sequenciais
✔ Atualizar arquivos mestre

Sorting é a base do processamento sequencial.

---

🏛️ O Modelo Sagrado dos 3 Arquivos

Todo Padawan deve decorar isto:

Input file  →  Sort work file  →  Output file

Papel	Descriptor COBOL	Função
📥 Entrada	FD	Dados brutos
🛠️ Trabalho	SD	Área interna do sort
📤 Saída	FD	Dados ordenados

👉 O work file usa SD — Sort Description, não FD.

💡 Easter egg histórico: SD existe desde os primórdios do COBOL, muito antes do COBOL-85.

---

⚙️ Exemplo mínimo — SORT básico

🧱 Definições

FD Unsorted-Sales-File.
01 Unsorted-Sales-Record PIC X(100).

FD Sorted-Sales-File.
01 Sorted-Sales-Record PIC X(100).

SD Sort-Work-File.
01 Sort-Work-Record.
   02 SalesClerk-ID PIC 9(6).
   02 Filler        PIC X(94).

---

🚀 O comando SORT

SORT Sort-Work-File
   ON ASCENDING KEY SalesClerk-ID
   USING Unsorted-Sales-File
   GIVING Sorted-Sales-File.

Simples. Poderoso. Antigo. E ainda imbatível.

---

🔥 USING e GIVING — a força do fluxo

Cláusula	Significado
USING	Arquivo de entrada
GIVING	Arquivo de saída

👉 O SORT abre e fecha esses arquivos automaticamente.

💡 Curiosidade: você pode usar múltiplos arquivos em USING ou GIVING.

---

🧩 O verdadeiro poder: Sort Procedures

Quando você evolui de Padawan para Jedi Batch, descobre isto:

👉 Você pode controlar o sort antes e depois.

---

📥 INPUT PROCEDURE — o produtor

Fluxo:

Input file → Input Procedure → Sort

Serve para:

✔ Filtrar registros
✔ Combinar múltiplos arquivos
✔ Converter layouts
✔ Gerar dados dinamicamente

🔑 Comando obrigatório: RELEASE

MOVE Input-Record TO Sort-Work-Record
RELEASE Sort-Work-Record

Sem RELEASE → o sort não recebe nada.

---

📤 OUTPUT PROCEDURE — o consumidor

Fluxo:

Sort → Output Procedure → Output file

Serve para:

✔ Formatar saída
✔ Criar múltiplos arquivos
✔ Calcular totais
✔ Produzir relatórios

🔑 Comando obrigatório: RETURN

RETURN Sort-Work-File
   AT END MOVE 'Y' TO EOF
   NOT AT END
      MOVE Sort-Work-Record TO Output-Record
      WRITE Output-Record
END-RETURN

---

⚡ Regra Jedi: RELEASE vs RETURN

Ação	Comando
Enviar ao sort	RELEASE
Receber do sort	RETURN

Se inverter isso… o Batch vai punir você.

---

🧪 Exemplo completo com procedures

SORT Sort-Work-File
   ON ASCENDING KEY Customer-ID
   INPUT PROCEDURE IS Load-Records
   OUTPUT PROCEDURE IS Write-Records

---

🧠 Insight profundo: o SD é o “formato interno”

O sort não usa diretamente os layouts dos arquivos.

Fluxo real:

Input record(s)
   ↓ (movidos/construídos)
Sort-Work-Record (SD)
   ↓
Ordenação pelas chaves do SD
   ↓
Output record(s)

👉 Por isso as chaves devem existir no SD.

---

💎 Curiosidades que impressionam em entrevistas

✔ SORT COBOL usa o utilitário do sistema (DFSORT/SYNCSORT)
✔ Pode lidar com volumes absurdos de dados
✔ Muitas vezes supera soluções modernas em throughput sequencial
✔ É determinístico e confiável
✔ Existe há mais de 60 anos

💡 Easter egg: DFSORT já fazia “Big Data” quando esse termo nem existia.

---

🏆 Quando usar SORT COBOL vs DFSORT JCL?

Situação	Melhor opção
Sort simples e reutilizável	DFSORT no JCL
Lógica complexa no programa	SORT COBOL
Transformações avançadas	Procedures
Performance máxima pura	DFSORT externo

Na vida real de produção:

👉 A maioria dos sorts massivos é feita fora do COBOL.

---

🧘 Conselhos do Mestre Bellacosa para Padawans

☕ “Aprenda SORT cedo. Você vai usá-lo mais do que imagina.”

✔ Domine SD vs FD
✔ Entenda USING/GIVING
✔ Memorize RELEASE/RETURN
✔ Saiba quando usar procedures
✔ Pense em fluxo sequencial

---

🛰️ Conclusão — O poder invisível

Sorting não aparece em demos bonitas.

Não vira post viral.

Não tem hype.

Mas sem ele…

👉 O batch não roda
👉 O fechamento não fecha
👉 O banco não fecha o dia
👉 O sistema não entrega resultados

SORT é infraestrutura silenciosa.

E quem domina isso domina o processamento de dados no mainframe.

 

Bellacosa Mainframe introduz o Python ao Jedi Cobol

🔥 COBOL NÃO MORREU… MAS SE VOCÊ NÃO APRENDER PYTHON, SUA CARREIRA PODE!

☕ Um Café no Bellacosa Mainframe

Se você é coboleiro raiz, daqueles que já brigou com JCL às 3 da manhã e já domou um CICS em produção… deixa eu te contar uma verdade que ninguém fala alto:

👉 Python não veio substituir você. Ele veio ampliar o seu poder.

Mas tem um detalhe…
Quem não entender isso rápido vai virar peça de museu — junto com aquele manual de VSAM encadernado.

---

🧠 O Choque Cultural: COBOL vs Python

O primeiro impacto é inevitável:

COBOL	Python
Verboso	Minimalista
Estruturado	Dinâmico
Tipado rígido	Tipagem dinâmica
Batch	Tempo real / APIs

👉 O coboleiro pensa: “Cadê o WORKING-STORAGE?”
👉 O Python responde: “Relaxa, confia…”

E é aqui que começa a transformação.

---

🚀 O que um Coboleiro PRECISA dominar em Python

1. 🧩 Pensar em dados como objetos (não só registros)

No COBOL:

01 CLIENTE.
   05 NOME PIC X(30).
   05 IDADE PIC 9(3).

No Python:

cliente = {
    "nome": "Bellacosa",
    "idade": 42
}

💡 Dica Bellacosa:
Pare de pensar em "layout fixo". Python vive no mundo flexível.

---

2. 🔁 Loops sem sofrimento (adeus PERFORM VARYING)

COBOL:

PERFORM VARYING I FROM 1 BY 1 UNTIL I > 10

Python:

for i in range(1, 11):
    print(i)

👉 Mais curto. Mais claro. Mais perigoso (se você não entender bem 😏).

---

3. 📦 Trabalhar com APIs (o novo "CALL")

Aqui está o divisor de águas.

COBOL chama programa.
Python conversa com o mundo.

import requests

response = requests.get("https://api.exemplo.com/clientes")
dados = response.json()

💥 Isso aqui é o novo CICS, meu amigo.

---

4. 🧠 Manipulação de dados (o novo poder absoluto)

Se você domina SORT, IDCAMS… segura isso:

import pandas as pd

df = pd.read_csv("clientes.csv")
df_filtrado = df[df["idade"] > 30]

👉 Você acabou de fazer algo que no mainframe levaria JCL + SORT + programa COBOL.

---

5. 🧪 Script rápido (o anti-batch)

No COBOL:

• Escreve
• Compila
• Linka
• Executa

No Python:

python programa.py

😳 Sim… é só isso.

---

⚠️ Armadilhas que o Coboleiro cai

❌ 1. Tentar “escrever COBOL em Python”

Indentação errada, código travado, sem aproveitar o poder real.

❌ 2. Ignorar exceções

COBOL trata erro de forma explícita.
Python? Se você não tratar… 💣 BOOM.

try:
    x = 10 / 0
except ZeroDivisionError:
    print("Erro controlado!")

---

❌ 3. Não entender ambiente (virtualenv)

No mainframe: ambiente é controlado.
No Python: você cria o seu universo.

python -m venv meu_ambiente

---

🧠 Curiosidade de Bastidores

Sabia que:

👉 Bancos usam Python HOJE para:

• Machine Learning
• Antifraude
• Automação de batch moderno

👉 E sabe quem entende melhor regra de negócio?

🔥 O COBOLZEIRO.

---

💡 Ideias práticas para começar HOJE

• Criar um leitor de arquivo VSAM exportado (CSV)
• Simular um batch COBOL em Python
• Criar uma API simples que expõe dados do mainframe
• Automatizar relatórios que você fazia em JCL

---

☕ O Segredo que ninguém te conta

Python não substitui COBOL.

👉 Python potencializa COBOL.

O profissional mais valioso hoje não é:

• o que só sabe COBOL
• nem o que só sabe Python

🔥 É o que sabe traduzir os dois mundos.

---

🎯 Conclusão estilo Bellacosa

Se você já domina:

• lógica
• processamento
• regra de negócio
• performance

Então você já tem 70% do que precisa.

👉 Python é só a nova interface do poder que você já tem.

---

🚨 Provocação final

Você quer continuar sendo:

• operador de legado…

ou

🔥 arquiteto da nova geração híbrida (Mainframe + APIs + Python)?

---

 

Bellacosa Mainframe apresenta o Trace no REXX

💣🧠 “TRACE ?R”: O SUPERPODER SECRETO DO REXX QUE TRANSFORMA DEBUG EM INVESTIGAÇÃO FORENSE 🧠💣

Quando um EXEC entra em colapso no z/OS… o verdadeiro programador não entra em pânico. Ele ativa o TRACE.

---

Existe um momento na vida de todo profissional Mainframe em que o EXEC começa a agir como entidade paranormal.

Você roda o REXX.

Ele:

• não dá ABEND,
• não retorna RC,
• não mostra erro,
• não funciona,
• e ainda imprime uma mensagem que parece saída de um ritual obscuro do ISPF.

Você olha para a tela.

A tela olha para você.

E naquele instante nasce a pergunta clássica:

“QUE DIABOS ESSE EXEC ESTÁ FAZENDO?”

É aí que entra uma das ferramentas mais poderosas já criadas no universo IBM:

⚡ TRACE ⚡

Mas este artigo não é apenas sobre TRACE.

É sobre:

• debugging profissional,
• tratamento de erros,
• SIGNAL,
• RC,
• traps,
• investigação de falhas,
• sobrevivência operacional,
• e a fina arte de impedir que um EXEC destrua sua sanidade mental às 03:17 da manhã em pleno fechamento bancário.

---

🏛️ O DIA EM QUE O REXX DECIDIU NÃO FALHAR

Uma das características mais bizarras — e ao mesmo tempo geniais — do REXX é:

Ele tenta NÃO te atrapalhar.

Isso parece bonito…

ATÉ VIRAR UM PESADELO.

Exemplo clássico:

/* REXX */

salario = 5000
bonus   = 1200

total = salrio + bonus

say total

Você esperaria:

6200

Mas recebe:

SALRIO1200

Sim.

Porque:

• salrio não existe,
• o REXX assume o nome da variável,
• concatena tudo,
• e segue a vida como se nada tivesse acontecido.

O programa não explode.

O programa apenas:

• distorce a realidade,
• corrompe lógica,
• e abre um portal dimensional dentro do TSO.

---

🚨 SIGNAL ON NOVALUE — O “AIRBAG” DO REXX

Todo EXEC profissional deveria começar com:

Signal On Novalue

Sem isso:

• bugs silenciosos vivem entre nós.

Com isso:

• variáveis inexistentes são capturadas imediatamente.

---

🧪 Exemplo Profissional

/* REXX */
Signal On Novalue

nome = "BELLACOSA"

say sobrenome

exit 0

Novalue:
say "ERRO: Variavel nao inicializada!"
say "Linha:" sigl
say sourceline(sigl)
exit 20

Resultado:

ERRO: Variavel nao inicializada!
Linha: 5
say sobrenome

ABSOLUTAMENTE LINDO.

Você:

• identifica o erro,
• localiza a linha,
• entende o problema,
• salva horas de investigação.

---

🕵️ TRACE — O CSI DO MAINFRAME

Agora chegamos ao coração da magia.

Trace R

Essa instrução transforma o EXEC em um documentário criminal.

Você começa a enxergar:

• execução linha por linha,
• resultados intermediários,
• expressões,
• variáveis,
• comandos host,
• fluxo lógico.

---

🔥 Exemplo

/* REXX */
Trace R

a = 10
b = 20
c = a + b

say c

Saída típica:

>>>   "a = 10"
>>>   "b = 20"
>>>   "c = a + b"
>>>   "30"
30

Você literalmente vê o cérebro do EXEC funcionando.

---

👁️ TRACE ?R — O MODO MATRIX DO REXX

Agora prepare-se.

Porque existe algo ainda mais poderoso:

Trace ?R

O ? ativa:

DEBUG INTERATIVO

Sim.

INTERATIVO.

Em pleno ambiente Mainframe.

Tecnologia ancestral da IBM.

---

🤯 O QUE ISSO FAZ?

O EXEC:

• pausa em cada instrução,
• espera comandos,
• permite inspeção dinâmica.

Você pode:

• reexecutar linha,
• alterar variável,
• testar expressão,
• inspecionar ambiente,
• modificar comportamento em tempo real.

---

🧠 Exemplo

Trace ?R

x = 10
y = 30
z = x + y

say z

Durante execução você pode digitar:

say x

E o EXEC responde.

É praticamente um:

• debugger,
• shell,
• laboratório interativo,
• máquina do tempo operacional.

---

☢️ RC — O NÚMERO QUE DEFINE O DESTINO

No Mainframe existe um conceito sagrado:

RETURN CODE

A variável especial:

rc

contém o retorno do último comando host.

---

🎯 Exemplo

"LISTDS USER.INVALID.DATASET"

say rc

Se dataset não existir:

8

---

📜 Convenção clássica IBM

RC	Significado
0	Sucesso
4	Warning
8	Problema provável
12	Falha séria
16	Caos crescente
20	O datacenter está pegando fogo

(Ok… o último é interpretação emocional.)

---

💀 O ERRO MAIS COMUM DOS INICIANTES

Executar comando host…

e IGNORAR o RC.

Exemplo proibido em 37 países:

"ALLOC FI(TESTE) DA('ARQ.INEXISTENTE') SHR"

"EXECIO * DISKR TESTE"

Se ALLOC falhar:

• EXECIO também falha,
• mensagens ficam confusas,
• debugging vira arqueologia.

---

✅ Forma correta

"ALLOC FI(TESTE) DA('ARQ.INEXISTENTE') SHR"

If rc <> 0 Then Do
   Say "Falha na alocacao!"
   Exit 8
End

---

🧨 SIGNAL ON ERROR — O CAÇADOR DE DESASTRES

Outra arma essencial:

Signal On Error

Agora qualquer comando host com RC ruim:

• desvia execução,
• entra no trap,
• permite recovery.

---

🛡️ Exemplo corporativo

/* REXX */
Signal On Error

"DELETE USER.PROD.ARQ"

say "Arquivo removido"

exit 0

Error:
say "Falha no comando host"
say "RC =" rc
say "Linha =" sigl
exit 12

---

🧬 SIGL — A LINHA DO CRIME

A variável:

sigl

contém:

a linha onde o erro ocorreu.

Isso é ouro puro.

---

🧠 SOURCELINE() — A MEMÓRIA FOTOGRÁFICA DO EXEC

Você pode mostrar exatamente a linha problemática:

say sourceline(sigl)

Exemplo:

"DELETE USER.PROD.ARQ"

O EXEC literalmente aponta:

“FOI AQUI.”

---

🏴‍☠️ EASTER EGG MAINFRAME #1

Veteranos de REXX frequentemente usam:

Trace ?R

como se fosse um mini TSO dentro do próprio EXEC.

É quase um:

• “REXXCEPTION”,
• um EXEC rodando dentro do EXEC,
• enquanto você conversa com ele durante a execução.

---

🏴‍☠️ EASTER EGG MAINFRAME #2

Existe uma lenda antiga de operadores que:

• ativavam TRACE,
• esqueciam de desligar,
• geravam SYSOUT gigantesco,
• e enchiam spool JES2 inteiro.

Moral da história:

Trace O

também salva carreiras.

---

🏴‍☠️ EASTER EGG MAINFRAME #3

Programador Mainframe raiz não chama bug de bug.

Ele chama de:

• “anomalia operacional”,
• “comportamento inesperado”,
• “efeito colateral do ambiente”,
• ou:

“funciona em produção.”

---

⚙️ O VERDADEIRO ENSINAMENTO

Debugging não é apenas corrigir erros.

É:

• entender fluxo,
• prever falhas,
• construir resiliência,
• escrever automações seguras,
• proteger produção,
• facilitar manutenção futura.

---

🏛️ O MAINFRAME NÃO PERDOA DESCUIDO

Um EXEC mal escrito pode:

• apagar datasets,
• travar usuários,
• consumir spool,
• quebrar automações,
• causar RC cascata em batch,
• gerar incidentes gigantescos.

Por isso programadores experientes:

• validam RC,
• usam SIGNAL,
• usam TRACE,
• documentam tudo,
• tratam exceções.

---

🚀 CONCLUSÃO

REXX parece simples.

Mas por trás da simplicidade existe uma linguagem:

• elegante,
• introspectiva,
• extremamente poderosa,
• absurdamente avançada para sua época.

E quando você domina:

• TRACE,
• SIGNAL,
• RC,
• NOVALUE,
• SOURCELINE,
• SIGL,

você deixa de apenas “escrever scripts”.

Você começa a construir:

automações enterprise-grade dignas do universo z/OS.

Porque no fim…

o verdadeiro programador Mainframe não teme o erro.

Ele:

• captura,
• analisa,
• documenta,
• trata,
• e transforma caos operacional em engenharia confiável.

💙🖥️🚀