Translate

Mostrar mensagens com a etiqueta DFSORT. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta DFSORT. Mostrar todas as mensagens

domingo, 1 de março de 2026

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

 

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
PapelDescriptor COBOLFunção
📥 EntradaFDDados brutos
🛠️ TrabalhoSDÁrea interna do sort
📤 SaídaFDDados 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áusulaSignificado
USINGArquivo de entrada
GIVINGArquivo 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çãoComando
Enviar ao sortRELEASE
Receber do sortRETURN

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çãoMelhor opção
Sort simples e reutilizávelDFSORT no JCL
Lógica complexa no programaSORT COBOL
Transformações avançadasProcedures
Performance máxima puraDFSORT 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.

sexta-feira, 20 de fevereiro de 2026

🔥 “Pandas: O ‘SORT’ do Python que Vai Fazer Você Repensar Tudo que Sabe sobre Arquivos Sequenciais”

 

Bellacosa Mainframe apresenta Pandas a Biblioteca poderosa do Python

🔥 “Pandas: O ‘SORT’ do Python que Vai Fazer Você Repensar Tudo que Sabe sobre Arquivos Sequenciais”


Se você vem do mundo COBOL, prepare-se: este não é apenas mais um artigo sobre Python.

É um choque de paradigma.

É como sair do SORT FIELDS=(...) no JCL e descobrir que você pode fazer tudo isso… e mais… em uma única linha de código.

Hoje vamos falar da biblioteca pandas — mas no estilo Bellacosa Mainframe: com história, bastidores, comparações práticas com COBOL, exemplos reais e até alguns easter eggs que vão te surpreender.


☕ 1. A Origem do Pandas — Não, Não Tem Nada a Ver com o Animal 🐼

O nome pandas vem de:

PANel DAta Structure

Criada em 2008 por Wes McKinney, a biblioteca nasceu dentro de um problema real:

👉 manipular dados financeiros de forma eficiente (algo que qualquer sistema em COBOL faz há décadas).

Ou seja…

💡 Pandas nasceu resolvendo problemas que você já resolve no mainframe.

A diferença?

👉 Ele fez isso com uma abordagem muito mais dinâmica e interativa.


🧠 2. O “choque cultural” para quem vem do COBOL

Se você trabalha com:

  • Arquivos VSAM
  • Sequential files
  • SORT / ICETOOL
  • DFSORT
  • DB2 queries

Então o pandas vai parecer… estranho no começo.

Mas depois:

🔥 viciante

Veja essa comparação:

COBOL / JCLPandas
SORT FIELDSsort_values()
READ FILEread_csv()
WRITE FILEto_csv()
IF / EVALUATEfiltros (query / loc)
FILE LAYOUTDataFrame

👉 O DataFrame é o seu novo “registro + tabela + dataset + tudo junto”


📊 3. O coração do Pandas: DataFrame

Imagine isso:

01 CLIENTE.
05 ID PIC 9(05).
05 NOME PIC X(30).
05 SALDO PIC 9(10)V99.

Agora pense nisso como uma tabela inteira carregada na memória.

👉 Isso é um DataFrame

Exemplo em Python:

import pandas as pd

dados = {
"ID": [1, 2, 3],
"NOME": ["ANA", "JOAO", "CARLA"],
"SALDO": [1500.50, 230.00, 9999.99]
}

df = pd.DataFrame(dados)

print(df)

Resultado:

ID NOME SALDO
0 1 ANA 1500.50
1 2 JOAO 230.00
2 3 CARLA 9999.99

💡 Pense assim:

👉 Você carregou um arquivo inteiro na WORKING-STORAGE… mas com superpoderes.


⚡ 4. Filtrando dados — o “IF” mais poderoso que você já viu

COBOL:

IF SALDO > 1000
DISPLAY CLIENTE
END-IF

Pandas:

df[df["SALDO"] > 1000]

Sim.

Só isso.

🔥 Sem loop. Sem READ. Sem controle manual.


🔀 5. Ordenação — adeus SORT JCL?

JCL:

SORT FIELDS=(SALDO, D)

Pandas:

df.sort_values(by="SALDO", ascending=False)

👉 Em memória
👉 Instantâneo
👉 Encadeável com outras operações


🧩 6. JOIN (sim, tipo DB2)

COBOL tradicional sofre aqui…

Mas pandas:

df1.merge(df2, on="ID", how="inner")

💡 É como um:

SELECT *
FROM A, B
WHERE A.ID = B.ID

🧠 7. Agrupamento (o famoso SUM + BREAK logic)

COBOL:

  • Sort
  • Control break
  • Acumuladores
  • Mil linhas de código 😅

Pandas:

df.groupby("NOME")["SALDO"].sum()

🔥 Isso substitui um programa inteiro de batch.


🥚 8. Easter Eggs do Pandas (sim, existem!)

🐼 1. Representação visual amigável

O pandas automaticamente formata tabelas no estilo “relatório bonito”.

👉 Parece um mini-ISPF tabular 😄


🧪 2. Você pode encadear tudo

df[df["SALDO"] > 1000] \
.sort_values(by="SALDO") \
.head(2)

💡 Isso seria:

  • filtro
  • sort
  • limitar registros

👉 tudo em pipeline


🧙 3. Pandas aceita dados de tudo

  • CSV (sequencial)
  • Excel
  • JSON
  • SQL
  • APIs

👉 É como se o COBOL lesse qualquer formato… sem FD.


🏛️ 9. Curiosidade histórica (nível mainframe)

Enquanto o mundo distribuído evoluía…

👉 o mainframe já fazia:

  • processamento massivo
  • batch
  • ETL
  • consistência

O pandas basicamente trouxe essa filosofia para o mundo Python.

💡 Em outras palavras:

Pandas é o “mini-mainframe” do desenvolvedor moderno


🚀 10. Onde isso muda sua carreira

Se você domina COBOL e aprende pandas:

🔥 você vira um profissional híbrido raríssimo

Você passa a atuar em:

  • Engenharia de dados
  • Data analytics
  • Integração legado + moderno
  • Automação de processos batch fora do mainframe

👉 E o melhor:

Você não joga fora seu conhecimento COBOL.

Você expande ele.


🧠 11. Mentalidade nova (o pulo do gato)

COBOL:

👉 Processamento linha a linha

Pandas:

👉 Processamento em conjunto (vetorizado)

Esse é o maior shift.


☕ Conclusão no estilo Bellacosa

Se o COBOL te ensinou disciplina…

Se o JCL te ensinou controle…

Se o SORT te ensinou performance…

Então o pandas vai te ensinar:

🔥 liberdade

Mas cuidado…

Depois que você fizer um groupby().sum() em uma linha…

👉 você nunca mais vai olhar um control-break da mesma forma.

terça-feira, 26 de janeiro de 2021

☕🔥 25 CODING PATTERNS — O “DNA INVISÍVEL” QUE TODO PROGRAMADOR DE MAINFRAME USA (MESMO SEM PERCEBER)

 

Bellacosa Mainframe apresenta 25 coding patterns

☕🔥 25 CODING PATTERNS — O “DNA INVISÍVEL” QUE TODO PROGRAMADOR DE MAINFRAME USA (MESMO SEM PERCEBER)

Existe uma verdade que separa programadores comuns de engenheiros realmente perigosos:

🔥 os melhores não decoram código…

eles reconhecem padrões.

E isso vale para:

  • Python

  • Java

  • C

  • COBOL

  • Assembler

  • PL/I

  • DB2 SQL

  • CICS

  • z/OS

Porque no fundo…

programação é:

resolver problemas repetitivos de maneiras inteligentes.

E quando analisamos esses Coding Patterns ao estilo Bellacosa Mainframe…

descobrimos algo fascinante:

🔥 o Mainframe já utilizava muitos desses conceitos MUITO antes deles virarem moda em entrevistas LeetCode.


☕🔥 O QUE SÃO CODING PATTERNS?

São modelos mentais reutilizáveis.


☕ Em vez de decorar solução…

você aprende:

COMO PENSAR

☕ Bellacosa Mainframe Analysis™

Coding Pattern é como:

🔥 um PROC JCL mental reutilizável.


☕ Porque problemas diferentes frequentemente compartilham:

  • estrutura

  • lógica

  • fluxo

  • comportamento


☕🔥 1. TWO POINTERS — O “MATCHING” CLÁSSICO DO MAINFRAME

Dois ponteiros percorrendo estruturas simultaneamente.


☕ Muito usado em:

  • merge

  • comparação

  • busca

  • matching


☕ Isso lembra MUITO:

🔥 SORT/MERGE no z/OS.


☕ Exemplo clássico Mainframe

Comparar:

ARQUIVO CLIENTE
VS
ARQUIVO PAGAMENTO

☕ Dois ponteiros avançam conforme chave.


☕ COBOL usa isso há décadas.


☕🔥 2. SLIDING WINDOW — O “BUFFER DINÂMICO”

Padrão extremamente poderoso.


☕ A ideia:

uma janela percorre dados continuamente.


☕ Exemplo moderno

  • stream

  • logs

  • monitoramento

  • analytics


☕ No Mainframe isso lembra:

  • leitura sequencial VSAM

  • análise SMF

  • monitoramento RMF


☕ Excelente para:

🔥 reduzir complexidade absurda.


☕🔥 3. PREFIX SUM — O “ACUMULADOR CORPORATIVO”

Muito usado em:

  • estatísticas

  • relatórios

  • batch processing


☕ Bellacosa Mainframe Analysis™

Isso é praticamente:

🔥 processamento batch financeiro clássico.


☕ Exemplo bancário

Saldo acumulado:

saldo_anterior + movimento

☕ Mainframe vive disso.


☕🔥 4. MERGE INTERVALS — O “CONSOLIDADOR DE JANELAS”

Combinar intervalos sobrepostos.


☕ Aplicações reais

  • agendas

  • reservas

  • processamento temporal

  • janelas batch


☕ Isso lembra muito:

🔥 scheduler corporativo.


☕ JES2/JES3 possuem conceitos semelhantes de coordenação temporal.


☕🔥 5. BINARY SEARCH — O “CATÁLOGO INDEXADO” DO DB2

Busca dividindo espaço pela metade.


☕ O ganho é brutal:

O(log n)

☕ Bellacosa Mainframe Analysis™

É praticamente:

🔥 acesso indexado DB2/VSAM KSDS.


☕ Índices existem exatamente para evitar:

table scan infernal

☕🔥 6. SORTING PATTERNS — O REINO ABSOLUTO DO MAINFRAME

Aqui o Mainframe reina historicamente.


☕ SORT sempre foi:

🔥 uma arte no z/OS.


☕ DFSORT e SyncSort são monstruosamente otimizados.


☕ Grandes bancos literalmente dependem disso.


☕ Exemplo:

  • fechamento bancário

  • consolidação

  • ranking

  • billing


☕🔥 7. FAST & SLOW POINTERS — DETECTANDO CICLOS E ANOMALIAS

Dois ponteiros em velocidades diferentes.


☕ Excelente para:

  • loops

  • listas

  • estruturas cíclicas

  • detecção de comportamento


☕ Isso lembra:

🔥 monitoramento operacional.


☕ Em sistemas críticos:

detectar loop cedo evita desastre.


☕🔥 8. BACKTRACKING — A “BUSCA EXAUSTIVA INTELIGENTE”

Testa possibilidades recursivamente.


☕ Parece caro?

E é.


☕ Mas resolve problemas extremamente complexos.


☕ Exemplo corporativo

  • otimização

  • roteamento

  • IA

  • scheduling


☕🔥 9. DIVIDE AND CONQUER — O “PARALEL SYSPLEX” MENTAL

Dividir problema gigante em partes menores.


☕ Mainframe faz isso há décadas.


☕ Exemplos:

  • Parallel Sysplex

  • workload balancing

  • batch parallelism


☕ Isso escalou o mundo corporativo.


☕🔥 10. LINKED LISTS — O “ENCADENAMENTO” CLÁSSICO

Estruturas ligadas dinamicamente.


☕ Mainframe conhece isso profundamente.

Especialmente em:

  • buffers

  • control blocks

  • cadeias de memória


☕ Assembler vive disso.


☕🔥 11. STACKS & QUEUES — O “CICS” DA LÓGICA

Agora entramos numa das estruturas mais importantes da computação.


☕ Queue

FIFO.


☕ Stack

LIFO.


☕ Isso aparece em TODO lugar.


☕ Bellacosa Mainframe Analysis™

CICS trabalha pesado com conceitos de filas e pilhas operacionais.


☕ MQ então?

🔥 literalmente vive disso.


☕🔥 12. MONOTONIC STACK — O “OTIMIZADOR SILENCIOSO”

Pattern avançado.


☕ Excelente para:

  • análise sequencial

  • máximos/mínimos

  • otimização temporal


☕ Muito útil em:

  • mercado financeiro

  • séries temporais

  • observabilidade


☕🔥 13. EXPRESSION EVALUATION — O “COMPILADOR INTERNO”

Avaliação de expressões.


☕ Compiladores COBOL fazem isso constantemente.


☕ Exemplo:

COMPUTE TOTAL = A + B * C

☕ Existe parsing por trás.


☕🔥 14. STRING MANIPULATION — O IMPÉRIO DO COBOL

Mainframe ama texto estruturado.


☕ Exemplos:

  • EBCDIC

  • layouts

  • copybooks

  • parsing bancário


☕ COBOL virou mestre nisso.


☕🔥 15. HASHMAPS — O “CATÁLOGO RACF” MODERNO

Busca rápida por chave.


☕ Isso lembra:

  • tabelas de controle

  • catálogos

  • cache

  • diretórios RACF


☕ Extremamente eficiente.


☕🔥 16. TREES & BST — A HIERARQUIA CORPORATIVA

Estruturas hierárquicas.


☕ Mainframe usa isso em:

  • catálogos

  • RACF

  • hierarquias de storage

  • índices


☕🔥 17. PATH SUM — O “FLUXO TRANSACIONAL”

Analisar caminhos possíveis.


☕ Isso aparece em:

  • antifraude

  • IA

  • workflows

  • análise financeira


☕🔥 18. HEAPS — O “TOP N” CORPORATIVO

Excelente para encontrar:

  • maiores

  • menores

  • prioridades


☕ Exemplo bancário

🔥 TOP clientes por volume.


☕🔥 19. TOP K FREQUENT — O “RMF ANALYTICS”

Análise estatística frequente.


☕ Muito usado em:

  • observabilidade

  • logs

  • IA

  • SIEM


☕🔥 20. MERGE K SORTED LISTS — O “INTEGRADOR CORPORATIVO”

Combinar múltiplas listas ordenadas.


☕ Isso é MUITO Mainframe.


☕ Exemplo:

  • consolidar filiais

  • processamento distribuído

  • múltiplos datasets


☕🔥 21. DYNAMIC PROGRAMMING — O “OTIMIZADOR MATEMÁTICO”

Agora entramos na elite.


☕ DP resolve problemas reutilizando resultados anteriores.


☕ Isso reduz explosão computacional.


☕ Bellacosa Mainframe Analysis™

DP lembra:

🔥 cache inteligente corporativo.


☕🔥 22. GREEDY — O “DECIDA AGORA”

Escolha local imediata.


☕ Funciona muito bem em:

  • scheduling

  • roteamento

  • alocação


☕🔥 23. BFS & DFS — O “NAVEGADOR” DAS ESTRUTURAS

Traversal em grafos.


☕ Muito usado em:

  • redes

  • IA

  • dependências

  • análise de infraestrutura


☕🔥 24. GRAPH ALGORITHMS — O “MAPA DO MUNDO DIGITAL”

A internet inteira é um grafo.


☕ Sistemas corporativos modernos também.


☕ Isso impacta:

  • redes

  • supply chain

  • fraudes

  • relacionamentos


☕🔥 25. DESIGN PROBLEMS — O VERDADEIRO NÍVEL SENIOR

Aqui termina o tutorial…

e começa engenharia real.


☕ Porque agora o problema deixa de ser:

como codar

e passa a ser:

como arquitetar

☕🔥 O MAINFRAME SEMPRE FOI “PATTERN-DRIVEN”

Essa talvez seja a maior conclusão.


☕ Mainframe nunca foi apenas linguagem.

Sempre foi:

  • arquitetura

  • repetibilidade

  • previsibilidade

  • padrões operacionais


☕ Por isso sistemas z/OS sobrevivem décadas.


☕🔥 CONCLUSÃO — PROGRAMAR NÃO É ESCREVER CÓDIGO… É RECONHECER PADRÕES

Os melhores engenheiros não decoram respostas.

Eles identificam:

  • estruturas

  • comportamentos

  • padrões invisíveis

E talvez essa seja a maior ironia da computação moderna:

enquanto muita gente acha que esses Coding Patterns nasceram com entrevistas FAANG…

🔥 o Mainframe já resolvia muitos desses problemas silenciosamente há mais de 40 anos.

quarta-feira, 8 de janeiro de 2020

☕💥 Algoritmos no Mainframe: Da Matemática de Al-Khwarizmi ao COBOL no z/OS

 

Bellacosa Mainframe apresenta algoritmos na programação

☕💥 Algoritmos no Mainframe: Da Matemática de Al-Khwarizmi ao COBOL no z/OS

Ou como um programador COBOL Padawan descobre que, antes de existir código, existia lógica

"Um bom algoritmo faz um bom programa. Um excelente algoritmo faz o programador parecer um mago. Um algoritmo ruim faz o operador do turno da madrugada querer abrir um chamado para exorcismo."

— Bellacosa Mainframe

Introdução

Existe uma frase que gosto de repetir aos meus alunos padawans:

"COBOL não é difícil. Difícil é pensar."

E isso pode soar estranho.

Muitos acreditam que programar significa decorar comandos, aprender sintaxe, conhecer verbos COBOL ou dominar JCL.

Não.

Programar é, essencialmente, aprender a pensar de forma estruturada.

E isso possui um nome.

Algoritmo.

Antes do COBOL.

Antes do Assembler.

Antes do FORTRAN.

Antes do System/360.

Antes do z16.

Antes do ChatGPT.

Já existiam algoritmos.

E a história deles é simplesmente fantástica.


O nascimento dos algoritmos

A palavra algoritmo deriva do nome do matemático persa:

Muhammad ibn Musa al-Khwarizmi

(cerca de 780–850 d.C.)

Ele escreveu um tratado chamado:

"Kitab al-Jabr wa-l-Muqabala"

Livro que deu origem à palavra:

Algebra

E seu nome latinizado tornou-se:

Algorismus

Posteriormente:

Algorithm

Ou seja...

Cada vez que fazemos:

ADD A TO B GIVING TOTAL

estamos usando ideias desenvolvidas há mais de mil anos.


Algoritmos antes dos computadores

Curiosamente, algoritmos são muito mais antigos que computadores.

Exemplos:

Receitas culinárias

Procedimentos militares

Construção de pirâmides

Cálculos astronômicos

Navegação marítima

Tributação romana

Tudo era algoritmo.

Apenas não era chamado assim.


O primeiro algoritmo famoso

O algoritmo de Euclides.

300 a.C.

Encontrar o MDC.

Exemplo:

MDC(48,18)

Passo 1

48 mod 18 = 12

Passo 2

18 mod 12 = 6

Passo 3

12 mod 6 =0

Resposta

6

Dois mil anos depois...

Continuamos utilizando a mesma lógica.


A chegada dos computadores

Década de 1940.

ENIAC

UNIVAC

EDSAC

LEO I

IBM 650

IBM 7070

A grande dificuldade não era processador.

Era ensinar uma máquina a pensar.

E pensar significava:

Transformar problemas em algoritmos.


O nascimento do mainframe

1952

IBM 701

1954

IBM 704

1964

System/360

Um dos projetos mais revolucionários da história.

Pela primeira vez:

Uma arquitetura única.

Diversos equipamentos.

Compatibilidade.

E o software começava a ganhar importância.


O problema dos programas gigantes

Década de 50.

Empresas começavam a automatizar:

Folha de pagamento

Seguros

Bancos

Governo

Previdência

Surgiu um problema.

Como ensinar milhares de pessoas a desenvolver sistemas?

Resposta:

Criando linguagens de alto nível.


COBOL nasce em 1959

CODASYL.

Grace Hopper.

Departamento de Defesa Americano.

Objetivo:

Criar uma linguagem próxima do inglês.

Exemplo:

READ CLIENTE

IF SALDO > 1000

   PERFORM LIBERA-CREDITO

END-IF

Mas existe um detalhe importante.

COBOL não pensa.

Quem pensa é o desenvolvedor.

COBOL apenas executa.

O algoritmo continua sendo o verdadeiro cérebro.


O algoritmo escondido dentro do COBOL

Muitos iniciantes acreditam:

"Aprendi COBOL."

Não.

Aprendeu comandos.

Programar é construir algoritmos.

Exemplo.

Problema:

Calcular média.

Padawan inexperiente:

ADD A TO B
ADD C TO TOTAL
DIVIDE 3 INTO TOTAL

Padawan treinado:

Entrada

3 notas

Processamento

Somar

Dividir

Saída

Média

Ele pensa primeiro.

Codifica depois.


Características de um algoritmo

Entrada

Pode possuir dados.

Exemplo:

Arquivo VSAM

DB2

MQ

GDG

SYSIN


Saída

Relatório

Arquivo

Mensagem

Tela CICS

API JSON


Finitude

Todo algoritmo precisa terminar.

Exemplo ruim:

PERFORM FOREVER

Exemplo bom:

PERFORM UNTIL EOF='S'

Clareza

Evitar ambiguidades.

Ruim:

"Processar cliente"

Bom:

Ler registro

Validar CPF

Consultar saldo

Atualizar DB2

Gravar auditoria


Algoritmos nos Batchs Mainframe

Imagine.

Banco processando PIX.

2 bilhões de registros.

A lógica continua igual.

Entrada

SORTIN

Processamento

JOINKEYS

ICETOOL

COBOL

Saída

SORTOUT

Relatórios

DB2

MQ


O algoritmo do fechamento bancário

Leitura

Validação

Consolidação

Apuração

Tributação

Geração de extrato

Backup

Auditoria

Tudo algoritmo.


Algoritmos no CICS

O novato vê:

EXEC CICS RECEIVE

EXEC CICS SEND

EXEC CICS LINK

Mas por trás existe:

Receber dados

Validar

Consultar

Persistir

Retornar

Fluxo decisório.


Algoritmos no Natural

Mesmo conceito.

MAP

READ

FIND

END-FIND

ESCAPE TOP

DECIDE ON

São apenas ferramentas.

O raciocínio continua sendo algoritmo.


Pseudocódigo

Excelente ferramenta para padawans.

Exemplo.

Transferência bancária.



Inicio


Ler conta origem


Ler conta destino


Ler valor


Saldo suficiente ?


SIM


Debitar


Creditar


Gerar log


Nao


Retornar erro



Fim



Só depois escrevemos COBOL.


Fluxogramas

Muito utilizados nos anos 70.

Analistas desenhavam:

Retângulos

Losangos

Setas

Pastas físicas.

Canetas.

Régua.

Pranchetas.

Sim.

Mainframe já existia antes do Visio.


Algoritmos de busca

Busca sequencial.

Busca binária.

Hash.

Índices VSAM.

DB2 Index.

B-tree.

LSM Trees.

Todos são algoritmos.


Algoritmos de ordenação

Mainframe ama ordenação.

DFSORT.

SYNCSORT.

ICETOOL.

Métodos famosos:

Bubble Sort

Merge Sort

QuickSort

HeapSort

No universo IBM, o Merge Sort praticamente reina.


Complexidade computacional

Nem todo algoritmo é igual.

O(1)

Constante

O(log n)

Busca binária

O(n)

Linear

O(n²)

Bubble

O(2ⁿ)

Exponencial


O dia em que um COBOL virou um monstro

Já vi programa COBOL com:

70 mil linhas.

350 PERFORM.

1200 IF.

85 GO TO.

Documentação inexistente.

Autor aposentado em 1998.

Chamado aberto em produção.

Ninguém sabe mexer.

Por quê?

Ausência de algoritmo.

Código cresceu.

Pensamento não.


Design de algoritmos

Força Bruta

Dividir e conquistar

Backtracking

Greedy

Programação dinâmica

Mesmo em bancos.

Mesmo em seguradoras.

Mesmo em governo.


Algoritmos modernos no IBM Z

Hoje temos:

z16

z17

LinuxONE

OpenShift

zCX

API Connect

z/OS Connect

Kafka

Python

Java

Node.js

AI

Machine Learning

Mas adivinhe.

O algoritmo continua sendo rei.


Inteligência Artificial também vive de algoritmos

Redes neurais.

Transformers.

LLMs.

Árvores.

Regressão.

Clustering.

Tudo algoritmo.

A IA não substituiu algoritmos.

Ela apenas os sofisticou.


O maior erro dos novos programadores

Querer aprender linguagem.

Antes de aprender lógica.

É equivalente a comprar um sabre de luz sem saber usar a Força.


Conselhos para um Padawan COBOL

Primeiro pense.

Depois desenhe.

Depois escreva.

Depois teste.

Depois otimize.

Nunca faça o inverso.

Pergunte sempre:

Quais entradas?

Qual processamento?

Qual saída?

Existem exceções?

Qual volume?

Como recuperar falhas?

Como auditar?

Como escalar?


O algoritmo invisível que move o mundo

Quando um cliente faz PIX.

Existe algoritmo.

Quando um avião decola.

Existe algoritmo.

Quando uma seguradora calcula prêmio.

Existe algoritmo.

Quando um cartão aprova compra.

Existe algoritmo.

Quando o INSS paga benefícios.

Existe algoritmo.

Quando um CICS responde em menos de um segundo.

Existe algoritmo.

E quando um velho programa COBOL criado em 1987 continua funcionando perfeitamente em um IBM Z moderno...

Existe um bom algoritmo escondido ali.


Considerações finais

Muitos dizem que COBOL é uma linguagem antiga.

Discordo.

COBOL é apenas um meio de expressão.

A verdadeira tecnologia imortal chama-se algoritmo.

Ela nasceu com matemáticos árabes, sobreviveu aos impérios, atravessou a Revolução Industrial, alimentou os primeiros computadores, ajudou a criar o System/360, sustentou bancos por décadas, acompanhou a internet, chegou ao z/OS, conversa hoje com APIs REST e provavelmente continuará existindo quando estivermos programando computadores quânticos.

Portanto, jovem Padawan, lembre-se:

Você não é pago para escrever DISPLAY, MOVE, ADD ou EXEC CICS.

Você é pago para transformar problemas caóticos em sequências ordenadas de decisões capazes de gerar valor para empresas, governos e pessoas.

E esse poder, desde Al-Khwarizmi até o IBM z17, continua tendo exatamente o mesmo nome:

Algoritmo.

☕🚀 E como diria um velho mestre do Bellacosa Mainframe:

"Código envelhece. Linguagens mudam. Frameworks desaparecem. Mas um algoritmo elegante continua sendo reconhecido por qualquer programador, em qualquer época, em qualquer plataforma."

 

domingo, 22 de junho de 2014

☕🔥 MAXCC — O “HUMOR” DO JOB NO z/OS

 

Bellacosa Mainframe e o max-cc conditional code

☕🔥 MAXCC — O “HUMOR” DO JOB NO z/OS

Quando o Mainframe Diz:

“SEU JOB TERMINOU… MAS EU TENHO ALGO A DIZER.”

Se existe uma coisa que TODO Junior Padawan COBOL precisa aprender cedo…

é que no z/OS:

nem todo fim de job é igual.

Às vezes o JOB termina:

✅ normalmente
⚠️ com avisos
🔥 com erros graves
☠️ completamente destruído

E quem conta essa história é o:

🚨 MAXCC


☕ O QUE É MAXCC?

MAXCC significa:

MAXIMUM CONDITION CODE

É o maior retorno gerado pelos steps do JOB.


🔥 A FILOSOFIA DO MAXCC

No z/OS:

programas “conversam” com o scheduler usando códigos numéricos.

Exemplo:

RETURN-CODE = 0

significa:

“Tudo OK.”

Mas:

RETURN-CODE = 16

significa:

“O APOCALIPSE CHEGOU.”


☕ O MAXCC MAIS FAMOSO

No SDSF/JESMSGLG:

MAXCC=0000

ou:

COND CODE 0004

🔥 O SEGREDO

MAXCC NÃO É ABEND.

Isso é MUITO importante.


☕ ABEND

Falha anormal.

Exemplo:

  • S0C7

  • S0C4

  • S806


☕ MAXCC

Programa terminou normalmente…

MAS quer avisar algo.


🔥 MAXCC 00 — O “MUNDO EM PAZ”

✅ MAXCC=0000

Significa:

tudo terminou perfeitamente.


☕ EXEMPLO

IEF142I STEP01 - STEP WAS EXECUTED - COND CODE 0000

🔥 INTERPRETAÇÃO BELLACOSA

O mainframe está dizendo:

☕ “Excelente, Padawan. Nada explodiu hoje.”


☕ CENÁRIO TÍPICO

  • arquivo processado

  • SORT OK

  • DB2 OK

  • nenhum warning

  • tudo consistente


🔥 MAXCC 04 — O “WARNING ELEGANTE”

⚠️ MAXCC=0004

O JOB terminou.

Mas:

algo merece atenção.


☕ O MAIS IMPORTANTE

MAXCC 4 normalmente NÃO é erro fatal.

Muitos jobs em produção aceitam:

RC=4 normalmente.


🔥 EXEMPLOS CLÁSSICOS


☕ SORT

SORT FIELDS=COPY

Mas:

  • registro inválido ignorado

  • campo truncado

  • duplicidade encontrada

Resultado:

RC=4


☕ IDCAMS

DELETE DATASET

Dataset não existe.

IDCAMS retorna:

4

Porque:

“não achei, mas sobrevivi.”


☕ IEBCOPY

Membro duplicado.

Warning.

RC=4.


🔥 INTERPRETAÇÃO BELLACOSA

☕ “Nada morreu… mas eu notei uma coisa estranha.”


🔥 MAXCC 08 — O “ERRO OPERACIONAL”

❌ MAXCC=0008

Agora a conversa ficou séria.


☕ SIGNIFICADO

o processamento falhou parcialmente.


🔥 MUITOS JOBS PARAM EM RC=8

Schedulers frequentemente tratam:

RC >= 8

como falha.


☕ EXEMPLOS CLÁSSICOS


☕ SORT

Campo inválido.

Chave inconsistente.

Arquivo problemático.


☕ IDCAMS

Falha em DEFINE CLUSTER.


☕ DB2

SQLCODE sério.


☕ COBOL

Programa detecta erro de negócio:

MOVE 8 TO RETURN-CODE
STOP RUN

🔥 INTERPRETAÇÃO BELLACOSA

☕ “Padawan… algo deu errado e você PRECISA olhar.”


🔥 MAXCC 12 — O “DESASTRE CONTROLADO”

☠️ MAXCC=0012

Agora entramos na zona crítica.


☕ SIGNIFICADO

Erro grave.

Processamento comprometido.


🔥 EXEMPLOS CLÁSSICOS

  • falha forte em SORT

  • utility quebrada

  • VSAM inconsistente

  • falha DB2 importante

  • step inutilizado


☕ O JOB AINDA TERMINOU

Isso diferencia de ABEND.

O programa conseguiu:

terminar conscientemente.

Mas avisando:

“o resultado NÃO é confiável.”


🔥 EXEMPLO COBOL

IF WS-ERRO-CRITICO = 'S'
   MOVE 12 TO RETURN-CODE
   STOP RUN
END-IF

🔥 INTERPRETAÇÃO BELLACOSA

☕ “O castelo ainda está de pé… mas está pegando fogo.”


🔥 MAXCC 16 — O “JUÍZO FINAL”

🚨 MAXCC=0016

Aqui o sistema está praticamente gritando.


☕ SIGNIFICADO

falha gravíssima.


🔥 MUITOS PRODUTOS TRATAM 16 COMO FATAL

Especialmente:

  • DFSORT

  • IDCAMS

  • DB2 utilities

  • IEBCOPY

  • custom utilities


☕ EXEMPLOS CLÁSSICOS

  • arquivo inacessível

  • utility impossível de executar

  • parâmetro inválido

  • corrupção

  • inconsistência crítica


🔥 COBOL TAMBÉM PODE RETORNAR 16

MOVE 16 TO RETURN-CODE
STOP RUN

☕ INTERPRETAÇÃO BELLACOSA

☕ “Padawan… o processamento fracassou de forma épica.”


🔥 O SEGREDO MAIS IMPORTANTE

CADA PRODUTO INTERPRETA RC DE FORMA DIFERENTE.


☕ EXEMPLO

Para um utilitário:

RC=4

pode ser trivial.

Para outro:

RC=4

já significa problema sério.


🔥 O JCL E O COND=

Agora nasce o verdadeiro conhecimento Jedi.


☕ EXEMPLO

//STEP2 EXEC PGM=PROG2,COND=(8,LT)

Significa:

execute STEP2 somente se RC anterior NÃO for menor que 8.


🔥 O IF/THEN/ELSE MODERNO

Mais elegante:

// IF (STEP1.RC > 4) THEN
//STEPERR EXEC PGM=ALERTA
// ENDIF

☕ O MAXCC E O JES2

O JES acompanha:

  • RCs

  • ABENDs

  • steps

  • histórico do JOB


🔥 O MAXCC E O SCHEDULER

Ferramentas como:

  • Control-M

  • CA7

  • TWS

tomam decisões usando:

RC/MAXCC.


☕ EXEMPLO REAL

RC=0 → continua fluxo
RC=4 → warning
RC>=8 → dispara incidente

🔥 O MAIOR ERRO DO PADAWAN

Achar:

RC=4 = tudo OK

Não necessariamente.

Você PRECISA entender:

o contexto do utilitário/programa.


☕ O SEGREDO DOS VETERANOS

Veteranos sempre perguntam:

“QUEM RETORNOU O RC?”

Porque:

  • DFSORT

  • IDCAMS

  • COBOL

  • DB2

  • CICS utilities

cada um possui semântica própria.


🔥 CURIOSIDADE HISTÓRICA

MAXCC existe desde os tempos do:

OS/360

Década de:

🏛️ 1960

IBM precisava que jobs batch “conversassem” automaticamente entre si.

Então nasceram:

  • return codes

  • condition codes

  • job control logic


☕ EASTER EGG MAINFRAME

Veteranos brincam:

RC=0 → “milagre corporativo”

RC=4 → “o sistema tossiu”

RC=8 → “alguém vai abrir chamado”

RC=12 → “gerência foi avisada”

RC=16 → “prepare o café… a madrugada será longa.”


quinta-feira, 17 de abril de 2014

☕🔥 ABEND S837 — O “CEMITÉRIO DOS DATASETS” NO z/OS

 

Bellacosa Mainframe e o abend s837

☕🔥 ABEND S837 — O “CEMITÉRIO DOS DATASETS” NO z/OS

Quando o Mainframe Diz:

“EU NÃO CONSIGO ALOCAR ESSE DATASET.”

Se existe um ABEND que faz o Junior Padawan perceber que:

espaço em disco no mainframe é um ritual sagrado…

é o lendário:

🚨 S837

E normalmente ele aparece assim:

IEF450I JOBNAME STEP01 - ABEND=S837

ou:

SPACE ALLOCATION FAILED

ou ainda:

NO SPACE LEFT ON VOLUME

E então começa o caos existencial:

“O dataset não nasceu?”
“O disco acabou?”
“O SMS ficou bravo?”
“Meu SORT criou um buraco negro?”
“Como um mainframe GIGANTE pode ficar sem espaço?!”

☕ Respira.

Porque o S837 é um dos ABENDs MAIS IMPORTANTES para entender:

SPACE allocation

DASD

extents

SMS

secondary allocation

SORT work datasets

volumes z/OS


🔥 O QUE É O S837?

O S837 é um:

🚨 SPACE ALLOCATION FAILURE

Traduzindo:

O z/OS NÃO CONSEGUIU ENCONTRAR ESPAÇO EM DISCO PARA O DATASET.


☕ A FILOSOFIA DO S837

No mainframe:

datasets ocupam espaço físico controlado rigorosamente.

Nada é “solto” como em PCs modernos.

Tudo precisa de:

  • cylinders

  • tracks

  • extents

  • volumes

  • allocation units


🔥 ANALOGIA BELLACOSA MAINFRAME

Imagine um estacionamento corporativo.

Seu caminhão chega precisando:

50 vagas contínuas.

Mas:

  • estacionamento lotado

  • vagas fragmentadas

  • limite atingido

Resultado:

❌ sem espaço.

Isso é o:

☠️ S837


🔥 O GRANDE SEGREDO

S837 NÃO significa necessariamente:

“acabou disco no datacenter.”

Frequentemente significa:

não existe espaço adequado para aquela alocação.


☕ O MOMENTO EXATO DO S837

Fluxo:

JCL solicita dataset
 ↓
z/OS tenta alocar espaço
 ↓
DASD/SMS procura área livre
 ↓
Falha
 ↓
S837

🔥 O MAIOR VILÃO DO S837

🚨 SPACE MAL DIMENSIONADO

O clássico absoluto.


☕ EXEMPLO JCL

//OUTFILE DD DSN=TESTE.ARQ,
// SPACE=(CYL,(5000,5000))

Mas o volume NÃO possui isso disponível.

Resultado:

💥 S837


🔥 O SORT DA MORTE

Lenda absoluta do z/OS.


☕ EXEMPLO

//SORTWK01 DD UNIT=SYSDA,SPACE=(CYL,(9999,9999))

DFSORT tenta criar work datasets gigantescos.

O disco entra em sofrimento espiritual.

Resultado:

☠️ S837


🔥 O S837 E O “SECONDARY SPACE”

Agora nasce o conhecimento Jedi.


☕ PRIMARY SPACE

Espaço inicial.


☕ SECONDARY SPACE

Expansão dinâmica.


🔥 O PROBLEMA

Primary cabe.

Mas durante crescimento:

secondary allocation falha

Resultado:

💥 S837


☕ O S837 FANTASMA

O mais traiçoeiro.

Job roda:

30 minutos normal

E explode depois.

Porque dataset cresceu além do previsto.


🔥 O S837 E O “EXTENTS”

Modo arquimago ativado.


☕ O QUE É EXTENT?

Bloco contínuo de espaço em disco.

Datasets possuem limite de extents.


🔥 O DRAMA

Disco possui espaço.

Mas fragmentado demais.

Sistema não consegue criar novo extent adequado.

Resultado:

☠️ S837


☕ O S837 E O SMS

Hoje muitos ambientes usam:

SMS (Storage Management Subsystem)

Ele decide:

  • volume

  • classe

  • performance

  • gerenciamento

Políticas SMS inadequadas podem causar:

💥 S837


🔥 O S837 E O GDG

Outro clássico.

Gerações antigas:

  • não apagadas

  • acumuladas

  • espaço esgotado

Nova geração tenta nascer.

Resultado:

☠️ S837


☕ O S837 E O RLSE

Parâmetro mágico:

RLSE

Libera espaço não usado ao final do job.

Sem isso:

desperdício silencioso.


🔥 O S837 E O UNIT=SYSDA

Outro cenário clássico.

Todos jobs disputando:

mesmos volumes.

Ambiente congestionado.

Resultado:

💥 falha de alocação.


☕ O S837 E O DB2

Utilities DB2 podem gerar datasets temporários gigantes:

  • SORT

  • REORG

  • UNLOAD

  • LOAD

Space errado?

☠️ S837


🔥 O S837 E O CICS

Menos comum diretamente.

Mas logs/journals/datasets auxiliares também podem sofrer.


☕ O S837 E O “VOLUME FULL”

Às vezes o volume realmente está:

LOTADO.

Operador olha:

D U,VOL=XXXX

E percebe:

sem espaço restante.


🔥 COMO INVESTIGAR O S837 PASSO A PASSO


✅ PASSO 1 — VERIFIQUE JESMSGLG

Procure:

S837
SPACE ALLOCATION FAILED
B37
E37

✅ PASSO 2 — IDENTIFIQUE O DDNAME

Qual dataset falhou?

SORTWK01
OUTFILE
TEMP001

✅ PASSO 3 — ANALISE SPACE=

Veja:

SPACE=(CYL,(x,y))

ou:

SPACE=(TRK,(x,y))

✅ PASSO 4 — VERIFIQUE VOLUME

Talvez:

  • cheio

  • fragmentado

  • limitado


✅ PASSO 5 — VERIFIQUE EXTENTS

Datasets podem atingir:

limite máximo de extents.


🔥 O SEGREDO DOS B37/E37

Parentes sombrios do S837.


☕ B37

Sem espaço durante escrita.


☕ E37

Sem extents disponíveis.


☕ S837

Falha de alocação/expansão.


🔥 O DUMP DO S837

Normalmente pouco útil.

O ouro está em:

  • mensagens IEC

  • SMS reports

  • allocation messages

  • JESMSGLG


☕ MENSAGENS IMPORTANTES


☕ IEC030I

Problemas de espaço/extents.


☕ IEC070I

Falha de allocation.


☕ IGDxxxx

Mensagens SMS.


🔥 O MAIOR ERRO DO PADAWAN

Resolver tudo assim:

SPACE=(CYL,(9999,9999))

Agora o job pede:

MAIS ESPAÇO DO QUE O DATACENTER POSSUI.


☕ O VERDADEIRO JEDI

Não apenas aumenta espaço.

Ele pergunta:

“QUAL O CRESCIMENTO REAL DO DATASET?”


🔥 COMO EVITAR S837


✅ Dimensionar SPACE corretamente


✅ Revisar secondary allocation


✅ Usar RLSE


✅ Monitorar SORTs gigantes


✅ Limpar GDGs antigos


✅ Revisar SMS classes


✅ Evitar datasets monstruosos desnecessários


✅ Monitorar extents


☕ O SEGREDO DOS VETERANOS

Veteranos respeitam profundamente:

SPACE planning.

Porque no z/OS:

storage físico ainda importa MUITO.


🔥 CURIOSIDADE HISTÓRICA

Nos anos 60/70:

discos eram:

  • pequenos

  • caríssimos

  • lentos

Programadores literalmente calculavam:

trilhas e cilindros manualmente.

O S837 nasceu dessa realidade brutal.


☕ EASTER EGG MAINFRAME

Veteranos brincam:

“S837 significa:

Seu Dataset Tentou Crescer Mais do Que o Universo Permitia.”


🔥 O MAIOR ENSINAMENTO DO S837

Ele ensina algo profundo:

no z/OS, armazenamento é engenharia matemática.

Não basta:

“salvar arquivo”

É preciso entender:

  • cylinders

  • tracks

  • extents

  • SMS

  • crescimento

  • fragmentação

  • alocação física


☕ A VERDADE FINAL

O S80A pune falta de memória.
O S878 pune fragmentação de storage virtual.
O S913 pune falta de autorização.

Mas…

☕ O S837 É O MOMENTO EM QUE O z/OS OLHA PARA O DISCO… E DESCOBRE QUE NÃO EXISTE MAIS ESPAÇO ADEQUADO PARA O SEU DATASET NASCER.